Would conky be a nice solution? I use conky to display fan speeds, temps, etc.

Hmm. I don't have Seamonkey installed and KSysguard is working fine here.

I have some (not much) experience in fail2ban. Essentially it's the same as the iptables filter given by Ilgar. The main advantage I can see is that fail2ban can be configured to unban after a given amount of time. That way you won't lock your self out permanently if you're unlucky/clumsy. Fail2ban can be used on other service then ssh aswell. (i.e. apache, ftp etc).

Another way of securing ssh (Or other ports) is port knocking. There is a slackbuild for it here. It gives you an increased security, the intruder has to send 65535^4 packets to detect an open port. Then the brute forcing starts afterwards.

The disadvantage is of course that it is an extra action you have to perform to connect, i personally think it's not worth the trouble. Perhaps I should. Wikipedia also says that the knock daemon can die once in a while, in that case you won't be able to connect at all. Some knock daemons check for this restarts the daemon.

+1 for Fail2ban. Works wonders keeping script kiddies from trying to brute force their way into my ftp server. Also, changing your ssh port to something other than default is also an excellent idea. I run my sshd on port 9000.

I use to actually hunt down attackers by their ip address and report them to their ISP, but since the majority of attacks originate out of China or Russia, it is a waste of time to do that.

Another vote for Fail2ban here.
Also take a look at Denyhosts. I have used that one in the past and was very impressed with it.

Using both of these i cut my attack logs from 98000 lines in a couple hours to around 300.

Hi All,

Well after taking into account all of the excellent advice offered on this topic, I have now resolved my KSystemGuard processtable problem, and (hopefully ... will be watching closely) secured the ssh daemon.


What I have done:

1. After running 'swaret --dep' on my system, I determined that for some reason the lm_sensors was missing a dependency (maybe from removing previously mentioned Seamonkey Browser) ... I resolved this by reinstalling lm_sensors-2.10.6-i486-1.tgz package and re-running 'ldconfig' on the system.

2. I altered my Router NAT forwarded port 22 that was open for ssh, and have now NAT opened a >1000 port instead.

3. Editing of /etc/ssh/sshd_config: After backing up original file, I altered it so that:
a.) The Default Port is now changed from 22, to the new NAT forwarded port.
b.) Ensured that Protocol 2 is in use.
c.) Altered 'PermitRootLogin' variable to: no

4. I do not have a /etc/rc.d/rc.firewall file to add Ilgar's script to, so instead I installed the slackware package of Fail2Ban.

5. Chmod'ed +x /etc/rc.d/rc.fail2ban & ../rc.sshd

6. Started fail2ban daemon and ssh daemon.

7. Via LAN, attempted to ssh into server as root ... DENIED (Good).

8. Via LAN, attempted to login as [user-account] ... DENIED (Hmmm, that's not right).

9. Read about ssh options ....

10. Re-attempted to log into server as [user-account] with console string:
ssh <servername> -l <user-account> -p <assigned-port>

System allowed me to log in as [user-account], and then I was able to 'su' to root within the remote ssh terminal (Good).

11. Strengthened both 'root' and 'user-account' passwords using a combination of letters, numbers & punctuation.



I will be keeping an eye on the system log over the coming days to see whether I receive any more ssh attacks on my system.


Two small questions...

1. If I want to use Ilgar's connection limiting script, could I just create a new file /etc/rc.d/rc.firewall, and insert the contents of the script into it? ... or do I need to get a rc.firewall file from somewhere, then add the script content into that existing file?
(not sure why I don't have an rc.firewall file .. what package supplies it?).

2. Why does the remote LAN system now require that I have to input my modified port number?, and not just connect on the Server modified Default Port? (If I try to remotely ssh into the Server without specifying the actual new port, it attempts to connect on old port 22 ?, then is connection refused... shown here:
Ideas? , I'll look forward to your responses about these two questions.


I would like to wholeheartedly express my gratitude to every member of the forum that has contributed to this post ... Thank You!


Kind Regards

You can get the rc.firewall script from here and optionally add some personal tweaks. Once you get the rc.firewall script just put it in /etc/rc.d/ and do a chown root:root and chmod 711. That's it: simplicity of Slackware ...

You could set the ssh_config to use your port as the default instead of the usual port 22.

The only downside is that you would have to remember this for future use.

-Or-

You could create a script that executes the commands for you so all you have to do is say ./<ssh connect script>


I think that all the script would have to be is

That was why you changed the default port in the first place, right? If you use the standard port (22), you can connect directly. So can anyone on the Internet. They connect randomly and check if port 22 is listening for connections on every host on the Internet (Not the same person, but every computer will be checked by someone sooner or later). If it listens for connections, they start attacking you.

One solution was to change the default port to something else. That way, when they try to connect to port 22 they wont see anything and move to the next host on their list. A port scan of your computer will show that port 1000 (Or whatever sshd_config says) is listening for connections. A quick connection with telnet to that port will easily show it's listening for ssh. But every computer got 65535 ports to check, so to check all these ports will be a huge task (And it will be detected as abuse by their ISP). Therefor they usually only connect to the standard ports.

Your computer can't magically know that your server is listening on port 1000 instead of 22. Therefor you need to tell your client what port to connect. Did that make any sense?

If this is the only ssh server you connect to, you could make a simple solution with an alias:

alias ssh='ssh -p 1000'

Then it will try to connect to port 1000 instead of 22 for every ssh connection you will make. This will have to be in ~/.bashrc on every client computer you are using to connect to your ssh server.

Exactly, that's what I did. You may also need to make it executable (sorry I'm out of town, away from my computer, I can't check how I set it up).