today I executed sudo journalctl and I saw many entries like
20 21:39:16 osmc sshd: PAM 2 more authentication failures; logname=
uid=0 euid=0 tty=ssh ruser= rhost=18.104.22.168
20 21:39:18 osmc sshd: pam_unix(sshd:auth): authentication failure;
logname= uid=0 euid=0 tty=ssh ruser= rhost=22.214.171.124 user=root
20 21:39:20 osmc sshd: Failed password for root from 126.96.36.199 port
20 21:39:22 osmc sshd: Failed password for root from 188.8.131.52 port
20 21:39:24 osmc sshd: Failed password for root from 184.108.40.206 port
20 21:39:24 osmc sshd: Received disconnect from 220.127.116.11: 11: [preauth]
The attacks are still happening.
How to check whether they compromised my RPI2 and how to prevent
this type of attacks.
I need ssh opened to the public addresses.
Pick a good strong password for the OSMC user and set it with
You should also automatically block access from any IPv4s with repeated fail login attempts. This can be done with fail2ban. You can read more about it here:
geez, if your gonna have it simple enough on port 22 you can expect that sort of things to happen. As Sam said fail2ban is a good start there is also 2-step verification using google services
good luck and have fun
fail2ban is a start. Something else would be running SSH on a different port than 22, but that comes with several difficulties. Not as destructive but still problematic would be a port redirection configured in your router from incoming port e. g. 39641 to port 22 of Raspi’s IP.
One might even think about using a certificate for SSH and disabling pure password logins.
Anyway, the login attempts are most likely not from actual people but automated scripts scanning whole IP ranges for logins on standard ports.
they can try and fail…
doesn’t matter if 22 is open
How about iptables approach?
/sbin/iptables -N LOGDROP
/sbin/iptables -A LOGDROP -j LOG
/sbin/iptables -A LOGDROP -j DROP
iptables -I INPUT -p tcp --dport 22 -i eth0 -m state --state NEW -m recent --set
iptables -I INPUT -p tcp --dport 22 -i eth0 -m state --state NEW -m recent --update --seconds 60 --hitcount 4 -j LOGDROP
Block SSH Brute Force Attacks with IPTables)
fail2ban uses iptables.
those rules will work, but you probably want an ACCEPT on ESTABLISHED before to play it safe
If I forbid ssh login by password and use only keys for login, that will also help, wouldn’t it?
Why not just change SSH to a non-standard port??!
Easiest way is to change the SSH port in your router to an non standard and forward to 22 - IF you really need access to you PI from the outside!
I don’t think that using non-standard port we can call protection.
Changing the port on it’s own is not enough however it will still eliminate 99% of the blind port scanning that is searching for IP addresses with port 22 open hoping to “get lucky”. On a non standard port only someone that was specifically targeting your IP address would bother to scan for a wide range of ports to find an open SSH server.
A good way to deal with this is to use ssh keys to login and disable password login - that way there’s nothing for them to try. Here’s a how-to:
SSH, or secure shell, is the most common way of administering remote Linux servers. Although the daemon allows password-based authentication, exposing a password-protected account to the network can open up your server to brute-force attacks. In this
One thing though - once you enable this, you will need your key file to be on whatever computer you login from, but it’s completely passwordless and very very secure.
I have just done it. Thanks