Fedora directory users - Aug 2006 - TLS authentication

Basically I am trying to use FDS for LDAP authentication for centralized
authentication on my Linux network and a need to make sure that it is
secure.  I figured that enabling TLS for authentication would be a good
start.  I read the Red Hat Directory Server administrator guide chapter
on TLS and followed the howto at
http://directory.fedora.redhat.com/wiki/Howto:SSL.  It looks like I have
TLS enabled because I can get my Linux clients using the OpenLDAP PAM
module to authenticate with TLS enabled, but my LDAP server will also
let them authenticate without TLS!  

If someone authenticates without TLS, does that mean that their login
credentials are being passed in the clear?  

How do I make the FDS to only allow TLS authentication?

My basic goal is to make this secure.  

I also have two medium vulnerabilities the keep popping up with ISS that
I need to resolve but can''t seem to find the proper configuration in
the
admin console. 

" LDAP NullBind: LDAP anonymous access to directory

The NULL bind entry allows a user to access the Lightweight Directory
Access Protocol (LDAP) directory anonymously. An attacker could take
advantage of the NULL bind entry to anonymously view files on the LDAP
director.
Remedy:
Disable the NULL bind entry or control the entry with Access Control
Lists (ACLs).
References:"

--and--

" LDAP Schema: LDAP schema information gathering

An attacker could access the Lightweight Directory Access Protocol
(LDAP) schema to gain information about the LDAP server. The LDAP server
dumps its schema, which can show all necessary attributes needed for an
object, including hidden or non-readable attributes. An attacker could
use this information to access directory listings and plan further
attacks.
Remedy:
Disable the cn=schema entry or allow only authorized users to view the
entry.
References:"

Any recommendations on any of these points would be helpful...  Thanks,

Sam Adams
General Dynamics - Information Technology

Adams Samuel D Contr AFRL/HEDR wrote:
> Basically I am trying to use FDS for LDAP authentication for centralized
> authentication on my Linux network and a need to make sure that it is
> secure.  I figured that enabling TLS for authentication would be a good
> start.  I read the Red Hat Directory Server administrator guide chapter
> on TLS and followed the howto at
> http://directory.fedora.redhat.com/wiki/Howto:SSL.  It looks like I have
> TLS enabled because I can get my Linux clients using the OpenLDAP PAM
> module to authenticate with TLS enabled, but my LDAP server will also
> let them authenticate without TLS!  
>
> If someone authenticates without TLS, does that mean that their login
> credentials are being passed in the clear?
>   
Yes.  But how are they authenticating other than PAM?  That is, if PAM 
is set to use TLS, how can they login through PAM without
TLS?
> How do I make the FDS to only allow TLS authentication?
>   
I don''t think you can.  The startTLS operation requires the non-secure 
port.  If you just want to use LDAPS (TLS without startTLS) then you can 
disable the non-secure port.  Then all server traffic must be
encrypted.
> My basic goal is to make this secure.  
>
> I also have two medium vulnerabilities the keep popping up with ISS that
> I need to resolve but can''t seem to find the proper configuration
in the
> admin console. 
>
> " LDAP NullBind: LDAP anonymous access to directory
>
> The NULL bind entry allows a user to access the Lightweight Directory
> Access Protocol (LDAP) directory anonymously. An attacker could take
> advantage of the NULL bind entry to anonymously view files on the LDAP
> director.
> Remedy:
> Disable the NULL bind entry or control the entry with Access Control
> Lists (ACLs).
> References:"
>   
Yes, you can disable access with ACIs by removing the anonymous search 
ACI.  However, this may disable apps like PAM that first need to perform 
a search for the user''s userid (e.g. at a login prompt).  Some apps 
(like PAM) allow you to perform the search as a real user, so you can 
grant search access to only that user.  You can also use SASL/Kerberos 
to avoid sending cleartext passwords over the wire.
> --and--
>
> " LDAP Schema: LDAP schema information gathering
>
> An attacker could access the Lightweight Directory Access Protocol
> (LDAP) schema to gain information about the LDAP server. The LDAP server
> dumps its schema, which can show all necessary attributes needed for an
> object, including hidden or non-readable attributes. An attacker could
> use this information to access directory listings and plan further
> attacks.
> Remedy:
> Disable the cn=schema entry or allow only authorized users to view the
> entry.
> References:"
>   
Again, you can simply remove the anonymous search ACI on this entry, but 
this may break some applications that require anonymous access to query 
the schema.
> Any recommendations on any of these points would be helpful...  Thanks,
>
> Sam Adams
> General Dynamics - Information Technology
>
> --
> Fedora-directory-users mailing list
> Fedora-directory-users@redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-directory-users
>

Adams Samuel D Contr AFRL/HEDR wrote:

  > I also have two medium vulnerabilities the keep popping up with ISS
that
> I need to resolve but can''t seem to find the proper configuration
in the
> admin console. 
> 
> " LDAP NullBind: LDAP anonymous access to directory
> 
> The NULL bind entry allows a user to access the Lightweight Directory
> Access Protocol (LDAP) directory anonymously. An attacker could take
> advantage of the NULL bind entry to anonymously view files on the LDAP
> director.
> Remedy:
> Disable the NULL bind entry or control the entry with Access Control
> Lists (ACLs).
> References:"
> 
> --and--
> 
> " LDAP Schema: LDAP schema information gathering
> 
> An attacker could access the Lightweight Directory Access Protocol
> (LDAP) schema to gain information about the LDAP server. The LDAP server
> dumps its schema, which can show all necessary attributes needed for an
> object, including hidden or non-readable attributes. An attacker could
> use this information to access directory listings and plan further
> attacks.
> Remedy:
> Disable the cn=schema entry or allow only authorized users to view the
> entry.
> References:"

Those are not vulnerabilities, they are deliberate features in the 
LDAPv3 standard.

  Those two nessus/ISS tests, among other LDAP related tests, are born 
of senseless "rationale" which was contributed to nessus several years
ago by a nessus mailing list member. Back then, the nessus engine 
creator was asking the nessus mailing list to submit any kind of test 
they could think of, so they could eventually brag about having 10k 
types of scans. There was no quality control involved, tests were just 
accepted at face value. And many of the explanations are not logical or 
rational if you really sit down and think about them. I think nessus and 
ISS trade or sell tests to/with each other, or something... Anyhow, one 
of their key marketing points is the number of included tests.

  It is up to a directory architect to consider the security 
ramifications of his or her design, not nessus or ISS. If you want to 
allow anon access to some portion of your directory, and lock down other 
portionss, then there is absolutely nothing wrong or insecure about 
that. Companies have public (anonymously accessible) portions of their 
website, don''t they? Is that a vulnerability?

  As well, claiming that anonymous schema discovery is a vulnerability 
is just plain nonsense. Knowing the name of an attribute which is not 
anonymously readable doesn''t help you in any way, shape, or form to
plan
an attack on an LDAP server. And the LDAP standard does not contain 
support for "hidden" attributes, unless you consider operational 
attributes which need to be explicitly requested. Operational attributes 
have well known names and are not easily extendable by directory architects.

  Sorry for the rant, but I''m particularly fed up with the 
self-proclaimed "security experts" spreading misinformation like this 
and trying to take over the networks with fud.


BR,
mike

Adams Samuel D Contr AFRL/HEDR wrote:
>I also have two medium vulnerabilities the keep popping up with ISS that
>I need to resolve but can''t seem to find the proper configuration
in the
>admin console. 
>
>" LDAP NullBind: LDAP anonymous access to directory
>
>
>  
>
...
>" LDAP Schema: LDAP schema information gathering
>
>  
>
In addition to the other posters comments I would point out that with 
zero access control configured in the DS nobody but the directory 
manager can do anything - zero access by default.  The best method of 
securing the server is to start with that blank sheet and selectively 
enable targeted operations for targeted users/groups on targeted sets of 
entries. For example, your requirement is that pam operates: add the aci 
that makes that happen and no more. The default aci''s added on install 
should be treated as examples only that just happen to be suitable for 
casual evaluation.

Most deployments can get away with very few aci''s in order to enforce 
their policy. Adding aci''s when something is found not to work
correctly
due to insufficient access is a lot less painful than the ramifications 
of overly broad grants of access.

-- 
Pete

Haha, I know exactly what you mean!  My workplace is full of "security
experts" that don''t even know what ICMP is.  I could send you some
results of some serious "ping vulnerabilities" so we all could get a
good laugh, but I digress.  Knowing how to run an ISS or Nessus scan
does not necessarily make you a security expert. 

Anyway, should I worry about clients using the LDAP to authenticate
without TLS?  Do I need to set my directory server such that users can
only authenticate only if they have TLS enabled?  

Sam Adams
General Dynamics - Information Technology
Phone: 210.536.5945

-----Original Message-----
From: fedora-directory-users-bounces@redhat.com
[mailto:fedora-directory-users-bounces@redhat.com] On Behalf Of Mike
Jackson
Sent: Tuesday, August 08, 2006 2:47 PM
To: General discussion list for the Fedora Directory server project.
Subject: Re: [Fedora-directory-users] TLS authentication

Adams Samuel D Contr AFRL/HEDR wrote:

  > I also have two medium vulnerabilities the keep popping up with ISS
that
> I need to resolve but can''t seem to find the proper configuration
in
the
> admin console. 
> 
> " LDAP NullBind: LDAP anonymous access to directory
> 
> The NULL bind entry allows a user to access the Lightweight Directory
> Access Protocol (LDAP) directory anonymously. An attacker could take
> advantage of the NULL bind entry to anonymously view files on the LDAP
> director.
> Remedy:
> Disable the NULL bind entry or control the entry with Access Control
> Lists (ACLs).
> References:"
> 
> --and--
> 
> " LDAP Schema: LDAP schema information gathering
> 
> An attacker could access the Lightweight Directory Access Protocol
> (LDAP) schema to gain information about the LDAP server. The LDAP
server
> dumps its schema, which can show all necessary attributes needed for
an
> object, including hidden or non-readable attributes. An attacker could
> use this information to access directory listings and plan further
> attacks.
> Remedy:
> Disable the cn=schema entry or allow only authorized users to view the
> entry.
> References:"

Those are not vulnerabilities, they are deliberate features in the 
LDAPv3 standard.

  Those two nessus/ISS tests, among other LDAP related tests, are born 
of senseless "rationale" which was contributed to nessus several years
ago by a nessus mailing list member. Back then, the nessus engine 
creator was asking the nessus mailing list to submit any kind of test 
they could think of, so they could eventually brag about having 10k 
types of scans. There was no quality control involved, tests were just 
accepted at face value. And many of the explanations are not logical or 
rational if you really sit down and think about them. I think nessus and

ISS trade or sell tests to/with each other, or something... Anyhow, one 
of their key marketing points is the number of included tests.

  It is up to a directory architect to consider the security 
ramifications of his or her design, not nessus or ISS. If you want to 
allow anon access to some portion of your directory, and lock down other

portionss, then there is absolutely nothing wrong or insecure about 
that. Companies have public (anonymously accessible) portions of their 
website, don''t they? Is that a vulnerability?

  As well, claiming that anonymous schema discovery is a vulnerability 
is just plain nonsense. Knowing the name of an attribute which is not 
anonymously readable doesn''t help you in any way, shape, or form to
plan

an attack on an LDAP server. And the LDAP standard does not contain 
support for "hidden" attributes, unless you consider operational 
attributes which need to be explicitly requested. Operational attributes

have well known names and are not easily extendable by directory
architects.

  Sorry for the rant, but I''m particularly fed up with the 
self-proclaimed "security experts" spreading misinformation like this 
and trying to take over the networks with fud.


BR,
mike

--
Fedora-directory-users mailing list
Fedora-directory-users@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-directory-users

Adams Samuel D Contr AFRL/HEDR wrote:
> Haha, I know exactly what you mean!  My workplace is full of "security
> experts" that don''t even know what ICMP is.  I could send you
some
> results of some serious "ping vulnerabilities" so we all could
get a
> good laugh, but I digress.  Knowing how to run an ISS or Nessus scan
> does not necessarily make you a security expert.
Those ping vulnerabilities are the best :-)

> Anyway, should I worry about clients using the LDAP to authenticate
> without TLS?  Do I need to set my directory server such that users can
> only authenticate only if they have TLS enabled?  
As LDAP is easily decodable with e.g. ethereal, passwords can be 
extracted in plain text. So, yes, I would avoid sending passwords across 
the network in plain text without transport security.

I think that it''s easier to configure all of your authentication 
handlers (PAM, web apps,  IMAP server, etc) to use SSL/TLS than it is to 
try to force the LDAP server to only allow TLS users bind privileges...

Configuring PAM to use TLS is really simple. Just put the CA cert in 
/etc/openldap/cacerts, configure /etc/openldap/ldap.conf, configure 
pam_ldap /etc/ldap.conf, and you''re done. You can write a fairly small 
shell script to automate the procedure...

BR,
Mike

Adams Samuel D Contr AFRL/HEDR wrote:
>Anyway, should I worry about clients using the LDAP to authenticate
>without TLS?
>
That really depends on your deployment - how sensitive would you be to 
someone having their credentials sniffed off the wire? How likely is it 
that someone will attempt a non-encrypted bind? YMMV.
>  Do I need to set my directory server such that users can
>only authenticate only if they have TLS enabled?  
>  
>
By the time the bind code is evaluating whether a secure transport was 
used the credentials have already passed over the wire. If you are 
sensitive to this, then I would suggest you disable the non-secure port 
by setting its port # to zero, then the only way to attempt a bind is 
over the secure port using SSL.

-- 
Pete

Pete Rowley wrote:
> Adams Samuel D Contr AFRL/HEDR wrote:
>
>> Anyway, should I worry about clients using the LDAP to authenticate
>> without TLS?
>>
> That really depends on your deployment - how sensitive would you be to 
> someone having their credentials sniffed off the wire? How likely is 
> it that someone will attempt a non-encrypted bind? YMMV.
>
>>  Do I need to set my directory server such that users can
>> only authenticate only if they have TLS enabled?   
>>
> By the time the bind code is evaluating whether a secure transport was 
> used the credentials have already passed over the wire. If you are 
> sensitive to this, then I would suggest you disable the non-secure 
> port by setting its port # to zero, then the only way to attempt a 
> bind is over the secure port using SSL.
Since LDAP suggests to use startTLS to start up TLS sessions on the 
non-secure port, there should be a way to disallow operations before the 
startTLS happens.  Fedora DS does not support this.
>
> ------------------------------------------------------------------------
>
> --
> Fedora-directory-users mailing list
> Fedora-directory-users@redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-directory-users
>

I have been adding, modifying, and removing ACIs on different parts of
my directory, generally breaking things.  The restore feature has been
useful lately.  For example, if you talk away the anonymous access aci
or at least anonymous read to the various parts of your directory, you
can certainly prevent anonymous access to that part of the directory,
but then a lot of important features break like PAM or seeing those
parts in the admin console.  

Is there an easier way of modifying ACIs a know beforehand what the
effect will be other than modifying them in the GUI or changing the
expression and restarting the server?

Sam Adams
General Dynamics - Information Technology
Phone: 210.536.5945

-----Original Message-----
From: fedora-directory-users-bounces@redhat.com
[mailto:fedora-directory-users-bounces@redhat.com] On Behalf Of Pete
Rowley
Sent: Tuesday, August 08, 2006 3:11 PM
To: General discussion list for the Fedora Directory server project.
Subject: Re: [Fedora-directory-users] TLS authentication

Adams Samuel D Contr AFRL/HEDR wrote:
>I also have two medium vulnerabilities the keep popping up with ISS
that
>I need to resolve but can''t seem to find the proper configuration
in
the
>admin console. 
>
>" LDAP NullBind: LDAP anonymous access to directory
>
>
>  
>
...
>" LDAP Schema: LDAP schema information gathering
>
>  
>
In addition to the other posters comments I would point out that with 
zero access control configured in the DS nobody but the directory 
manager can do anything - zero access by default.  The best method of 
securing the server is to start with that blank sheet and selectively 
enable targeted operations for targeted users/groups on targeted sets of

entries. For example, your requirement is that pam operates: add the aci

that makes that happen and no more. The default aci''s added on install 
should be treated as examples only that just happen to be suitable for 
casual evaluation.

Most deployments can get away with very few aci''s in order to enforce 
their policy. Adding aci''s when something is found not to work
correctly

due to insufficient access is a lot less painful than the ramifications 
of overly broad grants of access.

-- 
Pete

Adams, Samuel D Contr AFRL/HEDR wrote:
> I have been adding, modifying, and removing ACIs on different parts of
> my directory, generally breaking things.  The restore feature has been
> useful lately.  For example, if you talk away the anonymous access aci
> or at least anonymous read to the various parts of your directory, you
> can certainly prevent anonymous access to that part of the directory,
> but then a lot of important features break like PAM or seeing those
> parts in the admin console.  
>   
http://www.redhat.com/docs/manuals/dir-server/release-notes/ger.html

I believe you can view effective rights in the console as
well.
> Is there an easier way of modifying ACIs a know beforehand what the
> effect will be other than modifying them in the GUI or changing the
> expression and restarting the server?
>
> Sam Adams
> General Dynamics - Information Technology
> Phone: 210.536.5945
>
> -----Original Message-----
> From: fedora-directory-users-bounces@redhat.com
> [mailto:fedora-directory-users-bounces@redhat.com] On Behalf Of Pete
> Rowley
> Sent: Tuesday, August 08, 2006 3:11 PM
> To: General discussion list for the Fedora Directory server project.
> Subject: Re: [Fedora-directory-users] TLS authentication
>
> Adams Samuel D Contr AFRL/HEDR wrote:
>
>   
>> I also have two medium vulnerabilities the keep popping up with ISS
>>     
> that
>   
>> I need to resolve but can''t seem to find the proper
configuration in
>>     
> the
>   
>> admin console. 
>>
>> " LDAP NullBind: LDAP anonymous access to directory
>>
>>
>>  
>>
>>     
> ...
>
>   
>> " LDAP Schema: LDAP schema information gathering
>>
>>  
>>
>>     
> In addition to the other posters comments I would point out that with 
> zero access control configured in the DS nobody but the directory 
> manager can do anything - zero access by default.  The best method of 
> securing the server is to start with that blank sheet and selectively 
> enable targeted operations for targeted users/groups on targeted sets of
>
> entries. For example, your requirement is that pam operates: add the aci
>
> that makes that happen and no more. The default aci''s added on
install
> should be treated as examples only that just happen to be suitable for 
> casual evaluation.
>
> Most deployments can get away with very few aci''s in order to
enforce
> their policy. Adding aci''s when something is found not to work
correctly
>
> due to insufficient access is a lot less painful than the ramifications 
> of overly broad grants of access.
>
>

> Adams, Samuel D Contr AFRL/HEDR wrote:
>
>> Is there an easier way of modifying ACIs a know beforehand what the
>> effect will be other than modifying them in the GUI or changing the
>> expression and restarting the server?
>
>
You don''t need to restart the server after changing access control,
like
most DS configuration it allows dynamic modification.

-- 
Pete