Since last July or August, denial of service attacks have been popular on the internet, and are now on the rise a year later. In addition to the use of blocking software, is there any other way?
Service overload
Service overload occurs when a large number of service requests are sent to a service daemon on the same computer. These requests are issued in various ways, and many are intentional. In a time-sharing mechanism, computers need to handle these flood-like requests, so busy that they cannot handle common tasks, and many new requests are discarded. If the object of the attack is a service based on a TCP protocol, these requests will be sent back to further increase the burden on the network.
Typically, administrators can use network monitoring tools to discover this attack, analyze the problem through host lists and network address lists, or log on to a firewall or router to discover whether the attack came from outside the network or within the network.
Message Flow
Message flow often occurs when a user sends a large number of packets to the target host on the network, and the message flow can cause the target host to process slowly, and it is difficult to handle the task normally. These requests, in the form of requesting a file service, requesting a login, or requesting a response, are constantly flocking to the target host, aggravating the processor load on the target host, and causing the target host to consume a large amount of resources to respond to these requests. In extreme cases, the message flow can cause the target host to panic because there is no memory space to buffer or other errors.
Message flow is primarily for network servers. An attacked server may not be able to respond to network requests for a period of time. The attacker uses this opportunity to write a program to answer a request that should have been answered by the server. Suppose an attacker has written a program that sends thousands of ECHO requests per second to the target host to "Bomb" NIS servers. At the same time, an attacker attempts to log on to a privileged account on a workstation. At this point, this workstation will ask the NIS password for the true NIS server. However, a real NIS server is not responding to this request quickly because it is under attack. At this point, the attacker's host can be disguised as a server, responding to the request, and providing an incorrect message, for example, that there is no password. Under normal circumstances, the real server will indicate that the packet is wrong, but because the server is overloaded so that it does not receive the request or is not received in time, can not respond. The requesting client then handles the attacker's logon request based on the wrong answer.
An effective way to deal with this attack is to configure a monitor to separate the network into smaller subnets. Monitors help detect and prevent such attacks, but they do not completely eliminate them.
"Stick" attack
The TCP/IP implementation program in many UNIX systems has the potential to be abused. A TCP connection establishes a connection through a three-time handshake. If an attacker makes multiple connection requests, initially establishing a connection, but does not complete the subsequent connection steps, the receiver retains many of these half-open connections, consuming a lot of resources. Typically, these connection requests use a forged source address, and the system has no way to track the connection, only to wait for the connection to be released because of a timeout. The best way to deal with this type of attack is to deny connection requests from unknown hosts or networks outside the firewall, or to increase restrictions on the protocols used, but any fixed restrictions are inappropriate. Users can modify the operating system's source code, so that there is a time-out value, before rejecting a new connection, there is a limit to the number of concurrent connections, but the operating system is not easy to modify the source code.
Syn-flooding attack
In a syn-flooding attack, an attacker uses a disguised address to send as many requests as possible to the target computer to occupy the target computer resource more often. When the target computer receives such a request, it uses system resources to service the new connection, and then replies to a positive reply syn-ack. Because Syn-ack is returned to a disguised address, there is no response, so the target computer will continue to try to send syn-ack. Some systems have default response times and timeout times, only a certain number of times, or a timeout, when the resource is freed. The Windows NT 3.5x and 4.0 default settings can be repeatedly sent syn-ack5 times. After each resend, the wait time doubles. The user can use the netstat command to check the current status of the connection line to see if it is in a syn-flood attack. As long as the netstat-n-ptop is entered on the command line, it shows all the connection status of the machine. If there is a large number of connection lines in the Syn-received state, the system may be suffering from this type of attack. Hackers who implement such an attack cannot gain access to any of the system's rights. However, for most TCP/IP protocol stacks, the number of connections in the syn-received state is very limited. When the port limit is reached, the target computer usually responds and all additional connection requests are reset until the allocated resources are released.