Next: Resources on the Internet Up: *NIX Security Guide Previous: Introduction Contents
This section will provide a starting point for securing your *NIX computer and will help you avoid the inconvenience and lost time involved restoring from backups or worse still reinstalling the operating system and local software from scratch.
Internet services are things such as FTP and telnet that you provide to users on the Internet. While these services can be useful to legitimate users they can also provide a means by which an intruder can gain unauthorised access to your machine. If you don't need a service, don't run it. For instance, if you have an account on a School UNIX machine that provides e-mail facilities there is no point running a mail service on your workstation. Removing unneeded services removes security vulnerabilities that are known or could become known and also frees you of the responsibility of applying patches or upgrading the service when someone finds security problems with it later. Services such as NFS, IMAP, POP3, SMTP, HTTP, Telnet, and FTP should not be run on personal workstations.
inetd is a super or meta daemon, which means it provides access to multiple services. It is the facility many *NIX systems use to provide common Internet services. Outlined here are a few things you can do to improve your computer's security by limiting services provided by inetd. Alternatives to inetd such as xinetd exist and they should be similarly audited to stop unnecessary services.
Personal workstations should probably not even run inetd. Running ssh for secure remote access to your workstation is most likely sufficient. To disable inetd, log in as root and look in directories such as /etc/init.d or /etc/rc.d for a script called inetd, or run the command grep inetd * in those directories to find where inetd is started. When you have found the line or script that starts inetd comment out the line using a hash (#), or add the command exit 0 to the top of the inetd script so it begins like this:
#!/bin/sh exit 0 ...
For FreeBSD, edit /etc/rc.conf and set:
inetd_enable="NO"
When you have made the above change, stop inetd like this:
killall inetd
-OR-
kill -KILL `ps aux | grep inetd | grep -v grep | awk '{print $2}'`
If you must run inetd you should disable unwanted services as follows:
killall -HUP inetd
-OR-
kill -HUP `ps aux | grep inetd | grep -v grep | awk '{print $2}'`
If you run xinetd you should edit the configuration file /etc/xinetd.conf and files in the directory /etc/xinetd.d/ to disable unwanted services. Don't forget to restart xinetd--refer above for use of killall -HUP or kill -HUP. As per inetd you may wish to disable xinetd on workstations that don't need to provide Internet services.
After you have audited your meta daemon services you should check which ports remain open on your machine. You can do this with the command 'netstat -Lan', or if you run FreeBSD you can use 'sockstat -4'. If you use netstat you can see which process is attached to a particular port using the fstat or lsof commands as per this example,
sifaka# netstat -Lan Current listen queue sizes (qlen/incqlen/maxqlen) Proto Listen Local Address tcp4 0/0/128 *.6000 sifaka# lsof -i :6000 COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME XFree86 463 root 1u IPv4 0xdff28920 0t0 TCP *:x11 (LISTEN)
TCP Wrappers or tcpd is a package that can be used with inetd to improve security. It provides access control and improved network connection logging. tcpd should be combined with an inclusive firewall for adequate protection from untrusted computers and networks.
When tcpd is installed remote computers connect first to tcpd. tcpd will then log the connection and perform access control based on the contents of the files /etc/hosts.deny and /etc/hosts.allow before either transferring control to the actual service requested by the remote user or rejecting the connection.
Below is a sample minimalist inetd configuration file that provides two insecure services--it is an example only.
ftp stream tcp nowait root /usr/sbin/tcpd /usr/sbin/wu-ftpd -l telnet stream tcp nowait root /usr/sbin/tcpd /usr/sbin/in.telnetd
It is safe to either leave /etc/hosts.allow empty and place your access control entries in /etc/hosts.deny or vice-versa. To get information on the format of the TCP Wrappers files, use the command man 5 hosts_access.
The following simple example will grant access from the domain phys.unsw.edu.au to all services except SSH; two trusted hosts in the same domain are also permitted SSH access.
# /etc/hosts.deny for host plio.phys.unsw.edu.au ssh : verreaux.phys.unsw.edu.au : ALLOW ssh : sifaka.phys.unsw.edu.au : ALLOW ALL EXCEPT ssh: .phys.unsw.edu.au : ALLOW ALL : DENY
Refer to section §3.2 for a link to a site where TCP Wrappers can be found. Many *NIX distributions come with TCP Wrappers already installed so your experience with the package will probably be limited to editing the tcpd access control files /etc/hosts.allow and /etc/hosts.deny.
SSH server support and SSH clients are now so widely available that it is hard to justify providing Telnet and FTP. When using Telnet and FTP, usernames and passwords are transmitted in-the-clear (unencrypted) over the wire which makes them vulnerable to packet sniffing. Disable Telnet and FTP if you do not have a specific requirement to enable them.
Don't run anonymous FTP as it is not worth the risk unless you really know what you're doing you and are prepared to periodically plug security holes that inevitably will be found later. If you must run anonymous FTP avoid at all cost allowing users the ability to upload files and create directories via FTP. Many FTP services provide a configuration file that can limit who may login--people running such FTP servers should include at least these lines to make their FTP service safer:
root daemon bin sys sync games man lp mail news uucp nobody ftp
Secure Shell (SSH) is an alternative to the standard *NIX r* commands such as rlogin, rsh, rexec, and rcp. Its use is highly recommended. The enabling or use of any of the r* services or commands is highly not recommended. All of the main School workstations support the SSH 2.x protocol and thus a user with a Secure Shell enabled personal workstation will be able to more safely connect to the majority of hosts in the School. The benefits of Secure Shell include username and password pairs not being transmitted in in-the-clear on the wire, an encrypted network channel, and secure X11 connection forwarding which also obviates fiddling with the DISPLAY shell environment variable. Refer to section §3.3 for the location of SSH and OpenSSH on the Internet. You can find help on installing SSH server and client software at http://help.phys.unsw.edu.au/ssh.php.
Once SSH has been installed, the behaviour of the service is configured in the file /etc/sshd_config or /usr/local/etc/sshd_config. Examine this file carefully and set options as required. Here are some suggested settings to improve SSH security:
IgnoreRhosts yes RhostsAuthentication no PermitEmptyPasswords no PermitRootLogin no
Packet filtering is the process of selectively limiting traffic to or from a device. We deal here with packet filtering for the Linux, FreeBSD and Tru64 UNIX.
With the advent of the 2.4.x Linux kernel the concept of connection state based firewalling is a reality for Linux. You should utilise this facility in combination with TCP Wrappers and the disabling of unnecessary services to protect your computer. For detailed information on Linux firewalling visit the Linux Documentation Project HOW-TO page and look for the firewalling HOW-TO. For more information on the packet filtering scheme implemented in the 2.4.0 and higher kernels read the Linux Packet Filtering HOWTO and the NAT HOWTO. Another useful read is the Firewalls section of the FreeBSD Handbook.
Here is a simple variation on an iptables recipe mentioned in the Packet Filtering HOWTO which provides reasonable protection to people with 2.4 or greater Linux kernels:
## Insert connection-tracking modules (not needed if built into kernel). insmod ip_conntrack insmod ip_conntrack_ftp ## Create chain which blocks new connections, except if coming from inside. iptables -N block iptables -A block -m state --state ESTABLISHED,RELATED -j ACCEPT iptables -A block -m state --state NEW -i ! eth0 -j ACCEPT iptables -A block -j DROP ## Jump to the chain from INPUT and FORWARD chains. iptables -A INPUT -j block iptables -A FORWARD -j block
The above could be made into a script that runs just before ifconfig is used to activate the primary Ethernet interface on startup. For example, you could add the lines to your /etc/init.d/netbase startup script in Debian Linux.
FreeBSD's packet filtering rules can be manipulated using the ipfw command. In addition to the FreeBSD Handbook 'Firewalls' section mentioned above, enter man firewall or man ipfw on a FreeBSD system for detailed information. From an out of the box configuration you can probably get away with editing just two files to enable and configure filtering for your network:
firewall_enable="YES" firewall_type="CLIENT"
net="129.94.162.0" mask="255.255.254.0" ip="<YOUR_IP_ADDRESS>"
Having made the above changes, reboot or start up your firewall (run these commands from the local console in case you bollocksed up /etc/rc.firewall and wind up locking yourself out):
kldload ipfw sh /etc/rc.firewall
For added security you may wish to insert additional rules into the 'CLIENT' model to block access even from the local network to certain services.
As of this writing the interface filtering available for Tru64 UNIX is far less flexible and elaborate than that available for other operating systems such as Linux, but it nonetheless can be used to effectively block IP access from selected computers or networks. You start by populating a configuration file with entries as follows:
# Syntax: # interface-name address mask action # Block IP 216.34.236.5 that attacked us and log any connection attempts: tu0 216.34.236.5 255.255.255.255 denylog # We don't trust the 200.239.125 network to talk to us: tu0 200.239.125.0 255.255.255.0 deny
You then issue the command ipconfig tu0 filter to activate the filter or affect changes you made to the file. As of this writing the Tru64 UNIX filtering has no provision for blocking individual ports nor for logging of port or protocol information for blocked connection attempts. Refer to man 4 ifaccess.conf for further details.
It is a good idea to periodically run utilities such as tripwire and chkrootkit on your workstation to check for oddities including unexpectedly modified files and hidden processes which may indicate a system compromise. See section §3.3 for download locations.
These checklists roughly summarise the process of setting up a machine so that it won't be compromised.
*NIX INSTALLATION CHECKLIST
--------------------
[ ] DISCONNECT FROM NETWORK
[ ] INSTALL LATEST OS VERSION FROM CLEAN MEDIA
[ ] DISABLE UNNECESSARY SERVICES
/etc/rc.d
/etc/init.d
/sbin/init.d
/etc/inetd.conf
/etc/xinetd.conf
/etc/xinetd.d/*
[ ] INETD: USE TCP WRAPPER
man 5 hosts_access
/etc/inetd.conf
/etc/hosts.deny
-OR-
/etc/hosts.allow
[ ] SETUP INCLUSIVE FIREWALL
man iptables (LINUX)
/etc/rc.conf (FREEBSD)
/etc/rc.firewall (FREEBSD)
man firewall (FREEBSD)
man ipfw (FREEBSD)
[ ] SETUP TRIPWIRE AND GENERATE DATABASE
[ ] COPY TRIPWIRE DATABASE+CONFIGS OFF-HOST
[ ] INSTALL CHKROOTKIT
[ ] SET TRIPWIRE+CHKROOTKIT TO RUN IN CRON DAILY
AND MAIL RESULTS TO OFF-HOST ACCOUNT
[ ] LEVEL 0 DUMP
[ ] CONNECT TO NETWORK AND APPLY OS PATCHES
[ ] GENERATE NEW TRIPWIRE DATABASE AND COPY
OFF-HOST
[ ] SETUP TO SYSLOG OFF-HOST IF POSSIBLE
/etc/syslogd.conf
[ ] LEVEL 0 DUMP
[ ] SUBSCRIBE TO OS SECURITY E-MAIL LIST(S)
MAINTENANCE CHECKLIST
--------------------
[ ] READ TRIPWIRE REPORTS DAILY
[ ] READ CHKROOTKIT LOGS DAILY
[ ] HEED SECURITY ADVISORIES (CERT/AUSCERT)
[ ] HEED OS SECURITY ADVISORIES
[ ] APPLY OS PATCHES WHEN SECURITY BULLETINS ADVISE
[ ] USE LATEST STABLE APPLICATION VERSIONS WHEN
SECURITY BULLETINS ADVISE
[ ] UPDATE TRIPWIRE DATABASE PERIODICALLY WHEN
SYSTEM/APPLICTION CHNAGES ARE MADE AND
COPY DATABASE OFF-HOST
[ ] UPDATE CHKROOTKIT SOFTWARE REGULARLY
[ ] USE A RELIABLE BACKUP SCHEME
Physics IT Support 2003-09-16