> You don't want to stick the 'block abnormal packets' rules at the top of > the list, IMO. You want those at the end, since abnormal packets are > *usually* the exception. Optimize for the standard case.
Wow - that is _very interesting_ that you say this. We were having a similar discussion on -network a few days back where the consensus was the exact opposite - and based on that I have actually stuck my 10-15 deny rules at the very front of my ruleset. Things like: deny tcp from any to any tcpflags syn tcpoptions !mss deny tcp from any to any tcpflags syn,rst deny tcp from any to any tcpflags fin,syn,rst,psh,ack and so on. The thinking is this (and you may find this interesting): During normal traffic, yes, there are now 5 extra rules that every single packet has to go through in addition to whatever other portion of the ruleset they would have to go through. But, in normal traffic - even if the bandwidth is getting up to 8-12 megabits/s, the packets/s rate is still fairly low, and thus the firewall is not taxed. However, in an attack, the bandwidth might go as high as double normal situations BUT the packets/s can climb as high as 100 times the rate you normally see. So now you have 100x normal packets/s going through 200 rules to get to the special case deny rules (like the ones above). Therefore, by putting the special case deny rules at the very beginning, yes you add a very small amount of extra work for normal traffic, but you imporve your situation _dramatically_ in the case of suddenly ramping up to 12,000 packets/s of SYN flood ... and by kicking these out immediately at the top of the ruleset you at least buy yourself some time. My problem is that every time I add a new rule to the top, a new kind of attack is used, and gets through just fine - so I have 12K packets/s coming through all 300 rules of mine no matter what I put in :) thanks again for your help and comments. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
