On Wed, Jul 26, 2000 at 03:27:31PM -0400, Chris Brenton wrote:
> Patrick Darden wrote:
> > Ben, we disagree on our definition of stateful. RACLs do not store
> > session information (e.g. tcp sequence numbers),
>
> If this was true than most stateful packet filters would not be. Just
> did a dump on FW-1 & iptables, don't see sequence numbers stored in
> either.
fw-1 does not store seq numbers, therefor it can easily be fooled
to believe that malicious packets are part of the connection (see below)
(it offers some protection though: extra timeout and reconstruction of
its statetable for TCP and non-dynamic rules)
I would still call it "stateful" - just not as "stateful" as a pix ;)
> > they are easily spoofed (e.g. using nscan syn/ack sets
>
> Not true. In order to get by source IP & port as well as destination IP
> & port has to match. Just playing with the flags will not do it. I'm not
> a betting man, but I would "guess" that the odds of an outside attacker
> correctly guessing all of this info _as well as_ hitting the window when
> its open would be astronomical.
I strongly disagree.
Lets take the following scenario: a DoS attack against your SMTP servers
in your DMZ: FIN/RST connection interruption by the attacker.
(if the SMTP host checks sequence numbers on FIN or RST packets,
the dumb packetfilter is as good as the sophisticated SPF ;)
Lets also assume the attacker wants to disrupt mail traffic to a
frequent other host (i.e. MX of gmx.net or hotmail.com or the like) so
he already knows both pairs of IP addresses.
On a dumb packetfilter the attacker only has to guess one port number
do get a faked FIN or RST packets to the SMTP server (what the server
does with it depends on the IP stack used).
On a stateful packetfilter that only records IP's and port numbers,
the attacker still only has to "guess" one port number, since the other
one is fixed (25). This is _not_ "astronomical", since only
a few thousand packets with port numbers from 1024 to 10000 or such
are sufficient (you dont think that gmx.net or hotmail.com or the like
use anything else then the default OS mechanism to allocate the source
port of their connections? and how about Your MTA? ;)
One of these packets will fit the rule and cause the SPF to do these two things:
- pass that packet to the server and
- (in case of FW-1, ipfilter and probably most others) remove the connection
from it's statetable. (fw-1 simply changes the timeout to 3 seconds, to avoid
the attack - once a non-FIN/RST packet of the real connection passes within
this timeout, the connection is restored to normal in the statetable - other
FW products may vary ;)
On a stateful packetfilter that also records sequence numbers, the attacker
now has to guess one port number (easy) and the sequence number, which
is not easy, especially if it's randomized.
I would prefer the later.
And hitting a window, however small, is in the times of distributed attack
networks far too easy.
Btw, Working attacks like this (guessing one port number) do exist and
have been seen in the wild. (check several incidents lists)
So - if you look at what Services use your firewall/packetfilter
you might realize that an attacker does not have to guess all 4 parameters
of a TCP connection (src/dst IP and port), usually one port is 25 or
53 or 80 (i.e. fixed), one IP is fixed (the target's IP) and the other
is eigther also fixed (as in favorite ext. DNS server or MTA or webserver)
or can be limited to a small number of possibilities.
If your network is able to transport severl thousands of packets within
the window of a TCP connection (several seconds up to few minutes usually),
you are vulnerable.
> Are you thinking of static filtering? This can be fooled by nmap ACKs.
> Stateful can not.
yes it can. Through massive flooding with packets with incremented port
number. (no need to sniff the network)
> > Each time a TCP connection is established from an inside host accessing
> > the Internet through the... Firewall, the information about the connection
> > is logged in a stateful session flow table. The table contains the source
> > and destination addresses, port numbers, TCP sequencing information, and
> > additional flags for each TCP connection associated with that particular
> > host.
>
> Humm, so what does storing sequence numbers get you besides higher CPU
> and memory utilization? If I've sniffed the wire to figure out ports &
> IPs, I get sequence numbers as well. IMHO your taking a big performance
> hit for a marginal increase in difficulty to pull off the hack.
protection against the "port-number-guessing" attack where both ip's and
one port is well-known.
And most attackers cant sniff your wires. they dont need to if you're not
also checking sequence numbers ;)
> > ACK bits are too easily spoofed to be relied upon. That is why RACLs was
> > a first attempt that Cisco advises not using, except in cases that CBAC
> > will not work and a PIX is unacceptable.
>
> Interesting. I've had more than one Cisco engineer tell me I'm better
> off with reflexive filtering than CBAC because the performance
> difference. Guess it depends on whether your talking to sales or an
> engineer. ;)
Aha - but i guess (since cisco is a Networking company) most cisco engineer's
are Networking engineers, as opposed to Security engineers (of which cisco
_does_ has some good ones though).
Of course in gerneral (very general...) network engineers tend to prefer
performance and usability to security. (this is a very broad generalilsation,
i do know exceptions ;)
[take a quick look at your statetable (or sniff your network) to find
out what random-source ports are usually used in your traffic]
cheers,
Juergen
--
Juergen P. Meier email: [EMAIL PROTECTED]
#include <std-disclaimer.h>
-
[To unsubscribe, send mail to [EMAIL PROTECTED] with
"unsubscribe firewalls" in the body of the message.]
