Newsgroup: it.comp.os.linux.sys
Titolo: SYN Flood & DOS in genere

Ho un problema su uno-due server, quasi sicuramente causato da un dos.
La macchina muore letteralmente, l'accesso via SSH o l'apertura di
pagine web è impossibile e da console la reattività è praticamente
nulla.
O non scrive niente a video quando premo i tasti oppure cerco di fare
il login e dopo 5 minuti ancora non mi chiede la password.
Se lascio attivo un htop prima che il server collassi, la schermata si
freeza con il 100% di CPU (QuadCore), 100% di ram occupata (6GB) e
100% di swap occupata (4GB).
Nei log non vedo nulla, se non alcuni messaggi tipo "possible syn
flooding, sending cookies" o un errore simile, a memoria non lo
ricordo esattamente. (anche perchè son riuscito a leggere i log solo 2
volte, come dicevo sopra, la macchina si pianta paurosamente).
mrtg durante questo blocco mi fa vedere dei picchi di traffico 3-4
volte superiori alla norma
(il server, di norma, fa circa 5mbit, con l'attacco ne vedo 15-20) e
dopo pochi secondi la macchina muore.
Presumo sia un attacco DOS, più precisamente un SYN ma:
- ho attivato i syncookie
- ho messo il backlog a 20480 (minchia!)
- ho diminuito la durata delle connessioni half-open da 5 (default) a
2 (non ricordo il calcolo da fare, ma se non erro si parla di circa
30-45 secondi se il valore è impostato a 2)
- ho provato con iptables a droppare tutto il traffico che genera più
di 150 connessioni NEW al secondo
- ho installato "dos deflate" che manda in drop gli host che generano
più di X connessioni, nel mio caso 200, per 10 minuti.
Niente, la macchina muore sempre e comunque.
Idee?
Se la macchina muore ed io non riesco più accedere, come posso sapere
chi sta facendo cosa?
Dovrei lasciare un programma in esecuzione h24 con la console già
loggata, così quando muore la macchina avrei una istantanea a video
del programma. Ma quale programma mi permette di monitorare il
traffico in questa maniera? Con wireshark si riesce a capire se sono
sotto attacco dos?
Qualche regola di iptables per mitigare gli effetti? Forse quelle che
ho inserito io (ne ho usate due differenti) sia con --limit sia con --
recent non funzionano. Eppure se metto come soglia massima 1
connessione al secondo e mando in log, iptables logga correttamente.
Se metto più di 200 e mando in drop, non solo non logga, ma non droppa
nemmeno e mi pare
impossibile un dos con meno di 200 connessioni.
Il server fa svariati milioni di impression al giorno, è un server con
un circuito payperclick ovvero
tantissime mini-connessioni (e di conseguenza tantissimi syn)
necessarie a caricare una pagina in php e la relativa immagine del
banner, il che rende l'identificazione del traffico malevolo rispetto
a quello legittimo ancora più difficile, dato che tantissime mini-
connessioni sono "la norma".
Help me :)

 Help me :)
Potresti iniziare a loggare su un host remoto...
Una serie di altre domandine sorgerebbero spontanee...immagino
che tu abbia il modulo di conntracking caricato, se usi iptables
su quella macchina.
Che valore hai in /proc/sys/net/ipv4/netfilter/ip_conntrack_max?
Sarebbe inoltre interessante monitorare
/proc/net/ip_conntrack, nel caso in cui il conntracking sia attivo.
Se il problema dovesse essere effettivamente un syn flooding, potresti
vedere un mio articolo di qualche giorno fa sull'argomento, per cercare
di mitigare...il thread si intitola "Consiglio per Regole IPTABLES".
Interessante, comunque...

 Interessante, comunque...

 
MERDA!
Non ho il ipt_connlimit compilato e no, ricompilare il kernel
su quella macchina *non* è una soluzione.
Qualche workaround senza connlimit?

 ho fatto 2+2)
Escludi al 100% qualche "DoS" interno, ovvero qualcuno che esegua qualche 
procedura strana (a livello di codice da qualche altra parte, magari)?
-- 
Vide

 macchina *non* è una soluzione.
Non hai bisogno di ricompilare il kernel.
Che stai usando, come distro e versione?

 procedura strana (a livello di codice da qualche altra parte, magari)?
Al 100% no, ma a quel server accedo solo io.
Il proprietario ora è all'estero e non ha modo di accedere
ne di modificare gli script.
Esiste un programma che mi faccia delle istantanee del sistema
su cosa stava facendo, i carichi di lavoro, i programmi attivi
e così via? una sorta di snapshot, un super log con scritto tutto.
Esisterà no?

 Che stai usando, come distro e versione?
# uname -a
Linux x 2.6.21.5-smp #3 SMP Wed Sep 10 15:44:17 CEST 2008 i686 Intel(R) 
Xeon(R) CPU           E5320  @ 1.86GHz GenuineIntel GNU/Linux
# cat /etc/slackware-version
Slackware 12.0.0
( siate clementi, vi prego, ho altro a cui pensare che non ai
vostri insulti :-) )

 via csv. Login failed. Boh. Poi ho desistito....
Uhm...aspetta, connlimit, in realtà, dovresti avercelo anche senza gli
xtables-addons...
Hai il file di configurazione del kernel in uso?
Cerca CONFIG_NETFILTER_XTABLES e CONFIG_NETFILTER_XT_MATCH_CONNLIMIT.

 Cerca CONFIG_NETFILTER_XTABLES e CONFIG_NETFILTER_XT_MATCH_CONNLIMIT.
# cat /boot/config | egrep "XTABLES|CONNLIMIT"
CONFIG_NETFILTER_XTABLES=m

 CONFIG_NETFILTER_XTABLES=m
Dovresti poter compilare il solo modulo di connlimit senza rifare
tutto il kernel, allora.

 tutto il kernel, allora.
Ok, ma non trovo da dove scaricarlo.
il cvs server non va...

 il cvs server non va...
Ok, ho scaricato.
Ho compilato ma *non* ho fatto il make install
perchè poi in caso di problemi divento matto
a tornare alla versione precedente.
Ora ho "iptables/extensions/libxt_connlimit.so"
ma ovviamente non mi carica il modulo.
Io ho sempre odiato dover ricompilare i moduli di
netfilter, non ci son mai riuscito.

 Ok, ma non trovo da dove scaricarlo.
E' *già* nei sorgenti del kernel...

 Ora ho "iptables/extensions/libxt_connlimit.so"
Quella è la libreria userspace...

 E' *già* nei sorgenti del kernel...
Si ma dove?
# find -name *connlimit*
non ho nessun file connlimit.
ci sono i file di tutti gli altri moduli ma non di quello
tant'è che ho letto che per installarlo bisognava usare patch-o-matic
ed è una procedura che, sinceramente, non so fare.
Sarò scemo, ma non son capace ad installare
i moduli netfilter aggiuntivi.
(per la cronaca, spero di tamponare almeno con questo script eseguito
ogni minuto, almeno non mi devo più alzare di notte)
# cat /usr/local/bin/emergency_reboot.sh
#!/bin/sh
LOAD=$(cat /proc/loadavg  | awk '{print $2}' | cut -f1 -d.)
if [ $LOAD -gt 20 ]; then
    /sbin/reboot
fi
ROTFL, ROTFL e ancora ROTFL

 Si ma dove?
Per quanto ne so io ti basta dare il classico "make modules" poi "make 
modules_install" e ti ritrovi il modulo installato nella dir del tuo 
kernel sotto la lib
Rizio
-- 
Si dice che essere liberi significa non avere nulla da perdere...sembra 
facile a prima vista...ma la verità è che non avere nulla da perdere 
significa essere pronti a rischiare tutto ciò che si possiede.

 kernel sotto la lib
Si, però prima lo devi selezionare come modulo.
Io non ho la voce ne nel file di config, ne in "make menuconfig" ne
tantomeno il file da compilare....

 Con wireshark si riesce a capire se sono sotto attacco dos?
Tendenzialmente sě; metti uno sniffer su una porta in monitoring e salvi 
tutto il traffico fino a che non ti si atterra la macchina.
Poi con wireshark, ma anche con altri tools (snort, ngrep, tcpreply, 
tcpflow, ecc.ecc.) puoi analizzare il traffico.
Non č cosě semplice come appare a parole.
-- 
Flavio Visentin
Scientists have finally discovered what's wrong with the female brain:
On the left side, there is nothing right, and on the right side, there
is nothing left.

 Non è così semplice come appare a parole.
Appunto, vorrei prima sapere se è veramente un dos
che mi uccide la macchina....
C'è un programma che mi fa delle istantanee del server?
Ovvero un log con tutto: processi in esecuzione, carico del disco
e tutto il resto, senza dover usare 30 programmi differenti...

 tantomeno il file da compilare....
Avevo capito che fosse incluso in questo:
CONFIG_NETFILTER_XTABLES=m
Hai gia' provato a guardare un make menuconfig di un kernel "vergine" ?


 Hai gia' provato a guardare un make menuconfig di un kernel "vergine" ?
Non proprio, essendo una slackware, ha un kernel vanilla di suo...
(per la cronaca, questa mattina vedo un picco di 80mbit di traffico,
che io non ho nemmeno
come banda, e poi la macchina è morta. Quasi quasi escludo un ddos, se
fosse un ddos non
potrebbe saturare più della mia banda, ovviamente, inoltre l'utente è
limitato a 5mbit)

 limitato a 5mbit
Ecco l'ultimo /proc/loadavg
539.84 1000.10 1005.39 350/1990 16777
un dos può produrre un load così alto?

 un dos può produrre un load così alto?
Io comincio a pensare piu' ad un problema sw sai.... anche solo in 
funzione dello script che hai messo a far girare ogni 2 minuti....
non riesci ad eliminare uno ad uno i programmi in esecuzione ?
Potrebbe essere un problema hw ? Dischi e ram come li vedi ? Cioe' se 
stacchi il cavo di rete per 5 minuti tutto torna alla normalita' ?


 limitato a 5mbit)
Ma siamo sicuri che tu non abbia un rootkit o simili ?! Che magari il 
server ha subito un'incursione e te lo stanno usando in "malo modo"...
Partire con una distro live e far girare un rootkit detector... te la 
butto li'.


 butto li'.
Devo provare. In effetti tutto può essere.
Domani il proprietario del server viene qui e
gli dico che devo riavviare la macchina per un tot di tempo...

 stacchi il cavo di rete per 5 minuti tutto torna alla normalita' ?
Dischi sono ok.
La ram ora faccio partire un test che va in userspace, domani poi
lo farò con un cd di boot con memtest++.
Se stacco il cavo non cambia nulla, la macchina resta collassata.
Ma se fosse un problema di ram, crasherebbe il server, invece qui
non crasha nulla, semplicemente si satura tutto il saturabile
(cpu, ram, swap, ...) e si surgela.

 100% di swap occupata (4GB).
Un synflood non ti occupa tutta questa memoria, sei fuori strada.
Se usi apache, limita il numero di childs/thread e di numero massimo di
clients.
-- 
A: Because we read from top to bottom, left to right.
Q: Why should i start my reply below the quoted text?

 (cpu, ram, swap, ...) e si surgela.
Ni, potrebbe essere un fortunato caso di corruzione di uno specifico 
indirizzo di RAM.... lo sai; la sfiga ci vede benissimo ! Personalmente 
ho smesso di escludere delle cause quando il debug entra nello stato 
"improbabile"
(Es. un portatile HP dopo 2 mesi di sostituzioni in garanzia della 
board, ram, hd, e tutto il resto continuava a stagnarsi senza apparente 
motivo; tutto rallentava di colpo diventando un 486 con XP sp3 
installato ! Alla fine era l'alimentatore.... e questa per dirne una 
senza attingere alle storie di sala macchine di Davide :) )


 clients.
Già fatto, non sono pompatissimi
     ServerLimit           1000
     StartServers          10
     MinSpareServers       10
     MaxSpareServers       30
     MaxClients            1000
     MaxRequestsPerChild   100

 senza attingere alle storie di sala macchine di Davide :) )
ROTFL.
Comunque, CtRiX mi ha illuminato, potrebbe essere banalmente il numero
di connessioni apache, che quando salgono alle stelle fanno collassare
il tutto. Quello che però mi fa strano è che i blocchi avvengono anche
alle 3 di notte, quando il traffico è 1/3 di quello giornaliero.
Alle 16 del pomeriggio non si è mai bloccato nulla, ed il traffico è
massimo. Si è bloccato invece più volte alle 20 o alle 03 di notte
con il traffico di parecchio inferiore al pomeriggio.
Comunque, abbasso i limiti di apache, vediamo che succede.

 clients.
dimenticavo:
ok, potrebbe essere apache a farmi collassare la macchina, ma come
mai un aumento improvviso della banda occupata anche in piena notte
quando solitamente il traffico rasenta i 200-300kbit (anzichč i 5mbit
di pieno giorno)
magari non č un synflood ma non escludo che possa essere un ddos mirato
ad apache, il quale istanzia troppe risorse rispetto a quelle
istanziabili (forse la mia conf č troppo spinta) e fa collassare tutto.
Ho abbassato i limiti di apache, ma non risolverei comunque il ddos.
Se mi aprono 10000 connessioni in 1 secondo, magari il server regge
ma mi ritroverei con il traffico legittimo tagliato fuori....

 Help me :)
C'è anche MySql sulla macchina ?
Controllato la tmp ? è eseguibile ?
Hai provato a montare mod_evasive su apache ?
			-- Yena --

 Hai provato a montare mod_evasive su apache ?
Si, proprio ora....
Vediamo che succede, intanto ho sgonfiato apache...

      MaxRequestsPerChild   100
Stacippa....
Devi pensare (Ad esempio) che  se usi PHP ogni child alloca memoria per
l'interprete.
Se usi un DB, ogni istanza PHP che viene lanciata dal child, alloca risorse
anche per il DB.
Abbassa, abbassa...
Utilizza mod_status per sapere di quante risorse effettivamente hai
bisogno.
Riduci anche brutalmente il tempo di keepalive (o elimina i keepalive).
Non è *sicuramente* un syn flood.


 Riduci anche brutalmente il tempo di keepalive (o elimina i keepalive).
Ecco, proprio ora ho notato una cosa strana.
Nella config KeepAlive è off, eppure mod status mi dice KeepAlive on.
Boh, adesso guardo cosa possa essere, solitamente è la prima cosa che
stacco su server molto trafficati.

 quanta memoria porta via ogni child?
Tra i 7 e i 15 MB, dipende da quali moduli di PHP hai abilitato.
 
Bye.



Non è corretto.
Devi aggiungerci la memoria che ogni script PHP va ad allocare ed
utilizzare.
C'è un parametro nel php.ini per limitarla a sua volta.
Dipende anche da come utilizzi PHP: cgi o modulo.


 Dipende anche da come utilizzi PHP: cgi o modulo.
Modulo.
Comunque, ora su un server ho messo:
     StartServers          5
     ServerLimit           100
     MinSpareServers       5
     MaxSpareServers       10
     MaxClients            100
     MaxRequestsPerChild   100
     KeepAlive             off
     DOSHashTableSize 3097
     DOSPageCount 2
     DOSSiteCount 50
     DOSPageInterval 1
     DOSSiteInterval 1
     DOSBlockingPeriod 10
--
     Timeouts: connection: 60
     keep-alive: 60
     MPM Name: Prefork
     MPM Information: Max Daemons: 100 Threaded: no Forked: yes
     Server Architecture: 32-bit
--
Abbastanza scarichi, credo...
L'altro server č molto piů spinto come configurazione.
Se abasso i valori si notano dei rallentamenti.

 utilizzare.
Ma non viene usata sempre, viene allocata quando serve.
Io ho quel parametro impostato a 512 MB perche` mi serve in alcuni casi di 
elaborazione di immagini caricate, ma non e` che ogni processo di Apache 
occupa 527 MB, altrimenti sarei fregato...
Se lo usi come CGI o come modulo cambia relativamente poco. La memoria 
occupata e` la stessa, quella condivisa anche.
Puoi occupare meno se usi fastcgi o simili, e limiti il numero di processi 
php attivi, ma allora, visto che nel suo caso tutte le richieste sono PHP, 
il numero di processi apache attivi sara` limitato dal numero di processi 
php attivi, quindi si ricare nello stesso calcolo.
Visto quello che deve fare (servire ad), probabilmente togliendo quasi 
tutti i moduli da php e da apache, e lasciando solo quelli realmente 
utilizzati potrebbe riuscire a ridurre il peso di ogni "istanza" a 4-5 MB 
e quindi a tenere piu` processi attivi contemporaneamente.
Bye.

 e quindi a tenere piu` processi attivi contemporaneamente.
Ma neanche per sogno...
Metto 16GB di ram, non ho voglia di andare a ravanare nei
meandri dei moduli php....
:-)

 Comunque, ora su un server ho messo:
Aggiornaci, per curiosità, sugli sviluppi.


 Aggiornaci, per curiosità, sugli sviluppi.
Di sviluppo ne ho già uno:
mettendo 500 come limite massimo, per i primi 10 minuti il server è
stato
impallato. Solo la parte HTTP ovviamente perchè ha finito i child
disponibili ed
anche quelli forkabili.
Credo sia normale, tutte le volte che si riavvia apache i primi X
minuti è completamente
impallato, vuoi perchè deve avviare un corposo numero di figli, vuoi
perchè tutti si riversano
come una mandria all'attacco del povero server, ma sta di fatto che
ogni volta che faccio un
reload per alcuni minuti è come se il server fosse morto.
Attendo gli sviluppi di oggi pomeriggio, quando il traffico sarà a
regime.
Quello che però non mi spiego è come mai il server collassa solo in
ore notturne/mattutine quando
il traffico è inferiore (di molto) rispetto a quello pomeridiano. Se
fosse un sovraccarico, si verificherebbe
in condizioni di sovraccarico e non quando faccio mezzo megabit....
Per me c'è un pirla che mi vuol saturare le connessioni apache, ovvero
un ddos mirato che fa generare
più figli di quelli gestibili dal server a causa della mia errata
configurazione.
insomma, un duplice problema: dos con conseguente collasso (obiettivo
principale dei dos)

 in condizioni di sovraccarico e non quando faccio mezzo megabit....
Considera che de apache č impallato, di traffico ne fai pochino eh.
Quello che misuri non č proporzionale al numero di richieste come durante
il normale funzionamento.


 il normale funzionamento.
Mi son spiegato male.
Non dico che il traffico è poco quando apache è impallato, ma
apache si impalla quando c'è poco traffico.
Esempio:
ore 18.00: 5mbit di traffico, apache ok
ore 18.30: 3mbit di traffico, apache ok
ore 19.00: 1mbit di traffico, apache ok
ore 19.30: 0.3mbit di traffico, apache ok
ore 20.00: muore apache, traffico a 80mbit (impossibile, non ho
tale capacità di banda, è mrtg che da i numeri)
Quello che dico è che apache muore quando il traffico, mezzora o 1
ora prima era minimo. Se fosse solo un problema di risorse hardware
apache morirebbe a pieno carico, ovvero alle 18.00 non alle 20.00
Non so se rendo l'idea. In pratica, i 1000 child vengono utilizzati
quando faccio il massimo del traffico, non di certo quando ne faccio
praticamente 0. In tal caso dovrebbe essere tutti in idle o quasi.

 Mi son spiegato male.
Ho capito.
Un'altro consiglio:
prova a switchare da php come modulo a php wrappato da fastcgi (ed
eventualmente suexec).
Come aggiunta, non usare apache in modalità prefork ma usalo in modalità
threaded.
A partire ci mette sicuramente di meno e sulle mie installazioni mi da
performance migliori rispetto al php come modulo.
Controindicazione: il setup non è banalissimo


 Controindicazione: il setup non è banalissimo
Preferisco evitare di intervenire sul php.
Apache dovrebbe essere più facile.
(a breve ordino 8 o 16GB di ram, per cui il php non dovrebbe essere
problematico averlo in modulo)

 ricompilato apache...
usare apache con l'mpm dei thread è ottimo.
Usarlo con il PHP è sconsigliatissimo.
Fallo solo se usi php come (fast)cgi
Max
 

 Aggiornaci, per curiosità, sugli sviluppi.
Ad oggi sembra stabile....
Nessuno dei due server è collassato, per ora...