iptables OUTPUT rules: DROP by process (PID)?
 

Hi all,

I have a good iptables firewall set up to filter INPUT packets, but I want to be able to filter packets traversing the OUTPUT chain. Specifically, I want to limit the applications (ie, processes) that are allowed through the firewall to the internet.

I want to DROP all out-going packets from applications other than those I choose. This would prevent communications from trojans, spyware, update agents (!) etc etc from my box.

(ZoneAlarm, a popular Windows firewall, provides similar functionality: all applications are blocked until they are explicitly permitted. In addition, users are prompted when unauthorised applications attempt to communicate past the firewall.)

I have searched the forums without success. I see that it is possible to filter on PID (see http://iptables-tutorial.frozentux.n.../pid-owner.txt). The obvious problem is mapping from PIDs to applications (especially as they will be dynamic!)

Does anyone have any suggestions? Any scripts/applications/tools out there that can handle this? Has anyone done something similar before?

thanks in advance!
gregory.

Interesting, though IMO this is more of a programming question than a security related one. Anyway. Like everyone else I've been pondering this as well. If you want to explore this I think you need to look for functionality in a few area's:
Process discovery should
- scan for "valid" PID's and,
- queue them for processing and,
- leave out PIDs below 20 that belong to kernel processes or,
- are already in the state table.
- During the scanning it should check if processes in the queue haven't already died: those of you who are familiar with running Chkrootkit on boxen with short-living processes know the approach to checking PID's the way chkrootkit does it fails. This part will either make up for 99 percent of the app's overhead or make it fail, IMO.
Process validation should check if
- the app is capable of requesting a client or server socket,
- the name of the app on the commandline is equal to the name of the binary,
- if the checksum of the binary in /proc matches the binary on disk: something like "sha1sum /proc/$(/sbin/pidof someApp)/exe $(strings /proc/$(/sbin/pidof someApp)/cmdline)" if you want to have an idea,
- the process UID is part of a group that has privileges/restrictions: check out std Linux capabilities in LINUX_CAPABILITIES (caps intended) and Grsecurity.org patch for usable socket restriction options, you need to be able to filter server apps from user apps, do user/group management,
- the process already is in the state table or has no rules attached.
Examples of apps that could have "user servicable parts" could be Procwatch or Nabou: the FreeBSD port of Systrace looks promising in the way it handles authorization but I have only skimmed the docs a while ago.
Rule management then only has to deal with adding/deleting rules.

As far as I can see there are three basic hooks for getting an app. One is scanning /proc, the other is waiting for an app to call for a socket to be set up and the third one will be sniffing for traffic.
Scanning /proc will be more of a "brute force" approach because for instance starting up a client app like Nutscrape doesn't mean I'm going out on the network. Sniffing for traffic and denying it as soon as it doesn't match up with any criteria is just too late, so waiting for an app to make a call to set up a socket seems the best way so far. Having a static list of apps that are always allowed could speed up the decision part. Also for all of the above you have to ask yourself if an app could DoS this "ZA for Linux" approach.


I hope this gives you some idea about what I think you could be looking at in terms of needed functionality on a high level.

unSpawn,

Thanks for this informative post. Clearly some excellent advice here!

I was hoping someone else would have addressed this already and there would be an easy solution! Oh well, there is a lot to think about here anyway....thanks again. :-)

If you're willing to recompile your kernel, it is supported in iptables.

<snip from man iptables>
owner
This module attempts to match various characteristics of
the packet creator, for locally-generated packets. It is
only valid in the OUTPUT chain, and even this some packets
(such as ICMP ping responses) may have no owner, and hence
never match.

--uid-owner userid
Matches if the packet was created by a process with
the given effective user id.

--gid-owner groupid
Matches if the packet was created by a process with
the given effective group id.

--pid-owner processid
Matches if the packet was created by a process with
the given process id.

--sid-owner sessionid
Matches if the packet was created by a process in
the given session group.

--cmd-owner name
Matches if the packet was created by a process with
the given command name. (this option is present
only if iptables was compiled under a kernel sup-
porting this feature)
</snip>

These features can be used, for instance, to make a box only capable of making port 80 connections from mozilla, or IRC from XChat. Cool stuff.

HTH

Ben.

anyone know if 2.4.x supports this... or is this 2.5.x only

I think it's 2.5... I couldn't make it work on 2.4.18 or 2.4.20, though I can't say I tried very hard.

B.

lol, thx for the tip german. Too bad I need to have a stable kernel on this one box, and I was planning on writing a new iptables script one of these days.