snort's reporting Bad traffic...

TheIrish · 12-01-2003, 03:29 PM

Hi all,
I know this question has already been made, but since there weren't any real answer, I ask again so if anyone understood anything...
Recently snort started reporting a lot of s**t like this:

[**] [1:528:2] BAD TRAFFIC loopback traffic [**]
[Classification: Potentially Bad Traffic] [Priority: 2]
12/01-22:16:37.405399 127.0.0.1:80 -> ppp0.address:1493
TCP TTL:122 TOS:0x0 ID:53438 IpLen:20 DgmLen:40
***A*R** Seq: 0x0 Ack: 0x5BAE0001 Win: 0x0 TcpLen: 20

Even a newbie would understand this is something strange.
So, looking over the net, I found out many people are seeing these ghosts.
In a snort-mailinglist, THEY gave an explaination that seems quite strange to me.

Quote:

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

ort 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

First, in this explaination, some parts look... ehm, meaningless
Second, windowsupdate.com? I have a Linux only LAN
Please someone let us know, I'm getting paranoic again

PS: almost forget, iptables is not logging a single packet of this s**t !!!

TheIrish · 12-02-2003, 11:27 AM

Hi, this post seems to have no success at all eh?
Anyway, I found out what it is. If you're experiencing the same problems, post here or email me for advices.

unSpawn · 12-02-2003, 02:13 PM

Hi, this post seems to have no success at all eh?
Dunno. Speaking for myself, since I'm a moderator here I usually don't handle posts the same day unless the urgency/general importance for LQ is above my threshold (please don't mistake this for arrogance, if you need details, email me).

Anyway, I found out what it is. If you're experiencing the same problems, post here or email me for advices.
With all due respect, but that's not how we like to do it here at LQ.
I'll give you two reasons:
- It's not respectful towards LQ. LQ provides you with information, you should add where you can.
- It doesn't give a clue. Think people who stumble on this thread later on. We're also good on Google. What impression do you think it leaves, seeing another thread with again no answer?

If you're not going to post what you found out, I guess someone will have to dissect the rule and alert themselves. If no one does, I will.

TheIrish · 12-02-2003, 03:39 PM

Quote:

It's not respectful towards LQ. LQ provides you with information, you should add where you can.
- It doesn't give a clue. Think people who stumble on this thread later on. We're also good on Google. What impression do you think it leaves, seeing another thread with again no answer?

Sorry, unspawn. Both points are correct but as many people here, I have time to make questions and a little time to post replies.
So, for not leaving this thread without reason of being here, I'll post the solution.

* * *
If you find

Code:

[**] [1:528:2] BAD TRAFFIC loopback traffic [**]
[Classification: Potentially Bad Traffic] [Priority: 2]
12/01-22:16:37.405399 127.0.0.1:80 -> ppp0.address:1493
TCP TTL:122 TOS:0x0 ID:53438 IpLen:20 DgmLen:40
***A*R** Seq: 0x0 Ack: 0x5BAE0001 Win: 0x0 TcpLen: 20

in your snort logs, it might seem you've got a worm in your box or network.
It might be, but may be the contrary.
The first thing is to understand if this traffic is coming in from the outside or it's generated by you.
In the specific case, this traffic is generated by another mutation of the blaster worm (which infects win boxes).
One of the side effects of this worm is sending spoofed packets through the network using 127.0.0.1 as source address.
So snort is not logging traffic involving your loopback interface, as it seems.
The reason for iptables isn't able to log those packets is easy: since the source address (127.0.0.1) is for local use only, iptables discards the packets in the prerouting
phase. If you log the packets in prerouting, you'll be able to see them.

Is this traffic dangerous? who knows. Apparently not, since there shouldn'be be a way for it to get in. Probably this is only a side effect.
What can we do? apparently nothing. Just keep ourselves as clean as possible from virus and give up using W... ok, you know what I mean.

unSpawn · 12-02-2003, 08:53 PM

I have time to make questions and a little time to post replies.
So, for not leaving this thread without reason of being here, I'll post the solution.
You know we all appreciate that.

I'll add a some rule-reading as well. Dunno if it's usable. [1:528:2] Let's look at the rule, it's SID is 528: grep bad-traffic.rules -e 528: alert ip any any <> 127.0.0.0/8 any (msg:"BAD-TRAFFIC loopback traffic"; classtype:bad-unknown; reference:url,rr.sans.org/firewall/egress.php; sid:528; rev:4;)
What does it say? "Alert where traffic protocol matches IP, AND IP address matches any, AND port matches any, AND where flow matches any, AND where IP range matches the 127 class A, AND where port matches any. My first remark would be this rule doesn't use $HOME_NET and/or $EXTERNAL_NET variables, meaning you cant tweak that part to minimise FP's (false positives). It also doesn't do *any* additional packet characteristics or content matching, which makes it a "weak" rule and bound to pick up FP's.

What are *you* seeing? 127.0.0.1:80 -> ppp0.address:1493 TCP TTL:122 TOS:0x0 ID:53438 IpLen:20 DgmLen:40 ***A*R** Seq: 0x0 Ack: 0x5BAE0001 Win: 0x0 TcpLen: 20 Alert on remote address 127.0.0.1, remote port 80, to local $HOME_NET local unprivileged port, protocol TCP, TTL 122, IP header details, TCP flags , TCP header details. So, if we assert this is coming from the outside, we have: from remote spoofed address (unroutable) port 80 (privileged port), to local unprivileged port (client), with flags indicating end of the session (FIN or RST) and ACK is set when it's part of an existing one. If you didn't know it was Blaster, then if you assert the TTL real, it's value is 122. OSes with a high default TTL (128) include MICROS~1 , Cisco and Solaris.

Can we positively profile this packet as Blaster or related? No, not without knowing any details wrt connection and payload. http://securityresponse.symantec.com...ster.worm.html (old) shows details that are in line with your story, so this could definately be fallout from the DoS against windowsupdate.com per the "bad advice" thingie.

Is this traffic dangerous? who knows. Apparently not
Nope. It's "waste", it's inert, it's Blaster related but only in the way caymans are related to crows.