Re: Bad Loopback packets

[Michael Hofmeyr <michael () isa co za>]

Hi,

I have seen variations of this on a lot of our customers.

There are a numbrer of explanations, but in my experience it’s basically caused by the Blaster worms (or varients. When 
it was first noted
that the worm dos'd windowsupdate, some silly advice was given out on
the internet advising people to set DNS to return 127.0.0.1 for all
windowsupdate.com requests. This would, in theory, prevent the Internet
from being brought to a standstill by the sheer volume of traffic
heading for that site.

Basically what happens is:

1. the worm tries to dos's windowsupdate, (which now resolves to
120.0.0.1).
2. The packet is sent to localhost, but since there is no http server
listing on localhost it responds with a reset to the
spoofed source ip (which happens to be in your range in this instace).

The result looks like the following:

bash-2.05# snoop -d hme0 src 127.0.0.1
Using device /dev/hme (promiscuous mode)
localhost -> 196.x.x.x HTTP R port=1207
localhost -> 196.x.x.x HTTP R port=1170
localhost -> 196.x.x.x HTTP R port=1514

You should drop packets with a source of 127.0.0.1 at the
border router ( you should be doing this anyway). 

Rgds

--
Michael Hofmeyr
Information Security Architects
Phone: +27 11 326-2242
Cell : +27 83 631 0736
Fax  : +27 11 326-2285
152 Hendrik Verwoerd Drive
Randburg, Gauteng, South Africa
********************************



Neil Dickey wrote:

> We've been seeing what Snort calls "bad loopback traffic" in our
> university network for perhaps a week and a half now, and we've
> had no luck in tracking down the source much less figuring out
> what is generating it.
>
> Here's what the packets look like:
>
> [**] [1:528:3] BAD TRAFFIC loopback traffic [**]
> [Classification: Potentially Bad Traffic] [Priority: 2] 
> 04/21-16:17:39.669986 0:A:BB:CC:DD:EE -> 0:FF:GG:HH:II:JJ type:0x800 len:0x3C
> 127.0.0.1:80 -> 131.156.XX.YYY:1903 TCP TTL:125 TOS:0x0 ID:323 IpLen:20 DgmLen:40
> ***A*R** Seq: 0x0  Ack: 0x474A0001  Win: 0x0  TcpLen: 20
> [Xref => http://rr.sans.org/firewall/egress.php]
>
> The MAC addresses and part of the target address are obfuscated.
>
> My sensor is located within a subnet of the university network,
> and the MAC address of the "source" is that of our subnet border
> router.  The packets do not, therefore, originate from within
> our subnet.  Conversations with other sysops indicate that these
> packets are observed more-or-less everywhere within the university
> network.
>
> The target ports vary between 1000 and 2000 exclusively, with the
> lowest number I have seen being 1002 and the highest 1999.  The
> source port is always 80, and the packets are always ACK-RST.  The
> window size is always zero.
>
> Traffic can be spotty.  We may see lots of these for a couple of
> days, followed by none at all for most of a day, and then it will
> pick up again.
>
> Target machines include unix boxes, Macs, and PCs.  Boxes which
> are most active on the network receive more of these packets than
> do others.  For instance, our mail server has received 501 since
> early Sunday morning, and one of our webservers 217, while a
> typical PC got 15 during the same interval.  About half the
> machines in our subnet have received none at all.
>
> I don't know why loopback traffic is being allowed to pass our
> internal routers; in any event I have no control over them.  It
> is possible there is something here I don't understand, but it
> seems to me that such traffic shouldn't be allowed out of or into
> a subnet -- much less in through our border routers, if that's
> where it's coming from.
>
> I have tried Google, and what I find is other people asking the
> same question, but few answers.  One such suggested that these
> packets could be a sort of recon, but I don't see how:  Any
> response generated by the probed box would never get back to
> the source.
>
> I would be most grateful if anyone could explain what's happening
> here.
>
> Best regards,
>
> Neil Dickey, Ph.D.
> Research Associate/Sysop
> Geology Department
> Northern Illinois University
> DeKalb, Illinois
> 60115
>
> ---------------------------------------------------------------------------
> ----------------------------------------------------------------------------
>
>  



---------------------------------------------------------------------------
----------------------------------------------------------------------------