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.
