I had an outage this morning, otherwise I wouldn’t have been checking.
My company has a Business DSL Service contract with AT&T, previously BellSouth. Just recently they turned up the throughput on our circuit as part of a promotion to let everyone in the neighborhood know that it can finally go faster. (It’s still not as fast as broadband, but broadband isn’t available on our block.) Incidentally, we’re located in the metropolitan sprawl-swamp north of Atlanta, GA, just off of GA 400 (a.k.a the Alpharetta Autobahn).
The IP addresses noted above, 205.152.37.23 and 205.152.144.23, are the primary and secondary nameservers assigned my company’s DSL router (via an automatic DHCP-like transaction, I assume) when it syncs up with the upstream router/DSLAM. So basically our own primary and secondary nameservers just portscanned us.
What were they looking for? They were looking to see if we had any UDP ports open on our network for port numbers 12113, 12123, 12125, 12133, 12141, and 12156. It took some digging to find this out, but a few of those ports are associated with projects like eMule and uTorrent. You know. Peer-to-peer filesharing networks. Big surprise. AT&T shouldn’t care what traffic I accept or generate, but apparently they do. As if a portscan will actually reveal what service is on the other end of it. As if running said services actually reveals illegal sharing of data/copyright violations.
Anyway.
I was logged into the Netopia 3347NWG DSL router this morning, asking it what it thought the problem was. I clicked on a little Alert icon and this was what it showed me. I printed it out, just in case the security logs get wiped out when you reset the router. And it seems they do. But what this is saying is that the DSL router blocked their portscan. This is the DSL router THEY issued us. With the default firewall/security config. THEY scanned us, and the basic hardware THEY shipped us with the default firewall config THEY ship it with stymied them.
And then the DSL SYNC light on the router went out. And we lost dial-tone on that phone line. Then, after a few minutes, dial-tone came back. I had to call them up and get them to twiddle things to get service restored–but while I was talking to my tech, the call dropped. She called me back on another line and we continued the troubleshooting process.
The outage is possibly unrelated–as I mentioned, I was having problems before the portscan or I wouldn’t have been logged into the router to check on things–but there’s still something laughable about their own hardware getting in the way of their own snooping.
Futher: While on hold and waiting for the DSL service tech, I listened to a recording that told me that common connectivity problems could be solved by powering down the DSL modem (router) and turning it back on. They recommend this to everyone, for whatever reason, to every joker on hold.
I say, sure, this might help. But it will also most likely wipe your security logs. I highly recommend you connect to your DSL router first to review any interesting tidbits that might be in your security logs before you wipe them by following the snoopin’-ass bastards at AT&T’s blindly recommended procedure. They shouldn’t be snooping in the first place. Neither should they be recommending that you wipe the logs that would reveal suspicious Denial-of-Service traffic before anyone gets a chance to look at them. Especially if they’re the one generating said traffic.
In my opinion, my company is paying for connectivity and bandwidth and AT&T shouldn’t have the first thing to say about how we use it until served with a warrant signed by a judge. In fact, if AT&T is just personally curious as to what traffic we generate or accept, then they can damn well put a sniffer on the line and passively generate their histograms. I expect them to do so, frankly. But a portscan is basically prank-calling your network and seeing if anyone picks up the phone when you dial whatever numbers you dial. My router is busy enough without having to answer (or decide not to answer) prank calls. AT&T’s nameservers are busy enough looking up IP addresses for whatever machine/service names we supply in our thousands of URLs without also being tasked to run hack-attacks on my network. And the recommendation that you flush any evidence before you ask them to help you figure out what’s happening? Actionably stupid.
I suppose it’s also possible that their nameservers have been hacked and are hacking on someone else’s behalf, but I’d like to think they check for that periodically. Frankly, I recommend running public-facing nameservers off of CDROM and rebooting them every couple of hours, but that’s just me.
[*]