Any network is facing huge reduction of rrc and erab attempts?
There is a TCP sync flood attack going on all over the world, but very low throughput attack.
Ue receving few DL packets every few seconds and UE cannot go to idle.
Here, increasing.
As well as payloads.
Since the #StayAtHome
We face the issue in FWA LTE network and already mitigate the attack by identifying source ips.
But it’s not throughput reduction, you will see 70% Rrc attempts and erab attempts reduction.
Due to UE is always in Rrc-Connected mode.
What is a SYN flood attack
TCP SYN flood (a.k.a. SYN flood) is a type of Distributed Denial of Service (DDoS) attack that exploits part of the normal TCP three-way handshake to consume resources on the targeted server and render it unresponsive.
Essentially, with SYN flood DDoS, the offender sends TCP connection requests faster than the targeted machine can process them, causing network saturation.
Attack description
When a client and server establish a normal TCP “three-way handshake,” the exchange looks like this:
- Client requests connection by sending SYN (synchronize) message to the server.
- Server acknowledges by sending SYN-ACK (synchronize-acknowledge) message back to the client.
- Client responds with an ACK (acknowledge) message, and the connection is established.
In a SYN flood attack, the attacker sends repeated SYN packets to every port on the targeted server, often using a fake IP address. The server, unaware of the attack, receives multiple, apparently legitimate requests to establish communication. It responds to each attempt with a SYN-ACK packet from each open port.
The malicious client either does not send the expected ACK, or—if the IP address is spoofed—never receives the SYN-ACK in the first place. Either way, the server under attack will wait for acknowledgement of its SYN-ACK packet for some time.
Progression of a SYN flood.
During this time, the server cannot close down the connection by sending an RST packet, and the connection stays open. Before the connection can time out, another SYN packet will arrive. This leaves an increasingly large number of connections half-open – and indeed SYN flood attacks are also referred to as “half-open” attacks. Eventually, as the server’s connection overflow tables fill, service to legitimate clients will be denied, and the server may even malfunction or crash.
While the “classic” SYN flood described above tries to exhaust network ports, SYN packets can also be used in DDoS attacks that try to clog your pipes with fake packets to achieve network saturation. The type of packet is not important. Still, SYN packets are often used because they are the least likely to be rejected by default.
Methods of mitigation
While modern operating systems are better equipped to manage resources, which makes it more difficult to overflow connection tables, servers are still vulnerable to SYN flood attacks.
There are a number of common techniques to mitigate SYN flood attacks, including:
Micro blocks —administrators can allocate a micro-record (as few as 16 bytes) in the server memory for each incoming SYN request instead of a complete connection object.
SYN cookies —using cryptographic hashing, the server sends its SYN-ACK response with a sequence number (seqno) that is constructed from the client IP address, port number, and possibly other unique identifying information. When the client responds, this hash is included in the ACK packet. The server verifies the ACK, and only then allocates memory for the connection.
RST cookies —for the first request from a given client, the server intentionally sends an invalid SYN-ACK. This should result in the client generating an RST packet, which tells the server something is wrong. If this is received, the server knows the request is legitimate, logs the client, and accepts subsequent incoming connections from it.
Stack tweaking —administrators can tweak TCP stacks to mitigate the effect of SYN floods. This can either involve reducing the timeout until a stack frees memory allocated to a connection, or selectively dropping incoming connections.
Obviously, all of the above mentioned methods rely on the target network’s ability to handle large-scale volumetric DDoS attacks, with traffic volumes measured in tens of Gigabits (and even hundreds of Gigabits) per second.
Due to increased user activity…user will not release RRC and ERAB that frequently and attempts will reduce…we have observed it in our network.
If it’s Huawei, you can check active user counter… Is there a sudden jump in active user count?
Any documented reference here pertaining to mobile networks?
It’s a very good point to study!
But this reduction happen gradually right?
But our case is sudden.
Any changes done related to RRC connection state timer?
Yes it is and small packet count also slight increment.
No, UE inactivity timer is 20 Seconds since long time.
I’m trying to understand how can you saturate RRC resources with a TCP attack coming from a single UE, that while attacking will shows an increase in active RRC users.
Attack is from many source IP to our public IPs, each our public IPs is NAT and PAT to many local IPs which belongs to UE.
So attacker just send a TCP request to one Public ip by changing destination port can reach it to many users.
When user receive these sync packets in every other second for example, UE will always stay in Rrc Connected.
Every network has anti DDOS solutions to mitigate such attacks, but when it comes in very low throughput, anti-ddos systems cannot detect it.
Because anti-ddos detection and cleaning is based on predefined throuput of attacker traffic.
In this case it was very low throughput attack.
It’s low throughput but it can saturate radio resources.
They do not consume resources, but prevent legit users from consuming theirs.
We face such attacks once in a while for our network but not sure it can be global for all operators and UEs.
This part I didn’t know… this should be part of the core NW.
I was trying to understand how would it be possible doing such an attack, coming from the radio side…
So it comes from the other side.
So you can get packets forwarded to UE, by using a combination of different public IP addresses and TCP ports? Is that it?
Yes, normally ddos attacks are to Saturate server and router resources, but it should send in Gigs of throughput traffic, in this case it is low throughput, don’t know the purpose of attack.
Yes, that is the function of CGN node In a network.
But attacker should monitor ongoing tcp flows to do that.
Note: CGN is just a router, but dedicated for NAT and PAT function, different networks may call it by diferent name based on Vendor.
We used wireshark at eNB to capture C plane traffic and filtered the IP which was having the most TCP connections to UEs and found it to be the attacker IP.
So trying to spot this attack from stats…
- increase in RRC active users
- increase PRB utilisation
- lower throughput (expected, due to higher number of RRC active users + higher PRB utilisation)
- decrease in traffic (not normal at all, considering all previous findings)
