Wow, not a Juniper post. I bet those of you who don’t use Juniper are excited? Today is a handy blog for your toolbox. I work on older hardware now that I am an ex-gamer and dedicating my time to further my knowledge and pursuing my life goals. I am using an older OSX based machine. Running OSX 10.6, I wanted to figure out a way to perform a ping sweep on a subnet without installing extra software. I am a big proponent of using out of the box software where possible.
After researching a little I conjured together my cheap trick. Have a look at this and tell me what you think.
for i in {1..254}; do ping -c 1 -W 1 192.168.1$i | grep 'from'; done
I am choosing to grep the output with the word from. It will be
Dreamspike:~ pandom_$ bash
bash-3.2$ for i in {1..254}; do ping -c 1 -W 1 192.168.15.$i | grep 'from'; done
64 bytes from 192.168.15.2: icmp_seq=0 ttl=64 time=0.058 ms
64 bytes from 192.168.15.25: icmp_seq=0 ttl=64 time=0.070 ms
64 bytes from 192.168.15.128: icmp_seq=0 ttl=64 time=0.042 ms
64 bytes from 192.168.15.143: icmp_seq=0 ttl=64 time=0.076 ms
This is a great way of finding out what hosts are responding to icmp on your network segment. Remember that devices may not respond to ICMP replies but be active. Kurt Bales (check that new logo out!) suggested using nmap and using the following
nmap -sP 192.168.15.*
Not bad if you run Nmap. Much cleaner.
Dreamspike:~ pandom_$ nmap -sP 192.168.15.* Starting Nmap 6.25 ( http://nmap.org ) at 2012-12-19 10:40 EST Nmap scan report for srp527w (192.168.15.1) Host is up (0.023s latency). Nmap scan report for 192.168.15.2 Host is up (0.00047s latency). Nmap scan report for 192.168.15.4 Host is up (0.065s latency). Nmap scan report for 192.168.15.9 Host is up (0.043s latency). Nmap done: 256 IP addresses (4 hosts up) scanned in 16.83 seconds Dreamspike:~ pandom_$
It is much faster to yield responses too. He also went on to state the learning the scripting combo described earlier is far more powerful as it can lead to the creation of better things. Hope this helps. Enjoy and Happy Holidays.
Useful post Anthony. Sometimes Static NAT can hide your subnets and block the above approaches. E.g. If you only have one or two IPs in a range natted, you have to ping from the NAT’ing router. It’s not ideal but running the following command from tclsh can be helpful.
for {set z 1} {$z<254} {incr z} {ping ip "192.168.15.$z" repeat 2}
I'm sure it can be extended to grep for the ! response.
Thanks John. I am a virgin when it comes to scripting and it took me a while to get what I wanted. It is a marvellous feature. “You’ve just taken you’re first step into a larger world” comes to mind.
It is worthy to note your comments about NAT. TCL would be much easier and far more beneficial from a device.
I was just thinking for local subnet when I had made this and didn’t make any considerations for anything else. I generally don’t allow ICMP reply for a lot of devices so this tool would be one of many to use.
I am going to compile some of my favourite and safe NMAP scans I feel next.
Thanks John. I am a virgin when it comes to scripting and it took me a while to get what I wanted. It is a marvellous feature. “You’ve just taken you’re first step into a larger world” comes to mind.
It is worthy to note your comments about NAT. TCL would be much easier and far more beneficial from a device.
I was just thinking for local subnet when I had made this and didn’t make any considerations for anything else. I generally don’t allow ICMP reply for a lot of devices so this tool would be one of many to use.
I am going to compile some of my favourite and safe NMAP scans I feel next.
NMAP and bash are definitely the way to go. Plenty of installed linux machines that don’t have it installed, and people can get a bit pissy when you ask. The TCL is a real edge case, but still handy to have on the bottom tray of your toolbox.
Using nmap -sP will also give you more accurate results when you are acutally connected to the network segment. The reason is that Nmap will use ARP requests/replies in that situation instead of ICMP. And ARP is less likely to be blocked by packet filters. Just rerun your scan with “nmap -sP –packet-trace 192.168.15.*”. The packet trace option is great for learning Nmap and figuring out what it is doing.
Very nice. The moment you said it uses ARP vs ICMP I just thought how much quieter that would be. I feel a few Junos Screens/ASA rules vs nmap may be in order.
Thank you Jochen.