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 server. 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, 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 server.
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. You will run it during the ISE configuration process documented in “What Do I Need to Do?” in Chapter 1.
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 should 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 the 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 Must 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 chapter shows an example of the answers applicable to systems that are running a Web server or other front-end application on the Internet, and who are therefore at substantial risk of attack by hackers:
The SGI 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 SGI 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 helps you build a configuration file for the ipchains(8) tool. This tool allows you to control the following at the IP packet level, based on the IP address and port number on each side of the connection:
Those systems that can establish a connection to your SGI server
Those systems to which your SGI server can connect
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.
To configure IPCHAINS correctly, you must know the following:
What systems should be allowed to connect to your SGI 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 that can connect to your SGI server
OUTPUT chain, which lists the systems to which your SGI server is allowed to connect
FORWARDING chain, which is used for firewall systems
Each part functions the same way but must be configured separately; if you have a SGI 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 do not explicitly allow a packet, it is blocked.
The following example is for a system with one network interface: eth0 is connected to a public network (that is, non-trusted).
Given that this is a web server, you would allow only the following protocols to connect:
http on port 80
https on port 443
smtp on port 25
Although it is possible to allow access to port 98 over a public network, this is not recommended. Source IP addresses can potentially be spoofed (in which one machine on the network masquerades as another), and passwords transported over a public network in clear text can potentially be viewed by a hacker. See Chapter 6, “Enabling HTTP Access for Linuxconf Administration”.
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 SGI 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 web server, you should only allow smtp, http, 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 http 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 is 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 |
| Note: Once a rule is matched, it is acted on; therefore, 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): YYou 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 prefer more verbose instructions for each step?
(Y or N): YIf 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"]:(Press the 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 [""]:
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 [""]: 80 443 25
This will allow anyone connecting from the public interface to connect to HTTP, HTTPS, and SENDMAIL ports.
UDP_PUBLIC_SERVICES [""]:
TCP_INTERNAL_SERVICES [""]:
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"]: (Press the space bar to zero out the defaults)
ENABLE_SRC_ADDR_VERIFY ["Y"]: Y
IP_MASQ_NETWORK [""]:
IP_MASQ_MODULES ["ftp raudio vdolive"]: (Press the 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
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 web server, you would allow only the following protocols to connect on the public interface:
http on port 80
https on port 443
smtp on port 25
The INPUT chain for the public interface would be as follows:
Target Interface Source Protocol Port Input eth0: ANY tcp 80 Input eth0: ANY tcp 443 Input eth0: ANY tcp 25 |
However, if you intend to allow your hosted customers to upload content by means of FTP, you must also open up ports 20 and 21 on the INPUT chain of your public interface. For POP3 and IMAP4 mail reader services, open up ports 110 and 143, respectively.
You would not enable any protocols on the OUTPUT configuration on the public interface. Any attempt to open a connection from your SGI 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 must configure it.)
On the private interface INPUT chain, you would allow the following protocols:
http on port 80
https on port 443
smtp on port 25
telnet on port 23
linuxconf on port 98
ftp on ports 20 and 21
You must also consider how you will be backing up this system, and what tools you will be using to publish content to your SGI 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 SGI server. The INPUT chain is as follows:
Target Interface Source Protocol Port Input eth1: ANY tcp 80 Input eth1: ANY tcp 443 Input eth1: ANY tcp 25 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 SGI 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. SGI strongly recommends that you either apply the same access controls to port 98 as at the application level or else do not allow any source IP addresses here.
You must also consider to whom your system can connect. This is important because it can be used to prevent intruders 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 web server, you should have a very limited number of allowable OUTPUT connections, such as for DNS lookups or remote logging. If in your service architecture the DNS co-master is actually on the public network, you must allow OUTPUT access to it on the public interface eth0 instead of eth1.
On your private interface, you must consider issues such as remote logging (syslog), which allows your SGI 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 SGI 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 |
Following are the questions and recommended answers for this example.
Would you like us to install the ipchains script?
(Y or N): YYou 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 prefer more verbose instructions for each step?
(Y or N): YIf you are unfamiliar with IP filtering, or security issues in general, you will benefit from the verbose mode.
Advanced networking options?
(Y or N): YDNS_SERVERS ["0.0.0.0/0"]:(Press the 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 [""]: 80 443 25
This will allow anyone connecting from the public interface to connect to HTTP, HTTPS, and SENDMAIL ports.
UDP_PUBLIC_SERVICES [""]:
TCP_INTERNAL_SERVICES [""]: 20 21 23 25 80 98 443
This will allow anyone connecting from the private interface to connect to FTP, FTP data, TELNET, SENDMAIL, HTTP, LINUXCONF, 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"]: (Press the space bar to zero out the defaults)
ENABLE_SRC_ADDR_VERIFY ["Y"]: Y
IP_MASQ_NETWORK [""]:
IP_MASQ_MODULES ["ftp raudio vdolive"]: (Press the 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, see:
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 from 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 harm in 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 password 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
tcpdchk(8) 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 ISE 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 addresses 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).
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
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 automatically 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 6, “Enabling HTTP Access for Linuxconf Administration”, for the next steps.