[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
kern/75873: Usability problem with non-RFC-compliant IP spoof protection implementation
- Subject: kern/75873: Usability problem with non-RFC-compliant IP spoof protection implementation
- From: fireball at zerouptime.ch (Jonas Nagel)
- Date: Thu Jan 6 08:40:30 2005
>Synopsis: Usability problem with non-RFC-compliant IP spoof protection implementation
>Arrival-Date: Thu Jan 06 08:40:26 GMT 2005
>Originator: Jonas Nagel
"Some servers are protected by a mechanism whereby upon receiving a SYN
packet from an unknown source, attempt to validate the source IP by
generating an invalid ACK packet in response. The server then expects to
receive a RST back from the Client, for the invalid ACK, and this then
validates the source IP of the Client. At this point the Server knows
the Client's IP is not spoofed, and will add the Client's IP to a list
of valid IPs.
The problem is that the PIX passes this invalid ACK packet to the
Client, and the client correctly responds with a RST. However, the PIX
will not pass this RST packet because the Sequence number in the RST
does not match the Next Expected Sequence number. Therefore, the PIX
responds to the RST packet with an ACK, and the Ack number is set equal
to the Next Expected Sequence number. The PIX then expects the client to
Reset this ACK with the valid sequence number, but the client is not
obligated to do so."
CISCO PIX and FreeBSD seem to have that problem with such
implementation. While above description is copied from a CISCO Firewall
Engineer response, the latest PIX microcode engineering releases
incorporates a fix that works around this.
Maybe this is also an IPFilter Problem (I am using ipf/ipnat on my firewall).
Try to connect to https://citrix.lehmannholding.ch - at least with FreeBSD 4.x as Firewall the (listening) port appears to be 'filtered', also the other ports which are listening (or being forwarded rather) on this peer appear this way. While all other ports which are not listening return RST and therefore appear 'unfiltered' (in fact they are blocked on the firewall).
Btw. this host is running a Symantec Raptor Firewall.
It would require a full analysis of the broken packet being sent. But
hacking IPFILTER or even the FreeBSD TCP Stack is out of my scope.
Visit your host, monkey.org