Hugo.van.der.Kooijat_private 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 -- ************************************** cbrentonat_private * 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
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 15:06:13 PDT