A tutta velocita’ con PHP-FPM

PHP-FPM Very Fast

Come sa bene chiunque si occupi di creare e gestire un servizio Web moderno, il primo aspetto che viene ricercato e di cui si chiede la massima affidabilita’, e’ la velocita’ di risposta, cosi da garantire la presenza online delle imprese supportando il lavoro quotidiano delle Web Agency.

Nonostante oggi giorno ci siano nuovi linguaggi di sviluppo e di scripting il PHP rimane comunque ancora uno dei piu’ utilizzati e, grazie alle nuove funzionalita’ del PHP-FPM, questo linguaggio tornera’ sicuramente ad avere un ruolo di rilievo.

Ma, facciamo un piccolissimo passo indietro per rivedere come sono state gestite fino a ieri tutte le richieste php fatte dagli utenti ai vostri siti.

La maggior parte degli amministratori di siti sa che il PHP può essere incorporato nell’ HTML e che funziona con i principali web server. Tuttavia, l’aspetto meno conosciuto è la modalità con cui può essere eseguito il PHP sul web server, e questo può avvenire in diversi modi.

Aggiungiamo nell’equazione anche l’acronimo LAMP che, per chi non lo conoscesse, indica una piattaforma software per lo sviluppo di applicazioni web e sta per :

  • Linux (il sistema operativo)
  • Apache (il server web)
  • MySQL o MariaDB (il database management system)
  • PHP (il linguaggio di programmazione)

Come stavamo dicendo, fino a ieri  la modalità con cui si eseguivano le richieste e i processi di php sulla piattaforma LAMP era il PHP FastCGI.

Si tratta di un protocollo generico utilizzato per l’interfacciamento con un server web. Nello specifico è una variante della precedente Common Gateway Interface (CGI) che ha come obiettivo quello di ridurre il sovraccarico associato all’ interfacciamento tra web server e programmi CGI, consentendo ad un server di gestire più richieste contemporaneamente.

Ma con FastCGI è possibile configurare più versioni di PHP, cosa particolarmente utile quando si hanno vecchi siti web creati, ad esempio, in PHP 5.1 che non sono compatibili con l’ultima versione, inoltre, con FastCGI è possibile supportare diversi utenti ognuno con le proprie istanze di PHP. Questa funzione è particolarmente importante per migliorare la sicurezza in un ambiente condiviso, in cui è possibile avere utenti diversi che gestiscono ciascuno i propri siti web.

Andiamo ancora avanti, quindi grazie al protocollo PHP FastCGI il webserver genera un’ unico processo in fase di inizializzazione che, al termine della fase di start-up, si mette in attesa. Ogni volta che arriva una nuova richiesta in ingresso, il webserver apre una connessione con il processo fast-cgi (in attesa) che a sua volta genera l’output sulla connessione con il client, trasferitagli dal server. Il vantaggio principale di questo protocollo è la creazione dei processi solo in fase di inizializzazione, ottimizzando così il numero dei processi php.

Bene, quindi cerchiamo di capire adesso che cosa cambia con l’introduzione di PHP-FPM ?

PHP-FPM è una modalità più recente (nato nel 2004 come patch di PHP) di utilizzare PHP con un server web, ed è un’alternativa al precedente PHP FastCGI con l’implementazione di alcune funzionalità aggiuntive molto utili, in particolare ai siti che gestiscono quotidianamente sempre più traffico (dai siti vetrina agli e-commerce). Per queste tipologie di siti web è sempre piu’ necessario avere a disposizione strumenti sempre più performanti, proprio come il PHP-FPM.

Fino ad oggi una delle grosse mancanze di FastCGI è stata l’impossibilità di avere un numero di CHILD (processi) PHP che cambi in modo dinamico a seconda delle richieste effettive.

Nel suo insieme, il funzionamento è molto simile al FastCGI e si basa dunque sull’ esecuzione ottimizzata dei processi php che vengono creati solo in fase di inizializzazione e rimangono in attesa di una nuova richiesta. La grossa differenza sta nel fatto che è lo stesso PHP-FPM ad eseguire il processo e non più il web server.

Il “Process Manager” è uno script che gestisce direttamente i processi PHP, nella pratica attende e riceve istruzioni dal server web ed esegue gli script PHP richiesti, permettendo cosi ad un sito web di gestire carichi intensi. Il PHP-FPM mantiene dei “pool” per rispondere alle richieste PHP e i processi che si generano sono direttamente “figli” (CHILD) del Process Manager e possono quindi essere gestiti separatamente dal web server.

Questa modalità garantisce una maggiore robustezza del servizio, poiché tutte le operazioni come i cambi di configurazione o il restart dei processi, impattano i singoli pool FPM e non più l’intero web server.

Ecco alcune delle interessanti caratteristiche tecniche:

  • Demonizzazione dei processi PHP (file PID, file log, setsid(), setuid(), setgid(), chroot();
  • Possibilità di riavviare i processi PHP senza causare alcuna interruzione delle richieste in fase di processamento, si potra’ quindi cambiare qualsiasi parametro nel file di configurazione o addirittura aggiornare PHP senza avere nemmeno 1 secondo di downtime;
  • Possibilità di non processare le richieste provenienti da un determinato IP;
  • Possibilità di avviare i CHILD sotto differenti UID/GID/CHROOT e con differenti impostazioni di PHP (php.ini) il tutto senza bisogno di safe mode;
  • Possibilità di loggare tramite stdout e stderr;
  • In caso di corruzione della memoria RAM condivisa utilizzata da un OPCode Cache, PHP-FPM può effettuare un riavvio di emergenza di tutti i CHILD PHP;
  • Forza l’arresto dell’esecuzione di uno script nel caso in cui set_time_limit() avesse dei problemi.

Secondo un recente articolo pubblicato su CloudWays, effettuare uno switch da mod_php a PHP-FPM permetterebbe, tra i tanti vantaggi attesi, di ridurre del 300% i tempi di caricamento delle Web Application a traffico elevato.

La UE ricompensa chi scova bug

Bug Bounty UE Environment

Ormai e’ una tendenza che trova sempre maggiori conferme ogni giorno che passa, infatti e’ di pochissimi giorni la nuova interessante notizia (per chi lo e’ gia e per chi vorrebbe diventare un Bug Bounty), che imparare a scovare i bug nel codice e’ un lavoro molto remunerativo.

Proprio pochi giorni fa avevamo pubblicato l’articolo FB Bug Bounty e scopriamo con interessato stupore che anche la UE ha deciso di istituire qualcosa di simile.

Come gia ampiamente affermato “non esiste software esente da bug” , non lo sono i progetti a codice chiuso e, chiaramente, non lo sono nemmeno quelli Open Source, ma con l’ovvio vantaggio che chi sa e puo’ fare, diventa facilmente un “revisore” di codice ad uso e consumo di tutti coloro che quel software decidono di usarlo.

Insomma e’ un po’ come quando si parla della Blockchain e si dice “ecco il codice, la transazione e’ li pubblica, verificatela”, o come quando si scrivono le pagine di Wikipedia, se si scrive qualcosa di inesatto, ci sara’ qualcun’altro che leggendo fara’ la correzione etc…..

A parte cio’ quale miglior modo di convincere il maggior numero possibile di programmatori (ed esperti di codice) , ad usare il proprio talento e tempo se non quello di offire delle vere e proprie “taglie” sulla testa dei Bug 😉

Questo sistema, funziona ormai talmente bene, pensiamo a coloro che scovano i famigerati zero-day per i grandi colossi (Apple, Facebook, Whatsapp, Huawei….etc), che anche la Unione Europea ha deciso di varare un proprio programma di ricompensa economica, come parte del progetto FOSSA (Free and Open Source Software Audit).

L’iniziativa è stata annunciata, con un post sul suo sito web, da Julia Reda, membro del European Pirate Party e co-fondatrice del progetto FOSSA, con il titolo:
In January, the EU starts running Bug Bounties on Free and Open Source Software

Dunque, a partire da Gennaio 2019 la Commissione Europea garantira’ finanziamenti ai progetti di “caccia al bug”, ma non per ogni progetto Open esistente al mondo, soltanto per una lista ben specifica di 15 Programmi che sono ovviamente utilizzati a livello Istituzionale ed Europeo, con ricompense che vanno da 17.000 a 90.000 euro.

La lista dei progetti open source interessati comprende parecchi software noti:

  • 7-zip
  • Apache Kafka
  • Apache Tomcat
  • Digital Signature Services (DSS)
  • Drupal
  • Filezilla
  • FLUX TL
  • the GNU C Library (glibc)
  • KeePass
  • Notepad++
  • PuTTY
  • PHP Symfony
  • VLC Media Player
  • WSO2
  • Midpoint

I ricercatori, gli sviluppatori, gli esperti di sicurezza, insomma tutti coloro i quali sono interessati a dare il loro contributo, dovranno segnalare la presenza di eventuali bug attraverso le piattaforme HackerOne e Intigriti/Deloitte.
I programmi termineranno tra il 31 luglio 2019 e il 15 aprile 2020, mentre quelli che potete leggere sulla tabella qui sotto saranno i premi in denaro per ogni software. Good Luck !!!

 

 

UE Bug Bounty Program

Mesosphere e la scalabilità dei Data Center

Mesos(sphere) Data Center scalabili

Mesos(sphere) Data Center scalabili

Mesosphere , per chi ancora non la conoscesse, è una startup con sede a San Francisco che si è concentrata sullo sviluppo di un sistema operativo per garantire la scalabilità di un Data Center attraverso il componente open source Apache Mesos, nato dalle viscere della UC Berkeley e già adottato e riadattato nell’uso da giganti del calibro di Twitter, eBay e Airbnb ed anche Apple, che ha ricostruito il progetto SIRI proprio sulla piattaforma tecnologica di Mesos.

L’obiettivo di Mesosphere è semplice, ossia rendere Mesos e le tecnologie a esso affini adatte all’uso anche nelle piccole enterprise, cioè in tutte quelle realtà che non possono permettersi un esercito di ingegneri pronti a prototipare e mettere in produzione un sistema proprietario. In questo modo, anche le piccole realtà potrebbero godere dei vantaggi di cui gode Google, tanto per citarne uno (a caso), che ha sviluppato la tecnologia proprietaria BORG, ossia un substrato software capace di orchestrare le applicazioni, suddividendone l’esecuzione fra tutte le risorse disponibili nei data center globali dell’azienda.

Per capire meglio come funziona BORG e come funziona Mesosphere, basti pensare a tutti i servizi che Google mette a disposizione della propria utenza, come Google Search, Gmail, Google Maps, YouTube e via discorrendo. Mountain View ha organizzato tutte queste applicazioni in modo che condividessero i workload fra tutte le risorse di tutti i data center della società, evitando di assemblare dei cluster separati di server per ogni servizio. [Elementi fondamentali, i workload, nella progettazione del moderno ambiente IT, infatti un buon design dei workload serve per permettere alle applicazioni di essere eseguite con maggior efficienza].

Cosi come il segreto della scalabilità dei servizi di Google sembra risiedere in BORG, Mesosphere punta alla scalabilita’ dei Data Center e, lavora per offrire un sistema operativo per Data Center anche a chi non ha le opportunità di investimento al pari di Mountain View.

Il nome di questo sistema operativo e’ DCOS, ossia Data Center Operating System, il quale è capace di astrarre CPU, memoria, storage e altre risorse computazionali dai server fisici, per riunirli in una piattaforma di gestione unica e facilmente scalabile. Secondo Mesosphere, questo sistema operativo, attualmente in fase beta, permette agli amministratori IT di scalare i cluster data center aggiungendo fino a 50 mila server.

La base del DCOS è un insieme di strumenti open source di cui molti disponibili via Apache Licenses. Questi tools giacciono su un sistema kernel distribuito, che offre le API necessarie alla gestione e all’organizzazione delle applicazioni distribuite. Fra i componenti del nuovo sistema operativo per il cloud computing ci sono un init system distribuito (Marathon), un pianificatore di attività distribuito (Chronos) e un service discovery (DNS). L’architettura supporta già ed è compatibile con Apache Spark, Apache Cassandra, Kafka, Hadoop, YARN, HDFS e Google Kubernetes.

La flessibilità del nuovo sistema operativo di Mesosphere è comprovatadalla capacità di supportare tutte le versioni Linux più recenti delle distribuzioni CoreOS, CentOS, Ubuntu e Red Hat e, dalla possibilita’ di poter essere eseguito su bare metal o in un ambiente di private cloud virtualizzato su alcuni dei più importanti cloud provider come AWS, Google Compute Engine, Digital Ocean, Microsoft Azure, Rackspace e VMware vCloud Air e, dal supporto ad altri strumenti di gestione data center come OpenStack, Docker, Cloud Stack e VMware vCenter Orchestrator.

La crescita di Mesosphere è garantita da una serie di finanziamenti per startup, di cui l’ultimo ricevuto è pari a 10 milioni di dollari. Il nuovo finanziamento, permetterà quindi a Mesosphere di uscire dalla fase beta e proporre DCOS in due differenti versioni, una a pagamento offerta con supporto tecnico e servizio di consulenza e una gratuita per la community.

 

#MesosilnuvoSystemperDataCeter

Le novita’ di Debian 8

Debian 8 Jessie

Debian 8 Jessie

Il 25 aprile 2015 è stato annunciato il rilascio di Debian 8 (alias Jessie), che e’ l’ultima versione di uno dei più noti ed apprezzati sistemi operativi basati su Linux. Questo rilascio, atteso da moltissimi utenti e da altrettante aziende, porta con sè alcune novità significative, frutto di un lavoro di sviluppo durato circa due anni, e culminato in un sistema operativo che sarà supportato fino al 2020.

In questo articolo vedremo le principali novità introdotte su Debian 8, di cui è possibile effettuare il download direttamente dal sito ufficiale del progetto.

Una distribuzione universale
Debian, ad oggi vanta una vasta gamma di pacchetti software (circa 43 mila), che consentono a chiunque di personalizzarla a proprio piacimento, in base al tipo di applicazione per cui questo sistema sarà utilizzato: dai server alle workstation, passando per il cloud, i mainframe o le board che implentano l’Internet of Things.

L’idea della distribuzione universale, adatta a tanti contesti, ha spinto negli anni la comunità open source a creare un gran numero di derivate (ed il caso più noto risponde al nome di Ubuntu). Il fatto che molti sistemi Linux si basino su Debian aumenta quindi l’importanza di ogni aggiornamento apportato a questa distribuzione in ogni rilascio, dal momento che ciò si ripercuote su tutte le sue derivate (ufficiali e non).

Il passaggio a systemd
La novità più significativa, che ha creato molti dibattiti accesi, introdotta con Debian 8, riguarda il passaggio definitivo a systemd quale sistema di init principale, sebbene sia possibile utilizzare sysvinit come alternativa. Tale scelta trova le sue motivazioni nella riduzione dei tempi di avvio ed arresto del sistema, sebbene non tutti gli utenti sembrano convinti di ciò. Inoltre, systemd non si occupa solo della fase di boot: in quanto gestore di sistema, esso incorpora anche la gestione di diverse altre funzioni (alimentazione, dispositivi, login, eccetera), con conseguenze che potrebbero comportare, ad esempio, la necessità di riavviare il sistema in caso di aggiornamento. Un problema significativo per una distribuzione server, dovuto proprio a systemd. Il problema piu’ grande sorge per via del fatto che oggettivamente, l’attuale sistema usato, SysVInit, è oggettivamente un sistema antiquato, con un elenco di noti difetti, il principale dei quali è sicuramente la grande lentezza derivante dall’approccio seriale all’avvio dei servizi. L’idea di sostituirlo con un prodotto più moderno e meglio ingegnerizzato è, quindi, tutt’altro che sbagliata.

Il problema reale è che systemd sta andando ben oltre questo encomiabile tentativo, ma sta fagocitando al suo interno tutta una serie di servizi che con la gestione dei processi e la creazione dello ‘spazio utente’ poco hanno a che fare. Approccio, questo, che viola radicalmente le logiche della filosofia Unix, che sono alla base non solo dei Linux che usiamo oggi, ma in larga parte di quella che è l’informatica moderna.

Va detto, però, che il passaggio a systemd era già in atto da tempo, e non soltanto sulle distribuzioni basate su Debian: anche Red Hat, Fedora e SUSE (per citare alcune grandi distribuzioni Linux) sono già passate a questo nuovo gestore.

Desktop e applicazioni
Dal punto di vista dell’interfaccia utente, il grande grado di personalizzazione offerto da Debian si traduce nella possibilità di scegliere il proprio desktop environment preferito tra un gran numero di possibilità. L’ultimo rilascio è infatti compatibile con GNOME 3.14, KDE Plasma 4.11.13, Xfce 4.10, MATE 1.8 e Cinnamon 2.2.16.

Ai sopra citati desktop environment si aggiungono anche diverse applicazioni, tra cui Iceweasel 31.6, GIMP 2.8.14 e LibreOffice 4.3.3 per la sfera desktop, Apache 2.4.10, Tomcat 7.0.56 e 8.0.14, MariaDB 10.0.16 e MySQL 5.5.42 per quella server, nonchè OpenJDK 7u75, PHP 5.6.7 e Python 2.7.9 e 3.4.2 per gli sviluppatori.

Altre novità
Per concludere ricordiamo che Debian 8 è basato sul kernel Linux 3.16.7, che garantisce la compatibilità con le più recenti tecnologie disponibili. È altresì interessante notare che, con il nuovo rilascio, viene garantito il supporto a ben dieci architetture diverse, tra cui x86, PowerPC, MIPS, ARM e diverse altre.

 

#DebianottoJessie

Proteggere i Server da attacchi SlowHTTP/Slowloris

SlowHTTP difendersi da attacchi DDOS

SlowHTTP difendersi da attacchi DDOS

Gli attacchi del tipo SlowHTTP/Slowloris sono tra i più fastidiosi da ricevere in quanto il server di per sè non riporta nessuna anomalia se non un elevato numero di processi attivo, ma senza carico effettivo sulla macchina, questo perchè l’attacco apre quante più connessioni possibili al webserver e le lascia aperte inviando saltuariamente qualche header per mantenere aperta la connessione saturando di fatto il numero massimo di connessioni che il server può gestire e rendendolo irraggiungibile.

N.B.: con il termine attacco Slowloris s’intende un tipo di attacco chiamato Distributed Denial of Service (DDoS) che, in questo caso, sfrutta lo script Slowloris, scritto da Robert Hansen, grazie a cui vengono create una serie di connessioni web con lo scopo di inviare una enorme quantità di dati al server vittima in modo da renderlo inutilizzabile per gli utenti.

Un’ attacco con tale script permette tra l’altro ad una singola macchina attaccante di occupare le risorse di un server con un’ampiezza di banda minima e limitati effetti collaterali a servizi e porte non coinvolte.

Slowloris prova a mantenere le connessioni aperte ad un server web obiettivo e trattenerle aperte il più a lungo possibile. Fa questo, aprendo le connessioni al server web obiettivo e inviandogli richieste parziali. Periodicamente, invierà le successive intestazioni HTTP, aggiungendo ma mai completando la richiesta. I server attaccati terranno così le connessioni aperte, riempiendo il loro numero di connessioni disponibili, infine negando ulteriori tentativi di connessione dai client. Viene spesso usato anche per effettuare verifiche sulla stabilità di server, che forniscono servizi sotto stress.

Per proteggersi da questo tipo di attacchi si ricorre a degli escamotage, uno dei quali è limitare il numero di connessioni massime per IP in modo da evitare che questo possa intasare il server, per proteggere un server con directadmin, come pannello di gestione, e apache da questo tipo di attacchi basta semplicemente lanciare i seguenti comandi da root

cd /root
wget ftp://ftp.monshouwer.eu/pub/linux/mod_antiloris/installoris

chmod 755 installoris
./installoris

come segnalato sul sito di DirectAdmin

questi comandi non faranno altro che scaricare e installare il modulo mod_antiloris per apache (httpd), installarlo e riavviarlo.

 

#DifendersidaAttacchiSlowHTTP