> Again, thank you very much for your advice and comments - they are very > well taken. > > I will clarify and say that the fbsd system I am using / talking about is > a _dedicated_ firewall. Only port 22 is open on it.
Ah, OK. That wasn't clear from your emails. > The problem is, I have a few hundred ipfw rules (there are over 200 > machines behind this firewall) and so when a DDoS attack comes, every > packet has to traverse those hundreds of rules - and so even though the > firewall is doing nothing other than filtering packets, the cpu gets all > used up. If you've created your rules well, then you should only have to traverse a couple of dozen at rules at most for the majority of packets. > I have definitely put rules at the very front of the ruleset to filter out > bad packets, and obvious attacks, but there is a new one devised literally > every day. Agreed, but establishing good rules and optimizing them helps to mitigate both current *and* future attacks. As an example of something that tends to help, adding rules that apply *ONLY* to the external (internet) interface helps out a ton. Otherwise, the packet has to traverse both rulesets (once as it passes the external interface, and again for the internal interface). This is but one *very* easily implemented rule that many do not realize. To be honest, I just recently implemented in my ruleset, having been made aware of it, despite the fact that my firewall is not CPU bound. A good idea is a good idea, and I strive to keep my firewall as optimized as I can, as long as I can maintain protection of my internal machines. On that matter, I've been following this and other threads, and are doing some 'research' into tightening up my firewall against the more common DOS/DDOS attacks. However, as Terry pointed out, for the most part there is little that can be done in a 'dedicated' attack if the attacker can fill up your pipe. Ultimately, all you can do is keep from responding to the attacker (thus causing needless/unecessary that is created at your end), or at least do things to slow the attacker down (in some case the attack relies on responses from your machines). The bottom line is that there's a good chance that *IF* your firewall is CPU bound under attack, your firewall ruleset could use some optimizing. In my experience, it's hard to wipe out a well configured firewall. Now, it is possible to saturate a network link, but generally it doesn't take out the firewall, but it certainly makes it difficult for 'valid' traffic to get through due to packet loss and other 'niceties' that typically occur in a saturated network. :( > So, you say that a poorly configured netscreen is no better than a poorly > configured freebsd+ipfw ... but what about the best possibly configured > netscreen vs. the best possibly configured freebsd+ipfw ? IMHO, they would perform similarly, depending on the hardware used on both appliances. Now, if you're firewall is a 386sx/15, and the netscreen has a P4-3.0Ghz CPU in it, their would certainly be a difference in performance. :) :) :) As far as the suggestion to use the FreeBSD box in bridging mode, I can't speak to that. My attempts to do so were less than successful, so I stuck with the more 'common' router/firewall combination. FWIW, I now have two firewalls in my rather 'puny' network. One is used to connect my 'DMZ' LAN to my ISP via a wireless link, which uses a *very* simple ruleset to ensure that only traffic destined for my network is passed in, and that traffic with a source address from my network is passed out. There are also some simply 'spoofing' rules in place, but the ruleset is less than 2-dozen rules. (Again, it's optimized by interface, so that packets only need to visit the rules once). This keeps a bunch of Windows/broadcast crap that lives on my ISP's network from cluttering up my firewall logs, and also sanitizes the traffic both to/from my network so that my firewall doesn't have to mess with it. On my 'real' firewall, I have a copy of these rules in place as well, but that's because paranoia runs deep, but these rules are rarely hit. I suspect I could do without the 'outer' firewall, but since it's got nothing else to do besides pass packets from one interface to the other, I figured it wouldn't hurt to give it *something* else to do. :) :) Nate To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
