Case study of UDP Attack Packets penetrating iptables Firewall

A real case analysis of UDP Attack Packets that penetrate the iptables firewall reveals some security risks that are little known when using iptables. I hope to help you!

Such attacks are rare and a good troubleshooting process.

 

Symptom

By chance, I found a very abnormal situation on a server: high CPU consumption.

Through top observation, it is found that the snmpd process continues to rise

 

Packet Capture

Restart the snmpd process. After several minutes of normal operation, an exception occurs again. At this time, it is caused by special data packets.

To verify the speculation, we captured packets on UDP/port 161 and found some clues.

Packet Capture showed that there was an attack. From the perspective of packet capture, the attack was sudden. when there was an attack:

Frequency: ≈ 10Hz

Cycle: ≈ 0.1 s

Type: Request snmpd Root Information "Linux C"

Principle: The system is in a high load state by comparing the request with a higher level of root content. Due to the high frequency, it is difficult to eliminate the high load state.

Malicious: In order to break through some stateless firewalls, the source port sport also uses the same UDP/161 as the snmpd service, which is very sinister.

 

 

Rule Check

However, the strange problem is that my firewall is based on status detection. It is easy to tell whether incoming packets come in with active requests or back packets after I send them out.

In this case, why is the snmpd message still received and processed by the system? Is there a problem with using iptables rules?

The rules are as follows:

Iptables-m state -- state RELATED, ESTABLISHED-j ACCEPT

Iptables-a input-I lo-j ACCEPT

Iptables-a input-p tcp -- dport 80-j ACCEPT

Iptables-a input-p udp -- dport 161-s IP1-j ACCEPT

Iptables-a input-p udp -- dport 161-s IP2-j ACCEPT

Iptables-a input-p udp -- dport 161-s IP3-j ACCEPT

Iptables-a input-j DROP

Through observation, no exception was found. For snmpd packets, the system only allowed access from three Special IP addresses. That's strange. How did this attack packet come in?

 

 

Conntrack Feature Analysis: difference between UDP and TCP

As we all know, iptables is only the controller of userspace. The real subject is netfilter, while conntrack is an important part of netfilter.

The core value of conntrack is to implement a state-based firewall for Linux.

In Linux, after conntrack is enabled, even UDP packets have the concepts of "NEW" and "ESTABLISHED.

However, unlike TCP, TCP has a three-way handshake. By analyzing the compliance of the data packet header during the three-way handshake, you can check whether the current data is valid.

However, UDP is different. in Linux, there are only two concepts: "Go" and "back". When the system sees the UDP packet for the first time, it is regarded as NEW. After seeing the back packet of the packet, it is considered as ESTABLISHED.

 

Reasoning

After knowing this, we can probably guess the problem. It must be related to conntrack.

Guess Out Of Control Process:

1. When the system does not start conntrack, an attack message has been requested.

2. When the system starts the conntrack mechanism, it happens to have a system return response packet, which is regarded as active data sending by the system conntrack and is in the NEW State.

3. The system's iptables rule finally blocks the packet.

However, subsequent attack packets use the same SIP/SPORT to access the same DIP/DPORT, resulting in the same connection after hash.

The attack packet is not treated as a NEW packet. The connection changes to the ESTABLISHED status.

4. In the future, all data from the SIP/SPORT to the DIP/DPORT will be unobstructed, leading to the first scene

Www.2cto.com

Verify

To prove that the reasoning is correct, a shell is deliberately written, and sleep is added to the first line-m state -- state RELATED, ESTABLISHED-j ACCEPT to increase the reproduction probability.

The experiment shows that the reasoning is completely correct. UDP Attack Packets are treated as NEW packets, and the real attack is ESTABLISHED.

The location of the first sentence is also the main cause of the problem.

 

Try to solve

In order to prevent this situation, it is feasible to put the state matching to the end?

The answer is "no", because, in the same way, status misjudgment may occur due to the time difference mentioned above.

What is the safest way?

I thought of a solution:

1. service iptables stop first

2. First write the first rule, unconditionally-j DROP anything

3. How to Write Other rules?

4. After the rule takes effect for a period of time (to ensure that this time exceeds the system response time after the snmpd packet is entered), delete the first line of the rule, let Data Flow in (like opening a gate and releasing water)

Unfortunately, the attack packets can still come in through the test. This is amazing!

/Etc/init. d/iptables stop Behavior Analysis

When you see the above doubts, you have to doubt the implementation of the stop function in the iptables script.

In theory, iptables not only clears all rules, but also deletes all modules used by iptables. This also includes conntrack.

Reasoning: If the stop function of iptables is abnormal, The conntrack cannot be correctly uninstalled, and the above method will not help.

 

 

The red part is the key statement for clearing conntrack. Continue tracking:

 

IPTABLES = iptables

IPV =$ {IPTABLES % tables} # ip for ipv4 | ip6 for ipv6

 

The script initially has the above definition, that is, the final value of IPV is "ip", and the unmount module is ip_conntrrack.

Manually verify:

 

[Root @ platinum-PT ~] # Modprobe ip_conntrack

[Root @ platinum-PT ~] # Iptables-A INPUT

[Root @ platinum-PT ~] #/Etc/init. d/iptables stop

Flushing firewall rules: [OK]

Setting chains to policy ACCEPT: filter [OK]

Unloading iptables modules: [OK]

[Root @ platinum-PT ~] # Lsmod | grep conntrack

Nf_conntrack_ipv4 22028 0

Nf_conntrack 67784 1 nf_conntrack_ipv4

[Root @ platinum-PT ~] #

 

It is observed that the conntrack is not uninstalled, but the module name is not ip_conntrack but nf_conntrack.

I seem to understand. Verify that:

 

[Root @ platinum-PT ~] # Cat/etc/redhat-release

Red Hat Enterprise Linux AS release 4 (Nahant Update 2)

[Root @ platinum-PT ~] # Uname-r

2.6.24.4-7

[Root @ platinum-PT ~] #

You know the reason:

• The system is RHEL 4U2, and the default kernel should be 2.6.9. At that time, the conntrack module used by netfilter was called ip_conntrack.
• The current kernel of the system is 2.6.24.4. The conntrack modules used by netfilter are nf_conntrack and nf_conntrack_ipv4.
• Since the/etc/init. d/iptables script of RHEL 4U2 is written for the 2.6.9 kernel, The 2.6.24.4 kernel conntrack cannot be correctly uninstalled during stop.
•  

Uninstall the conntrack Solution

Modify

Rmmod_r $ {IPV} _ conntrack

Change

Rmmod_r nf_conntrack

Because it is a custom system, no detailed judgment and dynamic adaptive work is made.

Summary

• The ACL takes effect at a special time. Therefore, conntrack mistakenly believes that the attack packet's return packet is NEW.
• Attack Packets maliciously use a fixed sport, so that conntrack mistakenly identifies a connection
• The logic of iptables rules may cause penetration attacks (although a small probability event)
• Because the System script and the kernel do not match, the conntrack cannot be correctly uninstalled, and the problem persists.