Threat Level: green Handler on Duty: Johannes Ullrich

SANS ISC: Critical Control 13: Limitation and Control of Network Ports, Protocols, and Services SANS ISC InfoSec Forums

Watch ISC TV. Great for NOCs, SOCs and Living Rooms: https://isctv.sans.edu

Sign Up for Free!   Forgot Password?
Log In or Sign Up for Free!
Critical Control 13: Limitation and Control of Network Ports, Protocols, and Services

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

I will be teaching next: Defending Web Applications Security Essentials - SANS San Francisco Winter 2019

Johannes

3680 Posts
ISC Handler
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.
Mose

2 Posts
Googling "pads passive service detection" makes it more friendly.

http://passive.sourceforge.net/about.php
Mose
1 Posts
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.
Anonymous

Sign Up for Free or Log In to start participating in the conversation!