I just realized that while I haven’t been blogging actively in years now, I’ve been psuedo-blogging at Quora.

In coming months the situation shall change around here as well as I’ve finally started working on Linux/OSS after a three year gap. After stints in Xbox and Windows 10 I have finally landed Linux work; I’m now developing disk encryption solutions for Linux VMs in Azure. As the feature gets closer to public availability (somewhere in July), I’ll be blogging fun stuff related Linux disk encryption.

Meanwhile, Quora shall be my cyber-home. If you still haven’t heard of it, please get an internet connection in your cave and head over to the most addictive website on the planet right now.

As I promised in the comments section of previous post, I set out on the adventure of recompiling Bro for Lantiq routers. As a result of the exercise I have new-found respect for open-source package maintainers. Holy waffles if troubleshooting build errors in a large Autotools mess isn’t the most hemorrhage-inducing activity known to mankind.

Anyways, this time I’ve tried to keep track of the changes I’ve been making along the way. The full set of updated Makefiles and patches is maintained in the openwrt-bro repo. Also, the compiled ipk packages for Atheros and Lantiq routers are available on the release page.

Now that I have a reasonably updated Buildroot on my system and an organized set of patches, feel free to request an ipk package for your router. While I can’t guarantee that the clusterfuck of patches will compile smoothly for your platform, I’ll still give it a try.

Word of caution though, my notes indicate that one of the default scripts was leaking memory and I never got around to figuring out which one. The workaround was to launch Bro in barebone mode with -b switch, which would prevent loading of default scripts.

Abstract: With only access billing no longer ensuring profits, an ISP’s growth now relies on rolling out new and differentiated services. However, ISPs currently do not have a well-defined architecture for rapid, cost-effective, and scalable dissemination of new services. We present iSDF, a new SDN-enabled framework that can meet an ISP’s service delivery constraints concerning cost, scalability, deployment flexibility, and operational ease. We show that meeting these constraints necessitates an SDN philosophy for a centralized management plane, a decoupled (from data) control plane, and a programmable data plane at customer premises. We present an ISP service delivery framework (iSDF) that provides ISPs a domain-specific API for network function virtualization by leveraging a programmable middlebox built from commodity home-routers. It also includes an application server to disseminate, configure, and update ISP services. We develop and report results for three diverse ISP applications that demonstrate the practicality and flexibility of iSDF, namely distributed VPN (control plane decisions), pay-per-site (rapid deployment), and BitTorrent blocking (data plane processing).

Combined with the paper in IEEE COMST about botnet detection that was published last year, this yields a grand-total of 2 publications more than I thought would ever bear my name. In any case, my former colleagues are continuing their excellent work on the project which can be tracked at the iSDF wiki-page.

To ramp-up on both subjects with one shot I wrote an implementation of Elliptic Curve Crypto in Lisp. So far, it does EC versions of Diffie-Hellman, ElGamal and DSA. Some rudimentary testing was performed using the NIST-P192 curve and its corresponding ECDSA test vectors.

The package is available at GitHub in the krkhan/cl-ecc repository. Here’s a quick snippet of what the code looks like:

As a disclaimer — even though I know no one would be stupid enough to do so — please do not use this code in a production environment. It was written for recreational purposes by a hobbyist who is bad with cryptography and even worse with Lisp. On the other hand, if you have any suggestions/patches, feel free to create an issue/pull-request on GitHub.

I needed to block some flows on OpenWRT from the Bro IDS. One option was to install the recent module for expiring iptables rules which sounded like an overkill. After some tinkering around I landed on using bash and at to expire the firewall rules after timeouts (luckily the at daemon was available on OpenWRT which made my job easier).

There are three parts to the process:

The bash script

First, a script which:

Constructs and adds the iptables rule to the FORWARD chain.

Constructs the corresponding deletion rule.

Creates a temporary bash script, writes the rule to it, makes the new script self-deleting.

And the flow will be blocked for 2 minutes. Unfortunately, due to the way at command works the granularity of timeouts is limited to minutes. If you really want to block flows for only a few seconds a quick solution would be to use sleep in place of at before expiring the rule.

While I was at SysNet, we had been working on a project we called “Shrimp” — Software-defined Home Router Intelligent Monitoring Point. The goal of the project was to provide a framework for easy programmatic access to network monitoring on low-cost, commodity, home router devices. One of the requirements was to have an IDS on the home routers for which we chose Bro — the leading framework for semantic analysis of network traffic.

The OpenWRT OS was chosen as the target platform. Its SDK contained a cross-compile toolchain for CMake projects. However, during the compilation Bro tried to run the binpac and bifcl executables for processing intermediate files. The executables refused to run on the build platform if the target platform architecture was different (mostly the case, e.g., we were building on x86-64 and target was arm).

The (not-so-pretty ™) workaround we used was to build Bro twice. Once for the host, and once for the target. The CMake files were then patched to first generate binpac and bifcl binaries if they weren’t provided and then use the provided binaries if they were defined at make time. The first compile generated the binaries on x86-64 and the second compile (for arm) used the earlier binaries to process the bif files.

The Makefile and patches are available in this tarball: openwrt-bro.tar.gz, while the compiled ipk package is also available for installation. Here is a test execution of Bro on OpenWRT:

It has been a while since I’ve posted around here and the reasons have been entirely mundane — got a job, moved to a different country and lost track of everything open-source during the transition.

However, open-source is out there and every once a while you’re bound to stumble across gems that make life easier (and fun) no matter which line of work you are in and that’s exactly what happened to me today. Let me admit first, I have a fetish for multiple screens. If it was up to me I would have a circle of screens and sit inside them all day long, just to make revolving chairs lot more exciting. Take that, 3D!

Anyways, the issue with multiple screens is not only having enough video outputs on your graphic card(s), but also the sharing of resources. I want three different machines with different processors, hard-disks, heck even different operating systems to share their I/O devices. One option would be the KVM switches, but that would restrict me to only one “active” machine at a time, plus the switching button is too much of a hindrance in the work flow. Aristotle famously claimed that the whole is greater than the sum of its parts, then cometh Synergy:

(Click on the thumbnail for larger version.)

Three different machines sharing the keyboard, mouse and clipboard across five different screens and it even works across different platforms! Granted, there are some issues with the configuration which you have to take care about (especially on Windows 7+ platforms with UAC) but once it gets going it becomes one of those cute plus practical toys that make you wonder how you ever lived without them.

During the course of my work on botnet security we have had to deal with mammoth traffic traces captured at a local ISP. While analyzing the traffic we needed to extract traffic for some certain hosts out of large pcap files. An obvious solution would be to run tshark once for each host, filtering the traffic for that particular IP and writing it to a separate pcap file. However with the number of hosts approaching thousands and the pcap traces approaching terabytes in size tshark didn’t really fit the bill.

Initially I thought of writing a splitter in Python but my colleague’s aversion for using Python on large network traces coupled with lack of maintenance of libpcap bindings resulted in me going for C/libpcap directly. The new C-based slicer is available at our GitHub respository. It needs glib to compile though, as I needed a hash table implementation for maintaining the list of hosts that need to be sliced. The Makefile in the repository should take care of compiling with the appropriate flags.

Onto the performance, the speed of slicing is only throttled by libpcap‘s own read/write throughput as most of the remaining work is done in constant time. It took only 71 minutes (or 1.1 hours) to slice 1019 hosts out of a 180 GB pcap file on 2.5 GHz CPU. In simpler words, it’s lightning fast.

Right now the script does its job well enough. If someone needs to package it I’ll prefer removing the glib dependency in favor of perhaps glibc‘s own hash table implementation (search.h). In any case, I hope it proves helpful for other people playing with large pcap files.