[LARTC] syn flood protection - inside initiated attacks
Perhaps someone will help me on this :- I have read a lot of examples of syn flood protect on the INPUT chain. That I have no question at all. I wonder if it make sense to perform syn flood protection at the FORWARD chain ? If packets are originated from a LAN worm, and are not targetted at the firewall itself, but rather at hosts in the internet, will it cause problem with the firewall itself, such as iptables connection table full etc ? I tried to do it, to be specific, I tried this :- iptables -N lan-syn-flood iptables -A lan-syn-flood -m limit --limit 1/s --limit-burst 4 -j RETURN iptables -A lan-syn-flood -j DROP Hook it to FORWARD chain, iptables -I FORWARD -p tcp --syn -j lan-syn-flood But this will result in denial of service of a lot of legitimate traffic. I try to increate the limits to bigger values it still does not work, primarily my firewall is also doubling as a router across subnet and there are a lot of traffic. Any advise or comments ? ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] syn flood protection - inside initiated attacks
IMO, you have to --limit for each of the computer separately (1 chain for each IP address), otherwise you will block both the instruder and the legitimate users. Perhaps the better solution is to install an IDS and completely block instruder, wait until he/she contacts you and ask for worm removal before removing the blockage. Ming-Ching Tiew wrote: Perhaps someone will help me on this :- I have read a lot of examples of syn flood protect on the INPUT chain. That I have no question at all. I wonder if it make sense to perform syn flood protection at the FORWARD chain ? If packets are originated from a LAN worm, and are not targetted at the firewall itself, but rather at hosts in the internet, will it cause problem with the firewall itself, such as iptables connection table full etc ? I tried to do it, to be specific, I tried this :- iptables -N lan-syn-flood iptables -A lan-syn-flood -m limit --limit 1/s --limit-burst 4 -j RETURN iptables -A lan-syn-flood -j DROP Hook it to FORWARD chain, iptables -I FORWARD -p tcp --syn -j lan-syn-flood But this will result in denial of service of a lot of legitimate traffic. I try to increate the limits to bigger values it still does not work, primarily my firewall is also doubling as a router across subnet and there are a lot of traffic. Any advise or comments ? ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
[LARTC] limiting bandwidth on iface
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi there!
Well, as an exercise, I try 'simulating' an adsl link (just the speed ;o))
with a GRE tunnel and HTB for bandwidth limiting. Typically in germany
adsl has about 1024kbit downstream and 128kbits upstream (yes, there are
others ;) but these are what I have) - which are the values i try to simulate.
Here is the snipped that does the real thing on the client-side:
- -snip-
~ 23 # now setup shaping to dsl-like-speed (up:128, down:1024 - this \
~is the dsl-client)
~ 24 $tc qdisc del dev $tun root - 2-
~ 25 $tc qdisc add dev $tun root handle 1: htb
~ 26
~ 27 # shapiung class of root -- not more than 1mbit bandwidth
~ 28 $tc class add dev $tun parent 1: classid 1:1 htb rate 1mbit \
~burst 0 cburst 128
~ 29
~ 30 # this is for downstream
~ 31 $tc class add dev $tun parent 1:1 classid 1:10 htb rate 1mbit
~ 32 # this does upstream
~ 33 $tc class add dev $tun parent 1:1 classid 1:20 htb rate \
~128kbit burst 0 cburst 128
~ 34
~ 35 # add fairness queues for up- and downstream classes
~ 36 $tc qdisc add dev $tun parent 1:10 handle 10: sfq perturb 5
~ 37 $tc qdisc add dev $tun parent 1:20 handle 20: sfq perturb 5
~ 38
~ 39 # now take care of what is up- and what ist down-steam
~ 40 U32=$tc filter add dev $tun protocol ip parent 1:0 prio 1 u32
~ 41 # everything that is from me is upstream
~ 42 $U32 match ip src $tunip flowid 1:20
~ 43 # everthing that comes to me is downstream
~ 44 $U32 match ip dst $tunip flowid 1:10
- -snap-
eplanations:
$tunip is the ip of this end of the tunnel
$tc = tc
OK, I tryied this setup and noticed that approximately every 60 seconds,
the bandwidth gues up to about 256kbits for about 3 seconds - I have no
explanation for this - well, I do not really know what to set as parameter
for burst/cburst...
Any ideas, grave mistakes?
thanks a lot,
Marcus Fritzsch
- --
~ s(c,t){return isalpha(c)t?/*
Marcus Fritzsch [EMAIL PROTECTED] ICQ:53118621 WWW:fritschy.de
~ GnuPG: gpg --keyserver sks.keyserver.penguin.de --recv-keys 98A1D365
*/s(65-c97-c?--c:c+25,--t):c;}main(){for(;;)putchar(s(getchar(),13));}
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.0 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFCQXAM8lT6s5ih02URAha4AKCqbcvh8h4OqqaLKiKv806SsqdHrACgg8iw
kFyUksrkfYe+QQ4nKILAEKo=
=voOh
-END PGP SIGNATURE-
___
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] limiting bandwidth on iface
Marcus, I'm a little confused. Downstream is 1mbit and upstream is 128kbit but the root limit in your code is 1mbit. Surely this could be the cause of your problem? Regards Brian On 23 Mar 2005 at 14:33, Marcus Fritzsch wrote: ~ 27 # shapiung class of root -- not more than 1mbit bandwidth ~ 28 $tc class add dev $tun parent 1: classid 1:1 htb rate 1mbit \ ~ burst 0 cburst 128 ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
[LARTC] tc + zebra/quagga
I have some problem with traffic shaping on debian testing. I actually posted a full config on the list a while ago but didn't get any answers. The problem is that traffic doesn't get into the user classes (~150) when I associate a class with a qdisc. I tried sfq, fifo but none works. If I dont't associate a qdisc with a class classification occurs well. I'm pretty sure the config is ok. Just was wondering if someone has already steped into this one. This box runs zebra and bgpd as it is a bgp border router. I found this post on google which is quite similar to my case: http://mailman.isi.edu/pipermail/6bone/2002-May/005420.html. Thank you. -- + Lorin + I tought I taw a putty cat...I did! I did taw a putty cat! + http://si-bemol.ro ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
[LARTC] Suspicious Attachment
-- Warning: Message delivery wasn't performed. Reason: Our virus scanner detected very suspicious code in the attachment of a mail addressed to a user of our system. The following message will not be delivered: From: [EMAIL PROTECTED] To: LARTC@mailman.ds9a.nl Subj: [LARTC] Re: Date: Thu, 24 Mar 2005 00:49:35 +0530 Virus: Worm.Bagle.AG.2 Feel free to contact no_one if you can't cope with it. -- This mail was automatically generated by TrashScan v0.12 ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
