SPECIAL SECTION ON DoS ATTACKS
This section covers Denial of Service attacks. A DoS attack is typically a packet attack. While there is not much you can do about modern spoofed packet attacks that saturate your network, you can generally limit the damage by ensuring that the attacks cannot take down your servers.
- Limiting server forks
- Limiting springboard attacks (ICMP response attacks, ping broadcast, etc.)
- Kernel Route Cache
A common DoS attack is against a forking server that attempts to cause the server to eat processes, file descriptors, and memory until the machine dies. The inetd(8) server 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 not generally possible to prevent a service from being disrupted by the attack. Read the inetd(8) manual page carefully and pay specific attention to the -c -, -C , and -R options. Note that spoofed-IP attacks will circumvent the -C option to inetd(8), so typically a combination of options must be used. Some standalone servers have self-fork-limitation parameters.
The sendmail(8) daemon has its -OMaxDaemonChildren option which tends to work much better than trying to use sendmail 8 s load limiting options due to the load lag. You should specify a MaxDaemonChildren parameter when you start sendmail(8) high enough to handle your expected load but not so high that the computer cannot handle that number of sendmail s without falling on its face. It is also prudent to run sendmail(8) in "queued" mode (-ODeliveryMode=queued) and to run the daemon ("sendmail-bd") separate from the queue-runs ("sendmail-q15m"). If you still want real-time delivery you can run the queue at a much lower interval, such as -q1m , but be sure to specify a reasonable MaxDaemonChildren option for that sendmail(8) to prevent cascade failures.
The syslogd(8) daemon can be attacked directly and it is strongly recommended that you use the -s option whenever possible, and the -a option otherwise.
You should also be fairly careful with connect-back services such as tcpwrappers reverse-identd, which can be attacked directly. You generally do not want to use the reverse-ident feature of tcpwrappers for this reason.
It is a very good idea to protect internal services from external access by firewalling them off at your border routers. The idea here is to prevent saturation attacks from outside your LAN, not so much to protect internal services from network-based root compromise. Always configure an exclusive firewall, i.e., ' firewall everything except ports A, B, C, D, and M-Z '. This way you can firewall off all of your low ports except for certain specific services such as named(8) (if you are primary for a zone), talkd(8), sendmail(8), and other internet-accessible 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 to update the firewall. You can still open up the high-numbered port range on the firewall to allow permissive-like operation without compromising your low ports. Also take note that
.Fx allows you to control the range of port numbers used for dynamic binding via the various net.inet.ip.portrange sysctls (""sysctlnet.inet.ip.portrange""), which can also ease the complexity of your firewalls configuration. I usually 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 my firewall (except for certain specific internet-accessible ports, of course).
Another common DoS attack is called a springboard attack to attack a server in a manner that causes the server to generate responses which then overload 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 your LANs broadcast address with the source IP address set to the actual machine they wish to attack. If your border routers are not configured to stomp on pings to broadcast addresses, your LAN winds up generating sufficient responses to the spoofed source address to saturate the victim, especially when the attacker uses the same trick on several dozen broadcast addresses over several dozen different networks at once. Broadcast attacks of over a hundred and twenty megabits have been measured. A second common springboard attack is against the ICMP error reporting system. By constructing packets that generate ICMP error responses, an attacker can saturate a servers incoming network and cause the server to saturate its outgoing network with ICMP responses. This type of attack can also crash the server by running it out of
.Vt mbuf Ns s , especially if the server cannot drain the ICMP responses it generates fast enough. The
.Fx kernel has a new kernel compile option called ICMP_BANDLIM which limits the effectiveness of these sorts of attacks. The last major class of springboard attacks is related to certain internal inetd(8) services such as the UDP echo service. An attacker simply spoofs a UDP packet with the source address being server As echo port, and the destination address being server Bs echo port, where server A and B are both on your LAN. The two servers then bounce this one packet back and forth between each other. The attacker can overload both servers and their LANs simply by injecting a few packets in this manner. Similar problems exist with the internal chargen port. A competent sysadmin will turn off all of these inetd 8 -internal test services.
Spoofed packet attacks may also be used to overload the kernel route cache. Refer to the net.inet.ip.rtexpire, net.inet.ip.rtminexpire, and net.inet.ip.rtmaxcache sysctl(8) variables. 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. There are two problems: (1) The kernel does not react quickly enough when a lightly loaded server is suddenly attacked, and (2) The rtminexpire is not low enough for the kernel to survive a sustained attack. If your servers are connected to the internet via a T3 or better it may be prudent to manually override both rtexpire and rtminexpire via sysctl(8). Never set either parameter to zero (unless you want to crash the machine :-)). Setting both parameters to 2 seconds should be sufficient to protect the route table from attack.
ACCESS ISSUES WITH KERBEROS AND SSH
There are a few issues with both Kerberos and SSH that need to be addressed if you intend to use them. Kerberos5 is an excellent authentication protocol but the kerberized telnet(1) and rlogin(1) suck rocks. There are bugs that make them unsuitable for dealing with binary streams. Also, by default Kerberos does not encrypt a session unless you use the -x option. SSH encrypts everything by default.
SSH works quite well in every respect except when it is set up to forward encryption keys. What this means is that if you have a secure workstation holding keys that give you access to the rest of the system, and you ssh(1) to an unsecure machine, your keys become exposed. The actual keys themselves are not exposed, but ssh(1) installs a forwarding port for 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.
We recommend that you use SSH in combination with Kerberos whenever possible for staff logins. SSH can be compiled with Kerberos support. This reduces your reliance on potentially exposable SSH keys while at the same time protecting passwords via Kerberos. SSH keys should only be used for automated tasks from secure machines (something that Kerberos is unsuited to). We also recommend that you either turn off key-forwarding in the SSH configuration, or that you make use of the from = IP/DOMAIN option that SSH allows in its authorized_keys file to make the key only usable to entities logging in from specific machines.
chflags(1), find(1), md5(1), netstat(1), openssl(1), ssh(1), xdm 1(ports/x11/xorg-clients), group(5), ttys(5), accton(8), init(8), sshd(8), sysctl(8), syslogd(8), vipw(8)