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.
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.
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?
DocumentationCode download linksGoalRequirementLimitationsSupported ISR and UCS-E ModelSupported ISRG2 and UCS-E Blades:Supported ISR4K and UCS-E Blades:Step by Step ConfigurationConfigure one of the connectivity options to access the Cisco IMC from the n...
Firepower Threat Defense (NGFWv) on UCS E-series - Transparent Mode in HA
DocumentationCode download linksGoalRequirementLimitationsSupported ISR and UCS-E ModelSupported ISRG2 and UCS-E Blades:Supported ISR4K and UCS-E Blades:Step by Step ConfigurationCo...
I am currently unable to specify "crypto keyring" command when configuring VPN connection on my cisco 2901 router.
The following licenses have been activated on my router :