Monday Apr 09, 2007

2007-04-09 Security Link Of The Day

Time to bang my own trumpet - occasionally I receive requests to address a particular customer's requirement, viz: three strikes lockout where if a person fails to log in to a system (eg: mistyping a password) - and if they fail to log-in three times in succession, then some manner of portcullis drops and the resource is barred from further access. The account gets locked, in the same-old way that was popular on even-then-antiquated mainframes back when I was a student, some 20 years ago.

So I wrote this explanation of my thoughts upon the matter:

"Three-Strikes" Password Security Considered Antiquated, Hazardous, Stupid and Wrong.


The problems of "three-strikes" in the modern enterprise environment are legion: in modern distributed authentication directories - NIS, LDAP, etc - there is no typically no central authority who is counting the number of failed authentication attempts, generally for technical reasons. For example: LDAP is deeply sub-optimal for poking little bits of data like that back to a central place, for immediate propagation to all replicas. No immediacy == no security.

Even if there were a central authority that brokered this sort of information it would be subject to flooding attacks by miscreants who could tie-up that one service and thereby prevent anyone from authenticating in your enterpise, with significant business impact.

You cannot architect around this risk by including a "timeout" or other "we've tried checking whether the user has struck-out but got no reply, so we'll let him in anyway" mechanism, because that defeats the whole point of the policy.

Anyway - what merits being called "authentication" nowadays? Would you like it if you changed your system password, and then - having walked away for a coffee - your automatic IMAP-enabled mail client goofed-up three authentications and locked you out of your own system because you forgot to update the client?


- Alec

Friday Apr 06, 2007

2007-04-06 Security Link Of The Day

So what happens if by hook or by crook someone breaks into your Solaris system and installs a trojan horse? Modifies the password file? Deletes a few old logfiles?

Or what if you run a heavily change-controlled system environment, and you need to know whether anything has been changed outside of the scope of your operational processes?

There's a solution built-in to Solaris 10: bart - Basic Audit & Reporting Tool, a truly boringly-named tool which does something both useful and interesting:

BART provides a quick and easy way to collect information on filesystem objects and their attributes so that, at a later time, you can determine whether there have been any changes. BART can help you detect accidental or malicious changes to files within an operating system due to either a security incident or change management incident.

BART is able to collect such information as an object's UID, GID, permissions, access control lists, modification time, size, and type. In addition, for files, BART generates an MD5 fingerprint from the contents of the file. For a full list of the attributes that can be collected, see the bart_rules(4) manual page.

There's a lovely white paper "blue print" explaining all this, available for download (nb: PDF document ; apparently HTML was neither pretty enough nor impressive enough) along with the rest of the Sun Security BluePrints some of which we'll be spolighting individually over the next few weeks.

- Alec

Tuesday Apr 03, 2007

2007-04-04 Security Link Of The Day

Another one in the "in case you missed it" category - Glenn Brunette on How to enable 'snoop' in non-global zones; it also serves as a useful primer about the use of limit privilege sets in zones - check out the article by Rich Teer for a more in-depth explanation.

I see you! snoop(1M)'ing in non-global zones!

Today's article talks about how to enable snoop(1M) in a non-global (or local) zone. In Solaris 10 today, the ability to use the snoop(1M) command or any other packet sniffer for that matter is restricted to the global zone. There is no way to snoop traffic from within a zone. Enter the Configurable Privileges for Zones project which integrated into Nevada build 37 and of course is available in OpenSolaris today.

Using this project and a little device manipulation, you can today get snoop working in a non-global zone, and here is how to do it... But first, a few warnings:

WARNING #1: This approach will allow the local zone to see all of the network traffic associated with the device that is added. Unless you use separate network interfaces for the global zone and other non-global zones, this means that following these instructions will allow a zone to see traffic intended for or exchanged with another zone.

WARNING #2: This approach is likely not generally recommended. This is meant only as an illustration of what can be done and may serve as a useful workaround in some environments until a more recommended, secure and supportable solution is available.


- Alec

Monday Apr 02, 2007

2007-04-03 Security Link Of The Day

Scary Dave scribed thusly, back in November:

Dave's Bit Bucket

I had a rather illuminating discussion with A Really Big Customer a little while back, in the context of a Really Big Project they are working on.

The customer have an issue which states that they are getting worried about "not having an IDS solution on Solaris 10". In terms of IDS, they are typically an ISS shop - they want something agent-based which will do centralised reporting and alerting on perceived usage anomalies.

It turns out that only one IDS vendor - this being Prelude, about whom the customer knew nothing - currently do an agent for Solaris 10. From their perspective, this is "a bit of a bugger".

Now, in my (moderately) humble opinion, there are only three reasons why an organisation would consider having IDS in the first place...

  1. Most of the time folk talk to be about IDS, they are working from a mechanistic risk evaluation and mitigation analysis system such as One I Won't Name Here which gets used when designing lots of Government stuff. This approach sometimes takes people down a technology path which might not be appropriate for them, and IDS isn't for everyone.

  2. Consider that IDS doesn't actually secure anything - it merely alerts an admin team to its belief that an environment is under attack. I've met a very few folk who want IDS because they have their entire underlying security infrastructure well and truly organised, and want to add IDS as not so much "the icing on the cake" as the "100s and 1000s and the cherry on top".

  3. Plain, simple pointy-haired stupidity, usually from some senior manager who just came back from Infosecurity or some other major show with a big wedge of brochures.

I don't find many folk (only two so far) in the situation of 2, and there's a lot more in 1. There's even more folk in 3. Really, IDS is only worth considering if everything else is nailed down properly already.

So, I was fortunate enough to get around a table with some senior geeks in the customer's admin and IDS department, and thrash a few things out in a forum where honesty ruled and political correctness was pretty much left at the door.

Things went roughly like this...

article continues on Dave's site...

Thursday Mar 29, 2007

2007-03-30 Security Link Of The Day - ROT13 Passwords

Solaris is - to the best of my knowledge - unique amongst Unix impementations in having a pluggable password encryption routine so that the administrator has the option of selecting a non-default password hash routine with the hope of making yourself more proof against password cracking - plus you can migrate users off-off older, weaker algorithms in a smooth fashion.

Brendan Gregg took this to the point of extreme silliness when he implemented a ROT13 password-hashing module for which he's posted the source; if you're not familiar with ROT13 it's the most trivial of pencil-and-paper ciphers, the sort of thing which got used to hide the punchlines of jokes posted via e-mail or on USENET.

I wouldn't recommend rolling out Brendan's code in an enterprise deployment - not unless you want all your passwords cracked in about 3 milliseconds flat - but it makes a nice proof of concept, and shows what you are free to do with the pluggable crypt API.

- alec

Wednesday Mar 28, 2007

2007-03-29 Security Link Of The Day

Glenn Faden is one of Sun's hardline security geeks, the prime mover behind the Solaris Trusted Extensions project which succeeds the older Trusted Solaris.

Glenn writes:

I have been working on an architecture for multilevel mail in Trusted Extensions in which mail can be delivered to labeled zones that are only in the ready state (mounted but not running). This would reduce the overhead of the current polyinstantiation approach in which an instance of sendmail is running in each zone.

For those unfamiliar with "trusted platforms", their core concept of "labelling" is to mark each file, directory, object, process or person on a machine with both a "compartment" (eg: finance, IT, payroll, human-resources) and some sort of "sensitivity" (eg: unclassified, confidential, secret); the trusted functionality permits "label-aware" applications to enforce need-to-know information handling rules.

That may sound outre or faintly military ("top secret") but there are dozens of possibilities for systems where you can keep programs aloof from each other, or from the data which they are processing.

Consider a webserver with one Internet-facing network interface, and another network interface attached to your credit-card database. Wouldn't it be nice to be assured that no data can pass from your credit-card data through to the Internet without being specially filtered, brokered and sanity checked? I find the idea rather appealing, I must admit.

Or consider the possibility of multilevel Instant Messenger - there would be no cut-and-paste between internal IM and external AIM, Yahoo or Skype; that really gets some finance people (eg: the sort who deal with traders) rather excited...

- alec

Tuesday Mar 27, 2007

2007-03-28 Security Link Of The Day

As our first Security Link Of The Day we'd really like to mention OpenSolaris and specifically the security communities and projects within it; there are over a score of projects including (but not limited to!) the following categories:

  • Cryptographic Framework (abstract access to accelerated cryptography)
  • IPsec (secure TCP/IP networking)
  • Kerberos (single sign-on solution)
  • SASL (simple authentication security layer, framework for authentication / authorization in internet protocols)
  • SSH (secure shell, encrypted interactive access with tunneling)
  • RBAC (role-based access control, constraining privileged user access)
  • Solaris Auditing (audit trail of user activity)
  • Trusted Extensions (compartmentalisation and labelling of user data and processes)

The best jumping-off points to investigate all the security possibilities are probably the Security Community Wiki and the main OpenSolaris Projects List.

Do take a look. There's a lot of nifty stuff there.

- alec


This blog provides security vulnerability fix notifications relevant to third party software components distributed and supported as part of Oracle Products.
Summarized version of this blog is available as a mapping of CVEs and solutions.


« August 2016