Week 36: Ports -- Don't have an 'open house' sign out

In this week's column, Shelley offers advice on securing ports.

This Content Component encountered an error

What
Managing the port located on your network.

When
As needed.

Why
People have been back from DEFCON now about a month, so the latest hacks, er, network analysis tools unveiled there have filtered through the bulletin boards by now. It's a good time to sweep your ports and see what's what. You should know what ports are regularly used by your system, and which are not.

Transmission Control Protocol and User Datagram Protocol (TCP/UDP) port numbers are divided into three ranges. The well-known ports (0 through 1023), sometimes also known as trusted ports, can only be used by system (or root) processes or by programs executed by privileged users on most systems. The others include registered ports (1024 through 49151) and dynamic and/or private ports (49152 through 65535). Dynamically assigned ports are opened and closed by the server(s) as needed.

Ports are used in TCP to name the ends of logical connections that carry long-term conversations. For the purpose of providing services to unknown callers, a service contact port is defined. The port list specifies the port used by the server process as its contact port, so this contact port is sometimes called the "well-known port." As much as possible, these same port assignments are used with UDP. Some of the most well known include: 21 for FTP; 25 for SMTP; and 80 for HTTP. While many services may rely on a particular TCP or UDP port, only a single service or process can be actively listening on that port at any one time.

Trojans are often discovered because they use the same port regularly to enter, exit and/or send information, a notorious example being Back Orifice, which listens on port 31337. Other malware and their associated known port numbers can be found at http://www.sans.org and http://www.securityfocus.com (enter "Trojan port list" in the search function).

Strategy
NMAP (network mapper) is a free network port scanner that checks a set of target hosts to see which TCP and UDP ports have servers listening on them. Since most network services are associated with well-known port numbers, this information also tells you a lot about what the machine is running. NMAP works on most platforms and is also a good way to find out what a system looks like to someone who's trying to break in. Like any analytical tool, NMAP can be used for evil purposes, so be sure to use your powers for good!

Netstat is a common IP-troubleshooting utility that comes with many OSes, including Windows. You can use it to display all the active and listening UDP and TCP ports on a local host. Open a DOS command prompt and type netstat-a.

You should regularly scan your network ports and learn which ports are commonly in use, and which are not. It is also good to review port lists that contain known Trojan exploits, so you can examine your registry and port configuration files in detail.

More information
A complete list of port numbers with assignments can be found at http://www.iana.org/assignments/port-numbers. NMAP (free software available with full source code under the terms of the GNU General Public License) can be found at http://www.insecure.org/nmap. A good article from Microsoft on regularly used port assignments can be found at http://support.microsoft.com/default.aspx?scid=kb;en-us;832017; detailed documentation on this subject is available on Microsoft TechNet and on Microsoft Developer Network (MSDN). A good article on regularly used Unix ports can be found in Simson Garfinkel's and Gene Spafford's book Practical UNIX & Internet Security, Second Edition, O'Reilly & Associates Inc. 1996; in Appendix G, they suggest firewall handling for each service based on known security issues. More information on Unix port assignments can be found in any Unix man pages manual.

About the author
Shelley Bard, CISSP, CISM, is a senior security network engineer with Verizon Federal Network Systems (FNS). An information security professional for 17 years, Bard has briefed and written infosecurity assessments and technical reports for the White House and Department of Defense, special interest groups, industry and academia. Please e-mail any comments to mailto:securityplanner@infosecuritymag.com.

Opinions expressed in this column are those of Shelley Bard and don't necessarily reflect those of Verizon FNS.

Last week: Incident response
Next week: Who's afraid of auditing?

This was first published in August 2004

Dig deeper on Password Management and Policy

Pro+

Features

Enjoy the benefits of Pro+ membership, learn more and join.

0 comments

Oldest 

Forgot Password?

No problem! Submit your e-mail address below. We'll send you an email containing your password.

Your password has been sent to:

-ADS BY GOOGLE

SearchCloudSecurity

SearchNetworking

SearchCIO

SearchConsumerization

SearchEnterpriseDesktop

SearchCloudComputing

ComputerWeekly

Close