March 20146
February 20141
January 20145
December 20135
November 20132
October 20134
August 20134
July 20132
June 20131
May 20131
April 20131
March 20131
Full Archives

Tue, 19 Apr 2011

HBGary Open Letter - Air Gap

Our source code has always been air gapped from the Internet. The forensic examination confirmed that software development servers and workstations were not affected by the incident -- from HBGary

Anyone else find it hard to accept that none of the developers, testers, documentation writers or build people ever accessed source code from their Internet connected laptops / workstations? Especially considering the state of their other security measures.

Don't get me wrong, in some cases it's a sensible solution ( off-line key signing for example) but for entire teams working on a shared code base?

Posted: 2011/04/19 13:33 | /security | Permanent link to this entry

Thu, 08 Jan 2009

Limiting Failed SSH Logins using PAM

Ever wanted to limit the number of ssh login attempts a user can make before their account gets locked? Well, not really, but when brute force tools are so common and easy to use it's another useful trick in the sysadmins arsenal.

In this example I'll show you how to install, configure and audit failed ssh loging attempts on Linux. While the PAM mod_tally module is available for a number of different distros and Unix variants we'll set it up on Debian. First of all grab the package if you don't already have it -

apt-get install libpam-modules

Now we've installed mod_tally you have to add a couple of lines to the /etc/pam.d/ssh PAM config file for ssh.

$ vi /etc/pam.d/ssh

# add before @include common-auth
# lock the buggers after 3 attempts
auth required pam_tally.so onerr=fail deny=3

# add before @include common-account
# resets count if login successful
account required pam_tally.so reset

The ordering of the lines is important. In some configurations previous PAM checks can shortcut the full process. While this post isn't the place to learn all about PAM the first line of the example sets what to do if something strange happens, such as the log file being unavailable (onerr=fail) and how many times a login can fail before being locked (deny=3). The second line tells PAM to reset the counter once a successful login has occurred for a specific user. If you leave this one out every failure is remembered for ever and eventually all will be locked out.

Now you're up and running how do you find out what's happening? If you want to look at the current status then you can run the pam_tally command and you'll see output like this -

root@pam:/etc/pam.d# /usr/sbin/pam_tally
User ajones     (1000)   has 2
User lockme     (10010)  has 4

pam_tally also logs wherever your authentication events go (/var/log/auth.log on Debian by default ) so you can keep historical information or feed the attempts in to your normal log monitoring systems

# sample log line
Jan  8 19:16:24 pam pam_tally[30086]: user lockme (10010) tally 4, deny 3

To close the loop let's cover resetting the locked accounts. If you have a user complaining then you can run pam_tally --reset --user lockme to clear their tally. Another option (worth considering) is a scheduled reset. This gives you the benefit of slowing down brute force attacks while not requiring you to unlock all accidentally locked accounts. The simplest way to do this is to add a cronjob that runs a reset. Newer versions have an unlock_time=n option you can supply in the ssh PAM config file but that didn't work for me under Etch.

Posted: 2009/01/08 23:31 | /security | Permanent link to this entry

Thu, 21 Sep 2006

Run Security Scans from Visio

I'm not a huge fan of Visio but the ability to connect the MBSA to individual hosts and trigger scans is very neat. I'm also assuming that you can use the Visio scripting interface to mark machines that fail as a different colour. Full details over at the Visio Connector for MBSA article.

Posted: 2006/09/21 07:38 | /security | Permanent link to this entry

Wed, 06 Sep 2006

Own a SQL Server 2000 Machine and get ALL Passwords

Watch it be done in under five minutes in the MS SQL Preauth Attack, Pwdump and John the Ripper video. Surprising? No. Fun to watch? Yes! Every now and again it's nice to be reminded our systems are not as secure as we'd like to think.

Posted: 2006/09/06 22:59 | /security | Permanent link to this entry

Wed, 16 Aug 2006

Incompetents, Security and Hellish Policies

"You do not secure the liberty of our country and value of our democracy by undermining them. That's the road to hell.
-- Lord Phillips of Sudbury (source: BBC News - "Police decryption powers 'flawed'"

I don't normally post on politics or law because I'm not an expert and, to be honest (judging by my apache logs), they're only interesting to a small fraction of the people that stop by here. However, two of the security related news stories I've seen today need to be pointed out, first of all we have proof of the old saying, "if they want you bad enough they'll get you".

Only in this case "they" turned out to be a 12 year old child (and no, I don't read the Express - it's the only instance of the story I could find to link to) who'd run away from a care home in Merseyside. And made it on to a jet during "one of the tightest lock-downs in airport history". He only managed to sneak through passport control. And police. And security. And a metal detector and pad down. And the ground control checks. And through the departure checks.

Who ever said "The guards are most diligent after the break in" has obviously never met any of the massively skilled people at Heathrow. I liked "we're launching an investigation", I don't want an investigation, I want a full witch hunt; with bloodhounds. Followed by lots of high level sackings and possible prosecutions. Airports are a vital part of our infrastructure, something like this must be as near to criminal negligence as you can get without seeing a nice cell and that guy called "Bruiser" with the pretty tattoos on his knuckles...

Now I've released my bile let's get to the other story, well, another link. Some peers have claimed the Police decryption powers are 'flawed' and risk being abused.. No shit.

Posted: 2006/08/16 19:32 | /security | Permanent link to this entry

Mon, 26 Jun 2006

AIDE Agony

When it comes to host-based intrusion detection I'm most familiar with the Tripwire OpenSource Edition, while shopping around for a HIDS to deploy on a play box I decided to try AIDE. And got stopped at one of the first hurdles.

Tripwire has an interactive update mechanism, it runs a scan (based on your config file) and then prompts you to except, reject or mark changes as pending - within one operation. Unless I'm missing something, AIDE takes a generate signatures, user checks the output, generate signatures approach, which leaves a huge race condition open. Any files created / edited between the check and second generate steps will slip through the net.

Am I missing something or is this really how it works?

Posted: 2006/06/26 17:15 | /security | Permanent link to this entry

Wed, 08 Mar 2006

Know Thy Open Network ports

Which ports do your servers have open right now? How did you check? Netstat? Are you really sure that it's doing the right thing? What the host claims to be exporting isn't always the same as what other hosts on the network see. When did your DNS server start exposing that TCP port? Has it always been there?

I want a tool that keeps track of what ports a machine has open and shows me changes (and tracks when things change). It has to scan the whole port range from top to bottom and it needs to do UDP scans in under a couple of hours. Think of tripwire but for network ports. Changes have to be approved or they keep being flagged as suspicious. As a side effect it'll also show you when things go away. Hard to write? Not really. But why don't most of us already have it built and running?

It's also worth pointing out that this isn't the same role that programs like Nagios fill. You tell Nagios what to watch and it picks up changes in that limited scope. I want something to watch the whole (finite) port range and show me things I didn't think about.

Posted: 2006/03/08 20:45 | /security | Permanent link to this entry

Mon, 06 Feb 2006

Patching for Custom Config File Locations

While discussing the FIA via SSH article, one of my comments got some feedback; the comment was sudos config potentially giving the game away. A number of people suggested the same solution, patch where the source looks for the config file and compile it yourself. The idea is that you put a fake config file in the usual place, patch the source to use a different location and then compile the application. When it runs it leaves the fake config alone, uses the custom location you added and the attacker is none the wiser.

This isn't difficult to do. For example a number of honeypot articles recommend patching syslog so the attacker doesn't see a "log to remote host" config setting. Technically this works just fine. But that's not where you pay the price...

Doing something like this is a small security win but a huge usability loss. Firstly, every time you want to upgrade the binaries you need to patch, compile and occasionally even package them. After you've done this step you need to find a way of incorporating their distribution with the rest of your software. Lastly you have the enjoyment of having a sysadmin spend half an hour changing settings, restarting the command/daemon and NOTHING HAPPENS! Why? Because they changed the default config file. Which is a fake... You'll do this once and then swear off the technique for anything except a one man research box that you don't want to keep current.

Posted: 2006/02/06 23:33 | /security | Permanent link to this entry

Sat, 04 Feb 2006

File Integrity Assessment via SSH Article - Sysadmin Article

Hal Pomeranz has an interesting article on File Integrity Assessment via SSH over at sysadmin magazine (well worth a subscription). At my last job a couple of us discussed doing something similar so I enjoyed the article; it's nice to see someone actually implement the damn thing.

The basic idea addresses one of the implicit weaknesses with FIA tools. You give the attacker an obvious target to try and subvert. While there are little tricks you can employ to make their life harder (add a false positive so if they replace the binary with a fake it doesn't report everything you'd expect etc.) Hals technique moves the whole FIA setup off the machine. You only copy the FIA tools in when you're going to run the scan. This won't stop kernel level hacks written just for screwing with FIA but it does raise the bar a fair bit.

One of my suggested tweaks for this would be to replace the null passphrase root SSH. Firstly I dislike allowing root to SSH to a machine. Secondly, keys with no passphrase are often a bad thing. While SSH agent can make them better, a non-privileged account, sudo and the NOPASSWD option are often a better choice.

The config in '/etc/sudoers' will make it easier for a competent attacker to work out what's going on (although to make life harder you can still rename commands as mentioned in the article) but this is better than allowing such a dangerous entry point to all your systems.

Posted: 2006/02/04 20:28 | /security | Permanent link to this entry

Sat, 28 Jan 2006

Over Mounting in Linux

A topic that's been discussed to great length on one of (many) Linux lists I lurk on has been that of mounting one file over another. It's easier to show this with an example:

$ cat password

$ cat fakepassword

(root) $ mount --bind fake_password password

$ cat password

While this requires root access (or flimsy mount permissions) to execute, it is a nasty little trick. An 'ls' won't show anything strange but a 'mount' command will. It's also worth noting that this can be done with binary and executable files. 'root# mount --bind /tmp/attacker_ps /bin/ps' works as well as the example did.

Posted: 2006/01/28 19:46 | /security | Permanent link to this entry

Sat, 12 Nov 2005

Sudo Article Promoted Bad Behaviour

I like sudo, it allows you to give people (and automated jobs) more privileges without having to hand out the root password. One of the more important aspects of its use is restricting the commands a user can run. After all, limiting peoples access to rootly powers doesn't help much if they can just shell out to bash or edit the shadow file (or other important files) and locally escalate their privileges.

Unfortunately a Linux.com sudo article shows new users a number of ways of doing this without explaining why it's a really bad idea. I understand that a lot of people just give themselves full root powers using sudo (hell I do on my own machines) but in an article pointed at beginners, especially one that has examples of using an interactive editor with sudo, the concepts need to be explained and some good practices presented. More why with the how please.

The highlight of the article for me was introducing new users to the 'sudoedit' and '-e' options: "but it uses the editor in your $EDITOR environment string". How often do you check the value in $EDITOR? Neither do I. And you're expected to blindly trust, with full root powers, whichever command it points to?

Posted: 2005/11/12 16:33 | /security | Permanent link to this entry

OpenCON 2005 OpenBSD Slides

The OpenCON 2005 OpenBSD Slides are now available and linked to from undeadly.org. When ever the OpenBSD people get together and present on security it's worth ten minutes of the admins day to have a look for the new ideas, after all they'll often appear ever where else over the next year.

The highlights of this batch include an overview of how the congestion indicator works and allows you to log in even when getting DoSed, the changes to the ports and package tools (which are moving to Perl!) and the whole of Theos Exploit Mitigation Techniques slides. Especially the Stackgap slide.

PS: MagicPoint needs to output HTML with access-keys defined. It'd make the slides a lot easier to read...

Posted: 2005/11/12 15:53 | /security | Permanent link to this entry

books career cloud events firefox geekstuff linux meta misctech movies nottech perl programming security sites sysadmin tools tools/ansible tools/commandline tools/gui tools/network tools/online tools/puppet unixdaemon

Copyright © 2000-2013 Dean Wilson :: RSS Feed