On Thu, 30 Nov 2000, Rusty Russell wrote: > Connection tracking fails to track them, then the NAT code drops them > before traversing the NAT table. > > You could drop them in mangle, but there's little point. ... > NAT occurs before routing, and rp_filter is part of routing. Does that imply I can drop just about everything in mangle? (... with relatively high cost as all the packets go through these rules?) > > > Note that filtering packet floods makes no sense unless your bandwidth > > > behind the box is < the bandwidth in front. > > > > Well packet floods tend to flood the connection tracking tables too. > > Sure, it'll start discarding things, but that's OK, as long as it > discards the right ones. Are you having trouble getting real > connections in/out? Not really having problems with them yet; nobody has tried to DoS me ;) Has anyone actually tested how ip_conntrack handles things like 10+ different port scans flooding both the internal & external interfaces simultaneously? And whether useful packets start to get dropped as untracked because of that? But I'm trying to get rid of potential problems & log floods like the following: Nov 7 15:34:14 bx5 kernel: NAT: 3 dropping untracked packet c19652e0 6 127.0.0.1 -> 10.1.16.5 Nov 7 15:34:19 bx5 kernel: NET: 651 messages suppressed. Nov 7 19:29:59 bx5 kernel: NAT: 0 dropping untracked packet c39f3800 6 128.214.xxx.48 -> 130.233.xxx.25 Nov 7 19:29:59 bx5 last message repeated 8 times Nov 7 19:30:05 bx5 kernel: NAT: 0 dropping untracked packet c59b85c0 6 128.214.xxx.48 -> 130.233.xxx.25 Nov 7 19:30:11 bx5 kernel: NET: 9 messages suppressed. Nov 7 20:28:37 bx5 kernel: NAT: 3 dropping untracked packet c5e0ad80 6 130.233.xxx.91 -> 128.214.xxx.48 Nov 7 20:18:22 bx5 kernel: NAT: 0 dropping untracked packet c5da8e00 1 202.0.xxx.2 -> 130.233.xxx.50 Nov 7 20:18:23 bx5 last message repeated 5 times Nov 7 20:18:25 bx5 kernel: NET: 18 messages suppressed. Now in an "ideal" world the logs would get something funny like: Dec 24 00:00:00 foo kernel: ddos_start: IN=ippp0 OUT= MAC= SRC=24.68.xxx.3 DST=130.233.xxx.25 LEN=40 TOS=0x00 PREC=0x00 TTL=34 ID=53013 PROTO=TCP SPT=60349 DPT=1402 WINDOW=3072 RES=0x00 FIN URGP=0 Dec 24 00:00:00 foo ddoslogger: dDoS FIN-scan hosts detected: ... Dec 24 00:10:00 foo ddoslogger: dDoS src addresses & (adaptive) type flags: ... Dec 24 06:42:00 foo ddoslogger: silence detected - 5142 source addresses and 24+6 flooding methods logged since Dec 24 00:00:00. (well dDoS logger should prolly attempt to detect address patterns too;) What I'm trying to say is that "NET: 651 messages suppressed." is not exactly good as some of those 651 messages could actually be useful... - : send the line "unsubscribe linux-net" in the body of a message to majordomo@vger.kernel.org
