This chapter discusses how to set up a “firewall”—a configuration that stands between your local network and your Internet service provider. The types of firewalls discussed are those in which an IRIX host is configured as part of the firewall. A general overview of some possible hardware configurations is presented, and the rest of the chapter presents detailed information on configuring IRIX software.
This section discusses how to configure network hardware to serve as the hardware portion of a firewall solution. (For information on how to configure Silicon Graphics software in a firewall solution, refer to “IRIX Configuration”.) Only setups that include an IRIX host as part of the solution are discussed, as router-only solutions tend to be too limited. The use of a firewall host has the advantages of permitting and restricting specific applications, maintaining log files, and adding authentication to network access.
The firewall host is typically combined with a router, whether provided as part of your connection to your Internet service provider (referred to as an ISP router in this document) or added by you to your private configuration. Many routers can be configured to provide IP packet-level security, but do not support such features as proxies and authentication (See “Using Proxy Servers”). To add these features, you must have a system such as the IRIX host setups described in the rest of this chapter.
When using a router with a firewall host, configure it to allow traffic only to the firewall host. You should filter out:
ICMP redirects not from the router
IP packets specifying the loose source routing option
external packets claiming to be from the internal network (known as “spoofing”)
Consult with your Internet service provider to determine the packet filtering options available for your Internet connection. You can also add routers to your firewall configuration as described in the next section, and then configure your routers with additional filtering options (refer to the router vendor documentation for details). (See also “Packet Filtering Gateways,” in Firewalls and Internet Security, by Cheswick and Bellovin, referenced in “Books”.)
Refer to ipfilterd(1M) for information on IP packet filtering with IRIX.
This section discusses general hardware configuration issues for the basic setup of a dual-homed host acting as the firewall, and then presents the “screened host” and “screened subnet” firewall configurations.
You can configure your Silicon Graphics host hardware for use in a firewall by making it a dual-homed gateway—that is, giving it two network connections. Figure 1-1 illustrates the general idea of using a dual-homed host as the firewall.
Creating a dual-homed host may involve, for example, adding an additional Ethernet controller board, or you may already have two Ethernet connections. For specific information on the network hardware in your system, refer to your system documentation. For information on configuring network hardware, refer to “Networking Hardware” in the IRIX Advanced Site and Server Administration Guide.
A screened host scenario uses a router to screen traffic between the Internet and the external network connection of the firewall host. It can further limit traffic to a few ports of the firewall host. No traffic is allowed from the outside to any other host on the internal network. This is the typical connection to the Internet in which the router is provided by the Internet service provider. Figure 2-1 illustrates the basic screened host scenario.
An additional level of complexity—and flexibility—is added when you expand the screened host scenario to a screened network scenario. The basic design remains the same, but the screened network receives all external traffic. Both the Internet and the internal network have access to the screened network, but traffic must still pass through the firewall host. This is useful for sites that want to make multiple servers available to the Internet and yet maintain a secure internal network. You could, for example, use one of the public hosts as your WWW server and another as an FTP server, depending on what you want to make available and the relative CPU loads expected.
In the situation shown in the example, you continue to concentrate your security efforts on the single firewall host . Remember though, that your servers outside of the firewall are more easily compromised as they are protected only by a router. Keep your private data on the internal network and forward important data collected on the public servers to an internal host. (Details on software configuration are discussed in the next section.)
This section discusses the basic network addressing configuration required on a firewall host, and then provides details on configuring IRIX software to tighten security on the host.
|Note: Unless specified otherwise, all the software changes discussed in this section are to be performed on the firewall host.|
A dual-homed host is configured in network software as if it is two hosts, each with a different network address and, optionally, a different name. Use separate IP addresses for the two (or more) network interfaces. Refer to “Configuring a Router with Two Interfaces” in the IRIX Advanced Site and Server Administration Guide.
This section discusses various modifications you can make to the IRIX operating system software to provide for increased network security. Some of these changes are highly desirable on a firewall; others are more a matter of personal choice depending on the level of security you feel is necessary. The issues discussed include why the changes must or might be made.
The following discussion of changes made to the firewall host software also applies to any host made publicly-accessible, such as the WWW server and FTP server shown in the screened subnet example in Figure 2-2.
|Note: When you have finished the procedures described in this section, reboot your firewall system to ensure that all changes take effect. Many of these changes do not take effect until the system is rebooted.|
By default, IRIX forwards IP packets on machines with more than one network hardware interface. You must edit a kernel configuration file, run autoconfig, and then reboot to disable this default.
Follow this procedure to turn off automatic IP packet forwarding:
Edit the file /var/sysgen/master.d/bsd, changing the value of ipforwarding to 0:
Change the line:
int ipforwarding = 1;
int ipforwarding = 0;
Save the modified /var/sysgen/master.d/bsd file and exit from the editor.
Run autoconfig with the -f option:
# autoconfig -f
This creates a /unix.install file which becomes the new /unix after the system is rebooted.
Reboot your system.
To verify that IP packet forwarding has been disabled after your system comes back up, use the netstat command:
# netstat -s -p ip | grep forwarding
You should see the following:
0 packets forwarded (forwarding disabled)
If you do not see this message, repeat steps 1 through 5 until you do. (Be sure that your root file system has enough disk space so that the /unix.install file is being created correctly. See autoconfig(1M) for more information.)
When your system starts up, the inetd process reads the /etc/inetd.conf file for a list of Internet services to support. Comment out services listed in this file that are not very secure or that you are not using.
|Note: These services are being disabled on the firewall only. Services that are commented out in the system files on the firewall may still be available on your internal network—you just can't use them on the firewall host.|
Edit the file /etc/inetd.conf, and add the # symbol at the beginning of the following lines to comment them out (some may have already been commented out):
exec stream tcp nowait root /usr/etc/rexecd rexecd bootp dgram udp wait root /usr/etc/bootp bootp rstatd/1-3 dgram rpc/udp wait root /usr/etc/rpc.rstatd rstatd walld/1 dgram rpc/udp wait root /usr/etc/rpc.rwalld rwalld rusersd/1 dgram rpc/udp wait root /usr/etc/rpc.rusersd rusersd rquotad/1 dgram rpc/udp wait root /usr/etc/rpc.rquotad rquotad bootparam/1 dgram rpc/udp wait root /usr/etc/rpc.bootparamd bootparam ypupdated/1 stream rpc/tcp wait root /usr/etc/rpc.ypupdated ypupdated rexd/1 stream rpc/tcp wait root /usr/etc/rpc.rexd rexd
In other words, they should look like this:
#exec stream tcp nowait root /usr/etc/rexecd rexecd #bootp dgram udp wait root /usr/etc/bootp bootp #rstatd/1-3 dgram rpc/udp wait root /usr/etc/rpc.rstatd rstatd #walld/1 dgram rpc/udp wait root /usr/etc/rpc.rwalld rwalld #rusersd/1 dgram rpc/udp wait root /usr/etc/rpc.rusersd rusersd #rquotad/1 dgram rpc/udp wait root /usr/etc/rpc.rquotad rquotad #bootparam/1 dgram rpc/udp wait root /usr/etc/rpc.bootparamd bootparam #ypupdated/1 stream rpc/tcp wait root /usr/etc/rpc.ypupdated ypupdated #rexd/1 stream rpc/tcp wait root /usr/etc/rpc.rexd rexd
If you want details on the services you are disabling, refer to their reference pages. For example, refer to rexecd(1M) for more information on the rexecd daemon.
ftp stream tcp nowait root /usr/etc/ftpd ftpd -la telnet stream tcp nowait root /usr/etc/telnetd telnetd shell stream tcp nowait root /usr/etc/rshd rshd login stream tcp nowait root /usr/etc/rlogind rlogind tftp dgram udp wait guest /usr/etc/tftpd tftpd -s \ /usr/local/boot /usr/etc/boot
If you comment them out (totally disable them), they should look like this:
#ftp stream tcp nowait root /usr/etc/ftpd ftpd -l #telnet stream tcp nowait root /usr/etc/telnetd telnetd #shell stream tcp nowait root /usr/etc/rshd rshd #login stream tcp nowait root /usr/etc/rlogind rlogind #tftp dgram udp wait guest /usr/etc/tftpd tftpd -s \ /usr/local/boot /usr/etc/boot
To be safe, it is best to disable all those services with the comment character as shown above. If, however, you must include any of these services, change them as indicated below so that they record a log of their use in the file /var/adm/SYSLOG:
ftp stream tcp nowait root /usr/etc/ftpd ftpd -ll shell stream tcp nowait root /usr/etc/rshd rshd -Lal tftp dgram udp wait guest /usr/etc/tftpd tftpd -s -l -h /dev/null
Of these, enabling rshd is probably the most dangerous, and tftpd is almost never required on a firewall. Regarding ftpd, refer to the section “Setting Up a Proper Anonymous FTP Account”. Note the options added to each daemon invocation. (For more information, refer to the reference page for any daemon you modify.)
The telnetd and rlogind entries have not been included here because remote logins can (and should) be controlled with the use of one-time passwords. One-time passwords are just that—a password can be used once to gain access, but any future use of that same password is disallowed. There are various ways to implement one-time passwords, and how (and if) you use them at your site depends on your need for remote login capability and the degree to which you want to authenticate such logins. Refer to the Firewalls and Internet Security book referenced in “Books”.
The fingerd service is also a potential security hole because it is a source of account names. You can use the -S option to suppress information about login status, home directory, and shell, which might be used to attack security:
finger stream tcp nowait guest /usr/etc/fingerd fingerd -S
Or, to be more secure, you can configure fingerd with the -f option, to return just a message file. In the following example, a message has been placed in /etc/fingerd.message:
finger stream tcp nowait guest /usr/etc/fingerd fingerd -f \ /etc/fingerd.message
and the contents of /etc/fingerd.message might say something like:
Thank you for your interest in XYZ company. Please contact us at xyz.email.address or 1-800-XYZ-PHON for more information.
The same message is then returned for any finger access.
When you have finished making changes to the /etc/inetd.conf file, write the changes and quit the editor. The changes take affect after a reboot or, if you want to apply them immediately, enter:
# killall -HUP inetd
Test any modified services to be sure they perform as expected.
Limit the number of users with login accounts on the firewall system as much as possible. All accounts in /etc/passwd should have a password (see passwd(1)).
Check the /etc/passwd file to be sure that all accounts have passwords—the second field should not be empty (::).
Use the passwd command to add passwords for any accounts that do not have one. Choose long passwords composed of arbitrary ASCII characters—the password should not be in any dictionary.
Edit the /etc/default/login file to include the following lines:
This causes all login attempts—successful or not—to be recorded in the system log (see syslog(3C)).
This causes login to exit after a single incorrect login. Note that if you set this value to 0, it allows unlimited login attempts.
Sleep for 5 seconds after an unsuccessful login attempt before exiting. Make it a longer period if you are experiencing attempts at password guessing.
No user is allowed to log in without a password.
For more information on these fields and the /etc/default/login file, refer to login(1).
Check to see if there are any /etc/hosts.equiv or $HOME/.rhosts files. These files can be configured to allow remote access without password protection, and should not be allowed on a firewall host. Refer to hosts.equiv(4) for more information.
You can limit access to the firewall host's RPC services by use of the portmap command's -a option. This allows you to specify the host(s) and/or network(s) within your firewall that are allowed access to RPC-based services. Edit the file /etc/config/portmap.options to add options to the portmap command that is executed at system startup.
For example, if you create a /etc/config/portmap.options file with the following entry:
access to firewall host RPC services are restricted to hosts on the Class C network 192.0.2.
The syntax for the -a option allows you to specify multiple network masks, network addresses, and host addresses. As usual, the fewer hosts and/or networks allowed access, the better the security. Refer to the reference page portmap(1M) for more information.
Because NIS (formerly called Yellow Pages) has a number of known security holes, remove it from the firewall host as shown in the following steps:
Remove the NIS software from the firewall host with the versions command:
# versions remove nfs.sw.nis
Certain databases may have been modified to add NIS information by including a + symbol in database entry. Use an editor to remove any lines beginning with the + symbol from the files /etc/passwd, /etc/group, and /etc/aliases.
Remove the /etc/netgroups file if it exists.
Exporting filesystems and remote mounting external systems on the firewall host can present security problems. You have a few options:
You can disallow NFS altogether:
# chkconfig nfs off
You can edit the /etc/exports file to limit exported filesystem permissions and access. You can, for example, use the rw=hostname option to limit read-write access to a specific host, or you can use the access=client option to limit mounting to specified hosts. Refer to the reference page for exports(4) for more information.
If you choose to mount external systems on the firewall host, use the mount command with the nosuid option to prevent running a trojan horse. Refer to the reference page for fstab(4) for details.
The default configuration allows all hosts access to your display, and this should be disabled. Edit the /var/X11/xdm/Xsession* files to comment out or remove the xhost + entries. For example, in /var/X11/xdm/Xsession, the lines that look like this:
# Gives anyone on any host access to this display /usr/bin/X11/xhost +
should look like this:
# Gives anyone on any host access to this display # /usr/bin/X11/xhost +
Also inform users not to use the xhost + command, or simply delete it.
For even better security (just commenting out xhost + still allows local programs to connect to the X server), you can enable X authority. To do this, change the DisplayManager*authorize entry in /var/X11/xdm/xdm-config to say:
This makes xdm generate “magic cookies” (put in each user's $HOME/.Xauthority file) which are then required for any X client to connect to the X server. This provides a good means of X server access control. (Note that this may already be the default on your system.).
If you want to allow anonymous FTP access to the firewall host (or any publicly-accessible host), complete instructions for an anonymous FTP account are given in the reference page for the daemon process, ftpd(1M). Note that if you allow anonymous FTP access, you should enable logging but not disable the ftpd process as was described in “Limiting inetd Services”.
An additional risk is incurred if you allow writes to your anonymous FTP directory. Excessive writes to a crucial system partition could disable the system. It is a good idea to isolate the ftp directory to a separate partition or disk (if you allow writes) for this reason.
Log files provide useful information to the firewall administrator, recording specific or all attempts at firewall host login. The various options used to turn on login logging for different daemons have been covered in the discussions on each daemon. Note that the log files must be reviewed periodically to be of use.
Log files are sensitive information and need not be stored on the firewall host. Refer to syslogd(1M) for information on how to forward syslog messages from the firewall host to a trusted host inside the firewall.
All software on a firewall host should be watched for modification. A record of checksums of software should be kept and compared periodically to detect unauthorized changes. For this reason too, the less software installed on the firewall host the better.
You can take great pains to make a secure firewall and then have security compromised by users ignorant of the consequences of their actions. If possible, do not allow user accounts on the firewall host. If you do allow user accounts, be sure to tell the account holders:
Don't use .rhosts files (you can add the -l option to the rshd invocation in /etc/inetd.conf and thereby disallow these files on the firewall. See rshd(1M) for more information.)
Use passwords with long, non-dictionary, ASCII strings, change them frequently, and don't write them down!
Don't use the “xhost +” command (you can delete the binary, or limit its execution to the superuser as well.).
Even your supposedly protected internal network can be compromised by inappropriate actions of users. If, for example, a user on an internal host attaches a modem and establishes a PPP or SLIP session with an external site, you now have a situation in which the external world has two connections to your internal network—one through the firewall, but the other directly to a non-secure, internal host.
While it is beyond the scope of this document to describe how to configure your internal network, this section discusses issues of DNS and sendmail configuration that relate specifically to firewall security.
DNS, the name service used on the Internet, should be configured for your site to give out the addresses that other sites need to contact you. This might include the address of your router, your firewall host, and any other machines you want others to be able to communicate with. In the case of a simple firewall comprised of a dual-homed host, the dual-homed host would be a DNS server, providing the address of the Internet side of its network connection. In the case of a screened subnet, the DNS server could be any of the “public” hosts in the subnet, and it could provide addresses for all of these hosts and the router.
You should also set up the DNS Mail eXchanger (MX) record to advertise the name of the host(s) responsible for mail at your site. This may be the firewall host or another host. Do not publish internal host names and addresses on the firewall host. If you have a single firewall host performing multiple services, say FTP and WWW serving, use CNAME records to “alias” the services to the host name. This makes it easy to move these services to different hosts if you want to separate them later.
This section presents some suggestions for limiting the susceptibility of your site to an attack through the electronic mail system. Internet electronic mail is based on the Simple Mail Transfer Protocol, or SMTP. The program that implements that protocol is commonly referred to as sendmail. sendmail is a large and complicated program that is frequently the subject of attack.
Your mail system should be configured cooperatively with your DNS configuration. That is, whichever machine your DNS server is advertising as your Mail eXchanger (MX) host, must have its sendmail configured to accept mail for your network, and to do the appropriate thing with it once it is received. Usually that means to forward the mail to a master mail machine on the internal network, which knows users' internal addresses, and how to deliver the mail to them.
A note about current convention: It is popular to use the domain name of your network as your electronic mail address. For example, user “harry” at company XYZ corporation, whose domain name is XYZ.com would have the electronic mail address of “harry@XYZ.com”.
To reinforce the electronic mail address of your site, and to make it easy for others to reply to your users' mail, it is recommended that you configure your sendmail to rewrite all your addresses to conform to the above convention.
For details on how to configure sendmail, refer to the IRIX Advanced Site and Server Administration Guide.
If a barrage of email is sent to your firewall host, it can fill up the disk and paralyze further operation. If you are concerned about this possibility, isolate the mail spool by putting it on a disk or disk partition of its own. While this does not prevent email from being overwhelmed, it does keep a crucial system disk partition, such as /usr, from filling up.
A proxy server is an application that implements security for a particular network service. It is basically an application-level gateway—by “understanding” the particular application protocol, it is able to transparently intercept traffic and so implement protocol-specific security, logging, authentication, and so on.
Proxy servers provided on the firewall can allow, for example, internal users to use Netscape Navigator™ to access the World Wide Web, use ftp to transfer files between a host on the internal network and one on the Internet, or to telnet to an external host for an interactive session.
Two of the most common proxy server solutions are those supplied in the TIS Firewall Toolkit, and the SOCKS proxy server. The proxy servers available with the TIS Firewall Toolkit implement server-side only applications, in which one proxy server exists for each supported application. The SOCKS approach utilizes a socksd process on the server, and then requires any application that communicates with it to be “SOCKSified” that is, compiled with the SOCKS library. The Netscape Navigator, for example, comes already “SOCKSified”.
Refer to “Proxy Servers” and the WebFORCE page on Proxy Servers for more information