Re: Inspecting routers

[Lorens Kockum <firewall-wizards-20021015 () tagged lorens org>]

On Mon, Nov 25, 2002 at 09:45:01AM +0100, Pierre-Yves wrote:
>    There are _no_ outgoing connexions from the internal network to the
> Internet through those links (those connexions go to another ISP and
> route). The only trafic crossing the internal access router will be
> administration traffic (internal to web systems) and data requests (web
> systems to internal databases).

Nice.

>    The "web services zone" hosts several load balanced web systems,
> with reverse proxies and the like. No DNS/SMTP servers in this zone.
> Currently "pure web zone", and it should stay so.

Nice.

> Throughput to the internet customers is a major constraint.

That will of course define things later on . . .

>    Both routers have quite extensive IP filters (well, the external one
> basically has "deny if not TCP/80 or TCP/443 targeted to the web
> servers").
>    The customer is currently thinking about inspecting routers, to go
> "one step further than plain filtering".
>    First question, does this low-level inspection really buy anything
> wrt security ?

You said only 80 and 443, that's incoming, can the webservers
initiate connections to the outside?  If they can, stateful
filtering on the external router could maybe be a good idea.

If not, stateful filtering on the external router might still
protect you from outgoing streams being created by a cracker
once one of the web machines is already rooted.  I assume
that you want to avoid that happening in the first place
:-)  Anyway, an IDS would be a better idea (www.snort.org,
www.prelude-ids.org [made in France]).

Other than that, stateful filtering on the external router will
basically protect you from some consequences of having worse TCP
stack implementations on the web servers than on your routers.
Nothing more, nothing less, unless you also put something doing
QoS on the router (don't).  You should have confidence in your
TCP stack implementations, otherwise you should change your
TCP stack implementation; therefore stateful filtering on the
external router won't buy you much.

It will, on the other hand, cost you.  Stateful filtering is
more expensive than non-stateful in terms of CPU / memory /
performance.  It doesn't matter for small[1] sites since even
low-end firewalls have enough horsepower by far to do stateful
on a small scale, but if you are at the point where you worry
about performance, which you obviously are, and are used to
calculating router load in tens of percent instead of single
digits, then you will probably not like the numbers.

OK, I have not tested the affirmations in the above paragraph.
I have no hard numbers to base myself on.  If someone has,
please tell.

>    Secondly, I advise him to put his inspection stuff on the
> internal access router, where 1/ the throughput is far lower
> than on the external router 2/ we know exactly what should
> cross here 3/ if anything unusual comes this way, all hell
> should and will break loose.  Would this be the best place to
> inspect packets ? What would we gain (or loose) by putting
> inspection on the external router ? Tia,

If the load isn't extreme, you should in my opinion enable
inspection on the internal router.

My only question is if there are connections initiated from the
web farm.  I'd avoid it if possible, it simplifies everything --
as I'm sure was the meaning of it all, right?

I doubt I've said anything you haven't thought of; just don't
forget an IDS or two and something automatic to parse the IDS
alerts / router reject logs and evaluate the importance of the
alert.

HTH

-- Lorens

[1] defining small as small enough for my sentence to be correct :-)

P.S. Since you seem to be French . . . I'm looking for a job
in the west of France . . . or something extremely well paid
elsewhere :-)

-- 
#include <std_disclaim.h>                          Lorens Kockum
_______________________________________________
firewall-wizards mailing list
firewall-wizards () honor icsalabs com
http://honor.icsalabs.com/mailman/listinfo/firewall-wizards