It's The Muppet Show!


TextSecure - Android SMS Replacement App

, posted: 5-Mar-2014 06:00

TextSecure is a Drop-In SMS replacement app for Android.  I consider it to be very similar to Apple's iMessage, in that messages to other TextSecure users are sent over the Data Channel (referred to by TextSecure as Push) thereby bypassing your carriers SMS fees.  It also provides easy to use secure group messaging.

Unlike Apple's iMessage however, both the client and the server used are fully Open Source.  It's been written and developed by Moxie Marlinspike who is a well known and trusted security and crypto guy.

TextSecure aims to bring some privacy to your life in these days of everyone watching everything you do.  It does this by:

  • Encrypting all texts received to it's database, which by default requires a password to be set to allow access. The App can be configured to stay unlocked for a length of time, or the password requirement can be switched off entirely if you like.
  • Encrypting all texts to other TextSecure users.  Even when not using the Data/Push method, SMS and MMS to other TextSecure users are encrypted.  It's seemless, you only know the message was encrypted by the little lock icon showing on the message.
  • If available, it will use the Data/Push channel, bypassing SMS/MMS fees.  Again this is seemless, the only way you know this has happened is by the different colour of the sent/received message in the interface, again exactly like iMessage.

I really like TextSecure and it's replaced the standard SMS app on my phone, though I should note you can configure it not be your default SMS app and  use it only for secure messages.

I've shown it to a few people and they've said "This is just another WhatsApp/Viber replacement" which is true, except it's fully open source and you can trust that only you and the person you sent the message to can read it. Not also WhatsApp/FaceBook/Viber/FBI etc.

The downsides are there's no iPhone version at the moment, and there's no desktop or Tablet version.  Work is progressing on the iPhone version and Desktop version, hopefully to be released later this year.  Texts to your iPhone friends will just go through as a standard SMS.

Lastly, if you're a Cyanogenmod user, support for TextSecure's protocol was recently rolled into the SMS framework, helping to increase the mass adoption of TextSecure.

Give it a try, even if it's just because its SMS/MMS Interface is better than the stock one IMHO.

- muppet

PS: Like this post? Don't forget to follow me on Twitter.



EMET v4.0 Released - Secure your Windows System.

, posted: 18-Jun-2013 07:05

Microsoft's Enhanced Mitigation Experience Toolkit v4.0 is now available for free download.

EMET is a program that enables many advanced security features for Windows Applications, some of them similiar to the sort of features found in the Linux grsecurity patch that, those who know me, will know I am a big advocate of using.

EMET enables control of features such as:
  •       Detects attacks leveraging suspicious SSL/TLS certificates
  •       Strengthens existing mitigations and blocks known bypasses
  •       Addresses known application compatibility issues with EMET 3.0
  •       Enables an Early Warning Program for enterprise customers and for Microsoft
  •       Allows customers to test mitigations with “Audit Mode”

EMET is a great piece of software, made freely available by Microsoft, that I'm always amazed more people don't know about.  You should investigate adding it your arsenal of system protections.  You'll likely get much more benefit from it than the latest bloatware Norton 360 software.

It even supports Windows XP!

- muppet



Install Your Own Mini Google

, posted: 11-Jan-2012 09:13

This post is about a bit of software for Windows, and especially for those people who use Outlook as part of their daily routine.

One of the big problems I have with Outlook (which I use at work on a hourly basis) is the fact that its built in search really isn't that great.  It got a lot better with Outlook 2007 and the addition of Windows Search, but I still found it was still slow, reliant on iFilters and has a poor previewer.

I've been a long time user of the X1 Professional Client search program.  It's a paid product, but it's always been worth the money in my opinion, because of the amount of time and hassle it saves.  I've had many people stand at my desk and go "Wow, what version of Outlook is THAT?" as I search in seconds for an email from a couple of years ago.

I don't use folders in my Outlook.  Every emails stays in my Inbox.  This is because in X1 I can just "create" a new folder instantly by searching for all emails from, for example, Juniper.  Or all emails from "Mr Blobby".  I can save those searches as well, instantly creating the contents of what would be in that folder.

It's a lot like the power of Gmail Search, but for Outlook.  It also builds an index of your documents and allows you to preview them quickly before opening.

The main purpose of this post though is to mention X1 Pro 7, which is X1's new version that's currently in beta and thus freely available for download.  Using it you can Index not only your Outlook and Files as before, but you can also index and search Twitter, Facebook, Gmail, Yahoo and even your own IMAP servers.

If you're as much of a search nerd as me, you might like to give it a try.  It's very powerful and may help save minutes of your time every day.  As the post title suggests, it's kind of like having your own mini Google.

This isn't a paid post, btw.  I'm just a long time user and big fan of X1.

Like this post? You should follow me on Twitter.



Linux System Hardening

, posted: 14-Oct-2011 20:30


Anyone who knows me fairly well knows that I'm a big Linux fan. I'm not so crazy as to think Linux is the answer for anything (my laptop happily runs XP), but I'm pretty sure as a server, it can't be beat.

In this article I'm going to talk about some of the methods you can use to harden a running linux system in a server environment. Some of the methods are also applicable to a desktop system, but given the nature where people usually want to tinker and fiddle, hardening isn't usually a great idea, as you're often having to edit rules to allow things. You get to the point where an “allow all” would be easier, defeating the purpose of the rules in the first place.
This article is written as a guide to some of the methods available to you to protect your systems.  It doesn't attempt to explain detailed implementation steps, there's many guides and howto's out there if you're after these things. I'm happy to help if you ask as well.

Finally, before I start it's important to remember that even if you add every single thing I talk about here to your system, it's a fallacy to sit back and think “Now I'm unhackable!”. If your sensitive data is stored in a web directory you leave exposed to world, no amount of fancy pants rules/filtering and memory hardening is going to help you. It always pays to monitor your logs, check your system and sometimes approach your own system as if you're an attacker without the passwords and see how far you can get.

Starting from Scratch
There's aready a number of Linux distributions that are built from the ground up with hardening as part of the tool chain. Examples include Openwall and Hardened Gentoo.
If you're starting from scratch, I'd suggest looking at one of those systems.
This article is written to give some pointers and ideas to people who already have a working system but would like to take some steps to strengthen it.

SpamHaus Drop List
The first and most simple way to help protect your machine against automated attacks is to add the SpamHaus DROP list to your iptables rules. The drop list is a list of IP addresses that haven't officially been allocated by IP registers yet.  It means if you see traffic coming from them, you can be pretty sure it's traffic from a spammer.  There's a number of scripts out there that make applying DROP a simple step, this is the one that I currently use.

Active Response - Fail2Ban
The next way to protect your system against attack is to monitor the system logs and act when you see suspicious activity. The tool I use for this job is called fail2ban and will, after seeing a custom number of errors/denies appear in a log file, take a certain action. That action could be to email you, to send a tweet, or to add an iptables rule that filters the IP triggering the log from access the machine.

I have fail2ban setup so that when it sees more than 3 failed SSH attempts from the same IP address, it adds that IP Address to an iptables rule which drops all traffic to/from that address. I also have it setup to blacklist people trying to spam me (if they're listed in a Real-Time Blackhole List they get blacklisted). Addresses that tries to brute force the IMAP server are added to IPTables as are addresses that triggers the Web Server firewall rules (more on this in a minute)

By adding a simple system such as fail2ban, you protect your server against the automated SSH/IMAP scans that are common, as well as anyone else without much clue that tries to bruteforce your password. This attack won't stop a resourceful attacker who has an army of zombies with many thousands of IP addresses from trying though.

Apache Webserver with PHP

Suhosin PHP Patch + Module
The next step I take is to harden the webserver. I, like many people, use the Apache server with a lot of PHP Scripts that I just have to trust are security-hole free. Sadly I don't really have a strong enough understanding to read every file and verify it's secure. Given that I run some fairly commonly exploited software (phpMyAdmin being the biggest) I feel it's important to make it as harder to exploit my server than normal, in the hope of thwarting a dumb script kiddie.
The two tools I use for this are: The Suhosin PHP patch and mod_security. The Suhosin PHP patch is the easiest for me, as Debian user the PHP binary itself is already patched with the “simple” version. Suhosin is best descirbed by this quote from their website:

Suhosin comes in two independent parts, that can be used separately or in combination. The first part is a small patch against the PHP core, that implements a few low-level protections against bufferoverflows or format string vulnerabilities and the second part is a powerful PHP extension that implements all the other protections."

It's also quite simple, just a single Debian command to add the Sushion PHP module as well, thus completing the protection offered by Suhosin.
I then go through and tweak the various options it offers, such as enabling session and cookie encryption. You can configure Sushion so that cookies sent via the standard PHP Method (note: Not all PHP apps use this!) are valid only if they're used from the /24, /16 or /8 netblock. Which means that if someone in Mexico steals your cookie, they can't use it from their IP Address.

Sushion is easy to install, simple to configure and hasn't in my experience broken any of the PHP Applications I use. I consider it a fairly low-key but effective protection.

Apache Module - mod_security

mod_security is the next level of protection I add to a Apache webserver. mod_security by itself does nothing, it's not until you give it a list of rules that it becomes useful. Thankfully it comes with what's known as the Core Ruleset, a set of rules that apply broadly (but not perfectly) to most webapps. Using this ruleset, mod_security can detect and act upon a very wide range of commonly used web exploits. Things such as SQL Injection, Javascript Injection etc can all be protected against. It will trigger when it sees the webserver echoing PHP instead of text, things like that. mod_security is a very powerful Apache module but it comes at a cost.
The first is that the more rules you throw at it, the slower it is to respond to each web request. The second cost is that the Core Ruleset is not easy to configure. It's best to install it in a monitoring only mode and then use your website(s) as you and your users normally would. Then you can examine the logs that mod_security generates, then modify the rules you have to protect against the false positives it has no doubt detected. It's a bit of trial and error for a while until you get the hang of the way the rules work, how they can be modified and tweaked.

Once you've got mod_security's rules to a level you're happy with, you can move mod_security into active mode. This means it will drop/block/deny requests (you can configure which) that match one of it's rules. I use this in conjuction with fail2ban above. If an IP Address triggers a rule a few too many times (and spambots, zombie and exploit scanners do) they too are added to the iptables rules. This effectively stops most people scanning my websites and attempting 100+ different exploits on it.

Another feature of mod_security is the ability to change the string Apache uses to announce itself.  I change mine to not say Apache. This stops a number of the scanners that have in the past scanned for the Apache string before attempting an exploit.

Hardening the Kernel Itself - grsecurity
The final level of protection is the most complex, but one you get the most benefit from. Anyone that knows me well knows I'm always blabbing on about it, so apologies in advance if you're one of those people. Maybe stop reading now. The final system hardening method I use is the grsecurity patch for the Linux kernel. Grsecurity adds many hardening features to the kernel all which help to prevent exploits. The features it add are so numerous that really only reading the features page will do it justice.
I'll simplify and list a few here:

  • Memory Protection - Enforces non-executable pages
  • Kernel Stack Protection
  • Proper Address Space Randomization
  • Prevents various kernel structures
  • Role Based Access Control - Very powerful (A bit like SELinux)

The amazing thing is, adding all these features does not under most circumstances make the system any less usable. In it's default state (not using the RBAC system) you don't really notice that it's running. It will however catch many different memory and buffer overflows that the standard kernel would happily let happen.

The problem with grsecurity is that it's a patch you have to apply to the vanilla Linux kernel. This means you're in the territory of compiling your own Linux kernel, though there are some sites out there that offer precompiled gresecurity kernels for download.
For this reason it's probably out of the reach of many people, which is a shame. It'd be great if oneday the features that grsecurity are added into the kernel, but I don't think that'll happen anytime soon. A few features have already crept in on a case by case basis, such as address space randomisation.

The second part of the grsecurity is the Role Based Access Control. What this does is add another level of security to the system. With proper rule tuning, you effectively render the root login just as powerful as a normal user, that is not very!
Root won't be able to kill important processes, won't be allowed to replace important system binaries etc. The only way to do this is to authenticate to the RBAC system in an admin role, when full system privledges are once again granted. This makes an attackers job that much harder. They might fight for a couple of hours to get a root shell on your system, only to find that root shell is worthless to them.

grsecurity - a couple of stories
've used grsecurity for many years and there's been once it saved me when a webapp was exploited.  A bad person uploaded a binary that attempted a buffer overflow to root.  However grsecurity realized it was a buffer overflow, crashed the app and logged it.  It's also stopped some of the other root exploits that have been released, when I tested them on a grsecurity kernel, they were caught.  The system was unstable and crashed, but I'd much rather have a crashing system than a still working one + an unknown attacker with root.
If you're sharing your system with other people, another powerful feature is the ability to stop users running their own binaries.  They can only run the ones in /usr/bin, /bin etc.  Not their own ones in /home/user.  This shuts down another attack vector.

Summary
I hope this article gets you interested in a few of the measures you can take to help secure your system.    There's a lot of nasty people out there and anything you can do to make your system that bit more secure is a good thing.  Hopefully someone will realise your server isn't worth the effort and move onto someone elses!
If you have any questions or would like to know anything more, please post a comment below.  Thanks!

- muppet

Like this post? Don't forget to follow me on Twitter!

Permalink to Linux System Hardening | Add a comment (4 comments) | Main Index


Traceroute

, posted: 12-Jun-2011 21:25

I got a question in my email this morning asking some interesting questions about traceroute.  I'll reproduce the email along with my response here, in the hope that others might also find it useful.

> I found many times in traceroutes, I see 1st hop latency 200ms, next
> 150ms and by final destination it goes to 100 or sometimes 200 (less
> then or equal to 1st hop).
>
> I don't understand what it means my 200ms latency on 1st hop itself?
> Also, in most of such traceroutes I found that if we see latency on
> destination that's actually correct and logical but I just don't
> understand middle route at all.

My Reply:


There's a couple of reasons you might be seeing this. First of all, it's important to fully understand how traceroute works.

When you run traceroute, you're actually sending out packets with a small time-to-live. The first packet goes out with a TTL of 1 so when the next hop gets it, the TTL is decremented and the router sends you
back a "Time To Live Exceeded". The IP address of the host that sent back the TTL-exceeded is then recorded and shown to you. Another packet is sent out to the same destination, but with the TTL set to 2. This time the next hop gets it, reduces the TTL by 1 and sends it on. Now when the second hop gets it, the TTL is reduced to 0 and a TTL-exceeded is sent back from the 2nd hop.

That's pretty basic and easy to understand, right? That's how traceroute works.

What people don't realise is that the path that the TTL-exceeded packet comes back to you _might be very different_ than the path it took to get there.

Let's took at a pretend example:

Our source address is 1.2.3.4 and we run a trace:

traceroute to 192.168.5.5 (192.168.5.5), 30 hops max, 60 byte packets
1 192.168.0.1 (192.168.0.1) 4.977 ms 5.264 ms 5.625 ms
2 192.168.1.2 (192.168.1.2) 600.603 ms 600.238 ms 600.435 ms
3 192.168.5.5 (192.168.5.5) 8.977 ms 8.264 ms 8.625 ms

That 2nd hop looks strange? But why?
Let's pretend we have access to each of the 3 hops there and can trace back to our source of 1.2.3.4

From hop 1:

traceroute to 1.2.3.4 (1.2.3.4), 30 hops max, 60 byte packets
1 1.2.3.4 (1.2.3.4) 4.977 ms 5.264 ms 5.625 ms

Well that was quick, one hop!

From hop 2:

traceroute to 1.2.3.4 (1.2.3.4), 30 hops max, 60 byte packets
1 10.2.3.4 (10.2.3.1) 4.977 ms 5.264 ms 5.625 ms
2 10.8.3.4 (10.8.3.1) 6.894 ms 6.234 ms 6.789 ms
3 8.8.8.8 (8.8.8.8) 600.654ms 600.234ms 600.723ms
4 8.6.3.4 (8.6.3.4) 602.845ms 601.932ms 601.945ms
5 8.4.3.5 (8.4.3.5) 600.654ms 600.234ms 600.723ms
6 1.2.3.4 (1.2.3.4) 602.874ms 601.456ms 601.456ms

Woah! What happened?

The return path that 192.168.1.2 has is very a very slow, long path!
The packet still gets there, but it takes ages because it's routing over let's pretend it's a satellite link.

But then the return path from 192.168.5.5 looks like:

traceroute to 1.2.3.4 (1.2.3.4), 30 hops max, 60 byte packets
1 192.168.5.9 (192.168.5.9) 4.977 ms 5.264 ms 5.625 ms
2 192.168.100.100 (192.168.100.100) 4.977 ms 5.264 ms 5.625 ms
3 1.2.3.4 (1.2.3.4) 6.678ms 601.331ms 601.824ms

Nice and fast again. It has it's own fast good paths back to 1.2.3.4 that 192.168.1.2 doesn't have.

Now that's a _very_ extreme example (it pretends each different provider has only one hop) and in the real world you probably won't see things that extreme.

However what I'm trying to point out is that traceroute _only_ ever shows you the outwards path between you and your destination. It doesn't show you (and you can't see) the return path that the TTL-Exceeded packets travel back on. Usually it's the same path. But in an asymmetrical routing situation (what I've  shown above) that's not the case.

The OTHER thing that can cause high TTL's can be a router under load. When most ISP routers forward packets these days, they do so in hardware. However if they have to examine the packet and process it, it has to be handed out of the hardware forwarding plane and be given to the CPU to software process. Now the CPU might be very busy, so it might take it a few tens or even hundreds of milliseconds to process it via the CPU. i.e. longer that it'd have taken it to hardware switch it (a few ms at most) That means that some hops might show a high latency spike but then the rest won't, because in most cases the router is just hardware switching the traceroute packet, except for the time when it has to generate the TTL exceeded packet itself.

Hope that helps explain it. Traceroute is a good tool, but it only shows one side of the packet path, which might be only half the story if there's asymmetrical routing going on.

Be sure to follow me on Twitter.

Permalink to Traceroute | Add a comment (2 comments) | Main Index


muppet's profile

TiM 
New Zealand


My name's Tim and I'm a Network Engineer! Well these days I'm actually a Network Architect. I'm one of those weird people that really love their job. I work with a great bunch of people in an interesting industry that's always changing. Sometimes slower than I'd like.

In my spare time I work on the LiCe Script for the EPIC5 IRC Client. Try it out, it's like Irssi but better.