101–110 of 127 posts
Still being attacked constantly. I gotta admit that I am a bit confused with the user names chosen: CISCO, User, adempiere, admin1, adminstrator, alarm, alem, amanda, ansible, apache2, apc, arma3server, as, assembla, azure, azureuser, bamboo, bilbomeakine, bill, blackvoid, carlos, cds, centos, chinochan, cloud, cloudera, codeship, contributor, csgo, csgoserver, csserver, debian, default, demo, deployer, dev, device,…
Still being attacked constantly. I gotta admit that I am a bit confused with the user names chosen: CISCO, User, adempiere, admin1, adminstrator, alarm, alem, amanda, ansible, apache2, apc, arma3server, as, assembla, azure, azureuser, bamboo, bilbomeakine, bill, blackvoid, carlos, cds, centos, chinochan, cloud, cloudera, codeship, contributor, csgo, csgoserver, csserver, debian, default, demo, deployer, dev, device,…
amanda, bill, carlos, eurek, john, kevin, michael (mike), steve, and zyfwp
Since wireguard is a thing now wouldn't it be inadvisable for new deployments to put ssh on the bare internet anyway?
Why exactly is wireguard safer than ssh with keys?
I would say at the very least it offers an extra layer of authentication over ssh, so it would require a wireguard bug and ssh bug to cause damage. That alone provides extra security!
Another helpful thing, is that wireguard doesn't respond to invalid connection attempts at all. An invalid connection attempt appears as if you are accessing a port that nothing is listening on! Because of this, you can't detect what port wireguard is listening on, or even if it's running at all, so mass scanning the internet for wireguard listening ports and attempting connections is extremely ineffective.
There are probably other aspects that make it safer. You can read a lot about wireguard here https://www.wireguard.com/papers/wireguard.pdf
Earlier quoted context omitted.
Watching the connection in verbose it appears the cipher list from both the client and server side being significantly shorter and matching on both sides speeds up the negotiation. There may also be other factors but that is what sticks out to me. I've not dug deep enough into this to see if utilizing different ciphers is also part of the speed-up.
RFC 4253 says about the key exchange: > Each side MAY guess which algorithm the other side is using, and MAY send an initial key exchange packet according to the algorithm, if appropriate for the preferred method. If you only support one method, that guess will always be correct, and you save a round trip.
Since wireguard is a thing now wouldn't it be inadvisable for new deployments to put ssh on the bare internet anyway?
No reason to expose ssh to the internet.
Earlier quoted context omitted.
Honestly, I don't understand why people make reporting abuse so hard/labour-intensive. It is trivial to record netflow data (and most networks do that already), and then verify incoming abuse reports against those records.
is there a chance of forming some kind of a community fail2ban blocklist? I guess trusting the contributors and admins is the hard part here and that’s why spam lists are a double edged sword?
Unfortunately he shut down his bgp spam route sender last year.
Still being attacked constantly. I gotta admit that I am a bit confused with the user names chosen: CISCO, User, adempiere, admin1, adminstrator, alarm, alem, amanda, ansible, apache2, apc, arma3server, as, assembla, azure, azureuser, bamboo, bilbomeakine, bill, blackvoid, carlos, cds, centos, chinochan, cloud, cloudera, codeship, contributor, csgo, csgoserver, csserver, debian, default, demo, deployer, dev, device,…
I guess attackers has gotten a hacked password file and hope that some of the users have used the same username and password combinations on other servers.
Searching for bzrx1098ui showed that attackers try with the same logins on many servers. E.g., https://dataplane.org/signals/sshidpw.txt
Most of the passwords on that list are silly, but not all of them E.g.: )w%WLq^3UAwn 75afaf6480ca5f9c214fabb6e3663813 7h4a5n9d0a2oiang@))* 960c3dac4fa81b4204779fd16ad7c954f95942876b9c4fb1a255667a9dbe389d
The last one is used at: https://github.com/tlaverdure/laravel-echo-server/issues/273
and https://www.digitalocean.com/community/tutorials/how-to-secu...
Which mentions that is can be generated as: echo "digital-ocean" | sha256sum
Apparently Digital Ocean was telling people in 2014, that feeding a weak password to a hash function would result in a longer and therefore very strong password.
I am sure there are plenty of people that would use sha256sum("password")= 6b3a55e0261b0304143f805a24924d0c1c44524821305f31d9277843b8a10f4e as a password in a redis-file. But it is not something you would type in every time you ran SSH.
So maybe someone is just trying to use a search engine to find passwords made public.
Just yesterday I recently exposed SSH on a machine that had never had it exposed, on a router that had port 22 closed. Over the few hours it was open, my access log had about a hundred attempts against it.
It's not hard to scan the entire IPv4 address space, I doubt there is much use for lists of accessible servers.