Newsgroup: it.comp.os.unix
Titolo: Solaris 2.6 e codered + nimda

Quando ce li toglieremo di mezzo questi due worms? :-((
...a parte questo, quattro netra-T 1125 con solaris 2.6 e SWS web server
1.0, che nonostante l'applicazione delle reccomended patches, presentano
questo problema sotto l'attacco continuo di codered e nimda: netstat -na
restituisce una sfilza impressionante di CLOSE_WAIT di connessioni da
siti infettati, e la macchina diventa di una lentezza impressionante,
fino a renderla eccessivamente satura e rendere impossibili le
connessioni al web (macchina ma soprattutto web server pressoche'
"incartati"...). Che devo fare? Aggiornare SWS alla versione 2.0,
passare ad Apache, aggiornare Solaris alla 2.8, etc. etc... fare causa
alla microsoft o chi non applica le patch a IIS? :-))))
In ogni caso, al di la' di cosa mi verra' consigliato, da cosa
dipenderebbe il problema? (la macchina dovrebbe comunque reggere un
carico IMHO nettamente superiore a questo, con un processore a 296mhz,
256mb ram, una buona swap. anche se ammetto che in realta' sono state
installate, due anni fa, da schifo...). Magari ipoteticamente un timeout
delle connessioni tcp/ip male impostato nella configurazione di SWS? E'
una ciofeca SWS? Nel caso chiedo venia, ma SWS non lo conosco
approfonditamente.
bye G.L.

Gian Luca Sole wrote:
Penso di aver trovato la soluzione, adesso vedo un po' come si comporta...
(come prima impressione mi sembra gia' molto meglio :-)  Bisogna modificare
alcuni parametri del tcp/ip:
http://www.sean.de/Solaris/tune.html
http://sunsolve.sun.com/pub-cgi/retrieve.pl?doc=fiplanet%2F1268&zone_32=CLOSE_WAIT
%2A%20
bye G.L.

Gian Luca Sole wrote:
Niente da fare... le CLOSE_WAIT (e solo quelle delle connessioni dai siti infettati),
che dovrebbero perdurare per non piu' di 60 secondi, permangono fino ad accumularsi in
numero spropositato. Il server Web SWS si "incarta", la macchina rallenta enormemente,
il risultato sembra quello di un attacco DOS... Le modifiche ai parametri del tcp-ip
sono le seguenti:
/usr/sbin/ndd -set /dev/tcp tcp_keepalive_interval 900000
/usr/sbin/ndd -set /dev/tcp tcp_rexmit_interval_min 3000
/usr/sbin/ndd -set /dev/tcp tcp_rexmit_interval_initial 3000
/usr/sbin/ndd -set /dev/tcp tcp_rexmit_interval_max 10000
/usr/sbin/ndd -set /dev/tcp tcp_close_wait_interval 60000
/usr/sbin/ndd -set /dev/tcp tcp_ip_abort_interval 60000
/usr/sbin/ndd -set /dev/tcp tcp_conn_req_max_q0 4096
/usr/sbin/ndd -set /dev/tcp tcp_conn_req_max_q 2048
Any suggestion?
bye G.L.

 sono le seguenti:
Non conosco abbastanza solaris ma ho visto come funziona nimda: la maggior
parte delle connessioni viene sempre dagli stessi host: rigetta le connessioni
provenienti da questi ip.
Se non hai tempo di farlo manualmente (la lista ovviamente deve essere
integrata con una certa periodicità) puoi fare uno script che legge i log del
demone httpd, estrae gli ip dei server infettati e li aggiunge al tuo filtro:
io non ho niente di pronto (lo facevo a mano un paio di volte al giorno e
comunque con iptables su linux) ma magari puoi trovare qualcosa con un motore
di ricerca.
Fabio

 Fabio
Grazie
Saluti,
G.L.

 quella che ritengo una bug nello stack tcp-ip di solaris 6.
Cospargersi il capo di cenere, flagellarsi col cilicio, e diversi giorni di digiuno,
dopo aver proferito un b. del genere...  :-)))
Soluzione: Patch 105710-01, Sun WebServer 1.0: Security and performance bla bla bla
Il problema e' che il nimda ed il code red non rispettano la corretta sequenza di
handshaking nella chiusura della connessione tcp/ip. Per un baco, il web server
aspetta indefinitamente il pacchetto "ack", e lascia permanentemente lo stato del
socket in CLOSE_WAIT.
bye G.L.

 socket in CLOSE_WAIT.
Bisognerebbe lamentarsi con il produttore: č inammissibile una cosě palese
violazione delle RFC :)
Se per caso hai anche problemi di banda passante un altro accorgimento
potrebbe essere quello di ridurre le dimensioni della pagina dell'errore 404.
Fabio

 potrebbe essere quello di ridurre le dimensioni della pagina dell'errore 404.
No, problemi di banda no... anche se questo traffico supplementare e indesiderato
lo paghi...  :-(
bye G.L.