> > 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):
I watched that discussion, but I don't remember folks saying that the rules should go at the top. Apparently I didn't play close enough attention. :( > 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. Yep, you dump things as quick as possible. > 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 :) It may be time to look at things differently. Rather than trying to generate a rule for every attack, it may be time to start thinking about only allowing 'valid' packets through. I know this is a bit harder than it may sound, but you may be suprised to find that it works. Kind of like how the people who look for counterfeits do. Rather than spend their time trying to find a counterfeit, they analyze what a 'good' bill is, so that when a counterfeit arrives, it's immediately obvious. Again, this may be beyond what ipfw can do today, but it's certainly something to think about. At this point, without more details to what your rules look like, I'm still of the opinion that it can be optimized to handle the higher loads. Nate To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
