Commit | Line | Data |
---|---|---|
033a4603 | 1 | .\" Copyright (c) 1998 Matthew Dillon. Terms and conditions are those of |
984263bc MD |
2 | .\" the BSD Copyright as specified in the file "/usr/src/COPYRIGHT" in |
3 | .\" the source tree. | |
4 | .\" | |
5 | .\" $FreeBSD: src/share/man/man7/security.7,v 1.13.2.11 2002/04/13 02:04:44 keramida Exp $ | |
6 | .\" | |
7 | .Dd September 18, 1999 | |
8 | .Dt SECURITY 7 | |
9 | .Os | |
10 | .Sh NAME | |
11 | .Nm security | |
ac5c99e1 | 12 | .Nd introduction to security under DragonFly |
984263bc MD |
13 | .Sh DESCRIPTION |
14 | Security is a function that begins and ends with the system administrator. | |
15 | While all | |
16 | .Bx | |
17 | multi-user systems have some inherent security, the job of building and | |
18 | maintaining additional security mechanisms to keep users | |
19 | .Sq honest | |
20 | is probably | |
21 | one of the single largest undertakings of the sysadmin. Machines are | |
22 | only as secure as you make them, and security concerns are ever competing | |
23 | with the human necessity for convenience. | |
24 | .Ux | |
25 | systems, | |
26 | in general, are capable of running a huge number of simultaneous processes | |
27 | and many of these processes operate as servers - meaning that external entities | |
28 | can connect and talk to them. As yesterday's mini-computers and mainframes | |
29 | become today's desktops, and as computers become networked and internetworked, | |
30 | security becomes an ever bigger issue. | |
31 | .Pp | |
32 | Security is best implemented through a layered onion approach. In a nutshell, | |
33 | what you want to do is to create as many layers of security as are convenient | |
34 | and then carefully monitor the system for intrusions. You do not want to | |
35 | overbuild your security or you will interfere with the detection side, and | |
36 | detection is one of the single most important aspects of any security | |
37 | mechanism. For example, it makes little sense to set the | |
38 | .Pa schg | |
39 | flags | |
40 | (see | |
41 | .Xr chflags 1 ) | |
42 | on every system binary because while this may temporarily protect the | |
43 | binaries, it prevents a hacker who has broken in from making an | |
44 | easily detectable change that may result in your security mechanisms not | |
45 | detecting the hacker at all. | |
46 | .Pp | |
47 | System security also pertains to dealing with various forms of attack, | |
48 | including attacks that attempt to crash or otherwise make a system unusable | |
49 | but do not attempt to break root. Security concerns can be split up into | |
50 | several categories: | |
51 | .Bl -enum -offset indent | |
52 | .It | |
53 | Denial of service attacks | |
54 | .It | |
55 | User account compromises | |
56 | .It | |
57 | Root compromise through accessible servers | |
58 | .It | |
59 | Root compromise via user accounts | |
60 | .It | |
61 | Backdoor creation | |
62 | .El | |
63 | .Pp | |
64 | A denial of service attack is an action that deprives the machine of needed | |
65 | resources. Typically, D.O.S. attacks are brute-force mechanisms that attempt | |
66 | to crash or otherwise make a machine unusable by overwhelming its servers or | |
67 | network stack. Some D.O.S. attacks try to take advantages of bugs in the | |
68 | networking stack to crash a machine with a single packet. The latter can | |
69 | only be fixed by applying a bug fix to the kernel. Attacks on servers can | |
70 | often be fixed by properly specifying options to limit the load the servers | |
71 | incur on the system under adverse conditions. Brute-force network | |
72 | attacks are harder to deal with. A spoofed-packet attack, for example, is | |
73 | nearly impossible to stop short of cutting your system off from the Internet. | |
74 | It may not be able to take your machine down, but it can fill up Internet | |
75 | pipe. | |
76 | .Pp | |
f79ec571 | 77 | A user account compromise is even more common than a D.O.S. attack. Many |
984263bc MD |
78 | sysadmins still run standard telnetd, rlogind, rshd, and ftpd servers on their |
79 | machines. These servers, by default, do not operate over encrypted | |
80 | connections. The result is that if you have any moderate-sized user base, | |
81 | one or more of your users logging into your system from a remote location | |
82 | (which is the most common and convenient way to login to a system) | |
83 | will | |
84 | have his or her password sniffed. The attentive system admin will analyze | |
85 | his remote access logs looking for suspicious source addresses | |
86 | even for successful logins. | |
87 | .Pp | |
88 | One must always assume that once an attacker has access to a user account, | |
89 | the attacker can break root. However, the reality is that in a well secured | |
90 | and maintained system, access to a user account does not necessarily give the | |
91 | attacker access to root. The distinction is important because without access | |
92 | to root the attacker cannot generally hide his tracks and may, at best, be | |
93 | able to do nothing more than mess with the user's files or crash the machine. | |
94 | User account compromises are very common because users tend not to take the | |
95 | precautions that sysadmins take. | |
96 | .Pp | |
97 | System administrators must keep in mind that there are potentially many ways | |
98 | to break root on a machine. The attacker may know the root password, | |
99 | the attacker | |
100 | may find a bug in a root-run server and be able to break root over a network | |
101 | connection to that server, or the attacker may know of a bug in an suid-root | |
102 | program that allows the attacker to break root once he has broken into a | |
103 | user's account. If an attacker has found a way to break root on a machine, | |
104 | the attacker may not have a need to install a backdoor. | |
105 | Many of the root holes found and closed to date involve a considerable amount | |
106 | of work by the hacker to cleanup after himself, so most hackers do install | |
107 | backdoors. This gives you a convenient way to detect the hacker. Making | |
108 | it impossible for a hacker to install a backdoor may actually be detrimental | |
109 | to your security because it will not close off the hole the hacker found to | |
110 | break in the first place. | |
111 | .Pp | |
112 | Security remedies should always be implemented with a multi-layered | |
113 | .Sq onion peel | |
114 | approach and can be categorized as follows: | |
115 | .Bl -enum -offset indent | |
116 | .It | |
117 | Securing root and staff accounts | |
118 | .It | |
119 | Securing root - root-run servers and suid/sgid binaries | |
120 | .It | |
121 | Securing user accounts | |
122 | .It | |
123 | Securing the password file | |
124 | .It | |
125 | Securing the kernel core, raw devices, and filesystems | |
126 | .It | |
127 | Quick detection of inappropriate changes made to the system | |
128 | .It | |
129 | Paranoia | |
130 | .El | |
131 | .Sh SECURING THE ROOT ACCOUNT AND SECURING STAFF ACCOUNTS | |
132 | Don't bother securing staff accounts if you haven't secured the root | |
133 | account. Most systems have a password assigned to the root account. The | |
134 | first thing you do is assume that the password is | |
135 | .Sq always | |
136 | compromised. This does not mean that you should remove the password. The | |
137 | password is almost always necessary for console access to the machine. | |
138 | What it does mean is that you should not make it possible to use the password | |
139 | outside of the console or possibly even with a | |
140 | .Xr su 1 | |
141 | command. | |
142 | For example, make sure that your pty's are specified as being unsecure | |
143 | in the | |
144 | .Sq Pa /etc/ttys | |
145 | file | |
146 | so that direct root logins via telnet or rlogin are disallowed. If using | |
147 | other login services such as sshd, make sure that direct root logins are | |
148 | disabled there as well. Consider every access method - services such as | |
149 | ftp often fall through the cracks. Direct root logins should only be allowed | |
150 | via the system console. | |
151 | .Pp | |
152 | Of course, as a sysadmin you have to be able to get to root, so we open up | |
153 | a few holes. But we make sure these holes require additional password | |
154 | verification to operate. One way to make root accessible is to add appropriate | |
155 | staff accounts to the wheel group | |
156 | (in | |
157 | .Pa /etc/group ) . | |
158 | The staff members placed | |
159 | in the wheel group are allowed to | |
160 | .Sq su | |
161 | to root. You should never give staff | |
162 | members native wheel access by putting them in the wheel group in their | |
163 | password entry. Staff accounts should be placed in a | |
164 | .Sq staff | |
165 | group, and then added to the wheel group via the | |
166 | .Sq Pa /etc/group | |
167 | file. Only those staff members who actually need to have root access | |
168 | should be placed in the wheel group. It is also possible, when using an | |
169 | authentication method such as kerberos, to use kerberos's | |
170 | .Sq Pa .k5login | |
171 | file in the root account to allow a | |
172 | .Xr ksu 1 | |
173 | to root without having to place anyone at all in the wheel group. This | |
174 | may be the better solution since the wheel mechanism still allows an | |
175 | intruder to break root if the intruder has gotten hold of your password | |
176 | file and can break into a staff account. While having the wheel mechanism | |
f79ec571 | 177 | is better than having nothing at all, it isn't necessarily the safest |
984263bc MD |
178 | option. |
179 | .Pp | |
180 | An indirect way to secure the root account is to secure your staff accounts | |
181 | by using an alternative login access method and *'ing out the crypted password | |
182 | for the staff accounts. This way an intruder may be able to steal the password | |
183 | file but will not be able to break into any staff accounts (or, indirectly, | |
184 | root, even if root has a crypted password associated with it). Staff members | |
185 | get into their staff accounts through a secure login mechanism such as | |
1f243df2 | 186 | .Xr kerberos 8 Pq Pa security/heimdal |
984263bc MD |
187 | or |
188 | .Xr ssh 1 | |
189 | using a private/public | |
190 | key pair. When you use something like kerberos you generally must secure | |
191 | the machines which run the kerberos servers and your desktop workstation. | |
192 | When you use a public/private key pair with ssh, you must generally secure | |
193 | the machine you are logging in FROM | |
194 | (typically your workstation), | |
195 | but you can | |
196 | also add an additional layer of protection to the key pair by password | |
197 | protecting the keypair when you create it with | |
198 | .Xr ssh-keygen 1 . | |
199 | Being able | |
200 | to *-out the passwords for staff accounts also guarantees that staff members | |
201 | can only login through secure access methods that you have setup. You can | |
202 | thus force all staff members to use secure, encrypted connections for | |
203 | all their sessions which closes an important hole used by many intruders: That | |
204 | of sniffing the network from an unrelated, less secure machine. | |
205 | .Pp | |
206 | The more indirect security mechanisms also assume that you are logging in | |
207 | from a more restrictive server to a less restrictive server. For example, | |
208 | if your main box is running all sorts of servers, your workstation shouldn't | |
209 | be running any. In order for your workstation to be reasonably secure | |
210 | you should run as few servers as possible, up to and including no servers | |
211 | at all, and you should run a password-protected screen blanker. | |
212 | Of course, given physical access to | |
213 | a workstation an attacker can break any sort of security you put on it. | |
214 | This is definitely a problem that you should consider but you should also | |
215 | consider the fact that the vast majority of break-ins occur remotely, over | |
216 | a network, from people who do not have physical access to your workstation or | |
217 | servers. | |
218 | .Pp | |
219 | Using something like kerberos also gives you the ability to disable or | |
220 | change the password for a staff account in one place and have it immediately | |
68b2c890 | 221 | affect all the machines the staff member may have an account on. If a staff |
984263bc MD |
222 | member's account gets compromised, the ability to instantly change his |
223 | password on all machines should not be underrated. With discrete passwords, | |
224 | changing a password on N machines can be a mess. You can also impose | |
225 | re-passwording restrictions with kerberos: not only can a kerberos ticket | |
226 | be made to timeout after a while, but the kerberos system can require that | |
227 | the user choose a new password after a certain period of time | |
228 | (say, once a month). | |
229 | .Sh SECURING ROOT - ROOT-RUN SERVERS AND SUID/SGID BINARIES | |
230 | The prudent sysadmin only runs the servers he needs to, no more, no less. Be | |
231 | aware that third party servers are often the most bug-prone. For example, | |
232 | running an old version of imapd or popper is like giving a universal root | |
233 | ticket out to the entire world. Never run a server that you have not checked | |
234 | out carefully. Many servers do not need to be run as root. For example, | |
235 | the ntalk, comsat, and finger daemons can be run in special user | |
236 | .Sq sandboxes . | |
237 | A sandbox isn't perfect unless you go to a large amount of trouble, but the | |
238 | onion approach to security still stands: If someone is able to break in | |
239 | through a server running in a sandbox, they still have to break out of the | |
240 | sandbox. The more layers the attacker must break through, the lower the | |
241 | likelihood of his success. Root holes have historically been found in | |
242 | virtually every server ever run as root, including basic system servers. | |
243 | If you are running a machine through which people only login via sshd and | |
244 | never login via telnetd or rshd or rlogind, then turn off those services! | |
245 | .Pp | |
9bb2a92d | 246 | .Dx |
984263bc MD |
247 | now defaults to running ntalkd, comsat, and finger in a sandbox. |
248 | Another program which may be a candidate for running in a sandbox is | |
249 | .Xr named 8 . | |
250 | The default rc.conf includes the arguments necessary to run | |
251 | named in a sandbox in a commented-out form. Depending on whether you | |
252 | are installing a new system or upgrading an existing system, the special | |
253 | user accounts used by these sandboxes may not be installed. The prudent | |
254 | sysadmin would research and implement sandboxes for servers whenever possible. | |
255 | .Pp | |
256 | There are a number of other servers that typically do not run in sandboxes: | |
257 | sendmail, popper, imapd, ftpd, and others. There are alternatives to | |
a4b3cb41 | 258 | some of these, but installing them may require more work than you are willing |
984263bc MD |
259 | to put |
260 | (the convenience factor strikes again). | |
261 | You may have to run these | |
262 | servers as root and rely on other mechanisms to detect break-ins that might | |
263 | occur through them. | |
264 | .Pp | |
265 | The other big potential root hole in a system are the suid-root and sgid | |
266 | binaries installed on the system. Most of these binaries, such as rlogin, | |
267 | reside in | |
268 | .Pa /bin , | |
269 | .Pa /sbin , | |
270 | .Pa /usr/bin , | |
271 | or | |
272 | .Pa /usr/sbin . | |
273 | While nothing is 100% safe, | |
274 | the system-default suid and sgid binaries can be considered reasonably safe. | |
275 | Still, root holes are occasionally found in these binaries. A root hole | |
276 | was found in Xlib in 1998 that made xterm | |
277 | (which is typically suid) | |
278 | vulnerable. | |
f79ec571 | 279 | It is better to be safe than sorry and the prudent sysadmin will restrict suid |
984263bc MD |
280 | binaries that only staff should run to a special group that only staff can |
281 | access, and get rid of | |
282 | .Pq Li "chmod 000" | |
283 | any suid binaries that nobody uses. A | |
284 | server with no display generally does not need an xterm binary. Sgid binaries | |
285 | can be almost as dangerous. If an intruder can break an sgid-kmem binary the | |
286 | intruder might be able to read | |
287 | .Pa /dev/kmem | |
288 | and thus read the crypted password | |
289 | file, potentially compromising any passworded account. Alternatively an | |
290 | intruder who breaks group kmem can monitor keystrokes sent through pty's, | |
291 | including pty's used by users who login through secure methods. An intruder | |
292 | that breaks the tty group can write to almost any user's tty. If a user | |
293 | is running a terminal | |
294 | program or emulator with a keyboard-simulation feature, the intruder can | |
295 | potentially | |
296 | generate a data stream that causes the user's terminal to echo a command, which | |
297 | is then run as that user. | |
298 | .Sh SECURING USER ACCOUNTS | |
299 | User accounts are usually the most difficult to secure. While you can impose | |
300 | Draconian access restrictions on your staff and *-out their passwords, you | |
301 | may not be able to do so with any general user accounts you might have. If | |
302 | you do have sufficient control then you may win out and be able to secure the | |
303 | user accounts properly. If not, you simply have to be more vigilant in your | |
304 | monitoring of those accounts. Use of ssh and kerberos for user accounts is | |
305 | more problematic due to the extra administration and technical support | |
306 | required, but still a very good solution compared to a crypted password | |
307 | file. | |
308 | .Sh SECURING THE PASSWORD FILE | |
a4b3cb41 | 309 | The only sure-fire way is to *-out as many passwords as you can and |
984263bc MD |
310 | use ssh or kerberos for access to those accounts. Even though the |
311 | crypted password file | |
312 | .Pq Pa /etc/spwd.db | |
313 | can only be read by root, it may | |
314 | be possible for an intruder to obtain read access to that file even if the | |
315 | attacker cannot obtain root-write access. | |
316 | .Pp | |
317 | Your security scripts should always check for and report changes to | |
318 | the password file | |
319 | (see | |
320 | .Sq Checking file integrity | |
321 | below). | |
322 | .Sh SECURING THE KERNEL CORE, RAW DEVICES, AND FILESYSTEMS | |
323 | If an attacker breaks root he can do just about anything, but there | |
324 | are certain conveniences. For example, most modern kernels have a | |
325 | packet sniffing device driver built in. Under | |
9bb2a92d | 326 | .Dx |
984263bc MD |
327 | it is called |
328 | the | |
329 | .Sq bpf | |
330 | device. An intruder will commonly attempt to run a packet sniffer | |
331 | on a compromised machine. You do not need to give the intruder the | |
332 | capability and most systems should not have the bpf device compiled in. | |
333 | .Pp | |
334 | But even if you turn off the bpf device, | |
335 | you still have | |
336 | .Pa /dev/mem | |
337 | and | |
338 | .Pa /dev/kmem | |
339 | to worry about. For that matter, | |
340 | the intruder can still write to raw disk devices. | |
341 | Also, there is another kernel feature called the module loader, | |
342 | .Xr kldload 8 . | |
343 | An enterprising intruder can use a KLD module to install | |
344 | his own bpf device or other sniffing device on a running kernel. | |
345 | To avoid these problems you have to run | |
346 | the kernel at a higher secure level, at least securelevel 1. The securelevel | |
e9c76aaf SW |
347 | can be set with a sysctl on the |
348 | .Va kern.securelevel | |
349 | variable. Once you have | |
984263bc MD |
350 | set the securelevel to 1, write access to raw devices will be denied and |
351 | special chflags flags, such as | |
352 | .Sq schg , | |
353 | will be enforced. You must also ensure | |
354 | that the | |
355 | .Sq schg | |
356 | flag is set on critical startup binaries, directories, and | |
357 | script files - everything that gets run up to the point where the securelevel | |
358 | is set. This might be overdoing it, and upgrading the system is much more | |
359 | difficult when you operate at a higher secure level. You may compromise and | |
360 | run the system at a higher secure level but not set the schg flag for every | |
361 | system file and directory under the sun. Another possibility is to simply | |
362 | mount / and /usr read-only. It should be noted that being too draconian in | |
363 | what you attempt to protect may prevent the all-important detection of an | |
364 | intrusion. | |
365 | .Sh CHECKING FILE INTEGRITY: BINARIES, CONFIG FILES, ETC | |
366 | When it comes right down to it, you can only protect your core system | |
367 | configuration and control files so much before the convenience factor | |
368 | rears its ugly head. For example, using chflags to set the schg bit | |
369 | on most of the files in / and /usr is probably counterproductive because | |
370 | while it may protect the files, it also closes a detection window. The | |
371 | last layer of your security onion is perhaps the most important - detection. | |
372 | The rest of your security is pretty much useless (or, worse, presents you with | |
373 | a false sense of safety) if you cannot detect potential incursions. Half | |
23265324 | 374 | the job of the onion is to slow down the attacker rather than stop him |
984263bc MD |
375 | in order to give the detection side of the equation a chance to catch him in |
376 | the act. | |
377 | .Pp | |
378 | The best way to detect an incursion is to look for modified, missing, or | |
379 | unexpected files. The best | |
380 | way to look for modified files is from another (often centralized) | |
381 | limited-access system. | |
382 | Writing your security scripts on the extra-secure limited-access system | |
383 | makes them mostly invisible to potential hackers, and this is important. | |
384 | In order to take maximum advantage you generally have to give the | |
385 | limited-access box significant access to the other machines in the business, | |
386 | usually either by doing a read-only NFS export of the other machines to the | |
387 | limited-access box, or by setting up ssh keypairs to allow the limit-access | |
388 | box to ssh to the other machines. Except for its network traffic, NFS is | |
389 | the least visible method - allowing you to monitor the filesystems on each | |
390 | client box virtually undetected. If your | |
391 | limited-access server is connected to the client boxes through a switch, | |
392 | the NFS method is often the better choice. If your limited-access server | |
393 | is connected to the client boxes through a hub or through several layers | |
394 | of routing, the NFS method may be too insecure (network-wise) and using ssh | |
395 | may be the better choice even with the audit-trail tracks that ssh lays. | |
396 | .Pp | |
397 | Once you give a limit-access box at least read access to the client systems | |
398 | it is supposed to monitor, you must write scripts to do the actual | |
399 | monitoring. Given an NFS mount, you can write scripts out of simple system | |
400 | utilities such as | |
401 | .Xr find 1 | |
402 | and | |
d454c55c | 403 | .Xr md5 1 . |
984263bc MD |
404 | It is best to physically md5 the client-box files boxes at least once a |
405 | day, and to test control files such as those found in | |
d454c55c | 406 | .Pa /etc , |
984263bc | 407 | .Pa /usr/local/etc |
c8e8a2e5 SW |
408 | and |
409 | .Pa /usr/pkg/etc | |
984263bc MD |
410 | even more often. When mismatches are found relative to the base md5 |
411 | information the limited-access machine knows is valid, it should scream at | |
412 | a sysadmin to go check it out. A good security script will also check for | |
413 | inappropriate suid binaries and for new or deleted files on system partitions | |
414 | such as | |
415 | .Pa / | |
416 | and | |
417 | .Pa /usr | |
418 | .Pp | |
23265324 | 419 | When using ssh rather than NFS, writing the security script is much more |
984263bc MD |
420 | difficult. You essentially have to |
421 | .Pa scp | |
422 | the scripts to the client box in order to run them, making them visible, and | |
423 | for safety you also need to scp the binaries (such as find) that those scripts | |
424 | use. The ssh daemon on the client box may already be compromised. All in all, | |
425 | using ssh may be necessary when running over unsecure links, but it's also a | |
426 | lot harder to deal with. | |
427 | .Pp | |
428 | A good security script will also check for changes to user and staff members | |
429 | access configuration files: | |
430 | .Pa .rhosts , | |
431 | .Pa .shosts , | |
432 | .Pa .ssh/authorized_keys | |
433 | and so forth... files that might fall outside the purview of the MD5 check. | |
434 | .Pp | |
435 | If you have a huge amount of user disk space it may take too long to run | |
436 | through every file on those partitions. In this case, setting mount | |
437 | flags to disallow suid binaries and devices on those partitions is a good | |
438 | idea. The | |
439 | .Sq nodev | |
440 | and | |
441 | .Sq nosuid | |
442 | options | |
443 | (see | |
444 | .Xr mount 8 ) | |
445 | are what you want to look into. I would scan them anyway at least once a | |
446 | week, since the object of this layer is to detect a break-in whether or | |
447 | not the breakin is effective. | |
448 | .Pp | |
449 | Process accounting | |
450 | (see | |
451 | .Xr accton 8 ) | |
452 | is a relatively low-overhead feature of | |
453 | the operating system which I recommend using as a post-break-in evaluation | |
454 | mechanism. It is especially useful in tracking down how an intruder has | |
455 | actually broken into a system, assuming the file is still intact after | |
456 | the break-in occurs. | |
457 | .Pp | |
458 | Finally, security scripts should process the log files and the logs themselves | |
459 | should be generated in as secure a manner as possible - remote syslog can be | |
460 | very useful. An intruder tries to cover his tracks, and log files are critical | |
461 | to the sysadmin trying to track down the time and method of the initial | |
462 | break-in. One way to keep a permanent record of the log files is to run | |
463 | the system console to a serial port and collect the information on a | |
464 | continuing basis through a secure machine monitoring the consoles. | |
465 | .Sh PARANOIA | |
466 | A little paranoia never hurts. As a rule, a sysadmin can add any number | |
a4b3cb41 LF |
467 | of security features as long as they do not affect convenience, and |
468 | can add security features that do affect convenience with some added | |
984263bc MD |
469 | thought. Even more importantly, a security administrator should mix it up |
470 | a bit - if you use recommendations such as those given by this manual | |
471 | page verbatim, you give away your methodologies to the prospective | |
472 | hacker who also has access to this manual page. | |
473 | .Sh SPECIAL SECTION ON D.O.S. ATTACKS | |
474 | This section covers Denial of Service attacks. A DOS attack is typically | |
475 | a packet attack. While there isn't much you can do about modern spoofed | |
476 | packet attacks that saturate your network, you can generally limit the damage | |
477 | by ensuring that the attacks cannot take down your servers. | |
478 | .Bl -enum -offset indent | |
479 | .It | |
480 | Limiting server forks | |
481 | .It | |
482 | Limiting springboard attacks (ICMP response attacks, ping broadcast, etc...) | |
483 | .It | |
484 | Kernel Route Cache | |
485 | .El | |
486 | .Pp | |
a4b3cb41 | 487 | A common D.O.S. attack is against a forking server that attempts to cause the |
984263bc MD |
488 | server to eat processes, file descriptors, and memory until the machine |
489 | dies. Inetd | |
490 | (see | |
491 | .Xr inetd 8 ) | |
492 | has several options to limit this sort of attack. | |
493 | It should be noted that while it is possible to prevent a machine from going | |
494 | down it is not generally possible to prevent a service from being disrupted | |
495 | by the attack. Read the inetd manual page carefully and pay specific attention | |
496 | to the | |
497 | .Fl c , | |
498 | .Fl C , | |
499 | and | |
500 | .Fl R | |
501 | options. Note that spoofed-IP attacks will circumvent | |
502 | the | |
503 | .Fl C | |
504 | option to inetd, so typically a combination of options must be used. | |
505 | Some standalone servers have self-fork-limitation parameters. | |
506 | .Pp | |
507 | Sendmail has its | |
508 | .Fl OMaxDaemonChildren | |
509 | option which tends to work much | |
510 | better than trying to use sendmail's load limiting options due to the | |
511 | load lag. You should specify a | |
512 | .Cm MaxDaemonChildren | |
513 | parameter when you start | |
514 | sendmail high enough to handle your expected load but no so high that the | |
515 | computer cannot handle that number of sendmails without falling on its face. | |
516 | It is also prudent to run sendmail in queued mode | |
517 | .Pq Fl ODeliveryMode=queued | |
518 | and to run the daemon | |
519 | .Pq Cm sendmail -bd | |
520 | separate from the queue-runs | |
521 | .Pq Cm sendmail -q15m . | |
522 | If you still want realtime delivery you can run the queue | |
523 | at a much lower interval, such as | |
524 | .Fl q1m , | |
525 | but be sure to specify a reasonable | |
526 | .Cm MaxDaemonChildren | |
527 | option for that sendmail to prevent cascade failures. | |
528 | .Pp | |
529 | Syslogd can be attacked directly and it is strongly recommended that you use | |
530 | the | |
531 | .Fl s | |
532 | option whenever possible, and the | |
533 | .Fl a | |
534 | option otherwise. | |
535 | .Pp | |
536 | You should also be fairly careful | |
537 | with connect-back services such as tcpwrapper's reverse-identd, which can | |
538 | be attacked directly. You generally do not want to use the reverse-ident | |
539 | feature of tcpwrappers for this reason. | |
540 | .Pp | |
541 | It is a very good idea to protect internal services from external access | |
542 | by firewalling them off at your border routers. The idea here is to prevent | |
543 | saturation attacks from outside your LAN, not so much to protect internal | |
544 | services from network-based root compromise. Always configure an exclusive | |
545 | firewall, i.e.\& | |
546 | .So | |
547 | firewall everything *except* ports A, B, C, D, and M-Z | |
548 | .Sc . | |
549 | This | |
550 | way you can firewall off all of your low ports except for certain specific | |
551 | services such as named | |
552 | (if you are primary for a zone), | |
553 | ntalkd, sendmail, | |
554 | and other internet-accessible services. | |
555 | If you try to configure the firewall the other | |
556 | way - as an inclusive or permissive firewall, there is a good chance that you | |
557 | will forget to | |
558 | .Sq close | |
559 | a couple of services or that you will add a new internal | |
560 | service and forget to update the firewall. You can still open up the | |
561 | high-numbered port range on the firewall to allow permissive-like operation | |
562 | without compromising your low ports. Also take note that | |
9bb2a92d | 563 | .Dx |
984263bc MD |
564 | allows you to |
565 | control the range of port numbers used for dynamic binding via the various | |
566 | net.inet.ip.portrange sysctl's | |
567 | .Pq Li "sysctl -a | fgrep portrange" , | |
568 | which can also | |
569 | ease the complexity of your firewall's configuration. I usually use a normal | |
570 | first/last range of 4000 to 5000, and a hiport range of 49152 to 65535, then | |
571 | block everything under 4000 off in my firewall | |
572 | (except for certain specific | |
573 | internet-accessible ports, of course). | |
574 | .Pp | |
a4b3cb41 | 575 | Another common D.O.S. attack is called a springboard attack - to attack a server |
984263bc MD |
576 | in a manner that causes the server to generate responses which then overload |
577 | the server, the local network, or some other machine. The most common attack | |
578 | of this nature is the ICMP PING BROADCAST attack. The attacker spoofs ping | |
579 | packets sent to your LAN's broadcast address with the source IP address set | |
580 | to the actual machine they wish to attack. If your border routers are not | |
581 | configured to stomp on ping's to broadcast addresses, your LAN winds up | |
582 | generating sufficient responses to the spoofed source address to saturate the | |
583 | victim, especially when the attacker uses the same trick on several dozen | |
584 | broadcast addresses over several dozen different networks at once. Broadcast | |
585 | attacks of over a hundred and twenty megabits have been measured. A second | |
586 | common springboard attack is against the ICMP error reporting system. By | |
587 | constructing packets that generate ICMP error responses, an attacker can | |
588 | saturate a server's incoming network and cause the server to saturate its | |
589 | outgoing network with ICMP responses. This type of attack can also crash the | |
590 | server by running it out of mbuf's, especially if the server cannot drain the | |
591 | ICMP responses it generates fast enough. The | |
9bb2a92d | 592 | .Dx |
984263bc MD |
593 | kernel has a new kernel |
594 | compile option called ICMP_BANDLIM which limits the effectiveness of these | |
595 | sorts of attacks. The last major class of springboard attacks is related to | |
596 | certain internal inetd services such as the udp echo service. An attacker | |
597 | simply spoofs a UDP packet with the source address being server A's echo port, | |
598 | and the destination address being server B's echo port, where server A and B | |
599 | are both on your LAN. The two servers then bounce this one packet back and | |
600 | forth between each other. The attacker can overload both servers and their | |
601 | LANs simply by injecting a few packets in this manner. Similar problems | |
602 | exist with the internal chargen port. A competent sysadmin will turn off all | |
603 | of these inetd-internal test services. | |
604 | .Pp | |
605 | Spoofed packet attacks may also be used to overload the kernel route cache. | |
e9c76aaf SW |
606 | Refer to the |
607 | .Va net.inet.ip.rtexpire , | |
608 | .Va net.inet.ip.rtminexpire , | |
609 | and | |
610 | .Va net.inet.ip.rtmaxcache | |
611 | sysctl | |
984263bc MD |
612 | parameters. A spoofed packet attack that uses a random source IP will cause |
613 | the kernel to generate a temporary cached route in the route table, viewable | |
614 | with | |
615 | .Sq netstat -rna \&| fgrep W3 . | |
616 | These routes typically timeout in 1600 | |
617 | seconds or so. If the kernel detects that the cached route table has gotten | |
618 | too big it will dynamically reduce the rtexpire but will never decrease it to | |
f79ec571 | 619 | less than rtminexpire. There are two problems: (1) The kernel does not react |
984263bc MD |
620 | quickly enough when a lightly loaded server is suddenly attacked, and (2) The |
621 | rtminexpire is not low enough for the kernel to survive a sustained attack. | |
622 | If your servers are connected to the internet via a T3 or better it may be | |
623 | prudent to manually override both rtexpire and rtminexpire via | |
624 | .Xr sysctl 8 . | |
625 | Never set either parameter to zero | |
626 | (unless you want to crash the machine :-)). | |
627 | Setting both parameters to 2 seconds should be sufficient to protect the route | |
628 | table from attack. | |
629 | .Sh ACCESS ISSUES WITH KERBEROS AND SSH | |
630 | There are a few issues with both kerberos and ssh that need to be addressed | |
631 | if you intend to use them. Kerberos V is an excellent authentication | |
632 | protocol but the kerberized telnet and rlogin suck rocks. There are bugs that | |
633 | make them unsuitable for dealing with binary streams. Also, by default | |
634 | kerberos does not encrypt a session unless you use the | |
635 | .Fl x | |
636 | option. Ssh encrypts everything by default. | |
637 | .Pp | |
638 | Ssh works quite well in every respect except when it is set up to | |
639 | forward encryption keys. | |
640 | What this means is that if you have a secure workstation holding | |
641 | keys that give you access to the rest of the system, and you ssh to an | |
642 | unsecure machine, your keys becomes exposed. The actual keys themselves are | |
643 | not exposed, but ssh installs a forwarding port for the duration of your | |
644 | login and if a hacker has broken root on the unsecure machine he can utilize | |
645 | that port to use your keys to gain access to any other machine that your | |
646 | keys unlock. | |
647 | .Pp | |
648 | We recommend that you use ssh in combination with kerberos whenever possible | |
649 | for staff logins. Ssh can be compiled with kerberos support. This reduces | |
650 | your reliance on potentially exposable ssh keys while at the same time | |
651 | protecting passwords via kerberos. Ssh keys | |
652 | should only be used for automated tasks from secure machines (something | |
653 | that kerberos is unsuited to). We also recommend that you either turn off | |
654 | key-forwarding in the ssh configuration, or that you make use of the | |
655 | .Pa "from=IP/DOMAIN" | |
656 | option that ssh allows in its | |
657 | .Pa authorized_keys | |
658 | file to make the key only usable to entities logging in from specific | |
659 | machines. | |
660 | .Sh SEE ALSO | |
661 | .Xr chflags 1 , | |
662 | .Xr find 1 , | |
984263bc MD |
663 | .Xr md5 1 , |
664 | .Xr netstat 1 , | |
665 | .Xr openssl 1 , | |
666 | .Xr ssh 1 , | |
c8e8a2e5 | 667 | .Xr xdm 1 Pq Pa x11/xdm , |
984263bc MD |
668 | .Xr group 5 , |
669 | .Xr ttys 5 , | |
1da04567 | 670 | .Xr firewall 7 , |
984263bc MD |
671 | .Xr accton 8 , |
672 | .Xr init 8 , | |
8d6aeca2 | 673 | .Xr kerberos 8 , |
984263bc MD |
674 | .Xr sshd 8 , |
675 | .Xr sysctl 8 , | |
676 | .Xr syslogd 8 , | |
677 | .Xr vipw 8 | |
678 | .Sh HISTORY | |
679 | The | |
680 | .Nm | |
681 | manual page was originally written by | |
682 | .An Matthew Dillon | |
683 | and first appeared | |
684 | in | |
685 | .Fx 3.1 , | |
686 | December 1998. |