The seasoned security administrator needs to be comfortable at the command line. In this video, you’ll learn about some of the most important command line security tools for the security professional.
<< Previous Video: Software Security Tools Next: Common Security Issues >>
If you’ve ever needed a test to see if another device was available on your network, then you’ve probably used the ping command. The ping command can also be used to determine a round trip time between your device and another device on the internet using a protocol called the Internet Control Message Protocol, or ICMP. If you’re doing any type of network troubleshooting or security analysis, you will be using ping quite a bit. It’s usually the first thing that you use.
You want to know if a device is available, the first thing you try to do is to ping that device. This is a utility that was written by Mike Moose in 1983. So it’s been around for a while. He named it ping because that’s the sound used by sonar. Some people have stated that the term ping is an acronym for Packet Internet Groper. But, in fact, this was an acronym that was created after the fact, something we call a backroym. And Mike says, no. This is simply the sound that you make whenever you’re using sonar to try to find another device that might be out there.
Ping is a relatively easy utility to use. You simply type ping, and then the IP address of the device that you’d like to see is available. I’m going to use Google’s DNS server since that is not only easy to remember– the IP addresses 8.8.8.8– But it’s also an IP address that you could use if you’d like to try to ping this yourself. And now we get the results back from the ping. It tries on my machine until I choose to stop it with Control C.
You can see that it’s sending 64 bytes of data from 8.8.8.8. That’s what we’re receiving. It shows the sequence number of what we’re pinging. The time to live is 57. On my system, it probably starts with 64 as the time to live. And every time the packet goes through a router, it decreases by one. So you can guess by looking at the time to live just how many hops this had to go through to get back to my workstation. And the time it takes to be able to get round trip to that device is anywhere between 17, 14, 28 milliseconds. And you can see exactly how quickly we can get data between point A and point B.
And we know that 8.8.8.8 must be available because we’re receiving an answer back from that device. We can also use names. In ping, we could use the DNS capability. So I could ping www.professormesser.com, and we’ll get a response back from the Professor Messer server, or at least the device that sits in front of all the Professor Messer servers. And now you can see exactly how long it takes to get between this device and that web server. Another utility that’s available on many different operating systems is netstat. You can find netstat on Linux, on Unix, on Windows, and many others.
Netstat stands for network statistics, and it provides you with many different views of what the statistics are for network communications on that particular device. So, for example, if you wanted to see all of the active connections that were on an individual machine, you can run netstat dash a. On a Windows machine, you could combine the netstate dash a with the a netstat dash b, which would not only show you the number of active connections, it would tell you exactly the Windows binary that was used to create that connection across the network. And if you wanted to get rid of the resolved names and just get IP addresses with netstat, you can run netstat dash n.
Let’s run a netstat on my computer. I’m just going to run netstat with no other parameters, and it’s going to show me all of the network communications that I have made. You can see a number of them out to professormesser.com and to other web services. And you can see as it’s working through all of the active connections, it begins updating those on the screen. When we ran the ping command earlier, we could tell from the time to live settings that there were a number of hops between my computer and the Google DNS server. With the traceroute command, we could map out every single router along the way, and effectively build a map that shows the route between my system and another device.
If you’re running this utility on Linux or Mac OS, it’s the entire word trace route. If you are on Windows, it’s trace RT. Trace route uses a function of ICMP to be able to map out this network communication. If you ever send traffic that exceeds the time to live, that device will send a response back to you saying that it had to drop the packet because your time to live was exceeded. What we’ll do is send some messages out across the network with intentionally small time to lives that will automatically expire. So we should expect to receive a message back from a number of the devices out across the network.
Not every device will send you back a time to live exceeded message. So occasionally in your trace route, you’ll see asterisks appear instead of getting information about a route. And occasionally, once it gets past that particular router, it will pick up after that point and continue with its mapping function but you can always try running a trace route and see exactly what route happens to appear between you and the other device. Behind the scenes, here’s what’s really happening with traceroute. In this example, I’m going to be Sam, and I’m going to trace route to Jack’s IP address, which is 10.10.30.10.
So when I run the traceroute, it will tell me that it’s going to trace the route to that IP address. And in this particular version of trace route that I’m using here, it will do it to a maximum of 30 hops. But we can see already from this map it’s nowhere close to that number of hops to get to Jack’s device. The first packet that is sent to jack is one that has a traceroute set with a time to live of one, which means as soon as it hits the first router, that time to live of one will suddenly be decreased by one, making the time to live zero, and the router will identify that the time to live has been exceeded, and it drops that particular frame.
This router then sends back to Sam a time to live exceeded message with the source IP address as the router that sent the message. So we know that it only took, in this case, two milliseconds because Sam was counting this response. And this response came from 10.10.10.1. That is our first hop along the way. Now Sam will send another message, but this one’s going to set the time to live exceeded to two, which means it will make it through the first router and it will decrease by one. But as soon as it gets to the next router along the way and the time to live is decreased to zero, it again is exceeded, and a message is sent back to Sam, and Sam makes a note of the IP address of the router where that particular time to live was exceeded.
So we know the first hop and we know the second hop of the IP addresses of those routers. We perform the process again by taking the time to live and making it three, which means it’s going to get through the first two routers. But when it gets to the third router, and the time to live is decreased that last time, a time to live is again exceeded, and that message is sent back to Sam, and the IP address of that router is put into the traceroute. And finally, we’ll do a time to live equal to 4, which means it will make it through the first router, the second router, and the third router. But finally, when it gets to Jack’s machine, it will decrease one last time to zero, and Jack’s device will send back a time to live exceeded message completing the traceroute.
And now we have our complete map of all of the IP addresses that it takes to get between Sam’s device and Jack’s device. Let’s run a traceroute on my operating system. I’m going to run it with the parameter dash q1. That means it will send a single frame each time it performs that time to live change. And I’m going to send that to 8.8.8.8, which is Google’s DNS server. And if I hit Enter, we can see that I’ve got a trace route to that IP address. This is 64 hops maximum. Obviously, we only went 11 hops between my IP address and that Google DNS server. And you can see every hop along the way, every router that was used.
Now, a lot of these were also changed from IP addresses to names. So you could run trace route again with the dash q1. I’m going to specify dash n to tell traceroute not to resolve the names. And when it performs the traceroute, this looks very similar to the traceroute we were just looking at in our example where it went through the connections again and finally got 11 hops. You can see in this particular traceroute, whichever router ended up as being the ninth route on this particular route, did not respond back with an ICMP time exceeded message.
This isn’t completely unusual when you’re communicating to a device across the internet. There’s multiple paths and redundancy built in. You may take one path on one instance to that device, and a completely different path on another instance. Whenever we’re putting the name of a web server in our browser, we don’t even think about the IP addresses associated with that web server. We leave it to the domain name services to be able to convert from a fully qualified domain name down to the IP address so that things can communicate across the network. But, of course, from a security perspective, you may want to perform that same look up yourself.
And there are a number of tools that you can use to be able to do that on your computer. One that’s very common is nslookup. This is something available on Windows and your POSIX-based systems. So you’ll find this already built in on Linux, Mac OS, and other types of systems. This is a utility where you can put in an IP address or the name of a device and it will either perform a lookup or a reverse lookup up using the nslookup utility. Although nslookup is still available on most of these operating systems, it is a utility that has been deprecated, and they highly recommend you use the more updated utility dig.
Dig stands for domain information groper. And this is going to provide you with a lot more detail about what it finds on that DNS server. And there are many more options available in dig that you didn’t have available in nslookup. Let’s run an nslookup on Professor Messer. So I’ll type in nslookup and I’ll type In www.professormesser.com. And you can see that it went out to the Google domain server because that is the default for this particular computer. And it got an answer saying that professormesser.com is 104.20.215.49.
Let’s run the same lookup, but let’s use the dig utility instead. So I’ll use dig, and we’ll choose again www.professormesser.com. And you can see we get a lot more output from the dig command than we did the nslookup command. You can see all of the different queries that were done for this particular default dig command, but you have a lot of other options that you could add here. The question section is going to show you what the actual query was to the DNS server. In this case, it was professormesser.com,. and I’m looking for the address record.
And here’s the answers back. The two records from that server is www.professormesser.com. 299 is the cache that is available. I have a very small cache configured so that I could change the IP addresses for my servers very quickly. And you can see we did get the same IP address, 104.20.215.41. And we have a lot of other options in dig. And if you’re planning to do a lot of queries, and a lot of lookups, you may want to make sure that you have both of these utilities available on your system.
ARP is the Address Resolution Protocol. This is the protocol that’s used across our local network to be able to associate a local IP address with the MAC address of these local devices. There is a cache of these that is stored on our computer in the ARP cache. And we’re able to view that ARP cache by using the ARP command. On most operating systems, we would view that ARP cache by using ARP dash a. It’s a very simple command to use, and that allows us to verify that the IP address and MAC address associations are correct for the devices that we’re connecting to.
Let’s see what’s in my ARP cache. I’m going to type ARP dash a. And we’re going to see that there are a number of IP addresses, 10.1.10.1 through 10.1.10.249. And for each of those, we can see the MAC addresses that are associated with those IP addresses. If we were ever trying to determine if there might be a man in the middle, or if any of these are not resolving properly, we’ll be able to see all of that by looking at our ARP cache.
When you’re doing any type of network analysis or network troubleshooting, it’s useful to know what the local IP address configuration is of the device that you happen to be working on. The way that you would view this is by either using the ipconfig command. Or the ifconfig command. Both of these commands are designed to give you information about the hardware address and the IP addressing on your device. If you have more than one ethernet adapter in your device, then you’ll have hardware and IP address information available for each one of those ethernet adapters.
If you’re using a Windows operating system, the command is ipconfig. If using Linux, Mac OS, or almost any other operating system, it’s ifconfig. I’m running Mac OS. So let’s run the ifconfig command. And I’m going to specify en0, which is the ethernet adapter on my computer. And you can see it does show me hardware information about this device along with the IPv6 and the IPv4 addresses that are defined on this computer. If we were running Windows, and we ran IP config, then we’d be able to see similar information. Here’s the Mac address information on this Windows device.
This device was not able to get a DHCP address. So we can see an APIPA address on this device. And you can see if there are any IPv6 or other DNS server configurations all from the ipconfig command. In a previous video, we talked about using a protocol analyzer to capture packets, but there are utilities you can use to capture packets at the command line. One of these utilities is tcpdump. This allows you to capture packets in most Linux and Unix flavors. It’s also available on Mac OS. And you can also download it for Windows in the utility called WinDump.
You can not only capture the packets, you can apply filters, you can view these packets going by in real time, and if you’re just trying to view some very basic information, this might be a very easy way to do it. You can save these packets, and then you can load them up in a protocol analyzer later on if you wanted to because tcpdump will write them into a standard format called the pcap format. Whenever you’re capturing data on any device, it can be a lot of information. So it may take a little bit of time to figure out how to filter and save the information you want. But this can be a very valuable tool if all you need to do is capture a little bit of data.
Here’s some data I captured on my system using tcpdump. You can see it’s a combination of IPv6 and IPv4 data. There’s a lot of different kinds of data going back and forth. And this can be a little difficult to read if you’re not familiar with exactly the format. This becomes a little bit easier over time, but you can see why it’s useful sometimes to capture large amounts of data and then import that data later on into a protocol analyzer.
One security utility you do not want to be without is Nmap. Nmap is the network mapper and allows you to gather information from all of the different devices across the network. Using Nmap, you can perform a port scan to identify what services might be available on a device. Nmap can perform an operating system scan, which means it can determine what operating system is running on a machine without authenticating into that device. It can also perform a service scan. So not only does it know what services are available on that device, it can tell you the name, the version, and other details about that service without actually using that service.
And there are other scripts built into and Nmap that extend the capabilities and allow you to perform vulnerability scans and much more. Let’s run a very simple Nmap scan. I’m going to choose one of the devices on my network, and it tells me very quickly that there were 991 ports that were closed, but it did show that port 22 was open, which is normally the SSH service. Port 80 was open for HTTP. Port 443 was open using HTTPS, and there’s others here as well.
We can also have Nmap perform an operating system scan. In this particular case, Nmap requires that I run it as roots. So I’m going to perform a [? Sudu, ?] and I’m going to choose to run Nmap with a dash O option to that same IP address to see if we can figure out what operating system is running on that device. It asks for my password since I asked to run as root. And as it goes out and performs the scan, it will show me information about those open ports.
But notice, it also shows me the Mac address of this device, which is a sinology device. And it is indeed running Linux, and it was able to tell me that all based from this in Nmap scan. When we’re accessing services on these devices across the network, we’re usually using a front end application. So to access a web server, we’re using a browser. To access an FTP server, we’re using an FTP client. But you are able to access those services without using those specific clients. And one of the utilities that allows you to do that is netcat.
Netcat as a way to read or write information to or from the network, and you can listen to a particular port number, transfer data to a particular port number, or scan a number of ports and send data to all of them to see what kind of responses you get. We sometimes will see people enable netcat to listen on a particular port number so that it will act as a shell or a backdoor to a remote device. There’s lots of other utilities that do similar functions, such as Ncat. And you can usually find one of these utilities available for the operating system that you’re using.
On my machine, I have Ncat. So we’re going to use Ncat to query that device we were scanning earlier. I’m going to run Ncat, and I’m going to specify the IP address of that device and tell it that I want to communicate to that vise on port 80. I’m going to then tell it to perform a get command and specify that I’m using HTTP version 1 to do that. And here’s the output that I get from that particular device. It tells me that it’s a server running engine x. It is a web server.
Notice that it says that this particular root of this web server gives me an error 302, which means it has been moved temporarily. The new location is the same thing except using a port number of 5,000. So now I’m found that this server, although it has a port 80 available, it’s really telling me that this server is running on port 5,000. So let’s run the same command with Ncat 10.1.10.222. But in this case, let’s choose port 5,000.
And I’m going to run the same git command using HTTP of 1.0. And you can see I get a much larger web server page back– this is the entire page for this particular web server– all by using Ncat at the command line rather than querying any of this with a browser.