Re: [fw-wiz] Inspecting routers

From: Kyle R. Hofmann (krh@lemniscate.net)
Date: 11/25/02 

To: firewall-wizards@honor.icsalabs.com
From: "Kyle R. Hofmann" <krh@lemniscate.net>
Date: Mon Nov 25 23:00:33 2002

On Mon, 25 Nov 2002 18:20:49 +0100, Lorens Kockum wrote:
> > 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.

Even if they can, should they? I can't think of a compelling reason for them
to be initiating connections to the outside world, but I don't know how
they're setup.

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

This is not strictly true. Pure stateful filtering may still allow
maliciously constructed TCP segments. You are thinking of packet
normalization, which usually has stateful filtering as a prerequisite.

> It will, on the other hand, cost you. Stateful filtering is
> more expensive than non-stateful in terms of CPU / memory /
> performance.

This is not true for all implementations, and probably not even for most.
See http://www.benzedrine.cx/pf-paper.html.

In particular, Hartmeier says that by storing states in a balanced tree, state
lookup becomes O(log n) while ruleset evaluation is still O(n). That implies
that processing a fifty rule set for each packet takes about the same work
as comparing that packet to one of 5*10^22 states. Keeping a million states
takes about the same work as processing a fourteen rule set for each packet.

(Note that truly valid numbers would vary from these estimates. These
are really order-of-magnitude approximations.)

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

What does your customer hope to gain by inspecting packets on his routers?
He says he wants to go "one step further than plain filtering". Is he looking
for a proxy server, an IDS, an IPS, or something else?

If his goal is to be as secure as possible, he needs to evaluate how much
money he's going to dedicate to security before he starts looking at
particular options. Once he knows how much he's willing to spend, he needs
to look at all of the options that remain within his budget. It doesn't sound
to me like he's quite sure what's out there.

If his goal is specifically to inspect packets, it sounds like he wants either
an IDS or an IPS. First figure out which one he wants; then make sure he
knows what he's getting and what he's not; then he can evaluate the cost of
having it on zero, one, or both access points.

If he wants an IDS or an IPS in his router and wants to buy only one, then he
needs to determine what sorts of attackers he's hoping to catch. If he wants
to stop script kiddies, then he'll want to put it on the externally facing
interface with a very generic set of rules to catch the exploit-of-the-week.
If he wants to stop insiders, then the ruleset will have to be much more
carefully written and he'll want to put it on the internally facing interface
(though a slightly more clever insider could use his inside knowledge, a
throwaway dialup account, and the external interface; he should seriously
consider either getting two inspecting routers or a standalone IDS). 

-- 
Kyle R. Hofmann <krh@lemniscate.net>

Relevant Pages

  • Re: newb: netfilter/iptables ?? extension?
    ... Explain further what you expect to gain by filtering on IP ... I think it would take a rack of Cisco high speed packet filtering ... perform a lookup -- just like iptables. ... provide a clue to solve it -- except that _no_ packet filtering router ...
    (comp.os.linux.networking)
  • Re: DROP Protocols
    ... > Or according to the following article, use like a Router or Firewall to do ... > The code value of the ICMP Destination Unreachable packet is 0x0D. ... > administrative filtering. ...
    (microsoft.public.win2000.advanced_server)
  • Re: VPN problems from Linksys WAG54G to Netscreen 208 using netscreen client
    ... > IPsec filtering is on and the router asks for my username and password. ... set ffilter src-ip 2.2.2.2** ... the 445 or the SQL traffic because your WAG think's it's not good Internet ...
    (comp.security.firewalls)
  • Re: Airport dropping connection
    ... filtering, and the MAC address of the computer from which you connect ... is not allowed, the computer will *appear* to be connected, but the router ... Have you examined the Airport passwordstored in your MacBook ...
    (comp.sys.mac.portables)
  • Router Packet Filtering and Firewalls
    ... I am trying to confirm my thoughts regarding the use of router packet ... a firewall but used packet filtering on the router to protect our ...
    (Security-Basics)