Hi,

I changed my ssh port (/etc/ssh/sshd_config) to an obscure number and confirmed it's working.
I am still seeing login attempts (and fails) in my /var/log/auth.log.

1. Is that normal or should those attempts no longer generate log traffic for auth.log?

2. Second question. I see in the log entries a mention of various ports ( ....from 49.234.100.133 port 59898 ssh2.....). Does this mean users are trying to log into the system on port 59898). If so, I guess I answered my first question.

Thanks
Nacht
----
Dec 16 20:03:51 jrpno sshd[20534]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=181.30.28.73
Dec 16 20:03:53 jrpno sshd[20534]: Failed password for invalid user securityagent from 181.30.28.73 port 43308 ssh2
Dec 16 20:03:53 jrpno sshd[20534]: Received disconnect from 181.30.28.73: 11: Bye Bye [preauth]
Dec 16 20:03:56 jrpno sshd[20536]: Invalid user mine from 49.234.100.133
Dec 16 20:03:56 jrpno sshd[20536]: input_userauth_request: invalid user mine [preauth]
Dec 16 20:03:56 jrpno sshd[20536]: pam_unix(sshd:auth): check pass; user unknown
Dec 16 20:03:56 jrpno sshd[20536]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=49.234.100.133
Dec 16 20:03:57 jrpno sshd[20536]: Failed password for invalid user mine from 49.234.100.133 port 59898 ssh2
Dec 16 20:03:58 jrpno sshd[20536]: Received disconnect from 49.234.100.133: 11: Bye Bye [preauth]
-------

If nothing listens on port 22, it's indeed odd. But check if your sshd really uses an obscure port. Have you restarted it after changing the configuration?

Run
to check the port sshd is using.

User mine tries to log in FROM port 59898. I.e. it's the port the SSH client is using.

1 members found this post helpful.

Both are normal. The bots can find your new port number in minutes and at that point instantly know that it is SSH and get back to work. If you set up either SSH keys or SSH certificates and turn off password authentication, then many of the bots can sense that and will leave your system alone regardless of the port number.

See: There's No Protection In High Ports Anymore. If Indeed There Ever Was by Peter N M Hansteen.

As for the high port numbers in the logs, those are the ports the remote attackers are contacting your system from, not the port on your system they are connecting to.

1 members found this post helpful.

I used to track all of the login attempts to see where they came from geographically. The majority were China.

Even with nothing pointing to an IP, you will still get login attempts every day from many different IPs. Changing ports weeds out some but not all. Iptables rules to drop connections after 3 failures will get you exactly 3 login attempts from a bunch of different IPs. They know pretty much every trick you can think of. I removed my external ssh port entirely this year, since I work from home anyway.

1 members found this post helpful.

I would suggest installing ufw or use iptables to filter the traffic to port 22 or the other port (ex. 2222)

Assuming 192.168.0.0/16 is on your local network

• iptables -I INPUT 1 -p tcp -m multiport --dport 22,2222 -s 192.168.0.0/16 -m conntrack --ctstate NEW -j ACCEPT

• ufw insert 1 allow in proto tcp from 192.168.0.0/16 to any port 22,2222 comment "SSH Local Network Access"

Also, do a grep on /etc/ssh/sshd_config to make sure you changed the port to the following:

• egrep -i PORT /etc/ssh/sshd_config

This is an old post, so I am not sure why the team did not tell you to limit access to the port using the UFW or the IPtables firewall lists. But oh well, I am sure you got everything done.

T

This is not an old post.

1) the post is not old
2) UFW is quite complicated
3) iptables is deprecated in favor of nftables
4) most password guessers are distributed and do not come from single addresses any more
5) switching to SSH keys or SSH certificates and dropping password authentication will block the most bots

1) the post is not old - ok
2) UFW is quite complicated - UFW is not complicated
→ dnf install ufw -y
→ systemctl enable ufw
→ systemctl start ufw
→ ufw enable, select y
→ ufw insert 1 allow in proto tcp from <local subnet> to any port 22,2222 comment "SSH Monitoring"
Not sure how complicated that is compared to others
3) iptables is deprecated in favor of nftables - ok
4) most password guessers are distributed and do not come from single addresses any more
→ If you block remote access (Internet) and limit access from certain ip addresses, this can be done or utilize the VPN
5)switching to SSH keys or SSH certificates and dropping password authentication will block the most bots
→ Yes, I agree using SSH Certs but it won't stop the entry from appearing in the logs, because once the key is not entered and there is a failure, a log entry appears.

I do think with both mechanisms will help but one way should not be the only way and they need another outside firewall to limit this traffic.

1. They should have an outside firewall blocking access to this server only limiting certain IPs to access it
2. I am not sure why they would not use SSH Certs since that is the defacto standard in most business environments, if not, then they have bigger issues
3. And this is what I found from nft:

% nft add table ip filter
% nft 'add chain ip filter input { type filter hook input priority 0 ; }'
% nft 'add chain ip filter output { type filter hook output priority 0 ; }'

You have to configure this first before you start adding rules, from the last time I looked, I did not have to do that with ufw or iptables.

T

They tend to mostly leave the SSH server alone once you have turned off password authentication. Though misconfigured bots may come in bursts anyway. But that is a far cry from the steady stream of probes which occurs otherwise.

2 members found this post helpful.

Yeah, but that can be handled by the outside firewall to limit specific traffic to that server, that may be the underlying issue, there needs to be two levels of security before it reaches the machine.

If it is a webserver, again, there needs to be limitations on who can access what, internal firewalls and in certain cases HIDS, NIDS and other solutions to thwart those attacks or even direct that traffic to a honey point after it has been identified to be as nefarious. Logwatch can help with identifying the traffic (other costly tools other there that do a better job) and then after a certain number of attempts, the system should block them anyway.

Evaluate the security posture to alleviate these problems.

Todd