July 31, 2014

Bro IDS on OpenWRT Part II — The Paper

Filed under: Blog — krkhan @ 11:40 pm

The paper chronicling our adventures with Bro IDS on home routers just got published in the latest issue of SIGCOMM CCR. Here’re the details:

Title: Rapid and Scalable ISP Service Delivery through a Programmable MiddleBox

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).

Published in: ACM SIGCOMM Computer Communication Review (Volume 44 Issue 3, July 2014)

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.

Tags: , , , , , , , , , , ,

June 19, 2014

cl-ecc: A prototype implementation of ECC in Common Lisp

Filed under: Blog — krkhan @ 11:20 pm

Recently I’ve been reading through these excellent books in my spare time:

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:

(defconstant *p17-curve*
    :a 2
    :b 2
    :p 17
    :g (make-instance
         :x 5
         :y 1)
    :n 19))

And an ECDSA with this curve:

(def-positive-test test-ecdsa ()
  (let* ((c *p17-curve*)
         (bob-priv 3)
         (bob-pub (ecdh-gen-pub c bob-priv))
         (msghash 8)
         (k 7)
         (sig (ecdsa-gen-sig c msghash bob-priv k)))
    (assert (sig-equalp sig (make-instance 'ECDSASig :r 0 :s 12)))
    (ecdsa-verify-sig c msghash sig bob-pub)))

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.

Tags: , , , , , , , ,

July 1, 2013

Blocking traffic flows selectively with a timeout from Bro IDS

Filed under: Blog — krkhan @ 2:55 am

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:

  1. Constructs and adds the iptables rule to the FORWARD chain.
  2. Constructs the corresponding deletion rule.
  3. Creates a temporary bash script, writes the rule to it, makes the new script self-deleting.
  4. Schedules a launch of the temporary script with at command.

Here’s the script:

if [ $# -le 5 ] ; then
  echo "usage: $0 proto src sport dst dport timeout"
  exit 1
echo "  proto: $1"
echo "    src: $2"
echo "  sport: $3"
echo "   dest: $4"
echo "  dport: $5"
echo "timeout: $6"
if [ "$proto" != "any" ]; then
  rule="$rule --protocol $proto"
if [ "$src" != "" ]; then
  rule="$rule --source $src"
if [ "$sport" != "0" ]; then
  rule="$rule --sport $sport"
if [ "$dest" != "" ]; then
  rule="$rule --destination $dest"
if [ "$dport" != "0" ]; then
  rule="$rule --dport $dport"
rule="$rule -j DROP"
echo "rule: $rule"
addcmd="iptables -I FORWARD $rule"
delcmd="iptables -D FORWARD $rule"
echo "delscript: $delscript"
echo "#!/bin/sh" >>$delscript
echo $delcmd >>$delscript
echo "rm \"${delscript}\"" >>$delscript
chmod 755 $delscript
echo "adding iptable rule:"
echo $addcmd
atcmd="at -M -f $delscript now + $timeout min"
echo "creating at job for deletion:"
echo $atcmd

Given below is an example run. First, let’s print the default FORWARD chain:

# iptables -nL FORWARD
Chain FORWARD (policy ACCEPT)
target     prot opt source               destination         
ACCEPT     all  --  anywhere            state RELATED,ESTABLISHED
ACCEPT     all  --         anywhere            
ACCEPT     all  --  anywhere             anywhere            
REJECT     all  --  anywhere             anywhere             reject-with icmp-port-unreachable
REJECT     all  --  anywhere             anywhere             reject-with icmp-port-unreachable
REJECT     all  --  anywhere             anywhere             reject-with icmp-host-prohibited

Block a flow for 2 minutes:

# sh tcp 50 60 2
  proto: tcp
  sport: 50
  dport: 60
timeout: 2
rule:  --protocol tcp --source --sport 50 --destination --dport 60 -j DROP
delscript: /tmp/tmp.SAREJvtsK0
adding iptable rule:
iptables -I FORWARD --protocol tcp --source --sport 50 --destination --dport 60 -j DROP
creating at job for deletion:
at -M -f /tmp/tmp.SAREJvtsK0 now + 2 min
job 79 at Sun Jun 30 14:37:00 2013

Let’s check if the new rule was added:

# iptables -nL FORWARD
Chain FORWARD (policy ACCEPT)
target     prot opt source               destination         
DROP       tcp  --          tcp spt:50 dpt:60
ACCEPT     all  --  anywhere            state RELATED,ESTABLISHED
ACCEPT     all  --         anywhere            
ACCEPT     all  --  anywhere             anywhere            
REJECT     all  --  anywhere             anywhere             reject-with icmp-port-unreachable
REJECT     all  --  anywhere             anywhere             reject-with icmp-port-unreachable
REJECT     all  --  anywhere             anywhere             reject-with icmp-host-prohibited

After 2 minutes, the temporary bash script shall remove the rule and then delete itself. To confirm:

# iptables -nL FORWARD
Chain FORWARD (policy ACCEPT)
target     prot opt source               destination         
ACCEPT     all  --  anywhere            state RELATED,ESTABLISHED
ACCEPT     all  --         anywhere            
ACCEPT     all  --  anywhere             anywhere            
REJECT     all  --  anywhere             anywhere             reject-with icmp-port-unreachable
REJECT     all  --  anywhere             anywhere             reject-with icmp-port-unreachable
REJECT     all  --  anywhere             anywhere             reject-with icmp-host-prohibited

The Bro module

A simple module which export one function, i.e., BlockFlow::block which takes a conn_id and a count and calls the bash script with appropriate parameters:

module BlockFlow;
export {
  global block: function(id: conn_id, t: count);
function block(id: conn_id, t: count)
  print fmt("blocking %s:%d -> %s:%d for %d minutes", id$orig_h, id$orig_p, id$resp_h, id$resp_p, t);
  local protocol = get_port_transport_proto(id$resp_p);
  print fmt("protocol is: %s", protocol);
  local cmd: string = fmt("sh %s %s %d %s %d %d", protocol
                                                             , id$orig_h, id$orig_p
                                                             , id$resp_h, id$resp_p, t);
  print fmt("executing: %s", cmd);

Bro module usage

And finally, using the module from a Bro script:

@load ./blockflow
event bro_init()
    local id: conn_id;
    id$orig_h =;
    id$orig_p = 10/tcp;
    id$resp_h =;
    id$resp_p = 20/tcp;
    BlockFlow::block(id, 2);

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.

Tags: , , , , , , ,

December 10, 2012

Bro IDS on OpenWRT

Filed under: Blog — krkhan @ 12:59 pm

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:

# bro –v
bro version 2.0
# cat test.bro
event bro_init()
	print "Hello World!";

event new_connection(c: connection)
	print "New connection created";
# bro test.bro
Hello World!
# bro -i br-lan test.bro
Hello World!
New connection created
New connection created
# ls
conn.log           notice_policy.log  reporter.log       weird.log
dns.log            packet_filter.log  test.bro

A heap of thanks to Zaafar for dealing with my messy code and providing the links to hosted files :) !

Tags: , , , , , , , ,

March 2, 2010

GoDaddy/WordPress ninoplas Base64 virus and the fix

Filed under: Blog — krkhan @ 7:40 pm

Update: The virus seems to have affected only GoDaddy websites, hence the change in title.

Few hours ago I opened my website and noticed some rather strange Javascript hanging around the bottom. After some inspection, it became evident that every page on my blog was trying to load an IFrame to some place called Turns out, I wasn’t alone and there are other users as well who are affected by this. Judging by the fact that different blogs were attacked at the same time, this was in all probability the result of a security hole in some plugin or the core itself.

The virus acted by adding a piece of encrypted code on the first line of all PHP files on the server. It’s rather unsettling to consider the extend of damage that could have been caused with the write access to those files. Still, the damage could be rectified by simply deleting those lines. I wrote a tiny script for doing this job which cleans the ninoplas virus from all the PHP files in the current directory:

Warning: While this script has worked for me, I am in no way providing any guarantee for how it behaves on other blogs. Backup your blog as well as database before executing this script.
You have been warned.

Using the fix is a simple matter of:

-bash-$ cd wordpress
-bash-$ wget
-bash-$ sh

And don’t forget to backup everything again after cleaning up. The security hole — if there is one — has still not been tracked and if it’s in the core or some plugin which you’re still using, the virus might not be so benevolent next time.

Tags: , , , , , , ,

November 29, 2008

Next Generation Intelligent Networks Research Center

Filed under: Blog — krkhan @ 7:27 pm

“Research is what I’m doing when I don’t know what I’m doing.” — Wernher von Braun

As soon as the next semester rolls over, I will be joining nexGIN RC as a research student. My task will be to participate in developmental efforts on the National ICT R&D funded project “An Intelligent Secure Kernel for Next Generation Mobile Computing Devices”. Here’s an excerpt from the project’s executive summary:

The project aims to develop secure kernel framework that enable self-monitoring, and consequently self-healing operation for an operating system of mobile devices. This is expected to produce a fully functional Secure Linux Kernel that will be run on tablet PCs / smartphones. The developed framework will be fully aware of system conditions and resource usage and will schedule different threads intelligently based on each thread/process’ behavior, thus providing a truly secure computing experience in which malware that manages to escape detection by intrusion detection systems gets thwarted in the scheduler.

From the looks of it, there will be substantial poking around Linux involved in this one. So even though my research area primarily revolved around back-heeled through balls, spoon-chip goals, splendid crosses, powerful curlers, Totti, De Rossi, Batistuta, Montella, Ibrahimovic and Cruyff until now, I’ll be trying to redirect the efforts towards kernel development. What could possibly be more fun? Oh yes, watching Roma top the Champions League Group A ahead of Chelsea, but digressing that much isn’t suitable for a single post ;) .

Tags: , , , , , ,

September 17, 2008

The (possible) Indian WiFi crackdown

Filed under: Blog — krkhan @ 10:47 pm

The blasts go off, the government comes under pressure, and going by the books, they pull out an egregiously absurd law out of their asses: They inculpate WiFi hotspots, as one of them was used by the terrorists to send an email.

“We cannot blame anyone if we forget to lock our own rooms. The ISPs should provide all these features of password and password protection,” said a Ministry of Communication and Information Technology Indian Computer Emergency Response Team (CERTC-in) senior official an incompetent dork.

First of all, I do not sympathize with terrorists’ motives because of Indians getting targeted (as distasteful as that sounds, some people did suggest it when I argued with them about WiFi-blaming being ridiculous). With that said, I find it hard to believe that clamping down on hotspot security is going to reduce the level of terrorist threats. The Indian government shall have to outlaw real life mailboxes, phone-calls and anonymity all together as well as install GPS-trackers on every Indian resident for an approach like this to work. On the other hand, exploiting public fear by labeling inane regulations as being Anti-Terrorist is much more convenient than implementing adept law enforcing, don’t you think so?

Tags: , , , , , ,