(22-01-2012, 10:10 AM)[GF]Acqua Wrote: [ -> ] (22-01-2012, 07:51 AM)Th3k1nG Wrote: [ -> ]Nel caso si ripetessero gli attacchi provate a fare cosi :
netstat -nat | awk '{print $6}' | sort | uniq -c | sort –n
Usare questo comando dalla machine per identificare gli ip in ascolto
L’output sarà qualcosa del genere:
1 CLOSING
1 established)
1 Foreign
5 LAST_ACK
15 FIN_WAIT1
16 LISTEN
59 FIN_WAIT2
424 TIME_WAIT
442 ESTABLISHED
Le diverse connessione al SYS_SENT indicano che siete sotto attacco , per individuare l'ip che sta lamerando basta fare cosi
netstat -atun | awk '{print $5}' | cut -d: -f1 | sed -e '/^$/d' |sort | uniq -c | sort –n
Per bloccare questi IP da itptables potete usare questo semplice comando:
iptables -A INPUT -s IP-ATTACCANTE -j DROP
Quindi se l’indirizzo IP dell’attacante fosse 123.234.80.65 il commando da dare sarebbe:
iptables -A INPUT -s 123.234.80.65 -j DROP
Poi rendiamo le modifiche effettive
netstat -nr
e verifichiamo che siano stati bloccati.
Le iptables sono per linux non freebsd, gli ip sono centinaia (e hanno un range non definibile), già li so, così come so la porta e la tipologia del protocollo utilizzato per il trasferimento dei pacchetti.
Questo genere di problema non può essere risolto lavorando sul firewall (iptables o ipfw)
Si hai ragione....allora l'unica cosa che mi viene in mente è recuperare i log e i backup e reinstallarli D:
(22-01-2012, 11:53 AM)Th3k1nG Wrote: [ -> ] (22-01-2012, 10:10 AM)[GF]Acqua Wrote: [ -> ] (22-01-2012, 07:51 AM)Th3k1nG Wrote: [ -> ]Nel caso si ripetessero gli attacchi provate a fare cosi :
netstat -nat | awk '{print $6}' | sort | uniq -c | sort –n
Usare questo comando dalla machine per identificare gli ip in ascolto
L’output sarà qualcosa del genere:
1 CLOSING
1 established)
1 Foreign
5 LAST_ACK
15 FIN_WAIT1
16 LISTEN
59 FIN_WAIT2
424 TIME_WAIT
442 ESTABLISHED
Le diverse connessione al SYS_SENT indicano che siete sotto attacco , per individuare l'ip che sta lamerando basta fare cosi
netstat -atun | awk '{print $5}' | cut -d: -f1 | sed -e '/^$/d' |sort | uniq -c | sort –n
Per bloccare questi IP da itptables potete usare questo semplice comando:
iptables -A INPUT -s IP-ATTACCANTE -j DROP
Quindi se l’indirizzo IP dell’attacante fosse 123.234.80.65 il commando da dare sarebbe:
iptables -A INPUT -s 123.234.80.65 -j DROP
Poi rendiamo le modifiche effettive
netstat -nr
e verifichiamo che siano stati bloccati.
Le iptables sono per linux non freebsd, gli ip sono centinaia (e hanno un range non definibile), già li so, così come so la porta e la tipologia del protocollo utilizzato per il trasferimento dei pacchetti.
Questo genere di problema non può essere risolto lavorando sul firewall (iptables o ipfw)
Si hai ragione....allora l'unica cosa che mi viene in mente è recuperare i log e i backup e reinstallarli D:
Inutile anche questo. Il problema è di consumo di banda non di file di gioco o database.
Acqua ma hai sistemato? Fa loggare!
(22-01-2012, 12:02 PM)[GF]Acqua Wrote: [ -> ] (22-01-2012, 11:53 AM)Th3k1nG Wrote: [ -> ] (22-01-2012, 10:10 AM)[GF]Acqua Wrote: [ -> ] (22-01-2012, 07:51 AM)Th3k1nG Wrote: [ -> ]Nel caso si ripetessero gli attacchi provate a fare cosi :
netstat -nat | awk '{print $6}' | sort | uniq -c | sort –n
Usare questo comando dalla machine per identificare gli ip in ascolto
L’output sarà qualcosa del genere:
1 CLOSING
1 established)
1 Foreign
5 LAST_ACK
15 FIN_WAIT1
16 LISTEN
59 FIN_WAIT2
424 TIME_WAIT
442 ESTABLISHED
Le diverse connessione al SYS_SENT indicano che siete sotto attacco , per individuare l'ip che sta lamerando basta fare cosi
netstat -atun | awk '{print $5}' | cut -d: -f1 | sed -e '/^$/d' |sort | uniq -c | sort –n
Per bloccare questi IP da itptables potete usare questo semplice comando:
iptables -A INPUT -s IP-ATTACCANTE -j DROP
Quindi se l’indirizzo IP dell’attacante fosse 123.234.80.65 il commando da dare sarebbe:
iptables -A INPUT -s 123.234.80.65 -j DROP
Poi rendiamo le modifiche effettive
netstat -nr
e verifichiamo che siano stati bloccati.
Le iptables sono per linux non freebsd, gli ip sono centinaia (e hanno un range non definibile), già li so, così come so la porta e la tipologia del protocollo utilizzato per il trasferimento dei pacchetti.
Questo genere di problema non può essere risolto lavorando sul firewall (iptables o ipfw)
Si hai ragione....allora l'unica cosa che mi viene in mente è recuperare i log e i backup e reinstallarli D:
Inutile anche questo. Il problema è di consumo di banda non di file di gioco o database.
Ma se sono problemi di consumo di banda basta configurare il firewall che protegge il server in modo che non permetta il transito dei pacchetti ICMP in ingresso o sbaglio?
Se non è questo non so cosa dirti perchè non ho il problema davanti.
Sti lameroni fanno salire i nervi...
Con il firewall non si fà niente...
Comunque per il momento il problema sembra mitigato..
Perfetto xD...l'hacker la domenica va dai parenti xD
allora non è del tutto un forever alone il nostro hacker
sto facendo le missioni e te vega?
Ascolto la musica e parlo Cn il cell Cn Kibaz
