Re: [fw-wiz] Host based vs network firewall in datacenter
From: Alin-Adrian Anton (aanton_at_spintech.ro)
To: sin <email@example.com> Date: Sun, 03 Jul 2005 02:36:59 +0300
> Alin-Adrian Anton wrote:
>>No matter what kind of network you have, you need at least one firewall
>>at the border with the Internet.
>>Having a datacenter without a fast firewall at the border, is simply
> in fast firewall i presume you mean basic ACLs to filter much of the
> junk traffic, no ?
Fast firewall is fast firewall. The minimum requirement would be with
basic ACLs to filter junk traffic. If the circumstances can offer
better, the better the better.
>>The machine at the border can be some expensive hardware, like a cisco,
>>or can be a powerful BSD-based packet filter, sitting on powerful
>>hardware (the best you can get, Intel based).
> It can also be run on commodity hardware; expensive hardware it's not
> always gonna give you uber performance over cheaper hardware.
Correct. By all means, I've seen many second-hand brands doing a great
job for years without interruption. Powerful hardware doesn't necessarly
mean it has to be uber expensive ;). It just has to be decently
powerful, depending on loads, complexity of ACL, other needs, etc.
>>If you chose cisco-like solution, chose an expensive one. You defenately
>>need it (because expensive ones can handle smarter ACLs and keep state
>>much better, and also can resist to DDoS over 100 Mbps. Cheap ones may
> every router dies because of DDOS if some part of that traffic is not
> filtered upstream, and by dieing i mean that you have a big chance
> running out of bandwidth before you run out of vip cpu power.
By dieing I mean literally provide malfunction and require a reboot (or
>>If you chose BSD solution use ipfw (fastest), or pf (best in terms of
>>what it can do). Pf on FreeBSD with Intel "FXP" cards is able to use the
>>hardware chip for checking CRC of the packets. This feature is only
>>available on FreeBSD, and as far as I know nobody ported it to other OS.
>>Having hardware to check for checksums greatly improves performance,
>>even over ipfw.
> Intel's Linux drivers also offer the same facility.
>>I would not chose a linux based solution for firewalling high loads of
> can you also give some arguments why not ?
From my past experience, I've managed BSD much better. I don't want to
get into OS war, I'm not a holly knight. It's just my opinion, and
providing solid arguments would turn into a different thread, named "BSD
vs Linux" or viceversa.
Anyway iptables seems much buggier than BSD firewalls, and defenately it
is slower. However I never did benchmarks for such things.
>>Even better, if you can afford it, you can have both: the cisco and the
>>BSD, cisco sitting maybe in front of the BSD. This way you also keep a
>>simple and good control of what goes in and what goes out, and you can
>>cut down packets which the hardware firewall missed (it happens).
> firewalls just don't miss packets. they allow them to pass based on
> certain rules. maybe some software bugs can cause some unwanted packets
> to pass on certain situations.
I was reffering to a past situation when the DDOS contained random junk
with random valid protocols. This ment some of the junk went through the
ACL. (over 200 Mbps)
>>In case of a serious DDoS problem, you can even enable statefull ACL
>>version (keep it somewhere) on the BSD box, to really cut down whatever
>>the hardware firewall skips into the internal network.
> i believe you might want to do exactly the opposite, disabling any
> statefull ACLs on the router (you know, a 7500 cisco router can get
> pretty busy processing a high rate of small packets without any ACLs
> defined on a particular interface). adding statefull ACL's can have
> negative impact on the router performance in case of DoS/DDoS attack.
Depends on the situation. If your hardware is powerful enough, statefull
ACLs can take out the junk from the internal network way much better,
and prevent the situation of random junk traffic skipping inside the
network. A preset ACL for that (for example allow just HTTP/etc and
outgoing connections from within the internal network to outside) can
help. In order to allow outgoing connections you need statefull mechanisms.
I mean just how fast can the DDOS go? It can go as fast as your
bandwidth is allowed by your ISP. How much is that? 100 Mbps? 1 Gbps?
It's not hard to work with 100 Mbps stateful filter (on BSD and decent
hardware). For 1 Gbps you can use a multiprocessor or a firewall cluster
(PF on BSD with CARP for instance).
And that statefull firewall is going to be used only in rare situations,
like a DDOS. It won't help too much in cases of intrusion, but IDS can
be added (like an isolated SNORT machine logging and providing output).
I do 50-60 Mbps statefull inspection with PF (at home) on a P2 266 Mhz
second-hand Dell, without using Intel-based CRC check.
For real enviroments one needs write-back caches and fast RAM. And as
much as possible by budget/hardware slots.
>>On the inside land, it may be a very good idea to use any kind of
>>firewall you want on each machine, in order to limit access to SNMP (if
>>you are going to monitor them via SNMP), and so on. You should use a
>>different switch for the monitoring connection, such that an internal
>>server cannot impersonate you in any way (arp, ISN prediction, etc).
> It can get quite expensive doing out of band management on a fairly big
> network, and also somewhat complex.
Complex yes, too complex not (no need to shoot in the foot). Expensive,
no I don't think so. Just some basic local ACLs on the existing
hardware, at minimum.
>>Limit all services to what they really need to accept, and nothing else.
>>If they are not going to use the LAN, always bind them on the local
>>Each host inside the lan should not trust anyone from the LAN, so
>>writing down what is strictly needed for each of them is a good thing.
>>Implementing it is the next step, I just pointed some ideas.
> it will have to trust another host by some degree...
Sure. But better is *much* better, otherwise just unplug the cables. I
know making it harder makes the difference. Maybe somebody knows a bug
in SNMP but doesn't know in SMTP. Fortunately he/she can't access the
SNMP, but he/she can connect to SMTP. Etc.. It minimizes the probability
that "the right person" will say hello from within the LAN.
-- Alin-Adrian Anton GPG keyID 0x183087BA (B129 E8F4 7B34 15A9 0785 2F7C 5823 ABA0 1830 87BA) gpg --keyserver pgp.mit.edu --recv-keys 0x183087BA "It is dangerous to be right when the government is wrong." - Voltaire _______________________________________________ firewall-wizards mailing list firstname.lastname@example.org http://honor.icsalabs.com/mailman/listinfo/firewall-wizards