Watch Your Back Door Guarding the front door can leave the back door wide open

December  1995

Some in the industry (particularly firewall vendors) will tell you that if you install a firewall, all your network security problems will be solved. Unfortunately, this is not the case. A properly installed and managed firewall makes a strong defense -- but only when there are no other connections to the protected system. If there are any other connections to those hosts, they must be protected as well.

This month we'll discuss firewall technologies and methods. Next month we'll conclude with evaluations of the firewall products, both commercial and in the public domain.

Also in Pete's Wicked World this month: two security problems with sendmail, and an easy way to remotely gain root access you may not know about. And don't forget to check out the review of Building Internet Firewalls in the bookstore. (3,400 words)

Mail this article to a friend

Once you've secured the machines in your installation, it's time to secure the remote accesses to your site. The usual method of installation security is to secure the remote access, and then to secure the systems if time and energy allow. But consider that, until you've inspected and secured each host, you don't know what kinds of access each host is allowing.

A firewall is useful only when it is the only connection to an uncontrolled network.

If a host has a modem and allows packet passing (it's acting as a router), that system is making your whole network vulnerable. The host need not even pass packets. If it provides network services, it can be compromised. Once compromised, the hacker can manually access the network and break into other machines. Putting a firewall in place at the corporate Internet connection will solve no problems, and will give you a false sense of security (Diagram 2). So, for an installation that is about to gain access to the Internet, consider these steps in turn:

One uncontrolled modem can compromise the system.

1. Secure each machine that is connected to the network
2. Install the firewall to throttle access
3. Enable the Internet link
4. Continuously monitor the link, and periodically re-check network hosts

If your management has succumbed to the hype and wants an Internet connection immediately, you'll have to fight a rear-guard action. Install the firewall and permit only a minimum complement of protocols through, and initiate an internal sweep of systems. First check for modems that could allow outsiders to gain access to the internal hosts, and control them if possible. Follow up with a security audit of all of the hosts.

At this time in the operation, it is important to establish connectivity and security guidelines throughout your installation. If you've nailed down each modem, and have secured the Internet connection, and have secured each system, you currently have a good level of network security. Do your users know that connecting a modem to a machine could be a "bad thing"? Do they know to get the modem checked out by security or system staff, and any external access approved? If not, your well-spent time and effort could be wasted the moment they turn on that modem.

Those of you without Internet connections have reason to worry as well. Most security problems are caused by internal agents, not external. Can you trust users (and even system administrators) in other divisions of your company that have network connections into your machines? If your user machines and the corporate financial system are connected via a network, are you sure you should be trusting your users to stay away from that interesting data?

One approach to securing an installation is to partition it into domains. Each domain should have a defined security level and defined connectivity to hosts outside of the domain. Each link between domains needs access control. Some domains (corporate financial and personnel information systems) should have no external connectivity. Any change to inter-domain connectivity needs to be planned and controlled.

Sensitive internal domains can be shielded from the rest of the net work for additional security.

Firewall technology
First, a definition. I like the definition of a firewall from Building Internet Firewalls by Chapman and Zwicky: "A component or set of components that restricts access between a protected network and the internet, or between other sets of networks." The firewall can be hardware in the form of a router or a computer, software running on a gateway system, or some combination. Each type of implemention has inherent pros and cons, and each specific implementation likewise has good and bad points, strengths and weakness. With that in mind, let's consider the two main types of firewalls.

Packet filters
Normally, a router looks at the header of a packet, knows on which interface it arrived, and determines which interface to send it to. Except for the normal checksum test, it passes all packets that reach it and are destined for another network it knows about.

A packet filter, when implemented by software or by a smart "screening router" adds a step. Instead of passing all packets, it applies a set of rules to each packet to determine whether to pass or reject it. Because routers only look at packet header information, not its contents, the filters are based on the packet's

• IP source and destination addresses
• source and destination port
• network protocol (TCP, UDP, ICMP, etc.)
• ICMP message type

The port information is crucial, because most network services are based on port-number designation (see sidebar on port numbers below). For instance sendmail listens for connections on port 25. If the operating system sees a packet destined for port 25, it sends it to sendmail. Likewise, http daemons commonly listen at port 80. Therefore, based on the port number, service access through the packet filter may be allowed or denied.

A packet filter might compute something like: "Hmm, this packet is from network 128.140.1.1, and it's to 128.10.1.1, and it's a TCP packet. That's all fine. But it's being sent to port 80, and my rule set says not to allow that. I'll bounce the packet."

Unfortunately, the port number doesn't tell the whole story. For instance, some services listen on one port and reply from a different port. This is important because the firewall needs to know that, say, an outgoing ftp session is going to cause the remote host to open up a reply connection on a different port. If you are allowing outgoing ftp, you must allow that incoming connection.

Why are packet filters good?

• They are relatively easy to configure.
• Current applications that send packets through the filter (telnet, mail) run without modification.
• You may already have one -- smart routers usually allow configuration of filter rules.

Why are packet filters bad?

• They can't look within a service. For instance, you can't specify which users are allowed to telnet, just which hosts.
• By default, they usually pass all packets. They operate on the theory "what is not forbidden is allowed".
• Getting the rule set correct, and testing it, can be tricky.

Proxy servers
Proxy servers are usually composed of a dual-homed (two interface) host and some specialized networking software. One interface connects to the protected net and the other to the unprotected net. IP routing, the kernel mode that passes packets from one interface to the other (allowing the host to act as a router), is disabled. All packets are therefore intercepted by the proxy server software, and examined. Based on the facilities provided and a set of rules, each packet is either passed, rejected, or dropped. Each packet requires action by the proxy server to move from one interface to the next, so none are passed by accident.

Why are proxy servers good?

• By default, "all that is not allowed is forbidden".
• They can look deeper into a packet, so rules may be user-specific.
• They can hide the protected network from the unprotected network -- no hosts are directly exposed, no internet network numbers must be known to the outside. This also means that proxy servers can be used, regardless of their security abilities, to connect un-registered networks to the Internet without renumbering all the hosts.

Why are proxy servers bad?

• The extra overhead of reading and passing each packet causes slower network throughput and requires more expensive hardware for a gateway.
• There may be protocols you want to pass that have no proxy daemon, so they can't be passed.
• Most proxy servers require special client-side applications that know to contact the server, rather than attempting to directly connect to a service on the unprotected network. For instance, a special version of telnet would connect to the proxy server, tell it which system the user wants to connect to, and would be allowed or denied based on the source and destination information.

Both packet filters and proxy servers have pros and cons. Fortunately, there is no reason they can't be used together to form a stronger firewall than either would provide separately. For instance, you may want to pass SMTP (mail) packets through the firewall directly to your mail server. Therefore a packet filter could be used to implement this rule. However, you might want to limit who within your protected network can use ftp, or when they can use it, so ftp access would be controlled by a proxy server. The packet filter would only allow ftp packets to go to the proxy server, and it would decide whether to send those packets on to their destination.

By combining good internal system security with an appropriate combination of packet filters and proxy servers, you can achieve very good protection for those resources you want to connect to unprotected networks or networks in different security domains.

Bug of the Month Club
Solaris 2.4 is much more secure than SunOS 4.1.x out of the box. However, there are still a couple of problems that you need to watch for. Previously in this space we described the problem with the crash program. Now we turn your attention to the root login.

By default, Solaris 2.4 disables root logins from remote hosts. Root may only login directly on the console. All other root access must be done via su after logging in.

This behavior can be changed by editing the /etc/default/login file and commenting out the CONSOLE line. Doing so will allow root login from remote hosts. Note that this is generally a bad thing to do -- there is no accountability for root actions if the user does not have to first identify himself or herself via a normal login. There is no log showing the trail of a user logging in and becoming root. All that you know is that someone was root.

Unfortunately, Solaris 2.4 (and previous versions), by default, allows root to ftp to the host to gain access. So, while remote root login via telnet is disabled, remote root login via ftp is enabled. Of course, root running ftp is able to change any files on the system, so ftp root access is equally as dangerous as root telnet access. It may even be more dangerous, as even less logging is done with ftp. ftp logins are not even logged.

To disable root ftp access, you need to edit the /etc/ftpusers file and add an entry for root. This file contains a list of the user-ids that should be disallowed ftp access. After installing Solaris, this file doesn't even exist. So create it and add a root entry, and root logins will be limited only to the console.

In another disturbing development, CERT has let it be known that the two most widely used security methods in the X Window System have weaknesses that are actively being exploited by crackers. Both the MIT-MAGIC-COOKIE and XDM-AUTHORIZATION-1 methods of determining which remote processes are allowed access to the X server are breakable, under certain circumstances. We haven't determined if Open Windows is vulnerable to these problems, so check out the CERT advisory for yourself. If anyone has information on whether Solaris does suffer from this problem, please let us know.

Alas, more problems have been found with Sun's (and most other vendors') version of sendmail. From the Sun announcement:

TOPIC: SunOS 5.4: sendmail jumbo patch - security
PATCH #: 102319-01 (Solaris 2.4)
         102320-01 (Solaris 2.4_x86)
         101235-01 (Solaris 2.3)
APPLIES TO: Solaris 2.3 and 2.4 systems

  Fixes numerous sendmail bugs, including one in which, if a domainname is
  successively appended when expanding a short name, it skips placing a "."
  between two of the successive domain fields; and one in which certain
  addresses (mx records with mixed cases) cause SEGV termination and core
  dumps.

Remember, a day without patching your systems is like a day without sunshine.

Another problem, currently being exploited in sendmail but also extant in most programs that call the syslog subroutine, is very difficult to patch. In fact, of all the systems that use a BSD-based sendmail, only Sony's NEWS-OS 6.0x, SunOS 5.5 (part of Solaris 2.5) and Linux with libc version 4.7.2 are free of the bug. To fix the bug in sendmail, at least, you'll need to install sendmail version 8.7.1.

The CERT advisory associated with this problem not only describes it but includes information about the smrsh (sendmail restricted shell), which is a very good way to control the access sendmail has to your system. Also included is a pointer to documentation that walks you through converting your Sun system from Sun's sendmail to BSD sendmail 8.7.1.

Given the number of bugs in sendmail, and that the BSD version is fixed much more rapidly that vendor-released versions, converting to BSD sendmail is a very good idea.

The Bookstore
A few words about Building Internet Firewalls by D. Brent Chapman and Elizabeth Zwicky (O'Reilly and Associates, 1995). This is a very fine, practical, accessible, yet complete overview of firewalls. Considering that it is also well written, and that its authors are authorities on the topics of firewalls and system administration, this is a book that should be on your bookshelf if firewalls interest you.

The topics it covers include: why you may need a firewall, Internet services (detailed descriptions of each service and associated security risks), security strategies, firewall design (including bastion hosts, packet filtering, and proxy systems), configuring Internet services (including recommendations on how to secure each service), two sample firewalls, authentication, a section on keeping your site secure, and useful resource, tools, and TCP/IP fundamentals appendices.

Building Internet Firewalls doesn't supplant Cheswick's and Bellovin's Firewalls and Internet Security (Addison Wesley, 1994). The latter is a more theoretical look at the topic, and lacks a little in practical application. With both of these books in hand, you'll be ready to tackle just about any firewall security issue.

Next Month, on "As Pete's Wicked World
Turns" Next month we'll look at some of the firewall products available. What's available, what isn't, and how to choose the best pieces for your firewall goals.

Resources

• X Window System vulnerability alert
  ftp://cert.org/pub/cert_bulletins/VB-95%3A08.X_Authentication_Vul
• Yet another sendmail bug
  ftp://cert.org/pub/cert_advisories/CA-95%3A13.README Building Internet Firewalls by D. Brent Chapman and Elizabeth Zwicky http://www.ora.com/gnn/bus/ora/item/fire.html Firewalls and Internet Security By Cheswick and Bellovin http://www.aw.com/cp/Ches.html

If you have technical problems with this magazine, contact webmaster@sunworld.com

URL: http://www.sunworld.com/swol-12-1995/swol-12-security.html
Last modified:

A port number is an unsigned 16-bit integer. Port numbers less than 1024 are supposed to be secure. That is, if the source port field in a packet is a number less than 1024, that packet should have come from a secure service on the remote machine (say, a packet from sendmail). Likewise, under Unix, only daemons run with root privileges can listen on ports less whan 1024. Unfortunately, other operating systems aren't as trustworty as Unix. On a PC running some lesser operating system, any software can connect to any port and send or receive packets. Also, even people who run Unix systems can be evil. So the port number is no longer an indication of how trustworty the sender is. For most Unixes, including SunOS and Solaris, some port numbers are defined in the /etc/services files. Note that port numbers are protocol specific, so UDP and TCP can have different services associated with the same port number.

A sample /etc/services from Solaris:

#ident	"@(#)services	1.9	93/09/10 SMI"	/* SVr4.0 1.8	*/

#
# Network services, Internet style
#
tcpmux		1/tcp
echo		7/tcp
echo		7/udp
discard		9/tcp		sink null
discard		9/udp		sink null
systat		11/tcp		users
daytime		13/tcp
daytime		13/udp
netstat		15/tcp
chargen		19/tcp		ttytst source
chargen		19/udp		ttytst source
ftp-data	20/tcp
ftp		21/tcp
telnet		23/tcp
smtp		25/tcp		mail
time		37/tcp		timserver
time		37/udp		timserver
name		42/udp		nameserver
whois		43/tcp		nicname		# usually to sri-nic
domain		53/udp
domain		53/tcp
hostnames	101/tcp		hostname	# usually to sri-nic
sunrpc		111/udp		rpcbind
sunrpc		111/tcp		rpcbind
#
# Host specific functions
#
tftp		69/udp
rje		77/tcp
finger		79/tcp
link		87/tcp		ttylink
supdup		95/tcp
iso-tsap	102/tcp
x400		103/tcp				# ISO Mail
x400-snd	104/tcp
csnet-ns	105/tcp
pop-2		109/tcp				# Post Office
pop		110/tcp				# Pop3
uucp-path	117/tcp
nntp            119/tcp         usenet		# Network News Transfer
ntp		123/tcp				# Network Time Protocol
ntp		123/udp				# Network Time Protocol
NeWS		144/tcp		news		# Window System
#
# UNIX specific services
#
# these are NOT officially assigned
#
exec		512/tcp
login		513/tcp
shell		514/tcp		cmd		# no passwords used
printer		515/tcp		spooler		# line printer spooler
courier		530/tcp		rpc		# experimental
uucp		540/tcp		uucpd		# uucp daemon
biff		512/udp		comsat
who		513/udp		whod
syslog		514/udp
talk		517/udp
route		520/udp		router routed
new-rwho	550/udp		new-who		# experimental
rmonitor	560/udp		rmonitord	# experimental
monitor		561/udp				# experimental
pcserver	600/tcp				# ECD Integrated PC board srvr
kerberos	750/udp         kdc		# Kerberos key server
kerberos	750/tcp		kdc		# Kerberos key server
ingreslock      1524/tcp
listen          2766/tcp                        # System V listener port
nfsd		2049/udp	nfs		# NFS server daemon
lockd		4045/udp			# NFS lock daemon/manager
lockd		4045/tcp

About the author
Peter Galvin is Chief Technologist for Corporate Technologies, Inc., a Systems Integrator and VAR. He is also Adjunct System Planner for the Computer Science Department at Brown University, a member of the Board of Directors of the Sun User Group, and has been Program Chair for the last four SUG/SunWorld conferences. As a consultant and trainer, he has given talks and tutorials world-wide. He has written articles for Byte and Advanced Systems (SunWorld) magazines, and the Superuser newsletter. Peter is coauthor of the best-selling Operating Systems Concepts textbook. Reach Peter at peter.galvin@sunworld.com.