Should i blocked 22 ssh port?

Discussion in 'Installation/Configuration' started by pecka33, Dec 16, 2021.

  1. pecka33

    pecka33 Member

    Hello,

    i would like to do best for secure my dedicated server. Do you think that is one of things i should to do is blocked port 22 for ssh login? I guess i just add new port to firewall via ispconfig and after that i add this new port in sshd file?

    Do you recommend this or this is not effect to secure of my server?
     
  2. Taleman

    Taleman Well-Known Member HowtoForge Supporter

    If you do not use SSH Logins to that server, by all means close that port on firewall and also do not install SSH server or disable SSH server from starting.
    I'm not sure what you meant adding new port to sshd file, but one way to make SSH a bit more secure is change the port it uses, from 22 to something else like 2222. If you need to use SSH logins to that host this is the way to go.
     
  3. nhybgtvfr

    nhybgtvfr Well-Known Member HowtoForge Supporter

    changing the port number just adds a bit of obscurity to it.
    port scans will still be run against your server, and you may well spot, and block them, but at some point the randomly chosen ssh port you're using will be known to an attacker, so you're back where you started.

    as @Taleman states, if you don't use ssh, don't install the ssh server, and close the port, then you just don't need to worry about it ever again.

    i think disabling remote root login, and only allowing key based ssh logins should be secure enough for most cases.
    if you want to go full on paranoid / secure, then look towards setting up port-knocking for ssh access on top of blocking root logins and requiring key based access.
    basically, you'll need to try to connect to a pre-arranged list of ports, in a pre-arranged order, before the ssh port is opened up for you to access. obviously it's more work and more complicated to configure in the 1st place, but it will be more secure. It would take some serious dedication/persistence (and time) from attackers to run enough port scans to work their way through that sequence.
     
  4. Jesse Norell

    Jesse Norell Well-Known Member Staff Member Howtoforge Staff

    Other considerations are you could use a vpn to connect to your firewall or to your server and only allow ssh from that (with or without port knocking); and you can also use multi-factor authentication on ssh (eg. time based OTP, U2F, etc.), so even if/when someone gains access to the machine you're connecting from (and hence obtains your password and keys), they still can't login to your server.
     
    Steini86 likes this.
  5. ahrasis

    ahrasis Well-Known Member HowtoForge Supporter

    I think your approach @pecka33 should work just fine as port 22 is a commonly targeted port for ssh attack especially if you use key as suggested by @nhybgtvfr above but I wouldn't worry that much about others scanning for open ports.

    I also personally won't use vpn, certain ip only access or multi factor ssh authentification as I would prefer to avoid paranoia but you can use any or all of them if that makes your server safe and you feel safe.
     
  6. 30uke

    30uke Active Member HowtoForge Supporter

    When you use SSH: no, an alternative port might help a little bit. When you don't use SSH, then just disable it.
    I have my own way to secure SSH.
    What helps is to tune Fail2Ban a little bit and use a certificate or 2FA for SSH.
    2FA
    There are quite some articles written about libqrencode3 / libpam-google-authenticator like this one: https://www.sysorchestra.com/add-two-factor-authentication-to-ssh-on-debian-wheezy-and-jessie/
    The only thing I found is that a lot of articles promote to comment out @include common-auth in /etc/pam.d/sshd but I don't like that method. I just keep the common-auth and just add the requirement for pam_google_authenticator.so
    Besides that most articles promote the use of a public key in /etc/ssh/sshd_config. I just go ahead and add AuthenticationMethods keyboard-interactive instead. So everything has to be done via the keyboard.
    This means I have to type my password and I have to enter the OTP code when I login. In my opinion this adds an extra layer of security.
    Fail2Ban
    For Fail2Ban I did add the following to /etc/fail2ban/jail.local at the bottom of the file:
    Code:
    [sshd]
    bantime = 31104000
    findtime = 86400
    maxentry = 1
    
    [recidive]
    enabled = true
    findtime = 31104000
    bantime = 31104000
    and at the top of the file I did add this:
    Code:
    [DEFAULT]
    ignoreip = 127.0.0.1/8 86.nn.nnn.86 2001:nnn:nnnn:73::/64
    I did "n" to mask my IP addresses. Just put yours there.
    hosts.allow
    The file "hosts.allow" is pretty much underestimated these days. But it works fine.
    I did add the following to /etc/hosts.allow
    Code:
    sshd: 86.nn.nnn.86 :allow
    sshd: ALL :deny
    Again: I did use "n" to mask my IP address.
    How does this work then?
    So, when I connect via SSH and something goes wrong, Fail2Ban will ignore that. I can go ahead and retry to connect. I have to enter my password and the OTP code.
    When someone else tries to logon from some IP, that IP will be banned instantly for a year. When it happens again recidive will kick in. Maybe a year is a bit long-ish but a second attempt from the same IP will miserably fail. It will also add a nice IP list to /var/log/fail2ban.log so you can use it to feed block lists as a bonus (you did create your own SSH honeypot too).

    Tip: join https://www.blocklist.de when you are used to Fail2Ban and wish to add hacking attempts to their blocklist :)
     
    Last edited: Dec 25, 2021

Share This Page