Re: Linux basic authentication?

["List Spam" <listspam () gmail com>]

On 2/16/06, Bhavatosh <bhavatosh () gmail com> wrote:
> Hi,
>
> PAM with the LDAP would be te best combination I guess.
>
> -Bhavatosh

The best combination for what - sending credentials across the wire in
the clear?  Unless you wrap LDAP up in TLS (SSL), all of your LDAP
communincations are plain-text and easily sniffed.  Having a
centralized account database is great - both from an administration
and liability/response standpoint - and having an LDAP directory
(whether it be slapd, Active Directory, whatever) is one good way to
accomplish this.  Just make sure that you secure the communications
and the directory contents.  There are enough attack vectors floating
around in a typical network and there's no need to introduce another
when it's a simple matter of going through a couple extra
configuration steps to mitigate vulnerabilties in the authentication
stuff.

The OP should do whatever is possible to minimize the ability to
define local accounts and restrict shell access to specific trusted
groups (e.g. wheel, custom sysadmin group defined in LDAP, etc)
through his distro's standard access control mechanism (e.g.
/etc/security/access.conf in RedHat-ish distros).  If folks need
access beyond "user" level access, give them the ability to sudo that
specific command (never let them sudo a shell or other program that
allows them to spawn processes unless you trust them) and centrally
log (e.g. a store-and-forward syslog setup) that privilege escalation
so that it can be audited, alerted, and reported on correctly.

Once this is done, you should only have to then worry about securing
physical access to the local console and any remotely accessible
services from privilege escalation and then ensure that you don't let
folks have too much privilege via configuration/design.  The only
thing then left to deal with is the chair to keyboard interface.

Regardless of the platform, the maximum amount of privilege a named
user can have is the maximum amount needed to perform the task they
are there to perform.  Unnamed users should have no privilege at all,
other than what you want anonymous public access to (e.g. marketing
area of corporate website).  Account control should be centralized in
order to ensure quick and global response should accounts need to be
immediately disabled and/or audited.  If a chroot'ed environment makes
sense for your environment and users, set it up.

Another idea:  Never rely on logged failures to gain a sense of
security.  Afterall, other than identifying potential attack sources
and verifying your configs, you expect them to fail.  While you still
want to log everything, what you really need to focus your audit
efforts on are successful accesses to critical processes and/or data
as that is where you will find the bad guys hiding as normal users. 
You should know what you want folks to have access to and developing
an audit facility to identify exceptions will do you well.

When it comes down to it, like many have stated, there are a bazillion
and one ways to get things done.  It's all a matter of what makes
sense for your business's operational environment, budget, and
support-staff skillset.  Above all, the number one concept to apply is
to provide the least amount of privilege necessary to get the job done
and audit and alert/report on the excepctions to that rule.

My two cents.

RE

---------------------------------------------------------------------------
EARN A MASTER OF SCIENCE IN INFORMATION ASSURANCE - ONLINE
The Norwich University program offers unparalleled Infosec management
education and the case study affords you unmatched consulting experience.
Tailor your education to your own professional goals with degree
customizations including Emergency Management, Business Continuity Planning,
Computer Emergency Response Teams, and Digital Investigations.

http://www.msia.norwich.edu/secfocus
---------------------------------------------------------------------------