Bastile Hardening Tool Guide

DON'T post new tutorials here! Please use the "Pending Submissions" board so the staff can review them first.
Post Reply
User avatar
uid0
Fame ! Where are the chicks?!
Fame ! Where are the chicks?!
Posts: 106
Joined: 08 Jun 2008, 16:00
15
Contact:

Bastile Hardening Tool Guide

Post by uid0 »

This is other guide I made, more than a guide is an article with descriptions of the options it tries to modify from your systems, I made it because although I don't use it much, I always forget what those options try to do even while reading the default descriptions in the tool.

Hope you find it useful, at least to know what you could change in your system to make it a little more secure, if not, feel free to discard it, flame it or delete it ;)

Contents

1. Introduction
2. What's Bastille
3. Bastille flags
4. Hardening Walk-through
5. Conclusion



Introduction

Security is a most, we all know that, or do we? There are a lot of systems that are not secured in any way all over the net, we know this because we read security reports updated daily, and you know this because there's a chance that you've been owned/rooted/pwnd once or more times ^^ so every effort you take to make your system secure can help you to avoid loosing all your hair, but we know, securing a system can take a lot time and if you're the lazy-type admin will take longer, but fear not, others might to help you, even more, others might try to educate you :)

This is an article that offers you information about one easy way to apply harder security to your Linux system. It's important to say that by reading this article is assumed that you have a basic-intermediate knowledge about how Linux works, however, I try to made the article as easy to follow as I could for the beginners (given the fact I'm a beginner too) :)

From now on, I'll be referring to "hardening" as the process to implementing rules to activate or deactivate a feature in order to make your system's security more stronger.

At must note before you go crazy changing things, Bastille, as any other automatic tool to do things, can do a lot of good but also a lot of damage if used improperly, so, read carefully, contrast what you see here with other sources, and more importantly, test it in a non-production system, something that you can screw up without lose your job or important files.


What's Bastille?

This is a tool, or more appropriate, a set of scripts that helps you (yes lazy admin, I'm talking to you!) to set a stronger security on a system. Bastille can be used over most common Linux distributions, HP-UX and Mac OSX, however, this article is just based over Linux, so understand that not all the settings posted here are equal in different systems.

Bastille works by showing a set of questions, all regarding to a feature that could be secured by using one of the automated scripts that Bastille is based on. What I like of Bastille is that not only is easy to follow and have pretty good things to enforce security but it's designed to educate the user by offering explanations (although sometimes not so useful explanations), and the security implications, on every setting that will be changed.

To this point you might be a little interested but keep wondering what if the settings fails or what if you don't feel good about the changes you've made? If you're asking this questions then you will most that pleased to know that Bastille does come with a very good "undo changes" feature, so, if you are not happy with the changes you can run ReverseBastille

Bastille also offers you a way to secure more than one system based in just one configuration file that can be called using the -i flag.

On the downside, Bastille isn't capable of securing "all" your system, by this I mean that although Bastille can take care over different services, there are others that you'll have to secure by your self, so, Bastille's work is to help you to secure "Linux" but not to secure your MySQL server or your PureFTPD Server, that's your work!


Bastille's Flags

You should see the options and arguments that can be used with Bastille by issuing Bastille -h, but since I know you're lazy I will post them here :)

Code: Select all

root@root [~]# Bastille -h
Usage: Bastille [ [ -h | -b [--<os version> ] | -c | -r | -x | -a [--<os version>] | -l ] -i <alternate config> ] 
         -b : use a saved config file to apply changes 
              directly to system 
         -c : use the Curses (non-X11) GUI
         -h : this help
         -i : input alternate configuration file
         -r : revert Bastille changes to original file versions (pre-Bastille)
         -l : list the standard config file(s) (if any) that matches the last
              run config
         --os version : ask all questions for the given operating system 
              version.  e.g. --os HP-UX11.11
         -x : use the Perl/Tk (X11) GUI
         --assess / -a : run Bastille in assessment mode, generating a report and displaying it in a browser
         --assessnobrowser : run Bastille in assessment mode, generating a report with no browser
The flags are self explanatory, however I'll explain the --assess flag. Basically, it will launch a browser with a report, in this report you'll see a set of questions that are intended to let you know what security rules you should think about in order to make your system more secure. The explanations of every question isn't the best but will help you more than nothing ;)


Hardening Walk-through

In this part I cover the questions you'll be asked while running Bastille and the security goal of each, although you'll find explanations of every change you're about to make, I hope this will gives you a better idea about what to expect of the tool.

Doesn't matter if you use Bastille with the curses based interface or TK's, the questions will be the same on a Linux system.

Bastille is divided by sections, questions and answers, the answers are of tree types: Yes, No and user input, at the moment you want to return to a previous questions just click the Back button or press Esc. For easy to read purpose, I'll be using this format:

Section: FilePermissions
Feature: Ping Usage
Question: Something
Explanation: Something
Recommended Answer: Yes|No|User Input

Let's get start:

To understand the first set of questions you need to understand what's SUID. Is a bit that gives to "common users" the permit to access a the file or a feature that should be run by root. This bit exists for convenience but it can be for obvious reasons a security problem.

Section: FilePermissions
Feature: SUID Mount/Unmount
Question: Would you like to disable SUID status for Mount/Unmount?
Explanation: If SUID is set, normal users can mount and unmount devices (such as flash drives, cdroms and so on). In desktop systems when "you" are the only one that have access to such system then you can use this bit. Even when if you don't set it you still mount things by changing to root using su, but if so, if KDE try to mount some usb drive, will ask you for root's password which, if you're the only user, isn't necessary.
Recommended Answers: If you're the only one with access to the system then Answer No, but if the system is used by several people then answer Yes.

Section: FilePermissions
Feature: Ping Usage
Question: Would you like to disable SUID status for Ping?
Explanation: By default, the SUID bit is set to ping so only root can use this tool and you should leave it that way.
Recommended Answer: If you're the only one with access to the system then you can safely remove the SUID of Ping by answering No to this one.

Section: FilePermissions
Feature: BSD r-tools
Question: Would you like to disable the r-tools?
Explanation: The BSD r-tools are things like rsh, rlogin, rdist and such. The problem with this tools is that everything is passed in clear text, that means that if someone is sniffing the LAN where you're at in the same time you're using rlogin to connect to some remote system, then that "someone" can be able to read the traffic you're sending, thus, gaining your user and password details to connect to the remote system.
Recommended Answer: For obvious reasons the answer should be "No", don't worry about loosing this tools since there are others that you can implement more secure than this ones.

Section: AccountSecurity
Feature: BSD r-tools
Question: Should Bastille disable clear-text r-protocols that use IP-based authentication?
Explanation: The difference of this one with the later is that this question is referred to r-tool's services that can be using to access, remotely, to your system (i.e: using rlogin to access to your system from other machine).
Recomended Answer: Again, everything send using r-tools are in clear text so the answer to this one should be "No" as the other.

Section: AccountSecurity
Feature: Password Aging.
Question: Would you like to enforce password aging?
Explanation: The idea with this feature is to change the default time that a password should be used before the system prompts the user to change it. By default, this is set as 99.999 days so a user can use a password that amount of time without having to change it, however, in large environment or systems where security is a most, admins set a lower value forcing the password to be changed frequently which is a good approach. Bastille will set the time to 60 days but you can change that by editing the file /etc/login.defs
Recommended Answer: It depends on the system you're working at, if it's a system that has many users that come and goes then it's good to answer "Yes" in here, that way you can reduce the compromising passwords.

Section: AccountSecurity
Feature: TTY's access.
Question: Should we disallow root login on tty's 1-6?
Explanation: This setting (if answered Yes) will disallow the root login at any tty (virtual terminals), by doing this, to use the root account you'll have to login first as regular user in any tty and then issue the su command. For many users this could be a pain actually but it isn't a bad idea at all since if root's password is compromised, the person who know that password won't be able to login directly as root, he'll have to know the password of a normal user account too.
Recommended Answer: "Yes" :)

Section: BootSecurity
Feature: Grub's Password.
Question: Would you like to password-protect the grub prompt?
Explanation: By enabling this, you'll have to enter a password in order to grub can be loaded and used. This is a way to prevent people who might have "physical" access to the system to gain root access by using the grub (i.e: setting the flag "Single" to the kernel line end to boot directly as root ;))
Recommended Answer: This setting might gives you lot of troubles if you have a multiboot system, if so, you should follow Bastille's advice and answer "No" to this one, however, if you don't have multiboot systems then you can safely can answer Yes to this.

Section: BootSecurity
Feature: Ctrl+Alt+Del reboot.
Question: Would you like to disable CTRL-ALT-DELETE rebooting?
Explanation: A system can be rebooted by using ctrl+alt+del, this will send a kill signal to gracefully end services, clean tmp and then reboot. Someone then though that by disabling this an attacker couldn't reboot the system but he can by shutting the computer's power supply, then, since a hard reboot could actually damage your system (because things aren't killed "gracefully"), is better to let the attacker to reboot the system by using ctrl+alt+del :P
Recommended Answer: Based on the fact that even disabling this the system can be reboot is better to answer "No" to this ;)

Section: Inetd
Feature: TCP Wrappers and xinetd
Question: Would you like to set a default-deny on TCP Wrappers and xinetd?
Explanation: inetd and its follower xinetd are called superservers, this can be on control of other services like ssh, ftp, email and the like, the idea behind this superservers is first to have a control center for other servers and second to execute those servers under the permissions of inetd and xinetd. What this question does is to set a rule that will deny external access to all the servers running under inetd or xinetd, by external access I mean anything that it is not localhost.
Recommended Answer: This one I'll leave it to you, you could answer "Yes" here and then make changes to the server files under /etc/inetd.d or /etc/xinetd.d in order to allow access to the servers your system might use (i.e: if you have a ftp server and such), answering yes will be good because with all denied you only have to worry by allowing access to really needed servers, thus avoiding security breaks by forgetting to deny access to some service.

Section: Inetd
Feature: Telnet
Question: Should Bastille ensure the telnet service does not run on this system?
Explanation: Telnet is old and insecure by default, every piece of traffic going under telnet will be in clear text, although even today telnet might have some use (think of smpt spoofing), this particular question is related to "telnet as a service", meaning that we're talking about allowing that someone from another machine could use telnet to access your system.
Recommended Answer: Obviously the answer here is "Yes". For those that are concerned, this won't disable your telnet clients.

Section: Inetd
Feature: FTP
Question: Should Bastille ensure inetd's FTP service does not run on this system?
Explanation: FTP is similar to telnet in the way that it's insecure by default, everything send or received using ftp goes through the network in clear text, if you are in the need to have an active ftp server, then you should try with a better solution like sftp.
Recommended Answer: You should answer "Yes" in here and use a better solution than the old FTP, however it's up to you the final decision of this answer.

Section: Inetd
Feature: Authorized Use message
Question: Would you lite to display "Authorized Use" messages at login time?
Explanation: What this feature does is to edite the /etc/issue file and configure /etc/login.defs to call /etc/issue before every login showing a message to let users trying to connect what kind of system their are trying to access. Bastille will create a very standard message, you should change the contents of the /etc/issue file in order to adapt it better to your system specification.
Recommended Answer: Answer what you want with this, it's said that this could help you if some day you're prosecuting some attacker.

Section: Inetd
Feature: Authorized Permit
Question: Who is responsible for granting authorization to use this machine?
Explanation: The answer you place here will be added to the later message to show users who they may contact in order to obtain permit to access to the system.
Recommended Answer: This answer is "input type based", meaning that you can type whatever you want (i.e: System Admin: uid0@something.com)

Section: ConfigureMiscPAM
Feature: System usage resource limits
Question: Would you like to put limits on system resource usage?
Explanation: PAM is a module that let's you to define rules over specifics services or features to grant or deny access. In this case, this setting could help you to reduce DoS attacks, won't stop them (use a firewall to that), it just can reduce them by adding rules like the amount of process an user can run at anytime. (Remember that under unix environments, every server runs under a virtual user account)
Recommended Answer: In short, answer "Yes" to this question, but don't relay "only" on it to avoid DoS attacks.

Section: ConfigureMiscPAM
Feature: Users accounts console access
Question: Should we restrict console access to a small group of user accounts?
Explanation: Is common that users that have login access over a console have some privileges at the same time (like binary file access), this setting however what offers is a way to allow console logins only to those accounts you trust.
Recommended Answer: You should answer "Yes" to this.

If you answered "Yes" to the previous questions, then you'll be presented with the following question:

Section: ConfigureMiscPAM
Feature: Accounts settings
Question: Which accounts should be able to login at console?
Explanation: Here you'll be able to type the account names (remember, the ones you trust) to give those accounts login access.
Recommended Answer: This answer is "input type based", just write the account names you trust, by default, only root will be granted, but you can add more of course, just set a space between the account's names (i.e: root user1 user2).

Section: Logging
Feature: Additional Logging.
Question: Would you like to add additional logging?
Explanation: This setting (if answered Yes) will give you the possibility to log on a remote system, also, will configure tty7 and tty8 to show those logs.
Recommended Answer: Logging is useful to know what might happen with the things that you "don't see" so you could answer Yes to this one.

Section: Logging
Feature: Remote Logging.
Question: Do you have a remote Logging host?
Explanation: Here you'll set the IP address of the remote system where logs should be placed.
Recommended Answer: This answer is "input based", here you'll need to type the IP address of the server to hold the logs.

Section: Logging
Feature: Process accounting
Question: Would you like to set up process accounting?
Explanation: This will enable the logs daemon to hold information about what process was executed, when and by who.
Recommended Answer: This kind of information is useful, mostly after a problem happen, however this will make your system's processor to work a lot so I leave the answer to you.

Section: MiscellaneousDaemons
Feature: GPM
Question: Would you like to disable GPM?
Explanation: GPM is a service that lets you use the mouse on text based consoles (use a mouse without using the X server).
Recommended Answer: Frankly I don't know why this question is asked at all, I don't personally see a security problem with this one as long as you have it answering only to localhost, anyway, if you like to use the mouse over the console then answer "No" to this.

Section: Sendmail
Feature: Daemon mode
Question: Do you want to stop sendmail from running in daemon mode?
Explanation: Daemon mode means that this service will be always listening in order to process emails (be it by sending them or by receiving them). If you don't have a mail server, then you don't need this service to be running in daemon mode, you could actually configure it to let cron or such to execute it every few minutes to process mail queue or let Bastille to configure it for you.
Recommended Answer: If you have a mail server then answer "No" to this and find more resources on how to protect it.

Section: Apache
Feature: Apache web server
Question: Would you like to deactivate the Apache web server?
Explanation: This setting is self explanatory, answering Yes will deactivate the apache web server, in case you need it you'll have to enable it manually (just run it using chkconfig or some init.d script)
Recommended Answer: Only answer "No" to this one if you use this server (even locally).

Section: Apache
Feature: Bind Apache
Question: Would you like to bind the Web server to listen only to the localhost?
Explanation: "Bind" is a way to create a link between a service and a specific IP address or domain, this setting will bind the apache web server to the localhost (127.0.0.1 addr) so the web server will only listen and process request coming from the localhost.
Recommended Answer: This setting is good if you'll only use the server locally, for instance, if you use it to develop and have a public server in other system. Answer according to your needs.

Section: Firewall
Feature: Packet filtering script
Question: Would you like to run the packet filtering script?
Explanation: If you answer Yes to this one, you'll be asked several things in order to define a set of rules that should be interpreted by ipchains or iptables (like ip masquerade, pre-routing, post-routing and so on...). Bastille have only support to make scripts compatible with 2.2 and 2.4 kernels, so if you use a 2.6 kernel you might have to change or add specific settings after Bastille create the script.
Recommended Answer: Answer this according to your needs, I personally don't use it since I prefer to build the script myself or use other tools like shorewall.

And we're done!

After this, you'll be prompted with a message that will ask you to confirm your changes, to this point, none of the changes have been applied so you can either exit without saving, go back and change the configuration or confirm that you're done.

After confirming, you'll be asked to save the changes, this will create a file in /var/log/Bastille called "last.config". This file could be used to apply the same configurations to other machines with the same system and then called like:

Code: Select all

root@root [~]# bastille -i last.config
Still at this point, even when you save the configuration no changes have been made so you'll see a final message to ask you if you want the changes to be applied.

Remember that if you applied the changes and aren't happy with the result you could revert everything by using:

Code: Select all

root@root [~]# RevertBastille


Conclusion

If you have reached until this point then I have to thank you for spend the time to read this, I hope you enjoyed. Feel free to check the main site of Bastille at: http://bastille-linux.sourceforge.net/index.html

As a final note, if you're looking for more in depth security then you could read about projects that use hardening at kernel level like GRSecurity (http://www.grsecurity.net/) or look if your distribution have a hardened version which commonly include kernel patches, also, you might want to check projects like Engarde Linux (http://www.engardelinux.org/), AppArmor (http://www.novell.com/linux/security/apparmor/) and OpenBSD(http://www.openbsd.org/)

Post Reply