Re: AllowUsers not working under certain conditions

This is a discussion on Re: AllowUsers not working under certain conditions within the OpenSSH Development forums, part of the Networking and Network Related category; Peter Stuge wrote on Friday, November 18, 2005 7:20 PM > [...I'm pretty sure your guess is spot ...


Go Back   Usenet Forums > Networking and Network Related > OpenSSH Development

FAQ Members List Calendar Search Today's Posts Mark Forums Read
  #1 (permalink)  
Old 11-19-2005
Donald Fraser
 
Posts: n/a
Default Re: AllowUsers not working under certain conditions

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@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@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

_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
http://www.mindrot.org/mailman/listi...enssh-unix-dev
Reply With Quote
Reply
Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are Off
[IMG] code is Off
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are On



All times are GMT +1. The time now is 05:24 AM.


Powered by vBulletin® Version 3.7.3
Copyright ©2000 - 2008, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO 3.0.0