Journal heliocentric's Journal: Grepping for inbound... 6
First, a little background. For those who don't remember this post I made a little comment about grepping for inbound boobies, and for me and my silly little group of flesh and blood friends this has remained a fun little phrase. Second item of interest, verizon is blocking inbound port 80 traffic to their DSL customers - or atleast the ones with cheap residential service and in my area (Pennsylvania). They started doing this when Code Red was out there and they appear to have no interest in stopping. Third item, at home I just happen to have verizon residential DSL.
Ok, now, with all of that out of the way we can begin with the interesting bits. In going through my firewall logs I saw some inbound port 80 activity and thought verizon finally stopped the filtration. Then I noticed it was a very odd IP, and only that IP is doing the poking on port 80. First thing I did was a quick nmap from another site, port 80 is still filtered and I didn't appear in my own firewall logs (for the port 80, other ports I did show up). So, how was this IP getting in my logs? My initial (and current) feeling is it must have originated from within verizon. Unless some really odd spoofing was in place and it was making it past the verizon filters... but I'm getting ahead of myself, first I want to show you the IP address: 0.24.10.144 Yes, marvel at it's wonders and it's spiffy little 0 in the beginning. Ever try to ping something like that, or maybe do some reverse DNS lookup? I'm wondering how in the world something like that could even work - I mean, if you spoof that IP and even just ping me, how can I pong back? If you claim to be that IP and poke for a port 80, how can you find out if it's open if I can't respond? This IP appears only for port 80, nothing else.
Any thoughts out there as to what/who might be creating such traffic? Suggestions for ways to inspect this?
My current thinking is to open port 80 at the firewall and leave it open and also forward it (I'm running a NAT deal at home) someplace in the network. At the same time have a sniffer running looking for port 80 traffic and that IP, then see if I can catch a MAC address. My question, however, is: will I see a MAC of the true originator or of my NAT which is just forwarding the traffic. I'm not that well versed in the workings of NAT'ing and port forwarding in this situation to know if it truely passes packets or does the NAT tabling. I'm hoping that by having the MAC I might atleast know what sort of machine I'm getting poked from (sun box, pc, cisco, etc...) - I know it's nothing too specific, but it will be more information than what I have currently.
What I can't explain is if it truely is Verizon poking at clients for rogue web servers, why are they bothering to cover their IP? Suggestions? What comes to mind about the cause of this thing? Any flaws in my plan to catch the MAC?
You know you're a geek when searching for this IP on your network is more interesting than grepping for inbound boobies.
Multiple things spring to mind. (Score:2)
So don't even think of getting the originator's MAC address. You won't, unless there is bridged traffic between you and them, which we know isn't the case since the Internet works with routing, not bridging.
Then, there is the mysterious 0.x.x.x network address. This does not appear to be a valid IP network, even when using the Cisco ip subnet-zero feature. See my transcript below:
HERUGA(config)#ip subnet-zero
HERUGA(config)#int eth0/0
HERUGA(config-if)#ip add 0.24.1.1 255.255.255.0
Not a valid host address - 0.24.1.1 HERUGA(config-if)#
It's possible that someone is spoofing their IP address and sending packets to you with an illegal return IP address, perhaps hoping to crash your machine. God knows. In any case, try to traceroute (tracert under Windows) to this IP address and see if you can even leave your PC and reach the next hop. It seems unlikely to me, but who knows.
In case you are able to reach this IP address somewhat, try to figure out what kind of device it is ! Try telnet, nmap -O, etc.
You may have to install a sniffer and let it run for port 80 (inbound) and see what you get. If you get a TCP SYN, SYNACK/ACK, ACK in sequence, then we know that there is something out there which is routable and which is poking you around. If all you get are SYN's then it may simply be a probe or exploit targetted at your IP address.
Re:Multiple things spring to mind. (Score:2)
www [7:27am] charlie [/home/charlie]> traceroute 0.24.10.144
socket: Invalid argument
I think that it's needless to say this isn't a proper IP. Your suggestion that maybe this IP type is a vulnerable thing to certain hardware seems very possible, however I would think it would need to originate very close to me (inside Verizon) since:
A) it's a port 80 thing, and remember they are blocking port 80
B) what router in it's right mind is going to route an IP like that?
If a crash is the intention and it is originating from withtin Verizon then why is this from Verizon? I mean, I know their EULA says I'm not to like run major biz stuff off of my connection, but I don't recall it saying "We're gonna crash your box for having a web server." If they got hacked and the best the intruder can do is spoof a funked out IP in order to hurt client boxen I'm not too impressed - getting my account info and ability to play with zone transfers seems a slightly more interesting trick.
Oh, and by the way, this wasn't just a one time thing, it appears to be at the least daily - sometimes two to three times a day. Also, I haven't locked it down to regular time intervals, but there hasn't been a day in the past two weeks that it hasn't appeared.
Re:Multiple things spring to mind. (Score:2)
A feature of most routers is to check wether the origin network is routable before forwarding a packet, therefore only allowing traffic coming from a valid IP address. But most providers don't normally enable this feature on their routers, because it causes heavier CPU utilization and because they don't really care either.
It will be interesting to sniff your traffic over a few days (only capture those incoming port 80) and check the incoming packets out.
Feel free to let me know if you have such a sniffer trace available some time :)
Could be... (Score:1)
Trif
Re:Could be... (Score:2)
As for your question about IE and web pages, I get that IP in the log when I'm not at home, during times I am using IE (but it's not like it hits everytime IE loads a page), and why in the world would it be inbound port 80?