on the edge
computers & technology, books & writing, civilisation & society, cars & stuff
Greg Blackgjb at gbch dot net If you’re not living life on the edge, you’re taking up too much space.
Syndication / Categories
All Worthy organisationsAmnesty International Australia — global defenders of human rights Médecins Sans Frontières — help us save lives around the world Electronic Frontiers Australia — protecting and promoting on-line civil liberties in Australia Blogroll(Coming soon ) Software resources |
Sun, 12 Sep 2004Security confusionIn a recent post, Sandra Mansell talks about some security concerns that resulted from a breakin that she suffered: So much for linux being more secure than Windows […] ssh is supopsed to be SECURE! Isn’t that what it stands for? Secure SHell? The thing to recognise is that ssh is a tool whose purpose is to permit people to break into your system—so if you’re going to deploy it, then you certainly need to know how to do that safely if you don’t really want everybody in the universe to come in. If you want just one trusted user to be able to login, then configure sshd to only allow logins from that user, as an example. Consider not permitting password logins, as another suggestion. In any case, you need to study the behaviour and appropriate configuration of any software that sits on exposed ports and welcomes intruders. Stuff like apache comes to mind here, not just ssh. Further on, Sandra mentions a few possible solutions that seem to warrant comment: I have thought perhaps about running sshd on an unusual port to stop automated attacks against it. Any automated attack that couldn’t find sshd running on a different port is hardly worth describing as automated. Generally, security through obscurity is not all that powerful a method. I’ve also thought perhaps about setting up firewall rules to deny access to the ssh port to all but a few ‘trusted’ hosts. If you know what hosts they are and you’re sure that they’ll always have the addresses you expect, that might help, a little. My experience is that the time when you need to get emergency access to a box that needs attention, then you’ll be doing it from a machine that you weren’t expecting to use, or else your remote machine will just happen to have a different address on this occasion. I’d stick to sensible restrictions based on users, not hosts. We’re also going to be implementing an intrusion detection system. I want to know the next time somebody tries to ssh in as root. I’d say that an IDS is probably not going to be good value in the situation described. However, I’d be using something to watch my logs and I’d want to know about any attempts to ssh in—as any user—from remote hosts.
|