Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 16 Jan 2003 15:41:23 -0800 (PST)
From:      Josh Brooks <user@mail.econolodgetulsa.com>
To:        Terry Lambert <tlambert2@mindspring.com>
Cc:        Nate Williams <nate@yogotech.com>, Sean Chittenden <sean@chittenden.org>, <freebsd-hackers@freebsd.org>
Subject:   Re: FreeBSD firewall for high profile hosts - waste of time ?
Message-ID:  <20030116153711.W38599-100000@mail.econolodgetulsa.com>
In-Reply-To: <3E274081.F2D2F873@mindspring.com>

next in thread | previous in thread | raw e-mail | index | archive | help

> In any case, he's got something else strange going on, because
> his load under attack, according to his numbers, never gets above
> the load you'd expect on 10Mbit old-style ethernet, so he's got
> something screwed up; probably, he has a loop in his rules, and
> a packet gets trapped and reprocessed over and over again (a
> friend of mine had this problem back in early December).

You are correct that the network load is very low (less than 10 megabits/s
when getting attacked) but if the packets/s is extremely high .. isn't it
expected if some extremely large number of packets per second traverses
2-300 properly constructed rules that the CPU is going to choke ?

When I say "properly constructed" I just mean there is nothing blatantly
wrong, like a rule loop - obviously the _efficiency_ of the ruleset could
always be improved.

My main question is, given that I get attacked a lot in a lot of different
ways, am I wasting my time trying to find that greater efficienct ?  That
is, will freebsd+ipfw always be worse in a ~10 meg/s throughput network
that gets attacked all the time than a purpose-built appliance like a
netscreen ?

I would sure like to stick with a freebsd firewall...so much nicer to use,
and with all the unix tools right there...




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?20030116153711.W38599-100000>