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:

Users affected by Netscape security hole:
http://abcnews.go.com/sections/tech/DailyNews/netscape000807.html

According to this story, "both ISS and Netscape officials noted that business users, because they're protected by the company's network firewall, are not vulnerable."

How do they know this for certain? What if the exploit were modified to run on port 53, or on another port the firewall might have open? At this point, the demo program for the vulnerability, Brown Orifice, is written only to read files on the victim's computer. There is no reason why it can't be modified to alter them as well.

Clearly, Netscape needs to fix this problem. But this is only a symptom of a growing trend in careless development practices. Just look at the proposed Simple Object Access Protocol (SOAP), which is designed to bypass firewalls.

http://www.microsoft.com/mind/0100/soap/soap.asp

If this protocol is adopted -- and it most likely will be -- the fundamental design principle of firewalls will be meaningless. No longer will firewalls be able to block services and ports in rulebases; instead, they will need to perform content filtering on the traffic itself. This will be much harder to implement and more error-prone -- to say nothing of the performance overhead.

If only we could point to Netscape or Microsoft as the root cause for security problems. Unfortunately, we can't. The problem is not confined to a particular vendor -- the whole industry is demanding faster turnaround on products and more features in each release. Until the industry demands security as a priority, we will continue to see more and more exploits. I predict the biggest will be called SOAPy Orifice.

» posted by abennett

Unix Insider

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