Categoria: Sistemistica

Come implementare e configurare correttamente le DNSBL (o RBL) sul nostro server di posta onde evitare falsi positivi.

spam_dnsbl_rmiozioneUno dei problemi maggiori da sempre riguardo il servizio email è lo SPAM.

Negli svariati anni sono state ideate diverse soluzioni (più o meno efficaci) per arginare il problema, tutte con i relativi pro e i relativi contro.
Ciò che si cerca di raggiungere è l’identificazione ed eliminazione dello SPAM totale, avendo cura di non eliminare nemmeno una mail legittima (o considerata tale).

Ovviamente bilanciare l’obiettivo risulta estremamente complesso, nell’ottica che cestinare una mail legittima, sia ben più grave che lasciar passare 2 email di SPAM.

Per questo, è bene tenere sempre a mente che non si possono scegliere soluzioni drastiche, ma sopratutto che la sicurezza è un processo e non un prodotto.

Ovvero, non ci si può affidare solamente di un software specifico, ma bisogna coordinare diverse tecnologie che lavorino in sinergia tra loro.

Noi ad esempio nel nostro stack antispam utilizziamo :

  • Postgrey
  • SPF
  • Amavisd
  • Clamd
  • Spamassassin
  • RBL (configurate su Spamassassin)
  • Pyzor

e possiamo vantarci di avere un ottimo rapporto SPAM ricevuto / fasi positivi, laddove i falsi positivi sono praticamente nulli, e lo SPAM ridotto al minimo (nella caselle info@dreamsnet.it ieri ne ho ricevute 3).

Da anni che lavoro nel settore, come sistemista e amministratore di server mail, posso fermamente affermare che un mailserver che non riceve nemmeno una mail di SPAM saltuariamente è un mailserver che filtra troppo (anche quello che non dovrebbe filtrare).

Una delle configurazioni più classiche (ed errate) che ho trovato implementate in diversi server mail (anche di importanti società di hosting e internet service provider) è quella di implementare RBL a livello assoluto direttamente sul mail server.

Cos’è RBL ?

Una DNS-based Blackhole List (anche DNSBL, Real-time Blackhole List o RBL) è un mezzo attraverso il quale è possibile pubblicare una lista di indirizzi IP, in un apposito formato facilmente “interrogabile” tramite la rete Internet. Come suggerisce il nome, il meccanismo di funzionamento è basato sul DNS (Domain Name System).
Le DNSBL sono principalmente utilizzate per la pubblicazione di indirizzi IP legati in qualche modo a spammer. La maggior parte dei mail server possono essere configurati per rifiutare o contrassegnare messaggi inviati da host presenti in una o più liste.
Questi servizi offerti gratuitamente agli utenti e sistemisti di tutto il mondo, permettono realmente di decimare l’invio di SPAM, nonchè la ricezione, contribuendo a una funzione realmente utile all’utente finale.

spamhaus_dnsbl_basic

 

Brevemente funziona così :

  1. Il mail server del mittente ci invia una mail.
  2. Il mailserver del destinatario (il nostro) farà una richiesta di tipo DNS a una delle liste DNSBL che abbiamo implementato.
  3. La lista DNSBL ci risponderà che è in blacklist o che non lo è.
  4. Se lo è rifiutamo di accettare il messaggio segnalando con un errore e informando il nostro mittente che è presente in una lista antispam.
  5. Se non è in SPAM accettiamo il messaggio.

 

Fino a qui tutto bene, sembra una meraviglia. Si potrebbe tranquillamente dire che si può eliminare lo SPAM alla frontiera, senza accettare il messaggio e dunque risparmiando preziose risorse sul mailserver.

Una meraviglia in effetti se non fosse che bisogna mettere in discussione la precisione della tecnologia RBL, e del suo insindacabile giudizio.

Come avrebbe detto un famoso conduttore televisivo : “La domanda nasce spontanea !”, ovvero :

Essere segnalati in una lista RBL significa che siamo veramente degli SPAMMER ?

La risposta è NO.

Vediamo ad esempio alcuni scenari per cui noi legittimi mittenti e non spammer ci vediamo ritrovati in una blacklist, e il nostro fidato e amico destinatario vedrà rifiutarsi la consegna del messaggio a causa della configurazione errata del suo mail server.

  1. Sono col dominio dominiotizio.it e sullo stesso mailserver (con lo stesso IP) ci sono ospitati altri 500 domini per un totale di 2500 caselle email gestite.
    Una casella email viene violata, e nel giro di un ora uno spammer riesce a consegnare 10000 email a indirizzi email random sui classici yahoo.com.
    L’amministratore se ne accorge, limita il danno disabilitando l’account … ma nel frattempo viene inserito in dnsbl.sorbs.net (una nota ed usatissima RBL).
    Da li in poi per diverse ore (anche giorni), l’IP del mail server risulterà come SPAMMER.
  2. Gli stessi presupposti dello scenario 1, con la differenza che siamo finiti in altre liste (questa volta a pagamento). Come riportato qui https://www.dreamsnet.it/2013/06/mailserver-blacklist-dnsbl-e-spam-uscire-dalle-liste-e-vivere-serenamente/ a volte per rimuoversi da liste RBL in tempi accettabili (poche ore), alcune liste pretendono un pagamento variabile tra 40 e 100 dollari per effettuare la rimozione dell’indirizzo “nell’immediato”.Nessun amministratore di server mail accetterà mai di cedere a tale spesa (o meglio ricatto), per cui è possibile che invece di essere in liste DNSBL per qualche ora o giorno, possiate rimanerci per 7 giorni fino alla rimozione automatica.
  3. Siamo sempre listati nelle liste di SPAM. Basti pensare e molti provider italiani, Libero.it su tutti, ma anche i vari Telecom e Fastweb che col loro alto numero di utenti e di mail server sono spessissimo (Libero lo è quasi sempre) listato in una o pià liste RBL.

 

In tutti e 3 i casi ci troviamo di fronte a situazioni in cui sebbene la mail venga inviata da un mailserver possa essere in liste antispam perchè precedentemente (o anche attualmente) usato da spammer, il contenuto della mail e la mail stessa risulta legittima e gradita, dunque non SPAM.

Arrivare a conclusioni del tipo “sei in una lista antispam per cui sei uno spammer, allora non accetto la mail” non ha senso in un contesto reale dove la mail diventa uno strumento di lavoro e la non ricezione può comportare gravissimi problemi.

Tornando all’introduzione precedente, oggi molti amministratori di sistema implementano i filtri direttamente sul mailserver in questo modo (esempio su mailserver postfix) :

reject_rbl_client zen.spamhaus.org,
reject_rbl_client list.dsbl.org,
reject_rbl_client sbl.spamhaus.org,
reject_rbl_client bl.spamcop.net,
permit

 

Ciò significa che il nostro mailserver rifiuterà di accettare il messaggio se l’IP del mailserver del mittente è listato in una delle 4 liste elencate. E sia ben chiaro, che per essere rifiutato basterà che sia presente in ALMENO UNA DELLE 4.

Approccio completamente assurdo e sbagliato. Nel caso in cui le liste fossero ipoteticamente 20 (teoricamente possibile, in pratica ne vengono configurate 3 o 4 normalmente), essere presente in 1 sola su 20 dovrebbe essere sinonimo di “essere in regola”, in questo caso invece 1 su 20, o su 100 significa essere SPAMMER.

Ciò è errato. Profondamente errato.

Il sistema RBL deve essere uno strumento in più, non l’unico atto a discriminare la bontà o meno di una mail. Deve indicare, ma non provare. Deve essere testimone e non giudice. Deve fornire prove, ma non emettere sentenze.

Ecco perchè un uso sensato delle RBL è quello di toglierlo immediatamente dai file di configurazione di postfix (o del vostro mailserver) e di utilizzarlo insieme ad un filtro bayesano come Spamassassin e poi eventualmente eliminato da Amavis.

Un filtro bayesiano (dal nome del noto matematico Bayes vissuto nel XVIII secolo) è una forma di filtraggio dello spam che si basa sull’analisi del contenuto delle email. Questa tecnica è complementare (e di grande efficacia) ai sistemi di blocco basati su indirizzo IP, le cosiddette blacklist.
Il filtro bayesiano applica all’analisi delle email un teorema, espresso per l’appunto da Bayes, secondo il quale ogni evento cui è attribuita una probabilità è valutabile in base all’analisi degli eventi già verificatisi. Nel caso dell’analisi antispam, se in un numero n delle mail analizzate in precedenza l’utente ha marcato come spam quelle che contenevano la parola “sesso”, il filtro ne dedurrà che la presenza di quella parola innalza la probabilità che le mail seguenti contenenti quella parola siano a loro volta spam.
In questo modo, il sistema è in grado di adattarsi in maniera dinamica e veloce alle nuove tipologie di spam.

Brevemente ora funzionerebbe così :

  1. Mi mandano una mail
  2. La accetto
  3. Faccio il controllo sull’IP del mittente. Se presente nella prima lista aggiungo 1 al punteggio
  4. Faccio il controllo sull’IP del mittente. Se presente nella seconda lista aggiungo 1 al punteggio
  5. Faccio il controllo sull’IP del mittente. Se presente nella terza lista aggiungo 1 al punteggio
  6. Faccio il controllo sull’IP del mittente. Se presente nella quarta lista aggiungo 1 al punteggio
  7. Faccio gli altri controlli Bayesani sull’oggetto, sul contenuto … e per ogni violazione aggiungo un punteggio specifico.Se alla fine di tutti i controlli di SPAMASSASSIN il punteggio finale della Email è 5, significa che questa mail è SPAM, altrimenti è legittima e la consegno.

 

Facile capire che una mail legittima, pur essendo in ben 4 liste antispam (a livello di IP) verrà comunque consegnata, come è altrettanto facile capire che una mail che non è presente in nessuna blacklist ma viola innumerevoli regole a livello di contenuto, viene comunque non marcata come SPAM e dunque consegnata.

Abilitare RBL su SpamAssassin è questione di 1 minuto, basta infatti editare il file /etc/mail/spamassassin/local.cf e aggiungere :

skip_rbl_checks 1
rbl_timeout 3
score RCVD_IN_SORBS_DUL 1
score RCVD_IN_SORBS_WEB 1
score RCVD_IN_SORBS_SMTP 1
score RCVD_IN_SORBS_HTTP 1
score RCVD_IN_XBL 1

ed avere cura poi di settare il punteggio di “taglio” di amavisd a 5 … o 6 (per essere meno ferrei e un po’ più elastici).

Symlink attack su Webserver apache. Dallattacco alla difesa. Un esempio pratico e la configurazione corretta.

Attacco-Informatico-ImcUn attacco di tipo symlink (collegamento simbolico n.d.t.) non è qualcosa di sicuramente nuovo in ambito unix-like. Curioso è invece vedere come online ed anche ultimamente ci siano sempre più forum dedicati che parlino di come arginare questa piaga : la gioia di tutti gli attacker odierni.

Se prendiamo questa due pagine ad esempio http://whmscripts.net/misc/2013/apache-symlink-security-issue-fixpatch/ , http://www.linuxkatta.com/cPanelFix/solutions-for-handling-symlink-attacks/ , vediamo come sia attualissimo il problema e che addirittura si millantano patch da parte di due colossi operanti nel settore hosting come Rack911 e cPanel.

Ciò ha del ridicolo, ed è praticamente assurdo in quanto già di default Apache prevede un elegante modo per risolvere il problema , ovvero disabilitare l’opzione FollowSymLinks e sostituirla con SymLinksIfOwnerMatch

La prima opzione permette di disabilitare completamente Apache dall’attraversare link simbolici, la seconda permette di sostituire la prima in maniera intelligente, ovvero “se e solo se” il proprietario del file target a cui punterà il link simbolico sia lo stesso del link.

Ciò permetterà di continuare ad usare quelle feature di Apache come l’url rewriting, (tramite mod_rewrite).

In questo modo e con una corretta separazione dei privilegi a livello di virtualhosting utilizzando Apache in modalità FastCGI o tramite PHP-FPM come abbiamo accennato in QUESTO PRECEDENTE ARTICOLO, si riuscirà a confinare forzatamente l’attaccante all’interno della propria home, ed evitare che scorrazzi indisturbato nel server o nelle home degli altri utenti.

Una delle preoccupazioni da adottare al momento di configurare Apache è anche quella di evitare che l’attaccante con un file .htaccess ad-hoc da lui caricato possa riabilitare l’opzione FollowSymLinks e che possa vanificare in pochi secondi i nostri sforzi.

Nel video alla fine di questo breve articolo troverete la dimostrazione pratica dell’attacco senza censura alcuna e una guida passo passo alla risoluzione del problema mostrandovi la configurazione corretta di alcuni file apache per un vhost che abbiamo usato per il nostro esperimento.

Buon proseguimento.

To all english readers :

Simply you can correctly configure Apache to limit this type of attack.

The steps you take are 3:

  1. Eliminate the option FollowSimLinks
  2. Add the option SymLinksIfOwnerMatch
  3. Remove the possibility of reactivating FollowSimLinks through a htaccess file.

Edit the configuration file for the vhost and set the following configuration:

Options-Indexes-FollowSymLinks + ExecCGI + SymLinksIfOwnerMatch
AllowOverride All Options = ExecCGI, SymLinksIfOwnerMatch, Indexes

In this way, no attacker will be able to do this kind of attack.

Problemi nell’inviare e ricevere mail. Guida di riferimento alla diagnosi e alla risoluzione.

quante-email-inviate-al-minutoVa premesso che l’invio di una mail e la sua ricezione comporta una serie di operazioni “dietro le quinte” assolutamente non banali che determinano in modo indiscutibile l’esito positivo o meno dell’invio e della ricezione.

Sebbene l’invio di una mail sia alla portata di tutti è anche vero che esistono migliaia di mailserver ognuno col proprio software e ognuno con la propria configurazione che a volte possono non comunicare tra loro per problemi di natura tecnica e di mal configurazione.

Cerchiamo dunque di ipotizzare uno scenario.

Quando un utente con email tizio@tizio.it ad esempio prova ad inviare una mail a caio@caio.it, ecco cosa succede dietro le quinte :

  1. Il client di posta di tizio si connette al mailserver delegato a gestire la posta per il dominio tizio.it ad esempio mail.tizio.it
  2. A sua volta viene fatta una richiesta al mailserver autoritario che è in ascolto sulla porta 25 e chiesto di inviare una mail al destinatario caio@caio.it. Questa richiesta viene fatta seguendo una sintassi per il protocollo SMTP in cui brevemente vengono descritti, mittente (MAIL FROM), destinatario (RCPT TO), oggetto (SUBJECT) e il corpo della mail (DATA).
  3. Una volta terminata la trasmissione della mail dal client di posta al mailserver, il mailserver (che altro non è che un programma server che rimane in ascolto sulla porta 25, adibito alla ricezione e alla consegna delle mail) fa una query al DNS cercando di ottenere il record MX (Mail eXchanger) per il dominio in oggetto.
  4. Il DNS per il dominio caio.it risponderà ad esempio che il mail server autoritativo per il dominio caio.it sarà mail.caio.it
  5. Il mailserver mail.tizio.it allora si collegherà alla porta 25 del mailserver mail.caio.it instaurando una connessione di tipo TCP e girerà la mail che aveva in coda (queue) speditagli dal client di posta (outlook o thunderbird ad esempio) dell’utente tizio@tizio.it
  6. A questo punto il mailserver del destinatario mail.caio.it avrà in coda la mail destinata ad un utente del suo dominio (caio@caio.it) e dovrà in qualche modo consegnarla in un file dentro una cartella del server, in formato normalmente Maildir o Mailbox.
  7. A quel punto il ricevente si collegherà tramite il suo client di posta ad un server di posta in entrata pop3 o imap che serve alla ricezione del messaggio precedentemente consegnato dal mailserver.

Questo è quello che avviene in un regime normale, ovvero senza controlli specifici antivirus e antispam.

Già fino ad ora per far funzionare tutto questo meccanismo si ha bisogno dei seguenti requisiti :

  1. 2 mailserver pienamente funzionanti , uno per il mittente uno per il destinatario
  2. Le informazioni host ed IP sui mailserver siano pubblicati nelle voci DNS (dette zone) dei domini in questione.
  3. Effettuare una query DNS implica cialis prices il fatto di avere un server DNS funzionante con le corrette informazioni pubblicate, in particolar modo il record MX

In una configurazione avanzata, si ha a che fare inoltre con controlli aggiuntivi, come ad esempio :

Greylisting : si rifiuta di accettare la mail del mittente per alcuni minuti. Nel caso di un mailserver reale e non spammer, sarà rinviata. Nel caso di spam bot spesso non viene rinviata per cui si inizia a fare una selezione di posta buona e posta cattiva. Ciò comporta un ritardo di circa 10, 15 minuti (ma anche più) del primo messaggio di un nuovo mittente per il nuovo mese.

DNSBL : si verifica se un IP del mittente risulti pubblicato in liste mondiali di Spammer tramite richieste di tipo UDP (simili a quelle usate per le query DNS). Se presente, il messaggio viene rifiutato e il mailserver mittente lo rispedirà al mittente, specificando il motivo del rifiuto di consegna.

Antispam/Antivirus : in base al contenuto, parole chiave ed allegati, si darà un punteggio al messaggio. Superato un certo punteggio (normalmente 5) il messaggio sarà etichettato come SPAM e sarà consegnato o nella cartella SPAM o nella posta normale con l’oggetto del messaggio modificato in qualcosa del tipo [SPAM]Oggetto del messaggio , oppure ***SPAM***Oggetto del messaggio.

In questo caso affinchè il messaggio sia ricevuto dall’indirizzo del destintario il mittente deve accertarsi che l’ip del suo mailserver non sia elencato come fonte di SPAM nelle DNSBL, deve avere l’accortezza di seguire delle regole standard per la scrittura di una mail come ad esempio scrivere l’oggetto, inserire un testo nel corpo del messaggio, evitare l’invio di file quasi sempre vietati come gli eseguibili (.exe, .com, .pif, .bat, ecc..).

Va inoltre messo nero su bianco un concetto : quando la mail non arriva o non si riceve la colpa può essere nostra come può essere dell’interlocutore.

Se un nostro fornitore o cliente, ci invia una mail da un indirizzo elencato in DNSBL, la colpa è sua che non invia rispettando le regole, e non nostra che rifiutiamo automaticamente il messaggio perchè appunto è SPAM.

Inoltre va detto che la mail non è uno strumento di comunicazione in tempo reale, la consegna non è garantita e che ogni uso diverso da quella per cui è stata progettata è un uso errato.

Ogni messaggio di errore che ritorna indietro ha un codice di identificazione, nonchè a breve una descrizione del problema.

Leggendo queste informazioni, possiamo sapere senza ombra di dubbio, se il problema siamo noi o l’altro interlocutore.

Basterebbe avere la voglia e prendersi la briga di leggere questi errori per evitare di brancolare nel buio evitando inopportune comunicazioni all’helpdesk aziendale.

Ottimizzare un server LAMP. mod_php vs suphp vs fcgid fastcgi vs php-fpm. La modalità ottimale per un ambiente in virtual hosting

ilovephpProgettare bene un web server, significa anche effettuare una scelta opportuna su come far girare l’interprete PHP.

Se è vero che Apache di default fornisca il classico mod_php che va bene tecnicamente per tutte le configurazioni senza (apparentemente) troppi problemi, è anche vero che guardando nel dettaglio tutte le varie possibili soluzioni, con un pizzico di tempo potremmo effettuare una configurazione ottimale sopratutto per quei server WEB che si ritrovano a far girare più siti web in modalità virtual hosting (più siti su un solo server).

A differenza di un web hosting dedicato (un server web su cui gira uno o più siti dello stesso cliente) lavorare in ambiente condiviso implica ragionare tenendo conto di concetti importantissimi per la sicurezza e le prestazioni : la separazione dei privilegi e il modo in cui viene implementata questa caratteristica.

Va premesso che questo articolo non affronterà la parte tecnica dell’installazione e configurazione di ogni possibile modalità (per quello ci sono innumerevoli tutorial in rete), ma vuole essere una panoramica introduttiva che aiuti il lettore a fare una scelta oculata tra soluzioni apparantemente equivalenti ma profondamente diverse.

Al fine di gestire un sito PHP, il server deve interpretare il codice PHP e generare una pagina quando i visitatori accedono al sito.
Si interpreta il codice in base a quale libreria PHP si sta utilizzando, ad esempio PHP 4 o PHP 5.
Un handler PHP (o gestore) è colui che effettivamente carica le librerie in modo che possano essere utilizzate per l’interpretazione.
I gestori di PHP determinano come PHP viene caricato sul server.

E’ fondamentale per le prestazioni del server, selezionare il gestore che si adatta meglio alla propria situazione.
Selezionando il gestore giusto è importante tanto quanto la versione di PHP stesso.
Un gestore non è necessariamente sempre migliore di un altro, ma dipende dalla configurazione e dalle esigenze.

Di quale caching avete bisogno ? Di quali moduli avete bisogno ? ecc …

mod_php (DSO)

DSO è anche conosciuto come mod_php. DSO significa: Dynamic Shared Object. Questa è una configurazione o, ma è generalmente considerato il gestore più veloce.
Gestisce PHP come modulo di Apache. Ciò significa che gli script PHP verranno eseguiti come utente Apache, che è l’utente: ‘apache o httpd o www-data o nobody’.

Riguardo mod_php si dovrebbe dire ben poco. Esso è infatti installato di default in tutte le distribuzioni Linux al momento che si installi un Webserver APACHE con PHP.
Va sottolineato Apache e non webserver alternativi come lighthttpd o NGINX, perchè mod_php non funzionano con questi altri.
E’ la soluzione classica, la più utilizzata dagli utenti pigri, ma sicuramente non la più ottimale. Nemmeno la più sicura.

mod_php infatti non dispone di caratteristiche di progettazione atte a garantire una separazione privilegi adeguata. Anzi, non la offre proprio.
Esso infatti si limita ad eseguire gli script PHP con gli stessi permessi del webserver che lo invoca, normalmente httpd, www-data, apache o nobody.

Ciò significa che per gestire vhosts multipli si dovranno impostare i permessi dei singoli vhosts con permessi non separati tra loro, dando la possibilità al webserver di leggere e scrivere file e cartelle con i permessi del webserver stesso.

DSO ha due inconvenienti. In primo luogo, tutti i file creati da uno script PHP avrà la proprietà dell’utente con cui gira Apache.
Essi non saranno leggibili dal webserver altrimenti. Siti web che hanno bisogno di caricare i file tramite PHP avranno problemi di autorizzazione di file a patto di non modificare i permessi in configurazioni fin troppo permissive.

Il secondo svantaggio è un problema di sicurezza. I file creati avranno la proprietà del webserver. Se un hacker trova un exploit nello script PHP, potrebbe realizzare un file con gli stessi privilegi file di sistema importanti che sono anche di proprietà del webserver. Questo darà loro la possibilità di modificare i file  al di fuori di tale account utente.

Per ovviare a queste mancanze sono state implementate feature empiriche e obsolete come safe_mode() e l’open_basedir(), puri palliativi per tentar di arginare un male che va risolto alla radice.

Risolvere alla radice il male significa usare configurazioni che supportano la separazione dei privilegi.
Tra queste troviamo suPHP, FCGId (tecnicamente l’evoluzione di FastCGI) e PHP-FPM.

suPHP

suPHP è stato il primo abbozzo per tentare una reale separazione privilegi utenti.

SuPHP altro non è che un modulo per Apache che ci dà la possibilità di presentarci al sistema come un utente differente dal default (www-data, httpd o apache).
Esso funziona solo su Apache e come il precedente mod_php è inutilizzabile su altri webserver.

Tra i suoi vantaggi :

  • Ogni vhost esegue PHP con il proprio user/group
  • I file PHP possono avere permessi 640 (rw-r—–). Ciò è perfetto per i file di configurazione con password e dati sensibili
  • I file e le cartelle create da PHP sono scritte con user/group del proprio vhost.
  • Può essere usato un file php.ini per ogni vhost (configurazioni personalizzate, impostazioni di sicurezza e performance su misura)

L’obiettivo lo raggiunge bene se non fosse a scapito delle prestazioni davvero ridotte.

Esso infatti è circa il 30 – 40% più lento e meno performante del classico mod_php.

Questo succede per le tempistiche bibliche dello spawning di un nuovo processo per ogni richiesta e l’effettuazione di una fork() che rende il tutto davvero ingestibile e inaccettabile sopratutto su siti ad alto traffico o su server che ospitano centinaia o migliaia di siti in virtual hosting.

fcgiD e FastCGI

fcgid invece è una soluzione derivata dal più obsoleto e non mantenuto fastcgi da cui prende comunque l’assonanza nel nome.

FastCGI (aka: mod_fcgid o fcgi) è una variante del CGI (Common Gateway Interface) ad alte prestazioni.

Ha la sicurezza e proprietà nonchè vantaggi di suPHP riguardo alla separazione dei privilegi degli utenti.
Inoltre può essere utilizzato a differenza di mod_php e suPHP anche su webserver diversi da Apache.

La differenza principale con suPHP è che con FastCGI si può risparmiare notevolmente sulle prestazioni della CPU e dare velocità prossime a quella della DSO (mod_php).
Può essere utilizzato anche con un opcode cacher come eAccelerator o APC, che può ulteriormente aiutare velocità il caricamento delle pagine, ma a causa della separazione privilegi dei processi non potrà accedere alla memoria condivisa di cacher come APC, xCACHE, eAccelerator.

Ciò si traduce in un elevato utilizzo della memoria. Questo anche perché invece di creare il processo di PHP ogni volta che viene chiamato, come suPHP, mantiene una sessione persistente aperta in background.

Se vi piace la sicurezza offerta da suPHP e volete avere performance simili a quelle di DSO (ovvero molto veloci) questa è una soluzione da tenere in considerazione sopratutto su versioni di php inferiori alla 5.3

PHP-FPM

A partire da php 5.3 infatti è stata implementata e messo in produzione il gestore PHP-FPM acronimo di FastCGI Process Manager.

PHP-FPM è una implementazionealternativa di PHP FastCGI con alcune funzioni utili per i siti di qualsiasi dimensione e specialmente per i siti e webserver particolarmente carichi.

PHP-FPM è destinato principalmente ai siti web gravati da numerose richieste HTTP. E’ possibile lanciare più pool di processi FastCGI in ascolto su porte separate per soddisfare le esigenze di ambienti virtuali multi-dominio in virtual hosting.

Offre inoltre:

  • Processo di gestione avanzato con possibilità di fare uno stop/start controllato.
  • La possibilità di avviare lavoratori con differenti uid/gid/chroot/ambienti e impostazioni di php.ini diverse (sostituisce safe_mode)
  • Registrazione di stdout e stderr .
  • Riavvio di emergenza in caso di distruzione accidentale della opcode cache
  • Supporto per l’upload accelerato.
  • Supporto per lo “slowlog” che registra le pagine che richiedono troppo tempo per essere completate

È possibile utilizzare PHP-FPM come back-end a qualsiasi server web e non essere più legati ad Apache.
Un altro vantaggio (che ha anche mod_php), è quello di gestire la memoria condivisa e dunque gestire in modo trasparente e indolore sistemi di caching PHP come APC, eAccelerator, xCACHE.

Riassumendo in breve:

  Sicurezza Prestazioni Integrazione Caching  Adatto Virtual Hosting Non Apache
mod_php Bassissima Altissime Si. Molto facile e indolore No. Sconsigliatissimo No
suPHP Altissima Bassissime No. Si. Non consigliato No
FastCGI Altissima Alte Si. Complessa, pochi vantaggi Si. Consigliato Si. 
PHP-FPM Altissima Molto Alte Si. Molto facile e indolore Si. Consigliatissimo Si. 

Le informazioni fino ad ora elencate sono più che sufficienti per mettervi in condizione di fare una scelta intelligente. Scelta che in un webserver adibito al virtual hosting nel mio caso si traduce senza esito a PHP-FPM.

Solo in situazioni in cui si ospita un solo dominio in un server VPS ad esempio, posso permettermi il lusso di usare ciò che offre la casa (mod_php) senza troppi problemi riguardo la sicurezza dato che quel sito rimane comunque l’unico sito che gira sul server.

Hosting. Prodotto o servizio ? Quattro conti insieme all’hoster per un acquisto sereno.

risparmiare_hosting_webAcquistare un piano hosting è diventata un’operazione comune. Facile ed immediata, nonchè alla portata di tutti.

Ma come orientarsi tra i tanti fornitori e le varie offerte ?

Prima di addentrarci nella risposta è bene fare una piccola introduzione.

Va precisato infatti che l’attivita di hosting provider non è filantropia, ma è un’attività imprenditoriale e come tale ci si prefissa un utile.

Ogni azienda di hosting propone la propria offerta secondo un business plan “studiato” a tavolino con cui conseguire gli obiettivi imprenditoriali ed economici prefissati.

Attualmente la moda è quella di proporre prezzi stracciati e di vendere piani hosting a cifre che oscillano tra le 10 e le 20 euro (annuali).

Queste offerte commerciali però non tengono conto di un concetto fondamentale, ovvero che un piano hosting non è solo un prodotto, ma sopratutto un servizio.

Senza un’adeguata assistenza che risponda in tempi ragionevoli alle proprie esigenze, un piano hosting è potenzialmente un problema più che una soluzione.

Ciò che va considerato infatti prima dell’acquisto è la reale competenza dell’acquirente nella gestione/configurazione ed uso di ciò che ha comprato.

Ad acquisto ultimato infatti l’hosting provider vi comunicherà i dati di accesso e i parametri di configurazione dei vari servizi (web, email, ecc.), ed è compito vostro saper giostrarvi tra concetti come POP3, Client, FTP, modalità passiva/attiva, DNS e simili.

Siamo sicuri di aver padronanza di ciò ? Oppure sarebbe meglio delegare e spendendo qualcosa in più avere la garanzia di un’assistenza disponibile e cordiale e che non sia menefreghista e sfuggente, pur di rientrare nel misero budget con cui vi hanno venduto un prodotto ?

La qualità di un servizio di hosting infatti si vede sopratutto dell’assistenza.

Cosa succederebbe se foste attaccati da hacker ? Se un trojan infettasse il vostro sito, o se più banalmente non riusciate a configurare Outlook per ricevere e inviare posta ?

Quanto tempo sarebbe in grado di dedicarvi il reparto tecnico di fronte ad un canone annuale di 10 euro ? Normale che non vadano troppo per le lunghe, limitandosi a rimandarvi a insoddisfacenti FAQ ed a improbabili ricerche su Google.

Nel comprare un servizio di hosting dunque valutiamo la nostra reale competenza informatica e  l’importanza di un assistenza umana e professionale che ad oggi è l’unica componente che faccia ancora la differenza.

Ottimizzare le performance di un sito web. Alcuni passi fondamentali per gestire siti con migliaia di visite al secondo

ottimizzazione-siti-webQuando si ha a che fare con un sito web con moltissime visite, prima o poi si dovrà fare i conti con le risorse insufficienti, l’inefficienza del sito e col portafogli.

Col portafogli perchè se continuerete ad avere un sito lento, non venderete; ma anche perchè per aumentare le performance probabilmente vi venderanno servizi cloud e servizi di hosting da svariate migliaia di euro al mese.

Questo è infatti il modo di ragionare puramente commerciale e per niente etico di molti fornitori di hosting.

Nella maggior parte dei casi invece sarebbe bastato solo rivolgersi alle persone giuste per fare un tuning intelligente del sistema, sostituire eventuali servizi con equivalenti più efficienti e mettere in piedi tecniche per massimizzare le performance e minimizzare i costi.

Verosimilmente in alcuni casi potremmo dimezzare i costi o addirittura decimare, aumentando le prestazioni in quei casi particolarissimi in cui realmente serve avere il massimo dell’efficienza.

Tra gli esempi di alcuni casi potrebbero essere portali giornalistici, community online, blog, o altri siti generici che hanno molte visite concorrenti e che richiedono funzionalità di lettura/scrittura verso il database ed hanno un interprete lato server come PHP.

Siti del tipo “Il fatto quotidiano” o la community su android “Tuttoandroid“.

Come gestire tutti quegli utenti in contemporanea ? Come dimensionare l’hardware ? Come settare il database per avere il massimo delle performance ? Quale webserver usare ? Come configurare l’interprete PHP ?

Per rispondere a queste domande bisogna avere una approfondita conoscenza sistemistica, conoscere i pro e i contro delle varie soluzioni disponibili e mettere in piedi un ambiente ottimale per dare il massimo dell’efficienza. In poche parole : Ottimizzare.

Brevemente possiamo dire che nell’ottica di gestire una mole elevatissima di utenti concorrenti bisogna scordarsi di implementare le soluzioni standard che il mercato offre in ambiente hosting.

In primis va scelto un hosting dedicato e non condiviso. Un server dedicato ben dimensionato con connettività possibilmente europea se si vuol rimanere contenuti nei costi.

Uno Xeon Quad core con 32 Giga di RAM e 3 terabyte di dati, 100 Mbit di banda normalmente lo si può trovare a meno di 80 euro / Mese.

Il webserver che normalmente viene configurato in questi casi è NGINX che offre (a differenza di Apache) di servire rapidamente i contenuti statici con un utilizzo efficiente delle risorse di sistema. È possibile distribuire contenuti dinamici HTTP su una rete che utilizza i gestori FastCGI per gli script, e può servire come un bilanciatore di carico software molto capace.

Ad esso dovrà essere abbinato PHP-FPM.

PHP-FPM è una derivazione di Php Fastcgi molto interessante, che apporta modifiche ed un nuovo modello di utilizzo al progetto originario. Incluso ultimamente nella release di Php 5.3.3, PHP-FPM rappresenta una tecnologia abbastanza matura da poter essere utilizzata in ambienti di un certo calibro. PHP-FPM ha la capacità di avviare pool multipli di processi Fastcgi in ascolto su porte separate per soddisfare le richieste su ambienti di hosting virtuale multidominio, anche se il modello di progettazione principale non consiglia utilizzi orientati all’hosting multiplo. PHP-FPM è stato principalmente pensato per siti web oberati da numerose richieste HTTP ed è dunque molto indicato per ambienti mono sito, con web server come Nginx e Lighttpd.

Il database se MySQL dovrà essere configurato in maniera adeguata in modo di gestire al meglio l’allocazione delle risorse come la cache delle query, i thread concorrenti, i vari engine di storage (MyISAM e InnoDB in primis), ecc…
Non basterebbe un libro intero sul tuning di MySQL, ma vi basti sapere che il settaggio può fare il buono e il cattivo tempo.

Se utilizzate CMS che lo permettono (o applicazioni da voi scritte appositamente) potrete affiancare a questa potentissima ricetta MEMCACHED.

Memcached aumenta le prestazioni e la scalabilità di siti web dinamici con tecnologia MySQL attraverso un caching dei dati e degli oggetti nella memoria per minimizzare il carico del database. I più grandi nomi del web, come YouTube, Facebook, Fotolog e Wikipedia utilizzano Memcached e MySQL per soddisfare le esigenze di milioni di utenti e di miliardi di visualizzazioni delle pagine ogni mese.

A livello WEB invece molti CMS (Drupal, Joomla, WordPress, ecc…) permettono l’implementazione di appositi moduli per effettuare il caching dei contenuti, ovvero far in modo di ridurre sensibilmente la generazione di pagine dinamicamente tramite PHP e MySQL e dunque far in modo di servire contenuti statici.

A questo potrebbe essere utile implementare e configurare servizi CDN specifici per distribuire le risorse e rendere più efficace il tutto.
I nodi CDN sono geograficamente distribuiti, spesso connessi a diverse dorsali; questi nodi collaborano vicendevolmente per soddisfare le richieste di contenuti, trasferendoli in maniera trasparente al fine di ottimizzarne il processo di consegna: un sistema centralizzato con unico server centrale non sarebbe in grado di soddisfare le molteplici richieste di servizio da parte di numerosi utenti. Le ottimizzazioni possono portare come vantaggi la riduzione dei costi per l’ampiezza di banda, o il miglioramento delle prestazioni, o entrambi.

Per gestire forum con centinaia di migliaia di iscritti invece, bisogna affidarsi alla soluzione commerciale di punta (peraltro molto economica), ovvero Vbulletin. Molto malleabile ed estremamente ricco di funzionalità, eccelle per la sua indiscussa velocità.

Abbiamo visto fino a qui alcuni dei passi principali per mettere online un sito rivolto a centinaia di migliaia di utenti, sicuramente non tutti, e non discussi approfonditamente.

Si potrebbe parlare di APC, di database NOSQL come MongoDB, Redis, ecc… di Web Accelerator come Varnish, o di un sacco di altre cose che sapientemente installate e configurate possano portare a risultati a dir poco sorprendenti.

Se pensi che il tuo sito Web abbia bisogno di dare il massimo in termini di velocità, o se credi di spendere troppo per la tua soluzione hosting o server dedicato attuale non ottimizzato e vuoi risparmiare oltre 2 terzi del canone mensile, siamo sicuramente la soluzione ai tuoi problemi.

Con un’analisi iniziale gratuita possiamo farti la nostra migliore offerta per avere il massimo delle performance al minor costo.

Contattaci per un preventivo gratuito

Mailserver, blacklist, dnsbl e spam. Uscire dalle liste e vivere serenamente.

spam_dnsbl_rmiozioneLo SPAM è diventato un business non solo per chi invia milioni di email indesiderate, ma anche per quelle aziende che si propongono come guardiani della rete offrendo gratuitamente il loro servizio di DNSBL per limitare la ricezione di messaggi indesiderati nella propria casella email.

Una DNS-based Blackhole List (anche DNSBL, Real-time Blackhole List o RBL) è un mezzo attraverso il quale è possibile pubblicare una lista di indirizzi IP, in un apposito formato facilmente “interrogabile” tramite la rete Internet. Come suggerisce il nome, il meccanismo di funzionamento è basato sul DNS (Domain Name System).

Le DNSBL sono principalmente utilizzate per la pubblicazione di indirizzi IP legati in qualche modo a spammer. La maggior parte dei mail server possono essere configurati per rifiutare o contrassegnare messaggi inviati da host presenti in una o più liste.

Questi servizi offerti gratuitamente agli utenti e sistemisti di tutto il mondo, permettono realmente di decimare l’invio di SPAM, nonchè la ricezione, contribuendo a una funzione realmente utile all’utente finale.

Può capitare però che si finisca dentro a queste liste e di entrare in una vera e propria valle di lacrime.

Entrare li dentro significa vedersi rifiutare la consegna dei messaggi alla maggior parte degli indirizzi email del mondo che fanno affidamento alle liste DNSBL per bloccare gli spammer.

spamhaus_dnsbl_basic

Ciò può essere un enorme problema sopratutto se ci lavoriamo. Significa infatti che il resto del mondo ci vedrà come Spammer e rifiuteranno a priori e in modo del tutto automatico le nostre email.

Il problema può essere ancora più grande se siamo un fornitore di servizi mail e vediamo bloccare l’intero server magari per colpa di un account di un cliente violato che mandando quantitativi di spam notevoli ci ha fatto finire dritti dritti in una o più di queste liste.

Uno dei modi ufficiali per uscirne è quello di fare la richiesta di rimozione.

Si va sulla pagina web di ogni Blacklist in cui siamo finiti e si compila la richiesta di rimozione dalla lista.

La rimozione non è immediata, ma può impiegare da un paio d’ore per le liste gratuite, fino anche ad una settimana per le liste “a pagamento”.

Il virgolettato è d’obbligo, in quanto è vero che il servizio di DNSBL tutte le liste lo rendono gratuito ma è vero che alcune liste pretendono un pagamento variabile tra 40 e 100 dollari per effettuare la rimozione dell’indirizzo nell’immediato.

Cosa succede dunque se un mailserver finisce in 5 o 6 blacklist a pagamento ?

O facciamo la richiesta di rimozione gratuita e aspettiamo fino ad una settimana per continuare a inviare email, o ci facciamo carico di spendere circa 500 dollari per venire rimossi nell’immediato (o quasi) da queste liste.

Nella pratica nessuna delle due ipotesi è realmente accettabile.

Uno degli stratagemmi sicuramente più pratici e indolori, al di la di mettere in piedi smarthost e simili, è quello di disporre di indirizzi IP di riserva da poter usare per inviare le email al posto dell’IP finito in Blacklist.

A livello aziendale normalmente si assegnano classi di circa 5 ip utilizzabili per piani di tipo business, Alice Business, NGI, ecc.

A livello Datacenter invece è possibile fare richiesta di indirizzi IP aggiuntivi al costo di 1 o 2 euro al mese.

Avere la possibilità di configurare il proprio mailserver per inviare la posta con un indirizzo IP diverso da quello in blacklist è qualcosa di estremamente rapido e funzionale.

Nessuna configurazione complessa, nessun costo esoso. Il giusto prezzo (economico) per ripartire nel giro di 5 minuti e vuotare la coda di posta che i mailserver di tutto il mondo non accettava perchè visti come spammer.

Qualora fosse incappati in questa soluzione e non riusciate a venirne fuori, vi ricordiamo che offriamo consulenza sistemistica su mailserver di tipo Postfix, Qmail, Exim e Sendmail.

Contattaci.

Mail e antispam service unavailable client host blocked using list.dsbl.org

Sin da oggi Venerdì 10 Agosto 2012, molti utenti email vedono rifiutare la consegna delle email che tornano indietro con un messaggio di errore del tipo : Service unavailable; Client host [17.158.233.225] blocked using list.dsbl.org

E’ bene precisare che ciò è dovuto alla configurazione errata di molti mailserver che si appoggiano alla lista DNSBL list.dsbl.org per i dovuti controlli antispam.

Sebbene questa lista sia ufficialmente “morta” dal lontano 2009, fino ad oggi non ha mai dato problemi di sorta sopratutto per ciò che riguarda i falsi positivi che da oggi affligge ogni messaggio in arrivo.

Si consiglia dunque a tutti gli amministratori di server mail (Postfix, Qmail, ESIM, Sendmail, Exchange o qualsiasi altro) di disabilitare il controllo su questa lista.

Se usaste postfix ad esempio dovreste editare il file main.cf e rimuovere o commentare la seguente linea :

#postfix/main.cf:smtpd_client_restrictions = reject_rbl_client sbl-xbl.spamhaus.org, reject_rbl_client list.dsbl.org

e poi riavviare il mailserver.

Backup remoto di un database MySQL su FTP con lftp e gzip per Windows.

Se avete mai avuto la necessità di fare un semplice backup di un DB MySQL e avete cercato in rete una soluzione facile ed efficace avrete sicuramente notato la mole inaudita di soluzioni più o meno professionali e potenti (dal costosissimo MySQL Enterprise Backup all’altrettanto valido, migliore, open source e gratuito XtraBackup della Percona) ma sopratutto infiniti script più o meno elaborati che facendo uso del semplice mysqldump permettono un backup (magari in rete).
Solitamente però sono fatti scritti in shell scripting (bash, sh, csh) o in linguaggi tipo Perl o Python che fanno uso dei comandi di sistema per ovviare le operazioni elementari che un backup richiede.
Difficilmente (in verità mai, ecco perchè ho scritto questo articolo) si trovano script funzionanti in ambiente Windows che permettano un uso immediato, semplice e malleabile come su ambienti Linux.

Lo spunto di questo articolo nasce dunque da un caso reale, e più precisamente la necessità di effettuare un backup remoto di un DB MySQL di uno studio personal training per salvaguardare i dati da eventuali rotture hardware, perdite dati, furti.

Lo script fa uso di 2 comandi originariamente Linux ricompilati e portati su Windows.

  • gzip (per la compressione del DB)
  • lftp (per il trasferimento e la sincronizzazione del backup generato su un server FTP)

 

il tutto viene invocato da uno script batch (.bat) che esegue il dump del DB (che fa uso di tabelle innodb, stored procedure, funzioni, viste) tramite l’invocazione di mysqldump (dell’installazione mysql originale già presente sul sistema) con l’opzione –routines che permette di fare il dump non solo dello schema e dei dati ma anche delle stored procedure, funzioni, trigger che sono elementi vitali del DB stesso.

Piu specificamente ecco l’intero script:

@echo off
 
set hour=%time:~0,2%
if "%hour:~0,1%" == " " set hour=0%hour:~1,1%
set dt=%DATE:~-4%-%DATE:~3,2%-%DATE:~0,2%_%hour%%time:~3,2%
cls
 
echo -------------------------------------------------------------------------
echo Backup del Database in corso.
echo.
echo Per favore non chiudere questa finestra e non usare il gestionale.
echo.
echo -------------------------------------------------------------------------
echo.
 
c:\xampp\mysql\bin\mysqldump -uNOMEUTENTE -pPASSWORD --opt --routines nomedatabase | gzip.exe > c:\backup\sql\nomedatabase-%dt%.sql.gz
echo Trasferimento del backup remoto in corso ...
 
c:\backup\lftp -f /backup/copiaremota.lftp

Lo script di per se è molto semplice e nel dettaglio si comporta nel seguente modo :

  1. Crea una variabile hour a cui è associata l’ora del sistema
  2. Crea una variabile dt a cui è associata la data e l’ora del sistema
  3. invoca mysqldump (dal percorso dove è installato mysql) specificando username e password e il nome del database da salvare, passando l’output tramite pipe a gzip.exe che genera un file di tipo .gz sotto la cartella c:\backup\sql
  4.  viene invocato lftp che ha come parametro copiaremota.lftp

 

copiaremota.lftp è il file contenente le direttive da “dare in pasto” a lftp.exe

set ftp:ssl-allow no
open -u nomeutenteftp,passwordftp ftp.hostremoto.it
mirror -R --only-newer --verbose /backup/sql /
quit

Basterà dunque modificare username e password e il nome dell’host remoto per il server ftp nel file copiaremota.lftp per adattarlo al proprio contesto.

Esso una volta processato da lftp.exe farà il mirror dei file nuovi dalla cartella c:\backup\sql alla root directory del server ftp in questo caso /

NOTA BENE : dato che lftp è conforme allo standard POSIX di unix, pur lavorando in ambiente windows, la cartella c:\backup\sql diverrà nel file di configurazione .lftp /backup/sql

Per far funzionare il tutto dunque, scompattare l’allegato che troverete alla fine di questo articolo in c:\backup, modificare il file backup.bat con il path corretto di mysqldump, nome utente e password mysql e nome del database.

Successivamente modificate il file copiaremota.lftp inserendo la configurazione corretta del vostro server ftp.

Lo script rimane dunque molto semplice e funzionale per il backup schedulato di DB MySQL di tipo MyISAM o InnoDB. Sicuramente non è la soluzione ideali per ambienti mission critical che richiedono l’integrità e la continuità in produzione su cui consiglio soluzioni di replica Master/Slave e backup a caldo con  XtraBackup, ma è una possibile soluzione per database di “semplici” gestionali.

In accoppiata con la schedulazione di Windows (ovvero Operazioni Pianificate) può diventare veramente di grossa utilità. In fondo basta solo lanciare backup.bat per avere una copia remota in maniera del tutto automatica.