01-31-2017, 09:17 PM
(01-31-2017, 07:30 AM)MarkHaysHarris777 Wrote:(01-31-2017, 05:24 AM)Luke Wrote:(01-31-2017, 12:29 AM)dedseason Wrote: Might be a little early, but disabling public SSH access definitely helped. Uptime increased from 1 day to 3 days and counting.
There you go. Also, I saw that a recent update to transmission daemon has solved the issue on that end.
I will set up a 512mb board, open up port 22, log everything, and wait for it to die. I will share the log here and have smart ppl like pferrick and Xalius take a look at it.
Whatever your port is, add these iptables rules to your server to make sure that the invalid ssh password attempts ( more than three ) block the ip address:
sudo iptables -I INPUT -p tcp --dport 5789 -i eth0 -m state --state NEW -m recent --set
sudo iptables -I INPUT -p tcp --dport 5789 -i eth0 -m state --state NEW -m recent --update --seconds 90 --hitcount 3 -j DROP
What happens is fantastic against the botnet. Updates every 90 seconds... more than hitcount 3, if not valid then the ip address is blocked. In order for the botnet to try on that port again, they have to switch up ip addresses, and that takes time. And your rules are all ready for them... because the next attempt will block THAT address too, and so forth.
Set your ssh port to something above 5000 that only you know... and change it from time to time.
Never expose port 22 on your server to the outside; its just not worth it.
Thanks for the advice. Going to try that after a week or two of uptime.
I was using fail2ban for this purpose, but my ban was only 10 minutes and I would keep getting hammered. And yeah, exposing 22 (and not a custom port) to the public was a mistake