IDS vulnerabilities and limitations

IDS vulnerabilities and limitations

Creation Time:
Article attributes: original
Source: www.cnsafe.net
Article submitted: Mayi (mayi99_at_263.net)

1. NIDs vulnerabilities and limitations
NIDs analyzes packets obtained from the network to detect and identify unauthorized or abnormal phenomena in the system.

1.1 Network limitations

1.1.1 Switching Network Environment
Because the shared hub can perform network listening, it will pose a great threat to network security. Now, switches are basically used on the network, especially on high-speed networks, thus causing trouble for NIDs network listening.

1.1.1.1 listener Port
Currently, better vswitches support listening ports, so many NIDs are connected to listening ports.
Generally, the full duplex mode is used to connect to a vswitch. That is, the two-way traffic on a 200 MB vswitch may reach 100 MB, but the traffic on the listening port can reach MB at most, resulting in packet loss.
To save vswitch ports, it is very likely to be configured as one vswitch port to listen to multiple other ports. Under normal traffic, all listening ports can be monitored, but when attacked, network traffic may increase, so that the total traffic on the monitored port exceeds the upper limit of the listening port, resulting in packet loss on the switch.
When a vswitch is under heavy load, the speed of the listening port cannot catch up with the speed of other ports, resulting in packet loss.
Adding listening ports means that more switch ports are required, which may require the purchase of additional switches, even modify the network structure (for example, a VLAN originally on a switch needs to be distributed to two switches now ).
Vswitches that support listening are much more expensive than vswitches that do not support listening. Many networks do not consider network listening requirements during design. The purchased vswitches do not support network listening, or the listening performance is poor, therefore, you need to change the vswitch when preparing to install NIDs.

1.1.1.2 shared Hub
Connect a shared hub to the network cable to be monitored to implement the listening function. For small companies, placing an NIDS between the company and the Internet is a relatively cheap and easy-to-implement solution.
Using the hub will change the network connection of the host from full duplex to half duplex. If the data sent by the NIDs through this hub, the possibility of conflict will be increased.

1.1.1.3 cable shunting
A special device is used to directly copy the same data from the network cable. Two copies (one copy in each direction) are copied from the network cable and connected to the switch that supports listening, connect NIDS to the vswitch again. This solution does not affect the existing network system, but requires a vswitch, which is expensive and faces the same problems as the listening port.

1.1.2 network topology limitations
For a complex network, careful packet sending can lead to different content or sequence of packets received by NIDs and protected hosts, thus bypassing NIDs monitoring.

1.1.2.1 other routes
Due to some non-technical factors, other routes may bypass NIDS to reach the protected host (for example, a neglected modem, but NIDS is not installed next to the modem ).
If the IP Source Route Option permits, you can bypass NIDs by carefully designing an IP route.

1.1.2.2 TTL
If the number of NIDs packets reaches is different from that of the protected host. You can set the TTL value so that a data packet can only be received by the NIDs or only by the protected host, so that the NIDs sensor is different from the data packet received by the protected host, this bypasses NIDs monitoring.

1.1.2.3 MTU
If the MTU of the NIDs is different from the MTU of the protected host (the MTU settings of the protected host are different), you can carefully set the MTU between the two, this package cannot be split, so that the NIDs sensor is different from the data packet received by the protected host, thus bypassing NIDs monitoring.

1.1.2.4 TOS
Some network devices process the TOS option. If the process of NIDS is different from that of the network devices connected to the protected host, carefully set the TOS option, this will lead to a different sequence of the NDIS sensor and the packets received by the protected host, which may lead to inconsistent data packets after NIDs reorganization with the data packets of the protected host, this bypasses NIDs monitoring (especially in UDP packets ).

1.2 limitations of Detection Methods
Common NIDs detection methods include feature detection, exception detection, status detection, and protocol analysis. In practice, most commercial intrusion detection systems adopt several detection methods at the same time.
NIDs cannot process encrypted data. If the data is encrypted during transmission, NIDs cannot be processed even if it is simply replaced, such as using SSH, https, and compressed files with passwords, can effectively prevent NIDs detection.
NIDs cannot detect replay attacks, man-in-the-middle attacks, and network listening.
Currently, NIDs cannot effectively detect DDoS attacks.

1.2.1 system implementation limitations
Because NIDs-protected hosts run a wide variety of programs and even implement the same protocol, intruders may use different implementations of different systems to collect system information (for example, NMAP uses TCP/IP fingerprints to identify the operating system) or select attacks, because NIDs are unlikely to be familiar with different implementations of these systems, they may be bypassed by intruders.

1.2.2 limitations of exception detection
Exception detection usually uses statistical methods.
Exception detection requires a large number of original audit records. A pure statistical intrusion detection system will ignore intrusions that do not or seldom generate audit records that affect statistical rules, even if it has obvious features.
Statistical methods can be trained to adapt to the intrusion mode. When an intruder knows that his activity is being monitored, he can study the statistical methods of the intrusion detection system, generate audit events within the acceptable scope of the system, and gradually train the intrusion detection system, therefore, the corresponding activity profile deviates from the normal range, and the intrusion event is treated as a normal event.
Application systems are becoming more and more complex. Many subject activities are difficult to portray with simple statistical models, while complex statistical models cannot meet real-time detection requirements in terms of computing workload.
The threshold value in the statistical method is difficult to determine effectively. A value that is too small will generate a large number of false positives, and a large value will generate a large number of false negatives, for example, if 200 half-open TCP connections are configured as syn_flooding in the system, 199 half-open connections established by intruders per second will not be considered as attacks.

1.2.2.1 slow scanning
Exception detection is often used to detect port scans and DoS attacks. NIDs has a traffic log limit. If the scan interval exceeds this limit, NIDs ignores this scan.
Although NIDs can be configured with a long limit, the longer the configuration, the more system resources are required, the more likely it will be to be attacked by DoS attacks against NIDs.

1.2.3 limitations of Feature Detection
The update of detection rules always lags behind the update of attack methods. Currently, a new vulnerability is published on the Internet. The next day, you may find the method and code used for attacks on the Internet, however, it may take several days for the corresponding detection rules to be summarized on average. There is a time difference between discovering a new intrusion method and upgrading the rule repository/knowledge base for the user. There will be plenty of time for intrusions.
Many published attacks do not summarize the corresponding detection rules or the detection rules have a high false positive rate. In addition, more and more Hackers tend not to publish their discovered vulnerabilities, making it difficult to summarize the Attack Characteristics of these attacks.
Currently, the sorting of new rules is mainly completed by volunteers or manufacturers. Users can download and use the new rules by themselves. In fact, user-defined rules are rarely used, which facilitates intruders while facilitating users: intruders can first check all the rules and then perform intrusion by means that are not detected, greatly reducing the probability of being detected by NIDs.
Currently, the rules are mainly for hacking tools or methods published on the Internet. However, for many hacking tools released with source code, many intruders can make simple changes to the source code (for example, Hackers often modify the trojan code) and generate a variant of the attack method to bypass NIDs detection.

1.2.4 protocol restrictions
For application-layer protocols, generally NIDs only process commonly used protocols such as HTTP, FTP, and SMTP. A large number of protocols are not processed, and they are unlikely to be processed in full, attackers can bypass NIDs checks directly for attacks against some special protocols or custom protocols.

1.2.5 intrusion variants

1.2.5.1 HTTP attack variants
The duplicate directory delimiter, '/' '//'.
In the current directory, '/cgi-bin/phf' is changed to'/cgi-bin/./phf '.
In the upper-level directory, '/cgi-bin/phf' is changed to'/cgi-bin/XXX/../phf '.
URL encoding. '/cgi-bin/' is changed to '% 2fcgi-bin /'.
Use tabs and other delimiters to replace spaces.
Null method, 'Get % 00/cgi-bin/phf '.
Use methods other than get, such as post.
Change the Parameter order and add useless parameters.
For IIS, you can also use the following methods:
Directory delimiter in DOS/win, '/winnt/system32/cmd.exe' is changed to '/winnt/system32/cmd.exe '.
For example, cmd.exe is changed to cmd. EXE.
Iisquadratic decoding. For example, if the character. exeis changed to 255.2563md.exe, % 25 is decoded as '%', and % 63 is decoded as 'C '.
Unicode=, for example, cmd.exeto %c010963md.exe. Unicode encoding is complex. Currently, only a few NIDs can decode it.

1.2.5.2 Telnet attack variants
Use the backspace key.
Use the tab key to complete the command.
Use shell to execute attack code.
Use macros.
Add useless parameters.
In fact, it is difficult for NIDS to detect local attacks connected to the server through Telnet.

1.2.6 TCP/IP protocol limitations
Because the TCP/IP design did not properly consider security at the beginning, the security of IPv4 is worrying. In addition to the problems caused by the network structure, there are some limitations below.

1.2.6.1 IP sharding
Packet sharding. Some NIDs can bypass NIDs if they cannot be reorganized or exceed the processing capability.
An IP datagram can contain a maximum of 8192 parts. A performance parameter of NIDS is the maximum number of IP parts that can be reorganized.
Each time NIDs receives a new IP address datagram IP segment, it starts a segment reorganization process. After the reorganization is completed or timed out (usually 15 seconds), the reorganization process is closed, A performance parameter of NIDS is the number of IP packets that can be reorganized at the same time.
The maximum size of an IP datagram is 64 KB. To prepare to receive an IP datagram, NIDs will prepare enough memory to accommodate the upcoming parts, A performance parameter of NIDS is the maximum length of IP datagram that can be reorganized.
Combined with the preceding three parameters, this is the number of IP datagram restructures that NIDs can simultaneously prepare for maximum value (for example, 64 K) during the timeout time (for example, 15 seconds.
If the data packets received by NIDs exceed the above limits, NIDs will have to packet loss, resulting in DoS attacks.

1.2.6.2 IP overlapping parts
When reorganizing an IP packet, if you encounter overlapping parts, the processing methods of each operating system are different. For example, some systems use the first received parts (Windows and Solaris ), some slice will be received later (BSD and Linux). If the data of the overlapped slice is different, and the NIDs processing method is different from that of the protected host, the data packets after the NIDs reorganization are inconsistent with the data packets of the protected host, thus bypassing the NIDs detection.
For example, the TCP or UDP destination port can overlap, and then penetrate the vast majority of firewalls, and may bypass NIDs.
It can also overlap the TCP flag so that NIDs cannot correctly Detect tcp fin packets, so that NIDs can quickly reach the maximum number of TCP connections that can be monitored at the same time; so that NIDs cannot correctly detect the tcp syn packet, so that NIDs cannot detect the appropriate TCP connection.

1.2.6.3 TCP segments
If NIDs cannot be reorganized over TCP streams, you can use TCP segments to bypass NIDs.
Some Abnormal TCP segments will confuse some NIDs.

1.2.6.4 TCP un-sync
Sending error serial numbers, repeated serial numbers, and reverse transmission order in TCP may bypass NIDs.

1.2.6.5 OOB
Attackers can send OOB data. If the application of the protected host can process OOB, NIDs may bypass NIDs because it is impossible to accurately predict the amount of normal data in the buffer when the protected host receives OOB.
When processing OOB, some systems discard the starting 1-byte data (for example, Apache in Linux, but IIS does not, if a TCP segment with the OOB option is included, the data after the NIDs stream reorganization may be inconsistent with the application of the protected host, thus bypassing NIDs.

1.2.6.6 t/tcp
If the target host can process transaction TCP (currently seldom supported by the system), attackers can send transaction TCP, and NIDs may not process the same as applications on the protected host, this may bypass NIDs.

1.3 resource and processing capability limitations

1.3.1 DoS attacks against NIDs.

1.3.1.1 large traffic impact
An attacker can send a large amount of data to a protected network. If the processing capability of NIDS is limited, packet loss may occur, which may cause leakage of intrusion.
The network packet capture capability of NIDS is related to many factors. For example, if each packet contains 1500 bytes, NIDs can process more than 100 Mb/s, or even more than 500 Mb/s. However, if each packet contains only 50 bytes, 100 Mb/s traffic means 2000000 packets/s, which will exceed the processing capability of most network adapters and switches.

1.3.1.2 IP fragmentation attack
Attackers can send a large number of IP fragments (such as the targa3.) to the protected network, which exceeds the capability of NIDS to reorganize IP fragments at the same time, leading to the underreporting of attacks by using the IP sharding technology.

1.3.1.3 TCP connect flooding
Attackers can create or simulate a large number of TCP connections (through the overlapping IP address sharding method described above), exceeding the maximum number of TCP connections simultaneously monitored by NIDs, as a result, redundant TCP Connections cannot be monitored.

1.3.1.4 alert flooding
Attackers can refer to the detection rules published on the network to intentionally send a large amount of data (such as stick attacks) that will trigger NIDS alarms at the same time, which may exceed the speed at which NIDs sends alerts, in this way, the network administrator receives a large number of alarms, making it difficult to identify the real attack.
If one alarm is generated when 100 bytes are sent, 50 Alarms can be generated every second through dial-up access, and 10000 Alarms can be generated every second within a 10 m lan.

1.3.1.5 log flooding
An attacker sends a large amount of data that will trigger NIDS alarms. This will eventually exhaust NIDs's log space and delete previous log records.

1.3.2 memory and hard disk restrictions
If NIDs wants to improve the IP Fragment reorganization and TCP connection monitoring capabilities that can be processed at the same time, more memory will be needed for buffering. If NIDs memory allocation and management are poor, the system will consume a large amount of memory in some special circumstances. If you start to use virtual memory, memory jitter may occur.
Generally, the hard disk speed is far less than the network speed. If the system generates a large number of alarm records to the hard disk, it will consume a lot of system processing capabilities. If the system records the original network data, storing large amounts of and high-speed network data requires expensive large-capacity raid.

1.4 NIDs-related system vulnerabilities
NIDs itself should have high security. Generally, no IP address is available for the network adapter used for listening, and no ports are opened for other network adapters. However, systems related to NIDs may be attacked.

1.4.1 console host Security Vulnerability
Some systems have separate consoles. If attackers can control the host where the console is located, they can control the entire NIDs system.

1.4.2 vulnerability of sensor-console Communication
If the communication between the sensor and the console can be successfully attacked by attackers, the system will be affected. For example, ARP spoofing or syn_flooding.
If the communication between the sensor and the console is in plain text or simply encrypted, it may be attacked by IP spoofing or replay attacks.

1.4.3 vulnerabilities of other devices related to system alarms and their communication
If an attacker can successfully attack other devices related to system alarms, such as the email server, the sending of alarm messages will be affected.

2 HIDS vulnerabilities and limitations

2.1 resource limitations
Because HIDS is installed on protected hosts, the occupied resources cannot be too much, which greatly limits the detection methods and processing performance.

2.2 operating system limitations
Unlike NIDs, the manufacturer can customize a secure enough operating system to ensure the security of NIDs. The security of HIDS is restricted by the operating system of the host. if the system is cracked, HIDS will be cleared soon. If the HIDS is a single machine, it can only detect unsuccessful attacks. If the HIDS is a sensor/console structure, it will face the same attacks on the relevant system as NIDs.
Some HIDS consider increasing the security of the operating system (such as lids ).

2.3 System Log restrictions
HIDS detects suspicious behaviors by monitoring system logs, but the system logs of some programs are not detailed enough or there is no logs. Some intrusion behaviors are not recorded by programs with system logs.
If the system does not have a third-party log system installed, the system's own log system will soon be attacked or modified by intruders, and the intrusion detection system usually does not support third-party log systems.
If HIDS does not check system logs in real time, attacks using automated tools may completely complete all attack engineering and clear the traces left in system logs during the detection interval.

2.4 The modified system core can cheat file Inspection
If intruders modify the system core, they can cheat the tool based on the file consistency check. This is like some viruses. When they think they are being checked or tracked, they will provide the original files or data to the checking tool or tracking tool.

2.5 network detection limitations
Some HIDS can check the network status, but this will face many problems faced by NIDs.

ID: Mayi
QQ: 711705
MSN: cnsafe@msn.com
Homepage: www.mayia.com www.cnsafe.net