Define this network behavior

I initially discovered I was having a peering problem by performing a traceroute:

traceroute: Warning: www.google.com has multiple addresses; using 208.67.219.231
+traceroute to google.navigation.opendns.com (208.67.219.231), 64 hops max, 40 byte packets+
+1 192.168.1.1 (192.168.1.1) 0.959 ms 0.658 ms 0.653 ms+
+2 cpe-76-95-80-1.socal.res.rr.com (76.95.80.1) 12.597 ms 12.703 ms 8.229 ms+
+3 24.24.193.145 (24.24.193.145) 13.410 ms 12.509 ms 12.428 ms+
+4 ae5-chswca1-rtr2.socal.rr.com (66.75.145.28) 12.896 ms 14.031 ms 13.275 ms+
+5 ge-4-3-0.tustca1-rtr1.socal.rr.com (66.75.145.13) 15.249 ms 15.197 ms 14.844 ms+
+6 ae-5-0.cr0.lax30.tbone.rr.com (66.109.6.64) 19.756 ms 36.849 ms 68.577 ms+
+7 ae-1-0.pr0.lax10.tbone.rr.com (66.109.6.131) 17.338 ms 17.727 ms 18.051 ms+
+8 * * *+
+9 te8-1.ccr01.lax01.atlas.cogentco.com (154.54.0.213) 31.040 ms te4-2.ccr01.lax01.atlas.cogentco.com (154.54.6.229) 18.951 ms te7-4.ccr01.lax01.atlas.cogentco.com (154.54.3.9) 89.567 ms+
+10 te3-1.ccr02.sjc01.atlas.cogentco.com (154.54.5.185) 28.293 ms 29.853 ms te9-3.ccr02.sjc01.atlas.cogentco.com (154.54.25.186) 28.882 ms+
+11 te7-2.ccr02.sjc03.atlas.cogentco.com (66.28.4.78) 42.413 ms 29.635 ms 28.248 ms+
+12 te9-3.mpd01.sjc04.atlas.cogentco.com (154.54.0.170) 29.837 ms te4-3.mpd01.sjc04.atlas.cogentco.com (154.54.24.141) 29.947 ms te9-3.mpd01.sjc04.atlas.cogentco.com (154.54.0.170) 29.393 ms+
+13 38.104.140.46 (38.104.140.46) 30.549 ms 31.876 ms 32.086 ms+

The problem lays at hop 8 between

ae-1-0.pr0.lax10.tbone.rr.com

and

te8-1.ccr01.lax01.atlas.cogentco.com

This problem has been persistant for at least one week.

Later in my firewall log I discovered a large number of stealth mode connection attempts paired with nmblookup querys all pointing to IP 38.118.213.10.

Whois shows 38.118.213.10 as belonging to atlas.cogentco.com.

So I'm having peering problems with atlas.cogentco.com, and I am also being attacked by someone or something over there?

iMac 2.4 GHz Intel Core 2 Duo, 4 GB RAM, Mac OS X (10.5.7), Bootcamp 50 GB Windows 7

Posted on Jul 5, 2009 2:13 PM

Reply
27 replies

Jul 5, 2009 3:19 PM in response to Bang A. Lore

There is a problem on hop 8. Can't you see that? Another user advised me that I am having a peering problem between the two servers and that I should report this problem to them.

Now I'm seeing stealth connection attempts from this same server to my local IP.

How is this "imagined"?

None of this bothers me as it's occurring on a test system. I am trying to understand the behavior, not necessarily find a fix.

What does "Bang A. Lore" mean?

Jul 5, 2009 3:34 PM in response to pianoman1976

First of all, you're not having peering problems with Cogent. Your ISP may be, but even that's not apparent from the traceroute.

It's easy to read too much into a traceroute. In this particular case, all the traceroute says is that whatever device is at hop 8 does not respond to traceroute and/or ICMP traffic. That is the only thing you can deduce.

While it's common for internet routers to respond to ICMP and traceroute traffic, they are not required to. As such, the lack of response does not mean the device is faulty in any way. In fact, looking at the other data in the traceroute, it seems that there isn't much wrong with the connection at all. The reply times ramp fairly smoothly through each hop - from an average of 11ms at your ISP connection through to 31ms at google. The only outliers are the 68ms response at hop 6 and the 89ms at hop 9.

The only slightly unusual, but not necessarily problematic, elements are the multiple hostnames at hops 9 and 12. Differing hostnames in the reply usually indicate some kind of load-balanced setup where one reply takes one path and the subsequent reply takes a different path. This isn't necessarily a problem, especially if both links are expected to be active (as opposed to one link being active and the second link only coming live in a failover situation). There's no way you can tell whether this is normal or not without talking to Cogent.

The only real question here is what makes you think you have a problem?

Later in my firewall log I discovered a large number of stealth mode connection attempts paired with nmblookup querys all pointing to IP 38.118.213.10.


I think that IP coming from Cogent, and your assumption about your traceroute are purely coincidental.

The 38.118.213.10 address maps to somewhere in Chicago, so is unlikely to be related to your traceroute to Google, which doesn't go anywhere near Chicago. It sounds like normal internet noise to me (and something that should normally be filtered at your router/firewall and should never, ever hit your system.

Jul 5, 2009 3:47 PM in response to Camelot

Camelot wrote:


The only real question here is what makes you think you have a problem?



A user here with decent reputation told me so.

Then the "coincidence" with Cogent items showing up in my Firewall log and raised more curiosity.

I didn't know that a plethora of repeated stealth connection attempts and nmblookup queries were considered normal "internet noise".

Jul 5, 2009 4:04 PM in response to pianoman1976

pianoman1976 wrote:
A user here with decent reputation told me so.


The only problem you have is that you've seen way too many bad cybercrime movies and are now compulsively digging through logs you have absolutely no hope of comprehending and seeing imaginary attackers at every turn. What is it that you have on your computer that you think these etherial master hackers at Cogent are after exactly? Some pirated Ghost in the Shell DVD rips?

Jul 5, 2009 4:17 PM in response to Bang A. Lore

Bang A. Lore wrote:
pianoman1976 wrote:
A user here with decent reputation told me so.


The only problem you have is that you've seen way too many bad cybercrime movies and are now compulsively digging through logs you have absolutely no hope of comprehending and seeing imaginary attackers at every turn. What is it that you have on your computer that you think these etherial master hackers at Cogent are after exactly? Some pirated Ghost in the Shell DVD rips?


lol.

That's not it at all.

I'm not bothered or paranoid. I keep all my illegal pornogrpahy, meth recipes and plans to over-through the government off any system that connects to the net. This system in question is my test system that typically undergoes a new OS install every week. I mess around with it, as this is how I learn. I'm really interested in UNIX and networking right now.

I enjoy this stuff immensely and appreciate the time other users take to inform me on these matters.

Message was edited by: pianoman1976

Message was edited by: pianoman1976

Jul 5, 2009 8:43 PM in response to pianoman1976

I've read the original thread now (don't know why I missed it before since I hang out in that forum, too).

In this particular cast, Brody is misguided. It doesn't indicate a peering problem at all - at least, not directly or definitively.

Neither Cogent nor Roadrunner are going to take any action if you called them since packets are clearly passing through whatever device it is that isn't responding to the trace, and like I said the trace times are consistent, which indicates that the traffic isn't passing through a bottleneck and getting slowed down.

Furthermore, if it were a peering problem and packets were getting dropped at that point, all points beyond that link would also show a problem - either intermittent replies (since either the trace ping or the reply got dropped at the peering point), or a marked increase in response time (because either the ping or the reply was getting held up). Neither of these is the case, ergo there is no peering problem.

As for hop 14 - the * * * that indicates you've hit a firewall that's not passing traceroute traffic. That doesn't indicate a problem at all, just that you're blind beyond that point and have no idea what devices are behind the firewall. Many sites do this - try tracerouting to www.apple.com sometime and see what you get. It doesn't indicate there's any kind of problem, especially if you can actually hit the site in question. It just means the network admins at that site don't care to let you traceroute into their network.

Jul 5, 2009 9:09 PM in response to pianoman1976

Well thank you team. Good learning going on here! My only remaining question is if repeated stealth mode connection attempts are considered normal "internet noise" as previously stated on this thread. Could someone comment on this?

Here's a typical instance of what I see quite frequently on this system:


+Jul 5 20:57:11 XXXX Firewall[38]: Stealth Mode connection attempt to TCP 192.168.1.140:53094 from 204.160.122.126:80+
+Jul 5 20:57:11 XXXX Firewall[38]: Stealth Mode connection attempt to TCP 192.168.1.140:53092 from 204.160.122.126:80+
+Jul 5 20:57:11 XXXX Firewall[38]: Stealth Mode connection attempt to TCP 192.168.1.140:53095 from 204.160.122.126:80+
+Jul 5 20:57:11 XXXX Firewall[38]: Stealth Mode connection attempt to TCP 192.168.1.140:53096 from 204.160.122.126:80+
+Jul 5 20:57:15: --- last message repeated 1 time ---+
+Jul 5 20:57:15 XXXX Firewall[38]: Stealth Mode connection attempt to TCP 192.168.1.140:53095 from 204.160.122.126:80+
+Jul 5 20:57:15 XXXX Firewall[38]: Stealth Mode connection attempt to TCP 192.168.1.140:53092 from 204.160.122.126:80+
+Jul 5 20:57:15 XXXX Firewall[38]: Stealth Mode connection attempt to TCP 192.168.1.140:53094 from 204.160.122.126:80+
+Jul 5 20:57:21 XXXX Firewall[38]: Stealth Mode connection attempt to TCP 192.168.1.140:53096 from 204.160.122.126:80+
+Jul 5 20:57:21 XXXX Firewall[38]: Stealth Mode connection attempt to TCP 192.168.1.140:53095 from 204.160.122.126:80+
+Jul 5 20:57:21 XXXX Firewall[38]: Stealth Mode connection attempt to TCP 192.168.1.140:53092 from 204.160.122.126:80+
+Jul 5 20:57:21 XXXX Firewall[38]: Stealth Mode connection attempt to TCP 192.168.1.140:53094 from 204.160.122.126:80+
+Jul 5 20:57:33 XXXX Firewall[38]: Stealth Mode connection attempt to TCP 192.168.1.140:53096 from 204.160.122.126:80+
+Jul 5 20:57:33 XXXX Firewall[38]: Stealth Mode connection attempt to TCP 192.168.1.140:53095 from 204.160.122.126:80+
+Jul 5 20:57:33 XXXX Firewall[38]: Stealth Mode connection attempt to TCP 192.168.1.140:53092 from 204.160.122.126:80+
+Jul 5 20:57:33 XXXX Firewall[38]: Stealth Mode connection attempt to TCP 192.168.1.140:53094 from 204.160.122.126:80+

Jul 6, 2009 8:41 AM in response to pianoman1976

My only remaining question is if repeated stealth mode connection attempts are considered normal "internet noise"


Do you happen to be running a ping or traceroute at the time these come in?

The interesting thing here is that it's the destination port (on your machine) that is changing, with the source port (on the remote machine) being static (all hits come from port 80).

The same set of port numbers are being hit every few seconds. They don't increase over time, so that (should) exclude a traceroute or similar.

Overall the volume of traffic isn't sufficient to bother me - it really is just noise, and clearly nothing's getting through to anywhere (other than your logs). If you're really bothered, though, setup a server to listen to those ports and see what comes in.

I'd be more concerned, though, that these packets get to your machine at all. Why is your router letting these packets into the local network?

Finally, if you do want to escalate, the IP address maps back to Level3, so copying the log in an email to abuse@level3.net is probably your only practical action.

Jul 6, 2009 10:28 AM in response to Camelot

Thanks Camelot.

No, I was not running a ping or traceroute at the same time.

I'll have to look into why my router is letting these packets into the local network. I use a Linksys WRT WiFi router with Tomato firmware. I have the radio turned off and use it as a hardwired ethernet router. At the moment, I know a lot about a little with this new firmware I'm running. I'm sure there is a way to block this traffic, I'll check into it.

And I appreciate your advice as to how escalate.

I think we're done.

This thread has been closed by the system or the community team. You may vote for any posts you find helpful, or search the Community for additional answers.

Define this network behavior

Welcome to Apple Support Community
A forum where Apple customers help each other with their products. Get started with your Apple Account.