Re: Apache e default.ida

> Come penso molti di voi, ricevo diverse chiamate ad un presunto file
> default.ida nella dir di apache. Si tratta di Code Red. Logicamente
> Apache non ne è affetto, ma mi chiedevo questo: per evitare che tutte le
> volte il mio server invii una pagina di errore 404 (è pur sempre
> traffico sulla mia banda) voi cosa consigliate?
>
> Creare uno O file in htdocs denominato default.ida? O altro?

A meno che tu non abbia una pagina 404 molto grande, il maggior spreco
di banda nell'attacco di CodeRed e sue varianti (si, e' CodeRed) si ha
nel transito dei pacchetti che contengno la GET ed il codice del worm.

Premesso che con l'attuale rate degli attacchi ritengo che sia inutile
un sistema du questo tipo, direi che il modo piu' efficace di limitare
il traffico in transito dovuto a codered e' quello di:

- filtrare il traffico diretto verso la porta 80/tcp con uno strumento
  analogo allo string match di netfilter;
- usare uno strumento per abbattere la connessione analogo al flexresp
  di snort.

Per il problema citato da dido, i due presidi devono essere utilizzati
contemporaneamente. In questo modo il traffico sara' limitato al three
way handshake, al primo pacchetto (con la GET ed un primo segmento del
worm) e ai due RST emessi da snort e netfilter o dal solo snort.

In pratica, completato l'handshake, il worm inviera' la GET che dovra'
essere riconosciuta da netfilter (o chi per lui) ed essere o droppata,
e snort dovra' resettare entrambi i lati della connessione con rst_all
o rigettata con RST, e snort dovra' resettare con un rst_rcv.

Snort, da solo, potrebbe non essere efficace nel 100% dei casi a causa
di possibili ritardi nell'emissione dei suoi RST/ACK: se nel frattempo
la finestra tcp si e' spostata non sarebbero efficaci. Interponendo il
filtro di netfilter, invece, si ha la certezza che flexresp possa fare
il suo sporco lavoro, perche' la connessione non puo' proseguire oltre
il punto a cui e' arrivata.

E' importante limitare al massimo i falsi positivi. La regola di snort
dovra' riferirsi al traffico "established" nella direzione "to_server"
utilizzando la direttiva flow. Le rules di default ai sid 1242, 1243 e
1256 sono un poco generiche e potrebbero non essere una buona base per
regole che attueranno la direttiva resp. In particolare la 1256 non e'
efficace in una configurazione di questo tipo, in quanto fa match solo
sul secondo pacchetto [1] contenente il worm, che non arrivera' mai in
quanto netfilter fermera' la sessione al primo. Se pensi di attuare un
sistema di questo tipo, dovresti fare un'analisi del traffico generato
dalle diverse varianti di codered per poi crearti delle regole il meno
possibile prone a falsi positivi. Questo aspetto dipende anche da cosa
passa normalmente in direzione del tuo server e, quindi, dovra' essere
valutato da te (ad es: se hai una pagina rigettare_default.ida.htm non
potrai usare una regola semplice come quella del sid 1242). Facilmente
una regola uricontent che faccia match su "/default.ida?" con depth di
13 byte penso che sia sufficientemente specifica nella maggioranza dei
casi (ovviamente varrebbe per le sole varianti del worm ad oggi note).


Fabio

[1] in realta' quella regola fa match sul superpacchetto assemblato da
    stream4, ma il discorso non cambia.


________________________________________________________
http://www.sikurezza.org - Italian Security Mailing List