Re: Firewall security: Re: Problems with simple Samba file share

From: Tony Lawrence (foo_at_pcunix.com)
Date: 05/10/05 

Date: Tue, 10 May 2005 16:11:17 -0400

Peter T. Breuer wrote:

>
> So he has disabled ssh login on his "safe" IPs? Cute. Then how did
> somebody get hold of this private key? It's only kept on the safe IPs!
> It seems that somebody doesn't need to log in via ssh in order to gain
> access to what's on disk in his safe IPs. Possibly a root trojan has
> been run ... (or his backup has been filched, etc.). Anyway, there is
> a high probability that his safeIPs are not safe.

It's quite tiresome that you keep pretending that this has not been
answered multiple times. Whack-a-mole again.. keys can be obtained from
stolen usb sticks, backup tapes, careless emails.. as noted at
http://aplawrence.com/Security/valuefirewalls.html - you did read that
apparently (someone named ptb left a comment; I assume that was you),
but you still choose to pretend otherwise.

>
>
>>But regardless, this is another red herring: we all understand that
>>nothing can give us absolute security. We are only talking about
>>increasing our safety - which this firewall does as detailed at
>
>
> To talk about it you have to analyse what you are talking about. The
> analysis seems to me to reveal that you do not obviously increase your
> safety by putting up a firewall around ssh - the only thing you guard
> against is people who already stole the private keys using them to do
> direct logins from china, and that didn't stop them stealing the private
> keys, so they likely have been able to get on to your safe IPs in the
> first place (I think it unlikely that they would not be able to get in
> once they had access to backups, but I grant you there are diffeernt
> degrees of access and they may not have sufficient to start with), and
> once there they can use the private keys to get into your server.

Once again you ignore the conditions as presented. Another whack-a-mole
strawman.

>
> If you want to argue about how they can escalate access to backups of a
> disk into access to where that disk is installed, well, there is likely
> to be something that one can figure after checking the configuration.
> For example they might see that samba is enabled, and reads its data
> from NIS.

You can read keys directly from a backup.. nothing more is needed.

>
>
>
>>http://aplawrence.com/Security/valuefirewalls.html
>
>
> Very good analysis. And I also recommend you to "Secrets and Lies", by
> Bruce Schneier.

Thank you. I'll order it.

>
>
>
>>>OK - but if the use for the f/w is to protect you against people who
>>>have already stolen your private key, then you should ask how it helps
>>>you. It didn't stop them stealing your private key.

Whack-a-mole: this has already been dealt with. There are ways to
steal keys that do not involve anything a firewall can protect from.
Some of them are things that a good security policy would surely
prohibit (safety of backups, for example) but that says nothing about
the value of the firewall. This is an attempt at misdirection; sleight
of hand for the casual reader.

>
>
>>I feel like I'm playing whack-a-mole with you. We've already dispensed
>>with this, but then you switch to something else, we knock that down,
>
>
> I have seen nothing "knocked down"! Is this some politically derived
> tactic? Claiming that you have answered when you have not?

Peter, do I really have to go back through nearly 200 posts and prove to
you that these things have been answered? How painful for both of us -
but that's why I put up
http://aplawrence.com/Security/valuefirewalls.html : you can see that
each of your objections has been "whacked down" there.

If I did take the time to pull your "moles", it would make quite a list..

>
>
>>and then this pops up again. Once again: no one claims the firewall
>>protects you from all conditions. It can protect you from stolen keys
>>being used from a non-approved ip address.
>
>
> Unfortunately, that doesn't do much - the aim of the firewall is to
> protect you from a result, namely the stealing of private info (for
> example - there are other classic results, namely changing private info
> or adding new info). It didn't stop the most private info of all being
> stolen! Now you claim that its use is to stop that private info being
> used to log in (as though they needed it the first time). Well, OK,
> but now the use is to prevent a breach being _escalated_.

Again, you are pretending that an entirely different condition exists
than that posited. It's easy to construct situations where a firewall
is of no value, but that does not change the fact the it is valuable for
the conditions stated.

>
> It's like this - if you have a machine gun that only stops burglars
> entering when it detects that they are carrying your family jewels, then
> the machine gun is evidently not effective by design, because its only
> use is when it has already failed to protect you.

Another whack-a-mole strawman. The stated objective of the firewall is
merely to block unknown ip's. No analogy exists to your jewel sensing
assault rifle.

>
>
>>Again, you ignore the stated conditions and set up your strawman yet
>>again. When will you stop?
>
>
>
> I see no "conditions".

You can't see http://aplawrence.com/Security/valuefirewalls.html ?

Those are the conditions. Rather simple to understand.

>
>
>>..

> I believe *I* am the one who suggested that they can get the data from
> backups or via listening to a bluetooth keyboard, etc. I have heard
> nobody else refer to such mechanisms, except maybe in the last post or
> two, and therefore nobody has "pointed it out to me".

Go back and review, Peter. You wanted to pretend that they needed to
have had access to the machine to steal its keys. I immediately
suggested theft or loss of usb sticks, backups, etc. The record is here..

>
>
>>http://aplawrence.com/Security/valuefirewalls.html ) they could have
>>obtained the keys by physical means: a stolen usb stick, a carelessly
>>discarded backup tape. But no doubt this mole will continue to pop up,
>>right Peter?
>
>
> If they have that information, they have enough to be getting on with.
> It's likely there is enough there to reveal backdoors or allow "social"
> pressure to be applied. But I'm very dubious of this whole setup - why
> is ssh permitted only from IPs that nobody may log in to? What kind of
> setup is that? The usual use of ssh is to permit a "private" connecton
> accross the internet, using secure identification. The implication is
> that the intended use is "from anywhere":

Oh, again with the "this is what I say ssh is for". Whack. Whack.

A hammer's normal use is for inserting nails, but it can be a fine way
to open walnuts, too. We use tools for whatever we find them useful
for: the history of mankind is full of inventing new uses for old devices.

Nor is the concept of restricting services to specific hosts alien to
ssh, as has already been pointed out to you - from the same man page you
quote. You didn't bother to comment much the last time that was pointed
out..

>
>>>The attack that makes sense is not against ssh but against the place
>>>that held the keys for ssh, thus rendering an attack against ssh
>>>unnecessary. That's the only sensible route - don't attack the
>>>fortress, attack the servant who has the keys to the fortress.
>
>
>>There's no doubt that a person intending such an attack would try to
>>breach the servant. And if succesful, our fw is pointless. But as we
>>keep saying over and over again, so what? When a woman zips her
>>pocketbook shut, it's harder for a pickpocket to get at her wallet. The
>>zipper is useless against someone who grabs the whole bag and runs.
>>That doesn't mean she shouldn't bother with the zipper.
>
>
> It does when her pocketbook is made of hardened zircon diamond and
> contains an interdimensional timelock that only a gamelan from Beta
> Centauri might have a chance of remembering the combination to. That's
> the degree of difficulty of breaking ssh by a frontal assault - there
> is not the slightest sense in forbidding people from china from trying!
> Let them try! Pickpockets, welcome all!

Again, you conveniently forget the conditions we are protecting against:
stolen keys, accidental misconfiguration, or fall-back to default
configuration due to software flaw. Whack. Whack. How many more times
must we see this particular mole?

>>Complete and utter nonsense, a mistastement of the conditions presented.
>
>
> In what way?
>
>
>> As has been said more than once.
>
>
> State the disagreement.
>

Peter, Peter, Peter. We keep stating the disagreements, but you never
address those. Instead, you keep coming back with the same pile of
straw, only rotating the hat he's wearing between a selected set. You
pretend that the keys can only be stolen by physical access. That
nonsense is dispensed with and the pile of grass pops up again wearing
the "the probability is too negligible to bother with". We point out
that the probability includes conditions that you keep ignoring and that
the cost of the protection is nearly zero while the potential cost of
not doing this is quite high, and bang! up pops the strawman again but
with the "there are no zero day exploit" hat. We knock that down, and
by gum, there's the "physical access" hat again. Whack-a-mole,
whack-a-mole, whack-a-mole.

The conditions are stated at
http://aplawrence.com/Security/valuefirewalls.html

If you post again with an argument that is already addressed there,
kindly make sure to do so against the conditions stated. Don't pretend
part of it doesn't exist.. you have to come up with something new if you
want to keep playing at this silliness. 

-- 
Tony Lawrence
Unix/Linux/Mac OS X  resources: http://aplawrence.com

Relevant Pages

  • Re: Jesus is the Key and the Door to Heaven
    ... The name Peter did not exist. ... Jesus actually said; "You are the Rock" ... I will give you the Keys to the Kingdom of Heaven. ... Who started this crap about Peter having the Keys to the gate? ...
    (alt.religion.christian.roman-catholic)
  • Re: Can I implement an autofill feature with a textbox?
    ... the arrow keys, though. ... Private mAutoFill As New ArrayList ... Private mblnLockout As Boolean ...
    (microsoft.public.dotnet.framework.windowsforms)
  • Jesus is the Key and the Door to Heaven
    ... Who has the Keys to Heaven? ... Who started this crap about Peter having the Keys to the gate? ... Jesus is talking here. ...
    (alt.religion.christian.roman-catholic)
  • Re: Encrypting files in XP
    ... You need to get the other user's public key (_not_ private key!). ... All that user has to do is encrypt one file on his PC and he ... if you lose your private keys you lose access to your files for good! ... This password protect user profile in which private ...
    (microsoft.public.windowsxp.security_admin)
  • Re: Certificates received from Windows CertStore: wrong public key (and incorrec
    ... I just did again a few tests with new generated certificates with larger ... RSAParameters exported from oRSA always have sizes corresponding ... The bogus private RSAParameters would be used, ... > size RSA keys also). ...
    (microsoft.public.dotnet.security)