AllowUsers not working under certain conditions

[Donald Fraser]

Peter Stuge wrote on Friday, November 18, 2005 7:20 PM

> [...I'm pretty sure your guess is spot on. The possibility to disable
> verification of IP-addresses vs. hostnames was likely removed
> because, as I wrote, without that verification it is trivial for
> anyone in control of a DNS-server serving PTR records to spoof their
> connection as being from your allowed domain.

Its wasn't a guess, I actually walked my way through the code using file
diffs on old code to new code untill I found the relevant changes that
effected my scenario. It was a one liner - the following code has been
removed from file canohost.c

 if (!verify_reverse_mapping)
      return xstrdup(name);

> > Before I could use the option:
> > AllowUsers Auser@*.somedomain.com
> > One has to admit that, whilst having reverse mappping turned off,
> > this is far more secure than the option I'm now forced to use to
> > achieve the same of:
> > AllowUsers Auser@*

> I'm afraid not. DNS is not a secure system and anything that trusts
> DNS will be vulnerable to all problems that DNS is vulnerable to.

I am not trying to be picky here but the point is I am able to use a lesser
level of security and the openssh people haven't removed those options so
why take away a level of security that is better than the worst case
scenario.
For example consider the options:

1) No AllowUsers option: Any user on my server can log in from any IP
address and any domain, how secure is that? Open to all sorts of brute force
attacks, yet this option is available.

2) Set the AllowUsers option with USER1 USER2 USER3... Only the listed users
can log in and from any domain or any IP address. Hackers now have to guess
which USERS to login as, not very secure but better than scenario 1).

3) Set the AllowUsers option with USER at DOMAIN and no reverse mapping checks.
Only the listed users can log in and only from the listed domains. Hackers
now have to guess the USERS and the DOMAIN - not particularly secure but
better than scenarios 1) and 2).

4) Set the AllowUsers option to USER at DOMAIN with reverse mapping checks.
Only the listed users can log in and only from the listed domains and a
valid DNS A name record must exist. This is still not fool proof, especially
for the dishonest DNS operator with a hacked DNS that doesn't propagate with
other DNSs. The hacker still has to guess the USER name and the DOMAIN name
and be the primary DNS for the system they are hacking... Not particularly
likely, but not impossible - but a better security option than scenarios 1),
2) and 3).

So once upon a time I could choose any of the above four listed security
options, but now by removing the option VerifyReverseMapping, I am limited
to scenarios 1), 2) and 4). (Please don't shoot me down and say well there
are actually a lot of other options - I'm looking at one particular window
of options here)
You don't have to be a rocket scientist to figure out that options 1) and 2)
are not as good as the option 3) which is now not possible - its a simply
case of I should be able to choose which level of security I want, the more
options the better, it shouldn't be forced upon me!
One cannot use the argument we have taken this level of security away
because it was not safe, when there are several other levels of security
that are worse than the one taken away - end of story.

I've put my points forward, I think they are valid and that's all I can do.
I don't like having to patch things myself because it means I have to
maintain packages specific for our needs, but if the powers to be don't see
things in the same light as I do then I'll write a patch and be done with
it - that's the beauty of open source software... If you don't like it fix
it yourself and move on.

I do appreciate the feed back, its nice to be able to debate things in an
open environment,
so thanks for all the feed back.

Cheers
Donald Fraser