[nmglug] ssh attacks

ABQLUG Events community at abqlug.com
Fri Aug 19 04:50:54 PDT 2022

Hi Aaron,

Since you are using this server at home, I would recommend sticking your 
home devices behind a separate (and properly configured) firewall. If 
your server gets pwned, you don't want that to spread to the rest of 
your devices... Having the server pass traffic to your home devices NOT 
a good idea, at all...

As for bypassing UNM's firewall rules. Keeping SSH on 443 w(e)rks, but I 
recommend putting OpenVPN on 443 (TCP) or on 53 (UDP) since you can use 
HMAC to drop packets from anyone that doesn't present the expected 
certificate. Keep in mind that port 53 is typically (not always) rate 
limited on most enterprise firewalls.


But these days, I recommend just using TailScale to access your devices 
at home if you are remote. Especially since you can bypass the most 
strictest of NAT rules quite easily. This eliminates the use of port 
forwarding (if you don't want to publicly expose your server).


To upgrade to a newer point release, you would need to run "sudo apt 
dist-upgrade" (I believe full-upgrade will do it too, but I haven't 
tested it though...)

Sorry it took so long to reply, I suck at life...

~ Jared

On 8/8/22 14:31, Aaron Birenboim wrote:
> thanx.
> On 8/8/22 13:35, ABQLUG Events wrote:
>> Hi Aaron,
>> I think the answer to your questions have been hammered away pretty 
>> well. But I wanted to give my 2¢.
>> Are the machines on-prem, in a datacenter, or on a cloud provider 
>> (such as Linode, DigitalOcean, Azure, or AWS)? Also, what distro and 
>> version are you using? Having those answers can help give more 
>> detailed advice.
> Dynamic DNS to server in my house.  Comcast.  Debian Bullseye (11.3 ... 
> does it upgrade to 11.4 if I apt upgrade?), behind an OpenWRT 
> firewall/router/WAP/NAT.  OpenWRT forwards ports 22 and 80 to server.
> Machine is also gateway between my DMZ and internal net.  Most of my 
> streaming devices and guest logins stay in the DMZ.
>> Above all, the biggest take away should be to use a 
>> belt-and-suspenders approach. If any one approach has a flaw, you have 
>> other layers of protection to fall back on.
>> This is what I do on a Linode hosted Ubuntu VPS.
>> 1) I set these in /etc/ssh/sshd_config
>> PermitRootLogin                  no
>> StrictModes                      yes
>> PubkeyAuthentication             yes
>> AuthorizedKeysFile               .ssh/authorized_keys
>> PasswordAuthentication           no
>> PermitEmptyPasswords             no
>> AuthenticationMethods            publickey
> done.
>> 2) Before proceeding, establish a new ssh session, to make sure ssh 
>> still works.
>> 3) I setup some Linode firewall rules to only allow my IP address to 
>> connect over port 22.
>> https://www.youtube.com/watch?v=H7wM5mDI1-k
>> 4) Check ssh again. Then I use UFW to setup a firewall on the OS side, 
>> replace with your IP address. Repeat firewall rules if you 
>> have multiple hosts to ssh from.
>> sudo ufw default deny incoming
>> sudo ufw allow proto tcp from to any port 22
>> sudo ufw enable
> done.  except I have port 80 open also.
> Still deciding if I should do https on 443, or have it forward to 22.  I 
> used to have to do this to get out of UNM WiFi to my house.  (UNM 
> allowed 443 out, but not 22)
>> 5) Setup fail2ban (especially if you decide to not use any firewalls)
>> https://www.linode.com/docs/guides/how-to-use-fail2ban-for-ssh-brute-force-protection/
> will check.
>> As Akkana mentioned, you really should also setup out-of-band 
>> "backdoor" is critical. Especially if the server isn't on-prem and 
>> easy to gain console level access. If the server hosted with a cloud 
>> provider, for example Linode, you can use their Lish Console through a 
>> web browser to gain console level access.
>> What I do with some servers at BigByte is setup an OpenVPN server that 
>> has a hole poked through the firewalls. You could also use something 
>> like TailScale if you haven't setup OpenVPN before.
>> And of course don't forget to use a strong and unique passphrase on 
>> all of your ssh keys. If you get tired of typing in ssh passphrases, 
>> you can setup a SSH agent (for example ssh-agent, Gnome Keyring, or 
>> KDE Wallet) to cache the passphrases up until you reboot.
>> I'm planning on doing a deep dive on using Google Authenticator to 
>> setup 2FA on SSH. But I haven't gotten around to it...yet.
>> https://www.linode.com/docs/guides/how-to-use-one-time-passwords-for-two-factor-authentication-with-ssh-on-ubuntu/
>> Hope this helps!
>> ~ Jared
>> On 8/8/22 10:01, Aaron Birenboim wrote:
>>> I've been getting constant ssh attacks, like several per minute.
>>> Any suggestions?   I could change the port from 22, but I don't know 
>>> if that will do much.
>>> There used to be some sort of sshd wrapper which could ban an IP 
>>> after failed attempts.  I think it was deprecated.   The attack IP 
>>> changes, but there often a few dozen attacks from the same IP. Again, 
>>> some help...  but not much.
>>> I have password access disabled.  (You need to have a key to ssh in). 
>>> Anything else I should do?
>>> aaron
>>> _______________________________________________
>>> nmglug mailing list
>>> nmglug at lists.nmglug.org
>>> http://lists.nmglug.org/listinfo.cgi/nmglug-nmglug.org
>> _______________________________________________
>> nmglug mailing list
>> nmglug at lists.nmglug.org
>> http://lists.nmglug.org/listinfo.cgi/nmglug-nmglug.org
> _______________________________________________
> nmglug mailing list
> nmglug at lists.nmglug.org
> http://lists.nmglug.org/listinfo.cgi/nmglug-nmglug.org

More information about the nmglug mailing list