Do your systems allow port 22 from the WAN?

[stevech]

Do your systems allow port 22 from the WAN along with very obtuse passwords, no anonymous, no telnet?

22 is of course SSH and on some SOHO NASes, it's the default port for special applications.

Or does everyone avoid the well known ports from outside access? And use auto-ban?

The number of login attempts per hour is amazing. I speculate that if the IP is in DDNS or a static DNS record, people harvest these DNS updates from fake DNS servers and use these IPs as newly-ripe targets. I say this because I used to have a static public IP and I didn't register it with a DNS, and got far fewer attempts.

 

[kamina]

Generally when I've opened port 22 from outside I either:

- Set strict password requirements and some kind of throttle / banning solution for login attempts and disable root login
- Only allow login with public key

You don't need DNS to attempt connection, just scan IP ranges and find where a service is listening -> attempt to connect.

One solution to get rid of the huge amount of (automated) login attempts is to map a different port on the router (since you will probably be using NAT anyway). Not that it will really increase security compared to a well configured service on the standard port, but at least it will reduce the amount of logs to a point where you might be able to analyze them.

 

[azazel1024]

Nope, I just block everything inbound. I don't have a compelling need to access my network externally, so I shut it all down.

 

[htismaqe]

I don't have any ports open externally. I'm in the same boat as azazel.

 

[Chrysalis]

On my home network, I dont run wan services.

In datacentres I dont use port 22 for ssh.

 

[sfx2000]

I wouldn't expose SSH on the NAS box directly - I've got the QNAP TS453Pro, and I do have a debian VM running on it, and there I do expose the SSH, and there using keys, not user/pass...

I used to run SSH over on 8022, and what I've found is that one that brute force SSH farms in China find it, they learn and start hitting that port as well, so I basically moved back to 22, and use Fail2Ban to put them in long term jails...

 

[sfx2000]

And along with Fail2Ban and sshd settings, also run UFW to rate limit - integration with UFW and Fail2Ban is a bit tricky, but together they're pretty effective...

On sshd, biggest thing is to disableRootLogin, and use AllowUsers with specific accounts - so then the farms can try to brute force all they want, but they're not getting in...

 

[stevech]

I moved SSH from port 22 to an odd one high above the reserved range.
No more attacks being logged.

I have auto-ban on.
No user named 'root'.
root-privileged user's password is very obtuse and lengthy.

The failed attempts in my log have some widely varying user names - some are funny.

SSH login is essential should the NAS' web server get hosed up (Apache on my Synology). That web server is not open through the router.

 

[sfx2000]

Steve, there's always root in a unix/linux based system, but one can seriously lock things down - Like you, there are times where I do want/need to get into the home server, but again, I never put the NAS directly online, it's thru the VM that I run inside it - then I can jump in to it if I need to...

I do enable the root account, but it's got an amazing random/long PW, and I'm set up to not have to use that account, and basically even if I use it, I'm either on the console directly via serial, or su - root in the case that I'm remote...

How I lock down SSH on the WAN/Public interface for my VM, and this might be useful for others that want to expose SSH to the outside world..

sshd_config - there more, but I've highlighted my specific custom items...

# What ports, IPs and protocols we listen for
# can use 22, or pick a port like 8022 or something...
Port 22
# Use these options to restrict which interfaces/protocols sshd will bind to
#ListenAddress ::
#ListenAddress 0.0.0.0
Protocol 2
# Authentication:
LoginGraceTime 30
# PermitRootLogin without-password
PermitRootLogin no
StrictModes yes
MaxAuthTries 3
# AllowUsers - this is a whitelist of allowed users
AllowUsers <your account only>
#MaxStartups 10:30:60
MaxStartups 3:50:10

This is enough to lock down SSH - then using Fail2Ban, in jail.local, this is how I'm set, as I also use UFW...

[ssh]

enabled = true
banaction = ufw-ssh
port = ssh
filter = sshd
logpath = /var/log/auth.log
maxretry = 3

And then for UFW, I can rate limit SSH by telling UFW to rate limit a service/protocol - note, that I don't need to name the port, as the port is defined by the service...

sudo ufw limit ssh/tcp

For details on iptables/ufw rate limiting, check out debian's article...

Anyways, hope this helps some out...

 

[stevech]

I mean a 'root' username.

I don't muck around with shell commands to my NAS.
Years back, for a long time, I worked with Unix, Sun OS, DEC's Unix, etc. for a living as a developer. But that was before rampant hacking and e-vandalism.

 

[sfx2000]

I mean a 'root' username.

I don't muck around with shell commands to my NAS.
Years back, for a long time, I worked with Unix, Sun OS, DEC's Unix, etc. for a living as a developer. But that was before rampant hacking and e-vandalism.

I would never put a consumer NAS out on the public internet - and I strongly suggest to folks, while yes, SSH/Telnet might be available - resist the temptation to make changes down in the shell of a consumer NAS box... breakage can occur very quickly.