Linux
Apache
MySQL
PHP

CSS
XHTML1.1
XML/RSS

Creative Commons

2013-04-10 12:05:59

Closing Ports on Linux

Recently in my web server class I talked about things you can do to secure your machine. One of those things was detecting open ports and figuring out how to close them. I wrote up a little "script" explaining the common case for doing this on RedHat-based machines and sent it to my class, but I thought it warranted posting here for anyone who might have to do this.

In the below example we scan our machine using Nmap and see that there is a port listening that we don't recognize. The other ports were due to services that we installed and configured, but one of them is not something that we installed. So we walk through using 'netstat' and 'ps' to determine what process is exposing that port and then show how to immediately kill the service (thus closing the port) and make sure it never gets opened again.

Of course, this assumes the offending process is an actual service, not some random binary being executed via non-traditional means. If the process is not a service you have to do some digging, but the below example will fit most cases.

# # Scan our machine to see what ports are open # [root@server0 ~]# nmap 10.85.10.101 Starting Nmap 5.51 ( http://nmap.org ) at 2013-04-09 15:54 EDT Nmap scan report for server0.slonka.com (10.85.10.101) Host is up (0.0000070s latency). Not shown: 994 closed ports PORT STATE SERVICE 21/tcp open ftp 22/tcp open ssh 23/tcp open telnet 53/tcp open domain 80/tcp open http 111/tcp open rpcbind Nmap done: 1 IP address (1 host up) scanned in 0.08 seconds # # Port 111 is open and we don't know what it is. We probably want to close it. # Let's see what process on our machine is exposing port 111 # [root@server0 ~]# netstat -anp | grep :111 tcp 0 0 0.0.0.0:111 0.0.0.0:* LISTEN 2305/rpcbind tcp 0 0 :::111 :::* LISTEN 2305/rpcbind udp 0 0 0.0.0.0:111 0.0.0.0:* 2305/rpcbind udp 0 0 :::111 :::* 2305/rpcbind # # We see that process ID 2305 is exposing port 111 on all network interfaces (0.0.0.0) # Let's see what the name of the program is that's running as PID 2305 # [root@server0 ~]# ps ax | grep 2305 2305 ? Ss 0:00 rpcbind 2327 pts/0 S+ 0:00 grep 2305 # # We now know the name of the program is rpcbind. Let's see if it's a normal service. # [root@server0 ~]# chkconfig --list | grep rpcbind rpcbind 0:off 1:off 2:on 3:on 4:on 5:on 6:off # # It is, and it's turned "on" for runlevel 3 (multi-user text-mode), which is what we use. # Let's stop it right now so it's no longer open. # [root@server0 ~]# service rpcbind stop Stopping rpcbind: [OK] # # That's great, but the next time we reboot the service will start again because it's set to # "on". Let's turn off the service so it never runs again. # [root@server0 ~]# chkconfig rpcbind off


Back

2 comments


2014-01-05 09:16:27


K3VL4R says...
iptables -A INPUT -m state --state NEW -j REJECT

just reject everything and prepend to your iptables to accept what you want. then it doesnt matter what services are running because you are behind an actual firewall :)

2014-01-05 09:57:11


slonkak says...
No, that's not good enough. Keeping [possibly vulnerable] services running on a machine is a great way to allow unwanted code execution. Just because a firewall can block outside packets doesn't mean someone can't coerce a "legitimate" service to communicate with another service on the same host and cause bad things to happen. The only way to properly secure a host, other than pulling the ethernet cord :), is to have an external firewall, internal firewall, and lock down the host itself using, in part, the above procedure.

Post a comment!

Name:
Comment: