From 5d5655b8c2c49789195d307df934e04257e3f224 Mon Sep 17 00:00:00 2001 From: Dima Dorfman Date: Tue, 14 Aug 2001 06:30:58 +0000 Subject: [PATCH] Assorted punctuation, grammar, and typo fixes. PR: 29566 Submitted by: John Murphy --- .../books/handbook/security/chapter.sgml | 157 +++++++++--------- 1 file changed, 79 insertions(+), 78 deletions(-) diff --git a/en_US.ISO8859-1/books/handbook/security/chapter.sgml b/en_US.ISO8859-1/books/handbook/security/chapter.sgml index 089d6a3ccf..f8e65fbcc3 100644 --- a/en_US.ISO8859-1/books/handbook/security/chapter.sgml +++ b/en_US.ISO8859-1/books/handbook/security/chapter.sgml @@ -1,7 +1,7 @@ @@ -58,8 +58,8 @@ at all. 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 break root. Security concerns + attack, including attacks that attempt to crash, or otherwise make a + system unusable, but do not attempt to break root. Security concerns can be split up into several categories: @@ -99,13 +99,13 @@ machine of needed resources. Typically, D.O.S. attacks are brute-force mechanisms that attempt to crash or otherwise make a machine unusable by overwhelming its servers or network stack. Some - D.O.S. attacks try to take advantages of bugs in the networking + D.O.S. attacks try to take advantage of bugs in the networking stack to crash a machine with a single packet. The latter can only be fixed by applying a bug fix to the kernel. 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. A - spoofed-packet attack, for example, is nearly impossible to stop + spoofed-packet attack, for example, is nearly impossible to stop, short of cutting your system off from the Internet. It may not be able to take your machine down, but it can saturate your Internet connection. @@ -132,7 +132,7 @@ account does not necessarily give the attacker access to root. The distinction is important because without access to root 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. + nothing more than mess with the user's files, or crash the machine. User account compromises are very common because users tend not to take the precautions that sysadmins take. @@ -152,11 +152,11 @@ to install a backdoor. Many of the root holes found and closed to date involve a considerable amount of work by the attacker to cleanup after himself, so most attackers install - backdoors. Backdoors provide the attacker with a way to easily + backdoors. A backdoor provides the attacker with a way to easily regain root access to the system, but it also gives the smart system administrator a convenient way to detect the intrusion. Making it impossible for an attacker to install a backdoor may - actually be detrimental to your security because it will not + actually be detrimental to your security, because it will not close off the hole the attacker found to break in the first place. @@ -301,7 +301,7 @@ guarantees that staff members can only login through secure access methods that you have setup. This forces all staff members to use secure, encrypted connections for all of their - sessions which closes an important hole used by many + sessions, which closes an important hole used by many intruders: That of sniffing the network from an unrelated, less secure machine. @@ -314,16 +314,16 @@ you should run a password-protected screen blanker. Of course, given physical access to a workstation an attacker can break any sort of security you put on it. This is definitely a problem that - you should consider but you should also consider the fact that the + you should consider, but you should also consider the fact that the vast majority of break-ins occur remotely, over a network, from people who do not have physical access to your workstation or servers. Kerberos Using something like kerberos also gives you the ability to - disable or change the password for a staff account in one place - and have it immediately effect all the machine the staff member - may have an account on. If a staff member's account gets + disable or change the password for a staff account in one place, + and have it immediately effect all the machines on which the staff + member may have an account. If a staff member's account gets compromised, the ability to instantly change his password on all machines should not be underrated. With discrete passwords, changing a password on N machines can be a mess. You can also @@ -370,7 +370,7 @@ example, the ntalk, comsat, and finger daemons can be run in special - user sandboxes. A sandbox isn't perfect unless + user sandboxes. A sandbox is not perfect, unless you go to a large amount of trouble, but the onion approach to security still stands: If someone is able to break in through a server running in a sandbox, they still have to break out of the @@ -410,7 +410,7 @@ run these servers as root and rely on other mechanisms to detect break-ins that might occur through them. - The other big potential root hole in a system are the + The other big potential root holes in a system are the suid-root and sgid binaries installed on the system. Most of these binaries, such as rlogin, reside in /bin, /sbin, @@ -421,12 +421,12 @@ Xlib in 1998 that made xterm (which is typically suid) vulnerable. It is better to be safe than sorry and the prudent - sysadmin will restrict suid binaries that only staff should run to - a special group that only staff can access, and get rid of + sysadmin will restrict suid binaries, that only staff should run, + to a special group that only staff can access, and get rid of (chmod 000) any suid binaries that nobody uses. A server with no display generally does not need an xterm binary. Sgid binaries can be - almost as dangerous. If an intruder can break an sgid-kmem binary + 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 crypted password file, potentially compromising any passworded account. Alternatively an intruder who breaks @@ -446,11 +446,11 @@ you can impose Draconian access restrictions on your staff and * out their passwords, you may not be able to do so with any general user accounts you might have. If you do - have sufficient control then you may win out and be able to secure + have sufficient control, then you may win out and be able to secure the user accounts properly. If not, you simply have to be more vigilant in your monitoring of those accounts. Use of ssh and kerberos for user accounts is - more problematic due to the extra administration and technical + more problematic, due to the extra administration and technical support required, but still a very good solution compared to a crypted password file. @@ -492,8 +492,8 @@ to worry about. For that matter, the intruder can still write to raw disk devices. Also, there is another kernel feature called the module loader, &man.kldload.8;. An enterprising intruder can - use a KLD module to install his own bpf device or other sniffing - device on a running kernel. To avoid these problems you have to + use a KLD module to install his own bpf device, or other sniffing + device, on a running kernel. To avoid these problems you have to run the kernel at a higher secure level, at least securelevel 1. The securelevel can be set with a sysctl on the kern.securelevel variable. Once you have @@ -523,13 +523,13 @@ convenience factor rears its ugly head. For example, using chflags to set the schg bit on most of the files in / and - /usr is probably counterproductive because + /usr is probably counterproductive, because while it may protect the files, it also closes a detection window. The last layer of your security onion is perhaps the most important – detection. The rest of your security is pretty much useless (or, worse, presents you with a false sense of safety) if you cannot detect potential incursions. Half the job - of the onion is to slow down the attacker rather than stop him in + of the onion is to slow down the attacker, rather than stop him, in order to give the detection side of the equation a chance to catch him in the act. @@ -543,28 +543,28 @@ other machines in the business, usually either by doing a read-only NFS export of the other machines to the limited-access box, or by setting up ssh key-pairs to - allow the limit-access box to ssh to + allow the limited-access box to ssh to the other machines. Except for its network traffic, NFS is the least visible method – allowing you to monitor the filesystems on each client box virtually undetected. If your limited-access server is connected to the client boxes through a switch, the NFS method is often the better choice. If your limited-access server is connected to the client boxes through a - hub or through several layers of routing, the NFS method may be + hub, or through several layers of routing, the NFS method may be too insecure (network-wise) and using ssh may be the better choice even with the audit-trail tracks that ssh lays. - Once you give a limit-access box at least read access to the + Once you give a limited-access box, at least read access to the client systems it is supposed to monitor, you must write scripts to do the actual monitoring. Given an NFS mount, you can write scripts out of simple system utilities such as &man.find.1; and &man.md5.1;. It is best to physically md5 the client-box files - boxes at least once a day, and to test control files such as those + 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 + mismatches are found, relative to the base md5 information the limited-access machine knows is valid, it should scream at a sysadmin to go check it out. A good security script will also check for inappropriate suid binaries and for new or deleted files @@ -579,7 +579,7 @@ scripts use. The ssh daemon on the client box may already be compromised. All in all, using ssh may be necessary when running over - unsecure links, but it's also a lot harder to deal with. + unsecure links, but it is also a lot harder to deal with. A good security script will also check for changes to user and staff members access configuration files: @@ -588,12 +588,12 @@ files that might fall outside the purview of the MD5 check. - If you have a huge amount of user disk space it may take too + If you have a huge amount of user disk space, it may take too long to run through every file on those partitions. In this case, setting mount flags to disallow suid binaries and devices on those partitions is a good idea. The nodev and nosuid options (see &man.mount.8;) are what you - want to look into. You should probably scan them anyway at least + want to look into. You should probably scan them anyway, at least once a week, since the object of this layer is to detect a break-in whether or not the break-in is effective. @@ -604,7 +604,7 @@ a system, assuming the file is still intact after the break-in occurs. - Finally, security scripts should process the log files and the + Finally, security scripts should process the log files, and the logs themselves should be generated in as secure a manner as possible – remote syslog can be very useful. An intruder tries to cover his tracks, and log files are critical to the @@ -619,13 +619,13 @@ Paranoia A little paranoia never hurts. As a rule, a sysadmin can add - any number of security features as long as they do not effect - convenience, and can add security features that do effect - convenience with some added thought. Even more importantly, a - security administrator should mix it up a bit – if you use - recommendations such as those given by this document verbatim, you - give away your methodologies to the prospective attacker who also - has access to this document. + any number of security features, as long as they do not effect + convenience, and can add security features that + do effect convenience with some added thought. + Even more importantly, a security administrator should mix it up a + bit – if you use recommendations such as those given by this + document verbatim, you give away your methodologies to the + prospective attacker who also has access to this document. @@ -654,10 +654,10 @@ A common DoS attack is against a forking server that attempts - to cause the server to eat processes, file descriptors, and memory + to cause the server to eat processes, file descriptors, and memory, until the machine dies. Inetd (see &man.inetd.8;) has several options to limit this sort of attack. It should be noted that - while it is possible to prevent a machine from going down it is + 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 the inetd manual page carefully and pay specific attention to the , , @@ -667,12 +667,12 @@ servers have self-fork-limitation parameters. Sendmail has its - option which tends to work + option, which tends to work much better than trying to use sendmail's load limiting options due to the load lag. You should specify a - MaxDaemonChildren parameter when you start - sendmail high enough to handle your - expected load but no so high that the computer cannot handle that + MaxDaemonChildren parameter, when you start + sendmail, high enough to handle your + expected load, but not so high that the computer cannot handle that number of sendmails without falling on its face. It is also prudent to run sendmail in queued mode () and to run the daemon @@ -680,8 +680,9 @@ (sendmail -q15m). If you still want real-time delivery you can run the queue at a much lower interval, such as , but be sure to specify a reasonable - MaxDaemonChildren option for that sendmail to - prevent cascade failures. + MaxDaemonChildren option for + that sendmail to prevent cascade failures. + Syslogd can be attacked directly and it is strongly recommended that you use the @@ -708,17 +709,17 @@ services. If you try to configure the firewall the other way – as an inclusive or permissive firewall, there is a good chance that you will forget to close a couple of - services or that you will add a new internal service and forget + services, or that you will add a new internal service and forget to update the firewall. You can still open up the high-numbered - port range on the firewall to allow permissive-like operation + port range on the firewall, to allow permissive-like operation, without compromising your low ports. Also take note that FreeBSD allows you to control the range of port numbers used for dynamic - binding via the various net.inet.ip.portrange + binding, via the various net.inet.ip.portrange sysctl's (sysctl -a | fgrep portrange), which can also ease the complexity of your firewall's configuration. For example, you might use a normal first/last range of 4000 to 5000, and a hiport range of 49152 to - 65535, then block everything under 4000 off in your firewall + 65535, then block off everything under 4000 in your firewall (except for certain specific Internet-accessible ports, of course). @@ -783,10 +784,10 @@ If your servers are connected to the Internet via a T3 or - better it may be prudent to manually override both + better, it may be prudent to manually override both rtexpire and rtminexpire via &man.sysctl.8;. Never set either parameter to zero (unless - you want to crash the machine. Setting both + you want to crash the machine). Setting both parameters to 2 seconds should be sufficient to protect the route table from attack. @@ -799,7 +800,7 @@ There are a few issues with both kerberos and ssh that need to be addressed if you intend to use them. Kerberos V is an excellent - authentication protocol but there are bugs in the kerberized + authentication protocol, but there are bugs in the kerberized telnet and rlogin applications that make them unsuitable for dealing with binary streams. Also, by default @@ -814,7 +815,7 @@ ssh to an unsecure machine, your keys becomes exposed. The actual keys themselves are not exposed, but ssh installs a forwarding port for the - duration of your login and if a attacker has broken root on the + duration of your login, and if an attacker has broken root on the unsecure machine he can utilize that port to use your keys to gain access to any other machine that your keys unlock. @@ -872,11 +873,11 @@ Unfortunately the only secure way to encrypt passwords when Unix came into being was based on DES, the Data Encryption - Standard. This is not such a problem for users that live in + Standard. This was not such a problem for users resident in the US, but since the source code for DES could not be exported outside the US, FreeBSD had to find a way to both comply with US law and retain compatibility with all the other Unix - variants that still use DES. + variants that still used DES. The solution was to divide up the encryption libraries so that US users could install the DES libraries and use @@ -892,7 +893,7 @@ It is pretty easy to identify which encryption method FreeBSD is set up to use. Examining the encrypted passwords in the /etc/master.passwd file is one way. - Passwords encrypted with the MD5 hash are longer than those with + Passwords encrypted with the MD5 hash are longer than those encrypted with the DES hash and also begin with the characters $1$. DES password strings do not have any particular identifying characteristics, but they are @@ -911,7 +912,7 @@ Identifying which library is being used by the programs on your system is easy as well. Any program that uses crypt is linked - against libcrypt which for each type of library is a symbolic link + against libcrypt, which for each type of library is a symbolic link to the appropriate implementation. For example, on a system using the DES versions: @@ -995,7 +996,7 @@ lrwxr-xr-x 1 root wheel 15 Mar 19 06:56 libcrypt_p.a -> libdescrypt_p.akey program accepts an iteration count, a seed, and a secret password, and generates a one-time password. The keyinit program is used - to initialized S/Key, and to change passwords, iteration counts, or + to initialize S/Key, and to change passwords, iteration counts, or seeds; it takes either a secret password, or an iteration count, seed, and one-time password. The keyinfo program examines the /etc/skeykeys file and prints out @@ -1290,7 +1291,7 @@ README krb.conf krb.realms If any additional files (such as principal.* or master_key) exist, then use the kdb_destroy command to destroy the old Kerberos - database, of if Kerberos is not running, simply delete the extra + database, or if Kerberos is not running, simply delete the extra files. You should now edit the krb.conf and @@ -1458,7 +1459,7 @@ Master key entered. BEWARE! Generating 'grunt-new-srvtab'.... Now, this command only generates a temporary file which must be - renamed to srvtab so that all the server can pick + renamed to srvtab so that all the servers can pick it up. Use the mv command to move it into place on the original system: @@ -1996,7 +1997,7 @@ FreeBSD BUILT-19950429 (GR386) #0: Sat Apr 29 17:50:09 SAT 1995 separate firewall and accounting entries. The present version provides packet accounting with each firewall entry. - If an index value is supplied, it used to + If an index value is supplied, it is used to place the entry at a specific point in the chain. Otherwise, the entry is placed at the end of the chain at an index 100 greater than the last chain entry (this does not include the default policy, rule @@ -2210,7 +2211,7 @@ FreeBSD BUILT-19950429 (GR386) #0: Sat Apr 29 17:50:09 SAT 1995 Matches if the packet is an attempt to establish a TCP - connection (the SYN bit set is set but the ACK bit is + connection (the SYN bit is set but the ACK bit is not). @@ -2389,7 +2390,7 @@ FreeBSD BUILT-19950429 (GR386) #0: Sat Apr 29 17:50:09 SAT 1995 through the firewall, so large FTP/http transfers, etc, will really slow the system down. It also increases the latencies on those packets as it requires more work to be done by the kernel before the - packet can be passed on. syslogd with also start using up a lot + packet can be passed on. syslogd will also start using up a lot more processor time as it logs all the extra data to disk, and it could quite easily fill the partition /var/log is located on. @@ -2424,12 +2425,12 @@ FreeBSD BUILT-19950429 (GR386) #0: Sat Apr 29 17:50:09 SAT 1995 Block all incoming UDP traffic. There are very few useful services that travel over UDP, and what useful - traffic there is normally a security threat (e.g. Suns RPC and + traffic there is, is normally a security threat (e.g. Suns RPC and NFS protocols). This has its disadvantages also, since UDP is a connectionless protocol, denying incoming UDP traffic also blocks the replies to outgoing UDP traffic. This can cause a problem for people (on the inside) using external archie (prospero) servers. - If you want to allow access to archie, you'll have to allow + If you want to allow access to archie, you will have to allow packets coming from ports 191 and 1525 to any internal UDP port through the firewall. ntp is another service you may consider allowing through, which comes from port 123. @@ -2524,7 +2525,7 @@ FreeBSD BUILT-19950429 (GR386) #0: Sat Apr 29 17:50:09 SAT 1995 IPsec - The IPsec mechanism provides secure communication either for IP + The IPsec mechanism provides secure communication for IP layer and socket layer communication. This section should explain how to use them. For implementation details, please refer to Transport Mode Example with IPv4 - Let's setup security association to deploy a secure channel + Let us setup security association to deploy a secure channel between HOST A (10.2.3.4) and HOST B (10.6.7.8). Here we show a little complicated example. From HOST A to HOST B, only old AH is used. From HOST B to HOST A, new AH and new ESP are combined. - Now we should choose algorithm to be used corresponding to + Now we should choose an algorithm to be used corresponding to "AH"/"new AH"/"ESP"/"new ESP". Please refer to the &man.setkey.8; man page to know algorithm names. Our choice is MD5 for AH, new-HMAC-SHA1 for new AH, and new-DES-expIV with 8 byte IV for new ESP. @@ -2560,7 +2561,7 @@ options IPSEC_ESP #IP security (crypto; define w/IPSEC) - OK, let's assign SPI (Security Parameter Index) for each protocol. + OK, let us assign SPI (Security Parameter Index) for each protocol. Please note that we need 3 SPIs for this secure channel since three security headers are produced (one for from HOST A to HOST B, two for from HOST B to HOST A). Please also note that SPI MUST be greater @@ -2595,7 +2596,7 @@ options IPSEC_ESP #IP security (crypto; define w/IPSEC) - Now, let's setup security association. Execute &man.setkey.8; + Now, let us setup security association. Execute &man.setkey.8; on both HOST A and B: @@ -2606,8 +2607,8 @@ add 10.6.7.8 10.2.3.4 esp 3000 -m transport -E des-cbc "PASSWORD" ; ^D - Actually, IPsec communication doesn't process until security policy - entries will be defined. In this case, you must setup each host. + Actually, IPsec communication does not process until security policy + entries are defined. In this case, you must setup each host. At A: @@ -2724,7 +2725,7 @@ spdadd 10.6.7.8 10.2.3.4 any -P out ipsec EOF - If port number field is omitted such above then "[any]" is + If the port number field is omitted such as above then "[any]" is employed. `-m' specifies the mode of SA to be used. "-m any" means wild-card of mode of security protocol. You can use this SA for both tunnel and transport mode. @@ -2915,8 +2916,8 @@ user@foobardomain.com's password: ******* The login will continue just as it would have if a session was created using rlogin or telnet. SSH utilizes a key fingerprint system for verifying the authenticity of the server when the - client connects. The user is prompted to enter 'yes' only during - the first time connecting. Future attempts to login are all + client connects. The user is prompted to enter 'yes' only when + connecting for the first time. Future attempts to login are all verified against the saved fingerprint key. The SSH client will alert you if the saved fingerprint differs from the received fingerprint on future login attempts. The fingerprints