SSH brute force connection attempts #fail
Collected these over the past few months, reverse chronological order. Seeing different machines attempting to connect hundreds of times a day each is just, wow.
Some might say that a SSH blacklist daemon might help, but it only increases the time taken for a brute force attempt, and is of no use against a botnet trying to brute force the ssh login.
There are plenty of things that can be done to lock down the ssh server, and restricting it to only publickey is by far one of the most effective, counting that the resource (the server) you're protecting is pretty important.
Changing internal network IP address range
Finally gotten my lazy busy ass down to implementing some of those stuff that I've always wanted to (like they say: eat your own dog food).
For tonight it was the changing and limiting of the DHCP address range served by my router to be a non-standard one (i.e. not in the 192.168.1.0/24 range), as one of the defences against CSRF attacks against the router.
The change turned out to not to be as smooth as I thought it would be, even though I had very few devices in the network as compared to an office one. Would keep this in mind as I think about/recommend this to others.
Additional reading on the topic of CSRFing home routers, for those who're interested:
GNUCITIZEN: BT HOME FLUB: PWNIN THE BT HOME HUB
GNUCITIZEN: ROUTER HACKING CHALLENGE
Verifying rkhunter file warnings
I got this problem as my rkhunter installation detected changed files (due to updates), so I encountered this solution by steve as I was searching for a solution.
Of course, as there could be a root kit/trojan/malicious stuff running in your system as rkhunter's meant to detect, you should NOT fully trust anything running from the machine. But I had to rely on this solution temporarily until I can get it (rebooted and) checked out proper using a tool like Finnix.
Am reposting the script here for reference, but you can get the most recent copy of the script here .