hardening hardening-tutorial-en.xml, NONE, 1.1 Makefile, 1.1, 1.2 fedora-hardening-guide-en.xml, 1.1, NONE
Author: kwade
Update of /cvs/docs/hardening In directory cvs-int.fedora.redhat.com:/tmp/cvs-serv4454
Modified Files: Makefile Added Files: hardening-tutorial-en.xml Removed Files: fedora-hardening-guide-en.xml Log Message: Updating to use new Makefile, renamed file and tutorial to match scope of document and FDP, other standardization changes.
--- NEW FILE hardening-tutorial-en.xml --- <!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd" [
<!ENTITY % FEDORA-ENTITIES-EN SYSTEM "../docs-common/common/fedora-entities-en.ent"> %FEDORA-ENTITIES-EN;
<!ENTITY BOOKID "hardening-tutorial-en-0.2 (2005-04-26)"> <!-- change version --> <!-- of manual and date here -->
<!ENTITY BUG-NUM "129957"> <!ENTITY FCLOCALVER "3"> <!ENTITY DRAFTNOTICE SYSTEM "../docs-common/common/draftnotice-en.xml"> <!ENTITY LEGALNOTICE SYSTEM "../docs-common/common/legalnotice-en.xml"> ]>
<book id="hardening-tutorial" lang="en"> <bookinfo> <title>&FC; &FCLOCALVER; Hardening Tutorial</title> <copyright> <year>2005</year> <holder>&FORMAL-RHI;</holder> <holder>Charles Heselton</holder> </copyright> <authorgroup> <author> <surname>Heselton</surname> <firstname>Charles</firstname> </author> </authorgroup> &LEGALNOTICE; </bookinfo>
<preface id="ch-intro"> <title>Introduction</title>
&DRAFTNOTICE; <para> This tutorial is a basic walk-through of how to harden a basic install of &FC;. Many of the actions and principles discussed here will apply to many different linux distributions. However, for the purpose of this tutorial we will be regarding &FC;, specifically. </para> <sect1 id="intro-scope"> <title>Document Scope</title> <para> While describing the techniques and tools used in this tutorial, it is the goal of the author to present both the Graphical User Interface (GUI) tools, and the more traditional command line (CLI) tools that are available in FC3. </para>
<para> Many users will have customized the appearance of their desktop (if running one), panels, menus, etc. This guide makes direction based on the default install and configuration of &FC;. The locations of items, menus, commands, etc. may differ from your actual experience. </para> </sect1>
<sect1 id="intro-audience"> <title>Intended Audience</title> <para> This document is intended for use by all &FC; users. However, there is a focus for home or small-business users. Enterprise deployments of Fedora will want to make some different considerations such as centralized syslog storage, unified (central) user authentication, etc. Most of the principles discussed will apply, however there are some enterprise applications which are outside the scope of this document. </para> </sect1> </preface>
<chapter id="ch-chapter1">
<title>Initial Steps</title>
&DRAFTNOTICE;
<sect1 id="pkg-considerations"> <title>Package Installation Considerations</title>
<para> This section will not go into the actual process of installing packages, that falls under the scope of the Installation Guide. However, there are some important things to consider, in regards to security, when you are installing &FC; and selecting your packages for installation, and when you are installing new packages on an already built system. </para>
<sect2 id="pkg-considerations-install"> <title>Package Selections During Install</title>
<para> When you are first installing your &FC; system, take careful consideration of the packages that you are installing. Know what type of system you are building before you build it. Fedora offers a "system role" method of choosing packages, which can be customized to remove or not install certain packages, and install others that may not be designated as part of that particular role. A good approach would be to, first, draw out a plan of what your system is to be used for, and what services you will want to offer (if any). You can then make an educated decision about what installation type you want to start with. Fedora offers the following in terms of installation types: </para> <para> <itemizedlist> <listitem><para>Personal Desktop</para></listitem> <listitem><para>Workstation</para></listitem> <listitem><para>Server</para></listitem> <listitem><para>Custom</para></listitem> </itemizedlist> </para>
<para>You can then check the "Select specific packages" to modify your installation, or use the <application>Add and Remove Progams</application> GUI utility, or the <application>yum</application> command line utility, to install any additional packages required for your needs. </para> </sect2>
<sect2 id="pkg-considerations-update"> <title>Package Considerations for Installation of New Software</title>
<para> If you are updating, or adding to, a system that is already installed with &FC;, then there are some other considerations that need to be made. </para>
<para> When installing a new package, you should check the integrity of the package. Most reliable sources will provide a signed checksum file for a package file. You can use <application>gpg</application> or <application>md5sum</application> to verify the checksum provided, depending on the digital signature provided. <command>gpg</command> is a utility which allows you to manage digital signatures. These signatures allow you to digitally sign or encrypt data (including text messages or files). For more details on <command>gpg</command> visit the GNU gpg website at <ulink url="http://www.gnupg.org">http://www.gnupg.org</ulink>. <command>md5sum</command> is a utility which is based off of the MD5 algorithm. This utility can be used to create a digital signature of a file, which can then be compared to the MD5 checksum downloaded with the software package. For more details on the MD5 hashing algorithm, and associated utilities, you can visit the MD5 website at <ulink url="http://www.fourmilab.ch/md5/">http://www.fourmilab.ch/md5/</ulink>. </para> <para> The actual source of the package must come into consideration as well. If you are downloading new packages from fedora.redhat.com, the package and checksum should be fairly trustworthy. However, if you are downloading the package from www.myanonymoussoftwaresite.com, you may want to try to find another source for the package, or further verify the integrity of the site. You can find a brief description of how to verify a downloaded file with the provided checksum in the following two sections. </para> <sect3 id="s3-intro-gpg-example"> <title><command>gpg</command> usage example</title>
<para> Verifying a file with <command>gpg</command> is a method of verifying a file's integrity with a digital signature. In porder for this to work, you must have the signer's public key, or digital signature, on your local keyring. If you are totally lost at this point, you should go back and read the documentation on the GNUpg site, linked above. For this example, we're going to download and test a kernel image from ftp://ftp.kernel.org. As just stated, we need to get the key for the Linux Kernel Archives. However, first we need to make sure that our gpg comfiguration is complete. </para>
<para> Start by issuing the following command to see if our home configuration directory exists or not. (If you have never used gpg, this directory will <emphasis>not</emphasis> exist.) </para>
<screen><userinput>ls -d ~/.gnupg</userinput></screen>
<para> If your directory exists, you will see something along the lines of the following: </para>
<screen><computeroutput>/home/charlie/.gnupg</computeroutput></screen>
<para> Of course, unless your username happens to be "charlie", this part of the path will be something different. If your directory does <emphasis>not</emphasis> exist, then you will see something like this: </para>
<screen><computeroutput>ls: /home/charlie/.gnupg: No such file or directory</computeroutput></screen>
<para> ... and you will need to create that directory ... </para>
<screen><userinput>mkdir ~/.gnupg</userinput></screen>
<para> Next, you will need to create your own keys, which will also initialize your gpg public and private keyrings. </para>
<screen><userinput>gpg --gen-key</userinput></screen>
<para>You will be prompted with the following:</para>
<screen><computeroutput>gpg (GnuPG) 1.2.6; Copyright (C) 2004 Free Software Foundation, Inc. This program comes with ABSOLUTELY NO WARRANTY. This is free software, and you are welcome to redistribute it under certain conditions. See the file COPYING for details.
Please select what kind of key you want: (1) DSA and ElGamal (default) (2) DSA (sign only) (4) RSA (sign only) Your selection? </computeroutput></screen>
<para> Option one (1) is the option you should choose if you ever might want to encrypt anything. The other two options only allow you to sign. After you make your selection, you will be asked a series of questions about yourself (name, email, etc.), and you will be asked for a passphrase. Once the key has been created, you will be prompted with your new gpg fingerprint: </para>
<screen><computeroutput>public and secret key created and signed. key marked as ultimately trusted.
pub 1024D/834AA506 2005-04-08 Bogus (Bogus key) <bogus@foo.com> Key fingerprint = 8F0F CDA0 1682 58B2 F38D 31AF CD8A 6FD5 834A A506 sub 1024g/0F43BE0D 2005-04-08</computeroutput></screen>
<para> If you have never used <command>gpg</command> before, you may also receive messages regarding the creation of your public and private keyrings. Now that you have your keyrings in place, you need to add the Linux Kernel Archive public key to your key ring. This process is described in detail at the following URL: </para>
<para><ulink url="http://www.kernel.org/signature.html">http://www.kernel.org/signature.html</ulink></para>
<para> However, the process is summarized in one simple step for you below: </para>
<screen><userinput>gpg --keyserver wwwkeys.pgp.net --recv-keys 0x517D0F0E</userinput></screen>
<para> When you downloaded the kernel file, you should have also downloaded a <filename>linux-2.x.x.x.tar.gz.sign</filename> file. This file contains the signature of the file you downloaded that was created with the Archive public key. In order to get that warm and fuzzy when we verify the file. We will also want to sign the key we just downloaded. </para>
<screen><userinput> gpg --lsign-key 517D0F0E</userinput><computeroutput> pub 1024D/517D0F0E created: 2000-10-10 expires: never trust: -/- sub 4096g/E50A8F2A created: 2000-10-10 expires: never (1). Linux Kernel Archives Verification Key <ftpadmin@kernel.org>
pub 1024D/517D0F0E created: 2000-10-10 expires: never trust: -/- Primary key fingerprint: C75D C40A 11D7 AF88 9981 ED5B C86B A06A 517D 0F0E
Linux Kernel Archives Verification Key <ftpadmin@kernel.org>
How carefully have you verified the key you are about to sign actually belongs to the person named above? If you don't know what to answer, enter "0".
(0) I will not answer. (default) (1) I have not checked at all. (2) I have done casual checking. (3) I have done very careful checking.
Your selection? (enter '?' for more information): </computeroutput><userinput>2</userinput><computeroutput> Are you really sure that you want to sign this key with your key: "Tuxxer (Tuxxer) <tuxxer@cox.net>" (F1E11EA1)
I have checked this key casually.
Really sign? </computeroutput><userinput>y</userinput></screen>
<para> Option two (2) in the dialog described above is a good selection if you are somewhat familiar with the person or group owning the key. Now on to the downloading and verifying. The download process is outlined below: </para>
<screen><userinput> ftp ftp.kernel.org</userinput><computeroutput> Connected to ftp.kernel.org (204.152.191.37). 220 Welcome to ftp.kernel.org. Name (ftp.kernel.org:charlie): anonymous 331 Please specify the password. Password: 230- Welcome to the 230- LINUX KERNEL ARCHIVES 230- ftp.kernel.org 230-
< ... snip kernel.org banner stuff ... >
230 Login successful. Remote system type is UNIX. Using binary mode to transfer files. ftp> </computeroutput><userinput>cd /pub/linux/kernel/v2.6</userinput><computeroutput> 250 Directory successfully changed. ftp></computeroutput><userinput>ls linux-2.6.11*</userinput><computeroutput> 227 Entering Passive Mode (204,152,191,37,71,78) 150 Here comes the directory listing.
< ... snip older versions listing ... >
-rw-r--r-- 1 536 536 37099602 Apr 07 19:21 linux-2.6.11.7.tar.bz2 -rw-r--r-- 1 536 536 248 Apr 07 19:21 linux-2.6.11.7.tar.bz2.sign -rw-r--r-- 1 536 536 46585077 Apr 07 19:21 linux-2.6.11.7.tar.gz -rw-r--r-- 1 536 536 248 Apr 07 19:21 linux-2.6.11.7.tar.gz.sign -rw-r--r-- 1 536 536 248 Apr 07 19:21 linux-2.6.11.7.tar.sign 226 Directory send OK. ftp> </computeroutput><userinput>prompt</userinput><computeroutput> Interactive mode off.</computeroutput></screen>
<para>At the time of this writing, the 2.6.11.7 kernel was the most recent. There may be a more recent version when you read this document. </para>
<screen><computeroutput>ftp> </computeroutput><userinput>mget linux-2.6.11.7.tar.gz linux-2.6.11.7.tar.gz.sign</userinput> <computeroutput>local: linux-2.6.11.7.tar.gz remote: linux-2.6.11.7.tar.gz 227 Entering Passive Mode (204,152,191,37,170,43) 150 Opening BINARY mode data connection for linux-2.6.11.7.tar.gz (46585077 bytes). 226 File send OK. 46585077 bytes received in 89.7 secs (5.1e+02 Kbytes/sec) local: linux-2.6.11.7.tar.gz.sign remote: linux-2.6.11.7.tar.gz.sign 227 Entering Passive Mode (204,152,191,37,84,119) 150 Opening BINARY mode data connection for linux-2.6.11.7.tar.gz.sign (248 bytes). 226 File send OK. 248 bytes received in 0.00102 secs (2.4e+02 Kbytes/sec) ftp> </computeroutput><userinput>bye</userinput><computeroutput> 221 Goodbye.</computeroutput></screen>
<para> Now that we have all that <command>ftp</command> stuff out of the way, we can verify the file that has just been downloaded. Since you have already gone through the trouble of creating your keyring, and signing the Linux Kernel Archive's key, this is a easy as the single command below. </para>
<screen><userinput>gpg --verify linux-2.6.11.7.tar.gz.sign linux-2.6.11.7.tar.gz</userinput> <computeroutput>gpg: Signature made Thu 07 Apr 2005 12:30:06 PM PDT using DSA key ID 517D0F0E gpg: Good signature from "Linux Kernel Archives Verification Key <ftpadmin@kernel.org>" gpg: checking the trustdb gpg: checking at depth 0 signed=7 ot(-/q/n/m/f/u)=0/0/0/0/0/2 gpg: checking at depth 1 signed=16 ot(-/q/n/m/f/u)=7/0/0/0/0/0 gpg: next trustdb check due at 2005-09-29</computeroutput></screen>
<para> The line "gpg: Good signature from ... " indicates that the signatures is valid, and the file is verified. </para> </sect3> <sect3 id="s3-intro-md5sum-example"> <title><command>md5sum</command> usage example</title> <para> The <command>md5sum</command> command is used to get an MD5 checksum from a file, or line/section of text, which can then be compared to a supplied checksum to verify the integrity of the file you are downloading. </para>
<para> Start by downloading the file. For this example, we are using the first disk image of the Fedora Core 3 install. </para>
<screen><userinput>ftp download.fedora.redhat.com</userinput></screen> <screen><computeroutput>Trying 66.187.224.20... Connected to download.fedora.redhat.com (66.187.224.20). 220 Fedora FTP server ready. All transfers are logged. Name (download.fedora.redhat.com:charlie): </computeroutput><userinput>anonymous</userinput><computeroutput> 331 Please specify the password. Password: 230 Login successful. Remote system type is UNIX. Using binary mode to transfer files. ftp></computeroutput><userinput> cd /pub/fedora/linux/core/3/i386/iso/</userinput><computeroutput> 250 Directory successfully changed. ftp> </computeroutput><userinput>ls</userinput><computeroutput> 227 Entering Passive Mode (66,187,224,20,49,191) 150 Here comes the directory listing. -rw-r--r-- 1 ftp ftp 2466410496 Nov 03 22:18 FC3-i386-DVD.iso -rw-r--r-- 1 ftp ftp 589832192 Nov 03 22:11 FC3-i386-SRPMS-disc1.iso -rw-r--r-- 1 ftp ftp 589844480 Nov 03 22:12 FC3-i386-SRPMS-disc2.iso -rw-r--r-- 1 ftp ftp 589815808 Nov 03 22:13 FC3-i386-SRPMS-disc3.iso -rw-r--r-- 1 ftp ftp 589817856 Nov 03 22:15 FC3-i386-SRPMS-disc4.iso -rw-r--r-- 1 ftp ftp 646987776 Nov 03 22:05 FC3-i386-disc1.iso -rw-r--r-- 1 ftp ftp 668520448 Nov 03 22:07 FC3-i386-disc2.iso -rw-r--r-- 1 ftp ftp 667498496 Nov 03 22:08 FC3-i386-disc3.iso -rw-r--r-- 1 ftp ftp 404764672 Nov 03 22:10 FC3-i386-disc4.iso -rw-r--r-- 2 ftp ftp 79908864 Nov 03 21:59 FC3-i386-rescuecd.iso -rw-r--r-- 1 ftp ftp 791 Nov 03 23:00 MD5SUM 226 Directory send OK. ftp> </computeroutput><userinput>get FC3-i386-disc1.iso</userinput><computeroutput> ftp> </computeroutput><userinput>get MD5SUM</userinput></screen>
<para> After you have the file downloaded, verify the checksum by issuing the following command: </para>
<screen><userinput>md5sum FC3-i386-disc1.iso</userinput></screen>
<para>This will output something similar to the following:</para>
<screen><computeroutput>db8c7254beeb4f6b891d1ed3f689b412 FC3-i386-disc1.iso</computeroutput></screen>
<para> You can then <command>grep</command> the <filename>MD5SUM</filename> file you should have downloaded for the correct checksum: </para>
<screen><userinput>grep 'FC3-i386-disc1.iso' MD5SUM</userinput> <computeroutput>db8c7254beeb4f6b891d1ed3f689b412 FC3-i386-disc1.iso</computeroutput></screen> <para> If the hexadecimal number in the first column matches the hexadecimal number output by the <command>md5sum</command> command, then you can be assured that the file you downloaded is an unmodified version of the file that was posted. </para> </sect3> </sect2> </sect1>
<sect1 id="s1-sudo"> <title>Configuring and Using <command>sudo</command></title> <para> Using the <command>sudo</command> utility allows a user to run another command or tool as if they were logged on as root. If you're doing something that requires the access of the root user, this is the best method for elevating your privileges. </para>
<para> The file that <command>sudo</command> uses as its configuration file is <filename>/etc/sudoers</filename>. This file allows you to set up command, host, and user aliases that are allowed through <command>sudo</command>, and which users are allowed to run them, from which host, etc. For more information on the details of the <filename>sudoers</filename> file and how to configure it, take a look at the <command>sudoers</command> man page. </para>
<para> If you add the lines below to the <filename>/etc/sudoers</filename> file, it will allow your user account access to command(s) specified by the 'Cmnd_Alias' when you use the <command>sudo</command> command. You will have to type your password for each command. </para>
<screen><userinput> Cmnd_Alias HARD = "gpg", "md5sum", "sudo", "yum", "rpm", "find", "pkill", "iptables", "umask", "chkconfig", "grep" yourusername ALL = HARD </userinput></screen>
<para> The commands selected for this example <emphasis>should</emphasis> provide all of the appropriate priveleges required by the instructions in this guide. If you would like a more complete configuration for your implementation of <command>sudo</command>, please consult the <command>man</command> page or the online documentation. </para>
<para> For more information on how to configure sudo, you can view the manpage and other documentation at the link below. <itemizedlist> <listitem><para> <ulink url="http://www.courtesan.com/sudo/man/sudo.html">http://www.courtesan.com/sudo/man/sudo.html</ulink> </para></listitem> <listitem><para> <ulink url="http://www.linuxhelp.net/guides/sudo/">http://www.linuxhelp.net/guides/sudo/</ulink> </para> </listitem> </itemizedlist> </para> </sect1>
<sect1 id="sysid-and-role"> <title>Identifying system role and usage</title> &DRAFTNOTICE; <para> As we have already mentioned, one important thing to do initially is to identify what your system will be used for, what services you will need, and how many users will be using your system. Here are some things to consider: </para> <itemizedlist> <listitem> <para>Will you be using your new &FC; system for Internet and email only?</para> </listitem> <listitem> <para>Will you be serving web/email/ftp content?</para> </listitem> <listitem> <para>Will your system act as a firewall for your home or office network which will do Network Address Translation (NAT'ing)?</para> </listitem> </itemizedlist> <para> Once you have considered all of these things in regards to your new &FC; system, you can make intelligent decisions about to secure your system. For the scope of this guide, it is assumed that you will be securing a workstation which will be used for web surfing, email, office documents, and the like. It is also assumed that there will be one primary user for this system. </para> </sect1>
<sect1 id="gui-update"> <title>GUI: Updates with <application>up2date</application></title>
<para> Make sure that you have all of the most current updates. There are many times that a package will be released with a distribution release and then a vulnerability with that version will be posted after the release of the distribution. While there is a lag between notification, and patching, the distribution "owner" will usually release a patch or updated version shortly. This means that if you are installing a system after it's initial release, it may be outdated. </para>
<para> &FC; provides a couple of different ways of accomplishing this. The GUI utility is called <application>up2date</application>. After you've first installed your new &FC; system, it should automatically try to connect to the &RHN; to determine if it's applications are up to date or not. Most likely, they will not be up to date. This is indicated by the red exclamation point icon in the upper right hand corner of the screen, on the <application>Gnome</application> panel. </para>
<para> Clicking on the icon will bring up the <application>&RHN; Alert Notification Tool</application> dialog. This will show you any products that are currently installed on your system that need to be updated. Click the "Launch up2date" button to launch the actual update application. Follow the instructions in the subsequent dialogs to update your system. If your system is up to date, you will receive a notification that indicates this. Otherwise, the <application>up2date</application> program will download the necessary packages and install them for you.</para> </sect1>
<sect1 id="cli-updates"> <title>CLI: Updates with <command>yum</command></title> &DRAFTNOTICE; <para> The most convenient CLI tool that comes with &FC; is <command>yum</command>. Yum will not automatically check to see if your applications and packages are up to date, since the default functionality relies on the GUI tools. It can, however, be configured to do so. By issuing the following command: </para> <screen> <userinput>sudo '/sbin/chkconfig --level 345 yum on; /sbin/service yum start'</userinput> </screen> <para> you will start the service, and configure it to start at runlevels 3, 4, and 5. If you are running a "headless" system, or if you are running in command line only mode, one of the first things that you will want to do will be to run <command>yum</command>. Use the following command to check for any available updates: </para>
<screen> <userinput>sudo 'yum check-update'</userinput> </screen>
<para> This will check for any package updates, and dependencies. Ultimately, this is not a necessary step, but I like to run it to see what updates are available, if any, before actually updating. Then, to install any updates found, you will need to run the following command: </para>
<screen> <userinput>sudo 'yum update'</userinput> </screen>
<para> This will automatically download any pending package or application updates, including kernel updates. Then once all of the updates packages have been downloaded, you will be prompted to continue with the transaction (or installation process). </para>
<para> The first time you run <command>yum</command>, you will be asked to install the gpg key, unless you have already disabled file signature checking in <filename>yum.conf</filename>. The simplest way to do this is to use the key installed when installing the operating system. Issue the following command to accomplish this: </para>
<screen> <userinput>sudo "rpm --import /usr/share/rhn/RPM-GPG-KEY-fedora"</userinput> </screen>
<para> Once you have the key installed, you will be able to verify the packages you download and install by using <command>yum</command>. </para>
<note> <title>Note</title> <para>If there are any unresolved dependencies, you will be asked if you want to download and install the dependencies. Most of the time, you should do this. </para> </note>
<tip> <title>Tip</title> <para> If you have received any critical updates, like a kernel update, you will want to reboot your system after the update is complete. </para> </tip>
<para> You can find more information on keeping your system up to date at following link: </para> <para> <ulink url="http://fedora.redhat.com/docs/updates/index.html">http://fedora.redhat.com/docs/updates/index.html</ulink> </para> </sect1>
<sect1 id="services-gui"> <title>Disabling unnecessary services</title> &DRAFTNOTICE; <sect2 id="services-gui-2"> <title>GUI: Service Configuration</title> <para> To get to the GUI tool to edit the default services, select <guimenu>Menu->System Settings->Server Settings->Services</guimenu>. This will bring up the Service configuration dialog. </para>
<note> <title>Access Note</title> <para> You should run this utility (and all other GUI utilities) as a normal user, unless otherwise specified. When doing so, you will be prompted for the root password. Type it in the dialog to continue. </para> </note> <para> For each service listed, the <application>Service Configuration</application> utility will display a short description about the service you have highlighted in the upper-right pane, and the current status and process ID (PID) of the service, if it is running. </para> <para> The services that you can <emphasis>safely</emphasis> disable will depend upon the role of your system. For example, if you are planning to run a web server, you will not want to disable the <application>httpd</application> service. The list below is a good starting place. These services can be disabled for the role we have chosen, that of a home workstation: </para> <itemizedlist> <listitem><para>aep1000 - load and unload AEP1000/AEP2000 coprocessor driver.</para></listitem> <listitem><para>bcm5820 - Hardware cryptographic accelerator support - BCM5820 Cryptonet driver.</para></listitem> <listitem><para>chargen - An xinetd internal service which generates characters.</para></listitem> <listitem><para>chargen-udp - This is the udp version.</para></listitem> <listitem><para>daytime - An internal xinetd service which gets the current system time.</para></listitem> <listitem><para>daytime-udp - This is the udp version.</para></listitem> <listitem><para>echo - An xinetd internal service which echo's characters back to clients.</para></listitem> <listitem><para>echo-udp - This is the udp version.</para></listitem> <listitem><para>httpd - Apache is a World Wide Web server. It is used to serve HTML files and CGI.</para></listitem> <listitem><para>irda - Infrared data link (for PDAs and such)</para></listitem> <listitem><para>ktalk - KDE version of the talk server.</para></listitem> <listitem><para>lisa - Provides information about hosts on your network.</para></listitem> <listitem><para>mysqld - MySQL database server.</para></listitem> <listitem><para>named - named (BIND) is a Domain Name Server (DNS) that is used to resolve host names to IP addresses.</para></listitem> <listitem><para>netplugd - netplugd is a daemon for managing non-static network interfaces.</para></listitem> <listitem><para>nfs - This service provides NFS server functionality.</para></listitem> <listitem><para>nfslock - This service provides NFS file locking functionality.</para></listitem> <listitem><para>nscd - This is a daemon which handles passwd and group lookups for running programs and cache the results for the next query. </para></listitem> <listitem><para>ntpd - ntpd is the NTPv4 daemon.</para></listitem> <listitem><para>pcmcia - PCMCIA support is usually to support things like ethernet and modems in laptops. </para></listitem> <listitem><para>rsync - allows remote file synchronization</para></listitem> <listitem><para>saslauthd - saslauthd is a server process which handles plaintext authentication requests on behalf of the cyrus-sasl library.</para></listitem> <listitem><para>services - An internal xinetd service, listing active services.</para></listitem> <listitem><para>sgi_fam - FAM is a file monitoring daemon.</para></listitem> <listitem><para>smartd - Self Monitoring and Reporting Technology (SMART) Daemon.</para></listitem> <listitem><para>snmpd - Simple Network Management Protocol (SNMP) Daemon.</para></listitem> <listitem><para>snmptrapd - Simple Network Management Protocol (SNMP) Trap Daemon.</para></listitem> <listitem><para>squid - Squid - Internet Object Cache.</para></listitem> <listitem><para>time - An RFC 868 time server. </para></listitem> <listitem><para>time-udp - This is the udp version.</para></listitem> <listitem><para>tux - The TUX threaded kernel-based http server.</para></listitem> <listitem><para>vncserver - Starts and stops vncserver. used to provide remote X administration services.</para></listitem> <listitem><para>winbind - Starts and stops the Samba winbind daemon.</para></listitem> <listitem><para>ypbind - This is a daemon which runs on NIS/YP clients and binds them to a NIS domain.</para></listitem> <listitem><para>yppasswdd - yppasswdd is the RPC server that lets users change their passwords in the presence of NIS (a.k.a. YP).</para></listitem> <listitem><para>ypserv - ypserv is an implementation of the standard NIS/YP networking protocol.</para></listitem> <listitem><para>ypxfrd - ypxfrd should be started in addition to ypserv to accelerate transferring yp maps.</para></listitem> <listitem><para>yum - Enable daily run of yum, a program updater. (This will depend on your environment.)</para></listitem> </itemizedlist> <note> <para> If you include <command>yum</command> in your list of services to disable here, then you will be disabling the automated updates you would have configured in earlier sections of this overview. Certain users may have specific reasons for <emphasis>not</emphasis> wanting to run automated updates every night. Most users will want to leave this enabled, if you are disabling it, you should know exactly why. </para> </note>
<para> Once you have chosen the services that you want to disable for your application, you can do so by unchecking the check box next to the name of the service you are disabling. Once you have deselected all of the services you want to disable, be sure to click the <guibutton>Save</guibutton> button, so that your changes are committed. The process needs to be done for all 3 multi user runlevels (3, 4, 5). The GUI utility defaults to runlevel 5, so you will have to manually select runlevels 3 and 4 to enable/disable service there. You may also want to check runlevel 2, as there are certain services that may be considered "critical" that will be started at that runlevel. </para> <important> <title>Important</title> <para> Be sure to stop the service you are disabling, if it is running. This will both prevent you from having to reboot your system, as well as give you an immediate indication of what effect <emphasis>not</emphasis> having that particular service running will have on your system. </para> </important> </sect2>
<sect2 id="services-cli"> <title>CLI: Service Configuration</title> <note> <title>Note:</title> <para> The following commands will need to be run as root. </para> </note> <para> There are a number of ways to tackle service control from the command line. One of the simplest is to use <command>chkconfig</command>. The following command will show you the all of the services that are enabled to run at runlevel 5: </para>
<screen> <userinput>sudo '/sbin/chkconfig --list | awk '/5:on/ { print $1 }' | sort'</userinput> </screen>
<para> If you are running in command line only mode (runlevel 3), theoretically, you could disable all of these services. However, this could cause problems if you were to ever run in GUI mode. So, focus on the ones that I have listed above in the GUI section. Take this list of services, and put it into a series of commands that can be run either from the command line directly, or in a script. The easiest way will be to put the list of services in a file, however you could list all of the services individually in the for loop. This might be the better option if you were running it directly from the command line. </para> <para> To put the list of services in a file, issue the command above, and redirect the output to a file: </para> <screen> <userinput>sudo '/sbin/chkconfig --list | awk '/[35]:on/ { print $1 }' | sort >> <replaceable>serviceslist.txt</replaceable>'</userinput> </screen> <para> This will capture all of the services that are designated to start at either runlevel 3 or runlevel 5. Then, edit the <filename>serviceslist.txt</filename> file to only disable the services you want to disable. An example serviceslist.txt file might look like this: </para>
<screen> <userinput>acpid anacron apmd autofs cpuspeed crond cups cups-config-daemon gpm haldaemon httpd iptables irqbalance kudzu lm_sensors mDNSResponder messagebus microcode_ctl netfs network nfslock nifd portmap readahead readahead_early rhnsd rpcgssd rpcidmapd rpcsvcgssd smartd smb vncserver xfs xinetd</userinput> </screen> <para> Once you've edited the <filename>serviceslist.txt</filename> file, put the following into a text file: </para>
<screen> <userinput> for SERVICE in `cat serviceslist.txt` ;do /sbin/chkconfig --level 35 ${SERVICE} off done </userinput> </screen>
<para> ...and give it executable permissions: </para>
<screen> <userinput> sudo chmod u+x script.sh </userinput> </screen> <para> Execute the script by issuing the following command: </para> <screen> <userinput>sudo ./<filename>script.sh</filename></userinput> </screen> <para> This will disable the services you have selected for runlevels 3 and 5, which are multi-user runlevels: level 3 for command line only, and level 5 for X, or GUI, mode. </para> </sect2> </sect1>
<sect1 id="userconfig-cli"> <title>Disabling or Deleting Unnecessary Users and Groups</title> &DRAFTNOTICE; <para> Once you've disabled all of the services you have determined to be unnecessary for your implementation, you will need to do the same thing for your users and groups. </para>
<warning> <title>Warning!</title> <para>Unmanaged users (unused users, users without passwords, etc.) can be a vector for attack. Without proper management of all of these "system" and "service" accounts, they could be easily compromised, and used to bring further harm to your system. </para> </warning>
<para> Remember the list of services that you disabled? Most of those services will have their own user. This is a good thing if you are intending to use those services, because that means that there is some chroot, or "jail environment", that is built into the application for that service. However, if you're not going to use those services, there is no reason to have those users lying around. For the most part, the user accounts that are associated with a service should be removed when the service is removed. However, the following steps will be necessary if a service or package is simply disabled, as described above, as opposed to completely removed. </para>
<sect2 id="userconfig-gui"> <title>GUI: Disabling unnecessary users</title> <para> Start by selecting <guimenu>Menu->System Setting->Users and Groups</guimenu>. This will bring up the <application>User Manager</application>. </para>
<note> <title>Authorization</title> <para>If you are running this as a normal user (as you should be), then you will have to type in the root password in the administrative privilege dialog box. </para> </note> <para> By default, the <application>User Manager</application> will filter all of the "default" and/or "system" users. These are the user account that need to be scrutinized. To view the users you want to disable, select <guimenu>Preferences->Filter System users and Groups</guimenu>. This will disable the default filter and you will be able to view the system users you want to disable. In order to disable a user, you will need to select the user, then click <guibutton>Properties</guibutton>. This will show you the details of the user's account. The first tab in the User Properties dialog will be the User Data tab. Here you will be presented with options such as "username", "user full name", etc. At the bottom of the tab will be the user's default shell. If this is not already <command>/sbin/nologin</command>, change it to that shell. Next, select the "Account Info" tab. You will be presented with two (2) check boxes here. The first is for account expiration period, the second is for "locking" the user account's password. Click both of these boxes so that they are checked. In the "Account Expiration" section, put today's date. Click the <guibutton>OK</guibutton> button, and move on to the next user. </para> <para> The following are some of the service related user accounts that you might want to disable, depending on your requirements: </para> <itemizedlist> <listitem><para>news - news server user</para></listitem> <listitem><para>operator</para></listitem> <listitem><para>gopher</para></listitem> <listitem><para>games</para></listitem> <listitem><para>squid - squid proxy cache daemon user.</para></listitem> <listitem><para>named - BIND (DNS Server) user.</para></listitem> <listitem><para>mysql - MySQLd user.</para></listitem> <listitem><para>ncsd - NCSD daemon user.</para></listitem> <listitem><para>ntp - ntp client user.</para></listitem> <listitem><para>apache - Apache/HTTPD user.</para></listitem> <listitem><para>smmsp - Sendmail mail queue user.</para></listitem> </itemizedlist> <para> Your usage will vary. If you are using certain publicly available services (such as a web server), you may not want to disable some of the user accounts mentioned here (like apache). A good rule of thumb is, that if you are disabling a service, and there is a user associated with that service, you will want to disable the user as well. </para> </sect2> </sect1> </chapter>
<chapter id="ch-chapter2"> <title>Securing the File System</title> &DRAFTNOTICE;
<para> Securing the file system basically translates to securing files. Some might consider selection of the file system type to be important, but for the scope of this document, it is assumed that you will be dealing with a base installation of &FC;. Given that assumption, most files will have "reasonable" permission already set. However, it never hurts to be sure. </para>
<sect1 id="fileleaks"> <title>Searching for insecure files</title> <sect2 id="fileleaks-fpintro"> <title>Basic File Permissions Introduction</title> <para>&FC; (and most other Unices) separates access control on files and directories according to three characteristics: user, group, and other. There is always exactly one owner, any number of members of the group, and everyone else. </para> <para> A quick explanation of Unix permissions: </para> <para>Ownership - Which user(s) and group(s) retain(s) control of the permission settings of the node and parent of the node </para> <para> Permissions - Bits capable of being set or reset to allow certain types of access to it. Permissions for directories may have a different meaning than the same set of permissions on files. </para> <para> Read: </para> <itemizedlist> <listitem><para>To be able to view contents of a file</para></listitem> <listitem><para>To be able to read a directory </para></listitem> </itemizedlist> <para> Write: </para> <itemizedlist> <listitem><para>To be able to add to or change a file</para></listitem> <listitem><para>To be able to delete or move files in a directory</para></listitem> </itemizedlist> <para> Execute: </para> <itemizedlist> <listitem><para>To be able to run a binary program or shell script</para></listitem> <listitem><para>To be able to search in a directory, combined with read permission</para></listitem> </itemizedlist> <para> Save Text Attribute: (For directories) </para> <para> The "sticky bit" also has a different meaning when applied to directories than when applied to files. If the sticky bit is set on a directory, then a user may only delete files that the he owns or for which he has explicit write permission granted, even when he has write access to the directory. This is designed for directories like /tmp, which are world-writable, but where it may not be desirable to allow any user to delete files at will. The sticky bit is seen as a t in a long directory listing. </para> <para> SUID Attribute: (For Files) </para> <para> This describes set-user-id permissions on the file. When the set user ID access mode is set in the owner permissions, and the file is executable, processes which run it are granted access to system resources based on the user who owns the file, as opposed to the user who created the process. This is the cause of many "buffer overflow" exploits. </para> <para> SGID Attribute: (For Files) </para> <para> If set in the group permissions, this bit controls the "set group id" status of a file. This behaves the same way as SUID, except the group is affected instead. The file must be executable for this to have any effect. </para> <para> SGID Attribute: (For directories) </para> <para> If you set the SGID bit on a directory (with chmod g+s directory), files created in that directory will have their group set to the directory's group. </para> <para> You - The owner of the file </para> <para> Group - The group you belong to </para> <para> Everyone - Anyone on the system that is not the owner or a member of the group </para>
<para> This is a fairly high level discussion of linux file permissions. A slightly more indepth discussion can be found here: </para>
<para> <ulink url="http://www.tldp.org/LDP/intro-linux/html/sect_03_04.html">http://www.tldp.org/LDP/intro-linux/html/sect_03_04.html</ulink> </para> </sect2>
<sect2 id="s2-chapter2--fileleaks-wwf"> <title>Finding world-writable files</title> <para> Unfortunately, there is no Fedora-specific tool (or GUI tool, for that matter) which raises the "Big Red Flag" and says: </para>
<screen> <computeroutput>/THIS/FILE/IN/THIS/PATH has world writable permissions. ANYONE can write to this file!!!</computeroutput> </screen>
<para> There is, however, a very simple (although not very timely) way of doing this with the *NIX <command>find</command> command. The lines below can be copied to a command line and then executed to find any world writable files and directories. </para>
<screen> <userinput>sudo 'find / ( -type d -o -type f ) -perm +002 | tee world-writable-files.txt'</userinput> </screen>
<para> You may be surprised at how many files are world-writable "out of the box". But you'll have to examine the list carefully, making sure that files that are listed are not links, or devices, or other special files. The command line above will only return normal directories and files. So if you have device (i.e. /dev/foo) files in your list, they are most likely marker files for devices that don't exist, or aren't in use on your system. </para> </sect2> <sect2 id="s1-chapter2-fileleaks-setuid"> <title>Finding SetUID/SetGID files</title> <para> You should also check for setUID/setGID files and directories. SetUID/setGID files are files that can be executed with permissions greater than that of the user running the program. Often, this can be exploited, and may still leave backdoors into your system, even after patching. </para> <para> Again, there is no Fedora-specific tool which will help us identify these files, however <command>find</command> can also solve this problem. Use the <command>find</command> command line string below to pipe all of the setUID/setGID files into a file. </para>
<screen> <userinput>find / -type f ( -perm -04000 -o -perm -02000 ) | tee -a setuid-files.txt</userinput> </screen> <para> You are likely to see many normal programs in this list, however, if you have just installed your system, and have not yet connected it to a network, it would be safe to consider this entire list of files as trusted. If you have connected this system to a network and/or have not just installed your system, you will want to carefully review the list of files, to make sure that there is nothing "odd" in the list. </para> </sect2> <sect2 id="fileleaks-summary"> <title>Insecure files summary</title> <para> Once you have obtained the list(s) of world-writable files and directories, you will want to save those lists in a secure place. Make a copy of the lists on a floppy, or other secure location, so you have them to reference, if needed. If you are using <application>gpg</application>, or have installed the <application>md5</application> utility, you will want to run a checksum of your file, or digitally sign it, so that in the event you need to reference that file, you are able to verify that it has not been tampered with. </para> <para> You will also want to periodically re-check your file system to make sure that no new files with the above permissions issues have been introduced into your system, that you are unaware of. To accomplish this, you can copy the following script, which combines the above commands, and run it from the cron tab on a regular basis. </para>
<screen> <computeroutput>#!/bin/bash
#simple script to check for world writable files and setUID/setGID files.
# baseline world-writable files list BL_WWF='/SCRIPTS/security/harden/world-writable-files.txt'
#baseline setuid files list BL_SUID='/SCRIPTS/security/harden/setuid-files.txt'
TODAY=`date +%y%m%d`
printf "Checking the file system for world-writable files ..... " find / ( -type d -o -type f ) -perm +002 > /tmp/${TODAY}-wwf.txt printf " done.\n"
printf "Checking the file system for setUID/GID files ..... " find / -type f ( -perm -04000 -o -perm -02000 ) > /tmp/${TODAY}-suid.txt printf " done.\n"
diff ${BL_WWF} /tmp/${TODAY}-wwf.txt > /tmp/${TODAY}-wwf.diff
diff ${BL_SUID} /tmp/${TODAY}-suid.txt > /tmp/${TODAY}-suid.diff printf "Changed world-writable files:\n" cat /tmp/${TODAY}-wwf.diff | mail -s "World Writable Files for ${TODAY}" charlie@localhost
printf "Changed setUID/GID files:\n" cat /tmp/${TODAY}-suid.diff | mail -s "setU/GID Files for ${TODAY}" charlie@localhost</computeroutput> </screen> <para> This may take a few minutes depending upon the size of your file system. For example, on a file system spanning multiple drives, and totaling approximately 160GB, it could take as long as 10 minutes. </para> <para> To run the script from the crontab, enter a line like the following into the cron: </para> <screen> <userinput>0 0 * * * /SCRIPTS/security/harden/check_files.sh</userinput> </screen>
<para> This will run the script every night at midnight. You will want to make adjustments for your own application. </para> </sect2> </sect1>
<sect1 id="rpm-verify"> <title>Verifying packages with <command>rpm</command></title>
<para> The <command>rpm</command> command can be used to verify the packages that you have installed. This should be done regularly. Verifying a package compares information about the installed files in the package with information about the files taken from the package metadata stored in the rpm database. Among other things, verifying compares the size, MD5 sum, permissions, type, owner and group of each file. Any discrepancies are displayed. Files that were not installed from the package will be silently ignored. There are a number of options that you can implement at the command line, however, they are mostly to disable features that you would most likely want. You can do this type of verification by issuing the following command: </para>
<screen> <userinput>rpm -Va</userinput> </screen>
<para> This will verify each installed package as described above, and output something similar to the following: </para>
<screen><computeroutput> .....UG. /lib/modules/2.6.9-1.724_FC3/build/scripts/lxdialog/msgbox.c .....UG. /lib/modules/2.6.9-1.724_FC3/build/scripts/lxdialog/yesno.c .M...UG. /lib/modules/2.6.9-1.724_FC3/build/scripts/mkuboot.sh .....UG. /lib/modules/2.6.9-1.724_FC3/build/scripts/mkversion S.5....T c /etc/pam.d/system-auth S.5....T /usr/share/texmf/web2c/amstex.fmt S.5....T /usr/share/texmf/web2c/bamstex.fmt </computeroutput></screen>
<para> There may be file identifiers, like the 'c' in the middle of the line for the <filename>/etc/pam.d/system-auth</filename>. This index can indicate any of the following: </para>
<screen><computeroutput> c - configuration file. d - documentation file. g - the file contents are not included in the package payload l - license file. r - readme file. </computeroutput></screen>
<para> The indicators in the left column indicate the test success or failure, and if the test failed, the reason for the failure. The alphanumeric indicator can indicate any of the following: </para>
<screen><computeroutput> S - file Size differs M - Mode differs (includes permissions and file type) 5 - MD5 sum differs D - Device major/minor number mismatch L - readLink(2) path mismatch U - User ownership differs G - Group ownership differs T - mTime differs </computeroutput></screen>
<para> Most of the time the errors seen here will be relatively benign, especially if you have yum configured to update packages automatically. However you should verify changes that you don't recognize. </para> </sect1>
<sect1 id="verify-config-file"> <title>Configuration File Verification</title> <para> If you are running any types of network services, i.e. web, mail, ftp, etc., you should periodically verify your configuration files. It is a good idea to have an external backup (floppy, CD, etc.) in case something happens to your working config. Once you have completed either the base configuration, or an update to an existing configuration, save your files to your chosen secure location. You may even consider running the tool <command>md5sum</command> against each configuration file as an extra measure. This will help to ensure that your configuration files haven't been tampered with. </para>
<note> <title>md5sum example</title> <para>md5sum /etc/httpd/conf/httpd.conf >> /dev/fd0/conf_files_checksums.md5</para> </note>
<para> The above example makes the assumption that you will be saving your md5 checksum list to a floppy, and the your floppy is already mounted. If you don't know how to mount a floppy, the following command should work: </para>
<screen><userinput>mount -t vfat /dev/fd0 /mnt/floppy</userinput></screen>
<para> You can also find more information on md5sum, and a more complete example in the previous section: <xref linkend="s3-intro-md5sum-example"></xref>. </para> </sect1>
<sect1 id="umask"> <title>Setting the default umask</title>
<para> The default UMASK is the file permissions mask that establishes the level of permissions used for creating the default permissions on files. The mask is the "mirror image" of the actual permissions that you want. For example, if you want files created with permissions of 755, or -rwxr-xr-x, you would want your umask to be 022. In order to set this globally, you will need to edit this parameter in the <filename>/etc/bashrc</filename> file. However, the default implementation with &FC; is fairly secure, employing the idea of what RedHat calls "User Private Groups". So, if you want to change this parameter, you should know exactly what you are doing and why. </para>
<para> To change the umask for a single session, you can use the <command>umask</command> utility as shown below. </para>
<screen> <userinput>umask 0022</userinput> </screen>
<para> The above command will change the default umask to 022. (This should already be the default and you can test this by issuing the command <command>umask</command> at the command line as root.) </para>
</sect1>
<sect1 id="fssummary"> <title>File System Security Summary: Where to go from here?</title>
<para> The actions discussed here will put you on the road to file system security. However, you may find that there are some other things which are handy to have to help ensure the security of your files. </para>
<para> One type of tool that you may want to look into is called a System Integrity Verifier (SIV). This is a program which will scan your system and keep track of any changes to your files, or file system, based on a security policy that you design. Some examples of this might be Tripwire or AIDE. You can find out more about these products at the links below. </para>
<itemizedlist> <listitem><para><ulink url="http://sourceforge.net/projects/tripwire/">http://sourceforge.net/projects/tripwire/</ulink></para></listitem> <listitem><para><ulink url="http://www.cs.tut.fi/~rammer/aide.html">http://www.cs.tut.fi/~rammer/aide.html</ulink></para></listitem> </itemizedlist> </sect1> </chapter> <chapter id="ch-chapter3"> <title>Securing User Accounts</title>
&DRAFTNOTICE;
<sect1 id="unnecessary-accounts"> <title>Disabling Unnecessary Users</title>
<para>Disabling unnecessary users can stop possible attacks by limiting the avenues that an attacker can use to penetrate your system. The procedure has already been discussed in <xref linkend="userconfig-gui"></xref>. </para>
</sect1>
<sect1 id="limit-root"> <title>Limiting root logins</title>
<para> There are a number of ways to limit how root can login to your system. When making changes to your system, you must be mindful of how root could access your system. The most secure practice is to limit root to <command>su</command> logins only. </para>
<sect2 id="limit-root-gui"> <title>GUI: Limiting root</title> <para> As alluded to in earlier sections, where GUI configurations were discussed, as long as you are logged in as a normal user, you will be prompted for the root password if you are attempting to administer any system-wide services that require root access. From time to time, there will be an application or program that does not ask for root authentication when attempting to run. If you believe that an application should run as root, and it does not ask for the root password, you may be better off running it from a terminal with the <command>su</command>. </para> </sect2>
<sect2 id="limit-root-cli"> <title>CLI: Limiting root</title> <para> Unfortunately, the command line isn't so forgiving. Unless you are starting a GUI application that requires root permissions, you will not be prompted for the root password if attempting to execute a command that requires root permissions. You will just get a "Permission Denied" error. </para>
<para> One of the easiest ways to utilize the <command>su</command> capability, is with the utility called <command>sudo</command>. </para>
<para> Aside from enabling and using <command>sudo</command>, one of the first things to disable is root's direct access via SSH. If you plan not to use SSH for remote access to your system, then you can disable SSH completely as described in <xref linkend="services-gui"></xref>. However, if you ARE planning to use SSH, then you will want to limit direct access as root. "Direct access" means that you login to the system as root, instead of SSH'ing as a normal user, then <command>su</command>'ing to root (or using <command>sudo</command>, which will be discussed later). </para>
<para> Unfortunately, there isn't yet a Fedora GUI tool for editing SSH configuration. So choose your favorite editor (this may actually be a GUI editor, but there is no specific tool for ssh configuration). Go to the line that reads: </para>
<screen> <computeroutput>PermitRoot yes</computeroutput> </screen>
<para>And change it to read:</para>
<screen> <computeroutput>PermitRoot no</computeroutput> </screen>
<note> <title>Application Security Note</title> <para> While you are editing the <filename>sshd_config</filename> file, you may want to disable the SSH1 protocol by changing the line that reads: </para>
<screen> <computeroutput>Protocol 2,1</computeroutput> </screen>
<para>to read:</para>
<screen> <computeroutput>Protocol 2</computeroutput> </screen>
<para> This forces the client to use the SSH2 protocol, which can help to discourage attacks that SSH1 is vulnerable to. </para> </note>
<para> Then, either reboot your system, or issue the command <command>pkill -1 sshd</command>. The <command>pkill</command> command will force <command>sshd</command> to re-read it's configuration file, it will also kill any existing connections, including your own if you're making these changes through an ssh session. A more graceful way to simply make sshd reread it's config file would be with the following command: </para> <screen> <userinput>sudo '/sbin/service sshd reload'</userinput> </screen> <para> This will force users to login as a normal user account and then <command>su</command> to root, or utilize <command>sudo</command>. </para> </sect2> </sect1>
<sect1 id="shells"> <title>Verifying and Correcting System user shells</title> <para> System users, such as bin, sys, nobody, lp, etc. should not have valid shells &FC; offers the <filename>/bin/false</filename> and the <filename>/bin/nologin</filename> shell for these users. </para>
<para> To verify the shells in use by your system accounts, you can use the <application>User Manager</application> utility. Select <guimenu>System Settings->Users and Groups</guimenu>. You will be prompted for the root password, if you are logged in as a normal user. Then the utility will open. If you do not see any of the systems users, make sure that you do not have them filtered (this is the default behavior). Select <guimenu>Preferences->Filter System Users and Groups</guimenu> from the menu and ensure that it is NOT checked. Then, you can scroll through the list of users to make sure that all of your system users have the <filename>/bin/false</filename> or <filename>/bin/nologin</filename> shells. </para>
<para> There are some users which will have a special shell, like the shutdown or halt users. These special shells can be left alone. </para> </sect1>
<sect1 id="passwd-sec-pam-config"> <title>Password Security and PAM Configuration</title>
<para> Password strength and security is one of the weakest points in a system's security posture. This is mainly because password strength depends on us humans. One way that you can help to enforce more secure passwords is by editing the PAM configuration. PAM stands for Pluggable Authentication Modules, and is a good way of setting password and authentication settings for many different services on your &FC; system. </para>
<para> All or most of the files that configure PAM settings for different services are located in the <filename>/etc/pam.d/</filename> directory. The one that we want to focus on for increasing password strength is the <filename>system-auth</filename> file. This file contains configuration information for your general system authentication. </para>
<para> The file <filename>/usr/share/doc/pam-0.77/txts/README.pam_cracklib</filename> contains some information regarding the configuration options for this file. </para> <para> One option described in this file is the <computeroutput>minlen=</computeroutput> option. This is the option that specifies the minimum number of characters in a password. A password with 7 characters, even a "strong" password, yeilds only a maximum of [still figuring this number] character combinations, which can be cracked rather easily by today's brute force methods. Increasing the minimum length to 8 characters ups the number of combinations to [still figuring this number too]. Most security guides will advise a password of at least 8 characters, however, 12-16 characters is considered ",very secure. </para>
<para> Other important options are the <computeroutput>dcredit=</computeroutput>, <computeroutput>ucredit=</computeroutput>, <computeroutput>lcredit=</computeroutput>, and <computeroutput>ocredit=</computeroutput> options. These options specify how many characters should be digits, uppercase, lowercase, and special characters, respectively. In order to ensure a strong password, all of these options should be set to at least one. </para>
<para> The <computeroutput>difok=</computeroutput> option specifies how many characters can be the same between the "old" password and the "new" password when changing passwords. For example, if your old password was password, and you had the <computeroutput>difok=</computeroutput> setting set to 4, the "new" password passways would fail, whereas pastels would succeed. </para> </sect1> </chapter>
<chapter id="ch-tcpwrappers-n-fw"> <title>tcp_wrappers and Firewall Configuration</title> <sect1 id="tcp_wrappers_config"> <title><application>tcp_wrappers</application> Configuration</title> <para> <application>tcp_wrappers</application> is a method of limiting the connections that can be made to your system - sort of like the "poor man's firewall". <application>tcp_wrappers</application> will allow or deny a connection based on the source IP address and the service that that IP address is attempting to connect to. The version of <application>tcp_wrappers</application> that comes with &FC; does not support the "enhanced" functionality, however with a proper implementation of <application>iptables</application> you can get a lot more granular in your network defense. </para>
<sect2 id="hosts.deny"> <title>The <filename>hosts.deny</filename> file.</title> <para> The basic <application>tcp_wrappers</application> configuration consists of two files: <filename>/etc/hosts.allow</filename> and <filename>/etc/hosts.deny</filename>. The <filename>hosts.deny</filename> is the easier of the two to configure. An example is below. </para>
<screen> <computeroutput> # Example hosts.deny file configuration # Deny all hosts unless specified in the allow file ALL:ALL </computeroutput> </screen>
<para> As indicated by the example, the best practice is to deny all hosts attempting to make a connection to your system, unless they are specifically allowed in the <filename>hosts.allow</filename> file. </para> </sect2> <sect2 id="hosts.allow"> <title>The <filename>hosts.allow</filename> file.</title> <para> The <filename>hosts.allow</filename> file is only slightly more complex in this implementation, than the <filename>hosts.deny</filename> file. Let's assume for example, that you were running a web server on your workstation and you wanted every system in your local network to be able to connect to it, but you only wanted to be able to manage the web server from one other workstation. You <filename>hosts.allow</filename> file might look something like the following: </para>
<screen> <computeroutput> # Example hosts.allow file configuration # Allow every system in the local network to connect to # the web server httpd:10.0.0.
# Only allow the administration workstation to ssh to the # server for configuration and administration sshd:10.0.0.192 </computeroutput> </screen>
<para> This would satisfy the requirements as specified above. If there was a service that you wanted anyone and everyone to be able to connect to, you might include a line like the following: </para>
<screen> <computeroutput> # Allow any system to make DNS queries named:all </computeroutput> </screen>
<para> There is more information on <application>tcp_wrappers</application> at the links below. They may mention features which are not implemented in the &FC; implementation, but they will give you an idea of how <application>tcp_wrappers</application> can be configured, and its purpose. </para>
<itemizedlist> <listitem> <para> <ulink url="http://www.cert.org/security-improvement/implementations/i041.07.html">http://www.cert.org/security-improvement/implementations/i041.07.html</ulink> </para> </listitem> <listitem> <para> <ulink url="http://www.stanford.edu/group/itss-ccs/security/unix/tcpwrappers.html">http://www.stanford.edu/group/itss-ccs/security/unix/tcpwrappers.html</ulink> </para> </listitem> </itemizedlist> </sect2> </sect1>
<sect1 id="iptables-fw-config"> <title>Firewall/IPTables Configuration</title> <para> The default &FC; firewall configuration utility is somewhat limited at this point in time. However, it should function well enough for most home or small office users. </para>
<para> During the install you will be asked if you want to enable the firewall, and what services you will want enabled (if any). If you disabled the firewall during the install, or if you are working with a previously installed system and are not sure whether the firewall was enabled, you can check the security level by selecting <guimenu>Applications->System Settings->Security Level</guimenu>. This will bring up the <application>system-config-securitylevel</application> utility. This utility will allow you to view or change the firewall settings. It will also allow you to change the SELinux settings, however that discussion is currently outside of the scope of this document. </para>
<para> If you are familiar enough with the applications that you need to allow to your system, then you can specify specific ports in the text area provided in the utility's dialog. The format for adding ports should match the following: </para> <screen><userinput>445:tcp, 135:tcp, 137:udp, 138:udp, 139:udp</userinput></screen>
<para> The example above would allow NetBIOS communications to your system. The utility currently does not support entry of port ranges. So, if your are going to use the default Fedora utility, you will need to specify each port specifically as exemplified above. </para>
<para> If you have need for more granular control over your firewall, you may consider a utility such as Firestarter. Or do some reading on the configuration of <command>iptables</command>. </para> </sect1> </chapter>
<chapter id="ch-conclusion"> <title>Conclusion</title>
<para> As stated in the introduction and the scope of this document, this is not meant to be the end-all-be-all document for security, or even Fedora security. However, it can be a guide to specific tasks that will help to accomplish a couple of things. One, it gives you guidance on how to accomplish specific tasks to make your Fedora system more secure. It also can act as a guide to get you thinking about security. </para>
<para> To stay as secure as possible, explore tools and opportunities outside of the Fedora utilities. This will help you to see the breadth of things that are out there to help you secure your system. Learn, learn, learn. As threats become more mature, so must the user. The more you read and learn about your system and your chosen operating system, the more savvy, and more secure as a user you will become. </para> </chapter>
<chapter id="ch-bibb-n-refs"> <title>Bibliography and References</title>
<itemizedlist> <listitem> <para><ulink url="http://www.tldp.org/LDP/intro-linux/html/sect_03_04.html">http://www.tldp.org/LDP/intro-linux/html/sect_03_04.html</ulink></para> </listitem> <listitem> <para><ulink url="http://www.linuxhelp.net/guides/sudo/">http://www.linuxhelp.net/guides/sudo/</ulink></para> </listitem> <listitem> <para><ulink url="http://www.brandonhutchinson.com/Hardening_Fedora.html">http://www.brandonhutchinson.com/Hardening_Fedora.html</ulink></para> </listitem> <listitem> <para><ulink url="http://www.linuxsecurity.com/docs/LDP/Security-HOWTO/file-security.html">http://www.linuxsecurity.com/docs/LDP/Security-HOWTO/file-security.html</ulink></para> </listitem> <listitem> <para><ulink url="http://security.linux.com/security/04/09/20/1555239.shtml?tid=35">http://security.linux.com/security/04/09/20/1555239.shtml?tid=35</ulink></para> </listitem> <listitem> <para><ulink url="http://lists.samba.org/archive/samba-technical/2002-November/025702.html">http://lists.samba.org/archive/samba-technical/2002-November/025702.html</ulink></para> </listitem> <listitem> <para><ulink url="http://www.puschitz.com/SecuringLinux.shtml">http://www.puschitz.com/SecuringLinux.shtml</ulink></para> </listitem> <listitem> <para><ulink url="http://www.kernel.org/pub/linux/libs/pam/Linux-PAM-html/pam-6.html#ss6.3">http://www.kernel.org/pub/linux/libs/pam/Linux-PAM-html/pam-6.html#ss6.3</ulink></para> </listitem> <listitem> <para><ulink url="http://openskills.info/infobox.php?IDbox=1092&boxtype=distro">http://openskills.info/infobox.php?IDbox=1092&boxtype=distro</ulink></para> </listitem> </itemizedlist> </chapter>
</book>
Index: Makefile =================================================================== RCS file: /cvs/docs/hardening/Makefile,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 --- Makefile 17 May 2005 02:02:13 -0000 1.1 +++ Makefile 26 Jul 2005 03:49:57 -0000 1.2 @@ -1,29 +1,30 @@ ############################################################################### # Makefile for RHLP docs project # Created by: Tammy Fox tfox@redhat.com -# Last edited by: Tammy Fox tfox@redhat.com +# Last edited by: Tommy Reynolds Tommy.Reynolds@MegaCoder.com # WARNING: need passivetex 1.24 for pdf generation to work # License: GPL # Copyright 2003 Tammy Fox, Red Hat, Inc. +# Copyright 2005 Tommy Reynolds, MegaCoder.com ###############################################################################
-XSLPDF = ../xsl/main-pdf.xsl -XSLHTML = ../xsl/main-html.xsl -LANG = en -#DOCNAME = fedora-hardening-guide-$(LANG) -DOCNAME = fedora-hardening-guide-$(LANG) -XMLFILE = $(DOCNAME).xml +XSLPDF = ../docs-common/xsl/main-pdf.xsl +XSLHTML = ../docs-common/xsl/main-html.xsl +XSLHTMLNOCHUNKS = ../docs-common/xsl/main-html-nochunks.xsl +LANG = en +DOCNAME = hardening-tutorial-$(LANG) +XMLFILE = $(DOCNAME).xml +XMLEXTRAFILES =
###################################################### -html: - @xmlto html -x $(XSLHTML) -o $(DOCNAME) $(XMLFILE) - @mkdir -p $(DOCNAME)/stylesheet-images - @cp ../stylesheet-images/*.png $(DOCNAME)/stylesheet-images - @cp ../css/fedora.css $(DOCNAME) - -pdf-%: - @xmlto pdf -x $(XSLPDF) $(XMLFILE) +include ../docs-common/Makefile.common ######################################################
-clean: - @rm -rfv *.html *.pdf *.tex $(DOCNAME) +# If you want to add additional steps to any of the +# targets defined in "Makefile.common", be sure to use +# a double-colon in your rule here. For example, to +# print the message "FINISHED AT LAST" after building +# the HTML document version, uncomment the following +# line: +#${DOCNAME}/index.html:: +# echo FINISHED AT LAST
--- fedora-hardening-guide-en.xml DELETED ---
docs-commits@lists.fedoraproject.org
-
fedora-docs-commits＠redhat.com