Re: Firewall security: Re: Problems with simple Samba file share
From: Tony Lawrence (foo_at_pcunix.com)
Date: Sun, 08 May 2005 13:47:09 -0400
Peter T. Breuer wrote:
> Tony Lawrence <firstname.lastname@example.org> wrote:
>>Peter T. Breuer wrote:
>>>(I am trying to get you to name a scenario against which it protects,
>>>instead of mouthing vague generalities that may or may not be true!).
>>I have given examples, and so have other people. It hasn't been vague
> Please quote. I have seen only fuzzy generalities.
>>I have a server that accepts ssh connections, but only from a specific
>>set of IP's.
> Ah good! An example!
> Why restrict ssh? There's no point in restricting ssh. Nobody can log
> in through it without your password and/or digital key, no matter where
> they try from. And the whole idea is to give you access wherever you
> are calling from, securely.
You are presuming a use for ssh that does not exist in this situation.
The point of ssh is not just to give access from wherever I am. As I
said, this server only allows access from specific ip's. Why do you
presume to tell me what purpose I have?
>>Additionally, ssh is configured only to accept specific
> Nobody unauthorised can log in. If you don't want somebody in
> particular to log in through ssh, why have you given him a password on
> your machine?
Local users have local access through telnet and are allowed to log in.
Only a few users have a need and therefor the ability to log in remotely.
>>and additionally only allows public key authentication.
> Why do you think that he has kept his private key secure? Or do you
> mean that the client must present a certificate? (normally we do not
> care WHERE we are logging in from! The point of ssh is to allow you to
> log in from unexpected places, or expected places, securely, with
Again, you presume to tell me what the point of MY connections are.
No, in this case I don't go the extra extent of a certificate. So yes,
if the private keys are stolen, ssh would accept the connection -
except, as already noted, both the iptables and the hardware firewall
are also restricting this to specific ip's.
>>that, it's configured to lock out after two incorrect passwords - which
> No point - there's a 6 second delay anyway, and I type badly. And it
> helps somebody steal the password by using a fake ssh frontend that
> aborts the connect after stealing the password.
There is a point. If it becomes necessary to momentarily allow password
logins, the lockout protection from pam is already in place. It also
helps protect against some unknown exploit that manages to get to a
shell and now wants to become root.
>>of course can't be given because it doesn't accept passwords. That
>>server is also protected by a hardware firewall and iptables. Most of
>>this is completely redundant,
> It worse - it does nothing. You don't want to restrict ssh entries,
> because the point of ssh is to allow _secure_ entries from anywhere. You
> try logging in from your laptop on an internet cafe otherwise!
The presumption on your part is that I want to allow logins to this
server from an internet cafe. I don't. I allow logins from specific,
known ip's only.
> (I knew this would be the case - any example of a server that needs
> restriction is likely to be an example of a server that is prevented
> from doing what it is supposed to be doing; and it would do that
> safely, if left to itself; because that's what it is supposed to do).
Who are you to say what my server is supposed to be doing????
-- Tony Lawrence Unix/Linux/Mac OS X resources: http://aplawrence.com