Come abilitare la pagina di stato di PHP-FPM con NGINX

PHP-FPM dispone nativamente di una utilissima pagina di stato.

Tale pagina è accessibile via WEB (localmente o remotamente) e ofre anche la possibilità di monitorare lo stato di PHP-FPM remotamente tramite scripts.

Le informazioni sono aggiornate in tempo reale quando viene effettuate la richiesta HTTP.

Come abilitare la pagina di stato PHP-FPM

Il primo passo è di editare il file di configurazione. Per esempio su Centos, lo troviamo in questo percorso /etc/php-fpm.d/www.conf

Editiamo perciò il file utilizzando l’editor vi

vi /etc/php-fpm.d/www.conf

Dovete trovare una linea che setta la variabile pm.status_path (togliete il commento se la linea dovesse essere commentata)

Nel nostro caso abbiamo pm.status_path = /fpm-status

Il valore di default è /status, si può cambiare a piacere. Nel caso stiate facendo funzionare un pool PHP-FPM, conviene dare un prefisso legato al particolare pool che state configurando.

Passiamo ora ad editare il file di configurazione principale di Nginx.

Dobbiamo aggiungere una sezione “location” come la seguente (o simile, dipende dalla vostra configurazione)

location ~ ^/(status|ping)$ {
     access_log off;
     allow 127.0.0.1;
     allow 1.2.3.4#your-ip;
     deny all;
     include fastcgi_params;
     fastcgi_pass 127.0.0.1:9000;
}

Non dimenticate di modificare a dovere il vostro indirizzo IP. In ogno caso è bene tenere la pagina di stato privata, contiene informazioni anche sensibili che non è bene rendere pubbliche.

Fate ripartire i servizi nginx e php-fpm per caricare le nuove impostazioni. Tenendo come rierimento Centos possiamo per esempio utilizzare i seguenti comandi

service php-fpm restart; service nginx restart

oppure

systemctl restart php-fpm; systemctl restart nginx

Come vedere la pagina di stato

prite tramite un browser (anche in modalità testo, utilizzando “links”) la pagina http://127.0.0.1/fpm-status (in locale) o http://1.2.3.4/fpm-status (remoto, sostituendo il vostro IP pubblico corretto)

Potranno essere viste molte informazioni interessanti:

pool:                 www
process manager:      dynamic
start time:           17/May/2016:13:54:02 +0530
start since:          886617
accepted conn:        1619617
listen queue:         0
max listen queue:     0
listen queue len:     0
idle processes:       28
active processes:     2
total processes:      30
max active processes: 31
max children reached: 0
slow requests:        0

Il significato dei vari valori delle variabili:

    pool – il nome del pool
    process manager – i valori possibili sono static, dynamic o ondemand. Non utilizziamo static. Provate ad uilizzare ondemand, ma consigliamo dynamic
    start time – la data e l’ora dell’ultima partenza o riavvio
    start since – numero di secondi trascorsi dalla partenza
    accepted conn – il numero di richieste accettate dal pool
    listen queue – il numero di richieste in coda di attesa. Se questo numero non è zero, provate ad aumentare il numero di processi spawnati nel pool.
    max listen queue – il numero massimo di richieste in coda da quando il servizio sta funzionando
    listen queue len – la lunghezza della coda di attesa
    idle processes – il numero di processi a riposo
    active processes – il numero di processi attivi
    total processes – il numero totale di processi (attivi + a riposo)
    max active processes – il numero massimo di processi da quando il processo è partito
    max children reached – il numero di volte in cui si è raggiunto il numero massimo di processi possibili. Se il valore è diverso da zero, alzare tal limite massimo
    slow requests – il numero di richieste “lente”. Attivare il log richieste “slow” prima di considerare questo valore. Di solito i processi che fanno query SQL tendono ad essere più lenti.

Si possono anche vedere delle informazioni più dettagliate, utilizzando un URL con un paramento finale, ad esempio http://127.0.0.1/status?full

Possiamo anche anche vederlo in formati diversi, json, xml, html

http://127.0.0.1/status?json , http://127.0.0.1/status?xml , http://127.0.0.1/status?html

e naturalmente combinando le due http://127.0.0.1/status?json&full

Stonebit – sviluppo software – consulenze informatiche – assistenza sistemistica Linux

Il kernel di linux 3.18.26 chiude la falla CVE-2016-0728

Rilasciata la patch che chiude la vulnerabilità CVE2016-0728

La vulnerabilità che interessava tutte le versioni del kernel 3.8 e superiori è stata chiusa da Yevgeny Pats (1) con il seguente commento “KEYS: Fix keyring ref leak in join_session_keyring()”

Per leggere tutto il changelog del nuovo rilascio del kernel 3.18.26  (LTS) , potete leggere qui http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.18.26-vivid/CHANGES

Stonebit – software house verona – consulenze informatiche e sicurezza di rete

Debian vuole permettere versioni di PHP diverse co-esistenti sullo stesso server

Una interessante proposta arriva da Debian per la pacchettizzazione di PHP

Per impostazione predefinita, è sempre stato “doloroso” ottenere più versioni di PHP (5.3, 5.4, 5.5, 5.6, ecc) in esecuzione sullo stesso singolo server. Il progetto Debian è al lavoro per risolvere tale problema al fine di consentire più versioni di PHP per essere installate side-by-side, semplicemente. Può essere che questa auspicabile soluzione possa poi venire adottata anche da altre grandi distribuzioni.

Gli autori di Debian annunciano dei cambiamenti che abbiamo fatto in pkg-php per il pacchetto di installazione di PHP.

Se siete interessati a ulteriori discussioni vi raccomandiamo di seguire la discussione sulel mailing-list pkg-php-maint, pkg-php-pecl and/or pkg-php-pear alioth,

dove le discussioni scenderanno ad un livello più ecnico.

Per leggere di più : https://lists.debian.org/debian-devel-announce/2016/01/msg00002.html

Stonebit – software house verona – consulenze informatiche e sicurezza di rete

Serio bug del kernel di linux in attesa di patch

Una patch per un bug critico presente nel kernel di Linux dal 2012 è stato rilasciato

La vulnerabilità interessa le versioni del kernel 3.8 e superiori, hanno detto i ricercatori di Perception Point che hanno scoperto la vulnerabilità. Il difetto si estende anche a due terzi dei dispositivi Android, l’azienda ha aggiunto.

“E ‘piuttosto grave, perché un utente con privilegi legittimi o inferiori può ottenere l’accesso root e compromettere l’intera macchina,” ammette Evgenij Pats, cofondatore e CEO di Perception Point. “Senza aggiornamento automatico per il kernel, queste versioni potrebbero essere vulnerabili per un lungo periodo di tempo. Ogni server Linux necessita di una patch non appena la patch è rilasciata

Pats afferma che un utente malintenzionato dovrebbe avere l’accesso locale per sfruttare la vulnerabilità su un server Linux. Sui dispositivi mobili Android è piu semplice, basta distribuire un app mobile con il codice dannoso per sfruttare la vulnerabilità su un dispositivo Android (Kit-Kat e superiori). Pats ha aggiunto che lo sfruttamento della falla è abbastanza semplice, ma non si sa se è stata utilizzata ad oggi.

La correzione è semplice“, ha detto Pats. “Il problema non è di tutti i dispositivi Linux ottenere patch automaticamente.”

La vulnerabilità, CVE2016-0728, è insita nella strutturaportachiavi” costruita sulle varie versioni di Linux. Il portachiavi cripta e memorizza le informazioni, le chiavi di crittografia e certificati login, e li rende disponibili per le applicazioni. In un rapporto pubblicato da Perception Point, ricercatori hanno detto la vulnerabilità è una perdita di “referenza / indirizzamento” che può essere abusata per eseguire codice nel kernel di Linux.

Per leggere di più : https://threatpost.com/serious-linux-kernel-vulnerability-patched/115923/#sthash.u64TN4eI.dpuf

Stonebit – software house verona – consulenze informatiche e sicurezza di rete

Intrusion detection semplice semplice con Psad su Centos 7

Intrusion Detection e Log Analisys su Centos 7 con Psad

Psad è una collezione di tre leggeri demoni di sistema (due demoni principali e un demone helper) che girano su macchine Linux che analizza i messaggi di log di iptables per rilevare scansioni delle porte e altro traffico sospetto. Una tipico impiego è quello di eseguire Psad sul nodo dove c’è l’accesso più veloce possibile ai log di Ipables. Ovviamente è anche molto conveniente metterlo in esecuzione sui server esposti sulla rete pubblica per monitorare le possibili minacce provenienti da provetti hacker o hacker conclamati.

Purtroppo Centos 7 non mette a disposiszione un pacchetto direttamente installabile con YUM, ma vale la pena perdere qualche minuto in più perche Psad è veramente molto utile (consiglio di affiancarlo anche a Fail2ban)

Qui di seguito vi elenco alcuni semplici comandi da dare dalla console di terminale come root per poterlo installare. Psad ha bisogno di alcuni pre-requisiti, cioà di alcuni pacchettu da cui dipende.

Installiamoli per primi

yum install perl-IPTables-ChainMgr perl-Date-Calc perl-Unix-Syslog whois mailx

yum install cpan

Tramite cpan installiamo altre due dipendenze di perl (le opzioni di default dovrebbero andare bene)
cpan IPTables::Parse
cpan IPTables::ChainMgr

Veniamo finalmente all’installazione vera e proprio di Psad (l’ultima versione al momento è la 2.4.2)

rpm -Uvh http://www.cipherdyne.org/psad/download/psad-2.4.2-1.x86_64.rpm

Se l’installazione è avvenuta correttamente procediamo con il primo semplice settaggio,

cambiare l’email del destinatario a cui mandare le notifiche.

E’ possibile farlo modificando il parametro EMAIL_ADDRESSES in psad.conf

Quindi

vi /etc/psad/psad.conf

Alla fine possiamo lanciare il programma come daemon con

service psad start

e attivarlo in partenza automatica del sistema con

chkconfig psad on

Ora potrete ricevere notifiche circa le attività sospette di cui il vostro server è bersaglio.

Stonebit – software house verona – consulenze informatiche e sicurezza di rete