Infosecurity Europe 2008: a selection of papers from exhibitors at Infosecurity Europe 2008, Europe's dedicated Information security event. Now in its 13th year, providing an education programme, new products & services, over 300 exhibitors and 11, 700 visitors from every segment of the industry. 22nd-24th April 2008 in the Grand Hall, Olympia: www.infosec.co.uk.

Why is LDAP Failing Audits?

For Unix/Linux shops, the security and compliance shortcomings of NIS and NIS+ have become evident in recent years. Lightweight Directory Access Protocol (LDAP) initially seemed a viable alternative that would also allow organizations to manage their Microsoft and Unix user populations in a standard way. So why are LDAP-based management systems now increasingly falling foul of auditors? And what can enterprises do to avoid this?

When it was first introduced, NIS provided a handy mechanism for centrally managing user and host information in large networks. However, the protocol lacks any inherent support for authentication and authorization, and it is difficult to produce audit trails keeping track of changes to user and host definitions across the system. With the advent of LDAP, many organizations saw the opportunity of consolidating user data for both Microsoft and Unix/Linux systems in one centralized directory. The problem is that organizations running LDAP are still failing security and compliance audits. LDAP simply does not per se include enough security features to satisfy auditors.

Unmanaged LDAP--that is, LDAP implemented as a core provisioning service within the enterprise, but without add-on functionality to secure and control its use--includes support for central controls on passwords, but without integrating security add-ons, LDAP password is the only authentication choice, unless users are allowed to set up their own authentication. In the latter case, a lack of centralized controls over authentication, for example being unable to prevent users from setting up SSH Public Key authentication with no password, can prove costly in audits.

Unmanaged LDAP does not provide enough fine-grained access controls to satisfy IT and compliance auditors. They want to know exactly who can access what resources, when. Unmanaged LDAP cannot control access for individual users or hosts, let alone at the service level.

Audit trails are another problem. Unmanaged LDAP provides no greater central auditing capabilities than NIS, and does not deliver the kind of documented output showing that provisioning and access policies are actually being enforced in the network that auditors require.

Finally, one of the biggest problems with relying on LDAP for network management is the issue of local functional accounts. When business critical applications require these local functional accounts to operate, application managers are rightly reluctant to hand over control of these accounts to external LDAP systems. However, not doing this leaves the enterprise with perhaps dozens of local accounts that are not under centralized control and not subject to policies. This leads to audit failures.

Given recent audit failures, more and more organizations are looking at strategies to manage LDAP across the different operating systems they use, releasing its potential as a provisioning and management tool while ensuring that it does not become a compliance liability.

One strategy on the table is to use Active Directory, Microsoft's implementation of LDAP, to manage all the resources in the network, both Microsoft and non-Microsoft. This category of solutions attempts to extend Active Directory authentication and Group policies to non-Microsoft resources including Unix and Linux systems.

While this approach leverages the investments many organizations have already made in Active Directory, solutions designed to graft Active Directory security models onto Unix and Linux environments typically control access on a host-by-host basis, and do not offer the granularity of managing access to individual Unix/Linux services. When it comes to the pressing problem of controlling the use of privileged accounts on Unix and Linux, a hot potato when it comes to audits, such solutions typically rely on variants of the freeware sudo utility, but do not include features like specific controls on su operations or keystroke logging.

Another approach to centralizing identity and access management in the enterprise is to find tools that will manage Unix and Linux systems with sufficient granularity to satisfy auditors and will at the same time integrate with managed LDAP systems, even allowing an LDAP system such as Active Directory to be used as the principal repository of identity data.

This strategy recognizes that specialized management systems are needed to control the specifics of the Unix and Linux environment. With a security model that differs from the Microsoft Active Directory Model, controlling Unix and Linux presents a different set of problems, including properly monitoring privileged accounts and the smooth deployment of secure protocols like SSH, to name but two. Such an approach will typically involve deploying a solution that can manage Unix/Linux authorization at the service level, not the host level, but can also securely integrate with LDAP directories to bring Unix and Linux into the enterprise's central provisioning and identity management system.

When it comes to auditing too, your audit output is only as detailed as the controls you have in place, so if you are controlling access at service level rather than host level, you have more detailed information to present to auditors. Similarly, robust controls on privileged account operations such as keystroke logging provide more evidence of accountability than using sudoers files to guarantee this vital element of Unix/Linux security.

This approach enables functional

accounts to be safely run in a local context meaning application managers can rest easy, but at the same time includes these local accounts in a centralized system of controls, subject to enterprise-wide policies, and centrally audited.

As industry searches for a new paradigm to manage mixed Microsoft and Unix/Linux environments, one thing is for sure: Unmanaged LDAP systems are failing audits, and it is imperative for companies to assess and determine what their strategy will be moving forward.

www.foxt.com

FoxT is exhibiting at Infosecurity Europe 2008.

Losing Control of Your Windows Network

Peter Wood, Chief of Operations, First Base Technologies I imagine that most people would consider the chances of an attacker guessing a privileged account name and password in two or three guesses to be astronomical. Unfortunately, nothing could be further from the truth. Breaking into corporate networks, and thereby corporate information, has never been easier. Why? Firstly, access to systems (usually Windows) at the desk-top is universal. Secondly, most people, including IT staff, don't appear to know how to select adequately secure passwords.

We have used the following technique for the past ten years, and it still gives us administrative control of a Windows network in at least fifty percent of cases. Imagine that you are a disgruntled employee or perhaps an intruder who has gained access to the building posing as a cleaner or a visitor. You will be able to gain complete control of the organisation's Windows network in less than 20 minutes if this works.

First you plug in a Windows laptop anywhere on the network--this can be in head office, at a branch office or store, anywhere in any trusted third-party premises or perhaps through a remote connection. You browse the net work using Windows Explorer and see all the Windows machines on the network--there's no need to logon or join a domain for this to happen (or of course you could be using a legitimate desktop or laptop machine if you are an employee or contractor).

Select a server (they're usually named in a obvious fashion) and attempt a "null session" connection--null sessions is a standard feature of NT & Windows 2000 which enables you to list users, groups, group memberships, etc. without any form of authentication whatsoever. There's plenty of free and licensed software on the Internet that will help you to establish a null session and then interrogate this information--my personal favourite is Hyena, a tool designed for managing Windows networks, but many miscreants will use free tools like SuperScan or Cain & Abel.

Next check the domain account lockout policy so you know how many password attempts you will be permitted in how long before the account is locked out (and a possible alert raised). Now list the users in the Administrators and Domain Admins groups and look for patterns, or rather exceptions to a pattern. Typically, organisations use formal naming conventions for user accounts, with combinations of surname and first name or initials such as WOODP.

Unfortunately, these are usually ignored where service accounts are concerned--service accounts are administrator-level accounts used to enable applications to log on to servers and domains (applications such as Backupexec, ArcServe and Tivoli are obvious examples). Select each of these service accounts in turn and try to guess its password--it's not as hard as you might think.

Frequently, network administrators will select something obvious, such as a password the same as the account name! Of course there are also long lists of default account names and passwords on the web which you can try. Beware that you don't exceed the account lockout threshold within the specified time period, otherwise even the most harassed admin may eventually guess something is up.