From owner-freebsd-doc@FreeBSD.ORG Tue Feb 14 17:07:06 2006 Return-Path: X-Original-To: doc@FreeBSD.org Delivered-To: freebsd-doc@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7B53C16A420 for ; Tue, 14 Feb 2006 17:07:06 +0000 (GMT) (envelope-from freebsd-listen@fabiankeil.de) Received: from smtprelay03.ispgateway.de (smtprelay03.ispgateway.de [80.67.18.15]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9EA0D43D46 for ; Tue, 14 Feb 2006 17:07:05 +0000 (GMT) (envelope-from freebsd-listen@fabiankeil.de) Received: (qmail 32491 invoked from network); 14 Feb 2006 17:07:03 -0000 Received: from unknown (HELO localhost) ([pbs]775067@[217.50.150.81]) (envelope-sender ) by smtprelay03.ispgateway.de (qmail-ldap-1.03) with SMTP for ; 14 Feb 2006 17:07:03 -0000 Date: Tue, 14 Feb 2006 18:07:05 +0100 From: Fabian Keil To: Chuck Swiger Message-ID: <20060214180705.4d4ba682@localhost> In-Reply-To: <43F0A70F.2090006@mac.com> References: <20060213154956.058ccd65@localhost> <43F0A70F.2090006@mac.com> X-Mailer: Sylpheed-Claws 2.0.0 (GTK+ 2.8.6; i386-portbld-freebsd6.0) X-PGP-KEY-URL: http://www.fabiankeil.de/gpg-keys/freebsd-listen-2006-08-19.asc Mime-Version: 1.0 Content-Type: multipart/signed; boundary=Sig_NkBSLDjT_ZUNtNlboSUfRgC; protocol="application/pgp-signature"; micalg=PGP-SHA1 Cc: doc@FreeBSD.org Subject: Re: Concerns about wording of man blackhole X-BeenThere: freebsd-doc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Documentation project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Feb 2006 17:07:06 -0000 --Sig_NkBSLDjT_ZUNtNlboSUfRgC Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Chuck Swiger wrote: > Fabian Keil wrote: > > |Normal behaviour, when a TCP SYN segment is received on a port > > where |there is no socket accepting connections, is for the system > > to return a |RST segment, and drop the connection. The connecting > > system will see |this as a ``Connection refused''. By setting the > > TCP blackhole MIB to a |numeric value of one, the incoming SYN > > segment is merely dropped, and no |RST is sent, making the system > > appear as a blackhole. By setting the MIB |value to two, any > > segment arriving on a closed port is dropped without |returning a > > RST. This provides some degree of protection against stealth |port > > scans. > >=20 > > In which way does this protect against stealth port scans? >=20 > Returning a RST tells the scanner that the port is definitely closed. > Returning nothing gives less information. As open ports still show up as open I don't see the protection. If some port are open, the attacker can assume that all the "filtered" ports are closed. =20 > > I don't understand why the "blackhole behaviour" would slow down > > a DOS attempt. >=20 > nmap is extremely well written, and can scan un-cooperative hosts > better than most other programs will. Anything which uses a > protocol-compliant TCP/IP stack will retry dropped connections > several times if no answer is forthcoming, and will even do things > like try to make a connection without enabling any TCP or IP options > normally set by default. >=20 > These reconnection attempts will greatly slow down attempts to scan > ports rapidly. Which shouldn't result in a DOS anyway. The reconnection attempts will even increase the inbound traffic. =20 > > Is there a known DOS vulnerability in FreeBSD > > which can be exploited by trying to connect to a closed port?=20 >=20 > Sending highly fragmented packets ("the Rose attack?") used to be > quite effective against FreeBSD, although Andre Opperman or someone > has improved the way FreeBSD handles fragment reassembly to be more > efficient since then. =20 > > I can only think of filling up the connection with useless traffic, > > but this is possible with every OS and turning the attacked system > > into a so called blackhole wouldn't make a difference unless the > > uplink is slower than the downlink and the attacker really floods > > closed ports instead of open ones.=20 >=20 > Network bandwidth is not the only finite resource used in processing > network traffic: exhausting memory of making the OS consume excessive > amounts of CPU are also DOS mechanisms. You're right, I didn't think about those. But it's unlikely that "blackhole behaviour" would make a difference. > > AFAICS the only thing it does is to decrease traceroute's > > usefulness and to turn closed ports into filtered ports which > > slows some kinds of port scans down for a few seconds. >=20 > Something using the OS to do TCP/IP is going to be slowed down by > roughly an order of magnitude, which includes many malware programs > like worms. Again I don't see the gain. Eventually the port scan will be finished and open ports found. Fabian --=20 http://www.fabiankeil.de/ --Sig_NkBSLDjT_ZUNtNlboSUfRgC Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (FreeBSD) iD8DBQFD8g5AjV8GA4rMKUQRAuixAJ9yUt/TYHNht5CYdr3l7jP5Cs6yawCeP/kM 562h9p4LIDRJLuQIYs65X18= =tx8T -----END PGP SIGNATURE----- --Sig_NkBSLDjT_ZUNtNlboSUfRgC--