My network is being flooded with UDP packets, Denial of Service attack, soucing from Cloud flare and Google IP Addresses, with 200-300 mbps minimum traffic, the destination in my network are IP prefixes that is currnetly not used but still getting traffic with high volume.
The traffic is being generated with high intervals between 10-30 Minutes for each time, maxing to 800 mbps
When reached out cloudflare support, they mentioned that there services are running on Nat so they can’t pin out which server is attacking based on ip address alone, as a single IP has more than 5000 server behind it, providing 1 source IP and UDP source port, didn’t help either
Any suggestions?
which attack protocol are seeing? I suspect you’re seeing DNS based amplification or similar, in which case you can’t really pinpoint the attack source…
800Mbps is not a whole lot of traffic - does it cause any disruptions to you? If the prefixes are not in use, I would suggest the use of RTBH (null routing / blackholing)
For short term relief, you might consider asking your upstream provider to block the unused IPs in your network that are being attacked. It may not get everything, but it could drop the volume considerably. Just be sure that the provider blocks them silently, without sending “no route to host” ICMP back to the hacker. That way the hacker won’t know that you’ve done anything and reshape his attack.
I'm going to take a guess that ahmed is:
AS | BGP IPv4 Prefix | AS Name
198735 | 185.51.220.0/22 | HRINS-AS, IQ
198735 | 185.51.220.0/24 | HRINS-AS, IQ
198735 | 185.51.221.0/24 | HRINS-AS, IQ
198735 | 185.51.222.0/24 | HRINS-AS, IQ
198735 | 185.51.223.0/24 | HRINS-AS, IQ
198735 | 217.145.228.0/22 | HRINS-AS, IQ
198735 | 217.145.228.0/24 | HRINS-AS, IQ
198735 | 217.145.229.0/24 | HRINS-AS, IQ
198735 | 217.145.230.0/24 | HRINS-AS, IQ
198735 | 217.145.231.0/24 | HRINS-AS, IQ
198735 | 5.1.104.0/21 | HRINS-AS, IQ
198735 | 5.1.104.0/24 | HRINS-AS, IQ
198735 | 5.1.105.0/24 | HRINS-AS, IQ
198735 | 5.1.106.0/24 | HRINS-AS, IQ
198735 | 5.1.107.0/24 | HRINS-AS, IQ
198735 | 5.1.108.0/24 | HRINS-AS, IQ
198735 | 5.1.109.0/24 | HRINS-AS, IQ
198735 | 5.1.110.0/24 | HRINS-AS, IQ
198735 | 5.1.111.0/24 | HRINS-AS, IQ
and that their upstream is:
41032 | 62.201.210.181 | IQNETWORKS, IQ
and that ideally IQnetworks can block this traffic for them...
you're forgetting if that was to be amplification, the source addresses would not be within Google or CloudFlare ranges (especially not CloudFlare, as they are not running a vulnerable recursor, and merely authoritative nameservers), the only possibility would be Google as in Google Cloud, with clueless people running open recursors that are prone to DNS(-SEC) reflection. It would pretty much be beyond the point using authoritative servers of parties such as CloudFlare as a) the scope of replies you will get is limited, b) they will high likely take a close look at your (forged) DNS queries and c) they will most certainly have limits in place defeating the entire point.
In any regard, <1 Gbps is pretty piss poor for an amplification attack too.
In any regard, <1 Gbps is pretty piss poor for an amplification attack too.
We’ve observed a customer receiving relative low volume attacks in the last week (so low they didn’t trigger our alarms).
My working theory is that with the Dec 3rd release of Halo Reach for PC, there are gamers attempting to lag, but not knock off, their opponents. This would be one reason to target adjacent unused addresses.
Normally these attacks are spoofed IPs, usually amplification attacks based on UDP using DNS/LDAP etc. This is something that is common and usually is towards schools, financial institutions. This an easy attack to orchestrate by anyone, most of these attacks can be launch via stresser services online. 800mbs to most smaller ISPs is a lot of traffic and can deeply impact not only the victim prefix but other non-targeted customers, as traffic consumed by the attack will cause problems for all users on that circuit.
There's a few things you can do, ask your upstream provider to rate limit UDP packets towards you. Rate limit them to what you think a normal UDP rate should be. I don’t recommend blocking UDP as you will block legit UDP packets from reaching any of your customer when the attack is not ongoing. Note most larger providers will not help or care to help, I know Comcast probably will not help you, their support techs will have no idea what you are taking about neither will most entry level engineers. However, it's worth taking a shot and asking you upstream provider.
Another way you can minimize this is if you are multi-hommed with BGP. In this case take the targeted prefix and advertise to be preferred through one of your upstreams and move all over prefixes to the other link. This will ensure that most of your customers will not be impacted during the DDOS. Once you have the victim prefix preferred on that specific BGP link then you can rate limit on your edge, or the provider can do this for you. You will still have the full force of the attack at the edge unless you can get one of your providers to help you out. With DDOS you can only mitigate it and not necessarily stop it. Someone will always get that DDOS traffic. rather is your, your provider or your customers. The problem is figuring out where you want the traffic to be rate-limited, stopped etc and that who's expense.
BTW those stresser services are usually free for a set about 0-15 min than you must pay thus why its not ongoing.
But, as others have pointed out, plenty to knock a single subscriber, shared access link (DOCSIS, wireless, or even well loaded GPON), or even a small regional PoP down. Plenty of opportunity for mayhem even with just a couple 100Mbps which is trivial to come up with these days as the spread of consumer-accessible speeds keeps growing. Keeping it small makes it less likely to get noticed and, perhaps even more importantly for the perpetrator, harder for the networks responsible for the reflection/amplification to track down the problem using traffic analysis as well as coming in on the lower end of the "how much do I care?" part of the abuse team's line-up.
Years ago, we looked at netflow data and precursors to attacks, and found that UDP 3074 Xbox Live was showing up just prior to the attacks...and through other research we concluded that gamers are a big cause of large ddos attacks.... apparently they go after each other in retaliation
I've crafted a series of things for dealing with the results of volumetric ddos attacks... I've had attacks in upwards of 50 or 60 gig as I recall.... across all of my (3) internet connections at times
- deny acl's ... for ports/protocols that I know are absolutely not needed
- policers of various well known port attack vectors (gleaned from netflow data)
- policers of well-known *good* ports/protocols (like ntp, dns, etc) to some realistic level
- a repeat-victims list of ip's with policing udp for this group (note1)
- rtbh (note2)
Note 1 - Also, I've learned that if a customer has been attack once, the chances of them being the target of an attack again is high....so by crafting the repeat victims list, you can catch next-day attacks of differing vectors.
Note 2 - for sustained attacks lasting a long time (30 mins, an hour, etc), we trigger a bgp/community route that goes out to the inet cloud and stops attack further into the upstream providers network... I know I "complete" the attack, but, I save my network
...I use an old cisco 2600 as my trigger router and wrote a job aid that I shared with the NOC for triggering rtbh when needed, couple commands.
...I would like to automate my rtbh using what I understand is a possibly use case for FastNetMon, but haven't got around to it
I also wonder if team cymru's utrs project and other things like that would benefit my security posture.
You might want to downpref these to a scavanger class, instead of
police. Since ultimately policing makes it just easier to ddos the
service, which is actually needed.
