Critical Control 13: Limitation and Control of Network Ports, Protocols, and Services

Published: 2011-10-20
Last Updated: 2011-10-20 03:22:04 UTC
by Johannes Ullrich (Version: 1)
3 comment(s)

Observing never ending port scans against my systems was one reason I started DShield.org back in 2000. Still today, DShield shows that these scans continue to happen today. It is the goal of a port scan to find vulnerable services. Later, the attacker will use this recognizance to exploit these services.

In order to protect yourself, two basic measures need to be taken:

1 - limit listening services.

As part of your standard configuration, you should turn off all unneeded services. A service that is not running can not be attacked. Of course, you will also need to monitor any changes to this standard configuration. The control of listening services should not stop at controlling services commonly installed on the particular host, but the control should include rogue services as well.

Here are a few ideas to review listening services on hosts:

  • review the output of "netstat" regularly. Netstat will show any listening services. Of course, in the case of rogue services, an attacker may use root kits to mask these services from tools like netstat.
  • review ephemeral port usage. If a port is used by a listening service, it can not be used as an ephemeral portal for outbound connections. You will see a "gap" if you plot all used ephemeral ports on a system.
  • regular port scans. Periodically scan your systems for listening ports. However, be aware that an attack may have masked the use of the port and will only respond to requests from a particular source
  • Network monitoring: Tools like "pads" are able to detect new services on a network passively. This may enable you to detect hidden services as soon as the attacker connects to them. 

2 - applying firewall rules.

Back in 2000, firewalls were a lot less common then they are today. Today, systems arrive with host based firewalls. Many times, the firewall is already enabled to block all inbound traffic by default. In addition to host based firewalls, a well designed network should include network firewalls and take advantage of capabilities in devices like switches to further limit network traffic. 

 

------
Johannes B. Ullrich, Ph.D.
SANS Technology Institute
Twitter

Keywords:
3 comment(s)

Comments

With regular port scans, can you suggest a tool that will point out differences? I can certainly nmap a range, and nmap will tell me about several thousand results, but I'm not going to be able to find, say, a single new open port. There's a good chance I'd even miss a new finger server in that mess.

Also, "Pads" is a little non-specific. Do you have any other term? Google wasn't my friend in this.
Googling "pads passive service detection" makes it more friendly.

http://passive.sourceforge.net/about.php
A good idea for identifying and document required device access is through the use of port justification exercises. These forms would collect information about each device (server, switches, routers, etc) including traffic flows, ports with identified justification for requiring the port to be open. Enforcement can be implemented by using endpoint firewalls, network switch port security, ACLs, perimeter firewalls, etc.

Diary Archives