From owner-freebsd-bugs@FreeBSD.ORG Thu Jan 6 08:40:28 2005 Return-Path: Delivered-To: freebsd-bugs@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6F7F616A4D2 for ; Thu, 6 Jan 2005 08:40:28 +0000 (GMT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2BC9143D4C for ; Thu, 6 Jan 2005 08:40:28 +0000 (GMT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.1/8.13.1) with ESMTP id j068eQAN099478 for ; Thu, 6 Jan 2005 08:40:26 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.13.1/8.13.1/Submit) id j068eQ4w099477; Thu, 6 Jan 2005 08:40:26 GMT (envelope-from gnats) Resent-Date: Thu, 6 Jan 2005 08:40:26 GMT Resent-Message-Id: <200501060840.j068eQ4w099477@freefall.freebsd.org> Resent-From: FreeBSD-gnats-submit@FreeBSD.org (GNATS Filer) Resent-To: freebsd-bugs@FreeBSD.org Resent-Reply-To: FreeBSD-gnats-submit@FreeBSD.org, Jonas Nagel Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 246EE16A4CF for ; Thu, 6 Jan 2005 08:35:21 +0000 (GMT) Received: from www.freebsd.org (www.freebsd.org [216.136.204.117]) by mx1.FreeBSD.org (Postfix) with ESMTP id E507F43D55 for ; Thu, 6 Jan 2005 08:35:20 +0000 (GMT) (envelope-from nobody@FreeBSD.org) Received: from www.freebsd.org (localhost [127.0.0.1]) by www.freebsd.org (8.13.1/8.13.1) with ESMTP id j068ZK85022903 for ; Thu, 6 Jan 2005 08:35:20 GMT (envelope-from nobody@www.freebsd.org) Received: (from nobody@localhost) by www.freebsd.org (8.13.1/8.13.1/Submit) id j068ZKpb022902; Thu, 6 Jan 2005 08:35:20 GMT (envelope-from nobody) Message-Id: <200501060835.j068ZKpb022902@www.freebsd.org> Date: Thu, 6 Jan 2005 08:35:20 GMT From: Jonas Nagel To: freebsd-gnats-submit@FreeBSD.org X-Send-Pr-Version: www-2.3 Subject: kern/75873: Usability problem with non-RFC-compliant IP spoof protection implementation X-BeenThere: freebsd-bugs@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Bug reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jan 2005 08:40:28 -0000 >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: