[clug] Linux Security
Daniel Pittman
daniel at rimspace.net
Wed Jun 11 13:52:22 GMT 2008
David Tulloh <david at tulloh.id.au> writes:
> Ian Bardsley wrote:
>
>> As I'm sure that at some point they are going to break something with
>> this system, I have been researching how to set this box up to allow
>> SSH over the internet through which I plan to tunnel VNC (I hope) in
>> the hope that I may be able to fix up damage if it occurs without
>> driving to Wagga.
[...]
> I tend to look at online security as setting up walls. You never
> really have any guarantee but so long as you have a few more walls
> than the guy next to you they aren't going to bother.
Well said. I must steal ^W remember that phrasing. ;)
[...]
> I've recently become a fan of public key authentication where you sign
> in using pgp keys rather than passwords.
That would be SSH public keys, which are distinct from (though not
technically that different from) PGP public keys.
> I would advise setting this up and then disabling password access to
> ssh entirely (config: PasswordAuthentication no, RSAAuthentication
> no). You can also restrict the key to only allow access from certain
> IP addresses in case you can't filter at the firewall or just like
> doing things twice.
This is an interesting security trade-off: it requires "something you
have" as well as "something you know"[1] -- but the trade-off is that
the something is only as secure as your local system, and may be much
easier to steal from you.
Anyway, I don't think this adds a lot of security compared to plain
passwords, but it does increase complexity -- and so risk -- a bit.
It isn't going to hurt, and may even be more secure, that using
passwords.
> It's a good idea to set up automated security updates in case of
> something like the recent ssh vulnerability debacle. It would also
> help close of firefox vulnerabilities and the like.
Good point, and one I omitted. Under Ubuntu the `unattended-updates' or
`apticron' packages will do this for you; on a yum based platform the
`yum-updatesd' package can apparently do this for you.[2]
[...]
> There's a lot of options out there, port knocking is kinda cool
Kind of, but there is zero *actual* security gain to it -- you might as
well institute a strong password policy and send that over SSL, since
the other doesn't gain you anything.[3]
> and the automated blocking Daniel mentioned looks handy but I haven't
> used them before, I'm sure someone could tell you exactly how to set
> them up if you wanted though.
For fail2ban, which I like, the process is "install and it goes"; the
fact that it is pretty much zero configuration to do ssh brute force
blocking is one reason I like it so much.
(It can do much, much more, and is very good, but being effective out of
the box makes lazy ol' me happy. :)
Regards,
Daniel
Footnotes:
[1] ...no one out there has a personal SSH key without a passphrase on,
do they? Tsk, tsk. Only for services, people. ;)
[2] I say this without specific experience at getting it to, you know,
actually /do/ this, but on paper...
[3] In theory, with the right setup and appropriate multi-path routing
it /might/ be harder for a TLA to intercept ... but they would just
pop you on a plane to a friendly third world country for a bit of
rubber-hose cryptography, I suspect.
More information about the linux
mailing list