Random ports

Firewalls have become the Internet equivalent of a condom. "Don't have hex without a firewall!" is the mantra for every security issue, from keeping out crackers to minimizing the threat of Melissa.

But what use is a firewall that permits any service from any source to any destination? Not much, obviously. A well-designed firewall can recognize valid service requests based on the source, destination IP address, and port number. The assignment of a service to a specific known port (such as port 23 for Telnet, port 21 for FTP, or port 80 for HTTP) is one of convention and convenience; it allows sites to use a protocol over a known port number without negotiating port assignments before communicating with other systems.

http://www.iana.org/assignments/port-numbers

Firewall architects use this convention to block ports for services that security administrators consider risky. But what's to stop someone from abusing this convention? Sadly, nothing. To make matters worse, developers are more and more frequently building applications that run via port assignments that are well known and commonly used -- the HTTP and HTTPS ports (80 and 443, respectively).

A prime port of call for hackers:
http://www.businessweek.com/bwdaily/dnflash/july2000/nf00711e.htm

This trend makes life easier for developers, who won't have to worry about a firewall getting in the way, but much harder for security administrators. Those in the trade of unleashing nasty new email viruses and Trojans won't end up with much to block their toys' dissemination. While inbound SMTP (Simple Mail Transfer Protocol) traffic on port 25 to a site may be filtered or blocked, many firewalls are configured to allow for outbound POP3 (Post Office Protocol) and IMAP4 (Internet Messaging Access Protocol) connections. Why worry about trying to get through the front door when the windows are open?

Consider also that some of the more popular firewalls have default configurations that leave port 53 (Domain Name Service [DNS]) wide open. Why would they do this? Curiously, it seems that most firewall vendors got tired of explaining to their customers that they couldn't reach their external DNS because of their firewall, and that they would need to open that service in their firewall ruleset. Instead of wasting time with countless hours of technical support, many chose to simply leave the service open to any source for any destination. Problem solved? More like problem squared.

A design flaw in Netscape's Java implementation demonstrates the danger of adding too much functionality to a software package without regard for the consequences:

Sign up for ITworld's Daily newsletter
Follow ITworld on Twitter @IT_world

• Email
• Print
• Share
  • Slashdot
  • Digg
  • Stumble
  • Reddit
  • Newsvine