Snorby on Ubuntu 14.04 LTS

I'm an IT department of one at home. It's difficult to get useful IDS tools working on your network, which is better than it used to be. Attacks are more sophisticated and easier to execute than ever. I've been experimenting with Suricata IDS and I want to see threats in a maximally useful way. Snorby is a Ruby on Rails based web application that can analyze your IDS logs and give you visibility into your network. Protection is the sum of prevention, detection and response. Log files are not detection. Snorby has a setup guide on it's website but I thought I'd make one specific to Ubuntu 14.04. There's a blog with instructions for 12.04 that will break in 14.04, as my students found out.

The key difference between the "vanilla" Snorby installation and this procedure is that I want to use Ubuntu's packaged versions of as many things as possible. I love the way Ruby bundles dependencies and compiles a standalone environment. Any sane admin would sacrifice disk space to reduce system interdependencies. I'm just seeing what I can get away with.

You must have gcc and a supporting build environment installed. I don't show that here. You install the Ruby components with:

$ sudo apt-get install ruby1.9.3 rails bundler rake wkhtmltopdf

Now you need dev packages for the gems that have C/C++ source that needs to be built:

$ sudo apt-get install mysql-server git-core libxml++2.6-dev libxslt1-dev libmysqlclient-dev

Now build. This process can be done entirely as a non-root user, therefore it should be. No excuses.

$ sudo mkdir /opt/snorby
$ sudo chown me:me /opt/snorby
$ cd /opt/snorby
$ wget https://github.com/Snorby/snorby/archive/v2.6.2.tar.gz
$ tar -xvf v2.6.2.tar.gz
$ cd snorby-2.6.2
$ bundle install
$ bundle exec rake snorby:setup

During setup I see this warning:
  "Jammit Warning: Asset compression disabled -- Java unavailable."
I'm ignoring it based on reading this thread.

Add a snorby user to the database. Don't fail to change the name and password.

mysql> grant all on snorby.* to 'snorby'@'localhost' identified by 'snorby';
Use the default configurations as a template:

cp config/snorby_config.yml.example config/snorby_config.yml

cp config/database.yml.example config/database.yml

Customize those files to match your needs. Snorby's instructions have the best information. Here's what I changed in my configuration:

1. Basic configuration: domain, email.
2. The location of wkhtmltopdf is /usr/bin/wkhtmltopdf
3. Database username and password.

What's next? Snorby's site has instructions on how to start it. After that you have to integrate the output of Suricata. 

Embedded Linux Conference, Day 2: Winners

Here's a postcard from the Embedded Linux Conference. The clear winners of this year are the Internet of Things (IoT) and drones. There was one talk about UAVs last year and this year they have an entire track. That's something of a 20x increase in talks on the subject. Some goes for IoT which in addition to its own track also scored two of the keynote talks.

One thing that really struck me is how much needs to be done in IoT. Panasonic announced that they are open-sourcing their existing software stack. Intel is headlining their efforts in the Open Interconnect Consortium which includes Cisco as a diamond member (the highest category). Everyone is happy to announce how many people are on board but during the panel discussion the emphasis was on interoperability. Something tells me Apple Homekit will start with a huge advantage: Interoperability guaranteed. Intel presented an interesting talk about IoT security but today that is more concept than implementation.

RA and Prefix Delegation on Ubuntu 14.04

I want my CIS-192 class to have access to public IP addresses for their projects. Unfortunately, there's just not enough IPv4 addresses for everyone. Rick setup prefix delegation on our router at school and I figured out how to integrate DHCP-PD and RA on Ubuntu. I based my efforts on the how-to here, but my network setup is quite different.

My Network

 

My network is loosely represented on the right. It consists of a Cisco router that is configured for SLAAC for addresses and prefix delegation for routers. Ubuntu has two interfaces. Their configuration is:

eth0: (External Interface) SLAAC
eth1: (Internal Interface) Generated by DHCP-PD from eth0.

Procedure 

Before you begin Ubuntu has to be configured to forward IPv6 packets. The following sysctl settings are required to make that work:

net.ipv6.conf.all.forwarding = 1

net.ipv6.conf.eth0.accept_ra = 2

In order for a router to accept RAs you must set the accept_ra variable to 2. The accept_ra variable is documented here. The documentation states: 

accept_ra - INTEGER 

  Accept Router Advertisements; autoconfigure using them. 

  It also determines whether or not to transmit Router Solicitations. If and only if the functional setting is to accept Router Advertisements, Router Solicitations will be transmitted. 

  Possible values are: 

    0 Do not accept Router Advertisements. 

    1 Accept Router Advertisements if forwarding is disabled. 

    2 Overrule forwarding behaviour. Accept Router Advertisements even if forwarding is enabled. Functional default: enabled if local forwarding is disabled. disabled if local forwarding is enabled.

Since I must accept RAs to be able to use eth0 this variable must be set to 2. Here's the IPv6 configuration of /etc/network/interfaces:

iface eth0 inet6 static

address 2001:db8::1

netmask 64

iface eth1 inet6 manual 

I've replaced my actual address with the RFC-3949 documentation address. Now I need to acquire a prefix from my DHCP server. I was not able to find any documentation that explained how to make the ISC DHCP client do this. Instead I installed the WIDE DHCP client:

apt-get install wide-dhcpv6-client 

Apt has a configuration script that asks what interface the DHCP client should use for performing DHCP. Be sure to set the interface that's facing the DCHP server (that's eth0 for me). The WIDE DHCP client needs to be told to ask for a prefix. In my case that's all it asks for. 

## this is: /etc/wide-dhcpv6/dhcp6c.conf

# Send a PD request on eth0 (external facing interface)

interface eth0 { 

  send ia-pd 1;

  script "/etc/wide-dhcpv6/dhcp6c-script";

};

# Upon receiving a prefix use the 

# information to set eth1 (internal facing interface)

id-assoc pd 1 {

  prefix-interface eth1 {

    ifid 1;

    sla-id 1;  

    sla-len 0; 

  };

};

It's worth describing the contents of the id-assoc stanza above. The information comes from the manual page. The DHCP client takes the prefix and computes new prefixes and interface addresses based on the lease and the information you've given. For each interface it generates the following:

Network: 

<delegated-prefix:prefix-length>|<sla-id:sla-len>::/64-<sla-len>

Address: 

<delegated-prefix:prefix-length>|<sla-id:sla-len>|<ifid>/64-<sla-len>

The composition is a bit tricky, so let's take an example. Suppose you receive a lease for 2001:db8::/48 and you want to have up to 256 delegated subnets (i.e. sla-len is 8 bits) and had the following configuration:

id-assoc pd 1 {

  prefix-interface eth1 {

    ifid 1;

    sla-id 1;  

    sla-len 8; 

  };

  prefix-interface eth2 {

    ifid 1;

    sla-id 2;  

    sla-len 8; 

  };

  prefix-interface eth3 {

    ifid 1;

    sla-id 3;  

    sla-len 8; 

  };

};

If all worked correctly you would have the following configuration: 

eth1: 2001:db8:0:1::1/56  

eth2: 2001:db8:0:2::1/56

eth3: 2001:db8:0:3::1/56

Astute observers will note that it's not possible to assign networks with a mask greater than 64. This means that if your DCHP server delegates /64 addresses (like mine does) you do not have any bits left for your sla-id so you must set sla-len to 0. If you don't set sla-len correctly the DHCP client silently fails. Grrr.

If all the above works you should be able to see an assigned address on your internal interface. The last step is to restart radvd and have it use the new address as the basis for sending out RAs. First configure radvd to pick up the prefix that's assigned to the interface: 

## this is /etc/radvd.conf
interface eth1

{

   AdvSendAdvert on;

   prefix ::/64 

   {

        AdvOnLink on;

        AdvAutonomous on;

   };

};

The empty prefix (::/64) directive will initially cause an error because radvd starts before the prefix delegation happens. There doesn't seem to be a upstart-y way to fix that so I added the following line to the bottom of my /etc/wide-dhcpv6/dhcp6c-script:

( sleep 10 ; service radvd reload )& 

Anytime the lease is renewed radvd will reload it's configuration files. This is probably close to what you want. The radvd.conf option DecrementLifetimes should probably be set to on. That is what you're supposed to do when you receive a prefix from DHCP. I haven't tried that option yet.

EDIT: This was necessary to make wide-dhcp start at the right time:

mv /etc/rc2.d/S20wide-dhcpv6-client /etc/rc2.d/S99wide-dhcpv6-client

Bacon Pecan Pie

I made a pecan pie for Pi day. I love pecans but I've never liked pecan pie because the overly sweet goo is such a put-off. Corn syrup is much cheaper than pecans so I guess you get what you pay for. My pies turned out right on the edge of sweet and savory. I loved them. Here's my recipe.

• 2 lbs. whole raw pecans
• 1 cup brown sugar
• 1 cup maple syrup
• 4 strips thick-cut bacon
• 3 medium eggs

Fry the bacon until it's crisp. Cut three strips into bits and save one for garnish. In a saucepan combine the sugar and syrup with two table spoons of bacon grease and heat until the sugar is dissolved. Stir smashed pecans and bacon bits into the syrup mixture and allow it to cool somewhat then stir in the beaten eggs. I baked mine in two prefab pie crusts at 400 degrees for 40 minutes.

The Internet of Horticulture

At the beginning of the school year Peter Shaw from the Horticulture Department asked to meet with the CS/CIS faculty about using technology in their growing operations. The Horticulture Department has magnificent greenhouses and very high tech hydroponics. So how can digital technology enable agricultural technology? The challenge seems almost too perfect a fit for exploration of the Internet of Things.

So what do you build?

We decided to take an existing function and make it more user friendly. The greenhouse has a system that uses the daily light integral to determine how much to water. It's a simple system. Light is accumulated until the measurement reaches a threshold then the water is turned on for a time. So how could a system that has two parameters (threshold and duration) be unfriendly? When both parameters are set by DIP switch. Ouch!

What networked gadget measures light?

This device is designed to use solar power alone. Since it's measuring the sun it's safe to assume it will be put in the sun and the ATtiny85 processor packs a lot of Arduino compatible punch with very little power. The bulk of power consumption comes from turning the XBee on once and a while. The robotics club prototyped this circuit over the fall semester using a breadboard. Now it's time for our first PCB!

Howto: Setup web-based IRC on Ubuntu

I want a way for students to chat me when I'm in my office hours. My classes are online and I want to make it easy for remote students to reach me. I had some time to try different solutions and I found one that is very easy to use. I had a few constraints:

1. Anonymous signin from the web. I don't want to have to create and delete accounts for students because that's a lot of work and, since I'm using my own server, I don't have access to the CIS AD server.
2. Use a popular protocol. Just because students login on the web doesn't mean that I should login from the web. I want to have my choice of clients so that I can pick one that's easy for me to manage. 
3. Using Ubuntu (of course)

So here's what I came up with. I started with ircd-hybrid. It's fairly simple to configure with a very readable configuration syntax. Install it:

apt-get install ircd-hybrid 

There are two files you will need to change first-thing:

/etc/ircd-hybrid/ircd.conf (the main configuration file)

/etc/ircd-hybrid/ircd.motd (the login message)

The ircd.conf file is fairly well documented. I setup the basic settings, naming my server and providing admin information. Because we'll be accessing this server over the web and because my webserver runs on the same machine I had to tweak the configuration somewhat. 

The irc daemon by default trusts clients connected from "localhost" (127.0.0.1). That's usually a very safe thing to do. In my case localhost should not be trusted so I altered the following section: 

auth {

        user = "*@127.0.0.1";

        spoof = "irc.lifealgorithmic.com";

        class = "users";

        flags = need_password, spoof_notice, no_tilde;

};

In this definition I use the "spoof" directive because I want to control what the domain name looks like in the client. In the default auth section I set a password:

auth {

        user = "*@*";

        class = "users";

        password = "SoooperSeeeeecretPaaaaasword";

};

This will keep random lurkers out because I can give my students the password in class. A determined person could watch my class or slides for the password but that would take more than a port scanner. If need be I can password protect the web interface. 

Now we need a web client. There happens to be a really nice and attractive one called KiwiIRC. It hasn't made it into Ubuntu yet but I hope it will someday. It's a very elegant program written in node.js. I read the installation instructions, but they need to be amended if you intend to run securely as a daemon. 

1. Install node.js and some components 

apt-get install npm

2. Create a user for kiwi. 

useradd -d /srv/kiwi -r kiwiuser

The user's home is in /srv/kiwi where I intend to install it. The kiwi user is a system user and doesn't (shouldn't) have a password. Create the home directory and make sure kiwi owns it:

mkdir /srv/kiwi

chown -R kiwiuser:kiwiuser /srv/kiwi 

3. Become kiwiuser and follow the installation instructions.

4. Make it an always thing. Until they throw upstart overboard we need to add a script to /etc/init. 

# This is /etc/init/kiwi.conf

# kiwi - The Kiwi web based IRC server

description "Kiwi server"

start on runlevel [2345]

stop on runlevel [!2345]

script

  HOME=/srv/kiwi

  export HOME

  cd /srv/kiwi

  exec /srv/kiwi/kiwi start

end script

exec /srv/kiwi/kiwi start

Now you can start kiwi with

service kiwi start

Unfortunately kiwi doesn't play nice with upstart and stopping the service must be done by hand. It's a small price to pay. Kiwi's configuration (found in config.js) is very simple. These lines matter if you're starting it as root: 

conf.user = "kiwiuser";

conf.group = "kiwiuser";

They tell kiwi to drop permissions, which it does. The daemon logs as it's own user so you will have to create a separate directory in /var/log to store the log file and give it proper permissions. Here's how you get kiwi to only connect to the local IRC server:

conf.outgoing_address = {

    IPv4: '127.0.0.1'

};

It won't be able to make connections anywhere else with that address. That's a good thing for me because I don't want my site to be abused. In the "conf.client" section you can set the default values the client gets. They can be overridden by the user or using HTML (which is rad). But the more interesting section to me was this group of directives: 

conf.restrict_server = "irc.lifealgorithmic.com";

conf.restrict_server_port = 6667;

conf.restrict_server_ssl = false;

conf.restrict_server_channel = "#web";

You can use these directives to force the way kiwi can connect to the server. This let's me put all my web clients into the "#web" jail if I want. It also keeps clever hackers from using HTML to override my defaults. The last step is to embed the widget onto your site. You can do that with an iframe element. Add HTTP arguments to control default values. Here's an example: 

<iframe frameborder="0" height="400" width="400px"

  src="http://irc.lifealgorithmic.com:7778/?theme=mini&amp;channel=#office"

></iframe>

Notice you can specify what channel to login to by default. Assuming you haven't put your users in the web jail you can use that to make widgets chat-room specific. That's what I want. 

Cisco Configuration Cheat Sheet - Part 2: More security

 h/t Omar Noory

Security is important (no, critical) to the success of a network. The cartoon on the right is the first image macro stating what is now known as an axiom of Internet life:

"Haters gonna hate"

 The phrase is used to dismiss hateful speech (often called trolling) on the Internet, especially in anonymous forums. But it's implications go much further. More people connected to the Internet means greater diversity and flow of ideas and possibly greater Democracy. It also means a greater diversity of bad behavior like trolling and hacking. People that have been into computers for a long time wish for the old days when everyone on the Internet could be trusted. Those days are gone and that's for the better.

The complexity of networks makes them resemble living things. Like living things they are constantly under threat and those threats will test their defenses and adapt. Networks, therefore, must be adaptable, resilient and self-healing. Our bodies have developed immunity to viruses in order to preserve our lives and our genes, but the defense isn't perfect and, as we now know, viruses are key drivers of human evolution. Without the viruses (and the damage they cause) we would not grow. That's true for networks, too.

So in celebration of hackers, here's something you can do to keep them out. Keep your sessions secure by doing some basic configuration:

// Make sure passwords are good passwords 
// (8 is not enough!)
(config)# security password min-length 12 

// Don't let people guess at will or they 
// will use automated bots to guess
(config)# login block-for 120 attempts 3 within 60

// Logout after a while so someone can't hijack your 
// terminal while you're at lunch
(config)# line vty 0 15

(config-line)# exec-timeout 10