What is Digg?Sponsored by Dragon Age: Origins
Join the Dragon Age: Origins development team on Facebook view!
facebook.com/DragonAgeOrigins - EA presents BioWare's new dark fantasy epic Dragon Age: Origins. '9/10' from Game Informer.
36 Comments
- Fratz, on 10/26/2007, -1/+17SSH and SCP are rare examples where security and convenience walk hand in hand. These are so much easier to use than telnet and ftp ever were, with many more features.
- samdu, on 10/12/2007, -0/+11I recently burned through a bunch of different apps (scripts, really, but them's semantics) to try to get a handle on the brute force break in attempts on my and some clients' servers. DenyHosts was one of them. The one I ended up using is Fail2Ban ( http://fail2ban.sourceforge.net/wiki/index.php/Main_Page ). Works like a champ and it's easy to configure. You tell it how many times a failed login is allowed and any more than that it will add an IPTables rule to block that IP address (you can specify an amount of time for the ban or a permanent ban). Now I can actually read my log files again. w00t!
- sjerome, on 10/12/2007, -2/+8ssh is the stuff of legends. :-)
- fiorenza, on 10/12/2007, -1/+7@Jabrone
I think he's saying that it's the *****. - gharding, on 10/12/2007, -0/+5Port knocking should be on this list.
- nakedcellist, on 10/12/2007, -0/+5Making RDP more secure? You could tunnel it over SSH...
- neoform, on 10/12/2007, -0/+4Anyone know how to make RDP more secure?
- portwojc, on 10/12/2007, -0/+4I would add that using something like bruteblock - http://samm.kiev.ua/bruteblock/ would also be a help. It helps to fight brute force attacks on ssh and even can be used for other services.
- pcrow, on 10/12/2007, -1/+5Running on a different port is more about keeping your log files quiet than about real security, but it's a good idea nonetheless.
I would suggest setting up iptables to redirect connections to port 22 to the real ssh port, but only for hosts that you normally use. That way you don't have to add an extra option on the command line except when connecting from an unexpected location. - Jabrone, on 10/12/2007, -1/+4Wow this stuff is awesome!
- djfelix, on 10/12/2007, -0/+3I got tired of logcheck emailing me with hundreds of login attempts every day, even after I installed fail2ban. The problem with fail2ban and other such scripts is they only work once the "attack" has already been attempted. It may be too late then ... If a 0-day remote SSH vuln is released ... you're screwed.
The best solution for me has been:
1) Whitelist good networks
2) Block SSH from all remaining networks
3) Install port knocker daemon
With the latest advances in port scanners, changing the port number probably won't help much if you leave it open to the world. Port scanners are smarter now, and can detect what services are running on which ports regardless of what number they are on. I use the following homegrown script on my Debian servers:
#!/bin/bash
# Create SSHSCAN bucket
iptables -N SSHSCAN
# Allow established SSH connections to continue to process
iptables -A INPUT -p tcp --dport 22 -m state --state ESTABLISHED -j ACCEPT
# Whitelist good networks/hosts
for i in `cat /etc/firewall-whitelist`; do
echo Whitelisting $i
iptables -A INPUT -s $i -j ACCEPT
done
# Setup the SSHSCAN rules to prevent brute force attacks
iptables -A INPUT -p tcp --dport 22 -m state --state NEW -j SSHSCAN
iptables -A SSHSCAN -m recent --set --name SSH
iptables -A SSHSCAN -m recent --update --seconds 300 --hitcount 5 --name SSH -j LOG --log-level info --log-prefix "SSH SCAN blocked: "
iptables -A SSHSCAN -m recent --update --seconds 300 --hitcount 5 --name SSH -j DROP
# Drop any SSH connection we haven't explicitly authorized.
iptables -A INPUT -p tcp --dport 22 -j DROP
# Drop DB connections from outside hosts
iptables -A INPUT -p tcp --dport 3306 -j DROP
iptables -A INPUT -p tcp --dport 5432 -j DROP
With that and the port knocker, logcheck is very quiet, and I can get in from wherever I want, whenever I want. The bit about SSHSCAN will block entirely any IP address that tries to hit my SSH port more than 3 times. I also run portsentry on ports that I don't use for my port knocker which pretty much blocks out anyone that hits me with nmap.
It's not foolproof, but it's better than most, and that's all I really need. Just enough to make any casual cracker move on looking for an easier nut to crack. - fak3r, on 10/12/2007, -0/+3Good idea, but my quick fix was to change sshd to use :666 instead of the default :22 -- now I get no more attacks, plus :666 was the original port that Doom used for network play ;)
- inactive, on 10/12/2007, -0/+3This is actually a pretty good list. The first step is the first step I take on every new Linux install that will be facing the outside world (which is to say all of them). I just find it hard to believe that so many distributions permit root logins by default, it's a giant gaping security hole to allow root to login anywhere. You should always login as a limited user and su - to root or sudo.
- bambam43410, on 10/12/2007, -0/+2Ask and ye shall recieve: http://pigtail.net/LRP/vnc/
- paulrenegar, on 10/12/2007, -1/+3http://duggmirror.com/linux_unix/HOWTO_Five_steps_to_a_more_secure_SSH/
It was starting to slow down for me already. - tedc, on 10/12/2007, -0/+2I was kind of hoping they'd get into how to control what the user can do once he's logged in. For example, how can you restrict an account so that only scp and sftp are available, but not a full shell?
- geronimo, on 10/12/2007, -0/+2That's like trying to fit a square into a round hole, just use linux and be done with it. btw to do that in linux you could create an iptables rule s.t. port 5500 only accepts packets from certain IPs.
the original article left out AllowUsers x y which is very useful. Otherwise there may be some odd accounts like mysql/postgres/mail etc that may allow SSH'ing in. - beermad, on 10/12/2007, -0/+2Small addition to my comment. This needs to be done on the machine your connecting FROM, not the one you're connecting TO.
- dblood, on 10/12/2007, -1/+3I don't think so. One of the benefits of SSH is convenience. If you have to worry about port knocking before connecting you no longer can connect from anywhere easily.
- hermatize, on 10/12/2007, -0/+1Good Article.... -tp
- spafbnerf, on 10/12/2007, -0/+1I always did the first two already. Step 3 was fictitious (oops!) and steps 4 & 5 aren't particularly necessary imo. :|
- Phocion55, on 10/12/2007, -0/+1Fail2Ban is pretty sweet and useful. Just recently checked my fail2ban logs and traced some lame attacks to somewhere in North Korea.
- inactive, on 10/12/2007, -0/+1Interestingly, Mandrake 8.2 used to include this feature as well. The firewall watched for unsuccessful attempts and banned your IP if you failed too many times. I kinda miss that functionality.
- beermad, on 10/12/2007, -2/+3No need to play with iptables.
Just add an extra two lines in your ~/.ssh/config file
---------------------
host myHostName
port 2222
----------------------
Then it will automatically connect on port 2222 instead of port 22. - Linh, on 10/12/2007, -0/+1you would do the same in windows, but you have to install openssh.
- argoff, on 10/12/2007, -0/+1In newer versions of SSH, there is a directive called "AllowUsers", that if included in the sshd_config will only allow logins to the users specified.
- seuaniu, on 10/12/2007, -0/+1Not to nitpick, but necessary or not depends on how valuable your server is to you. Or, usually more importantly, how valuable the secrecy of the data it holds is.
I work in an industry that absolutely requires you to take *every* step you can to maintain the integrity and secrecy of your data. If some steps seem redundant, well, good. I am required to take the steps outlined in the article, and some others, on machines that don't even face a public network. Anything that does face outward doesn't get to have ssh running on that nic, which can be a bitch when you want to telecommute a couple of days a week.
Some of the article might seem like a bit of overkill for many, but there are lots of scenarios where it wouldn't be considered enough, i.e. defense, finance, legal (hippa), medical (hippa again), etc. - diggduggjoe, on 10/12/2007, -0/+1I run sshd on port 22 on the local machines, but port forward to the outside world on others. It is a great way to keep the script kiddies and botnets at bay. I never see any scanning of my chosen ports. That does not mean a direct assault would not have a slow scan running, but it makes a real scan more visible in your logs. Some of the malware out there keeps the MS-SQL port, for example, very active in your logs..
- raindog469, on 10/12/2007, -0/+1Wow, I'm digging the article just for mentioning DenyHosts which led you guys to mention Fail2Ban. Seriously useful for anyone who doesn't want to come home and find a bunch of IRC bots running on your server.
- cornell, on 10/12/2007, -3/+3As always, paladin, a useful and concise article. Good job.
- critic, on 10/12/2007, -0/+0Thank-You for the link BamBam!
Appeciate your kind help and guidance in this Web 2.0 world.
Critic - asics, on 10/12/2007, -1/+0That's a great tutorial on securing a server.
http://www.asicsshoes.us/ - neouser99, on 10/12/2007, -3/+1the title indicates that it isn't secure enough out of the box!!! this is news to me
-neo - DontSayFanboy, on 10/12/2007, -4/+1RDP is already encrypted. I don't see how wrapping it in SSH by itself makes it any more secure.
If you really want to make RDP more secure, configure it to use TLS, which would add server authentication, which the RDP protocal doesn't already provide
http://technet2.microsoft.com/WindowsServer/en/library/a92d8eb9-f53d-4e86-ac9b-29fd6146977b1033.mspx?mfr=true - critic, on 10/12/2007, -5/+0Why are this articles always slanted towards linux users?
I have yet to see a good tutorial for XP people.
I'd love to see a concise tutorial for running VNC over Putty on XP.
Either than or some way to configure VNC to only accept connections from specific ips.
obtw - I think Linux users are the salt of the earth, and their knowledge is only exceded by their kindness to Windoze noobs. - Jabrone, on 10/12/2007, -11/+1What else do you use?
Browsing Digg on your phone just got easier with our enhancements to the 
© Digg Inc. 2009
— Content created and posted by Digg users is