|
After reading Kees Leune‘s guide to setting up a CA here, I thought it’d be handy to script a lot of the legwork involved. The end result after a day or two’s hacking about is ca-mgmt. Bug reports, feature requests, etc. are more than welcome to the usual address, or to the Github Issues page. A recent number of attempted break-ins to a few machines I manage has had me thinking again about the overall security of the machines, and how to get a better handle on what’s going on. This isn’t something new – anyone managing internet-facing systems ought to be aware of the dangers, and how to mitigate them. As with many things related to open source, there are a plethora of tools out there aimed at providing alerting based on network activity. I’d wager that many people have heard of Snort, and what it does. For those who aren’t familiar with it, it’s an open source intrusion detection system (IDS)/intrusion prevention system (IPS). In a normal configuration, Snort monitors traffic and alerts based on predefined rules for such things as port scans and maliciously-crafted HTTP requests. It’s an extremely powerful tool that is also highly configurable, and with an excellent community that provide custom rules for a wide variety of situations. But alerting is one thing – being able to make sense of those alerts is something else. → Continue reading ‘A Prelude to better things – Open Source and IDS’…IPv6 is nothing new – it was finally standardised back in 1998 in RFC 2460, and virtually all operating systems have supported it now for at least 5 years, so most people are in a position to give it a try. If you’re one of the lucky ones, your ISP might provide native IPv6 connectivity (like AAISP), but for most of us, the main way to get connected to the rest of the IPv6 Internet is to use something we’ve already got – IPv4. And we’re going to tunnel over it. (Note: This was originally posted on my previous blog, but I’ve noticed that it’s being linked to, so I’ve reposted it here) I’m not a mathematician (or a cryptographer) so I’m happy to take this post‘s word for it about a recent attack against SHA-1 (short PDF here). The post goes into detail about changing the preferred digests on a key, and is well worth a read. The post also talks about using 2048-bit RSA keys, instead of the DSA/Elgamal default (which has a maximum size of 1024 bits). It goes into detail about how to migrate to an RSA key – if you’re going to migrate, I definitely recommend reading it. However, I thought it would be nice to write a (very) quick guide on generating RSA private keys with GnuPG, as there are a few extra steps involved – but nothing complicated! Historically, if you wanted to use Active Directory to authenticate users on a UNIX box, you were pretty much limited to using LDAP. This works fine for some people, but it’s not particularly elegant – especially if you’re having to create users home directories all the time, which negates some of the point of centralising authentication to begin with. I’m from a UNIX (mostly Linux) background, so I’m more at home using UNIX-alike platforms. That said, there’s a few things that Microsoft do that are particularly useful, and in my opinion AD is one of them (quiet at the back, there). Handily, there’s a project that can marry the two, and it goes by the name of Likewise. → Continue reading ‘Authenticating Active Directory users on Linux with Likewise Open’… One thing that’s always bugged me about IPTables is the lack of a way to use groups when writing rules, which can complicate things if you’ve got a potentially large rulebase. One way round this is to use something like fwbuilder, which gives you a graphical interface not unlike Checkpoint‘s SmartDashboard GUI for their Firewall-1 devices. The downside to this, though, is that the resulting IPTables ruleset is far from legible – which, to be fair, isn’t the goal of fwbuilder – and this makes hacking about with the rules nearly impossible. So what options are there? One way is to repeat the same rule for different sources or destinations, but this can quickly get messy, especially if there’s multiple ports involved. If there was a way we could group things together and keep them tidy, maintaining the rulebase would be a lot easier. This is where MARK comes in. I’m using OpenSC at the moment so that I can repurpose an otherwise unused Aladdin eToken to hold SSH keys. I could go through the process involved in setting up the token, but as this chap has already done a thorough job, I won’t go into detail. Unfortunately, the openssh-client package from Debian (and Ubuntu) doesn’t enable OpenSC support. It’s trivial to rebuild the package with OpenSC support, but for those who don’t want to or can’t for some reason, I’ve put my rebuilt, OpenSC-enabled packages here. Once installed, if your token is set up correctly, you should be able to get your SSH public key from the card with:- ssh-keygen -D <card> …which should give you something like:- ssh-rsa AAAA .. .. .. t8/Q== 1024 65537 14233 .. .. .. 70941 You can then add your private key to a running SSH agent with:- ssh-add -s <card> Pop in your PIN, and ssh should function as if you were using a normally-generated key. |
 
|
Wednesday, 21st of March 2012 at 12:39:41 AM