В Пнд, 27/04/2009 в 16:00 -0700, samsonpablo@xxxxxxxxx пишет: > i'm using a linux host as a router to perform some security testing. The testing is typically towards tcp based services. Currently the router is setup like this, with my test traffic coming into the box on eth0, exiting on eth1: > > eth0 192.168.1.1/30 > eth1 10.1.0.1/23 > > Due to policy from a networking group, I need to ensure that the number of established connections during my testing never exceeds 20 connections thru other devices that i may traverse beyond my linux router. I'm not as concerned with bandwidth as i am with state tables on downstream devices i have no control over. It seems to me that this could be accomplished if i can ensure that established connections from eth1 do not exceed 20 connections. > > So, after a really quick peek at iptables(8) i came up with: > > iptables -A OUTPUT -o eth1 -p tcp -m connlimit --connlimit-above 20 -j LOG --log-prefix "rl-queue: " > iptables -A OUTPUT -o eth1 -p tcp -m connlimit --connlimit-above 20 -j QUEUE > > and maybe better using --syn: > > iptables -A OUTPUT -o eth1 -p tcp --syn -m connlimit --connlimit-above 20 -j LOG --log-prefix "rl-queue: " > iptables -A OUTPUT -o eth1 -p tcp --syn -m connlimit --connlimit-above 20 -j QUEUE > > This definitely seems to be limiting traffic, but i'm not really sure if it's what i'm after and if the QUEUE target is working like i think it is (probably not). I guess my questions are: > > - does anyone have any suggestions on rules that will help me limit the number of connections outbound > > - can the QUEUE target act as a fifo queue, or is it entirely dependent on something in userspace to queue the packets up and send them back to iptables when the rate limiting numbers have dropped below the threshold? -j QUEUE target queues packet to be reviewed by a userspace program which then may filter some out and accept others by setting a verdict. This achieves effect like "-j ACCEPT" or "-j DROP" set from userspace. Other useful tasks may be done like accounting. -j QUEUE ensures that packet won't go further until userspace verdict is set. It also has buffer to collect packets to be reviewed by userspace, and when it is full packets get dropped. > I'm really concerned with the queuing aspect because i don't want potentially important packets from a portscan to get dropped on my side and an open port go undetected. I don't know any way in which this could be done. Thing is that connections are something which can live for a long time and even if there would be a way to queue/pause new connection until the quota is available the delay in many cases would cause client side to timeout. Also, it's probably not that bad idea to drop new connection attemps when there is no quota as those are being retried several times. P.S. In your case -j QUEUE is useless, it really does -j DROP with a delay due to buffer. -- Покотиленко Костик <casper@xxxxxxxxxxxx> -- To unsubscribe from this list: send the line "unsubscribe netfilter" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
