Classification to prevent DoS attacks on Linux

Categories prevent DoS attacks on Linux-Linux Enterprise applications-Linux server applications. For details, see the following section. As a result of the proliferation of Denial-of-Service attack tools and the fact that the protocol layer defects cannot be changed for a short time, denial-of-service attacks have become a widely spread and extremely difficult to prevent. Although no absolute method can be used to stop such attacks so far, there are still some solutions for different attack methods. This document uses Redhat Linux 9.0 as an example to describe how to classify and prevent DoS attacks.

Two Daemon Processes on the Linux Server

1. stand-alone mode

The stand-alone mode is the access mode of the traditional Unix C/S mode. The server listener (Listen) waits for the client to come online on a special port. If the client generates a connection request, the daemon creates a (Fork) subserver to respond to the connection, and the master server continues to listen to the connection to keep multiple subserver pools waiting for the next client request. The operating principle of the Stand-alone mode is shown in 1.

The network services that work in stand-alone mode include route and gated. The familiar Web servers are Apache and Sendmail. On a server with a large load such as Apache, creating a sub-server in advance can increase the customer's service speed.

In Linux, the services started in stand-alone working mode are started by the symbolic link in the running level under/etc/rc. d.

2. xinetd Mode

It can be seen from the concept of daemon that every service that the system uses must run a daemon that listens to a port connection. This usually means a waste of resources. To solve this problem, Linux introduces the concept of "network daemon service program.

The network daemon used by Redhat Linux 9.0 is xinetd (eXtended InterNET daemon ). Compared with the stand-alone mode, the xinetd mode is also called the Internet Super-Server (Super Server ). Xinetd can listen to multiple specified ports at the same time. When receiving user requests, it can start different network service processes to process these user requests based on different user request ports. We can regard xinetd as a management server that manages the startup service. It decides the program to which a customer request is sent for processing, and then starts the corresponding daemon process. The working principle of xinetd Mode 2 is shown in.

Compared with the stand-alone working mode, the system does not want every network service process to listen to its service port, and runs a single xinetd to listen to all service ports at the same time, thus reducing system overhead, protects system resources. However, if xinetd wants to start the corresponding network service process frequently when there is a large access volume and frequent concurrent access, it will lead to a decline in system performance.

Check which mode the system provides for the Linux service. Run the pstree command on the Linux Command Line to view the network services started in two different ways. Generally, some high-load services, such as Sendmail and Apache, are started independently, while other services can be managed using xinetd superservers, by default, xinetd services can be divided into the following categories: standard Internet services: telnet, ftp

Information Service: finger, netstat, comment

RPC service: rquotad, rstatd, rusersd, sprayd, walld

BSD service: comsat, exec, login, ntalk, shell, talk

Internal services: chargen, daytime, echo, servers, services time

Security Service: irc

Other services: name, tftp, uucp

TIPS: in principle, Apache and sendmail can also be started in xinetd mode, but you need servers with high hardware levels.

Xinetd-mode DoS prevention

Xinetd provides functions similar to inetd + tcp_wrapper, but it is more powerful and secure, and can effectively prevent DoS:

1. restrict the number of processes running at the same time

Set the number of concurrent processes that run at the same time by setting the instances option. For example:

Instances = 20

Note: When the number of processes requested to connect to the server reaches 20, xinetd will stop accepting connection requests from more than 20 processes until the number of requests is lower than the set value.

2. Limit the maximum number of connections of an IP address

Limit the maximum number of connections of a host to prevent a host from occupying a service exclusively. For example:

Per_source = 5

Note: The number of connections for a single IP address is 5.

3. Limit the log file size to prevent disk space from being filled up

Many attackers know that most services need to write logs. Intruders can construct a large number of error messages and send them. The server records these errors, which may cause huge log files or even full hard disks. The administrator faces a large number of logs, and it is difficult to find the real intrusion path of intruders. Therefore, limiting the log file size is a way to prevent DoS attacks. For example:

Log_type FILE.1/var/log/myservice. log 8388608 15728640

Note: The critical value of the log file FILE.1 set here is 8 MB. When it reaches this value, a warning will appear in the syslog file. When it reaches 15 MB, the system will stop all services that use this log system.

4. Restrict the load

Xinetd can also prevent DoS attacks by limiting loads. Use a floating point number as the load factor. When the load reaches this value, the service will suspend processing for subsequent connections. For example:

Max_load = 2.8

Note: When a system load reaches 2.8, all services will be temporarily terminated until the system load falls below the set value.

Of course, to use this option, you must add-with-loadavg during compilation, and xinetd will process the max-load configuration options to disable some service processes when the system load is too heavy, to launch some denial-of-service attacks.

5. Limit the number of all servers (connection rate)

Xinetd can use the cps option to set the connection rate. For example:

Cps = 25 60

Note: The first parameter indicates the number of connections that can be processed per second. If this number of connections is exceeded, the incoming connection will be temporarily suspended; the second parameter indicates the number of seconds after the service is stopped. That is, the server can start up to 25 connections. If this number is reached, the server will stop starting the new service for 60 seconds. No request is accepted during this period.

6. restrict the use of hardware resources

The rlimit_as and rlimit_cpu options can effectively limit the resource usage of a service for memory and central processor. Example: rlimit_as = 8 M

Rlimit_cpu = 20


Note: This setting limits the use of server hardware resources. The maximum available memory is 8 MB, and the CPU processes 20 processes per second.

Summary: an important feature of xinetd is that it can control the amount of resources available for subordinate services. The preceding settings can help prevent a certain xinetd service from occupying a large number of systems, this leads to "denial of service.

DoS defense against stand-alone

In Linux, the servers running in stand-alone mode are Apache and Sendmail.

1. DoS prevention measures for Apache servers

The Apache server mainly uses the Apache DoS Evasive Maneuvers Module to prevent attacks. It is an alternative to mod_access and can defend against DoS attacks. The software can quickly reject repeated requests from the same address to the same URL, which is achieved through a hash table query of each sub-process. Download link: http://online.securityfocus.com/data/tools/dospatch.tar.gz. you can click the relevant page to download the software installation configuration.

In addition, some security-related commands can be used in the Apache configuration file. Http://httpd.apache.org/docs/mod/directives.html. Use the following command to reduce DoS threats: LimitRequestBody: Numeric parameter, control the HTTP request size.

LimitRequestFields: Numeric parameter that controls the number of request headers.

KeepAlive: sets the connection lifetime.

KeepAliveTimeout: specifies the time to wait for a request.

Run the following command to reduce the risk of buffer overflow:

LimitRequestFieldSize: limit the size of each request header.

LimitRequestLine: limit the size of each request line.


In addition, the Apache server administrator should often download the patch program at http://www.apache.org/dist/httpd/##to ensure the security of the Web server.

2. Sendmail server defense against DoS

Due to the nature of the email, an attacker who wants to attack the email server can easily use the email to flood the server, resulting in DoS. By setting the limits under/etc/mail/sendmail. mc, the effectiveness of such attacks will be greatly limited.

ConfCONNECTION_RATE_THROTTLE: Number of connections that the server can accept per second. By default, Sendmail does not limit the number of connections. If the number of connections reaches the limit, subsequent connections will be delayed. Recommended Value: 40.

ConfMAX_DAEMON_CHILDREN: Maximum number of child processes that the server can Fork. By default, Sendmail does not limit the number of sub-processes. If the limit is set, connections that reach the limit will be delayed. We recommend that you set the memory size to 40 based on the recommended memory size: MB.

ConfMIN_FREE_BLOCKS: the minimum number of free blocks in the queue used by the file system to accept standard SMTP (Simple Mail Transfer Protocol) mail. The smaller the number, the more vulnerable it is to attack and fatal. The default value is 100. The recommended value is 4000 or greater.

ConfMAX_HEADERS_LENGTH: Maximum number of acceptable message headers (in bytes ). The default value is unlimited. The recommended value is 64.

ConfMAX_MESSAGE_SIZE: Maximum acceptable size of a single message (in bytes ). The bigger the attack, the more vulnerable it is to be attacked and fatal. The default value is unlimited and the recommended value is 5242880.

In addition, do not place the offline/var/spool/mail/directory on the NFS shared file volume. NFS does not control the group ID. Several users with the same UID can receive and read emails from each other.

Restrict the use of overall resources

You can also restrict system resources to enhance the system's anti-DoS capability.

Edit the/etc/security/limits. conf file and add the following lines: * hard core 0

* Hard rss 10000

* Hard nproc 30


Note: "core 0" indicates that the creation of core files is prohibited; "nproc 30" limits the maximum number of processes to 30; "rss 10000" indicates that apart from root, other users can only use up to 10 MB of memory. "*" Indicates all users logged on to the system.

These are valid for users logging on to the system. With these restrictions, you can better control the usage of processes, core files, and memory in the system. Finally, edit the "/etc/pam. d/login" file and add session required/lib/security/pam_limits.so at the end of the file.