Nate, So you are saying that if I put in:
ipfw add 00001 deny tcp from any to 10.10.10.10 6667 That an incoming packet for 10.10.10.10 on port 6667 will go through the rule set _twice_ (once for each interface) ? I don't understand this - if it comes in on the external and hits that rule, it is immediately dropped - at what time does it then traverse the rules for the internal NIC ? Or are you saying that rules I have in place that _allow_ traffic should have their _allowance_ apply to the external, because then they pass through the firewall without ever checking the ruleset for the internal interface they have to pass through ? ----- Also, if you don't mind, could you post your paranoia rules: > 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). Thanks! On Thu, 16 Jan 2003, Nate Williams wrote: > > 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
