Nadav Har'El wrote:
> > A possible attack is then to open as many connection as you can in a
> > short time to force that connection table to fill up. This is not (any
> > more) an academic discussions - SYN attacks, which are basically based
> > on the same principle (but happening at the bastion server, not the
> > firewall) is what caused in the last year major players like Yahoo and
> > eBay to fall down. Using a "stateful inspection" firewall introduces yet
> > another point of failure to your setup.
> >..
>
> This is a good point, but I think it's not much of a problem usually,
> because of two reasons:
>
> 1) In a home network, or even office network: In this case, the main concern
Agreed. DoS attacks are not very interesting to a home user. I was not
implying that they were.
I just gave a specific example how a feature of a firewall has two
faces.
> 2) Correct me if I'm wrong, but I don't see much point in doing stateful
> inspection on a *LISTENING* port. I mean, if you have an http server
> listening on port 80, then what would you gain by trying to follow the
> incoming sessions in the firewall? Are you interested in catching non-SYN
> segments of a non-existant connection and not return an RST? Why? Or
> are you trying to prevent weird "replies" to hosts that never asked a
> question? Why? (if this is to prevent trojans from connecting out, they have
> other ways to communicate out, usually... you can also prevent outgoing SYNs)
>
You wish - ever heard of the obscure FTP protocol? ;-) it tries to open
a TCP connection from the ftp server to the ftp client for it's data. So
if you want to support FTP (not an all together ridiculous demand after
all) you have to check incoming SYN packets for "correctness". And how
do you do that? right... you check against a state table (or hash,
doesn't matter). And everywhere there is a state table you can flood it.
The fact is the same thing happens everywhere you try to save state: in
the fragment queue, for example. The principle here is that "state"
requires a place to save data. You can flood that place. Hence "stateful
inspection" carries, by it's name, a weak spot.
Are there bigger weak spots out there? of course. I was just saying that
to use the buzzword of the day (here: "stateful inspection") does not
make anything more secure. It's always a trade off and a firewall that
does not do stateful inspection is not necessarily less better then one
who does. It depends in what you want to do.
>
> I see the importance of stateful inspection in the other direction: i.e.,
> a user from inside the firewall makes a connection, and we want to allow
> packets to return to him, but only from the one machine he's connected to -
> we don't want to open up everything from every machine just to allow this
> connection. I don't see how a DoS attack can be done remotely in such a
> case.
>
As I wrote above it is because of the user on the inside of the firewall
that it needs to keep state - to know which connection is lawful and
which isn't that state tables overflowing can be achieved.
Gilad.
--
Gilad Ben-Yossef <[EMAIL PROTECTED]>
http://kagoor.com :: +972(54)756701
"Any philosophy that can be put in a nutshell belongs there"
=================================================================
To unsubscribe, send mail to [EMAIL PROTECTED] with
the word "unsubscribe" in the message body, e.g., run the command
echo unsubscribe | mail [EMAIL PROTECTED]
