By Seán Boran
This article presents a concise step-by-step approach to securely installing RedHat Linux for use in a firewall DMZ, or other sensitive environment, using Bastille. Linux has progressed rapidly and can be configured to be as secure as, if not better, than commercial UNIX.
The focus in this article is on RedHat 6.2 on SPARC + x86, RedHat7 on x86 and Mandrake 7.0 on x86.
DRAFT: Includes bastille 1.1.1
We welcome your feedback on this article.
Table of Contents:
On x86 hardware, screen, keyboard and mouse are needed. Boot from CDROM or the boot floppy and choose install.
On SPARC hardware, the entire installation can be done without screen or keyboard (also called a "headless server"). Connect the serial console, switch on, halt to the OK prompt by sending a Stop-A (~#, ~%b, or F5 depending on whether you use tip, cu or a vt100 terminal), then start the installation procedure: boot cdrom - install.
The RedHat install is pretty buggy and options differ between releases:
The Mandrake 7.0 install does not suffer from these shortcomings.
So, choose a server or custom install, set hostname, IP parameters, timezone, etc. Don't enable any naming services like NIS or NFS. Choose manual disk partitioning:
- Consider a separate, large /var filesystem for syslog/web/news/proxy servers or firewall filters.
- Servers containing lots of data (web, ftp) should use a separate disk for their data.
- If you don't wish to mount partitions read-only and there are no logs or application data, then consider putting the whole boot disk under root.
- Suggestion for a 2GB disk: 1500MB / (root+usr), 200MB swap, 300MB /var.
- Suggestion for a 1GB disk: 700MB / (root+usr), 100MB swap, 200MB /var.
- Suggestion for a log server with 8GB: 100MB / root, 300MB swap, 800MB /usr, 6.9GB /var.
- See also  for a more detailed discussion of disk partitioning.
Set a strong password (At least 8 chars with numbers, letters and punctuation) for root. Create an additional test user, as you won't be able to login over the network as root.
The "init level" should be set to 3 (command line login), rather than 5 (graphical login). If a GUI is needed, it can always be started manually with startx.
To login via the 'serial port A' on x86 Hardware, which is useful for troubleshooting,
installations and getting to know the command line (it is not necessary for headless
SPARCs which do this automatically). Add the following to /etc/inittab.
con:23:respawn:/sbin/getty ttyS0 VC
To allow root to login via this serial port, add ttyS0 to /etc/securetty,
echo "ttyS0" >> /etc/securetty
Install SSH, the secure Shell for login access (Bastille can do this, but you need Internet access, I had problems with SPARC, and prefer to know exactly what options are used to compile SSH). SSH is already included in some distributions, such as Redhat7.
There are two key implementations for Linux 'ssh1' and 'OpenSSH', here we use ssh1 as an example. OpenSSH is more interesting in some ways, but ssh1 also supports securid (which is useful to me). See also  for a detailed discussion of SSH and it's various implementations.
Either download sources or RPMs (see sites listed under ):
zcat ssh-1.2.30.tar.gz | tar xf -
cd ssh-1.2.30; ./configure --prefix=/usr --without-none --without-rsh --without-idea
make && make install
2) RPMs (SPARC example shown):
rpm -i ssh-1.2.30-7i.sparc.rpm ssh-clients-1.2.27-7i.sparc.rpm
rpm -i ssh-extras-1.2.30-7i.sparc.rpm ssh-server-1.2.27-7i.sparc.rpm
Copy a startup file (example sshd) to /etc/rc.d/init.d/sshd
and setup links, unless it was done as part of the previous step.
chkconfig --add sshd
Configure an appropriate /etc/sshd_config file (see also ), so that access is restricted to named hosts with known public keys (/etc/ssh_known_hosts) and rhosts authentication is disabled. Avoid trusts. Only allow specific users and hosts to access SSH.
Deny daemon accounts access, for example:
DenyUsers daemon bin sync adm lp shutdown halt mail news uucp nobody operator sympa, squid, postgres, gopher, postfix, xfs.
Bastille is set of open source scripts designed to harden a virgin Red Hat 6.0 or 6.1
installation (6.2 support is planned soon). The first release was in December 1999 and
significant progress has been made. V1.1 (released June 2000) was used here. What does
Bastille do? Unneeded daemons are stopped, logging enabled/improved, SUID and file
permissions tightened, account security improved and even a chroot environment is
provided for DNS servers.
Note that Bastille does not run on other Linux variants such as SuSE (which have their own mechanisms and different startup files).
An automated and interactive interface is available. The text based menus provided by the interactive install are very useful for explaining the different options involved and generate a configuration file (tui-generated-raw-config) which is used in the next step by the Bastille back end to do the actual hardening. The configuration file can be edited or copied to other machines to speed up hardening.
ifconfig eth0 down
On SPARC the Interactive script won't work:
Can't load './Curses.so' for module Curses: ./Curses.so: ELF file data encoding not big-endian at /usr/lib/perl5/5.00503/sparc-linux/DynaLoader.pm line 169.
Fix: Download Curses-1.02.tar.gz from CPAN and install:
perl Makefile.PL; make && make install
Then change to the Bastille dir & remove the i386 Curses library:
cd /root/run-Bastille; mv Curses.* /tmp;
And run InteractiveBastille.pl again.
InteractiveBastille.pl runs through hardening setup on a step-by-step basis, asking the
user what should or should not be tightened down. Unneeded daemons are stopped, logging
enabled, SUID and file permissions tightened, account security improved and even a chroot
environment is provided for DNS servers.
Default answers except for the following were used (see tui-generated-raw-config):
Bug: the first time BackEnd fails with the following message:
# ./BackEnd.pl < config > screen.log
/bin/cp: /etc/banners: omitting directory
Run it again and it works fine!
tests# ps -ef
UID PID PPID C STIME TTY TIME CMD
root 1 0 10 17:07 ? 00:00:03 init 
root 2 1 0 17:07 ? 00:00:00 [kflushd]
root 3 1 0 17:07 ? 00:00:00 [kupdate]
root 4 1 0 17:07 ? 00:00:00 [kpiod]
root 5 1 0 17:07 ? 00:00:00 [kswapd]
root 6 1 0 17:08 ? 00:00:00 [mdrecoveryd]
root 276 1 1 17:08 ? 00:00:00 syslogd -m 0 -a /home/dns/dev/lo
root 286 1 0 17:08 ? 00:00:00 klogd
root 301 1 0 17:08 ? 00:00:00 crond
root 310 1 3 17:08 ? 00:00:00 /usr/sbin/sshd
root 369 1 0 17:08 ttyS0 00:00:00 login -- root
root 370 1 0 17:08 tty1 00:00:00 /sbin/mingetty tty1
root 371 1 0 17:08 tty2 00:00:00 /sbin/mingetty tty2
root 372 1 0 17:08 tty3 00:00:00 /sbin/mingetty tty3
root 373 1 0 17:08 tty4 00:00:00 /sbin/mingetty tty4
root 374 1 0 17:08 tty5 00:00:00 /sbin/mingetty tty5
root 375 1 0 17:08 tty6 00:00:00 /sbin/mingetty tty6
root 378 369 1 17:08 ttyS0 00:00:00 -bash
root 390 378 0 17:08 ttyS0 00:00:00 ps -ef
# netstat -a
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address Foreign Address State
tcp 0 0 *:ssh *:* LISTEN
raw 0 0 *:icmp *:* 7
raw 0 0 *:tcp *:* 7
Active UNIX domain sockets (servers and established)
Proto RefCnt Flags Type State I-Node Path
unix 3 [ ] DGRAM 239 /dev/log
unix 0 [ ] STREAM CONNECTED 108 @0000000f
unix 0 [ ] DGRAM 241 /home/dns/dev/log
unix 0 [ ] DGRAM 353
unix 0 [ ] DGRAM 282
unix 0 [ ] DGRAM 254
The Bastille Linux hardening script is a community consensus project: it attempts
to integrate existing "best practices" documents and the shared knowledge of
The Bastille team are to be congratulated on their good work, but a few problems have been noticed. It has been indicated that the following problems should be addressed in future releases, together with support for RH6.2.
At this stage standard tools/utilities are going to be installed. These tools should already have been compiled and tested extensively on another machine. They are typically transferred as tar files, by CD or FTP. Some of the following settings can also be configured via linuxconf.
Patch management is still very basic in Linux, there is no unique numbering, or dedicated tools for automated checking of patch levels (like Solaris for example), and no "patch bundles" to enable you to quickly get you system unto a current level.
Redhat 6.1, patches can be found at www.redhat.com/errata. Security advisories, bug fixes and package updates are on offer. Mandrake updates are at www.linux-mandrake.com/en/fupdates.php3, but Mandrake also offers a nice Patch checking and installation tool under KDE, that is worth trying out.
Only select patches that are relevant to tools/applications actually in use on your system.
Once you have downloaded the relevant patches apply them:
rpm - Uvh filename.rpm
There are also specific kernel patches to add security features such as strong crypto to the kernel, see .
Syslog logging: The additional syslog configuration setup by Bastille is useful, but only on hosts with local logging or loghosts (syslog servers).
Syslog "clients": It is suggested that most hosts log to central loghost, with an /etc/syslog.conf such as the following:
# syslog.conf for clients
# send all messages to "loghost":
# Save boot messages also to boot.log
# Log all logins to /var/log/loginlog
# Log additional data to the Alt-F7 and Alt-F8 screens (TTY 7 and 8)
Give the loghost a whopping great /var disk for logs.
Use the default syslog.conf, with the additions from Bastille.
Set up log pruning as described below.
Root cron entries:
- Cron is much better on Linux that Unix. /etc/crontab contains a list of standard scripts that are run (as root) hourly, daily, weekly and monthly.
- logrotate is called daily and is configured in /etc/logrotate.conf. It is used to prune and archive system and application logs. Applications are supposed to an an appropriate script to /etc/logrotate.d, by default there are entries for syslog, ftp, apache, cron and linuxconf. This is a really nice feature of Linux, much better than commercial Unix.
It is suggested that the following be changed from their defaults in /etc/logrotate.conf for better log control in a production environment:
rotate 30 [keep 30 weeks of logs - make sure you have disk space!]
compress [compress old logs]
And set 'rotate 24' in the /var/log/wtmp and /var/log/lastlog sections, so that records or logins for the last two years are kept.
- Set date once a day with a reliable source using rdate (consider also NTP, it's more accurate, but complex, uses bandwidth and is an additional security worry):
## Synchronise the time:
0,15,30,45 * * * * /usr/bin/rdate timehost1 >/dev/null 2>&1
# process the mail queue hourly during the week:
0 * * * 1-5 /usr/lib/sendmail -q
File permissions: tighten more permissions, and restrict certain tools to root or disable:
chmod u-s /usr/sbin/sendmail #Not for mailgateways or multi-user hosts
chmod 400 /.shosts
chmod 444 /etc/sshd_config /etc/ssh_known_hosts
Document configuration changes in a text file such as /etc/mods, update after each change, with date, author, files affected, description.
cat > /etc/mods <<EOF
19.12.00 sb New install of RH6.1+Bastille & tools according to hardening guidelines
Change login banners to warn users about unauthorised access - you'll need this if you want to prosecute intruders. Edit /etc/issue (for pre-login) and /etc/motd (for post-login). Bastille does not change /etc/issue, one might might want to remove indications about the Operating System type and add a banner (especially when the console is not in a secured room).
Test - Do SSH and the standard tools work? Check log entries, check console messages. Does the system behave as expected?
At this stage, we need to install a file integrity checker that uses secure hashing algorithms, initialise it's database and run regular checks to monitor for changes. If possible keep the master database on another machine or offline or on write-once media. Even if you can't run regular checks, take a master copy and store in on a floppy, it will be a great help in detecting what has changed, should the system be penetrated at a later stage.
What options do we have for integrity checking?
An example using the free Tripwire Version 1.2:
Depending on the function of the server, applications such as ftpd, BIND, proxies, etc. are installed at this point.
Hardening of specific applications like ftp, DNS, Email and also general application tips are discussed in a separate document .
Consider installing a script to check that important daemons are running. Install monitor_processes.pl and add a root cron entry:
## Check that important processes are running during office hours:
## [If you run 7x24, modify accordingly]
0,30 8-19 * * 1-5 /secure/monitor_processes.pl inetd sshd httpd
If data partitions had to be mounted read-write during the application install/testing, consider mounting them read-only now.
Reinitialise tripwire (or equivalent integrity checker).
Backup the system, again to two tapes, one offsite.
Run a network scan on the system, to ensure that only expected services are visible. A commercial tool such as ISS or a free one like Nessus, nmap or Satan should do the job. Print out the results and archive.
If possible, have additional people do the final testing, just in case something was forgotten. Test in detail - What works? What is forbidden? Check console/log entries. Does the system behave as expected? Watch the logs very frequently during the first few days of production.
Test in detail. Check log entries. Does the system behave as expected?
Have applications been tested in detail, by different people with different points of view, from different access points on the network?
The following activities should take place hourly, daily, weekly or monthly, depending on how critical the system is:
This article has been very specific, in the interest of making it practical. However, each security administrator has his own methods and each site has different requirements.
To change security levels, run /etc/security/msec/init.sh X, where X is the security level 0-5. The default is 3. When converting to level 4 and rebooting, the system asked for a runlevel number and on entering '3' it just sat there after an error saying no runlevel files found. All other console ttys were disabled.
chkconfig httpd off
chkconfig apmd off
chkconfig atd off
chkconfig xfs off
chkconfig pcmcia off
chkconfig lpd off
chkconfig nfs off
chkconfig gpm off
chkconfig linuxconf off
chkconfig identd off
chkconfig portmap off
chkconfig sendmail off
chkconfig xinetd off
etc/% saveit vfstab
copying file vfstab ===> /Backup.d/20000707/etc/vfstab
etc/% saveit vfstab
copying file vfstab ===> /Backup.d/20000707/etc/vfstab.13:37
etc/% ls -l /Backup.d/20000707/etc/vfs*
-rw-r--r-- 1 root sys 386 Mar 14 08:31 /Backup.d/20000707/etc/vfstab
-rw-r--r-- 1 root sys 386 Mar 14 08:31 /Backup.d/20000707/etc/vfstab.13:37
./ ../ vfstab
etc/% tail /Backup.d/log-20000707
Backup base directory /Backup.d
Backup requested by root
Date (dd/mm/aaaa) 07-07-2000
Backup base directory /Backup.d
Backup requested by root
Date (dd/mm/aaaa) 07-07-2000
The advantage of this tool are: simplicity and no clogging up the current directory with old versions of files, rcs directories etc. The script can be downloaded .
Linux on Sun SPARC: www.ultralinux.org www.sparclinux.com
|||Mandrake User and Reference Manual (also in /doc on the Mandrake CD)
included with this article: monitor_socket.pl,
monitor_processes.pl, trip_linux.sh, trip_host.sh, logcheck.sh, tui-generated-raw-config, sshd,
Saveit script: Original spanish version: saveit-sp.sh, my tweaked version: saveit (less verbose messages, fix for OpenBSD, english translations, if target exists save with a time postfix).
|||Klaxon and tocsin www.eng.auburn.edu/users/doug/second.html|
Free version V1.2 www.cert.org/ftp/tools/tripwire (last updated in 1994). It was difficult to find rpms, but I eventually found them at www.lj.net/~jht/rpms
Commercial Version www.tripwiresecurity.com (starts at $495.-/server) also runs on NT.
OpenSource Version www.tripwire.org Planned for late 2000, on Linux only.
|||Sample tools for analysing logs:
Logcheck www.psionic.com/abacus/logcheck (see also my improved version of logcheck.sh)
|||All About SSH PartI and Part II, an article written for SecurityPortal by the author.
All about SSH - PartI securityportal.com/direct.cgi?/research/ssh-part1.html,
All about SSH - Part II securityportal.com/direct.cgi?/research/ssh-part2.html
Downloading SSH Sources:
SSH1 sources: ssh-1.2.30.tar.gz from ftp.cs.hut.fi/pub/ssh
OpenSSH sources: www.OpenSSH.com
Downloading rpm binaries:
SSH1 for RH SPARC ftp.zedz.net/pub/crypto/linux/redhat/sparc
OpenSSH and SSH1 for RH x86: ftp.zedz.net/pub/crypto/linux/redhat/i386
OpenSSH for Mandrake x86: ftp.zedz.net/pub/crypto/linux/mandrake/7.0
|||AIDE, a GPL file integrity checker. www.cs.tut.fi/~rammer/aide.html|
Security Knowledge Base
|||New reports on Bastille or Linux Hardening since April'00:
- Bastille Walkthrough, by Jay Beale [STALE LINKS]
- Building a Secure Gateway System, By Chris Stoddard
- Shredding Access in the Name of Security: Set UID Audits, by Jay Beale [STALE LINKS]
- Why Do I Have to Tighten Security on My System?, by Jay Beale [STALE LINKS]
- How Do I Tighten Security on My System?, by Jay Beale [STALE LINKS]
|||Patching RedHat, tools: rh-errata|
syslog-ng www.balabit.hu/products/syslog-ng (tcp connections, content filtering, encryption, authentication)
secure syslog www.core-sdi.com/english/slogging/ssyslog.html
Nsyslogd coombs.anu.edu.au/~avalon/nsyslog.html (tcp connections & SSL)
|||Security Advisories: www.cert.org,
CERT provide several useful firewall/hardening/intrusion detection papers online www.cert.org/tech_tips.
|||Security Newsletters: SecurityPortal, SecurityFocus, SANS.|
25.Apr.'00 Improve tripwire, ssh, references, Mandrake.
Spelling. Feedback from Kurt+Jay.
29.Apr.'00 Initial Publication
28.Jun.'00 Add links to new reports , Correct links and snort.
09.Aug.'00 New: saveit, Update: Bastille 1.1, Links.
19.Dec.'00 Update for RH7
Last Update: 11 December, 2001
Seán Boran is an IT security consultant based in Switzerland and the author of the online IT Security Cookbook.
|© Copyright 2001, Sean.Boran, All Rights Reserved|
By default after 20 reboot, the filesystems are checked (fsck). If you have several filesystems, it's better to stagger the checking so that all filesystems are not checked at the same time, avoiding a slow "21 reboot".
Each filesystem has a mount count which can be interrogated as
dumpe2fs /dev/hda1 | grep 'Mount count'
Set this to a staggered number between 1 and 19, for example:
tunefs -C 6 /dev/hda1
tunefs -C 12 /dev/hda4
tunefs -C 18 /dev/hda7
Warning: umount filesystems before running tunefs.
The number of reboots between check can also be changed:
tunefs -c 10 [check every 10 reboots]
tunefs -i 5 [check every 5 days]