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 hvdkooijat_private 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!
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 15:06:16 PDT