[12081] in bugtraq
Re: FireWall-1 weakness
daemon@ATHENA.MIT.EDU (Chris Brenton)
Fri Oct 1 13:31:38 1999
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-Id: <37F3AC32.6E7E70E7@sover.net>
Date: Thu, 30 Sep 1999 14:30:10 -0400
Reply-To: cbrenton@sover.net
From: Chris Brenton <cbrenton@SOVER.NET>
X-To: BUGTRAQ@SECURITYFOCUS.COM
To: BUGTRAQ@SECURITYFOCUS.COM
Hugo.van.der.Kooij@CAIW.NL wrote:
>
> This rules allows winframe sessions to pass but should stop other traffic
> as it does some more packet analyses.
>
> A customer tried to run FTP through it and saw an accept in the log. But
> due to the lack of a server on the other side could not establish wether
> or not there was a leak.
>
> Recreating this in the lab with telnet showed the same. However putting a
> working telnetd on port 1494 at the specific server did still not allow
> anyone to enter the system. After initial TCP connection setup it seems
> the firewall drops connections.
Sounds like the rule is doing exactly what its suppose to (stop traffic
after additional analysis).
The "accept" you are seeing is due to the TCP three packet handshake.
When the initial SYN=1 packet is transmitted to the WinFrame, there is
insufficient data to determine what application is initializing the
connection. Remember at this point all TCP sessions are going to look
the same. This generates the initial "accept" log entry.
From what you describe above, once the handshake is complete and data
begins to be transferred the firewall is doing what its suppose to, it
blocks all traffic that does not have the proper WinFrame prologue.
Sounds like the stateful engine is working properly.
There are other ports however that do display the symptoms you are
alluding to. For example, leave TCP/DNS checked off under Properties and
setup telnetd to listen on port 53. You will find that you actually
*can* create an inbound Telnet session. This is because filtering on
this port is dynamic but not stateful. Check out:
http://www.geek-speak.net/fw1/fw1_properties.html
for more info.
> But this will lead to two weaknesses:
> 1. Any server defended by FireWall-1 could be subject to a DoS attack if
> the server should accept TCP sessions at port 1494.
IMO *any* system accepting connections on *any* TCP port is subject to a
DOS attack. Doesn't seem to be any more or less the case in this
situation.
> 2. The log only shows a succesfull start of the session but down not
> indicate any filtering. This leaves the operator of the firewall in
> the dark wether or not a session was cut off due to the missing
> winframe signature. So there is no indication off foul play and
> everyone will be assuming things are just fine.
You would have to look at "active" sessions instead of "log". When set
to "log", only the first packet exchange gets recorded. This is done to
keep the log files from growing too quickly. "Active" would show you
that the session traffic is being blocked after the fact and due to
which rule. Actually, you could probably due this through the accounting
functionality as well.
Cheers,
Chris
--
**************************************
cbrenton@sover.net
* Multiprotocol Network Design & Troubleshooting
http://www.amazon.com/exec/obidos/ASIN/0782120822/geekspeaknet
* Mastering Network Security
http://www.amazon.com/exec/obidos/ASIN/0782123430/geekspeaknet
