Newsgroup: it.comp.os.linux.sys
Titolo: Aiuto per Synflood

Come blocco questo: ?
Conlimit unica strada ?
Grazie !
-------------------------------------
IPTABLES: SYN_flood: IN=eth0 OUT= 
MAC=00:22:19:d4:35:2f:00:0a:8a:74:28:80:08:00 SRC=74.50.74.87 
DST=xxx.xxx.xxx.xxx LEN=48 TOS=0x00 PREC=0x00 TTL=118 ID=766 DF 
PROTO=TCP SPT=1024 DPT=6000 WINDOW=8192 RES=0x00 SYN URGP=0 OPT 
(020405B401010402)
IPTABLES: SYN_flood: IN=eth0 OUT= 
MAC=00:22:19:d4:35:2f:00:0a:8a:74:28:80:08:00 SRC=119.65.1.124 
DST=xxx.xxx.xxx.xxx LEN=48 TOS=0x00 PREC=0x00 TTL=118 ID=766 DF 
PROTO=TCP SPT=1024 DPT=6000 WINDOW=8192 RES=0x00 SYN URGP=0 OPT 
(020405B401010402)
IPTABLES: SYN_flood: IN=eth0 OUT= 
MAC=00:22:19:d4:35:2f:00:0a:8a:74:28:80:08:00 SRC=116.109.158.92 
DST=xxx.xxx.xxx.xxx LEN=48 TOS=0x00 PREC=0x00 TTL=118 ID=766 DF 
PROTO=TCP SPT=1024 DPT=6000 WINDOW=8192 RES=0x00 SYN URGP=0 OPT 
(020405B401010402)
IPTABLES: SYN_flood: IN=eth0 OUT= 
MAC=00:22:19:d4:35:2f:00:0a:8a:74:28:80:08:00 SRC=123.53.88.91 
DST=xxx.xxx.xxx.xxx LEN=48 TOS=0x00 PREC=0x00 TTL=118 ID=766 DF 
PROTO=TCP SPT=1024 DPT=6000 WINDOW=8192 RES=0x00 SYN URGP=0 OPT 
(020405B401010402)
IPTABLES: SYN_flood: IN=eth0 OUT= 
MAC=00:22:19:d4:35:2f:00:0a:8a:74:28:80:08:00 SRC=55.184.242.10 
DST=xxx.xxx.xxx.xxx LEN=48 TOS=0x00 PREC=0x00 TTL=118 ID=766 DF 
PROTO=TCP SPT=3072 DPT=6000 WINDOW=8192 RES=0x00 SYN URGP=0 OPT 
(020405B401010402)
IPTABLES: SYN_flood: IN=eth0 OUT= 
MAC=00:22:19:d4:35:2f:00:0a:8a:74:28:80:08:00 SRC=87.246.233.28 
DST=xxx.xxx.xxx.xxx LEN=48 TOS=0x00 PREC=0x00 TTL=118 ID=766 DF 
PROTO=TCP SPT=3072 DPT=6000 WINDOW=8192 RES=0x00 SYN URGP=0 OPT 
(020405B401010402)
IPTABLES: SYN_flood: IN=eth0 OUT= 
MAC=00:22:19:d4:35:2f:00:0a:8a:74:28:80:08:00 SRC=192.212.253.16 
DST=xxx.xxx.xxx.xxx LEN=48 TOS=0x00 PREC=0x00 TTL=118 ID=766 DF 
PROTO=TCP SPT=3072 DPT=6000 WINDOW=8192 RES=0x00 SYN URGP=0 OPT 
(020405B401010402)
IPTABLES: SYN_flood: IN=eth0 OUT= 
MAC=00:22:19:d4:35:2f:00:0a:8a:74:28:80:08:00 SRC=183.141.70.125 
DST=xxx.xxx.xxx.xxx LEN=48 TOS=0x00 PREC=0x00 TTL=118 ID=766 DF 
PROTO=TCP SPT=3072 DPT=6000 WINDOW=8192 RES=0x00 SYN URGP=0 OPT 
(020405B401010402)
IPTABLES: SYN_flood: IN=eth0 OUT= 
MAC=00:22:19:d4:35:2f:00:0a:8a:74:28:80:08:00 SRC=96.208.155.58 
DST=xxx.xxx.xxx.xxx LEN=48 TOS=0x00 PREC=0x00 TTL=118 ID=766 DF 
PROTO=TCP SPT=3072 DPT=6000 WINDOW=8192 RES=0x00 SYN URGP=0 OPT 
(020405B401010402)
IPTABLES: SYN_flood: IN=eth0 OUT= 
MAC=00:22:19:d4:35:2f:00:0a:8a:74:28:80:08:00 SRC=98.64.147.68 
DST=xxx.xxx.xxx.xxx LEN=48 TOS=0x00 PREC=0x00 TTL=118 ID=766 DF 
PROTO=TCP SPT=1024 DPT=6000 WINDOW=8192 RES=0x00 SYN URGP=0 OPT 
(020405B401010402)
IPTABLES: SYN_flood: IN=eth0 OUT= 
MAC=00:22:19:d4:35:2f:00:0a:8a:74:28:80:08:00 SRC=61.185.209.30 
DST=xxx.xxx.xxx.xxx LEN=48 TOS=0x00 PREC=0x00 TTL=118 ID=766 DF 
PROTO=TCP SPT=1024 DPT=6000 WINDOW=8192 RES=0x00 SYN URGP=0 OPT 
(020405B401010402)
IPTABLES: SYN_flood: IN=eth0 OUT= 
MAC=00:22:19:d4:35:2f:00:0a:8a:74:28:80:08:00 SRC=81.61.250.27 
DST=xxx.xxx.xxx.xxx LEN=48 TOS=0x00 PREC=0x00 TTL=118 ID=766 DF 
PROTO=TCP SPT=1024 DPT=6000 WINDOW=8192 RES=0x00 SYN URGP=0 OPT 
(020405B401010402)
-----------------------------------------
			-- Yena --

 Conlimit unica strada ?
Dipende da cosa stai realmene vedendo...
Se gli IP son sempre diversi connlimit gli fa una mazza...
-- 
http://bofhskull.wordpress.com/

 Grazie !
Beh, le considerazioni fatte all'epoca non cambiano, dunque direi
di sì.
Come possibile workaround per questo caso specifico, visto che, dai log 
che posti, pare che il bastardo stia spoofando da una sola postazione, visto 
che i syn spoofati arrivano tutti con TTL=118, potresti impostare, come male 
minore, una regola di limit dei syn per i soli pacchetti con TTL 118...

 Se gli IP son sempre diversi connlimit gli fa una mazza...
Beh, limita comunque, in qualche modo.
Associando anche recent, anche se non ci ho mai provato, si potrebbero
ottenere risultati intressanti.

whiplash ha scritto:

E bloccargli il MAC ADDRESS ?
( Gli IP sono tutti spooffati )
		-- Yena --

 E bloccargli il MAC ADDRESS ?
Cioè segare tutto il traffico che arriva dal tuo router?
E' una via, certamente.
Abbastanza definitiva, ma pur sempre una via :-P
-- 
http://bofhskull.wordpress.com/

 ( Gli IP sono tutti spooffati )
Il MAC address che vedi è quello dell'ultimo router prima del tuo 
firewall (il vendor ID dice DELL). Corri il rischio di tagliarti fuori 
dalla rete.

 (020405B401010402)
[...]
Che cos'hai in ascolto sulla porta 6000? X?

 ( Gli IP sono tutti spooffati )
Quanti ip differenti hai rilevato?

whiplash ha scritto:

GIUSTO !
		-- Yena --

 Che cos'hai in ascolto sulla porta 6000? X?
Una chat
L'architettura ï¿œ:
Linux Centos5.3 che fa il firewall +
Vmware che fa girare un windows2003 con la chat.
Vmware ï¿œ nattato e protetto da Iptables dell' Host.
		-- Yena --

 
IP sempre diversi :-(
		-- Yena --

 Abbastanza definitiva, ma pur sempre una via :-P
/sbam!

Neoviruz ha scritto:

	:-)

 Grazie !
blocca per sport 1024 e 3072 se noti attacca solo da quelle due porte li

 IP sempre diversi :-(
Così potrebbe funzionare...
Combinazione di recent e connlimit, come accennavo.
Testato in INPUT, ma in FORWARD è uguale.
Setup sperimentale: sulla macchina bersaglio, metto un netcat in listening
sulla porta 6000.
Scrivo poi le seguenti regole:
iptables -N SYNFLOOD
iptables -A SYNFLOOD -j DROP
iptables -I INPUT -p tcp --dport 6000 --syn -m recent --update --seconds 60 --name synner -j SYNFLOOD
iptables -I INPUT 2 -p tcp --dport 6000 --syn -m connlimit  --connlimit-above 3 -m recent --name synner --set -j SYNFLOOD
Vediamo le catene in questa fase:
# iptables -vnL
 pkts bytes target     prot opt in     out     source               destination
    0     0 SYNFLOOD   tcp  --  *      *       
0.0.0.0/0
 
0.0.0.0/0
           tcp dpt:6000 flags:0x17/0x02 recent: UPDATE seconds: 60 name: synner side: source
    0     0 SYNFLOOD   tcp  --  *      *       
0.0.0.0/0
 
0.0.0.0/0
           tcp dpt:6000 flags:0x17/0x02 #conn/32 > 3 recent: SET name: synner side: source
Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination
Chain OUTPUT (policy ACCEPT 4065 packets, 393K bytes)
 pkts bytes target     prot opt in     out     source               destination
Chain SYNFLOOD (2 references)
 pkts bytes target     prot opt in     out     source               destination
    0     0 DROP       all  --  *      *       
0.0.0.0/0
 
0.0.0.0/0
Dalla macchina attaccante lancio una prima raffica di 4 syn spoofati
verso la macchina bersaglio, 
192.168.0.227
:
ni-vpn1:~# hping -S -p 6000 -I eth1 -a 100.1.30.135  -c 4 192.168.0.227
HPING 192.168.0.227 (eth1 192.168.0.227): S set, 40 headers + 0 data bytes
len=46 ip=192.168.0.227 ttl=64 DF id=0 sport=6000 flags=SA seq=0 win=5840 rtt=1.1 ms
len=46 ip=192.168.0.227 ttl=64 DF id=0 sport=6000 flags=SA seq=1 win=5840 rtt=0.5 ms
len=46 ip=192.168.0.227 ttl=64 DF id=0 sport=6000 flags=SA seq=2 win=5840 rtt=0.5 ms
DUP! len=46 ip=192.168.0.227 ttl=64 DF id=0 sport=6000 flags=SA seq=0 win=5840 rtt=4000.8 ms
--- 192.168.0.227 hping statistic ---
4 packets transmitted, 4 packets received, 0% packet loss
round-trip min/avg/max = 0.5/1000.7/4000.8 ms
In realtà il quarto pacchetto ricevuto è stato droppato e ciò che vede hping è
un DUP, ovvero un syn-ack relativo ad un syn precedente.
Vediamo l'ouput verboso di iptables a questo punto:
 pkts bytes target     prot opt in     out     source               destination
    0     0 SYNFLOOD   tcp  --  *      *       
0.0.0.0/0
 
0.0.0.0/0
           tcp dpt:6000 flags:0x17/0x02 recent: UPDATE seconds: 60 name: synner side: source
    1    40 SYNFLOOD   tcp  --  *      *       
0.0.0.0/0
 
0.0.0.0/0
           tcp dpt:6000 flags:0x17/0x02 #conn/32 > 3 recent: SET name: synner side: source
Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination
Chain OUTPUT (policy ACCEPT 4118 packets, 398K bytes)
 pkts bytes target     prot opt in     out     source               destination
Chain SYNFLOOD (2 references)
 pkts bytes target     prot opt in     out     source               destination
    1    40 DROP       all  --  *      *       
0.0.0.0/0
 
0.0.0.0/0
Il quarto syn spoofato ha "matchato" la seconda regola in INPUT ed è quindi finito
nella catena SYNFLOOD, dove è stato "droppato".
Via con un nuovo hping dunque:
ni-vpn1:~# hping -S -p 6000 -I eth1 -a 100.1.30.135 192.168.0.227
HPING 192.168.0.227 (eth1 192.168.0.227): S set, 40 headers + 0 data bytes
^C
--- 192.168.0.227 hping statistic ---
10 packets transmitted, 0 packets received, 100% packet loss
round-trip min/avg/max = 0.0/0.0/0.0 ms
E vediamo l'output di iptables:
Chain INPUT (policy ACCEPT 632 packets, 111K bytes)
 pkts bytes target     prot opt in     out     source               destination
    9   360 SYNFLOOD   tcp  --  *      *       
0.0.0.0/0
 
0.0.0.0/0
           tcp dpt:6000 flags:0x17/0x02 recent: UPDATE seconds: 60 name: synner side: source
    2    80 SYNFLOOD   tcp  --  *      *       
0.0.0.0/0
 
0.0.0.0/0
           tcp dpt:6000 flags:0x17/0x02 #conn/32 > 3 recent: SET name: synner side: source
Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination
Chain OUTPUT (policy ACCEPT 4140 packets, 401K bytes)
 pkts bytes target     prot opt in     out     source               destination
Chain SYNFLOOD (2 references)
 pkts bytes target     prot opt in     out     source               destination
   11   440 DROP       all  --  *      *       
0.0.0.0/0
 
0.0.0.0/0
Quando sarà trascorso un minuto, 100.1.30.135 riuscirà ad inviare nuovamente
tre syn, ma dopo questi ulteriori syn saranno nuovamente "droppati".
Mission accomplished, almeno in questo limitatissimo setup sperimentale.

Alex "M0rF3uS" Anghelone ha scritto:

Buona Idea .. provvedo !
		-- Yena --

 Mission accomplished, almeno in questo limitatissimo setup sperimentale.
Non c'è che dire, GRANDISSIMO! come al solito !!
			-- Yena --

 Non c'è che dire
In realtà, puoi scegliere di abbassare il connlimit-above a 1 o 2
(il 3 ti assicura maggiore tolleranza per client legittimi che siano
congestionati e che non ricevano il primo o il secondo syn-ack di
risposta dal server)o non usare affatto il connlimit ma il semplice 
limit sui syn, in  associazione con recent.
Facci sapere se funziona.

whiplash ha scritto:

OK vi tengo aggiornati, intanto posto questo, che penso
farà felice tanti affezzionati di Centos:
http://people.redhat.com/dzickus/el5/144.el5/x86_64/
E' il kernel con il modulo connlimit :-)
			-- Yena --

 iptables -I INPUT 2 -p tcp --dport 6000 --syn -m connlimit  --connlimit-above 3 -m recent --name synner --set -j SYNFLOOD
Tradotto:
1) se ho già 3 connessioni da un dato IP sulla mia porta 6000, a 
partire dal quarto *tentativo* di stabilire una nuova (--syn) 
connessione inserisci detto IP nella tabella synner e droppa
2) se l'IP che tenta di stabilire una nuova connessione (--syn) alla 
mia porta 6000 è presente nella tabella "synner" e sono passati meno 
di 60 secondi dal precedente tentativo di connessione da parte di 
detto IP, aggiorna detta tabella con il nuovo time stamp per quell'IP 
e droppa.
Mi sfugge come possa aiutare in caso di IP spoofati sempre variabili e 
in più, da quello che ricordo, connlimit computa (--connlimit-above) 
solo le connessioni established, per cui un syn flood puro dovrebbe 
bypassarlo anche in caso di IP fisso.

 bypassarlo anche in caso di IP fisso.
Ignora quanto sopra, per scrupolo ho guardato il sorgente e connlimit 
  conta tutto tranne le connessioni in stato "closed".

  conta tutto tranne le connessioni in stato "closed".
Per la precisione:
return conn->proto.tcp.state == TCP_CONNTRACK_TIME_WAIT ||
        conn->proto.tcp.state == TCP_CONNTRACK_CLOSE;

 Mission accomplished, almeno in questo limitatissimo setup sperimentale.
Testata la prima versione:
iptables -N SYNFLOOD
iptables -A SYNFLOOD -j DROP
iptables -I INPUT -p tcp --dport 6005 --syn -m recent --update --seconds 
60 --name synner -j SYNFLOOD
iptables -I INPUT 2 -p tcp --dport 6005 --syn -m connlimit 
--connlimit-above 3 -m recent --name synner --set -j SYNFLOOD
Nada .. mi sa che mi satura la banda .. ora ho attivato l'mrtg ..
			-- Yena --

 bypassarlo anche in caso di IP fisso.
No; in presenza di un syn-ack di risposta dal bersaglio, sei già
passato in ESTABLISHED.

 Nada .. mi sa che mi satura la banda
E questo potrebbe essere un altro aspetto...

 passato in ESTABLISHED.
Quanto sopra (i.e. "connlimit computa solo le connessioni 
established") è sbagliato, perché, come ho potuto verificare dai 
sorgenti del kernel, connlimit sembra ignorare solo gli stati 
TCP_CONNTRACK_TIME_WAIT e TCP_CONNTRACK_CLOSE (i.e. tutti gli altri 
sembrano valere ai fini del contatore di --connlimit-above).
Ciò detto, la connessione resta TCP_CONNTRACK_SYN_RECV fino a quando 
non arriva il primo ACK al server. Solo allora passa a 
TCP_CONNTRACK_ESTABLISHED.
Non che questo abbia rilevanza visto come funziona connlimit, ma è 
giusto per fare i precisini :)

 
La macchina Host è Linux Centos e fa da Firewall alla macchina Guest
Windows 2003 Srv che non è altro che una machcina virtualizzata
raggiungibile solo su alcune porte tramite il NAT di Vmware.
Quindi suppongo che in INPUT sia corretto .. o mi sbaglio ?
			-- Yena --

whiplash ha scritto:

  Ho letto quest'altro nella pagina man di iptables, che può contribuire a
salvare i client legittimi:
(modulo recent)
       --rttl This option  must  be  used  in  conjunction  with  one  of
              --rcheck or --update. When used, this will narrow the match
              to only happen when the address is in the list and the  TTL
              of  the current packet matches that of the packet which hit
              the --set rule. This may be useful  if  you  have  problems
              with people faking their source address in order to DoS you
              via this module by disallowing others access to  your  site
              by sending bogus packets to you.
  In effetti, tutti i pacchetti che ha documentato Yena hanno TTL=118.
  Ciao,
-- 
Alessandro Selli 
http://alessandro.route-add.net
AVVERTENZA: i messaggi inviati a "trappola" non mi arriveranno.
WARNING: messages sent to "trappola" will never reach me.
Chiave PGP/GPG: EC885A8B

 Quindi suppongo che in INPUT sia corretto .. o mi sbaglio ?
  In INPUT vanno a finire i pacchetti destinati ai socket /locali/.
Quelli destinati ad altri host della LAN vanno tutti in FORWARD senza
passare per INPUT.


 passare per INPUT.
Ok, però lui usa una macchina virtuale. Tutto dipende da come questa 
macchina virtuale è impostata.

lorenzodes ha scritto:

Queste sono le interfaccie,
volendo potrei impostare la Macchina guest con rete "host only"
e fare il NAT da iptables ...
ma nella mia conf. attuale il nat lo fa Vmware.
eth0      Link encap:Ethernet  HWaddr 00:22:19:D4:35:2F
           inet addr:xxx.xxx.xxx.xxx  Bcast:xxx.xxx.xxx.255 
Mask:255.255.255.0
           inet6 addr: fe80::222:19ff:fed4:352f/64 Scope:Link
           UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
           RX packets:14099350 errors:0 dropped:2004324 overruns:0 
frame:134399
           TX packets:11016452 errors:0 dropped:0 overruns:0 carrier:0
           collisions:0 txqueuelen:1000
           RX bytes:1012768026 (965.8 MiB)  TX bytes:712361107 (679.3 MiB)
           Interrupt:169 Memory:dfdf0000-dfe00000
lo        Link encap:Local Loopback
           inet addr:127.0.0.1  Mask:255.0.0.0
           inet6 addr: ::1/128 Scope:Host
           UP LOOPBACK RUNNING  MTU:16436  Metric:1
           RX packets:3628 errors:0 dropped:0 overruns:0 frame:0
           TX packets:3628 errors:0 dropped:0 overruns:0 carrier:0
           collisions:0 txqueuelen:0
           RX bytes:2033868 (1.9 MiB)  TX bytes:2033868 (1.9 MiB)
vmnet1    Link encap:Ethernet  HWaddr 00:50:56:C0:00:01
           inet addr:192.168.47.1  Bcast:192.168.47.255  Mask:255.255.255.0
           inet6 addr: fe80::250:56ff:fec0:1/64 Scope:Link
           UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
           RX packets:0 errors:0 dropped:0 overruns:0 frame:0
           TX packets:27 errors:0 dropped:0 overruns:0 carrier:0
           collisions:0 txqueuelen:1000
           RX bytes:0 (0.0 b)  TX bytes:0 (0.0 b)
vmnet8    Link encap:Ethernet  HWaddr 00:50:56:C0:00:08
           inet addr:172.16.188.1  Bcast:172.16.188.255  Mask:255.255.255.0
           inet6 addr: fe80::250:56ff:fec0:8/64 Scope:Link
           UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
           RX packets:72 errors:0 dropped:0 overruns:0 frame:0
           TX packets:30 errors:0 dropped:0 overruns:0 carrier:0
           collisions:0 txqueuelen:1000
           RX bytes:0 (0.0 b)  TX bytes:0 (0.0 b)
				-- Yena --

lorenzodes ha scritto:

iptables -N SYNFLOOD
iptables -A SYNFLOOD -j DROP
iptables -I FORWARD -p tcp --syn -j LOG --log-prefix "IPT:SYN_fl: 
"--log-ip-options --log-tcp-options
iptables -I FORWARD -p tcp --dport 6005 --syn -m recent --update 
--seconds 60 --name synner -j SYNFLOOD
iptables -I FORWARD 2 -p tcp --dport 6005 --syn -m connlimit 
--connlimit-above 2 -m recent --name synner --set -j SYNFLOOD
NON LOGGA, quindi suppongo sia corretta in INPUT
					-- Yena --

 NON LOGGA, quindi suppongo sia corretta in INPUT
Ma dove stai lavorando?
Sul gateway: FORWARD
Sul server: INPUT

 NON LOGGA, quindi suppongo sia corretta in INPUT
Domanda: come redirigi i pacchetti destinati alla port 6005 tcp
verso la macchina virtuale?
(confesso candidamente che di vmware server so poco e che ho sempre
usato configurazioni bridged).

 usato configurazioni bridged).
Da quello che so io di vmware (praticamente niente) il tutto funziona 
con un net filter driver di vmware attestato sull'ethX della macchina 
host.

 usato configurazioni bridged).
Li redirigo tramite il NAT di vmware. ( nat.conf )
Altro aggiornamento, ho aggiunto:
net.ipv4.conf.all.rp_filter = 1
in /etc/sysctl.conf
e sembra dare benefici ...
			-- Yena --

Peregrino "Pipino" Tuc ha scritto:

Sono la stessa cosa .. sono la macchina HOST di VMWARE.
			-- Yena --

 giusto per fare i precisini :)
Hai perfettamente ragione: lo stato è SYN_RECV ed è comunque quanto basta a connlimit:
# conntrack -L|grep 100.1
tcp      6 54 SYN_RECV src=100.1.30.31 dst=192.168.0.227 sport=1583 dport=6000 packets=1 bytes=40 src=192.168.0.227 dst=100.1.30.31 sport=6000 dport=1583 packets=2 bytes=88 mark=0 secmark=0 use=1
tcp      6 58 SYN_RECV src=100.1.30.31 dst=192.168.0.227 sport=1582 dport=6000 packets=1 bytes=40 src=192.168.0.227 dst=100.1.30.31 sport=6000 dport=1582 packets=3 bytes=132 mark=0 secmark=0 use=1

 Piuttosto che nulla, meglio piuttosto.
Da me si direbbe
"Miôr polente cence nuie che nuie cence polente".
IMHO rende di più l'idea... ;-)
-- 
http://bofhskull.wordpress.com/

 Hai perfettamente ragione: lo stato è SYN_RECV ed è comunque quanto basta a connlimit:
Giusto :)

 "Miôr polente cence nuie che nuie cence polente".
O anche:
"piuttost che nint le mej piuttost"
non so scrivere in dialetto.

 IMHO rende di più l'idea... ;-)
polente cence = polente scadenti?
e cence polente?

 combinazione di -m limit (non connlimit) e -m ttl.
Esempio:
=====================================================================
#limit non supporta invert (!), quindi occorre
#splittare la regola in due
iptables -I INPUT  -p tcp --dport 6000 --syn -m ttl --ttl-eq 118 -m 
limit --limit 1/sec  -j ACCEPT
iptables -I INPUT  -p tcp --dport 6000 --syn -m ttl --ttl-eq 118 -j DROP
======================================================================
Ovviamente quanto sopra rischia di tagliare fuori le connessioni 
legittime con quel ttl nell'ipotesi, probabile, che giungano nel 
momento sbagliato. Si potrebbe, in quel caso, ipotizzare una whitelist.

 polente cence = polente scadenti?
"Meglio polenta senza niente che niente senza polenta". Letterale.
-- 
http://bofhskull.wordpress.com/

lorenzodes ha scritto:

La testo !!
Grazie !!
			-- Yena --
 

 combinazione di -m limit (non connlimit) e -m ttl.
Sempre che al bastardo non venga in mente di "randomizzare" i ttl...<g>

 Sempre che al bastardo non venga in mente di "randomizzare" i ttl...<g>
Se è un po' sveglio e se il suo kit del piccolo achero glielo 
consente, lo farà certamente.

 "Meglio polenta senza niente che niente senza polenta". Letterale.
Ecco, ora è più comprensibile...

 SPT=1024 DPT=6000 WINDOW=8192 RES=0x00 SYN URGP=0 OPT (020405B401010402)
Mi accodo agli altri argomenti e/o suggerimenti letti nei vari reply.
C'e' anche sempre [IP] ID=766 e SPT=1024. E se abiliti il logging dei
numeri di sequenza magari trovi altri dati che potrebbero consentirti
di filtrare tutto il flood in ingresso. Valuterei di sposare la porta
da 6000 a qualcos'altro, cosi' liberi anche la banda dai tuoi SYNACK,
se non vuoi provare a filtrare tutto.
Fabio