Hi everyone,
recently, we’re under a UDP DDoS attack flooding.
The number of packet from lots of source ip address is only 1.
When it comes to legitimate traffic, the packet is more than 50 packet per an IP address.
Wondering if I could create the pattern by using count and value.
detection condition : one packet for 10 seconds.
but should not detect 2, 3 or 4 packets for 10 seconds.
In general, we could make it for normal case, but i need the opposite case.
In the mentioned situation, if there is no specific string pattern, there is no way to verify that the first packet is an abnormal access like a bot. However, if the attack packet occurs only once in each IP, we can consider exceptions based on normal user behavior. A normal client such as a web browser performs retransmission when there is no response. The following signature can be used to ensure that retransmission packets from normal users are not blocked. It is inevitable to have to inspect every packet.
drop udp any any → $SERVER_NET any (msg:“UDP retransmission verification”; flow:not_established,to_server; flowbits:isnotset,udp_verify; flowbits:set,udp_verify; sid:1; )
UDP is connectionless. However, like netfilter, in suricata, when packets on both sides of the flow are identified, they are treated as established. not_established can identify the first packet of a flow without the response packet being identified, and apply exception handling using flowbits. The new flow has no flowbits applied. The option flowbits:isnotset,udp_verify is passed and flowbits:set,udp_verify is applied. Packets are dropped according to the detected signature’s action. Clients that do not receive a response from the server retransmit the first packet. Retransmission packets are sent to the server without being blocked due to flowbits:isset,udp_verify status.
This is not the right answer. This is just one case. Also, due to issues such as performance, it may not be suitable to apply to IPS.
Since normal users may be included in the configuration of NAT or Proxy, it was applied by flow, not source IP. So, the biggest problem with this signature, except for performance, is that all the drop logs for all flows are recorded in fast.log.
Attack bots have evolved a lot. Many bots can retransmit packets like normal users. I think it would be a good idea to combine and apply various factors such as Anti-DDoS or ja3.