Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!


Massive SSH infections - Page 2
New on LowEndTalk? Please Register and read our Community Rules.

All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.

Massive SSH infections

2

Comments

  • rcxbrcxb Member

    @jbuggie said:
    configure a fail2ban sshd jail.

    Doesn't work these days. I've been getting distributed attacks on my SSH servers *even on non-standard ports) going non-stop for years now. Huge logs with hundreds of Invalid user messages every day.

    I finally resorted to keeping long-term track of IPs with ssh log-ins attempts, and perma-banning any IP doing so more than once in several month sliding window. That at least slowed the mess down. Fail2ban needs to massively up their game.

    Thanked by 1vimalware
  • rcxbrcxb Member

    @raindog308 said:
    Allowing keys only instead of just passwords is more secure...no?

    Back of the envelop calculation indicates that a 1024-bit RSA key is as secure against brute-force as a 146 character random password. Although you might have to divide that if you have trusted multiple SSH keys.

  • LeviLevi Member
    edited August 2020

    At least for now it's working pretty good:

    1. Buy cheap box from cociu or terrahost.no and setup Wireguard server
    2. Install Wireguard client on another machine
    3. Set SSH to listen on Wireguard IP (ex. 172.XX.XX.XX), remove password auth, enable pubkey auth

    That's it. No over complicated setup, no annoying login with 2FA, no port changing, no resource intensive apps like fail2ban. Pure and simple.

  • LeviLevi Member

    @rcxb said: 1024-bit RSA key

    Who uses 1024 these days? You either setup 2048 or 4096 (a bit overkill).

  • jackbjackb Member, Host Rep

    @Gamma17 said:

    @jackb said:
    Keys are objectively more secure than an average password (>112 bits Vs even a strong password will be nowhere near that).

    But you are looking at it from just "how strong is it against bruteforce" point of view. Passwords are weaker here, but also ratelimiting mitigates this weakness.

    There are other considerations though, which in specific cases can easily make keys less secure. Especially keys with empty passwords or with 12345 passwords a lot of people use because of "but keys are so secure i do not need a password" complacency.

    Why advocate for passwords rather than properly securing keys in that case?

  • @jackb said:
    Why advocate for passwords rather than properly securing keys in that case?

    I am not really advocating for passwords, but more for people making their own informed decision on the matter.

    With all the guides on "how to secure ssh" stating "do not use passwords use keys" there are far too many people who learned it and repeat it without even understanding why. All while using passwords is not necessarily unsafe if additional measures are taken to mitigate bruteforce-related weakness and using keys is not necessarily safe when doing it mindlessly.

    Doing something without understanding never ends well, even more so when working with security related stuff.

    Thanked by 2Shazan quicksilver03
  • LeviLevi Member

    @Gamma17 said: when working with security related stuff

    In security world paranoia is considered a plus. And if overdo something in the name of security (even if you don't understand) - it is better than do nothing. Stay vigilant, be paranoid, don't get pwnd.

  • @LTniger said:
    In security world paranoia is considered a plus. And if overdo something in the name of security (even if you don't understand) - it is better than do nothing. Stay vigilant, be paranoid, don't get pwnd.

    You have to be careful with paranoia though, it leads to tunnel vision far too easily. You then start generating 8192bit keys and implementing all the measures on server at the same time, meanwhile your client machine gets pawned, all your 8129bit keys along with passwords are stolen and do absolutely no good.

  • @jbuggie said:
    It's so simple to configure a secured SSH installation: disable password and root login. That's it. While you are at it, configure a fail2ban sshd jail. Further more, configure psad to report/auto ban port scanning. You'd be amazed at how many attempted port scanning/hacking your server got in a day.

    This is anything but simple.

  • Quick Question.

    Doesn't whitelisting IP is enough ? is there still a way for a hacker to login to a whitelisted ip ssh server ?

  • @rcxb said:

    @jbuggie said:
    configure a fail2ban sshd jail.

    Doesn't work these days ... Huge logs with hundreds of Invalid user messages every day.

    I don't see the issue here, hundreds a day from wide and slow scans is trivial even for a tiny system and would barely register with even fairly long lived logrotation, just ignore them. Hundreds of thousands a day, where resources are genuinely impacted, is the scenario where fail2ban becomes useful.

    I ... perma-ban any IP doing so more than once in several month sliding window. ... Fail2ban needs to massively up their game.

    Surely it is down to you to tune/configure Fail2ban to meet those requirements, out of the box it's designed to slow targeted brute forcing, not to prevent the background noise of slow trickle attempts.

    Foe all those advocating leaving password authentication enabled, I'm surprised no-one's suggested using 'AllowGroups' as well as 'PermitRootLogin no'. YOUR password may be secure, but what about the other accounts on the system?

    Thanked by 1skorous
  • Take the time to teach developers about public key pairs and how to keep them safe. (not in your Gmail)

  • What @LTniger and others said. Put everything you can in a VPN tunnel, ssh, rdp, vnc ...
    Even better when it is a wireguard tunnel. Unless you run other public services no one will know that there is a server. Even if you run other services someone would only see those public ports and not the tunnel connection itself (unless the attacker sniffs the connection directly)
    An open ssh port will give info like the version of ssh and the OS you a running. From there you can dig a bit further and make a guess on what kernel and other program versions run ...

  • jsgjsg Member, Resident Benchmarker
    edited August 2020

    @raindog308 said:

    @jsg said: All off the above, plus magic candles

    I wouldn't dismiss everything above. Allowing keys only instead of just passwords is more secure...no?

    (Serious now) - it might be surprising but the answer is No. It depends on implementation and on passphrase length and quality.

    Theoretically passphrases can be just as good as keys. quasi-random 128 bits are quasi-random 128 bits no matter whether a passphrase or key, and btw. 128 bits are just 16 Bytes and hence not entirely beyond reach for mere mortals.

    The decisive point is that (most) passphrases (usually) are low entropy, not random plus using only a small part of the available space (about 60 out of 256 possible "characters"). Another problem is that the other side (typ. a server) expects those (poor) passphrases, usually further limited by length constraints
    All of that can changed however with a very simple method: hashing with a good algorithm like e.g. blake2 (mod allowed max passphrase length). Added advantage: stretching, so what a user types in may be only e.g. 7 bytes but the hash stretches it to e.g. 16 bytes anyway.

    The real major advantage of keys is that no user interaction is required which is desirable (or necessary) for increasingly many automated processes.

    The probably biggest argument in favor of passphrases is the fact that if RSA and ECC get cracked (their reductions are very similar) virtually all key based mechanisms are broken while passphrase mechanisms continue to work.

    @jackb said:
    Keys are objectively more secure than an average password (>112 bits Vs even a strong password will be nowhere near that).

    No. See above.

    @rcxb said:

    @raindog308 said:
    Allowing keys only instead of just passwords is more secure...no?

    Back of the envelop calculation indicates that a 1024-bit RSA key is as secure against brute-force as a 146 character random password. Although you might have to divide that if you have trusted multiple SSH keys.

    Depends a lot on the password quality. Even a high quality 16 byte password can be as secure as RSA-1024, but granted most passwords are not high quality. But use a good hash of that password and you even beat RSA-1024 plus passwords and good hashes must not be afraid of Shor's algo.

    @LTniger said:
    Who uses 1024 these days? You either setup 2048 or 4096 (a bit overkill).

    Yes, but ECC (with a good curve, please, and none of the NIST crap) is preferred.

    Thanked by 1poisson
  • I never use fail2ban, much preferring CSF and its' additional protection. Some idiot tries a few port scans to find the ssh port and they get (permanently, in my case) blocked. It even caters for a distributed attack. Likewise with too many login attempts to other services.

  • jackbjackb Member, Host Rep
    edited August 2020

    @jsg said:
    Theoretically passphrases can be just as good as keys. quasi-random 128 bits are quasi-random 128 bits no matter whether a passphrase or key, and btw. 128 bits are just 16 Bytes and hence not entirely beyond reach for mere mortals.

    The decisive point is that (most) passphrases (usually) are low entropy, not random plus using only a small part of the available space (about 60 out of 256 possible "characters").

    @jackb said:
    Keys are objectively more secure than an average password (>112 bits Vs even a strong password will be nowhere near that).

    No. See above.

    Looks more to me that we are in agreement that keys are objectively more secure than an average password.

    In order to reach approximately the same strength as a typical key, I had to make a password that was ~25 characters long, including uppercase, lowercase, numeric and special characters. Almost nobody does that without using a password manager, so it's a bit of a moot point.

    Thanked by 2skorous vimalware
  • jsgjsg Member, Resident Benchmarker

    @jackb said:
    Looks more to me that we are in agreement that keys are objectively more secure than an average password.

    I don't know (or care) what the quality and length of an average password are but I guess re. average passwords you are right.

  • @Gamma17 said:

    @jackb said:
    Why advocate for passwords rather than properly securing keys in that case?

    I am not really advocating for passwords, but more for people making their own informed decision on the matter.

    With all the guides on "how to secure ssh" stating "do not use passwords use keys" there are far too many people who learned it and repeat it without even understanding why. All while using passwords is not necessarily unsafe if additional measures are taken to mitigate bruteforce-related weakness and using keys is not necessarily safe when doing it mindlessly.

    Doing something without understanding never ends well, even more so when working with security related stuff.

    That's still confusing. You just stated you need a bunch of extra mitigations, so why fight the rule of thumb for absolutely no good reason?

    People who understand should use keys, people who don't understand should use keys.

  • TimboJonesTimboJones Member
    edited August 2020

    @jsg said:

    @raindog308 said:

    @jsg said: All off the above, plus magic candles

    I wouldn't dismiss everything above. Allowing keys only instead of just passwords is more secure...no?

    (Serious now) - it might be surprising but the answer is No. It depends on implementation and on passphrase length and quality.

    Theoretically passphrases can be just as good as keys. quasi-random 128 bits are quasi-random 128 bits no matter whether a passphrase or key, and btw. 128 bits are just 16 Bytes and hence not entirely beyond reach for mere mortals.

    The decisive point is that (most) passphrases (usually) are low entropy, not random plus using only a small part of the available space (about 60 out of 256 possible "characters"). Another problem is that the other side (typ. a server) expects those (poor) passphrases, usually further limited by length constraints
    All of that can changed however with a very simple method: hashing with a good algorithm like e.g. blake2 (mod allowed max passphrase length). Added advantage: stretching, so what a user types in may be only e.g. 7 bytes but the hash stretches it to e.g. 16 bytes anyway.

    The real major advantage of keys is that no user interaction is required which is desirable (or necessary) for increasingly many automated processes.

    The probably biggest argument in favor of passphrases is the fact that if RSA and ECC get cracked (their reductions are very similar) virtually all key based mechanisms are broken while passphrase mechanisms continue to work.

    @jackb said:
    Keys are objectively more secure than an average password (>112 bits Vs even a strong password will be nowhere near that).

    No. See above.

    @rcxb said:

    @raindog308 said:
    Allowing keys only instead of just passwords is more secure...no?

    Back of the envelop calculation indicates that a 1024-bit RSA key is as secure against brute-force as a 146 character random password. Although you might have to divide that if you have trusted multiple SSH keys.

    Depends a lot on the password quality. Even a high quality 16 byte password can be as secure as RSA-1024, but granted most passwords are not high quality. But use a good hash of that password and you even beat RSA-1024 plus passwords and good hashes must not be afraid of Shor's algo.

    So the script kiddie just inserts a single step to hash the password when brute forcing? I don't see how that prevents brute force, just slows it down a tiny bit.

    And still don't know how keys only is not more secure than keys, which was your response to raindog. Adding qualifiers (e.g. when password is of sufficient size and entropy) is required for you to even have a chance of making any sense. Afaik, you can have 1 character password. So your response to raindog is just flat out wrong unless you change the meaning entirely.

    I'd be interested if you can find just one source from an expert that disagrees with "Allowing keys only instead of just passwords is more secure".

    Your statement is the equivalent of "wearing masks is not safer than not wearing masks".

    Thanked by 1vimalware
  • DPDP Administrator, The Domain Guy
  • raindog308raindog308 Administrator, Veteran

    According to that site, "12345" is cracked "instantly" but "1" will take 200 picoseconds.

    I guess I'll have to change all my passwords tonight. Sigh. But it's worth it because I'll become infinity% more secure.

  • jsgjsg Member, Resident Benchmarker

    @raindog308

    Pro tip: Just tell everyone that you'll change your password from 1 to 3 - but then quietly use 2 as your password!

  • rcxbrcxb Member

    My ultra-secure password1234567890 will take 8 billion years to break!

    Thanked by 1Shazan
  • jsgjsg Member, Resident Benchmarker

    @rcxb said:
    My ultra-secure password1234567890 will take 8 billion years to break!

    Not if the NSA designs and builds a password1234567890-cracker-ASIC and a 250 ExaBytes rainbow table. With that they could do it within 2 - 3 million years!

  • SaahibSaahib Host Rep, Veteran

    I have seen that simply disabling root access to SSH causes bots to not to come back once they know it. There will be brute force attacks but lesser and mostly from new IPs only.

  • @Saahib said:
    I have seen that simply disabling root access to SSH causes bots to not to come back once they know it. There will be brute force attacks but lesser and mostly from new IPs only.

    That's interesting, I was sure that the block wasn't obvious to the intruder, that they still got asked for a password even if the user login was ultimately invalid. Are you sure you didn't also switch off PasswordAuthentication?

  • go for key auth and disable password like a golden rule for me o:)

  • @AlwaysSkint said: I never use fail2ban, much preferring CSF and its' additional protection. Some idiot tries a few port scans to find the ssh port and they get (permanently, in my case) blocked. It even caters for a distributed attack. Likewise with too many login attempts to other services.

    Yeah CSF Firewall's LFD (login failure daemon) does wonders. On Centmin Mod, users also have cminfo netstat command which breaks down some CSF logged stats

    ------------------------------------------------------------------
     Centmin Mod Netstat Info:
    ------------------------------------------------------------------
    
    Network Bandwidth In/Out (KB/s):
    docker0  In:  0.00  Out:  0.00
    eth0     In:  0.53  Out:  0.18
    
    Network Packets   In/Out (pps):
    docker0  In:  0.00  Out:  0.00
    eth0     In:  9.00  Out:  9.00
    
    Total Connections For:
    Port 80:   1
    Port 443:  1
    
    Unique IP Connections For:
    Port 80:   0
    Port 443:  0
    
    Established Connections For:
    Port 80:   0
    Port 443:  0
    
    TIME_WAIT Connections For:
    Port 80:   0
    Port 443:  4
    
    Top IP Address Connections:
    
    Top Outbound Connections:
    
    Top CSF Firewall Denied Country Codes:
    5908  CN
    5162  VN
    4480  US
    2681  BR
    2364  EG
    2259  RU
    2149  FR
    1701  TH
    1604  DE
    1366  KR
    
    Top CSF Firewall Denied Country Codes + Reverse Lookups:
    5398  CN  China       -
    2897  VN  Vietnam     static.vnpt.vn
    1751  US  United      States          -
    1439  VN  Vietnam     -
    941   KR  South       Korea           -
    842   IN  India       -
    753   RU  Russia      -
    691   ID  Indonesia   -
    623   BR  Brazil      -
    444   AZ  Azerbaijan  -
    
    Top CSF Firewall Denied Distributed sshd Attacks:
    3970  CN  China       -
    2793  VN  Vietnam     static.vnpt.vn
    1274  VN  Vietnam     -
    1030  US  United      States          -
    684   KR  South       Korea           -
    660   IN  India       -
    540   RU  Russia      -
    528   ID  Indonesia   -
    441   AZ  Azerbaijan  -
    434   BR  Brazil      -
    
    Top CSF Firewall Denied Distributed sshd Attacks Target Usernames:
    17774  admin
    13175  root
    2916   pi
    374    test
    275    user
    115    support
    114    sshd
    91     guest
    83     ubnt
    82     ubuntu
    
    Top CSF Firewall Failed SSH Logins:
    1428  CN  China        -
    721   US  United       States  -
    257   KR  South        Korea   -
    213   RU  Russia       -
    189   BR  Brazil       -
    182   IN  India        -
    180   SG  Singapore    -
    172   DE  Germany      -
    170   NL  Netherlands  -
    165   VN  Vietnam      -
    
    Last 24hrs Top CSF Firewall Denied Country Codes:
    
    
    Last 24hrs Top CSF Firewall Denied Country Codes + Reverse Lookups:
    
    
    Last 24hrs Top CSF Firewall Denied Distributed sshd Attacks:
    
    
    Last 24hrs Top CSF Firewall Failed SSH Logins:
    
  • rcxbrcxb Member
    edited August 2020

    Well, NOBODY visits lowendbox right now... Looks kinda like @jbiloh didn't pay his VPS bill.


    https://i.ibb.co/94d5Z16/LEB404.png

Sign In or Register to comment.