Dopo tanto tempo ecco a voi un “tutorial per sysadmin“, oggi vediamo come bloccare dei potenziali attacchi di tipo indiretto.

Cosa significa attacco indiretto? Significa che non c’è un attacco che parte da un punto preciso e finisce sul nostro server, in un attacco spam via referral link chi ti attacca fisicamente, ed inconsapevolmente, sono gli stessi utenti che visitano il tuo sito.

Vi porto l’esempio di un attacco che ho dovuto gestire fino a ieri sera. 3 giorni fa poco dopo l’ora di pranzo mi chiamano segnalando che il sito istituzionale di $cliente non si vede più.

Questo è un sito grosso, piazzato su un cluster altrettanto grosso, solo le macchine del front end sono 4 e non sono macchine comprate da mediaworld, sono dei mini carro armati.

Quindi quando mi si dice “il sito è giù” rimango alquanto basito, collegandomi sui bilanciatori vedo che in maniera abbastanza randomica l’apache che fa da reverse proxy non riesce più a contattare la porta 80 di alcune macchine del front end, ed in effetti con un semplice telnet finisco con un timeout.

Per tagliarla corta, dopo ore ed ore di analisi abbiamo visto che molti errori venivano generati da chiamate GET che avevano come referral link un motore di ricerca di inserzioni online.

Consultandomi con gli sviluppatori vengo a sapere che l’url verso cui sono dirette le GET è una landing page di una campagna di affiliazione via banner, lanciata da $cliente, ne consegue quindi che questo motore di ricerca deve essersi iscritto a questa campagna; peccato che visitandolo del banner in questione non ve n’è traccia.

Il sospetto è quindi che i furbacchioni abbiano prelevato il codice del banner e l’abbiano nascosto in qualche maniera nel codice delle pagine, in modo che ad ogni pagina visitata sul motore parta un click “fasullo” sul banner. Basta avere un motore di ricerca che fa tante visite ed ecco che automaticamente la truffa si tramuta in attacco.

Il sito istituzionale di $cliente è gestito da application server java [sigh] i quali dovendo gestire un throughput di GET mastodontico entro breve tempo saturavano la memoria messa a disposizione dalla JVM (Java Virtual Machine) facendo si che le GET si accodassero, mandando successivamente in blocco la porta 80, e quindi rendendo il sito inaccessibile.

Qui non si può filtrare semplicemente via firewall, perchè come detto prima l’attacco è indiretto, non parte dai server del motore di ricerca ma sono gli utenti che vengono dirottati sul sito che attaccano il sito stesso.

L’unica soluzione è quindi adottare il mod_security di apache2 e filtrare le GET in entrata basandosi sul referral link, in modo che le chiamate “dirottate” dal motore di ricerca non vengano processate dal web service java e vengano direttamente rimbalzate con errore di tipo 500.

Una volta su debian bastava installare libapache2_mod-security via apt-get, ma su lenny sembra che questi pacchetti non siano più presenti, e quindi bisogna prelevarli tramite il sito ufficiale di mod security [mirror per i pacchetti debian] ed installarli via “dpkg -i“

Installati i pacchetti è sufficiente creare un file chiamato mod_security dentro /etc/apache2/conf.d e scriverci dentro:

<IfModule mod_security.c>

# mod_security configuration directives

# …

# Turn the filtering engine On or Off

SecFilterEngine On

# Some sane defaults

#Check if URL characters where encoded

SecFilterCheckURLEncoding On

#Check UTF-8 encoding

SecFilterCheckUnicodeEncoding Off

#Allow 1 byte characters

# Accept almost all byte values

SecFilterForceByteRange 0 255

# Server masking is optional

# SecServerSignature “Microsoft-IIS/0.0?

SecAuditEngine RelevantOnly

# The name of the audit log file

SecAuditLog /var/log/apache2/audit_log

# You normally won’t need debug logging

# Debug level set to a minimum

SecFilterDebugLog /var/log/apache2/modsec_debug_log

SecFilterDebugLevel 0

# Should mod_security inspect POST payloads

SecFilterScanPOST On

# By default log and deny suspicious requests

# with HTTP status 500

SecFilterDefaultAction “deny,log,status:500?

# Blocco il referral nasone.it

SecFilterSelective “HTTP_REFERER” “domain.tld”

</IfModule>

Compilato il file salviamolo e riavviamo apache, e da questo momento le chiamate in questione verranno filtrate, potete vedere se il filtro funziona tramite il file di log impostato nella configurazione sopra o più semplicemente vedendo le chiamate che arrivano nei file di accesso al virtual host di apache, vedrete che le GET da questo momento in poi non otterranno più un codice 200 ma 500.

Popularity: 1% [?]

Puoi visualizzare il post originale qui.

Popularity: 1% [?]

Puoi visualizzare il post originale qui.

Popularity: 1% [?]

Puoi visualizzare il post originale qui.

Popularity: 1% [?]

Puoi visualizzare il post originale qui.

Popularity: 1% [?]

Puoi visualizzare il post originale qui.

Popularity: 1% [?]

Puoi visualizzare il post originale qui.

Popularity: 1% [?]

Puoi visualizzare il post originale qui.

Popularity: 1% [?]

Puoi visualizzare il post originale qui.

Popularity: 1% [?]

Puoi visualizzare il post originale qui.

Popularity: 1% [?]

Puoi visualizzare il post originale qui.

Popularity: 1% [?]

Puoi visualizzare il post originale qui.

Popularity: 1% [?]

Puoi visualizzare il post originale qui.

Popularity: 1% [?]

Puoi visualizzare il post originale qui.

Popularity: 1% [?]

Puoi visualizzare il post originale qui.

Popularity: 1% [?]

Puoi visualizzare il post originale qui.