My last two blog entries have talked about ways of locking down services to specific ports and IPs. In this entry, I want to show you two tools for inspecting your running server so you can see the result of your hard work, and identify other things that might need to be locked down.
Knowing What Your Server is Running
The first tool we are going to look at is netstat. Log into your linux server, and type this:
sudo netstat -lnpt
you'll see some output that looks like this (server names and IP address in this blog post have been changed to protect my clients):
[dbock@example.com ~]# sudo netstat -lnpt Active Internet connections (only servers) Proto Recv-Q Send-Q Local Address Foreign Address PID/Program name tcp 0 0 127.0.0.1:3306 0.0.0.0:* 28190/mysqld tcp 0 0 127.0.0.1:11211 0.0.0.0:* 1600/memcached tcp 0 0 127.0.0.1:631 0.0.0.0:* 2281/cupsd tcp 0 0 127.0.0.1:25 0.0.0.0:* 2425/sendmail tcp 0 0 :::80 :::* 3112/httpd tcp 0 0 :::22 :::* 2251/sshd tcp 0 0 :::443 :::* 3112/httpd
I'll leave it up to you to look at the man page and see what other parameters you can pass to netstat, but this is the view that matters most right now. This is a list of every service that is listening on an ethernet port, the name and process ID of that service, and the port it is listening on. This is pure gold from a security standpoint... many times I have done this to find an ftp service running that no one knew about, or some other tool like webmin.
Armed with this knowledge and the approach taken in the previous blog entries, you can now lock and and/or stop services you don't need. For instance, I really don't think that cups (the common unix printing system) is necessary on this server - I'll go ahead and stop that.
From that list above, we can see that mysql and memcache are locked down to localhost(127.0.0.1) as we planned... but how do we really *know* thats the case? What does the 'outside world' see when they look?
From the Outside Looking In
The next tool we are going to use is nmap. Nmap is an awesome tool that does a zillion different things for mapping out a network... in this example, we are going to use just one of its features - showing us the open ports running on a server.
You are going to run netstat from a machine other than your server, most likely your development box. We are going to do a port scan of your server, but before we do, a few words of caution - a port scan can be seen as hostile activity if you do it to someone else's server - at the very least it is rude. It is also possible that port scanning someone's server will put your IP address on that server's deny list, at least for a little while (and we'll see how to do that in a few blog posts).
With all that disclaimer out of the way, type this from your favorite shell:
nmap -A www.your-favorite-server.com
You'll get back something that looks like this:
Starting Nmap 5.00 ( http://nmap.org ) at 2010-08-11 02:28 UTC Interesting ports on xxx.xxx.xxx.xxx: Not shown: 997 closed ports PORT STATE SERVICE VERSION 22/tcp open ssh OpenSSH 4.3 (protocol 2.0) | ssh-hostkey: 1024 23:66:ab:b3:4f:45:70:77:79:65:4e:8b:37:61:71:88 (DSA) |_ 2048 a2:e5:af:bd:33:70:77:79:65:ce:a8:d4:82:4f:5c:45 (RSA) 80/tcp open http Apache httpd 2.2.3 ((CentOS)) |_ html-title: Apache HTTP Server Test Page powered by CentOS 443/tcp open ssl/http Apache httpd 2.2.3 ((CentOS)) |_ html-title: Apache HTTP Server Test Page powered by CentOS
Wow... look at all that information! First, lets pat ourselves on the back - from the outside looking in, no one can tell we are running mysql or memcache. The only thing they can see is http(on port 80), https(on port 443), and ssh(on port 22). It is a little disconcerting that they can see specific tools and version numbers, as that advertises potential vulnerabilities we might be subject to. Not as shocking is that we can see keys for ssh - if you know how ssh works, public keys like this have to be, well, public.
We have effectively hidden a lot of information from a would-be attacker doing a port scan... there are a few things they have learned though that could be useful... the most important of which is "if I want to attack the content on this web server, I know which instance of ssh I should start poking at".
In my next several blog posts, we'll learn about some minimal security configuration and practices for SSH, as well as a technique called "Service Address Isolation" so we can separate ssh from the web services. And in a few posts hen I talk about Firewalling with APF, we might even talk about portknocking.
A Couple nmap Tricks
In closing, I'll leave you with a few things about nmap to pique your curiosity. Try running the same kind of scan with -v (for verbose) or -O (for Operating System fingerprinting)... you'll see a lot of information about your server you'd be surprised is so easy to determine.
Comments