Re: Host based vs network firewall in datacenter

[Alin-Adrian Anton <aanton () spintech ro>]

sin wrote:
> 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
> > insane.
>
>
> 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
> > die).
>
>
> 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 
provide auto-reboot).

> > 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.

Great.

> > I would not chose a linux based solution for firewalling high loads of
> > evil traffic.
>
>
> 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
> > interface.
> >
> > 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.

Regards,
--
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
firewall-wizards () honor icsalabs com
http://honor.icsalabs.com/mailman/listinfo/firewall-wizards