Re: FireWall-1 weakness

[Hugo.van.der.Kooij () CAIW NL (Hugo.van.der.Kooij () CAIW NL)]

On Thu, 30 Sep 1999, David Grimes wrote:

>       Remember me? You should provide BugTraq the same detail I provided you. I
> wouldn't call this a weakness in FW-1 I would say it's a weakness in the
> winframe server, better yet in the TCP architecture itself. Winframe is just
> as vulernable through a firewall as an SMTP or FTP server, they all allow
> arbitrary connections. So with that said I'd like to point out two things
> first.
> 1. Your fear of a DoS could be averted by using SynDefender, which would
> protect from a syn flood type of attack.
> 2. Without inserting WinFrame specific data with in the packet there is no
> chance of a vulnerability.

The term weakness here refers to the fact that a dropped session is not
reported. It does not refer to a leak in the defenses.

I clearly stated that after connection setup (which anyone in our business
should now refers to the SYN, SYN/ACK, ACK packets) the connections is
dropped. My understanding from the SynDefender is that it stops worrying
when a session gets to the ACK. So SynDefender will not help here. But the
likelyhood of this is substantial smaller then the usual Syn attacks.

The issue here is that in the log there is a report of a successfull
connection reported. The session never got beyond the first 3 packets so
the defense mechanisme is correct. But there is nothing in the log that
will give you a clue that the firewall dropped a session.

So the weakness is not reporting a dropped session.

(This is what is in the report I send to BugTraq!)

Having a guard in place that has no way of reporting an attempted attack
is a weakness. I do like to know who is probing my defenses and when they
do.

>       To detail and clarify what exactly is happening here, let me explain how
> the firewall is treating this connection. When the connection comes in it is
> accepted by the firewall based on it's src. dest. and service (port), the
> real magic comes in to play when statefull inspection is applied to the
> connection there after. If you reference the base.def and the winframe
> description there, you'll notice that it's looking for a particular
> signature that is unique to WinFrame connections. Since this is not present
> in any other packet type the firewall then drops the packet as a violation
> of a WinFrame connection.
>       The ideal thing to do here is to modify the inspect script in the base.def
> to log this behavior and file it appropriately.  You should also take
> responsibility for allowing winframe connections in the first place. It's
> allways a risk to provide a service to the world. None the less good eye :)

Pardon me but this IS what I said in my report as well. No logging is the
issue CheckPoint never bothered to get a fix for! I reported this under
the proper case number but never got a fix for the logging. That's why
this report went to BugTraq.

Comparing with HTTP (which is only defined as TCP port 80) is something
quite differently here. The winframe definition does a lot more but it
requires you to dig into a firewall setup.

Hugo

--
Hugo van der Kooij; Oranje Nassaustraat 16; 3155 VJ  Maasland
hvdkooij () caiw nl     http://home.kabelfoon.nl/~hvdkooij/
--------------------------------------------------------------
Use of any of my email addresses for unsollicited (commercial)
    email is a clear intrusion of my privacy and illegal!