What is Digg?Sponsored by HowLifeWorks
How Private Online Shopping Clubs Work view!
howlifeworks.com - How to become a member and get discounts of up to 80% on must-have luxury goods
67 Comments
- davewelsh79, on 01/03/2008, -3/+19You should try to make your server secure rather than trying to hide it. Disabling protocol 1, key-based logins only, and no remote root access are all good advice.
Trying to hide your server by using a different port is attempting to get security through obscurity. You can do it if you want, but do all the other things you can to make your server secure first. - Carburetor, on 01/03/2008, -1/+14Another important thing is the "Port Knocking".
http://en.wikipedia.org/wiki/Port_knocking - antdude, on 01/03/2008, -0/+13Also, use DenyHosts -- http://denyhosts.sourceforge.net/ ... My buddies and I use it.
- enkoopa, on 01/03/2008, -0/+10Not bad tips.
Here's the best one though and the most overlooked. Toss this simple script in your rc.local. It will make iptables block any bad password attempt IP's for 15 seconds. I use this now instead of whitelisting which was a bit of a pain if I found myself somewhere unplanned and needed access to my server. Using logwatch I get maybe 2 login attemps per night. It makes the script-kiddies think the server died or something after their first login attempt fails. Make sure you have password tries set to 1 or 2.. nothing too high.
#!/bin/bash
# Change the value of external_if to the name of your Internet-facing interface!
external_if=eth0
/sbin/iptables --new-chain sshthrottle
/sbin/iptables --append sshthrottle
--match recent --update --seconds 15 --name sshthrottlelog
--jump DROP
/sbin/iptables --append sshthrottle
--match recent --set --name sshthrottlelog
--jump LOG --log-prefix "ssh connection stifled "
/sbin/iptables --append sshthrottle --jump DROP
/sbin/iptables --append INPUT --in-interface $external_if
--protocol tcp --destination-port 22
--match state --state NEW
--match recent --update --seconds 15 --name sshthrottle
--jump sshthrottle
/sbin/iptables --append INPUT --in-interface $external_if
--protocol tcp --destination-port 22
--match state --state NEW
--match recent --set --name sshthrottle
--jump ACCEPT - perhapsimcrazy, on 01/03/2008, -2/+12One Word... Kevlar
- manicallday, on 01/03/2008, -0/+8Dug for the simple fact it was on all on one page.
- cptl, on 01/03/2008, -0/+7I agree that you cannot just rely on security through obscurity. But the number of login attempts on my box has shrunk to just about 0 since I moved SSHD to a random high-numbered port. The scanners just check port 22 for the most part.
- dsendecki, on 01/03/2008, -1/+7Thanks for this — I'm a total newb when it comes to managing my own server (just got a dedicated box not too long ago and it's not managed) — so find these articles priceless. I've been collecting everything relating to Apache, etc, that's appeared on Digg. Check it out here: http://linkbag.com/dsendecki/tuning-apache
- mdvaldosta, on 01/03/2008, -0/+5I agree, in a similar boat. Had a server for a long time however hardening it is something that I don't really delve into. Quite useful.
- rastakid, on 01/03/2008, -3/+8Well, I think that would do more than these basic 'steps'.
Bullet-proof? How about using OPIE/SKEY logins instead of keys. What about port knocking? What about logging all session I/O to disk?
Running SSH on another port than 22 won't bulletproof your SSH service at all. That's just security through obscurity. If you rely on attackers not being able to find your SSH daemon because it's not on the default port your service isn't exactly bullet-proof. - ninja0, on 01/03/2008, -0/+4running on another port provides some security. I'm aware you can always just nmap the user or something, but if you dont configure your router properlu, and router supports stealth, then it makes it that much harder for them to scan.
- t0ny, on 01/03/2008, -0/+4Another thing I do is I only let users ssh in if they are in a group called sshusers. This keeps users created by some stupid script from being able to be hacked.
- spiffytech, on 01/03/2008, -0/+4Imagine a secret button/knock/etc. for the batcave. If you don't get the knock right, you can't even tell that the batcave is there. Once you get the knock right, you can verify that you're who you say you are like you would any private room.
Port knocking is the same. If I did a straight connect on port 22 to a port-knocking server, the server would drop my connection, making it look like that port isn't open at all, or that there isn't anything at that IP at that port, similar to port stealthing. Once I connect to the right sequence of ports, the port opens up to me and me alone, and I can proceed as normal.
This has two benefits: 1) Someone probing your server can't tell that you even have a certain service running (does he really have a target?) and 2) it functions like a second password, strengthening your security because you're not relying on just your password/key. - counterplex, on 01/03/2008, -0/+3I'd agree with ninja0. While security through obscurity isn't perfect i.e. by itself obscurity provides only minimal security, when combined with other forms e.g. limiting login options, adding port knocking etc you'll make any already secure solution a little more secure and there's something to be said about that.
- qwuinc, on 01/03/2008, -0/+3Even better, if you are administrating a multiuser server, prefer "AllowGroups sshusers" (over AllowUsers), that way you don't need to edit ssh config and restart the server every time you add a user.
- Punisher2K, on 01/03/2008, -1/+4I love how people try to condemn security through obscurity like it's a bad thing. Hiding things are an excellent way to protect them. If someone is port scanning they are going to go after a guy who has everything on the default ports before they attempt to identify what all your ports actually are. I'm not saying you should only hide stuff but people need to stop making it seem like a bad idea.
- spiffytech, on 01/03/2008, -0/+3On RHEL, 'knockd' does this. There's an article in one of the recent Linux Magazine issues that covers this.
- javaroast, on 01/03/2008, -0/+3Careful with denyhosts, there is a known vulnerability with denyhosts http://nvd.nist.gov/nvd.cfm?cvename=CVE-2006-6301 Make sure you are using the latest version
- mossblaser, on 01/03/2008, -0/+3"Port knocking sequences are public information as soon as you connect from somewhere where someone in the middle has the chance of sniffing packets." Not if they are cryptographic or are single use.
- qwuinc, on 01/03/2008, -0/+2Changing the port and implementing port knocking (iptables can do it rather easily using the recent module) are quite effective ways of hiding from casual scans and port scannings.
Just don't fall in the trap of thinking that using port knocking somehow means you are entitled to use weaker passwords (in case you don't disable password-based logins). Port knocking sequences are public information as soon as you connect from somewhere where someone in the middle has the chance of sniffing packets. - IphtashuFitz, on 01/03/2008, -0/+2Yeah, but it's not all that difficult to modify a port scanner to scan for high ports:
nmap -p1-65535 ... - jon3k, on 01/04/2008, -0/+2Straw man argument spotted. No one is saying move it to another port and ignore any other security concerns. Simply that there are lots of automated scanning attempts looking for port 22 these days. It's a nice addition to any already well secured sshd installation.
- rastakid, on 01/03/2008, -1/+3Agreed, but you must make sure the scanners have no ground at all to enter your system. If you use default passwords etc. you are still vulnerable. The only reason I would move my sshd to another port would be to get rid of the huge amount of login attempts being logged (and no, I don't want to disable logging).
- jon3k, on 01/04/2008, -0/+2You're forgetting that most of the SSH scanning that goes on these days involves scanning millions of hosts. If they only have to scan one port, they can scan through theses address really quickly. Let's do some quick math.
If I can check 100 hosts on port 22 every second, that's 6000 hosts a minute. Now, if I have to check 65k ports it would take almost 11 minutes to scan a single host.
Get it now? - sfrench, on 01/03/2008, -0/+2Also, right below "PermitRootLogin no" add "AllowUsers user1 user2" where user1, user2, etc are the users that are allowed to login (all other users will be denied through ssh)
One thing that wasn't mentioned is that one of your users should have the ability to login as root (su/sudo) if your going to turn off the ability for root to login through ssh.
The last tip here is make sure your server is logging everything (including login attempts) and your actually looking at the logs on a regular basis. - r00tus3r, on 01/03/2008, -0/+2Good stuff. I also recommend firestarter, if you know the ip address you'll be connection from ahead of time. Saw my guess attempts go from around 30 or 40 a day, to zero.
- mossblaser, on 01/03/2008, -0/+2If your server smokes on use then you need to fall right back to the basics of PC building, let alone server security...
- directrix13, on 01/03/2008, -0/+2Cool, so where is a resource that actually provides this functionality instead of just the definition?
- IphtashuFitz, on 01/03/2008, -0/+2But the people that do it are the ones you really need to worry about, not script kiddies.
- stix213, on 01/03/2008, -1/+2Security through obscurity should always be a second layer of defense, not the only one. But, it is naive to say that you should blanketly never do it because you are so high and mighty. 2nd layer of defense - it helps a lot because now you only have to focus on the few people who are actually skilled at attacking your computer, not the thousands of script kiddies that bang on the default port all day.
- mooninite, on 01/03/2008, -0/+1I do the same thing with iptables. Only 3 connections are allowed per 1 minute. This stops every script-kiddie I've seen. After 3 failed attempts the server looks "dead" to them and they move on.
Customizing SSH is nice and all, but treating the problem at the source (iptables) is the way to go.
I do the same for SMTP. It cuts down on mass spammers. - qwuinc, on 01/03/2008, -0/+1How about using the limit module/extension? Using that you could limit the number of new connections within certain time period. It's not IP-specific, though...
- qwuinc, on 01/03/2008, -0/+1Did you read my mind, or did you read my reply above? ;-)
This is one reason I like using AllowGroups, it also allows *me* to create local users (for example, guest X user account on a home workstation) instead of letting them login via SSH.
To be honest though, if any script creates a user account that can be logged into with a weak/default password, that sounds like a security problem that should be fixed. - s1mph0ny, on 01/03/2008, -0/+1If you think you're going to take down an openbsd server, you have another thing coming. Not only are the systems stable and secure, nobody cares about openbsd, so you won't get any help trying.
- JasonCox, on 01/03/2008, -2/+3And to think; I was all excited about getting armor for my server.
- IphtashuFitz, on 01/03/2008, -0/+1Another security measure, if you really feel like it, is to enable port knocking. It prevents simple port scanning from determining if you just moved ssh from the default port to another port. I've been using http://doorman.sourceforge.net for a while on a couple of my personal systems and I like it.
- javaroast, on 01/03/2008, -0/+1Same problem as with denyhosts. Make sure you patch according to this article if you use it.
http://www.ossec.net/en/attacking-loganalysis.html - kholburn, on 01/03/2008, -0/+1fail2ban - http://www.fail2ban.org/
- inactive, on 01/03/2008, -0/+1Why not also enable PAM to deny weak passwords? A server is only strong as its weakest password. Also enabling wheel group should be used so any user in wheel is even allowed to su/sudo
- jon3k, on 01/04/2008, -0/+1google.com
- ninja0, on 01/03/2008, -0/+1I dont quite understand. Why would you want to do this? From what I gather, is you connect on a preset sequence of ports, then certain defined ports open?
so the purpose of this would be what... i would connect say.. to 3 different ports then I would have my SSH port open up?
Please explain, I dont really understand. - rastakid, on 01/09/2008, -0/+1Alright, but we're talking about bullet-proofing your setup here...
- ninja0, on 01/08/2008, -0/+1and how would you go about doing this?
- jon3k, on 01/04/2008, -0/+1denyhosts is good, but if you just block all APNIC address space you'll stop 99% of these attacks anyway. Personally I just block all non-ARIN address space specifically with iptables.
http://www.iana.org/assignments/ipv4-address-space - cptl, on 01/03/2008, -0/+1The thing is, people don't do it.
- Stalks, on 01/03/2008, -0/+1 > so the purpose of this would be what... i would connect say.. to 3 different ports then I would have my SSH port open up?
Yes. - enterneo, on 01/03/2008, -0/+1OPIE is mature and not actively maintained at present.
- dbr_onix, on 01/04/2008, -0/+1Obviously it's not going to prevent any reasonably determined attacker, but that's not what it does:
It stops about every single automated mass-scan/dictonary-attack attempt against the SSHd - While if the server is even remotely secure, these aren't a problem (Not allowing blank passwords, and making sure common usernames don't use their login name as a password..), it *does* reduce log-noise, and makes it easier to spot more malicious attempts.
Other small point - Instead of globally disabling all password-logins via SSH, you can disbale a specific user's password by running "passwd -l" on the account. Useful for machines where you don't have access to the sshd configs (Shared hosting and shell-servers, for example) - antdude, on 01/03/2008, -0/+1Thanks for the tip. I am using 2.6, so I'm good.
- jon3k, on 01/04/2008, -0/+1Typically I would agree rastakid, but with the volume of SSH service scanning we're seeing targetting port 22 directly coming out of China, I've actually started recommending people move SSH off of port 22.
-
Show 51 - 67 of 67 discussions
© Digg Inc. 2009
— Content created and posted by Digg users is