From owner-freebsd-doc@FreeBSD.ORG Sun Feb 2 22:51:30 2014 Return-Path: Delivered-To: doc@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 03007AE3 for ; Sun, 2 Feb 2014 22:51:30 +0000 (UTC) Received: from homiemail-a97.g.dreamhost.com (caiajhbdccac.dreamhost.com [208.97.132.202]) by mx1.freebsd.org (Postfix) with ESMTP id DBA9C1813 for ; Sun, 2 Feb 2014 22:51:29 +0000 (UTC) Received: from homiemail-a97.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a97.g.dreamhost.com (Postfix) with ESMTP id B76FF286057 for ; Sun, 2 Feb 2014 14:51:23 -0800 (PST) Received: from dreadnaught (ip68-100-185-59.dc.dc.cox.net [68.100.185.59]) (Authenticated sender: trhodes@fbsdsecure.org) by homiemail-a97.g.dreamhost.com (Postfix) with ESMTPA id C42BA286058 for ; Sun, 2 Feb 2014 14:51:22 -0800 (PST) Date: Sun, 2 Feb 2014 17:51:21 -0500 From: Tom Rhodes To: doc@FreeBSD.org Subject: Patch (WIP): New security front matter; new shell redirection section Message-Id: <20140202175121.16a0c264.trhodes@FreeBSD.org> X-Mailer: Sylpheed version 1.0.6 (GTK+ 1.2.10; x86_64-unknown-freebsd9.2) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-doc@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Documentation project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Feb 2014 22:51:30 -0000 Hi, After talking to a few people, I've written up two new sections, one is a huge cleanup of the security chapter and the second adds a shell redirection section to the handbook. Right now I'm seeking some comments and suggestions here. Want to commit sometime this week. Cheers, -- Tom Rhodes Index: handbook/basics/chapter.xml =================================================================== --- handbook/basics/chapter.xml (revision 43727) +++ handbook/basics/chapter.xml (working copy) @@ -987,7 +987,7 @@ pw - &man.pw.8; is a command line utility to create, remove, + The &man.pw.8; command line utility can create, remove, modify, and display users and groups. It functions as a front end to the system user and group files. &man.pw.8; has a very powerful set of command line options that make it @@ -3432,6 +3432,79 @@ Then, rerun &man.chsh.1;. + + + + Advanced Shell Techniques + + + + + Tom + Rhodes + + Written by + + + + + The &unix; shell is not just a command interpreter, it + acts as a powerful tool which allows users to execute commands, + redirect their output, redirect their input and chain commands + together to improve the final command output. When this functionality + is mixed with built in commands, the user is provided with + an environment that can maximize efficiency. + + Shell redirection is the action of sending the output + or the input of a command into another command or into a + file. To capture the output of the &man.ls.1; command, for + example, into a file, simply redirect the output: + + &prompt.user; ls > directory_listing.txt + + The directory_listing.txt file will + now contain the directory contents. Some commands allow you + to read input in a similar one, such as &man.sort.1;. To sort + this listing, redirect the input: + + &prompt.user; sort < directory_listing.txt + + The input will be sorted and placed on the screen. To + redirect that input into another file, one could redirect + the output of &man.sort.1; by mixing the direction: + + &prompt.user; sort < directory_listing.txt > sorted.txt + + In all of the previous examples, the commands are performing + redirection using file descriptors. Every unix system has file + descriptors; however, here we will focus on three, so named as + Standard Input, Standard Output, and Standard Error. Each one + has a purpose, where input could be a keyboard or a mouse, + something that provides input. Output could be a screen or + paper in a printer for example. And error would be anything + that is used for diagnostic or error messages. All three + are considered I/O based file descriptors + and sometimes considered streams. + + Through the use of these descriptors, short named + stdin, stdout, and stderr, the shell allows output and + input to be passed around through various commands and + redirected to or from a file. Another method of redirection + is the pipe operator. + + The &unix; pipe operator, | allows the + output of one command to be directly passed, or directed + to another program. Basically a pipe will allow the + standard output of a command to be passed as standard + input to another command, for example: + + &prompt.user; du -h | less + + In that example, the &man.du.1; command will direct the + output to the &man.less.1; command. This allows the user + to scroll through the output at their own pace and prevent + it from scrolling off the screen. + Index: handbook/security/chapter.xml =================================================================== --- handbook/security/chapter.xml (revision 43727) +++ handbook/security/chapter.xml (working copy) @@ -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. + 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. - &os; provides an array of utilities and mechanisms to - protect the integrity and security of the system and - network. + 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,758 +113,202 @@ 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. + 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. - 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: + 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, and they expect + access to information at all times. Together they make up the + confidentiality, integrity, and availability of the + system. - - - Denial of service attacks. - + 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. - - User account compromises. - + + Threats - - Root compromise through accessible services. - + 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. - - Root compromise via user accounts. - + 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. + - - Backdoor creation. - - + + A Ground Up Approach - - DoS attacks - Denial of Service (DoS) - - - security - DoS attacks - Denial of Service (DoS) - - Denial of Service (DoS) + 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. - 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. + 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. + - - security - account compromises - + + System and User Accounts - 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 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. - 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. + To deny access to accounts, two methods exist. The first + one is to lock an account, for example, to lock the toor + account: - - security - backdoors - + &prompt.root; pw lock toor - 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. + 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: - Security remedies should always be implemented with a - multi-layered onion peel approach and can be - categorized as follows: + 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: - - - Secure root and staff - accounts. - + &prompt.root; chsh -s /usr/sbin/nologin toor - - Secure root–run servers - and SUID/SGID binaries. - + + Only super users are able to change the shell for + other users. Attempting to perform this as a regular user + will fail. + - - Secure user accounts. - + The account structure will now look like this, with + the nologin shell as the last entry: - - Secure the password file. - + toor:*:0:0::0:0:Bourne-again Superuser:/root:/usr/sbin/nologin - - Secure the kernel core, raw devices, and - filesystems. - + The /usr/sbin/nologin shell will block + the &man.login.1; command from assigning a shell to this + user. + - - Quick detection of inappropriate changes made to the - system. - + + Permitted Account Escalation - - Paranoia. - - + 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 next section covers these items in greater depth. - + 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; - - Securing &os; + 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: - - security - securing &os; - + &prompt.root; pw groupadd webadmin -M trhodes -g 6000 - This section describes methods for securing a &os; system - against the attacks that were mentioned in the previous section. + &prompt.root; visudo - - Securing the <systemitem class="username">root</systemitem> Account + %webadmin ALL=(ALL) /usr/sbin/service apache24 * - - &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 - account: - - foobar:R9DT/Fa1/LV9U:1000:1000::0:0:Foo Bar:/home/foobar:/usr/local/bin/tcsh - - could be changed to this using &man.vipw.8;: - - foobar:*:1000:1000::0:0:Foo Bar:/home/foobar:/usr/local/bin/tcsh - - 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 - - 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. - - Security scripts should be used to check for and report - changes to the password file as described in the Checking file integrity + 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 the section. - - Securing the Kernel Core, Raw Devices, and - Filesystems + + Passwords - 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. + Passwords are a necessary evil of the past. 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. - - &man.sysctl.8; - - - 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. - - 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: - - &prompt.root; sysctl kern.securelevel=1 - - By default, the &os; kernel boots with a security level of - -1. This is called insecure mode because - immutable file flags may be turned off and all devices may be - read from or written to. The security level will remain at -1 - 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 - 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. + 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. - 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. + 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. - - - 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 - table, viewable with netstat -rna | fgrep - W3. These routes typically timeout in 1600 - seconds or so. If the kernel detects that the cached route - table has gotten too big, it will dynamically reduce the - rtexpire but will never decrease it to less - than rtminexpire. This creates two - problems: - - - - - The kernel does not react quickly enough when a - lightly loaded server is suddenly attacked. - - - - The rtminexpire is not low enough - for the kernel to survive a sustained attack. - - - - If the servers are connected to the Internet via a T3 or - better, it may be prudent to manually override both - rtexpire and rtminexpire - via &man.sysctl.8;. Never set either parameter to zero - as this could crash the machine. Setting both parameters to 2 - seconds should be sufficient to protect the route table from - attack. - - - - Access Issues with Kerberos and &man.ssh.1; - - &man.ssh.1; - - There are a few issues with both Kerberos and &man.ssh.1; - that need to be addressed if they are used. Kerberos is an - excellent authentication protocol, but there are bugs in the - kerberized versions of &man.telnet.1; and &man.rlogin.1; that - make them unsuitable for dealing with binary streams. By - default, Kerberos does not encrypt a session unless - is used whereas &man.ssh.1; encrypts - everything. - - While &man.ssh.1; works well, it forwards encryption keys - by default. This introduces a security risk to a user who - uses &man.ssh.1; to access an insecure machine from a secure - workstation. The keys themselves are not exposed, but - &man.ssh.1; installs a forwarding port for the duration of the - login. If an attacker has broken root on - the insecure machine, he can utilize that port to gain access - to any other machine that those keys unlock. - - It is recommended that &man.ssh.1; is used in combination - with Kerberos whenever possible for staff logins and - &man.ssh.1; can be compiled with Kerberos support. This - reduces reliance on potentially exposed SSH - keys while protecting passwords via Kerberos. Keys should - only be used for automated tasks from secure machines as this - is something that Kerberos is unsuited to. It is recommended - to either turn off key-forwarding in the - SSH configuration, or to make use - of from=IP/DOMAIN in - authorized_keys to make the key only - usable to entities logging in from specific machines. - - - DES, Blowfish, MD5, SHA256, SHA512, and Crypt - - BillSwingleParts rewritten and updated by - - - - - - - - security - crypt - - - crypt - Blowfish - DES - MD5 - SHA256 - SHA512 - - Every user on a &unix; system has a password associated with - their account. In order to keep these passwords secret, they - are encrypted with a one-way hash, as they can - be easily encrypted but not decrypted. The operating system - itself does not know the password. It only knows the - encrypted form of the password. The only - way to get the plain-text password is by a brute - force search of the space of possible passwords. - - Originally, the only secure way to encrypt passwords in - &unix; was based on the Data Encryption Standard - (DES). Since the source code for - DES could not be exported outside the US, - &os; had to find a way to both comply with US law and retain - compatibility with other &unix; variants that used - DES. The solution was MD5 which is believed - to be more secure than DES. - - - Recognizing the Crypt Mechanism - - Currently the library supports DES, - MD5, Blowfish, SHA256, and SHA512 hash functions. To identify - which encryption method &os; is set up to use, examine the - encrypted passwords in - /etc/master.passwd. Passwords encrypted - with the MD5 hash are longer than those encrypted with the - DES hash and begin with the characters - $1$. Passwords starting with - $2a$ are encrypted with the - Blowfish hash function. DES password - strings do not have any particular identifying - characteristics, but they are shorter than MD5 passwords, and - are coded in a 64-character alphabet which does not include - the $ character, so a relatively - short string which does not begin with a dollar sign is very - likely a DES password. Both SHA256 and - SHA512 begin with the characters - $6$. - - The password format used for new passwords is controlled - by the passwd_format login capability in - /etc/login.conf, which takes values of - des, md5, - blf, sha256 or - sha512. Refer to &man.login.conf.5; for - more information about login capabilities. - - - One-time Passwords @@ -1970,6 +1419,44 @@ + Access Issues with Kerberos and &man.ssh.1; + + &man.ssh.1; + + There are a few issues with both Kerberos and &man.ssh.1; + that need to be addressed if they are used. Kerberos is an + excellent authentication protocol, but there are bugs in the + kerberized versions of &man.telnet.1; and &man.rlogin.1; that + make them unsuitable for dealing with binary streams. By + default, Kerberos does not encrypt a session unless + is used whereas &man.ssh.1; encrypts + everything. + + While &man.ssh.1; works well, it forwards encryption keys + by default. This introduces a security risk to a user who + uses &man.ssh.1; to access an insecure machine from a secure + workstation. The keys themselves are not exposed, but + &man.ssh.1; installs a forwarding port for the duration of the + login. If an attacker has broken + root on + the insecure machine, he can utilize that port to gain access + to any other machine that those keys unlock. + + It is recommended that &man.ssh.1; is used in combination + with Kerberos whenever possible for staff logins and + &man.ssh.1; can be compiled with Kerberos support. This + reduces reliance on potentially exposed SSH + keys while protecting passwords via Kerberos. Keys should + only be used for automated tasks from secure machines as this + is something that Kerberos is unsuited to. It is recommended + to either turn off key-forwarding in the + SSH configuration, or to make use + of from=IP/DOMAIN in + authorized_keys to make the key only + usable to entities logging in from specific machines. + + + Resources and Further Information