Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Already on GitHub? Sign in to your account

Events without packet data #17

Closed
yunzheng opened this Issue Jan 19, 2012 · 20 comments

Comments

Projects
None yet
4 participants

I have some Snort instances where the unified2 log files contain some events without any Packet information.
When the barnyard2 database plugin processes these events it will insert the event, but will not insert any ip information.

This will result in an alert entry without any source or destination address. This is for example the SQL queries for the event:

81 Query     BEGIN
81 Query     SELECT sig_id   FROM signature  WHERE sig_name = 'ET WEB_SERVER Script tag in URI, Possible Cross Site Scripting Attempt '    AND sig_rev = 6    AND sig_sid = 2009714    AND sig_gid = 1
81 Query     INSERT INTO event (sid,cid,signature,timestamp) VALUES (86, 62261, 31658, '2012-01-18 15:02:20')
81 Query     COMMIT

Notice that it misses an insert into tcphdr.

This is the event outputted with u2spewfoo:

(Event)
        sensor id: 0    event id: 33946 event second: 1326895340        event microsecond: 303126
        sig id: 2009714 gen id: 1       revision: 6      classification: 28
        priority: 3     ip source: x.x.x.x ip destination: 10.x.x.x
        src port: 62400 dest port: 80   protocol: 6     impact_flag: 0  blocked: 0

Notice that it does not have a Packet but does contain src/dst ip and port information.

Is this the intended behavior of barnyard2?

Collaborator

binf commented Jan 19, 2012

Try to use the updated db plugin and see if you can reproduce the issue.

https://github.com/binf/barnyard2/tree/DatabaseOutputUpdate

I have not tried using the new plugin, but when I look at the new code, the database plugin will now skip the alert if there is no packet data.

So the new behavior is to not insert the event if there is no Packet data. That's basically what I wanted to know.

I still wonder why Snort misses some packet data though, it means that barnyard2 will always discard these events.

Maybe it's an idea to extract the ip information from the event when there is no Packet data and use that to build a minimal tcphdr entry so it will still be possible to correlate the event with pcap data.

Collaborator

binf commented Jan 20, 2012

Humm what type of unified2 config do you use?

1: output alert_unified2: xxxxxx
2: output log_unified2: xxxxxxx
3: output unified2: xxxxxx

You should be using unified2 (option 3), where in the file is your event happening? at the start of the unified2 file ? at the end of the unified2 file ?

IUnless your using option 1 or 2 i would be curious to see your unified2 file for testing.

yup using:

output unified2: filename snort.u2, limit 128

The event is happening somewhere in the middle I think

Any ideas on how to anonymize the unified2 log file?

Owner

firnsy commented Jan 21, 2012

It's possible the IP's are being fetched from the packet instead of the event header. I'll take a look and get back to you. It doesn't sound like an intended feature.

yunzheng reply@reply.github.com wrote:

I have some Snort instances where the unified2 log files contain some events without any Packet information.
When the barnyard2 database plugin processes these events it will insert the event, but will not insert any ip information.

This will result in an alert entry without any source or destination address. This is for example the SQL queries for the event:

81 Query     BEGIN
81 Query     SELECT sig_id   FROM signature  WHERE sig_name = 'ET WEB_SERVER Script tag in URI, Possible Cross Site Scripting Attempt '    AND sig_rev = 6    AND sig_sid = 2009714    AND sig_gid = 1
81 Query     INSERT INTO event (sid,cid,signature,timestamp) VALUES (86, 62261, 31658, '2012-01-18 15:02:20')
81 Query     COMMIT

Notice that it misses an insert into tcphdr.

This is the event outputted with u2spewfoo:

(Event)
       sensor id: 0    event id: 33946 event second: 1326895340        event microsecond: 303126
       sig id: 2009714 gen id: 1       revision: 6      classification: 28
       priority: 3     ip source: x.x.x.x ip destination: 10.x.x.x
       src port: 62400 dest port: 80   protocol: 6     impact_flag: 0  blocked: 0

Notice that it does not have a Packet but does contain src/dst ip and port information.

Is this the intended behavior of barnyard2?


Reply to this email directly or view it on GitHub:
#17

Collaborator

binf commented Jan 21, 2012

Event header will have ip in them, if i was you i would still use the new db output plugin for obvious reasons.

Its hard to belive that if you use unified2, thats the event do not have packet. What version of snort do you use?

As of unified2 anonymiser you can try my alpha: https://github.com/binf/u2_anon using file to file (dir to dir) is not finished yet and you will have to use all switch for anon since there is still some change being worked on and this was just commited yesturday.

If you are able to anon it send it to me beenph@gmail.com, still i would like to have more info on your snort version & al.

Owner

firnsy commented Jan 23, 2012

@binf
I agree the event header will have the IP in them, however the legacy DB as well as your optimisations of the legacy DB still attempt to extract the IP from the packet instead of the event header.

https://github.com/binf/barnyard2/blob/DatabaseOutputUpdate/src/output-plugins/spo_database.c#L1926
https://github.com/binf/barnyard2/blob/DatabaseOutputUpdate/src/output-plugins/spo_database.c#L1950

If by chance that an event record is not accompanied by a packet record, then the IP should be able to be extracted from the event header.

Collaborator

binf commented Jan 23, 2012

As far as i know firnsy 1926 and 1950 insert into table IPhdr and if there is no IPhdr, there will not be any insertion done.

The model is made so its the only place where IPhdr are inserted.

yunzheng sent me a anonimized unified2 file, i will look into it later tonight.

Owner

firnsy commented Jan 24, 2012

@binf

I have not looked at how, front ends are utilising the data inside the IP header information but the regardless if the packet is presented or not there is some information that is of use to the frontend.

Perhaps, this is more off topic to the original problem and more appropriate with the new schema we establish. I guess all I'm saying is that the event record has information that could be used to populate fields from a missing packet record. But, I'm sure you know this so I'll leave it there :)

Owner

firnsy commented Jan 30, 2012

@binf - Have we had a reponse from Sourcefire on this?

Is it a unified2 issue or a barnyard2 issue?

Collaborator

binf commented Jan 30, 2012

Well Russ told me its on the top of his queue and he will probably get back to me.

Collaborator

binf commented Feb 21, 2012

Kind of both, the new spooler code will handle such exception, but
there is some issue with snort which prevent me to actually test some
things russ
told me he was looking into it about 1 week ago

On Mon, Jan 30, 2012 at 6:31 PM, firnsy
reply@reply.github.com
wrote:

@binf - Have we had a reponse from Sourcefire on this?

Is it a unified2 issue or a barnyard2 issue?


Reply to this email directly or view it on GitHub:
#17 (comment)

It looks like this is triggered on events on the same packet. For example signature A triggers on Packet X, but also signature B triggers on that same packet.

What happens is that Packet X is logged on the first event with signature A, but then the second event caused by signature B is also logged but without the Packet data.

Maybe the unified2 log has a "reference" field to the previous packet data?

Collaborator

binf commented Mar 22, 2012

That is exacly what i noted to Russ Combs, i will ring him back, but no there is not reference, the packet should be there.

Hello, I'm running into that same issue (though with the "sguil" plugin). I understand there seems to be both a snort issue (missing pkt entry) and barnyard issue (doesn't use the IP address and other information from the event entry).

I've also come across http://thread.gmane.org/gmane.comp.security.ids.snort.general/35412/focus=35428
Has anybody got any news on it?

Collaborator

binf commented Apr 11, 2012

On Tue, Apr 10, 2012 at 12:22 PM, Stephane Chazelas
reply@reply.github.com
wrote:

Hello, I'm running into that same issue (though with the "sguil" plugin). I understand there seems to be both a snort issue (missing pkt entry) and barnyard issue (doesn't use the IP address and other information from the event entry).

I've also come across http://thread.gmane.org/gmane.comp.security.ids.snort.general/35412/focus=35428
Has anybody got any news on it?

Well from what i have heard, the newest version of snort fix one part
of the issue, but it is a snort->unified2 issue not a by2 issue
since the way the unified2 is formated it was processed fine with snort.

What version of snort are you running and do you have SID where this
is happening.

Can you send me a unified2 file that has the issue that is run thru u2anon?

Thanks.
-elz


Reply to this email directly or view it on GitHub:
#17 (comment)

That's 2.9.2.1 from securityonion. I've been seeing this with older versions as well. Only now am I looking into it.

I couldn't find u2anon, but here is the output of the perl script below that reports the events without packets and tries to correlate those with events that have packets at the exact same microsecond.

For instance, event 3 below (5th record) had no packet. Nor did event 2156, but event 2155 had a packet at the same microsecond logged against it. So it seems it's not only about packets triggering several alerts.

5, sensor_id=0, event_id=3, tv_sec=2012-04-06_16:43:41, tv_usec=527525, sig_id=2012647, sig_gen=1, sig_rev=3, class=33, pri=1, sip=10.10.10.244, dip=199.47.219.151, sp=55729, dp=80, protocol=6, pkt_action=0
6, sensor_id=0, event_id=4, tv_sec=2012-04-06_16:43:44, tv_usec=206969, sig_id=2012647, sig_gen=1, sig_rev=3, class=33, pri=1, sip=10.10.10.216, dip=199.47.218.151, sp=52419, dp=80, protocol=6, pkt_action=0
11, sensor_id=0, event_id=7, tv_sec=2012-04-06_16:43:45, tv_usec=921156, sig_id=2012647, sig_gen=1, sig_rev=3, class=33, pri=1, sip=10.10.10.249, dip=199.47.216.148, sp=57933, dp=80, protocol=6, pkt_action=0
12, sensor_id=0, event_id=8, tv_sec=2012-04-06_16:43:46, tv_usec=54925, sig_id=2012647, sig_gen=1, sig_rev=3, class=33, pri=1, sip=10.10.10.248, dip=199.47.216.148, sp=52706, dp=80, protocol=6, pkt_action=0
17, sensor_id=0, event_id=11, tv_sec=2012-04-06_16:43:55, tv_usec=600844, sig_id=2012647, sig_gen=1, sig_rev=3, class=33, pri=1, sip=10.10.30.137, dip=199.47.218.150, sp=53159, dp=80, protocol=6, pkt_action=0
26, sensor_id=0, event_id=16, tv_sec=2012-04-06_16:44:01, tv_usec=312266, sig_id=2012647, sig_gen=1, sig_rev=3, class=33, pri=1, sip=10.10.10.236, dip=199.47.218.150, sp=52569, dp=80, protocol=6, pkt_action=0
43, sensor_id=0, event_id=25, tv_sec=2012-04-06_16:44:24, tv_usec=655231, sig_id=2012647, sig_gen=1, sig_rev=3, class=33, pri=1, sip=10.10.10.100, dip=199.47.217.149, sp=51614, dp=80, protocol=6, pkt_action=0
4386, sensor_id=0, event_id=2156, tv_sec=2012-04-06_18:39:40, tv_usec=946145, sig_id=2014520, sig_gen=1, sig_rev=2, class=29, pri=3, sip=77.67.11.67, dip=10.10.10.227, sp=80, dp=49516, protocol=6, pkt_action=0
  - 4370, sensor_id=0, event_id=2155, tv_sec=2012-04-06_18:39:40, tv_usec=946145, sig_id=11192, sig_gen=1, sig_rev=11, class=33, pri=1, sip=77.67.11.67, dip=10.10.10.227, sp=80, dp=49516, protocol=6, pkt_action=0
4387, sensor_id=0, event_id=2157, tv_sec=2012-04-06_18:39:40, tv_usec=946145, sig_id=15306, sig_gen=1, sig_rev=14, class=29, pri=3, sip=77.67.11.67, dip=10.10.10.227, sp=80, dp=49516, protocol=6, pkt_action=0
  - 4370, sensor_id=0, event_id=2155, tv_sec=2012-04-06_18:39:40, tv_usec=946145, sig_id=11192, sig_gen=1, sig_rev=11, class=33, pri=1, sip=77.67.11.67, dip=10.10.10.227, sp=80, dp=49516, protocol=6, pkt_action=0
7287, sensor_id=0, event_id=3578, tv_sec=2012-04-06_20:01:37, tv_usec=462367, sig_id=15306, sig_gen=1, sig_rev=14, class=29, pri=3, sip=77.67.28.43, dip=10.10.10.224, sp=80, dp=50512, protocol=6, pkt_action=0
  - 7272, sensor_id=0, event_id=3577, tv_sec=2012-04-06_20:01:37, tv_usec=462367, sig_id=11192, sig_gen=1, sig_rev=11, class=33, pri=1, sip=77.67.28.43, dip=10.10.10.224, sp=80, dp=50512, protocol=6, pkt_action=0
10452, sensor_id=0, event_id=5141, tv_sec=2012-04-06_21:30:59, tv_usec=735063, sig_id=15306, sig_gen=1, sig_rev=14, class=29, pri=3, sip=173.192.224.174, dip=10.10.10.224, sp=80, dp=49642, protocol=6, pkt_action=0
  - 10439, sensor_id=0, event_id=5140, tv_sec=2012-04-06_21:30:59, tv_usec=735063, sig_id=11192, sig_gen=1, sig_rev=11, class=33, pri=1, sip=173.192.224.174, dip=10.10.10.224, sp=80, dp=49642, protocol=6, pkt_action=0
17929, sensor_id=0, event_id=8874, tv_sec=2012-04-07_01:13:08, tv_usec=783337, sig_id=15306, sig_gen=1, sig_rev=14, class=29, pri=3, sip=4.26.226.126, dip=10.10.10.242, sp=80, dp=49504, protocol=6, pkt_action=0
  - 17916, sensor_id=0, event_id=8873, tv_sec=2012-04-07_01:13:08, tv_usec=783337, sig_id=11192, sig_gen=1, sig_rev=11, class=33, pri=1, sip=4.26.226.126, dip=10.10.10.242, sp=80, dp=49504, protocol=6, pkt_action=0
22155, sensor_id=0, event_id=10987, tv_sec=2012-04-07_03:18:41, tv_usec=469133, sig_id=2013504, sig_gen=1, sig_rev=2, class=33, pri=1, sip=80.193.213.28, dip=130.239.18.138, sp=46540, dp=80, protocol=6, pkt_action=0
22770, sensor_id=0, event_id=11295, tv_sec=2012-04-07_03:34:37, tv_usec=717231, sig_id=2013504, sig_gen=1, sig_rev=2, class=33, pri=1, sip=10.10.10.50, dip=143.166.224.62, sp=59382, dp=80, protocol=6, pkt_action=0
29466, sensor_id=0, event_id=14643, tv_sec=2012-04-07_07:02:11, tv_usec=833859, sig_id=2013504, sig_gen=1, sig_rev=2, class=33, pri=1, sip=10.10.10.205, dip=88.191.125.191, sp=56213, dp=80, protocol=6, pkt_action=0
#!/usr/bin/perl

use SnortUnified(qw(:ALL));
use Socket;
use POSIX;

$file = shift;
$UF_Data = openSnortUnified($file) or die;

$\ = "\n"; $" = ", ";
while ( $record = readSnortUnifiedRecord() ) {

  $recnum++;

  if ($record->{'TYPE'} == 7) {
    if ($last_event && !$packet_found) {
      print "$e{$last_event}";
      foreach $e (@{$p->{$last_event_time}}) {
        print "  - $e{$e}";
      }
    }
    $packet_found = undef;
    $last_event = $record->{'event_id'};
    $last_event_time = "$record->{'tv_sec'}.$record->{'tv_usec'}";
    $event_data = $recnum;
    foreach $field ( @{$record->{'FIELDS'}} ) {
      my $v = $record->{$field};
      if ($field =~ /^.ip$/) {
        $v = inet_ntoa(pack("N", $v));
      } elsif ( $field =~ /_sec$/) {
        $v = strftime("%F_%T", localtime $v);
      } elsif ( $field eq 'pkt' ) {
        $v = unpack("H*", $v);
      }
      $event_data .= ", $field=" . $v;
    }
    $e{$last_event} = $event_data;

  } elsif ($record->{'TYPE'} == 2) {
    $packet_found = 1;
    push(@{$p->{"$record->{'pkt_sec'}.$record->{'pkt_usec'}"}}, $record->{'event_id'});
  }
}
Collaborator

binf commented Apr 11, 2012

On Wed, Apr 11, 2012 at 3:34 AM, Stephane Chazelas
reply@reply.github.com
wrote:

That's 2.9.2.1 from securityonion. I've been seeing this with older versions as well. Only now am I looking into it.

2.9.2.2 has a fix for one of the issue and its not in a "security
onion i think"....so can't help you on how to get it running on there.
but if your able to compile 2.9.2.2 elsewhere it should work fine.

u2_anon ==https://github.com/binf/u2_anon

Also try to come to on barnyard2-users ML rather than talk thru github
if you can/want.

-elz

I couldn't find u2anon, but here is the output of the perl script below that reports the events without packets and tries to correlate those with events that have packets at the exact same microsecond.

For instance, event 3 below (5th record) had no packet. Nor did event 2156, but event 2155 had a packet at the same microsecond logged against it. So it seems it's not only about packets triggering several alerts.

5, sensor_id=0, event_id=3, tv_sec=2012-04-06_16:43:41, tv_usec=527525, sig_id=2012647, sig_gen=1, sig_rev=3, class=33, pri=1, sip=10.10.10.244, dip=199.47.219.151, sp=55729, dp=80, protocol=6, pkt_action=0
6, sensor_id=0, event_id=4, tv_sec=2012-04-06_16:43:44, tv_usec=206969, sig_id=2012647, sig_gen=1, sig_rev=3, class=33, pri=1, sip=10.10.10.216, dip=199.47.218.151, sp=52419, dp=80, protocol=6, pkt_action=0
11, sensor_id=0, event_id=7, tv_sec=2012-04-06_16:43:45, tv_usec=921156, sig_id=2012647, sig_gen=1, sig_rev=3, class=33, pri=1, sip=10.10.10.249, dip=199.47.216.148, sp=57933, dp=80, protocol=6, pkt_action=0
12, sensor_id=0, event_id=8, tv_sec=2012-04-06_16:43:46, tv_usec=54925, sig_id=2012647, sig_gen=1, sig_rev=3, class=33, pri=1, sip=10.10.10.248, dip=199.47.216.148, sp=52706, dp=80, protocol=6, pkt_action=0
17, sensor_id=0, event_id=11, tv_sec=2012-04-06_16:43:55, tv_usec=600844, sig_id=2012647, sig_gen=1, sig_rev=3, class=33, pri=1, sip=10.10.30.137, dip=199.47.218.150, sp=53159, dp=80, protocol=6, pkt_action=0
26, sensor_id=0, event_id=16, tv_sec=2012-04-06_16:44:01, tv_usec=312266, sig_id=2012647, sig_gen=1, sig_rev=3, class=33, pri=1, sip=10.10.10.236, dip=199.47.218.150, sp=52569, dp=80, protocol=6, pkt_action=0
43, sensor_id=0, event_id=25, tv_sec=2012-04-06_16:44:24, tv_usec=655231, sig_id=2012647, sig_gen=1, sig_rev=3, class=33, pri=1, sip=10.10.10.100, dip=199.47.217.149, sp=51614, dp=80, protocol=6, pkt_action=0
4386, sensor_id=0, event_id=2156, tv_sec=2012-04-06_18:39:40, tv_usec=946145, sig_id=2014520, sig_gen=1, sig_rev=2, class=29, pri=3, sip=77.67.11.67, dip=10.10.10.227, sp=80, dp=49516, protocol=6, pkt_action=0
 - 4370, sensor_id=0, event_id=2155, tv_sec=2012-04-06_18:39:40, tv_usec=946145, sig_id=11192, sig_gen=1, sig_rev=11, class=33, pri=1, sip=77.67.11.67, dip=10.10.10.227, sp=80, dp=49516, protocol=6, pkt_action=0
4387, sensor_id=0, event_id=2157, tv_sec=2012-04-06_18:39:40, tv_usec=946145, sig_id=15306, sig_gen=1, sig_rev=14, class=29, pri=3, sip=77.67.11.67, dip=10.10.10.227, sp=80, dp=49516, protocol=6, pkt_action=0
 - 4370, sensor_id=0, event_id=2155, tv_sec=2012-04-06_18:39:40, tv_usec=946145, sig_id=11192, sig_gen=1, sig_rev=11, class=33, pri=1, sip=77.67.11.67, dip=10.10.10.227, sp=80, dp=49516, protocol=6, pkt_action=0
7287, sensor_id=0, event_id=3578, tv_sec=2012-04-06_20:01:37, tv_usec=462367, sig_id=15306, sig_gen=1, sig_rev=14, class=29, pri=3, sip=77.67.28.43, dip=10.10.10.224, sp=80, dp=50512, protocol=6, pkt_action=0
 - 7272, sensor_id=0, event_id=3577, tv_sec=2012-04-06_20:01:37, tv_usec=462367, sig_id=11192, sig_gen=1, sig_rev=11, class=33, pri=1, sip=77.67.28.43, dip=10.10.10.224, sp=80, dp=50512, protocol=6, pkt_action=0
10452, sensor_id=0, event_id=5141, tv_sec=2012-04-06_21:30:59, tv_usec=735063, sig_id=15306, sig_gen=1, sig_rev=14, class=29, pri=3, sip=173.192.224.174, dip=10.10.10.224, sp=80, dp=49642, protocol=6, pkt_action=0
 - 10439, sensor_id=0, event_id=5140, tv_sec=2012-04-06_21:30:59, tv_usec=735063, sig_id=11192, sig_gen=1, sig_rev=11, class=33, pri=1, sip=173.192.224.174, dip=10.10.10.224, sp=80, dp=49642, protocol=6, pkt_action=0
17929, sensor_id=0, event_id=8874, tv_sec=2012-04-07_01:13:08, tv_usec=783337, sig_id=15306, sig_gen=1, sig_rev=14, class=29, pri=3, sip=4.26.226.126, dip=10.10.10.242, sp=80, dp=49504, protocol=6, pkt_action=0
 - 17916, sensor_id=0, event_id=8873, tv_sec=2012-04-07_01:13:08, tv_usec=783337, sig_id=11192, sig_gen=1, sig_rev=11, class=33, pri=1, sip=4.26.226.126, dip=10.10.10.242, sp=80, dp=49504, protocol=6, pkt_action=0
22155, sensor_id=0, event_id=10987, tv_sec=2012-04-07_03:18:41, tv_usec=469133, sig_id=2013504, sig_gen=1, sig_rev=2, class=33, pri=1, sip=80.193.213.28, dip=130.239.18.138, sp=46540, dp=80, protocol=6, pkt_action=0
22770, sensor_id=0, event_id=11295, tv_sec=2012-04-07_03:34:37, tv_usec=717231, sig_id=2013504, sig_gen=1, sig_rev=2, class=33, pri=1, sip=10.10.10.50, dip=143.166.224.62, sp=59382, dp=80, protocol=6, pkt_action=0
29466, sensor_id=0, event_id=14643, tv_sec=2012-04-07_07:02:11, tv_usec=833859, sig_id=2013504, sig_gen=1, sig_rev=2, class=33, pri=1, sip=10.10.10.205, dip=88.191.125.191, sp=56213, dp=80, protocol=6, pkt_action=0

#!/usr/bin/perl

use SnortUnified(qw(:ALL));
use Socket;
use POSIX;

$file = shift;
$UF_Data = openSnortUnified($file) or die;

$\ = "\n"; $" = ", ";
while ( $record = readSnortUnifiedRecord() ) {

 $recnum++;

 if ($record->{'TYPE'} == 7) {
   if ($last_event && !$packet_found) {
     print "$e{$last_event}";
     foreach $e (@{$p->{$last_event_time}}) {
       print "  - $e{$e}";
     }
   }
   $packet_found = undef;
   $last_event = $record->{'event_id'};
   $last_event_time = "$record->{'tv_sec'}.$record->{'tv_usec'}";
   $event_data = $recnum;
   foreach $field ( @{$record->{'FIELDS'}} ) {
     my $v = $record->{$field};
     if ($field =~ /^.ip$/) {
       $v = inet_ntoa(pack("N", $v));
     } elsif ( $field =~ /sec$/) {
       $v = strftime("%F
%T", localtime $v);
     } elsif ( $field eq 'pkt' ) {
       $v = unpack("H*", $v);
     }
     $event_data .= ", $field=" . $v;
   }
   $e{$last_event} = $event_data;

 } elsif ($record->{'TYPE'} == 2) {
   $packet_found = 1;
   push(@{$p->{"$record->{'pkt_sec'}.$record->{'pkt_usec'}"}}, $record->{'event_id'});
 }
}


Reply to this email directly or view it on GitHub:
#17 (comment)

Collaborator

binf commented Jun 21, 2012

The latest vestion of snort released today should fix the issue 2.9.3, except " it can happen for activate rules without a matching dynamic rule or if an error occurs with obfuscation".

Collaborator

binf commented Dec 28, 2012

Can be closed

@firnsy firnsy closed this Apr 8, 2013

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment