From owner-svn-doc-head@FreeBSD.ORG Tue Feb 4 00:31:28 2014 Return-Path: Delivered-To: svn-doc-head@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5B109669; Tue, 4 Feb 2014 00:31:28 +0000 (UTC) Received: from svn.freebsd.org (svn.freebsd.org [IPv6:2001:1900:2254:2068::e6a:0]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 467B418E8; Tue, 4 Feb 2014 00:31:28 +0000 (UTC) Received: from svn.freebsd.org ([127.0.1.70]) by svn.freebsd.org (8.14.8/8.14.8) with ESMTP id s140VSZW067350; Tue, 4 Feb 2014 00:31:28 GMT (envelope-from trhodes@svn.freebsd.org) Received: (from trhodes@localhost) by svn.freebsd.org (8.14.8/8.14.8/Submit) id s140VSd1067313; Tue, 4 Feb 2014 00:31:28 GMT (envelope-from trhodes@svn.freebsd.org) Message-Id: <201402040031.s140VSd1067313@svn.freebsd.org> From: Tom Rhodes Date: Tue, 4 Feb 2014 00:31:28 +0000 (UTC) To: doc-committers@freebsd.org, svn-doc-all@freebsd.org, svn-doc-head@freebsd.org Subject: svn commit: r43744 - head/en_US.ISO8859-1/books/handbook/security X-SVN-Group: doc-head MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-BeenThere: svn-doc-head@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SVN commit messages for the doc tree for head List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Feb 2014 00:31:28 -0000 Author: trhodes Date: Tue Feb 4 00:31:27 2014 New Revision: 43744 URL: http://svnweb.freebsd.org/changeset/doc/43744 Log: Rewrite the front of the security section. This version adds a small discussion on using sudo, shows and example of using an IDS rather than just discussing what they are, update of threats, discussion on rootkits and back doors, adds more sysctls and more. Modified: head/en_US.ISO8859-1/books/handbook/security/chapter.xml Modified: head/en_US.ISO8859-1/books/handbook/security/chapter.xml ============================================================================== --- head/en_US.ISO8859-1/books/handbook/security/chapter.xml Tue Feb 4 00:16:12 2014 (r43743) +++ head/en_US.ISO8859-1/books/handbook/security/chapter.xml Tue Feb 4 00:31:27 2014 (r43744) @@ -7,8 +7,13 @@ Security - MatthewDillonMuch of this chapter has been taken from the - security(7) manual page by + + + Tom + Rhodes + + Rewritten by + @@ -19,17 +24,17 @@ Synopsis - This chapter provides a basic introduction to system - security concepts, some general good rules of thumb, and some - advanced topics under &os;. Many of the topics covered here - can be applied to system and Internet security in general. - Securing a system is imperative to protect data, intellectual - property, time, and much more from the hands of hackers and the - like. - - &os; provides an array of utilities and mechanisms to - protect the integrity and security of the system and - network. + Security, whether physical or virtual, is a topic + so broad that an entire industry has grown up around it. + Hundreds of standard practices have been authored about + how to secure systems and networks, and as a user of &os;, + understanding how to protect against attacks and intruders + is a must. + + In this chapter, several fundamentals and techniques will + be discussed. The &os; system comes with multiple layers of + security, and many more third party utilities may be added to + enhance security. After reading this chapter, you will know: @@ -108,341 +113,357 @@ Introduction - Security is a function that begins and ends with the system - administrator. While &os; provides some inherent security, the - job of configuring and maintaining additional security - mechanisms is probably one of the single largest undertakings of - the sysadmin. - - System security also pertains to dealing with various forms - of attack, including attacks that attempt to crash, or otherwise - make a system unusable, but do not attempt to compromise the - root account. Security concerns can be - split up into several categories: - - - - Denial of service attacks. - - - - User account compromises. - - - - Root compromise through accessible services. - - - - Root compromise via user accounts. - - - - Backdoor creation. - - - - - DoS attacks - Denial of Service (DoS) - - - security - DoS attacks - Denial of Service (DoS) - - Denial of Service (DoS) - - A Denial of Service DoS attack is an - action that deprives the machine of needed resources. - Typically, DoS attacks are brute-force - mechanisms that attempt to crash or otherwise make a machine - unusable by overwhelming its services or network stack. Attacks - on servers can often be fixed by properly specifying options to - limit the load the servers incur on the system under adverse - conditions. Brute-force network attacks are harder to deal - with. This type of attack may not be able to take the machine - down, but it can saturate the Internet connection. - - - security - account compromises - - - A user account compromise is more common than a - DoS attack. Many sysadmins still run - unencrypted services, meaning that users logging into the - system from a remote location are vulnerable to having their - password sniffed. The attentive sysadmin analyzes the remote - access logs looking for suspicious source addresses and - suspicious logins. - - In a well secured and maintained system, access to a user - account does not necessarily give the attacker access to - root. Without root - access, the attacker cannot generally hide his tracks and may, - at best, be able to do nothing more than mess with the user's - files or crash the machine. User account compromises are common - because users tend not to take the precautions that sysadmins - take. - - - security - backdoors - - - There are potentially many ways to break - root: the attacker may know the - root password, the attacker may exploit a - bug in a service which runs as root, or the - attacker may know of a bug in a SUID-root program. An attacker - may utilize a program known as a backdoor to search for - vulnerable systems, take advantage of unpatched exploits to - access a system, and hide traces of illegal activity. - - Security remedies should always be implemented with a - multi-layered onion peel approach and can be - categorized as follows: - - - - Secure root and staff - accounts. - - - - Secure root–run servers - and SUID/SGID binaries. - - - - Secure user accounts. - - - - Secure the password file. - - - - Secure the kernel core, raw devices, and - filesystems. - - - - Quick detection of inappropriate changes made to the - system. - - - - Paranoia. - - - - The next section covers these items in greater depth. - - - - Securing &os; - - - security - securing &os; - - - This section describes methods for securing a &os; system - against the attacks that were mentioned in the previous section. + Security is everyone's responsibility. A weak entry point + in any system could allow intruders to gain access to critical + information and cause havoc on an entire network. In most + security training, they discuss the security triad + CIA which stands for the confidentiality, + integrity, and availability of information systems. + + The CIA triad is a bedrock concept of + computer security, customers and end users expect privacy + of their data. They expect orders they place to not be changed + or their information altered behind the scenes. They also expect + access to information at all times. Together they make up the + confidentiality, integrity, and availability of the + system. - - Securing the <systemitem class="username">root</systemitem> Account + To protect CIA, security professionals + apply a defense in depth strategy. The idea of defense in + depth is to add several layers of security to prevent one single + layer failing and the entire security system collapsing. A + systems administrator cannot simply turn on a firewall and + consider the network or system secure, they must audit accounts, + check the integrity of binaries, and ensure malicious tools are + not installed. To do this, they must understand what the + threats are. + + + Threats + + What is a threat as pertaining to computer security? For + years it was assumed that threats are remote attackers, people + whom will attempt to access the system without permission, from + a remote location. In today's world, this definition has been + expanded to include employees, malicious software, rogue + network devices, natural disasters, security vulnerabilities, + and even competing corporations. + + Every day thousands of systems and networks are attacked and + several hundred are accessed without permission. Sometimes + by simple accident, others by remote attackers, and in some + cases, corporate espionage or former employees. As a system + user, it is important to prepare for and admit when a mistake + has lead to a security breach and report possible issues to + the security team. As an administrator, it is important to + know of the threats and be prepared to mitigate them. + + + + A Ground Up Approach + + In security, it is sometimes best to take a ground up + approach, whereas the administrator begins with the basic + accounts, system configuration, and then begins to work with + third party utilities and work up to the network layer. It + is in these latter configuration aspects that system policy + and procedures should take place. + + Many places of business already have a security policy that + covers the configuration technology devices in use. They + should contain, at minimal, the security configuration of end + user workstations and desktops, mobile devices such as phones + and laptops, and both production and development servers. In + many cases, when applying computer security, standard operating + procedures (SOPs) already exist. When in + doubt, ask the security team. + + + + System and User Accounts + + In securing a system, the best starting point is auditing + accounts. Ensure that the root account has a strong password, + disable accounts that do not need shell access, for users who + need to augment their privileges, install the + security/sudo and only allow them access + to applications they need. The root user password should + never be shared. - - &man.su.1; - - - Most - systems have a password assigned to the - root account. Assume that this password - is always at risk of being compromised. - This does not mean that the password should be disabled as the - password is almost always necessary for console access to the - machine. However, it should not be possible to use this - password outside of the console or possibly even with - &man.su.1;. For example, setting the entries in - /etc/ttys to insecure - prevents root logins to the specified - terminals. In &os;, root logins using - &man.ssh.1; are disabled by default as - PermitRootLogin is set to - no in - /etc/ssh/sshd_config. Consider every - access method as services such as FTP often fall through the - cracks. Direct root logins should only - be allowed via the system console. - - - wheel - - - Since a sysadmin needs access to - root, additional password verification - should be configured. One method is to add appropriate user - accounts to wheel in - /etc/group. Members of - wheel are allowed to &man.su.1; to - root. Only those users who actually need - to have root access should be placed in - wheel. When using Kerberos for - authentication, create a .k5login in - the home directory of root to allow - &man.ksu.1; to be used without having to place anyone in - wheel. - - To lock an account completely, use &man.pw.8;: - - &prompt.root; pw lock staff - - This will prevent the specified user from logging in using - any mechanism, including &man.ssh.1;. - - Another method of blocking access to accounts would be to - replace the encrypted password with a single - * character. This character - would never match the encrypted password and thus blocks user - access. For example, the entry for the following + To deny access to accounts, two methods exist. The first + one is to lock an account, for example, to lock the toor account: - foobar:R9DT/Fa1/LV9U:1000:1000::0:0:Foo Bar:/home/foobar:/usr/local/bin/tcsh + &prompt.root; pw lock toor - could be changed to this using &man.vipw.8;: + This command will change the account from this + toor:*:0:0::0:0:Bourne-again Superuser:/root: + to toor:*LOCKED**:0:0::0:0:Bourne-again + Superuser:/root: + + In some cases, this is not possible, perhaps because of + an additional service. In those cases, login access + could be prevented by changing the shell to /sbin/nologin + like in this example: - foobar:*:1000:1000::0:0:Foo Bar:/home/foobar:/usr/local/bin/tcsh + &prompt.root; chsh -s /usr/sbin/nologin toor - This prevents foobar from logging in - using conventional methods. This method for access - restriction is flawed on sites using - Kerberos or in situations where the - user has set up keys with &man.ssh.1;. - - These security mechanisms assume that users are logging - in from a more restrictive server to a less restrictive - server. For example, if the server is running network - services, the workstation should not be running any. In - order for a workstation to be reasonably secure, run zero or - as few services as possible and run a password-protected - screensaver. Of course, given physical access to any system, - an attacker can break any sort of security. Fortunately, - many break-ins occur remotely, over a network, from people who - do not have physical access to the system. - - Using Kerberos provides the ability to disable or change - the password for a user in one place, and have it immediately - affect all the machines on which the user has an account. If - an account is compromised, the ability to instantly change the - associated password on all machines should not be underrated. - Additional restrictions can be imposed with Kerberos: a - Kerberos ticket can be configured to timeout and the Kerberos - system can require that the user choose a new password after a - configurable period of time. - - - - Securing Root-run Servers and SUID/SGID Binaries - - - sandboxes - - - &man.sshd.8; - - - The prudent sysadmin only enables required services and is - aware that third party servers are often the most bug-prone. - Never run a server that has not been checked out carefully. - Think twice before running any service as - root as many daemons can be run as a - separate service account or can be started in a - sandbox. Do not activate insecure - services such as &man.telnetd.8; or &man.rlogind.8;. - - Another potential security hole is SUID-root and SGID - binaries. Most of these binaries, such as &man.rlogin.1;, - reside in /bin, - /sbin, /usr/bin, or /usr/sbin. While nothing is - 100% safe, the system-default SUID and SGID binaries can be - considered reasonably safe. It is recommended to restrict - SUID binaries to a special group that only staff can access, - and to delete any unused SUID binaries. SGID binaries can be - almost as dangerous. If an intruder can break an SGID-kmem - binary, the intruder might be able to read - /dev/kmem and thus read the encrypted - password file, potentially compromising user accounts. - Alternatively, an intruder who breaks group - kmem can monitor keystrokes sent through - ptys, including ptys used by users who login through secure - methods. An intruder that breaks the - tty group can write to almost any - user's tty. If a user is running a terminal program or - emulator with a keyboard-simulation feature, the intruder can - potentially generate a data stream that causes the user's - terminal to echo a command, which is then run as that - user. - - - - Securing User Accounts - - User accounts are usually the most difficult to secure. - Be vigilant in the monitoring of user accounts. Use of - &man.ssh.1; and Kerberos for user accounts requires extra - administration and technical support, but provides a good - solution compared to an encrypted password file. - - - - Securing the Password File + + Only super users are able to change the shell for + other users. Attempting to perform this as a regular user + will fail. + - The only sure fire way is to star out as many passwords as - possible and use &man.ssh.1; or Kerberos for access to those - accounts. Even though the encrypted password file - (/etc/spwd.db) can only be read by - root, it may be possible for an intruder - to obtain read access to that file even if the attacker cannot - obtain root-write access. + The account structure will now look like this, with + the nologin shell as the last entry: - Security scripts should be used to check for and report - changes to the password file as described in the Checking file integrity - section. - - - - Securing the Kernel Core, Raw Devices, and - Filesystems + toor:*:0:0::0:0:Bourne-again Superuser:/root:/usr/sbin/nologin - Most modern kernels have a packet sniffing device driver - built in. Under &os; it is called - bpf. This device is needed for DHCP, - but can be removed in the custom kernel configuration file of - systems that do not provide or use DHCP. + The /usr/sbin/nologin shell will block + the &man.login.1; command from assigning a shell to this + user. + - - &man.sysctl.8; - + + Permitted Account Escalation - Even if bpf is disabled, - /dev/mem and - /dev/kmem are still problematic. An - intruder can still write to raw disk devices. An enterprising - intruder can use &man.kldload.8; to install his own - bpf, or another sniffing device, on a - running kernel. To avoid these problems, run the kernel at a - higher security level, at least security level 1. + In some cases, system administration access needs to + be shared with other users. &os; has two methods to + handle this. The first one, which is not recommended, + is a shared root password and adding users to the + wheel group. + To achieve this, edit the /etc/group + and add the user to the end of the first group. This + user must be separated by a comma character. + + The correct way to permit this privilege escalation is + using the security/sudo port which will + provide additional auditing, more fine grained user + control, and even lock users into running only single, + privileged commands such as &man.service.8; + + After installation, edit the + /usr/local/etc/sudoers file by using + the visudo interface. In this example, + a new webadmin group will be added, the user + trhodes to that + group, and then give the user + access to restart apache24, the following + procedure may be followed: + + &prompt.root; pw groupadd webadmin -M trhodes -g 6000 + + &prompt.root; visudo + + %webadmin ALL=(ALL) /usr/sbin/service apache24 * + + The security/sudo provides an + invaluable resource when it comes to local user management. + It is also possible to not require passwords and just default + to the &man.ssh.1; key method. To disable password login + via &man.sshd.8; and only use local passwords for + sudo, see . + + + + Passwords + + Passwords are a necessary evil of technology. In the cases + they must be used, not only should the password be extremely + complex, but also use a powerful hash mechanism to protect it. + At the time of this writing, &os; supports + DES, MD5, Blowfish, + SHA256, and SHA512 in + the crypt() library. The default is + SHA512 and should not be changed backwards; + however, some users like to use the Blowfish option. Each + mechanism, aside from DES, has a unique + beginning to designate the hash mechanism assigned. For the + MD5 mechanism, the symbol is a + $ sign. For the SHA256 or + SHA512, the symbol is $6$ + and Blowfish uses $2a$. Any weaker passwords + should be re-hashed by asking the user to run &man.passwd.1; + during their next login. - The security level of the kernel can be set in a variety - of ways. The simplest way of raising the security level of a - running kernel is to set - kern.securelevel: + + At the time of this writing, Blowfish is not part of + AES nor is it considered compliant + with any FIPS (Federal Information + Processing Standards) standard and it's use may not be + permitted in some environments. + - &prompt.root; sysctl kern.securelevel=1 + For any system connected to the network, two factor + authentication should be used. This is normally considered + something you have and something you know. With + OpenSSH being part of the &os; + base system and the use of ssh-keys being available for some + time, all network logins should avoid the use of passwords in + exchange for this two factor authentication method. For + more information see the section of + the handbook. Kerberose users may need to make additional + changes to implement OpenSSH in + their network. + + + + Backdoors and Rootkits + + Backdoors and rootkits are only a threat after they have + been installed. Once installed, this malicious software will + normally open up another avenue of entry for an attacker. + Realistically, once a system has been compromised, and an + investigation has been performed, it should be erased. There + is tremendous risk that even the most prudent security or + systems engineer will miss something an attacker left + behind. + + A backdoor or rootkit software does do one thing useful + for administrators - once detected, it is a sign that a + compromise happened at some point. But normally these types + types of applications are hidden very well. Tools do exist + to detect backdoors and rootkits, one of them is + security/rkhunter. + + After installation the system may be checked using the + following command which will produce a lot of + information: + + &prompt.root; rkhunter -c + + After the process complete, which will require some manual + pressing of the ENTER key, a status message + will be printed to the screen. This message will include the + amount of files checked, suspect files, possible rootkits, + and more. During the check, some generic security warnings may + be produced about hidden files, the + OpenSSH protocol selection, and + occasionally known vulnerable versions of installed software. + These can be handled now or later after a more detailed + analysis has been performed. + + Every administrator should know what is running on the + systems they are responsible for. Using tools like + rkhunter, + lsof and native commands such + as &man.netstat.1; and &man.ps.1; can show a great deal of + information on the system. Take notes on what is normal, + ask questions when something seems out of place and be + paranoid. And remember, preventing a compromise is ideal + but detecting a compromise is a must. + + + + Binary Verification + + Verification of system files and binaries is important + because it provides the system administration and security + team with information about system changes. In any system, + no internal command or application should change without + the system admin team knowing. A software application that + monitors the system for changes is called an Intrusion + Detection System or IDS. + + &os; provides native support for a basic + IDS system. In fact, as part of the nightly + &man.periodic.8; security emails will notify an administrator + of changes. Since the information is stored locally, there is + a change a malicious user could modify and spoof + the information. As such, it is recommended to create a + separate set of binary signatures and store them on a read + only, root owned directory or, preferably, off system such + as a USB disk or + rsync server. + + To being, a seed needs to be generated. This is a numeric + constant that will be used as to help generate the hash values + and to check the hash values. Lacking this seed value will make + faking or checking the checksum values of files difficult it not + impossible. In the following example, the key will be passed + with the flag. First, generate a set of + hashes and checksums for /bin using the + following command: + + &prompt.root; mtree -s 3483151339707503 -c -K cksum,sha256digest -p /bin > bin_chksum_mtree + + This should have produced something similar to: + + &prompt.root; mtree: /bin checksum: 3427012225 + + Viewing the bin_cksum_mtree file + should yield output similar to the following as well: + + # user: root +# machine: dreadnaught +# tree: /bin +# date: Mon Feb 3 10:19:53 2014 + +# . +/set type=file uid=0 gid=0 mode=0555 nlink=1 flags=none +. type=dir mode=0755 nlink=2 size=1024 \ + time=1380277977.000000000 + \133 nlink=2 size=11704 time=1380277977.000000000 \ + cksum=484492447 \ + sha256digest=6207490fbdb5ed1904441fbfa941279055c3e24d3a4049aeb45094596400662a + cat size=12096 time=1380277975.000000000 cksum=3909216944 \ + sha256digest=65ea347b9418760b247ab10244f47a7ca2a569c9836d77f074e7a306900c1e69 + chflags size=8168 time=1380277975.000000000 cksum=3949425175 \ + sha256digest=c99eb6fc1c92cac335c08be004a0a5b4c24a0c0ef3712017b12c89a978b2dac3 + chio size=18520 time=1380277975.000000000 cksum=2208263309 \ + sha256digest=ddf7c8cb92a58750a675328345560d8cc7fe14fb3ccd3690c34954cbe69fc964 + chmod size=8640 time=1380277975.000000000 cksum=2214429708 \ + sha256digest=a435972263bf814ad8df082c0752aa2a7bdd8b74ff01431ccbd52ed1e490bbe7 + + Notice the machine's hostname, the current date and time, + and the user who executed &man.mtree.8; are all included in + this report. There is also a checksum, size, time and + SHA256 digest for each binary that was + found. + + To verify binary signatures, the following command will + read in the current list of signatures and provide an + output: + + &prompt.root; mtree -s 3483151339707503 -p /bin < bin_chksum_mtree >> bin_chksum_output + + This should produce the same checksum for + /bin that was produced when the command + was originally ran. Since no changes occurred in the time these + commands were ran, the bin_chksum_output + output will be empty. To simulate a change, change the date + on the /bin/cat file using + &man.touch.1; and run the verification command again: + + &prompt.root; touch /bin/cat + &prompt.root; mtree -s 3483151339707503 -p /bin < bin_chksum_mtree >> bin_chksum_output + &prompt.root; cat bin_chksum_output + cat changed + modification time expected Fri Sep 27 06:32:55 2013 found Mon Feb 3 10:28:43 2014 + + More advanced IDS systems exist, such as + security/aide but in most cases, + &man.mtree.8; provides the functionality administrators need. + It is important to keep the seed value and the checksum output + hidden from malicious users. + + + + System Tuning for Security + + Many of the systems features may be tuned through the use + of &man.sysctl.8;. This is also true for a few security + features which could be used to prevent denial of service + (DOS) style attacks. Some of the more + important will be covered here. Any time a setting is changed + with &man.sysctl.8;, the chance to cause undesired harm is + increased affecting the availability of the system. Considering + the CIA of the system should be done during + any system-wide configuration change. + + The following is a list of &man.sysctl.8;'s and a short + description of what effects the changes will have on the + system. By default, the &os; kernel boots with a security level of -1. This is called insecure mode because @@ -451,413 +472,58 @@ unless it is altered, either by the administrator or by &man.init.8;, because of a setting in the startup scripts. The security level may be raised during system startup by - setting - kern_securelevel_enable to + setting kern_securelevel_enable to YES in /etc/rc.conf, and the value of kern_securelevel to the - desired security level. - - Once the security level is set to 1 or a higher value, the - append-only and immutable files are honored, they cannot be - turned off, and access to raw devices is denied. Higher - levels restrict even more operations. For a full description - of the effect of various security levels, refer to - &man.security.7; and &man.init.8;. - - - Bumping the security level to 1 or higher may cause a - few problems to &xorg;, as access - to /dev/io will be blocked, or to the - installation of &os; built from source as - installworld needs to temporarily - reset the append-only and immutable flags of some files. - In the case of &xorg;, it may be - possible to work around this by starting &man.xdm.1; early - in the boot process, when the security level is still low - enough. Workarounds may not be possible for all secure - levels or for all the potential restrictions they enforce. - A bit of forward planning is a good idea. Understanding the - restrictions imposed by each security level is important as - they severely diminish the ease of system use. It will also - make choosing a default setting much simpler and prevent any - surprises. - - - If the kernel's security level is raised to 1 or a higher - value, it may be useful to set the schg - flag on critical startup binaries, directories, script files, - and everything that gets run up to the point where the - security level is set. A less strict compromise is to run - the system at a higher security level but skip setting the - schg flag. Another possibility is to - mount / and /usr read-only. It should be - noted that being too draconian about what is permitted may - prevent detection of an intrusion. - - - - Checking File Integrity - - One can only protect the core system configuration and - control files so much before the convenience factor rears its - ugly head. For example, using &man.chflags.1; to set the - schg bit on most of the files in / and /usr is probably - counterproductive, because while it may protect the files, it - also closes an intrusion detection window. Security measures - are useless or, worse, present a false sense of security, if - potential intrusions cannot be detected. Half the job of - security is to slow down, not stop, an attacker, in order to - catch him in the act. - - The best way to detect an intrusion is to look for - modified, missing, or unexpected files. The best way to look - for modified files is from another, often centralized, - limited-access system. Writing security scripts on the - extra-security limited-access system makes them mostly - invisible to potential attackers. In order to take maximum - advantage, the limited-access box needs significant access to - the other machines, usually either through a read-only - NFS export or by setting up - &man.ssh.1; key-pairs. Except for its network traffic, - NFS is the least visible method, allowing - the administrator to monitor the filesystems on each client - box virtually undetected. If a limited-access server is - connected to the client boxes through a switch, the - NFS method is often the better choice. If - a limited-access server is connected to the client boxes - through several layers of routing, the NFS - method may be too insecure and &man.ssh.1; may be the better - choice. - - Once a limited-access box has been given at least read - access to the client systems it is supposed to monitor, create - the monitoring scripts. Given an NFS - mount, write scripts out of simple system utilities such as - &man.find.1; and &man.md5.1;. It is best to physically - &man.md5.1; the client system's files at least once a day, and - to test control files such as those found in /etc and /usr/local/etc even more often. - When mismatches are found, relative to the base md5 - information the limited-access machine knows is valid, it - should alert the sysadmin. A good security script will also - check for inappropriate SUID binaries and for new or deleted - files on system partitions such as / and /usr. - - When using &man.ssh.1; rather than NFS, - writing the security script is more difficult. For example, - &man.scp.1; is needed to send the scripts to the client box in - order to run them. The &man.ssh.1; client on the client box - may already be compromised. Using &man.ssh.1; may be - necessary when running over insecure links, but it is harder - to deal with. - - A good security script will also check for changes to - hidden configuration files, such as - .rhosts and - .ssh/authorized_keys, as these files - might fall outside the purview of the - MD5 check. - - For a large amount of user disk space, it may take too - long to run through every file on those partitions. In this - case, consider setting mount flags to disallow SUID binaries - by using nosuid with &man.mount.8;. Scan - these partitions at least once a week, since the objective is - to detect a break-in attempt, whether or not the attempt - succeeds. - - Process accounting (see &man.accton.8;) is a relatively - low-overhead feature of &os; which might help as a - post-break-in evaluation mechanism. It is especially useful - in tracking down how an intruder broke into a system, assuming - the file is still intact after the break-in has - occurred. - - Finally, security scripts should process the log files, - and the logs themselves should be generated in as secure a - manner as possible and sent to a remote syslog server. An - intruder will try to cover his tracks, and log files are - critical to the sysadmin trying to track down the time and - method of the initial break-in. One way to keep a permanent - record of the log files is to run the system console to a - serial port and collect the information to a secure machine - monitoring the consoles. - - - - Paranoia - - A little paranoia never hurts. As a rule, a sysadmin can - add any number of security features which do not affect - convenience and can add security features that - do affect convenience with some added - thought. More importantly, a security administrator should - mix it up a bit. If recommendations, such as those mentioned - in this section, are applied verbatim, those methodologies are - given to the prospective attacker who also has access to this - document. - - - - Denial of Service Attacks - - - Denial of Service (DoS) - - - A DoS attack is typically a packet - attack. While there is not much one can do about spoofed - packet attacks that saturate a network, one can generally - limit the damage by ensuring that the attack cannot take down - servers by: - - - - Limiting server forks. - - - - Limiting springboard attacks such as ICMP response - attacks and ping broadcasts. - - - - Overloading the kernel route cache. - - - - A common DoS attack scenario is to - force a forking server to spawn so many child processes that - the host system eventually runs out of memory and file - descriptors, and then grinds to a halt. There are several - options to &man.inetd.8; to limit this sort of attack. It - should be noted that while it is possible to prevent a machine - from going down, it is not generally possible to prevent a - service from being disrupted by the attack. Read - &man.inetd.8; carefully and pay specific attention to - , , and - . Spoofed IP attacks will circumvent - to &man.inetd.8;, so typically a - combination of options must be used. Some standalone servers - have self-fork-limitation parameters. - - Sendmail provides - , which tends to work - better than trying to use - Sendmail's load limiting options - due to the load lag. Specify a - MaxDaemonChildren when starting - Sendmail which is high enough to - handle the expected load, but not so high that the computer - cannot handle that number of - Sendmail instances. It is prudent - to run Sendmail in queued mode - using and to run the - daemon (sendmail -bd) separate from the - queue-runs (sendmail -q15m). For - real-time delivery, run the queue at a much lower interval, - such as , but be sure to specify a - reasonable MaxDaemonChildren to prevent - cascade failures. - - &man.syslogd.8; can be attacked directly and it is - strongly recommended to use - whenever possible, and - otherwise. - - Be careful with connect-back services such as - reverse-identd, which can be attacked directly. The - reverse-ident feature of - TCP Wrappers is not recommended for - this reason. - - It is recommended to protect internal services from - external access by firewalling them at the border routers. - This is to prevent saturation attacks from outside the LAN, - not so much to protect internal services from network-based - root compromise. Always configure an - exclusive firewall which denies everything by default except - for traffic which is explicitly allowed. The range of port - numbers used for dynamic binding in &os; is controlled by - several net.inet.ip.portrange - &man.sysctl.8; variables. - - Another common DoS attack, called a - springboard attack, causes the server to generate responses - which overloads the server, the local network, or some other - machine. The most common attack of this nature is the - ICMP ping broadcast attack. The attacker - spoofs ping packets sent to the LAN's broadcast address with - the source IP address set to the machine to attack. If the - border routers are not configured to drop ping packets sent to - broadcast addresses, the LAN generates sufficient responses to - the spoofed source address to saturate the victim, especially - when the attack is against several dozen broadcast addresses - over several dozen different networks at once. A second - common springboard attack constructs packets that generate - ICMP error responses which can saturate a server's incoming - network and cause the server to saturate its outgoing network - with ICMP responses. This type of attack can crash the - server by running it out of memory, especially if the server - cannot drain the ICMP responses it generates fast enough. Use - the &man.sysctl.8; variable - net.inet.icmp.icmplim to limit these - attacks. The last major class of springboard attacks is - related to certain internal &man.inetd.8; services such as the - UDP echo service. An attacker spoofs a UDP packet with a - source address of server A's echo port and a destination - address of server B's echo port, where server A and B on the - same LAN. The two servers bounce this one packet back and - forth between each other. The attacker can overload both - servers and the LAN by injecting a few packets in this manner. - Similar problems exist with the - chargen port. These inetd-internal - test services should remain disabled. - - Spoofed packet attacks may be used to overload the kernel - route cache. Refer to the - net.inet.ip.rtexpire, - rtminexpire, and - rtmaxcache &man.sysctl.8; parameters. A - spoofed packet attack that uses a random source IP will cause - the kernel to generate a temporary cached route in the route *** DIFF OUTPUT TRUNCATED AT 1000 LINES ***