This is the correct behaviour for all FW1's. When FW1 receives a !SYN-ACK packet it assumes the packet to be part of an established connection. If the connection was not in the connections table, it will be added, and the packet is mangled (strip data and change tcp seq. nr) and forwarded to the remote host. Whether the connection was valid or not, the destination host would reply, and the FW will drop the connection from the table, or keep it. However, the only way the connection is dropped from the table is when the destination host sends two FIN packets, or the timeout value is reached. Therefore if the destination host is not reachable, it takes a while for the connections to vanish. As far as I understand, the rules don't even have to allow the connection. This is because 'drop' in your ruleset does not mean drop. In order to really drop the mangled packets the action needs to be 'vanish' (which is not configurable through the GUI. Edit the .pf files manually). Note that this is how I understand the workings. I might be incorrect in assuming that this explains the problem. On Thu, Jul 29, 1999 at 09:42:39PM -0500, Spitzner, Lance wrote: > > Now, if you start a connection with an ACK packet, the FW > compares it against the rule base, if allowed it is added > to the connections table. However, the timeout is set to > 3600 seconds and does not care if a remote system > responds. You now have a session with a 1 hour timeout, > even though no system responded. Now, do this with alot > of ACK packets, and you have full connections table. > [SNIP] > > I would greatly appreciate if anyone could prove/disprove > this. Also, FW-1's SynDefender did not protect against this > attack.
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 14:54:49 PDT