Tiny Deathstars of Foulness

You can do some pretty simple testing of ports and network communications using strategies I’ve outlined in the past with tcpdump, trace route, telnet, curl, stroke and of course ping. However, netcat has a few interesting things you can do with it; namely actually run a port super-quickly to test traffic between subnets, forcing scans of ipv6 traffic, debugging sockets, keeping connections alive, parodying through SOCKS 4 and 5 and just checking for daemons that are listening rather than actually sending data to them. In this first example, we’re going to just check that Apple’s web server is accessible (adding -v for verbose output): /usr/bin/nc -v 80 The result would be pretty verbose
found 0 associations found 1 connections: 1: flags=82<CONNECTED,PREFERRED> outif en0 src port 50575 dst port 80 rank info not available TCP aux info available Connection to port 80 [tcp/http] succeeded! HTTP/1.0 408 Request Time-out Server: AkamaiGHost Mime-Version: 1.0 Date: Tue, 29 Jul 2014 15:41:34 GMT Content-Type: text/html Content-Length: 218 Expires: Tue, 29 Jul 2014 15:41:34 GMT <HTML><HEAD> <TITLE>Request Timeout</TITLE> </HEAD><BODY> <H1>Request Timeout</H1> The server timed out while waiting for the browser’s request.<P> Reference&#32;&#35;2&#46;48cf4d17&#46;1406648494&#46;0 </BODY></HTML>
If we added a -w to timeout we’ll cut out all the cruft (but wouldn’t know that the server’s at Akamai). Next, we’ll get a little more specific and fire up a test to check Apple’s push gateway at, using port 2195: /usr/bin/nc -v -w 15 2195 But, I want the cruft for the purposes of this article. Next, we can add a -4 to force connections over IPv4 and check the Apple feedback server and port 2196, also required for APNs functionality: /usr/bin/nc -v -4 2196 Right about now, something is probably happening at Apple where they’re getting sick of me sending all this data their direction, so let’s add a -z option, to just scan for daemons, without actually sending any data their way: /usr/bin/nc -vz -4 2196 Because of how NAT works, you might notice that the src port keeps changing (incrementing actually). Here’s the thing, we’re gonna’ go ahead and force our source port to stay the same as our destination port using the -p option: /usr/bin/nc -vz -4 -p 2196 2196 Now, what if this is failing? Well, let’s spin up a listener. I like to start on my own subnet, then move to another subnet on the same network and ultimately to another network so I’m checking zone-by-zone so-to-speak, for such a failure. So, we can spin up a listener with netcat in a few seconds using the -l option on another host: /usr/bin/nc -l 2196 Then I can scan myself: /usr/bin/nc 2196 I could also do this as a range if I forgot which port I used per host: /usr/bin/nc 2195-2196 Now, as is often the case, if our connection problem is because data isn’t parodying, we can also use nc to check that using the -x operator followed by an IP and then : and a port. For example: /usr/bin/nc -vz -4 -w 10 -p 2196 -x 2195-2196 Fun times with push notifications. Enjoy.

July 29th, 2014

Posted In: Mac Security, Mass Deployment, MobileMe, Network Infrastructure

Tags: , , , , , , , , , , , , , ,