Tue, 19 Apr 2011
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?
Thu, 08 Jan 2009
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
# sample log line Jan 8 19:16:24 pam pam_tally: 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.
Thu, 21 Sep 2006
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.
Wed, 06 Sep 2006
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.
Wed, 16 Aug 2006
"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.
Mon, 26 Jun 2006
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?
Wed, 08 Mar 2006
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.
Mon, 06 Feb 2006
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.
Sat, 04 Feb 2006
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.
Sat, 28 Jan 2006
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 dwilson:password $ cat fakepassword attacker:fakepassword (root) $ mount --bind fake_password password $ cat password attacker:fakepassword
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.
Sat, 12 Nov 2005
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?
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...
Copyright © 2000-2014 Dean Wilson :: RSS Feed