Date: Thu, 6 Jan 2005 08:35:20 GMT From: Jonas Nagel <fireball@zerouptime.ch> To: freebsd-gnats-submit@FreeBSD.org Subject: kern/75873: Usability problem with non-RFC-compliant IP spoof protection implementation Message-ID: <200501060835.j068ZKpb022902@www.freebsd.org> Resent-Message-ID: <200501060840.j068eQ4w099477@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
>Number: 75873 >Category: kern >Synopsis: Usability problem with non-RFC-compliant IP spoof protection implementation >Confidential: no >Severity: non-critical >Priority: medium >Responsible: freebsd-bugs >State: open >Quarter: >Keywords: >Date-Required: >Class: change-request >Submitter-Id: current-users >Arrival-Date: Thu Jan 06 08:40:26 GMT 2005 >Closed-Date: >Last-Modified: >Originator: Jonas Nagel >Release: 4.10-RELEASE-p4 >Organization: - >Environment: >Description: "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). >How-To-Repeat: 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. >Fix: 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. >Release-Note: >Audit-Trail: >Unformatted:
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200501060835.j068ZKpb022902>