03-01-2021, 07:27 PM
(This post was last modified: 10-03-2021, 12:52 AM by RussEfarmer. Edited 1 time in total.)
When I say "DDoS", many people imagine an intimidating hackerman joining the server, and then magically the entire server starts lagging when he gives the magic word. Or maybe it's a weird guy you ticked off on the YouTube comment section, and right after he posts an intimidating message, your Internet shuts off. With the stereotype of what a DDoS attack is floating around, I wanted to explain what a DDoS attack actually is, how attackers use them to deny service, and how most attacks on our server that make them lag are almost definitely not DDoS attacks.
DDoS originates from the acronym DoS, standing for Denial of Service. The goals of these attacks are to prevent a network service from being usable normally, usually by disrupting the server computer that's running the service. Most commonly this is done with overwhelming network traffic onto that server computer. However, as the sophistication of the computer networks protecting these servers increased, the feasibility of using a single network host to send any meaningful network traffic to achieve a disruption was lowering fast. This prompts the need to distribute the attack source across dozens, hundreds or thousands of different network hosts in a Distributed Denial of Service attack, or DDoS attack.
So the goal of a Denial of Service attack is to obviously deny service. But how?
Brute force!
A very common way is to overwhelm whatever computer is offering that service to the Internet by simply sending too many network packets for it to feasibly process and understand what to do with. There are two common ways to do this:
Telling other things to use brute force for you!
Instead of using their own computer to generate overwhelming network traffic, attackers can use a technique called amplification to multiply their bandwidth to an attack target. By using network hosts running protocols that allow us to send relatively small amounts of traffic, and have that server return an even larger amount of traffic, we can exploit this to "amplify" the amount of traffic coming out of our source computer.
A relatively recent method to do this is is with the memcached protocol, a protocol used to store common web requests and database queries in memory instead of running these requests every time. Afterwards, a service (usually an internal one) can request data from the memcache, and the memcache can provide the large data from memory very quickly. So we have a protocol that allows you to request data with very little effort, and will reply with a relatively huge amount of data, and if incorrectly configured, can be done from the open internet.. can you see where this is going?
On February 28th, 2018, GitHub was victim to an amplification attack using exposed memcached servers. It was the largest DDoS attack ever performed, with a maximum traffic volume of 1.3 terabits per second of traffic being sent to GitHub's border network and DDoS mitigation network. The attack lasted 28 minutes, with amazingly, both GitHub and GitHub's DDoS protection service surviving the assault with minimal disruption.
Controlling other computers to use brute force for you!
This is probably the one you've heard of the most. Another excellent way to initiate DDoS attacks is by writing malware designed to give you remote control of an infected system, where afterwards you can instruct the infected systems to attack whoever you want, however you like. This collection of "zombie computers" is called a botnet.
This model is effective and versatile, but comes with effort. An attacker needs to successfully write malware, usually a Trojan, to compromise several hundred or thousand computers across the Internet, and have this process not be traceable back to the attacker. Additionally, an attacker needs to maintain this botnet, by creating new malware and making workarounds for security patches for existing compromised systems. This makes it infeasible for a random threat actor wanting to cause trouble to perform, and those who do perform it, offer their services in exchange for money. Most of these are not explicitly advertised as "DDoS" tools, as this would draw attention, but if you google "network stress test service" you'll definitely find something.
The most famous DDoS attack performed with a botnet was in 2004, through the largest, most expensive and fastest spreading computer virus to date. W32.MyDoom@mm "mydoom" was an email worm discovered on Jan 26th, 2004 at 8am by McAfee security engineers. By 4pm on the same day, web traffic slowed 10% overall, with 50% of email messages being sent across the internet originating from infected systems. On February 1st, a DDoS attack consisting of approximately 1 million infected computers was directed towards www.sco.com, with the attack being so severe that the website was temporarily removed from the DNS by DNS service providers.
With software vulnerabilities!
The kind of DoS (usually not DDoS) attacks we almost exclusively see are called application layer denial of service attacks, where instead of attacking the network and transport layers of the network stack, an attacker attacks the application directly using a vulnerability in the software. This type of attack flies under the radar of just about every DoS protection a server has, because it's not a DoS in the traditional "spam random garbage at the server until it goes down" fashion. These attacks use known exploits in the software they are attacking (like an outdated or unpatched version of Apache webserver, or in our case, a 20 year old video game server) to slow performance or even stop the application from working.
In Garry's Mod, I call these "lag scripts" (because they are NOT a DDoS), which are a feature in many paid hack clients. I don't know what mechanism makes these attacks work, but I am thankful that it is difficult enough to perform to warrant charging money for the software that can do it.
So if our server only sees these "lag scripts", are normal DDoS attacks still a threat to our server?
The answer is technically yes, but no. Is 50 caliber sniper rifle pointed at your head a threat? Yes. Is it still a threat when you're standing behind 5 inches of steel plating? A little bit, but not really.
Dinkleberg's TTT and Dinkleberg's Prophunt (and most likely the other two servers) use NFOservers. This hosting provider uses in house DDoS protection, extremely high speed links to the Internet, and a very high availability internal network. These selling points drive up the price a lot, but the fact that we've been using this server host for so long has been a huge factor for the server's success. Our latency is EXTREMELY low compared to other servers, and we are only matched by other servers using NFO. We are basically always at the top of the server list as long as you are on the eastern United States, DESPITE having enterprise grade DDoS protection.
Unless the threat actor has either an absolutely gigantic botnet or has a nasty zero-day exploit up their sleeve, if a DDoS attack is launched on one of our servers, it's going to be completely unnoticeable to the players. In a worst case, NFO will crank up the firewall on your box a little bit and players will experience a few ms higher latency, but there will not be an interruption of service. Only during a MASSIVE attack will we ever have our server disrupted.
Do player bans prevent DDoS attacks?
An attacker doesn't need to be connected to the server, or even know what the server does, to launch a DDoS against it. However, denial of service done through lag hacks require the player to be connected, so banning them solves the problem.
Do IP bans prevent DDoS attacks?
No, ULX IP bans work at the application layer and provide no traffic blocking. These are the exact same thing as steamid bans, but with IPs. Besides, with a DDoS attack, traffic comes from multiple IPs, so even if blocking was provided by banning IPs through ULX, it wouldn't be effective unless you banned every single attacker IP. This wouldn't be necessary though, because NFO's DDoS protection initiates temporary blocks on attacker IPs during an attack. IP bans do protect against lag hacks by disconnecting the player, but IP bans are significantly less effective than steamid bans because of the way IP addresses are given to internet users by their ISPs. Ban evasion is as simple as unplugging your router and plugging it back in.
If we are safe against DDoS attacks, what can we do about lag hacks?
Detecting the exact player doing it is difficult (unless they're a moron and say something like "ddosing your server lul" in chat), but the only thing you can do is ban the player responsible. A trick I picked up over the years is that if a player is using a sophisticated enough hacked client, running the ulx getcommandtable command on them won't return anything because the hack blocks this data from being sent. If the table doesn't show up, they are hacking.
I wrote this over a few days because the nerd in me gets irritated at people saying things are DDoS attacks when they aren't ;) hopefully you can find this somewhat useful/entertaining even though this is one chonkin forum post.
DDoS originates from the acronym DoS, standing for Denial of Service. The goals of these attacks are to prevent a network service from being usable normally, usually by disrupting the server computer that's running the service. Most commonly this is done with overwhelming network traffic onto that server computer. However, as the sophistication of the computer networks protecting these servers increased, the feasibility of using a single network host to send any meaningful network traffic to achieve a disruption was lowering fast. This prompts the need to distribute the attack source across dozens, hundreds or thousands of different network hosts in a Distributed Denial of Service attack, or DDoS attack.
So the goal of a Denial of Service attack is to obviously deny service. But how?
Brute force!
A very common way is to overwhelm whatever computer is offering that service to the Internet by simply sending too many network packets for it to feasibly process and understand what to do with. There are two common ways to do this:
- SYN flooding - In the Transmission Control Protocol (TCP), in order to connect to a server and start sharing data, you need to perform something called a handshake to open the connection. This handshake starts with a SYN (sync) segment, which gives the server the necessary information to synchronize your connection settings for error free transmission. Afterwards, the server the server sends an ACK(nowledgement) segment verifying that it got your information, and then the server sends you its SYN segment. Finally, you ACK the server's SYN, and you're ready to transmit.
Now the problem comes with an attacker sending millions of SYN segments to a listening TCP port per second, usually with a different spoofed source address every time. The server will get these SYNs, send a SYN-ACK back for every single one, and then wait until the timeout period ends for you to respond with an ACK. If enough computer resources are spent replying to and waiting on these fraudulent SYN segments, there won't be enough resources to properly respond to legitimate connection requests, meaning they cannot connect to the server.
This attack is mitigated using several clever defense mechanisms outlined in RFC4987, and isn't very effective without massive traffic volumes.
- UDP flooding - the User Datagram Protocol (UDP), in contrast to TCP, is a very simple networking protocol. User sends data, server (probably) gets data, and whatever application that data goes to has to figure out the rest. In a UDP flood, bogus UDP packets are sent to the server on random ports, where the server uses CPU time to check if an application is listening on the port. If it's not, it uses even more CPU time to send an ICMP Destination Unreachable packet back to the source IP. The idea here is the server will waste time spewing out ICMP packets to random addresses, but this is easily mitigated by reducing the number of ICMP packets that are allowed to be sent per second. Again, this attack isn't effective without massive volumes of traffic.
Telling other things to use brute force for you!
Instead of using their own computer to generate overwhelming network traffic, attackers can use a technique called amplification to multiply their bandwidth to an attack target. By using network hosts running protocols that allow us to send relatively small amounts of traffic, and have that server return an even larger amount of traffic, we can exploit this to "amplify" the amount of traffic coming out of our source computer.
A relatively recent method to do this is is with the memcached protocol, a protocol used to store common web requests and database queries in memory instead of running these requests every time. Afterwards, a service (usually an internal one) can request data from the memcache, and the memcache can provide the large data from memory very quickly. So we have a protocol that allows you to request data with very little effort, and will reply with a relatively huge amount of data, and if incorrectly configured, can be done from the open internet.. can you see where this is going?
On February 28th, 2018, GitHub was victim to an amplification attack using exposed memcached servers. It was the largest DDoS attack ever performed, with a maximum traffic volume of 1.3 terabits per second of traffic being sent to GitHub's border network and DDoS mitigation network. The attack lasted 28 minutes, with amazingly, both GitHub and GitHub's DDoS protection service surviving the assault with minimal disruption.
Controlling other computers to use brute force for you!
This is probably the one you've heard of the most. Another excellent way to initiate DDoS attacks is by writing malware designed to give you remote control of an infected system, where afterwards you can instruct the infected systems to attack whoever you want, however you like. This collection of "zombie computers" is called a botnet.
This model is effective and versatile, but comes with effort. An attacker needs to successfully write malware, usually a Trojan, to compromise several hundred or thousand computers across the Internet, and have this process not be traceable back to the attacker. Additionally, an attacker needs to maintain this botnet, by creating new malware and making workarounds for security patches for existing compromised systems. This makes it infeasible for a random threat actor wanting to cause trouble to perform, and those who do perform it, offer their services in exchange for money. Most of these are not explicitly advertised as "DDoS" tools, as this would draw attention, but if you google "network stress test service" you'll definitely find something.
The most famous DDoS attack performed with a botnet was in 2004, through the largest, most expensive and fastest spreading computer virus to date. W32.MyDoom@mm "mydoom" was an email worm discovered on Jan 26th, 2004 at 8am by McAfee security engineers. By 4pm on the same day, web traffic slowed 10% overall, with 50% of email messages being sent across the internet originating from infected systems. On February 1st, a DDoS attack consisting of approximately 1 million infected computers was directed towards www.sco.com, with the attack being so severe that the website was temporarily removed from the DNS by DNS service providers.
With software vulnerabilities!
The kind of DoS (usually not DDoS) attacks we almost exclusively see are called application layer denial of service attacks, where instead of attacking the network and transport layers of the network stack, an attacker attacks the application directly using a vulnerability in the software. This type of attack flies under the radar of just about every DoS protection a server has, because it's not a DoS in the traditional "spam random garbage at the server until it goes down" fashion. These attacks use known exploits in the software they are attacking (like an outdated or unpatched version of Apache webserver, or in our case, a 20 year old video game server) to slow performance or even stop the application from working.
In Garry's Mod, I call these "lag scripts" (because they are NOT a DDoS), which are a feature in many paid hack clients. I don't know what mechanism makes these attacks work, but I am thankful that it is difficult enough to perform to warrant charging money for the software that can do it.
So if our server only sees these "lag scripts", are normal DDoS attacks still a threat to our server?
The answer is technically yes, but no. Is 50 caliber sniper rifle pointed at your head a threat? Yes. Is it still a threat when you're standing behind 5 inches of steel plating? A little bit, but not really.
Dinkleberg's TTT and Dinkleberg's Prophunt (and most likely the other two servers) use NFOservers. This hosting provider uses in house DDoS protection, extremely high speed links to the Internet, and a very high availability internal network. These selling points drive up the price a lot, but the fact that we've been using this server host for so long has been a huge factor for the server's success. Our latency is EXTREMELY low compared to other servers, and we are only matched by other servers using NFO. We are basically always at the top of the server list as long as you are on the eastern United States, DESPITE having enterprise grade DDoS protection.
Unless the threat actor has either an absolutely gigantic botnet or has a nasty zero-day exploit up their sleeve, if a DDoS attack is launched on one of our servers, it's going to be completely unnoticeable to the players. In a worst case, NFO will crank up the firewall on your box a little bit and players will experience a few ms higher latency, but there will not be an interruption of service. Only during a MASSIVE attack will we ever have our server disrupted.
Do player bans prevent DDoS attacks?
An attacker doesn't need to be connected to the server, or even know what the server does, to launch a DDoS against it. However, denial of service done through lag hacks require the player to be connected, so banning them solves the problem.
Do IP bans prevent DDoS attacks?
No, ULX IP bans work at the application layer and provide no traffic blocking. These are the exact same thing as steamid bans, but with IPs. Besides, with a DDoS attack, traffic comes from multiple IPs, so even if blocking was provided by banning IPs through ULX, it wouldn't be effective unless you banned every single attacker IP. This wouldn't be necessary though, because NFO's DDoS protection initiates temporary blocks on attacker IPs during an attack. IP bans do protect against lag hacks by disconnecting the player, but IP bans are significantly less effective than steamid bans because of the way IP addresses are given to internet users by their ISPs. Ban evasion is as simple as unplugging your router and plugging it back in.
If we are safe against DDoS attacks, what can we do about lag hacks?
Detecting the exact player doing it is difficult (unless they're a moron and say something like "ddosing your server lul" in chat), but the only thing you can do is ban the player responsible. A trick I picked up over the years is that if a player is using a sophisticated enough hacked client, running the ulx getcommandtable command on them won't return anything because the hack blocks this data from being sent. If the table doesn't show up, they are hacking.
I wrote this over a few days because the nerd in me gets irritated at people saying things are DDoS attacks when they aren't ;) hopefully you can find this somewhat useful/entertaining even though this is one chonkin forum post.
![[Image: horizontal-design-element-3.png]](https://fg-a.com/lines/horizontal-design-element-3.png)
![[Image: MYFtvx7.gif]](https://i.imgur.com/MYFtvx7.gif)
![[Image: dVe5C4F.gif]](https://i.imgur.com/dVe5C4F.gif)
