If you've ever looked at SSH server logs you know what I'm about to say: Any SSH server connected to the public Internet is getting bombarded by constant attempts to log in. Not just a few of them. A lot of them. Sometimes even dozens per second. And this problem is not going away; it is, in fact, getting worse. And attackers' behavior is changing.
The graph attached to this post shows the number of attempted SSH logins per day to one of @cloudlab s clusters over a four-year period. It peaks at about 3.4 million login attempts per day.
This is part of a study we did on our production system, using logs of more than 640 million login attempts, covering more than 1,500 hosts on our side and observing more than 840 thousand incoming IP addresses.
A paper presenting our analysis and a new, highly effective means to block SSH brute force attacks ("Where The Wild Things Are: Brute-Force SSH Attacks In The Wild And How To Stop Them") will be presented next week at #NSDI24 by @sachindhke . The full paper is at https://www.flux.utah.edu/paper/singh-nsdi24
First things first: everyone "knows" that most brute force attacks are against the "root" account, right? This is certainly what earlier studies have found.
As it turns out, this used to be true, but it's not anymore. This graph shows that the fraction of brute force attacks using the username root was nearly 100% back in 2017, but it's been falling - by mid-2021, only around 20% off the attacks we saw were against root.
So, why? Well, we don't have a hotline to the attackers, but we have an educated guess from our own data and from many others' reporting: a lot of the usernames we see correspond to default usernames for #network#routers, specific #Linux distributions, specific server software, and #IoT devices. Basically, as we connect ever more stuff to the Internet (and generally try to protect the "root" account), attackers seem to be diversifying the accounts they are going after.
(There's a table of the top 100 usernames in the paper.)
Anyone got an idea what could cause irregular #network lag on an #ArchLinux machine on a wired network?
We already ruled out cable, NIC and such stuff and system usage is fine, same with iotop and journalctl. We really are out of ideas.
VoIP tools lag behind (some sentences are send directly, some are only received by participants after up to 3 seconds) as well as games which act like lag spikes but without the latency going ham. Wireshark reports basically no dropped packages. #Help. #Linux
TIL that one symptom of a almost-but-not-quite-dead Cat 5e #network cable is magically getting the connection downgraded to 10 MBit/s (and causing the connection get dropped altogether for a few seconds every now and then).
🚀 traceroute + ping!
🛠️ Customizable multi-protocol tracing interface.
📊 Detailed reporting and platform support.
🦀 Written in Rust & built with @ratatui_rs