== Introduction ==

LAF - Linux Application Firewall
This kernel driver blocks network sockets, allowing only whitelisted process to connect to the LAN and the Internet.

While iptables filter by ip and port, it cannot filter by process name - laf.ko is a simple driver to do this.

The following diagram describes the inner workings:

   +--------+     add     +--------+
   | sysctl | <---------> | laf.ko | --------+
   +--------+ enabled = 0 +--------+ NETLINK |
     ^        debug   = 0     ^              |
     |        log     = 1     | upload       |
     |                        | whitelist    | get events              KERNEL
   - |  -    -    -    -    - |  -    -    - |  -   -   -    -    -    -    -
     |                +-------+           +------+  events  +------+     USER
     | sets           | NETLINK           | lafd | -------> | DBus |
     | enabled = 1    |                   +------+          +------+
   +--------------------+   launch  +---------+                |
   |       lafctl       | <-------- | systemd |                | QtDBus
   +--------------------+           +---------+             +------+
             ^  read whitelist       ^                      | qlaf | 
             |                       |                      +------+
      +--------------+ +---------------------------------+
      | /etc/laf.cfg | | /lib/systemd/system/laf.service |
      +--------------+ +---------------------------------+


== Configuration == 

Edit /etc/laf.cfg

There are two whitelists. The first is for specifying the entire process name that we want to allow access to network sockets.

The second is for strings to be compared with strstr(), if you want to allow all process with a name containing a specific word, then this is the wordlist for doing that. For example, Chrome changes its process name, so this wordlist should be used.

== Installing and running ==

$ make
# make install

This will compile and copy the module on /lib/modules.
You can load it with:

# modprobe laf

Add the module to /etc/modules or similar...

# vi /etc/laf.cfg
# lafctl -u -f /etc/laf.cfg

To make the qLAF GUI:

$ cd qlaf
$ qmake
$ make
# cp qlaf /usr/bin

If you want to see what is blocking the LAF driver:

tail -f /var/log/kern.log

[ 9006.541447] LAF: Enabled
[ 9010.042030] LAF: call 01 fam 0x100000002 blocked: iexplore.exe (24763:24730) parent: wine (24728)
[ 9015.586690] LAF: call 01 fam 0x100000002 blocked: kk.x86 (24769:24769) parent: bash (10343)
[13118.760088] LAF: call 01 fam 0x100000002 blocked: wineserver (25729:25729) parent: systemd (1)
[16569.004590] LAF: fam 10 proto 00 blocked: VBoxXPCOMIPCD (26102:26102) parent: systemd (1)
[16569.048654] LAF: fam 10 proto 00 blocked: VBoxSVC (26107:26107) parent: systemd (1)

And if lafd is started you also can monitor the dbus:

$ dbus-monitor --system "interface='laf.signal.source'"

signal sender=:1.529 -> dest=(null destination) serial=19 path=/laf/signal/alert; interface=laf.signal.source; member=event
   string "/2/0/kk/27293/27293/bash/27255"

== Philosophy ==

This is not a comprehensive solution against advanced attackers. There are many ways to bypass this kind of protection. However, it makes for an additional barrier for the attacker to overcome - think of it as defense in depth. The typical use case would be to isolate vainilla spyware, privacy issues and to block most common shellcodes.

In the past we protected our open ports to the Internet, nowadays the problem is in the client side, client apps sending data to the Internet.

== Authors ==

@sha0coder: https://twitter.com/sha0coder
@capi_x: https://twitter.com/capi_x