I'm currently using Slackware 13.0 and have my machine behind a Linksys DD-WRT router. I believe the DD-WRT software has all ports blocked by default so opening up my machine for SSH login would only leave my system vulnerable at that port. To give an extra layer of security for that opened port, I've created the following script that would be invoked as the users' shell.

#!/bin/sh
#if SSH_CLIENT defined run nail with $SSH_CLIENT as an argument
if [[ -n ${SSH_CLIENT} ]]; then
nail -r “me@email.com” -s “SSH login detected from $SSH_CLIENT” -S smtp=smtp.1and1.com -c me@email.com cellphone@carrier.com
fi
exec /bin/bash

This would hopefully send me an e-mail when someone logs in via SSH and then give the user the bash shell.

Anyone else care to share their tips and suggestions on securing this machine before I put it out there for SSH?

Sure:
1) Linux has iptables which is a system level firewall. You can lock down all the ports other than the ones you want. (Or more accurately deny everything and only open the ones you want.) That way if someone gets past your Switch/Router they still don't have access to Linux without hacking it as well.
In iptables you can even DROP packets from locations you don't want so if the IPs that were going to ssh in were fixed and few you could set rules to only allow those IPs in and DROP all others.
2) Stop all unnecessary processes. No point in having a bluetooth process running if you're not intending for bluetooth access.
3) Use an unusual port for ssh (that is don't use port 22) as all the script kiddies will try port 22.
4) You could implement SELinux which offers even further protections at file, process levels. (Many people don't do this but it is there.)

P.S. Careful about "!/bin/sh" - On some systems it is NOT linked to bash but to something else like tcsh, dash etc.... Best to use "!/bin/bash" if you intend the script be run by bash or "!/bin/dash" if you intend it to be run by dash.

Thanks for the above! I did have one question about what you said regrading "!/bin/sh". Are you saying on some systems /bin/sh is a soft link to /bin/tcsh or some other shell?

Consider turning off passwords and using key based authentication instead. This will stop the dictionary type attacks. You should also disable root access (login) as an added precaution. It seems like a good percentage try to use root as the user name, so why even enable it.

Try

ls -l /bin/sh

to see, but I'd never rely on a symlink; always specify the shell you really want.

Yes.

You might want to look into using AllowUsers and AllowHosts to restrict who and what IP addresses can use SSH. You also might consider a general file system integrity checker like Aide or Samhain.

Hello,

Here are some links that I've found when looking into the same, some time ago. Most likely you can put them to good use.
20 Linux Server Hardening Security Tips
Advanced SSH: security tips and tricks

Kind regards,

Eric

1 members found this post helpful.

Thanks for all the suggestions and links guys!

While searching on ways to make my script work better, I found a post here http://forums.gentoo.org/viewtopic-t...5-start-0.html where the OP mentioned using /etc/ssh/sshrc. Would that be a better solution overall or would a script like what I have in my original post do the same?

While an email or pager alert is a "nice to have" in terms of security posture it certainly isn't a "must have". I'm saying that because while under the current scenario (and the assumptions you attach to the current state) everything seems happily uninteresting you should care what for example happens if: 0) the DD-WRT gets compromised or 1) if its configuration gets changed to allow full access, 2) when a user cracks wide open your SSHd setup or 3) a (seemingly) legitimate user performs certain tasks on your system, 4) you later on enable other services. In short what you should look for first are system hardening best practices and not focus on SSH alone. And please get rid of that misconception that your script would "give an extra layer of security" as it does not. It's only an after-the-fact alert and does not harden your SSH setup or keep users from trying (repeatedly).

For system hardening see your slackware documentation and http://www.linuxquestions.org/questi...erences-45261/ (and please do test after hardening) and for SSH security see the sticky http://www.linuxquestions.org/questi...tempts-340366/ thread where advice for securing SSH was posted ages ago.

I understand unSpawn, however because I am the only one that has access to this system, an e-mail notification would at least give me an indication of whether or not the person logging in was me or not.

With my current setup of using the above posted script, ssh into the box works, however scp does not. Does anyone have any suggestions on fixing that?