Augh, this is all just TOO tempting.
> -----Original Message-----
> From: mouss [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, 5 December 2000 7:19
> To: Paul D. Robertson; Dane Balia
> Cc: [EMAIL PROTECTED]
> Subject: Re: Simple Pimple firewalls
>
>
> At 07:54 04/12/00 -0500, Paul D. Robertson wrote:
[so, this level is Paul]
> >
> >TCP-based systems keep their own state, and other than some DoS stuff
> >(which should be tuned on Internet-accessable hosts anyway),
> there's no a
> >great deal of value from the filter keeping state.
Which is an interesting point, and kind of flies in the face of "current
opinion", but the arguments you make are all reasonable and logical.
In my opnion, though, I'd still rather have a simple stateful filter. The
extra overhead to do TCP and UDP state-matching is not that extreme and
should not be all that hard to code. You throw away a line about bugs in
current stateful filters, but it seems to me that they've all been based on
application / control channel hackery - which is not strictly a part of a
stateful _packet_ filter (FTP control channel bugs, the PIX mailguard oops
etc). Has there been anything anyone has noticed that has been a "pure"
state-keeping error?
To be "market competitive" now an SPF has to virtually be a proxy, judging
by the amount of application knowledge required. This is not good. It seems
to me that the Cisco reflexive ACLs and IPFilter are both good "simple"
stateful solutions that don't try too hard. I like 'em as front-line
solutions.
Overall, I guess I can't really think of a nasty attack scenario with a
two-layer system where the outer firewall is a static filter instead of a
stateful filter - as long as the inner one is an SPF or an ALG, so I suppose
to that extent I agree with you. I'm possibly just not as paranoid about the
risks of code complexity in some solutions. ;)
[So this level is mouss]
[...]
>
> >Cisco router filtering
> >on a normal IOS image isn't stateful either, but it's still the best
> >first-line of defense.
>
> normal IOS is for routing, not for filtering. next generation
> firewall stuff
> from cisco and others is probably to come with stateful
> filtering if they
> don't have proxies.
No way. The static filtering in the IOS is the most mature simple packet
filter around. The reflexive ACLs (which ARE part of the basic IOS and ARE
stateful - sorry Paul) are, in my opinion, just as good. IPFilter / IPfw
will will a battle for features, but they don't run on your edge device.
Firewall IOS add-in stuff already exists, but I recommend against it for
front line filters - too complex, tries too hard to be a 'real' firewall.
The IOS/FW is good for small places that only have one firewall.
[...]
> >Since the biggest gain for keeping state is UDP or ICMP,
>
> that's obviously wrong. the first place for stateful filtering is TCP,
> so that holes are only opened when necessary and closed when no more
> needed (by followig the TCP state).
It's not wrong, it's right. The biggest _gain_ from stateful filtering is
the ability to fake state for stateless protocols like UDP. Without a
stateful filter you need to open huge holes to make DNS work, for example.
You can do a fairly good job of enforcing TCP state just by filtering out
incoming packets without the ACK or FIN bits set. If you add real state to
that the security delta is not as great.
[...]
> the only time you don't need state is when you have a proxy.
Or another firewall behind the packet filter.
[...]
> >DNS should go to a controlled machine or
> >two running a local resolver, no reason to allow anything
> else to talk UDP
> >if you're really worried about security.
>
> I've never needed state for DNS.
> just run BIND on the FW, in which case it acts as a proxy, or
> run it outside.
Ouch! I would never run bind on a firewall. Too complex, history too bad.
Take a look at djbdns (http://cr.yp.to/djbdns.html).
[...]
>
> (Caution: these are not Paul's words).
> That's because one doesn't chose his OS based on the software
> he needs, but
> the opposite. and until lately, ipchains was the best
> solution on linux. It
> has been outperformed by solutions on *BSD, but it itlself
> outperforms many
> other solutions. in other words, state is good, but you can
> live without!
> so one isn't gonna switch to an OS just because of a lack of feature.
I would argue that for firewalls that's exactly what one should do. It's all
moot, anyway, since it's not like IPFilter doesn't run on Linux.
> >Stateful rules are added in the next revision of Linux
> filtering, which
> >will replace IPChains.
>
> so, this is enough proof that stateful is good:)
*gack* *cough*
NEWS BULLETIN: LINUX INCLUDES FEATURE - MUST BE GOOD
Adoring masses crowd Penguin statue in Torvalds Square
[...]
> >For security, blocking a protocol is *always* preferable to
> passing it
> >when talking to the Internet at large, so state would only
> really play a
> >part in mission-critical protocols that absolutely must be
> supported and
> >don't contain any state information themselves.
>
> nop' with a non staeful filter, to allow outgoing telnet (for
> example), you
> need to allow incoming requests from port 23 to high ports, which is
> less secure than allowing those only if they correspond to an outgoing
> request. while it is hard to perform an attack based on this,
> it is still
> theoritically possible, and many practical attacks were only
> theoritical some
> years ago.
You can also filter any packets that don't have the ACK or FIN bits set.
This will stop anyone from the outside from starting a TCP session to your
internal hosts. The only TCP attacks that can then be performed are those
that can be carried out with uni-directional traffic and no TCP sessions.
That's normally DoS.
[...]
> we don't only protect hosts because they have buggy stack. we
> also protect
> them so that we can configure'em the way we want. yes, if all
> my internal hosts
> are protected, then I won't need a FW, but then each host
> would need its own
> servers, as it can trust no other hots. bye NIS, samba, dns, ...
> so for me a firewall is that thing that allows me to put
> funny .rhosts, share
> passwords and files, ... in the internal network, install a
> host without
> needing
> to sniff all traffic for an attack, ... otherwise, I don't need one.
You need to think about this. I think I'm paraphrasing someone famous here,
but secure networks with hard candy shells still need to do something about
the soft, chewy centres.
Yes, there's always a security / utility tradeoff, and you make whatever
decisions are right for your environement, but part of planning for
intrusion is working out risk / damage control if someone _does_ get in.
Cheers,
--
Ben Nagy
Marconi Services
Network Integration Specialist
Mb: +61 414 411 520 PGP Key ID: 0x1A86E304
-
[To unsubscribe, send mail to [EMAIL PROTECTED] with
"unsubscribe firewalls" in the body of the message.]
