Hacked by China?

If you actually want to ssh into your router remotely, I recommend using fwknop:

https://openwrt.org/docs/guide-user/services/fwknop

It provides some additional security with the benefit that you don't attract all these attacks and additional port scans that you get when hackers notice that you've got an open port.

4 Likes

But keep the ssh port below 1024.
You can just as well keep it on 22 (if you can't secure it there, you won't secure it elsewhere).

Google why moving ssh away from 22 is a bad idea, e.g. https://www.adayinthelifeof.nl/2012/03/12/why-putting-ssh-on-another-port-than-22-is-bad-idea/

1 Like

The only changes that should have been made to the firewall, was about 3 years ago to block all access for a NAS Cloud device except for NTP access, which I have added that set of rules back.

drop caches immediately frees up about 8MB, then it grabs about 5MB back with no real traffic, its seems to have settled down to 95MB free on average now

As for adding other stuff back, maybe Adblock service in a few weeks.

Lots of great advice to read over so far, I really don't use dropbear for much, other than checking setting or snooping on setting etc

Thanks everyone

If your problem is solved, feel free to mark the relevant post as the solution; and edit the title to add "[SOLVED]" to the beginning (click the pencil behind the topic).

grafik

Interesting article, thanks - always good to see another perspective. Many would disagree though:

  • An effective method is to run ssh on a non-standard port. Any unused port will do, although one above 1024 is preferable. - CentOS wiki [1]
  • If the server is to be exposed to the WAN, it is recommended to change the default port from 22 to a random higher one like this: Port 39901 - Arch Linux Wiki [2]

RedHat seems to agree at keeping OpenSSH port at 22. Some food for thought.

Thanks again!

[1] https://wiki.centos.org/HowTos/Network/SecuringSSH#head-3579222198adaf43a3ecbdc438ebce74da40d8ec
[2] https://wiki.archlinux.org/index.php/OpenSSH#Configuration_2

Strong authentication, keeping your SSH server current, and preventing root login are generally sufficient. Adding in a rate-limit for new connections can help, but also can cause DoS when you need to get into the box yourself. Log management can handle failed-login messages. At least for me, there is little tangible value of moving the service to another port.

I would probably agree with you, especially if port 22 is restricted to LAN/VPN with DROP as a default policy - pretty much the same end goal as moving to another port; i.e. an attacker wont know port 22 is listened on.
On the DoS point, the same is worth mentioning for fail2ban and the likes. Again quoting Arch Wiki here:

Additionally, if the attacker knows your IP address, they can send packets with a spoofed source header and get your IP address banned. link

https://infosec.mozilla.org/guidelines/openssh.html < this is a great read on hardening OpenSSH. Key points (besides the ones Jeff mentioned to avoid repetition):

  1. Use only RSA, ED2519, ECDSA for hostkey algorithms
  2. Use chacha20-poly1305, aes{256,192,128} for cihers. Using chacha20-poly1305 is preferred:

When CHACHA20 (OpenSSH 6.5+) is not available, AES-GCM (OpenSSH 6.1+) and any other algorithm using EtM (Encrypt then MAC) disclose the packet length - giving some information to the attacker.

  1. Use kernel sandbox: UsePrivilegeSeparation sandbox
  2. Deactivate moduli shorter than 3072 bits
  3. MFA is recommended whenever possible. BUT...Be careful with MFA using OTP:

ATTENTION In order to allow using one time passwords (OTPs) and any other text input, Keyboard-interactive is enabled in OpenSSH. This MAY allow for password authentication to work. It is therefore very important to check your PAM configuration so that PAM disallow password authentication for OpenSSH.

  1. Be careful with SSH agent forwarding and if possible use a safer alternative (-J flag on OpenSSH=>7.3)
# Single jump
$ ssh -J ssh.mozilla.com myhost.private.scl3.mozilla.com

# Jump through 2 hops
$ ssh -J ssh.mozilla.com,ec2-instance.aws.net 10.0.0.3

# Copy data from a host
$ scp -oProxyJump=ssh.mozilla.com myhost.private.scl3.mozilla.com:/home/kang/testfile ./
1 Like