Wednesday, September 12, 2007

Assessment of a Hardened Box

I thought I'd do a piece on *nix security. This will be a general guide on how to determine what ports have listening services and how to assess if those ports are available to the world wide web.

I like to do three different things:

1. Run Nmap against localhost (127.0.0.1).
2. Run Nmap against the machine's IP from another machine within the LAN.
3. Run Nmap against the machine from the internet.

Running Nmap against localhost can be deceiving, as the ports that are listening on the machine may not actually available to another machine, on or off the LAN. Note that 127.0.0.1 only pertains to the local machine. This is the loopback address that every machine uses to communicate to itself. I'll compare a localhost scan against a scan that was conducted from another machine on the LAN.

I'll scan localhost first:
-su-2.05b# nmap localhost

Starting Nmap 4.11 ( http://www.insecure.org/nmap/ ) at 2007-09-12 17:20 EDT
Interesting ports on localhost.home (127.0.0.1):
Not shown: 1674 closed ports
PORT STATE SERVICE
22/tcp open ssh
25/tcp open smtp
3306/tcp open mysql
5801/tcp open vnc-http-1
5901/tcp open vnc-1
6001/tcp open X11:1

Nmap finished: 1 IP address (1 host up) scanned in 10.662 seconds
Now, I'll scan the machine's IP from another machine:

root@slackbox:~# nmap 10.150.1.103

Starting Nmap 4.20 ( http://insecure.org ) at 2007-09-12 17:36 EDT
Interesting ports on delly (10.150.1.103):
Not shown: 1693 filtered ports
PORT STATE SERVICE
22/tcp open ssh
80/tcp open http
3306/tcp open mysql
5900/tcp closed vnc
MAC Address: 00:C0:4F:61:28:1F (Dell Computer)

Nmap finished: 1 IP address (1 host up) scanned in 22.277 seconds
Comparing the two scans, some things are readily apparent: port 25/tcp and 5801/tcp, 5901/tcp, and 6001/tcp are listening on the loopback device, yet they aren't listening on IP that is assigned to the machine. Also, note that certain ports are bound to the IP but not the loopback. The more important aspect of these two scans is the services listening on a non-loopback address, because services use IPs to communicate to other machines, not loopback devices.

So, TCP ports 25, 5801, 5901, and 6001 appear to be open. We can test this. Remember, we're concerned about whether these ports can be seen as open to the internet. We'll test this by using telnet. Below, I'm logged into another machine and attempting to telnet on port 25 to the machine we Nmap'd on localhost:

root@slackbox:~# telnet 10.150.1.103 25
Trying 10.150.1.103...
telnet: connect to address 10.150.1.103: Connection timed out
The connection timed out. It is pretty evident that the machine doesn't have services on 10.150.1.103:25 that just anyone can reach.

We can also test by running 'netstat -an' on the machine. Whle netstat doesn't connect to the port in question, it does indicate what interface services are using:

-su-2.05b# netstat -an | grep -i listen
tcp4 0 0 *.5801 *.* LISTEN
tcp4 0 0 *.5901 *.* LISTEN
tcp4 0 0 *.6001 *.* LISTEN
tcp4 0 0 *.3306 *.* LISTEN
tcp4 0 0 10.150.1.103.8118 *.* LISTEN
tcp4 0 0 10.150.1.103.80 *.* LISTEN
tcp4 0 0 127.0.0.1.25 *.* LISTEN
tcp4 0 0 *.22 *.* LISTEN
tcp6 0 0 *.22 *.* LISTEN
See port 25? What IP address is assigned to the service? Loopback! This means that this service isn't exposed to any other machine on the LAN or internet. The other services are listening (for example, *.22) but the '*' usually means that the service is assigned to an interface (which may have a number of IPs assigned to it). Ports 80 and 8118 have an IP assigned to the service, instead of '*'. This means that only IP 10.150.1.103 is assigned to that interface. Ports 80 and 8118 also do not show up when scanning localhost, but yet I can telnet to port 80 and 8118 when using the telnet command (and also browser), using 'telnet localhost 80' or 'telnet localhost 8118'. Port 80 is a web server. Port 8118 is a Privoxy proxy. The reason is probably because my PF install on that machine filters some loopback traffic. If I scan the IP of the machine, port 80 is then detected. The reason is because PF is configured to allow port 80 traffic to/from 'slackbox' from/to 10.150.1.103.

All of this is very elaborate. Everything has to be taken into consideration: what the firewall does/doesn't allow; what services run on 127.0.0.x; what services run on interfaces; what services run on IP addresses.

The last thing we'll do is scan the LAN from the internet. The results will be determined by what ports the gateway router/firewall are forwarding to machines within the LAN. For example, I know I've port 22/tcp open to the world because I've told my gateway firewall to forward any traffic on 22/tcp to 10.150.1.103. I also don't allow much else and also allow some traffic to be forwarded to different machines within the LAN. So, when a scan is being conducted from the outside, the whole LAN's security posture is taken into account. Now, let us scan from the internet:

Starting nmap V. 3.00 ( www.insecure.org/nmap/ )
Interesting ports on pool-xx-xxx-xx-xx.washdc.fios.verizon.net (xx.xxx.xx.xxx):
(The 1599 ports scanned but not shown below are in state: filtered)
Port State Service
22/tcp open ssh
3306/tcp open mysql
NICE! Of all the scans we've conducted thus far, this is the one that is important. The other scans paint the smaller picture, but this one puts it all together and is THE security assessment that one wants to conduct. So, you can see, ports 22 and 3306 are open to the world. This could be two different machines that need those ports open to the internet, or this could be one machine that has those two ports open to the world wide web. Note that while I can reach those ports, my firewall is configured to allow communication from the machine I scanned from. If a machine, from Google.com or any other IP/domain that is not accounted for within the FW policy, attempted the same thing, those ports wouldn't show as opened, as the firewall would drop the traffic. So, while the two ports appear to be open to the world in the above results, they actually aren't, as the traffic is being filtered.

I hope all of this has helped some in understanding security and how to assess your LAN gateway and hosts within the LAN. We've used Nmap, telnet, and netstat to determine the security posture of a given machine. There are other tools that I didn't mention for brevity, (such as socklist, tcpdump, snort, for example) but Unix and Linux machines offer much in the way of testing security of a machine.

`

No comments: