Tightening Security in IRIX

Tightening Security in IRIX

This section discusses various modifications you can make to the IRIX operating system software to provide 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 5-3.

Note: Do not connect your hardware to the external network until you make the changes described in this section. When you have finished the procedures, reboot your firewall system to ensure that all changes take effect. Many of these changes do not take effect until the system is rebooted.

Disable Forwarding of IP Packets

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:

As root, edit the file /var/sysgen/master.d/bsd, changing the value of ipforwarding to 0:
Change the line

int ipforwarding = 1;
to

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 (see reboot(1M)).
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 filesystem has enough disk space so that the /unix.install file is being created correctly. See autoconfig(1M) for more information.)

Limiting inetd Services

When your system starts up, the inetd process reads the /etc/inetd.conf file for a list of TCP/IP 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.

Comment out or restrict the following entries in /etc/inetd.conf:

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. (Doing so means, however, that the host can only be accessed from the local console.) Of these services, enabling rshd is probably the most dangerous, and tftpd is almost never required on a firewall. Regarding ftpd, refer to "IRIX Admin: Networking and Mail." 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

Note the logging 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 that 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

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.

This message is then returned for any finger access.

When you have finished making changes to the /etc/inetd.conf file, write the changes and exit from the editor. The changes take affect after a reboot. If you want to apply them immediately, enter:
# killall -HUP inetd
Test any modified services to be sure they perform as expected.

Password Protection

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 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.

Refer to "Password Administration" for details on host access password security.

Limiting rpc Services Access

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) 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, suppose you create a /etc/config/portmap.options file with the following entries:

-a 192.0.2.0
-a 192.14.12.0

This restricts access to firewall host RPC services to hosts on the Class C networks 192.0.2 and 192.13.12.

The syntax for the -a option allows you to specify multiple network masks, network addresses, and host addresses. As usual, the fewer hosts or networks allowed access, the better the security. Refer to the reference page portmap(1M) for more information.

Disabling NIS (YP)

Because the nature of NIS (formerly called Yellow Pages) does not accommodate security needs, remove it from the firewall host:

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 a 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.

Caution: You should not run NIS on a firewall. If you must run NIS, be sure the server is secure and have the clients run ypbind with the -ypsetme option which provides some minimal security.

Limiting NFS Access

Exporting filesystems and remote-mounting external systems on the firewall presents security problems. You should not use NFS on a firewall--remove it with versions remove nfs.sw.nis. If for some reason you cannot do this, you have a few (less secure) options:

You can disallow NFS altogether, using this command:
# 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 fstab(4) reference page for details.

In general, you should mount all filesystems other than your system directories with the nosuid, nodev options (refer to mount(1M)).

Setting Up a Proper Log File

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 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 are best not 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.

Checking Software Integrity

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 should always be on the watch for such things as device files outside of /dev, and files with SUID and GUID permissions set.

You can use the versions command to display a list of system files modified since installation. For example:

# versions changed
Configuration Files

m     = modified since initial installation
?     = modification unknown
blank = file is as originally installed

  /etc/init.d/netsite
m /etc/init.d/netsite.O
m /etc/init.d/netsite.N
m /etc/uucp/Devices
  /etc/uucp/Devices.N
m /var/X11/xdm/Xsession.dt
  /var/X11/xdm/Xsession.dt.O
  /var/X11/xdm/xdm-config
<etc>

You can also use the versions -m command to list only modified installed files. Refer to versions(1M) for more information.

Educating Users

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. (As the superuser, 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. (As superuser, 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.