Slashdot Mirror
Bigger Than Mirai: Leet Botnet Delivers 650 Gbps DDoS Attack (betanews.com)
Reader Mark Wilson writes: Earlier in the year, a huge DDoS attack was launched on Krebs on Security. Analysis showed that the attack pelted servers with 620 Gbps, and there were fears that the release of the Mirai source code used to launch the assault would lead to a rise in large-scale DDoS attacks. Welcome Leet Botnet. In the run-up to Christmas, security firm Imperva managed to fend off a 650 Gbps DDoS attack. But this was nothing to do with Mirai; it is a completely new form of malware, but is described as "just as powerful as the most dangerous one to date". The concern for 2017 is that "it's about to get a lot worse". Clearly proud of the work put into the malware, the creator or creators saw fit to sign it. Analysis of the attack showed that the TCP Options header of the SYN packets used spelled out l33t, hence the Leet Botnet name.
Should rename these from IoT devices to Internet of DDoS devices.
I know I might be being naive, but there is no way to solve the problem at the root, such as cutting the connection of devices that begin to generate disproportionately traffic aimed at a single site (the target)?
Each source is just a small part of the whole generating traffic the looks "normal" for the most part. So a bit harder to automatically filter. But... Logs and tracking back, and using the existing RIAA procedures to warn and then disconnect those sources would be a good start.
I know very well, thank you. Enough to know that try to filter at the target of attacks is practically useless and is why I am asking if there is any way that I do not know yet to solve the problem at the other end of the connection. And to avoid another dumb response from you I already know that filtering in the source of the attacks is difficult, If it were easy I would not be asking for alternatives.
Religion: The greatest weapon of mass destruction of all time
Ok, everybody who was effected by this raise your hands! Anybody?
These DDOS attacks are mildly interesting but irrelevant in the grander scheme of things. Given the nature of the attack payloads, it probably would have been effective at less than 100 Gbps so why hype the new high watermark? AFAIK, DDOS isn't a huge money maker so this isn't a threat in the same league as ransomware.
Quit trying to promote vandalism as news and maybe, just maybe it will become less interesting a thing to do.
Average Intelligence is a Scary Thing
See subject: SYN Attack Protection
---
The named value to enable SYN attack protection is located beneath the registry key:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\TcpIp\Parameters.
Value name: SynAttackProtect
Recommended value: 2
Valid values: 0 1 2
Description: Causes TCP to adjust retransmission of SYN-ACKS. When you configure this value the connection responses timeout more quickly in the event of a SYN attack. A SYN attack is triggered when the values of TcpMaxHalfOpen or TcpMaxHalfOpenRetried are exceeded.
---
SYN Protection Thresholds
The following values determine the thresholds for which SYN protection is triggered. All of the keys & values in this section are under the registry key
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\TcpIp\Parameters
Value name: TcpMaxPortsExhausted
Recommended value: 5
Valid values: 0-65535
Description: Specifies the threshold of TCP connection requests that must be exceeded before SYN flood protection is triggered.
Value name: TcpMaxHalfOpen
Recommended value data: 500
Valid values: 100-65535
Description: When SynAttackProtect is enabled this value specifies the threshold of TCP connections in the SYN_RCVD state. When SynAttackProtect is exceeded SYN flood protection is triggered.
Value name: TcpMaxHalfOpenRetried
Recommended value data: 400
Valid values: 80-65535
Description: When SynAttackProtect is enabled this value specifies the threshold of TCP connections in the SYN_RCVD state for which at least one retransmission has been sent. When SynAttackProtect is exceeded SYN flood protection is triggered.
APK
P.S.=> That's software/OS/IP stack side for Windows users (*NIX has analogs - as all std. IP stacks are BSD derived)... apk
10g transit ports are about the smallest practical to buy, 40 and 100 are a lot more common. This is a big attack as attacks go but not really pushing a well-built network.
No sir I dont like it.
If there is a known C&C that it communicates with or other things that will give away the device then yes some ISPs will call you up, warn you, and then suspend your account until you get the device removed or are able to clean it.
Manufacturers won't learn anything until it hits them in the pocketbook. And since the IoT devices are a dime a dozen, made by thousands of different fly by night operations in China, that is highly unlikely. Cutting corners is how they make a $24.99 device that does something that eliminates you walking across the room to do.
Agent K: A *person* is smart. People are dumb, stupid, panicky animals, and you know it.
I'll take the liberty of re-phrasing the question: What can be done to prevent "my" IOT devices, which require some access to the internet, from being part of the problem?
Don't really know the answer; consumer routers aren't up to the task, and configuring a more advanced router/firewall isn't easy, and the end devices themselves have terrible security. You could proxy some of the data that is sent by the equipment and track anomalies... but that becomes a lot of work.
If we had a global registry of DDoS targets that we added new addresses to when the bandwidth of an attack broached limit X from number of sources Y (100gbps / 1million bots?), then we could require ISPs to run automated scripts that Null Route those addresses in the database for time period Z (1 day?) The Botnet gets rejected at the edge in those cases, but the end result is the same for the target, they have to move or wait. If you can get the move done fast enough (up on new IP addresses in an automated fashion within seconds, DNS propagation for those new addresses at the same rate), then there is no loss of service, and no profit for the operators of the Botnet. Or no fun if its "just for the Lulz". So the real problem with DDoS is the inherent lack of configuration speed in the current internet. Blocking IP addresses at the edge routers is a manual process and takes time. Bringing NIC cards up on new IP addresses or changing static NATs in firewalls is a manual process and takes times. Changing DNS records and allowing for propagation, etc, etc. So to beat DDoS, we need to have more automated systems in place for migrating services from one address to another. You destroy the perception that there was any effect from the flood, and you beat DDoS.
/* * pope1 */