From owner-freebsd-net@FreeBSD.ORG Mon Mar 1 23:57:52 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DDFAD16A4CE for ; Mon, 1 Mar 2004 23:57:51 -0800 (PST) Received: from mail019.syd.optusnet.com.au (mail019.syd.optusnet.com.au [211.29.132.73]) by mx1.FreeBSD.org (Postfix) with ESMTP id E252943D2F for ; Mon, 1 Mar 2004 23:57:47 -0800 (PST) (envelope-from tfrank@optushome.com.au) Received: from marvin.home.local (c211-28-241-126.eburwd5.vic.optusnet.com.au [211.28.241.126])i227vgB08930; Tue, 2 Mar 2004 18:57:43 +1100 Received: by marvin.home.local (Postfix, from userid 1001) id 41F7C1FBA7; Tue, 2 Mar 2004 18:57:42 +1100 (EST) Date: Tue, 2 Mar 2004 18:57:42 +1100 From: Tony Frank To: Ian Smith Message-ID: <20040302075742.GA18966@marvin.home.local> References: <20040227151405.GA5540@marvin.home.local> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i cc: freebsd-net@freebsd.org Subject: Re: Bad loopback traffic not stopped by ipfw. X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Mar 2004 07:57:52 -0000 Hi, Bit of a delayed response I'm afraid - PC troubles. On Sun, Feb 29, 2004 at 01:28:23AM +1100, Ian Smith wrote: > On Sat, 28 Feb 2004, Tony Frank wrote (in freebsd-net@freebsd.org): > > > On Wed, Feb 25, 2004 at 05:21:34PM +0300, Gleb Smirnoff wrote: > > > On Wed, Feb 25, 2004 at 04:19:51PM +0200, Iasen Kostov wrote: > > > I> >>16:26:23.287642 0:1:2:9>c:cf:e2 0:02:55:b0:90:e4 0800 60: 127.0.0.1.80 > > > > I> >>192.168.118.205.1046: R 0:0(0) ack 1959723009 win 0 > > > I> > > > > I> >This is some kind of Win32 virus. This floods can be easily > > > I> >stopped by ipfw rule: > > > I> > > > > I> >deny tcp from any to any tcpflags rst,ack > > > I> > > > > I> These packets never reach IPFW as we can see. > > > > > > Ughu. Really. > > > But I have millions of them from non-localhost addresses. > > > > > > > This maybe is of interest? > > > > http://www.dshield.org/pipermail/list/2004-January/014027.php > > I'm sorry Tony, call me thick, but I couldn't see the relevance of this > posting "[Dshield] ISPs - How much monitoring is enough?" to the topic > regarding these inbound packets 'from' 127.0.0.1:80 ? I'm kind of > curious though, having seen several hundred of these (blocked by ipfw on > an ol' 2.2.6 system) over the last couple of weeks. > > Looks like an interesting list for such stuff, though; had a browse. The link seems to have changed. Checking it now I find something unrelated. Too much mail, too little sleep. Specifically on the question at hand regarding 127.0.0.1.80 business it seems to be relating to blaster and some aspects of how some admins tried to stop it. I'm including the message text (was a cross from securityfocus): -----Forwarded Message----- From: Dan Hanson To: incidents at securityfocus.com Subject: Administrivia: Are you seeing portscans from source 127.0.0.1 source port 80? Date: Tue, 28 Oct 2003 08:59:56 -0700 I am posting this in the hopes of dulling the 5-6 messages I get every day that are reporting port scans to their network all of which have a source IP of 127.0.0.1 and source port 80. It is likely Blaster (check your favourite AV site for a writeup, I won't summarize here). The reason that people are seeing this has to do with some very bad advice that was given early in the blaster outbreak. The advice basically was that to protect the Internet from the DoS attack that was to hit windowsupdate.com, all DNS servers should return 127.0.0.1 for queries to windowsupdate.com. Essentially these suggestions were suggesting that hosts should commit suicide to protect the Internet. The problem is that the DoS routine spoofs the source address, so when windowsupdate.com resolves to 127.0.0.1 the following happens. Infected host picks address as source address and sends Syn packet to 127.0.0.1 port 80. (Sends it to itself) (This never makes it on the wire, you will not see this part) TCP/IP stack receives packet, responds with reset (if there is nothing listening on that port), sending the reset to the host with the spoofed source address (this is what people are seeing and mistaking for portscans) Result: It looks like a host is port scanning ephemeral posts using packets with source address:port of 127.0.0.1:80 Solution: track back the packets by MAC address to find hte infected machine. Turn of NS resolution of windowsupdate.com to 127.0.0.1. Hope that helps D --------------------------------------------------------------------------- Regards, Tony