Watch Your Back Door
Guarding the front door can leave the back door wide open
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)
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.
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:
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.
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.
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
The port information is crucial, because most network services are
based on port-number designation
(see sidebar on port numbers below).
listens for connections on port 25. If the operating system sees a
packet destined for port 25, it sends it to
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 126.96.36.199, and it's to 188.8.131.52, 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,
ftp session is going to cause the remote host
to open up a reply connection on a different port. If you are allowing
ftp, you must allow that incoming connection.
Why are packet filters good?
Why are packet filters bad?
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?
Why are proxy servers bad?
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
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.
Bug of the Month Club
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
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
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
is able to change any files on the system, so
access is equally as dangerous as root
telnet access. It
may even be more dangerous, as even less logging is done with
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
but also extant in most programs that call the
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.
CERT advisory associated with this problem not only describes it
but includes information about the
(sendmail restricted shell), which is a very good way to control the
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
Given the number of bugs in
sendmail, and that the BSD version
is fixed much more rapidly that vendor-released versions, converting to
sendmail is a very good idea.
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.
If you have technical problems with this magazine, contact firstname.lastname@example.org
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 email@example.com.