cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
837
Views
0
Helpful
8
Replies

LocalHost Sigs 1104 on external sensor

community
Level 1
Level 1

I recieve several 1104 Local host signatures on my outside sensor, what is the best defense for this?

8 Replies 8

mcerha
Level 3
Level 3

When this signature fires, it often indicates a misconfigured/malfunctioning piece of network gear. If the suspect traffic is coming from outside your network, blocking 127.0.0.1 at the firewall would be prudent.

It is set to shun this traffic. Will that effect the sensor by blocking the loopback?

I have been seeing this traffic for some time now. During any given session when this is active I can see 3000-4000 1104 signatures triggered.

My DMZ has two Cisco Routers, one configured with zero ACLs, and the second with my full ACL list. This allows me to place a sensor 'on my internet' connection so to speak (between the two routers).

I see localhost traffic at that point.

I then have a sensor monitoring traffic between the 2nd router and my first perimeter firewall. I see localhost traffic at that point also.

The first firewall drops the localhost traffic.

I placed an ACL on the ISP side of my first router and found that it triggered logging indicating that packets were coming IN to my network with 127.0.0.1 already set (routers route based on destination IP not caring what the source IP is).

This shows that my network is not misconfigured, rather I am receiving traffic either from a misconfigured ISP (Time Warner) or someone is actually crafting packets with this source IP.

If you sniff the traffic, you may notice something charecteristic about them. In my case the incoming packets all have a s_ip of 127.0.0.1, a s_port of 80 and the FIN/ACK flags set.

Certainly no response will ever make it back to the true source, and so the question is, why would someone scan like this?

There's no data in the packet, so there's nothing covert going on. My guess is either my ISP is truly misconfigured or the source of this traffic is trying to 'snowblind' my security process and cause me to focus on the scan and miss the real attack. (which of course doesn't happen).

I've been experiencing this situation for some time now, and have not had a solid resolution to the problem.

I'd be interested to hear what the contents of your localhost packets are like.

I do not have a sniffer to analyze the traffic, my attack numbers aren't quite as high as your but are rapidly climbing daily. I too have ruled out a misconfiguration as my sensor is outside the network with inbound traffic being detected.

darin.marais
Level 4
Level 4

The URL below points to a theoretical answer as to why you may be receiving the event "localhost" at the sensor. (s_ip of 127.0.0.1, a s_port of 80 and the FIN/ACK flags set)

http://forum.cisco.com/eforum/servlet/NetProf?page=netprof&CommCmd=MB?cmd=display_location&location=.eea1a4b

I apologise if you have already seen or know about the theory as my reply is slightly off the originally question which was

“What is the best defence for this?”

However perhaps by understanding where the traffic is coming from it may help you in your decision process.

I do hope that the information that I have provided you with is helpful.

Well bugger me, I like that explanation. Had no idea windowsupdate.com was set to 127.0.0.1

I should state that we changed ISPs for our local Internet DMZ to Time Warner (about 3 weeks ago) and just started seeing this deluge of alarms. So I haven't been living with it for months, obviously Time Warner needs to not route s_ip 127.0.0.1

And so do I :)

Just one last thing, which still doesn't make me feel totally warm/fuzzy about the above explanation, is that windowsupdate.com doesn't resolve to 127.0.0.1 anymore, in fact it doesn't resolve to anything.

So either there are Blaster machines _still_ trying to DOS windowsupdate.com (without fresh queries to DNS) or this is something different (i.e. have any other notable DOS targets changed their DNS resolution to 127.0.0.1)?

Speaking of which, in hindsight, would it not have been better for Microsoft to have simply removed the IP address entry from DNS rather than change it to 127.0.0.1?

The theory makes sense but I have already scanned all internal systems for any virus/worm activity and the inside sensor is not picking up an any internal activity.

Since you mentioned it was your outside sensor, infected machines are just scanning your networks because it is part of the same Class B that the infected machine is also located on.

Nothing specifically directed to you.