Sep 21 2009
General, Networking, Security, Server Administration
When you think of your production servers, you need to imagine them as your car sporting a new stereo in a parking lot with a bunch of would-be burglars milling around outside constantly checking each window and door to make sure you locked it tightly the last time you had it open. Every door, window, or keyless entry system is a potential point of invasion that can fail you. Why do you think those brinks trucks have no windows and the only way in the back is a single, beefy, padlocked door. A Brinks truck may not be convenient to access, but that isn't their goal. You need to control the ways into your server with the same gusto.Better yet, what if your car wasn't in the parking lot at all? What if it was in a locked parking garage with a security guard at the door only letting in people with an ID card? A default install of windows leaves a lot of holes open for hackers to poke at. Just because something like file and print sharing is enabled doesn't mean you are publishing the contents of your hard drive to the inter-webs, but it does mean there is one more attack vector than there should be. That and Microsoft isn't especially known for un-exploitable software. You should think about every server you have that is accessible by the general public. What services do people NEED to access on this server and what ports do they listen on? HTTP? HTTPS? A lot of us can stop right there. Ports 80 and 443 are the only ports that need to be open on most web servers. The next most common ones are probably FTP/SFTP and Telnet/SSH. I would never recommend having netBIOS (139) or terminal services (3389) externally available without firewall rules only allowing connections to be made to those ports from specific IP addresses. You can block access to ports directly on the server via a software firewall or simply turning off the services that are listening on those ports. Assuming each of your servers are behind a network firewall, it is my preference to leave all ports open to your internal network and clamping them down at the firewall that is your gateway to the outside world. So, finally arriving at my purpose for this post-- how do I tell what ports I have open? Firstly, to get a list of ports being listened on you can run the netstat command from the computer in question. Windows Server 2003 supports the following parameters:
[code]netstat -aob | find "*:*"[/code]The same command on my OpenSuse Linux box looks about like this:
[code]netstat -pa | grep "*:*"[/code]Here's an abbreviated version of the output from my Linux Server.
[code]tcp *:mysql *:* LISTEN 18553/mysqld tcp *:ftp *:* LISTEN 2881/vsftpd tcp *:smtp *:* LISTEN 2952/exim tcp *:www-http *:* LISTEN 2979/httpd2-prefork tcp *:ssh *:* LISTEN 2856/sshd tcp *:smtp *:* LISTEN 2952/exim [/code]That's a good start, but it only tells me who's listening, it doesn't account for any ports blocked by firewalls. The best test is to simply try to connect on a port from an outside computer and see what happens. A very simple way to test a single port is with the telnet command. Telnet will attempt to connect to the remote machine you specify on the port you supply. You will either get back a response from the listening service, or a connection refused error. Try this at a Windows or Linux command prompt:
[code]telnet google.com 80[/code]This tries to establish a connection to Google's web servers on port 80; the same port your web browser uses when you go to google.com in IE or FF. To simulate a web browser making a request for a web page, type "GET /" and hit enter. Google's server will send you back all the HTML for their main page! Ok, so telnet lets us check a single port, but there are thousands of ports and so little time. This is where a little utility called Nmap comes in. My favorite version can be downloaded from http://insecure.org as an .exe (for Windows) or executable binary for Linux. Nmap will take an IP address (or a range of IPs) and scan for a specific port, a range of ports, or all ports. I generally install the command line utility. They have a gui for Nmap, but I've only used it once. Nmap has a few million options (including one to output the results into a file written in "s|<rIpt kIddi3" format), but in its simplest form it looks about like this:
[code]nmap google.com[/code]The output will look something like this:
[code]Starting Nmap 4.20 ( http://insecure.org ) at 2009-09-22 01:02 CDT Warning: Hostname google.com resolves to 3 IPs. Using 188.8.131.52. Interesting ports on pz-in-f100.google.com (184.108.40.206): Not shown: 1694 filtered ports PORT STATE SERVICE 80/tcp open http 113/tcp closed auth 443/tcp open https Nmap finished: 1 IP address (1 host up) scanned in 52.834 seconds [/code]You can easily see that Google's firewall only responds to incoming requests on the ports for HTTP, HTTPS, and AUTH. HTTP and HTTPS are accepting connections and AUTH is specifically rejecting requests (as opposed to just dropping the packets). Google probably does this for performance so a client that automatically tries to connect on port 113 will get an immediate response (TCP RST or an ICMP UNREACHABLE) instead of having to wait for it to timeout. http://www.grc.com/port_113.htm Well, now that you have the tools-- go and probe your servers and close off every port you don't actually need open. If you do need to have SSH or FTP ports open, know that hackers will try night and day to guess your usernames/passwords with relentless scripted attacks. Tools like Nmap make it very easy for them to find your server. This is why it is not a bad idea to run services like that on non-standard ports since what hackers generally do is scan ranges of IP addresses for a specific well-known port and then launch brute-force attempts at the targets they find. If you must use the standard port ensure you use good passwords and for goodness sakes, disable ssh logins to your root account and rename your windows administrator account. That right there will thwart 80% of all log in attempts.