Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 16 Jan 2003 14:04:30 -0700
From:      Nate Williams <nate@yogotech.com>
To:        Josh Brooks <user@mail.econolodgetulsa.com>
Cc:        Sean Chittenden <sean@chittenden.org>, freebsd-hackers@freebsd.org, <nate@yogotech.com>
Subject:   Re: FreeBSD firewall for high profile hosts - waste of time ?
Message-ID:  <15911.7774.98861.58086@emerger.yogotech.com>
In-Reply-To: <20030116124254.J9642-100000@mail.econolodgetulsa.com>
References:  <20030116203739.GA34165@perrin.int.nxad.com> <20030116124254.J9642-100000@mail.econolodgetulsa.com>

next in thread | previous in thread | raw e-mail | index | archive | help
> 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 majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?15911.7774.98861.58086>