Using Bastille Linux is optional but recommended. This chapter discusses the following:
 | Note: You must have access to the information listed in Appendix B, “Network Connectivity Worksheet”. |
Bastille Linux is a product that will provide increased security for your SGI Internet Server for Messaging. It is an open-source development effort to which SGI has contributed hardware, enhancements, and bugfixes. For the latest licensing, versioning, and security education information, please see the official project Web site:
http://www.bastille-linux.org |
This chapter provides additional documentation intended to make Bastille Linux easier to use as part of the deployment process of your SGI Internet Server for Messaging.
The purpose of Bastille Linux is to make it harder for someone to gain unauthorized access and/or root privileges to your system. It provides an interactive universal hardening program intended to be run immediately after installing Red Hat software. Because your SGI Internet Server for Messaging is preinstalled, you will be given the option to run it during your first boot-up.
When prompted to run the Bastille Linux hardening script, you should answer YES if you intend to put your system into production on an untrusted network such as the Internet.
 | Caution: Using Bastille Linux does not mean your system is impregnable; the only certain way to safeguard your system is to disconnect it from any network and put it behind a locked and guarded door. The point of using Bastille Linux is to make your network system so hard to break into that intruders will move on to easier systems. |
Bastille Linux has verbose and nonverbose options, so it is useful for both security savvy administrators and those who are inexperienced. The extensive online help in the verbose mode makes it an excellent instructional tool for those wishing to learn more about how to secure a Linux operating system. In addition, most tasks are optional, providing the flexibility required to provide the security appropriate to your site.
Bastille provides secure operations for the following products (in alphabetical order):
Bastille Linux keeps the following plain-text log files of each session:
/root/bastille-action-log, a complete transcript of the session
/root/bastille-input-log, a listing of all the answers given by the user
/root/bastille-error-log, a record of any errors that may have occurred
It is important to prevent a unauthorized access to these files. They be accessed only over a strongly encrypted channel, a private network, a serial connection, or a local console.
The Bastille Linux script will ask you a series of questions. Each answer you give is immediately processed, with no opportunity to skip questions or revise the answers. Therefore, it is important that you know the following information prior to running the Bastille Linux script:
Which interfaces are public and which (if any) are private.
IP addresses associated with each interface.
Which services should be available on each interface (everything else should not be available).
For each network port, a list of specific ports for which the kernel should allow connections. Instead of port numbers, you may also list service names as they appear in /etc/services, or a combination of both. For example, 192.82.208.21:80 is the HTTP port for the reality.sgi.com Web site. In Bastille you could refer to either the port number (80 in this case) or its popular name (HTTP), which can be found in the /etc/services file.
IP addresses of primary DNS co-master and secondary DNS servers.
IP address of network time protocol (NTP) co-master (to keep system clocks synchronized).
Hostname or IP address of a host for remote system logging (syslogging), if available. Ideally, this loghost should be accessible only on your private network. In a pinch, you can have production servers on a public network perform syslogging for each other.
Also see “What You Need to Know Before Answering IPCHAINS Questions”.
| Note: A complete log of your session is kept in the /root/bastille-action-log file. This is useful if you have multiple servers. |
How you answer the Bastille Linux questions depends upon your own situation. The rest of this appendix shows an example of the answers applicable to systems running a Web server or other front-end application on the Internet, and are therefore at substantial risk of attack by hackers:
The server to be locked down has one or more network interfaces. Zero or one of these are connected to a private subnet; all others are connected to public subnets. If a private subnet is to be used, the system acts as a secondary firewall (also known as a firewall perforation). It therefore must be configured with great care.
The private network is either completely disjoint from all public subnets or else connected to one of them via a primary firewall.
The server will be used as a web hosting platform, with content updates by means of FTP uploads, and a low number of E-mail accounts for use by the hosted customers.
The following subsections show the Bastille questions and the recommended answer (in bold). The reason for choosing the recommended answer follows the question when necessary; if no reason is given, the default reason is to plug a security hole.
One of the key components of Linux Bastille is the IPCHAINS module. This module is used to help you build a configuration file for the ipchains(8)tool, which allows you to control (at the IP packet level) which systems can establish a connection to your server or to which systems your server can connect to based on the IP address and port number on each side of the connection.
Packets are filtered based on any combination of the following:
Source or destination IP address
Network interface they arrived on
IP protocol number
Source or destination TCP/UDP port number
That is, IP filtering allows you to specify exactly what network connections are allowed by evaluating the following parameters:
source_machine_IP#:Port# - destination_machine_IP#:Port# |
Supported IP protocols include TCP, UDP, and ICMP.
In order to correctly configure IPCHAINS, you need to know the following:
What systems should be allowed to connect to your server
What protocols they will be allowed to use
Who your system is allowed to connect to
What protocol it is allowed to use
You can review the list of protocols by looking in the /etc/services file.
The IPCHAINS configuration has the following chains:
INPUT chain, which lists the systems can connect to your server
OUTPUT chain, which lists the systems your server is allowed to connect to
FORWARDING chain, which is used for firewall systems
Each part functions the same way but needs to be configured separately; if you have a server with multiple network interfaces, each interface must be configured independently as well. Unless you are configuring a firewall, you should not need to configure forwarding other than to set the policy to DENY. SGI recommends that you use the DENY policy on all three chains.
The DENY policy has the following benefits:
It returns no information or error codes to the remote system, giving them no help in cracking your system's security.
If you didn't explicitly allow a packet, it is blocked.
The following example is for a system with two network interfaces:
eth0 is connected to a public network (that is, non-trusted)
eth1 is connected to a private network
Given that this is a mail server, you would allow only the following protocols to connect on the public interface:
SMTP on port 25
POP on port 110
IMAP on port 143
The INPUT chain for our public interface would be as follows:
Target Interface Source Protocol Port Input eth0: ANY tcp 80 Input eth0: ANY tcp 81 Input eth0: ANY tcp 443 Input eth0: ANY tcp 25 Input eth0: ANY tcp 110 Input eth0: ANY tcp 143 |
You would not enable any protocols on the OUTPUT configuration on the public interface. Any attempt to open a connection from your server to a remote server will fail. (Of course, if you had a business need that required you to open a connection to a server on the public network, you would need to configure that.)
On the private interface INPUT chain, you would allow the following protocols:
http on port 80
http on port 81
https on port 443
smtp on port 25
telnet on port 23
linuxconf on port 98
imap on purt 143
pop on port 110
ftp on ports 20 and 21
You would also need to consider how you will be backing up this system, and what tools you will be using to publish content to your server. Even though this is the private interface (and supposedly safe), it is still a good idea to specify exactly what hosts can open a connection with your server. The INPUT chain is as follows:
Target Interface Source Protocol Port Input eth1: ANY tcp 80 Input eth1 ANY tcp 81 Input eth1: ANY tcp 443 Input eth1: ANY tcp 25 Input eth1: ANY tcp 110 Input eth1: ANY tcp 143 Input eth1: 192.82.208.21 tcp 98 Input eth1: 163.154.38.32 tcp 23 Input eth1: 163.154.38.32 tcp 20 Input eth1: 163.154.38.32 tcp 21 |
The above example specifies a single host that can connect to the server on port 98 (Linuxconf). Even though this is on the private interface, it is still a good idea to control access to this port because it is an administrative tool.
You must also consider who your system can connect to. This is important because it can be used to prevent someone from exploiting a programming or application bug on your system and using it to open a connection out of your box to their system or using your system to attack other servers on your network. You should therefore use the DENY policy.
As a mail server you should have a very limited number of allowable OUTPUT connections, a couple of examples would be for DNS lookups or remote logging.
On your private interface you will have to consider issues like remote logging (syslog), which allows your server to write out its logs to a remote logging server, and what backup software you are using and how it runs. If your backup solution is designed to push content to the backup server, then your server must create a connection from itself to your backup server. In order to do that, your OUTPUT chain configuration must allow it, as follows:
Target Interface Destination Protocol Port Output eth1: Domain_Name_Server udp domain Output eth1: Remote_Log_Host tcp syslog Output eth1: Remote_Backup_host tcp port_number |
The only real difference in this configuration is that there is no eth1 interface.
However, even though you are blocking connections to your system, the packets (and the information contained in them) that are traveling to/from your system can still be viewed (snooped) by anyone with a system connected to your network. You must connect to your system for any number of reasons, such as to push content or to administer your server (such as with Linuxconf). Unless you use a tool that encrypts your communications (such as SSH or SSL), your data (such as passwords) can be stolen.
The INPUT chain on a single interface system must combine both eth0 and eth1 input chains from the example above. Because this is a mail server, you should only going to allow smtp, pop, imap, and https connections from any host. You also want to enable the publishing server to connect (such as by means of ftp), and other protocols you want to allow, such as telnet. For example:
Target Interface Source Protocol Port Input eth0: ANY tcp pop Input eth0: ANY tc[ imap Input eth0: ANY tcp https Input eth0: ANY tcp smtp Input eth0: 192.82.208.21 tcp linuxconf Input eth0: 163.154.38.32 tcp telnet Input eth0: 163.154.38.32 tcp ftp |
The OUTPUT chain still looks similar to the first example:
Target Interface Destination Protocol Port Output eth1: Domain_Name_Server udp domain Output eth1: Remote_Log_Host tcp syslog Output eth1: Remote_Backup_host tcp port_number |
| Note: Once a rule is matched it is acted on, so the order of the rules in your chains can be important. |
After you have a good configuration, you can use the following command to save it:
# /sbin/ipchains-save > myconfig |
Bastille Linux will output the /etc/rc.d/init.d/bastille-firewall file. This file contains all the IPCHAINS configuration information that you input using the Bastille script. You can edit this file to reflect any future changes or use the following command (via a script) to load in your previously saved configuration:
# /sbin/ipchains-restore < myconfig |
After you have completed the configuration, you can use the following command to review and modify your configuration:
# /sbin/ipchains -L -v |
After you have completed running Bastille, you should review the configuration of IPCHAINS and test your configuration.
Following are the questions and recommended answers for this example.
Would you like us to install the ipchains script? (Y or N): Y
You will be asked to choose initial settings for the firewall script. The defaults are generally the minimal recommended settings. To accept the default (shown in brackets), press the RETURN key. To change a nonempty default to an empty value, enter some white space before pressing RETURN.
Would you like us to install the ipchains script? Y
Would you prefer more verbose instructions for each step? (Y or N): Y
If you are unfamiliar with IP filtering, or security issues in general, you will benefit from the verbose mode.
Advanced networking options? (Y or N): Y
DNS_SERVERS ["0.0.0.0/0"]:(Hit space bar to zero out the defaults)
If left empty, the contents of /etc/resolv.conf will be used.
TRUSTED_IFACES ["lo"]: lo
PUBLIC_IFACES ["eth+ ppp+ slip+"]: eth0
INTERNAL_IFACES [""]: eth1
TCP_AUDIT_SERVICES ["telnet ftp imap pop-3 finger sunrpc exec login linuxconf ssh"]: telnet ftp imap pop-3 finger sunrpc exec login linuxconf ssh
UDP_AUDIT_SERVICES ["31337"]: 31337
ICMP_AUDIT_TYPES [""]:
TCP_PUBLIC_SERVICES [""]: 443 25 110 143
This will allow anyone connecting from the public interface to connect to POP, IMAP, HTTPS, and SENDMAIL ports.
UDP_PUBLIC_SERVICES [""]:
TCP_INTERNAL_SERVICES [""]: 20 21 23 25 80 98 110 143 443
This will allow anyone connecting from the private interface to connect to FTP, FTP data, TELNET, SENDMAIL, HTTP, LINUXCONF, POP, IMAP, and HTTPS ports.
UDP_INTERNAL_SERVICES [""]:
FORCE_PASV_FTP ["N"]: Y
TCP_BLOCKED_SERVICES ["1024 2049 2065:2090 6000:6020 7100"]: 1024 2049 2065:2090 6000:6020 7100
UDP_BLOCKED_SERVICES ["1066 2049 6770"]: 1066 2049 6770
ICMP_ALLOWED_TYPES ["destination-unreachable echo-reply time-exceeded"]:
ENABLE_SRC_ADDR_VERIFY ["Y"]: Y
IP_MASQ_NETWORK [""]:
IP_MASQ_MODULES ["ftp raudio vdolive"]: (Hit space bar to zero out the defaults)
REJECT_METHOD ["DENY"]: DENY
DHCP_IFACES [""]:
NTP_SERVERS [""]:
If you are using NTP, you must enter the IP address(es) here.
ICMP_OUTBOUND_DISABLED_TYPES ["destination-unreachable time-exceeded"]: destination-unreachable time-exceeded
For a more detailed description of how IPCHAINS works you should read the IPCHAINS HOWTO from this URL:
http://www.redhat.com/mirrors/LDP/HOWTO/IPCHAINS-HOWTO-4.html |
Apply new file permissions? YES
It is important to ensure that your system is as secure as possible. If access is gained by intruders, you want to log as much as possible and limit their ability to fully compromise the system.
Disable SUID status for ping? YES
Disable SUID status for dump and restore? YES
Disable SUID status of cardctl? (PCMCIA devices) YES
This is only relevant for laptop systems.
May we remove SUID status form at? YES
May we remove SUID status from dosemu (dos emulation) YES
May we disable SUID status for inndstart and startinnfeed? YES
May we disable SUID status for the printing binaries? YES
A server on the Internet should not be a print server.
May we disable the Berkeley r-tools? YES
May we disable SUID root on usrnetctl? YES
May we implement shadowing? YES
Various processes running as nonprivileged users must read the /etc/passwd file for information other than passwords. Shadowing ensures the passwords are stored in the /etc/shadow file, which only the superuser may read.
May we create a second UID 0 account and apply monitoring on the original root account? YES
There is no liability to doing this.
Please enter a name for the admin (UID0) account: password
May we modify useradd to do so? (make a root-owned, nonwritable .rhosts file in each account) YES
May we enforce real password aging? (expire in 180 days) YES
This is a good way to remind yourself to remain vigilant, and reduces the risk of attacks based on derelict accounts.
Please enter a name for your account? (ordinary user account)account_name
This should be done here rather than in linuxconf(8) because Bastille Linux will apply file and directory permission changes to each user later in the script. If you use linuxconf to create these accounts, they will not be secured appropriately.
May we restrict cron use to admins only, allowing you to add others one by one? YES
Should we do this? (password protect LILO) YES
Applying a LILO passwd does not affect reboots (or reboot times) and will not stop a system from rebooting after a failure (such as power failures). The only time the password is required is if parameters are specified on the command line.
Please enter a LILO password: password
Reduce the LILO delay to zero? (block entry at the LILO prompt) YES
In a production server, you have no need for the option to boot off a test kernel.
Do you ever boot Linux from the hard drive? (is LILO on the hard drive)? YES
In a production server, that is the default.
Do you want to apply our Linux Loader changes to a boot floppy? YES
If you have approved a change here, you will be asked to insert a boot floppy disk as this point. The changes should be reflected in your boot floppy. If you are skeptical, create a backup copy of your original boot floppy before you proceed.
Now, type in the Linux name of the drive device, like so: (floppy drive address fd0 fd1) fd0
The name of the built-in floppy drive.
Disable CTRL-ALT-DEL rebooting? NO
The CTRL-ALT-DEL feature should only be disabled if physical access to the system is restricted (that is, someone cannot pull the plug). Using the CTRL-ALT-DEL feature allows the system to shut down cleanly.
Password protect single user mode? YES
You must always know the root passwords to your production systems. If you forget one, you will lose access to that system unless you have set up .rhosts access from a secure system on the private network.
May we modify inetd.conf and /etc/hosts.allow to optimize use of wrappers? YES
tcp_wrappers is a good tool for managing which hosts are given access to various services and for logging access events. It represents a redundant line of defense to the ipchains(8) configuration.
Should we limit this to a particular set of IPs? (limit sshd to accept secure shell connections from only certain IP addresses) YES
To comply with US export restrictions on cryptography, the ISM product does not include the open source implementation of the ssh(1) secure shell package. However, if you are legally allowed to use encryption products in your country, SGI recommends that you obtain this drop-in replacement package for the insecure rsh(1) and rcp(1) commands.
Enter a set of IP address or networks, delimited by spaces address_or_networks
Specify a set of network operations center workstations, or the subnet they are on (which should be your most private).
Note: The format for a C-class subnet is x.y.z.0, netmask 0.0.0.255. You should have multiple systems.
Should we create "Authorized Use Only" banners for your site? Make default banner set? YES
Doing so makes it easier to prosecute an attacker and avoid being sued yourself.
May we add this additional logging? YES
The additional level of detail will probably prove useful one day in troubleshooting a problem.
Do you have a remote logging host? YES
The first thing successful attackers will do is attempt to cover their tracks by destroying the syslog. Ideally, the remote logging host will be on the private network, out of reach.
If you answer YES, you must also answer the following question:
Enter IP address of your remote logging host. IP_address
May we configure process accounting? YES
This will enable logging of resource consumption per process run.
May we deactivate apmd? YES
Deactivate NFS and samba? YES
There is no reason to run either of these on a server that is connected to the Internet.
Disable atd? YES
May we disable pcmcia services? YES
May we deactivate DHCPD? YES
DHCPD is only needed if you intend to use this system for IP address management.
Deactivate GPM? (for text mode) YES
However, answer NO if you are using KVM during staging or in production.
May we deactivate the news server daemon, innd? YES
innd(8) is only needed if you intend to use this system as a news server.
May we deactivate the routing daemons? YES
A production server connected to public and private networks should only route packets if it is a primary firewall.
May we deactivate the NIS server and client programs? YES
-
If you followed the suggestions in the earlier sections on ipchains(8) configuration, this will already have been done for you.
Deactivate the web server? NO
You must provide this service if you are planning to offer Web hosting.
May we bind the web server to the local interface only? NO
The hosted Web servers must be accessible on the public interfaces.
Bind to a particular interface only? NO
There is no harm in making a public Web server also accessible from a private network.
Please enter the IP address for apache to listen to (include the port) IP_address_and_port
Use the IP address of the primary interface (incoming requests). Specify port 80.
Deactivate following symbolic links? NO
You must allow this feature to compete in the Web hosting market.
Deactivate SSI (Server Side Includes)? NO
Disable CGI script execution for now? NO
Disable indices? (disable automatic generated index file) YES
The answers for FTP questions depend on the services you will be providing and other business requirements.
You will then be asked if it is OK to reboot the system now for the changes to take effect; you should answer YES.
See Chapter 5, “Enabling HTTP Access for Linuxconf Administration”, for the next steps.