Archive for September, 2009

Detecting encrypted traffic with net-entropy, part two

Posted in Crazy Plans, net-entropy, NSM on 24 September, 2009 by Alec Waters

Back here I described my setup of a modified version of net-entropy, which I was going to use in my quest to detect encrypted traffic. Well, it’s been running for a week or so now, and I’ve got some results.

  • Did it detect encrypted traffic? Yes!
  • Did it detect stuff that wasn’t encrypted? Yes!
  • Did it fail to detect traffic that definitely was encrypted? Yes!
  • Was the experiment a total failure and a complete waste of time? No! Far from it, in fact.

The theory I was testing was that traffic with sufficient entropy might be encrypted, since high entropy is a property of decent encryption algorithms. net-entropy was set to trigger an alert if it saw any connections whose entropy crossed an arbitrarily chosen threshold of 7.9 (8.0 is the maximum), and protocols that were expected to be encrypted (HTTPS, etc.) were filtered out.

Here’s a summary of what I’ve found so far:

  • Encrypted traffic that crossed the 7.9 threshold included Windows Remote Desktop (RDP), Skype (both calls and signalling traffic), SSH-2, and Google Talk.
  • Unencrypted traffic that crossed the threshold was mainly RTMP (streaming Flash audio/video), and possibly Spotify (I don’t know for sure if Spotify uses encryption or not, but high entropy was observed both on the inbound media from port 4070 and the outbound media on random ports). Media protocols like this are usually highly compressed – high entropy is a side effect of compression as well as encryption.
  • Encrypted traffic that was not detected included SSH-1 (1.5, to be exact). SSH-2 was detected as one would hope, provided that the session was long enough.

Clearly my blunt approach of a single threshold isn’t the most effective one, as we have both false positives and false negatives. But after applying some visualisations to my results, an intriguing possibility presents itself.

net-entropy was installed in this instance on a Sguil box mainly so that it was in a position where it could see a large volume of real-world traffic. A happy side effect of this is that it’s quite simple to extract the raw traffic captures that each net-entropy alert is referring to. If we’ve built net-entropy with the –enable-statistics option, we are then in a position to draw graphs of the entropy of an individual TCP stream:

  • First, use the net-entropy alert to extract the specific TCP stream. The easiest way to do this is to search for it using the Sguil client, and then export the results to Wireshark. Let’s save the capture as session.raw
  • Then we run net-entropy over it in statistics mode:
    $ net-entropy -r session.raw -s mystatsdir -F
     -b -c net-entropy.conf
  • The output of this is a .dat file whose name is made up of a timestamp and the source and dest IP addresses and ports.
  • We can now plot this file in gnuplot:
    plot 'mystatsdir/whateveritwascalled.dat'

By way of a baseline, here is a plot showing the entropy of the first 64KB of an HTTPS and an SSH-2 session. The blue line marks the 7.9 alerting threshold:

net-entropy baseline

Zooming in a little, we can see that HTTPS crossed the threshold after about 2.2KB of data, and SSH-2 took a little longer:

net-entropy zoomLet’s zoom in a little on a different area of the graph – the little “wobble” on the SSH-2 line:

net-entropy ssh-2What we’re looking at here is the part of the conversation where the various parameters of the SSH-2 session are being exchanged (key exchange protocol, encryption/hashing algorithms, etc). These are passed as cleartext, hence the low entropy at this point.

It’s an interesting little pattern, though. Let’s overlay some more SSH sessions onto the one above and see what they look like:

net-entropy sshThere are three sessions illustrated here:

  • The blue line is an SSH-2 session, which in the context of this experiment is a “true positive” since it was encrypted and it did cross the 7.9 threshold
  • The red line is another SSH-2 session which was so short in duration it didn’t manage to make it above 7.9. This is a “false negative” because we’ve missed something that definitely was encrypted.
  • The green line is an SSH-1 session. At no point during this session’s life did it cross the 7.9 threshold – another false negative.

As far as detecting encrypted traffic goes, this clearly isn’t as useful as I’d have hoped. But look at the red and blue lines – look how tightly they follow one another:

net-entropy ssh zoom

This brings us to the intriguing possibility I alluded to earlier – using entropy analysis not for the detection of encrypted traffic, but for the classification of traffic.

What if the entropy of certain types of traffic is reasonably consistent? What if the patterns above represent “fingerprints” for SSH-1 and SSH-2 traffic? If we could match traffic against a library of fingerprints, we’d have a port-independent classifier of sorts.

I’ve not had time yet to analyse sample sets large enough to be anywhere approaching conclusive, but let’s look at some other kinds of traffic:

The following graph shows four RTMP sessions:

net-entropy rtmpWhilst RTMP isn’t encrypted, all four sessions have a similar visual fingerprint.

Now let’s look at nine RDP sessions (Windows Remote Desktop):

net-entropy rdpThe most obvious outlier here is the black line – this was an RDP session to a server whose encryption level was set to “Low”. If we zoom in a bit, we’ll see another outlier:

net-entropy rdp zoomThe orange line is significantly different to the others. This particular session sent the string “Cookie: mstshash=machinename” in the first data segment sent from the client to the server – the other sessions had mostly zeroes instead, hence the lower entropy at this point. Since this is the very first data segment in the session, we could possibly infer that we’re looking at different client software used to make the connection. Indeed, if we look at RDP sessions from rdesktop (rather than the Windows client), the entropy looks different still:

net-entropy rdp rdesktopThe entropy is low, relative to the Windows client, and there’s a slightly different signature at the start of the connection:

net-entropy rdp rdesktop zoomOne might be tempted to think that one could look at graphs like these and infer something about both the server (encryption level in use) and the client (type of software used).

OK. Enough graphs. Summary time.

Detecting encrypted traffic with a straightforward entropy threshold doesn’t seem to be useful. However, we may be able to use entropy analysis as a means to classify traffic in a port-independent manner, but I’ve analysed nowhere near enough traffic to assess whether this could be a viable technique or not (there are bound to be loads of outlying cases that don’t fit the profile). And even if it is a viable technique, are the bases already covered by other port-independent classifiers (l7filter, et al)? That said, I’m not the first person to explore various visualisations of encrypted traffic, so someone somewhere considers the broad concept useful.

Comments welcome!

Alec Waters is responsible for all things security at Dataline Software, and can be emailed at alec.waters(at)

Detecting encrypted traffic with net-entropy, part one

Posted in Crazy Plans, net-entropy, NSM on 17 September, 2009 by Alec Waters

I’ve been pondering the possibility of detecting encrypted traffic crossing a network, and I think I’m getting somewhere (not necessarily closer to the goal, but somewhere nonetheless!). My initial thoughts were to put some kind of frequency analysis to the task, and whilst I was researching this I came across net-entropy.

net-entropy is a clever tool that can learn the expected cumulative packet entropy (“randomness”) for a given protocol, and raise alerts if an observed connection falls out of bounds (there’s a very detailed writeup here). The theory is that if someone is attacking a flaw in some cryptographic software (a SSH server, for example), the observed entropy of the connection will decrease unexpectedly once the attack has been executed and the attacker is delivering shellcode or whatever (figures two and three here illustrate the principle).

net-entropy was designed to focus on its list of pre-learned protocols, each of which is described in a protospec file. Here is the file for SSH:

Port: 22
Direction: both
Cumulative: yes
RangeUnit: bytes
# Range: start    end      min_ent        max_ent
Range:   1        63       0              4.38105154
Range:   64       127      4.22877741     4.64838314
Range:   128      255      4.95194340     5.02499151
Range:   256      511      4.86894369     7.28671360
Range:   512      1023     4.86310673     7.59574795
Range:   1024     1535     4.94409609     7.74570751
Range:   1536     2047     5.77497149     7.81915951
Range:   2048     3071     6.44314718     7.85139179
Range:   3072     4095     7.17234325     7.92034960
Range:   4096     8191     7.46498394     7.96606302
Range:   8192     65536    7.82608652     7.99687433

Each range is defined in terms of start byte and end byte, and minimum and maximum entropy. For example, for the first 63 bytes, the entropy is expected to be between 0 and 4.38105154 – an alert is raised if the entropy at this point is either too high or too low.

We could have a go at detecting encrypted traffic (rather than profiling its properties) with a very simple protospec file. What I’m interested in seeing is anything with an observed entropy that’s greater than some defined threshold – this will be my indicator that what we’re looking at could possibly be encrypted. So, we could have a protospec file that looks like this:

Port: "whatever"
Direction: both
Cumulative: yes
RangeUnit: bytes
# Range: start    end      min_ent        max_ent
Range:   1        65536    0              7.9

This file will cause net-entropy to raise an alert if the entropy for a connection on port “whatever” exceeds my arbitrarily chosen threshold of 7.9 in the first 64KB of its life; the problem here is that I’d have to write thousands of these files to cover the complete set of all TCP ports. I spoke to net-entropy’s author, Julien Olivain, about this and he very kindly implemented me an “all” feature, whereby a single protospec file can be applied to the complete range of TCP ports (updated source code is available here).

Now we can start to experiment! net-entropy will accept the usual variety of capture filter, so we can use this to exclude:

  • The protocols that we expect to be encrypted (SSH, HTTPS, etc.)
  • High volume protocols that are scrutinised by other means (SMTP, HTTP, etc.)
  • Non-TCP protocols (net-entropy only works for TCP at the moment)

So, our net-entropy.conf file looks like this:

Interface: eth1
RuntimeUser: nobody
MemoryLimit: 131072
MaxTrackSize: 65536
PcapFilter: tcp and not port 80 and not port 25 and not port 22 and
            not port 443 and not port 993 and not port 995
ProtoSpec: /usr/local/share/net-entropy/protospec/proto-tcp-all.nes

I installed the software on a Sguil box and fired it up; pretty soon, things like this were popping up in /var/log/messages:

Sep 17 11:15:03 morpheus net-entropy[2689]: RISING ALARM on -> offset=2406 packets=7 entropy=7.90993547 range=0 (1 65536 0.000000 7.900000)

Woohoo! Data! Now all we have to do is work out if it’s useful or not. I’m not one for leaving logs lying idly on the server that generated them so I send the messages to a remote syslog collector, in this case a Cisco CS-MARS. The MARS certainly has its flaws and niggles, but it does let you write custom parsers for devices it doesn’t know about. Once the MARS has been educated in the ways of net-entropy, you can use its querying mechanism to start exploring the data.

I’ve written the required custom parsers, and exported them as a Device Support Package that you can import into your own MARS, if you happen to have one and want to play along (download it here). The net result is that I can do stuff like:

  • Ask about the kinds of messages from net-entropy:

    Event Types

    Event Types

  • See the details of sessions seen:



  • Drill down onto a single session:
    A single session

    A single session

    Note that the MARS has noticed that there are two events talking about the same session (based on the IP addresses and ports), and has been able to correlate them together into a single session.

  • Get the raw messages as raised by net-entropy:

    Raw messages from net-entropy

    Raw messages from net-entropy

So, here’s where we’re at:

  • net-entropy has been enhanced to support a protospec file that applies to all ports
  • This allows us to do “generic” entropy detection
  • Events from net-entropy are being exported to my MARS, from which I can run queries and reports

Next steps:

  • Work out if the things that net-entropy is alarming on are actually encrypted, or if the reason for their high entropy is something else (effective compression, for example). If I’m not reliably detecting encryption, then I can either tweak my entropy threshold, or give up the whole idea 😉
  • If the technique is really yielding useful results, perhaps write an agent for Sguil so that net-entropy’s alerts appear in the client for easy drill-down onto the session transcripts (there’s an agent available for modsec, so it could be feasible to try this)
  • In the far future, how about a mod to the Sguil client that lets you right-click and say “Graph session entropy”? This would extract the relevant session from the full-content capture (just like the Wireshark option does at present), run it through net-entropy in statistics mode, and use gnuplot to visualise the result.

This post is most definitely filed under “Crazy Plans”. Comments on my insanity are welcome.

Alec Waters is responsible for all things security at Dataline Software, and can be emailed at alec.waters(at)

Helping, trusting, sharing – at WARP speed

Posted in General Security, WARP on 10 September, 2009 by Alec Waters

It’s quite obvious that with every passing day the world is becoming more and more dependant on IT and the Internet, to the extent that many governments rightly include these when considering their “Critical National Infrastructure”. Internet-borne threats can clearly do much damage to all kinds of businesses, large or small.

But what can a small business, for example, do to help protect themselves? They’re too busy being grocers or mechanics or gardeners to learn about IT security. They don’t have the budget to hire someone to take care of this. A lot of the time they aren’t even aware of what they need to be aware of, because they’re grocers, mechanics and gardeners, not IT security geeks. IT is often pivotal to the day to day operation of their business, and a security incident could prove catastrophic.

Wouldn’t it be great if a small business had access to somewhere they could go to get relevant advice and share information. A community where:

  • Everyone has something in common; perhaps profession (e.g., lawyers, local government, etc.), or membership of a local traders’ association, etc. Ideally, at least one of the members should have some IT security expertise; this person need not be drawn from the membership demographic.
  • Members can get a single tailored feed of security information that is relevant to their specific needs (someone who uses Windows XP and Office 2007 has no need to know about flaws in Debian’s random number generator, for example, nor do they want to have to draw this information from multiple sources).
  • Members can ask for advice from each other. Initially, most of this would come from the resident IT expert, but as the community learns they’ll start to help each other.
  • If the community is kept small and focussed, the trust between members will grow. As trust builds, people will hopefully feel able to start sharing their own experiences, both positive and negative, without worrying about any kind of bad press or reputation damage. Sharing the story of “I got hacked, here’s how I found out, and here’s what I did to prevent it from happening again” would be of great benefit to all, but people aren’t going to tell it if they don’t trust the people they’re telling it to.

I think that this sounds like a pretty reasonable concept. It isn’t my concept of course; it’s a summary of what the UK’s Centre for the Protection of National Infrastructure calls a “Warning, Advice, and Reporting Point” (WARP). Without wishing to reproduce too much of the WARP website, a WARP provides three core services:

1. Filtered Warning Service – where members receive only the security information they need, selected via an on-line tick-list;

2. Advice Brokering Service – where members can learn from other members’ initiatives and experience, possibly through a members’ bulletin board;

3. Trusted Sharing Service – where reports are anonymised so that members can learn from each other’s attacks & incidents, without fear of embarrassment or recrimination.

How is this different to the myriad of tech support websites already on offer? The intimate and closed nature of a WARP facilitates the building of trust that you just can’t get when a site’s membership is world+dog. Trust leads to a more open sharing of information, and “sharing is protecting”.

The Australian government has a similar strategy, the Trusted Information Sharing Network, and there’s even a working draft for an ISO/IEC standard (27010) for the sharing of security information. WARPs can also share information with other WARPs, not just their own members, who can be from all kinds of organisation or demographic.

I’m enthusiastic about the concept, and we’re looking into setting up a WARP for one of a number of communities that we have ties to. Recently, we attended the WARP annual forum with the aim of learning more and meeting people who could help us get the ball rolling. The morning presentations were really useful (including a great animation from the Hitachi IRT), and lunch was jolly nice too (some of the afternoon sessions appeared to be verging on being sales pitches, but I can’t comment because we unfortunately had to leave the event prematurely).

The event served as good encouragement for setting up a WARP – with a bit of luck, this won’t be the last time I mention them!

Alec Waters is responsible for all things security at Dataline Software, and can be emailed at alec.waters(at)

Blog comments vs Akismet

Posted in Misc on 2 September, 2009 by Alec Waters

WordPress uses Akismet as a defence against comment spam, and for the most part it does a good job. It is supposed to put everything deemed “spam” into a spam queue, where it can either be confirmed as such or published as a legitimate comment. At the bottom of the WordPress stats page, there’s a proud banner that says “Akismet has protected your site from nnn spam comments.”

The problem here is that sometimes nnn increases without new messages appearing in the spam queue – i.e., the comments are lost forever. If they were indeed spam I don’t care, but if they were legitimate comments I most certainly do care. I’m certainly not alone in experiencing this.

In a nutshell, if you’ve posted a comment and it’s not showed up, I’m not ignoring you – it’s just disappeared over Akismet’s event horizon, never to return. If you want to get in touch, you can always email me – alec dot waters at dataline dot co dot uk.

Alec Waters is responsible for all things security at Dataline Software, and can be emailed at alec.waters(at)

Detecting encrypted traffic with frequency analysis – Update

Posted in Crazy Plans, net-entropy, NSM, Sguil on 2 September, 2009 by Alec Waters

I recently wrote about a plan for detecting encrypted traffic, where I mentioned in the comments that I’d come across a package called net-entropy (very detailed writeup here). I’ve been in touch with Julien Olivain, one of the authors, and he’s kindly given me the sources to experiment with.

And experiment I shall – I’ll post my findings when I’ve got some!

Alec Waters is responsible for all things security at Dataline Software, and can be emailed at alec.waters(at)

Sidestepping inline URL content filters – Update

Posted in NSM on 2 September, 2009 by Alec Waters

A while ago, I bemoaned the ease with which Cisco’s inline URL filtering can be bypassed. There were two main gripes:

  • Only HTTP GETs were processed – POSTs etc were not inspected
  • You have to manually nominate the ports that the inspection will take place on (although this point can be mitigated with egress filtering)

I have since discovered a third bypass, whereby HTTPS traffic is not inspected at all, even if you manually alter the port-map settings so that port 443 is listed as plain HTTP.

I’m pleased to report that I’ve successfully raised a product enhancement request to remedy some of this (big thanks to Herbert at Cisco TAC for getting the ball rolling here!) – the inspection of POSTs and of HTTPS is on the development roadmap for a future version of IOS.

Timescales? I have no idea. Best estimate is a one-year timeframe, but better late than never!

Alec Waters is responsible for all things security at Dataline Software, and can be emailed at alec.waters(at)