Unix Insider –
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. So, for an installation that is about to gain access to the Internet, consider these steps in turn:
- Secure each machine that is connected to the network
- Install the firewall to throttle access
- Enable the Internet link
- 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.
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
- 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. For instance
<font face="Courier">sendmail</font>listens for connections on port 25. If the operating system sees a packet destined for port 25, it sends it to
<font face="Courier">sendmail</font>. 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 188.8.131.52, and it's to 184.108.40.206, 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
<font face="Courier">ftp</font>session is going to cause the remote host to open up a reply connection on a different port. If you are allowing outgoing
<font face="Courier">ftp</font>, 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 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
<font face="Courier">ftp</font>, or when they can use it, so
<font face="Courier">ftp</font>access would be controlled by a proxy server. The packet filter would only allow
<font face="Courier">ftp</font>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
<font face="Courier">crash</font>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
<font face="Courier">su</font>after logging in.
This behavior can be changed by editing the /etc/default/login file and commenting out the
<font face="Courier">CONSOLE</font>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
<font face="Courier">ftp</font>to the host to gain access. So, while remote root login via
<font face="Courier">telnet</font>is disabled, remote root login via
<font face="Courier">ftp</font>is enabled. Of course, root running
<font face="Courier">ftp</font>is able to change any files on the system, so
<font face="Courier">ftp</font>root access is equally as dangerous as root
<font face="Courier">telnet</font>access. It may even be more dangerous, as even less logging is done with
<font face="Courier">ftp</font>logins are not even logged.
To disable root
<font face="Courier">ftp</font>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
<font face="Courier">ftp</font>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
<font face="Courier">sendmail</font>. From the Sun announcement:
<font face="Courier">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. </font>
Remember, a day without patching your systems is like a day without sunshine.
Another problem, currently being exploited in
<font face="Courier">sendmail</font>but also extant in most programs that call the
<font face="Courier">syslog</font>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
<font face="Courier">sendmail</font>, at least, you'll need to install
<font face="Courier">sendmail</font>version 8.7.1.