This site is now 100% read-only, and retired.

Application level firewalling

Posted by Steve on Thu 14 Apr 2005 at 17:56

Tags:

There are many application-level firewalls for other platforms, which allow you to allow or deny particular programs from making use of your network. With the standard iptables firewalling tool you can achive the same thing on Debian systems.

Although I've not seen this documented in many places I've recently been experimenting with firewalling some applications to avoid unwelcome privacy leaks, and to more tightly control the system.

If your kernel was compiled with CONFIG_IP_NF_MATCH_OWNER then you can configure your iptables firewall to allow or reject packets on a per-command basis.

The following example shows how to drop all outgoing packets from the acroread command:

iptables -A OUTPUT -m owner --cmd-owner acroread -j DROP

The owner module allows several different options to be used to match, allowing either matching against a process ID, a user ID, or a command name.

  • --uid-owner userid
    • Matches if the packet was created by a process with the given effective user id
  • --gid-owner userid
    • Matches if the packet was created by a process with the given effective group id
  • --pid-id processid
    • Matches if the packet was created by a process with the given process id
  • --cmd-owner name
    • Matches if the packet was created by a process with the given command name.

The "owner" module only allows matches on the OUTPUT chain, which lowers its usefulness a little - but if you're in a standard NAT situation it should be sufficient.

 

 


Re: Application level firewalling
Posted by Kellen (68.15.xx.xx) on Fri 15 Apr 2005 at 04:15
[ View Weblogs ]
Yay! Firewall rules! Blocking nasty apps from reporting usage!

Now how about some tips on shaping p2p traffic?

[ Parent ]

Re: Application level firewalling
Posted by Steve (204.52.xx.xx) on Fri 15 Apr 2005 at 04:17
[ View Weblogs ]

Is this question on Traffic Shaping useful?

If not contributions are welcome .. ;)

Steve
-- Steve.org.uk

[ Parent ]

Re: Application level firewalling
Posted by Kellen (68.15.xx.xx) on Fri 15 Apr 2005 at 04:36
[ View Weblogs ]
It is a little useful, but I've been trying to specifically target p2p and throttle its speed. I've used the ipp2p kernel module, but I didn't find this to work very well alone.

My current solution is a conjunction of ipp2p and to just to DROP (bad, I know) a huge port range from being forwarded (NAT) when I start to experience delays. Keeps the roommates in line, but I'd rather allow them to continue to use things at a reduced speed.

This seems like a "hard" problem since lots of p2p has block evasion built in...

[ Parent ]

Re: Application level firewalling
Posted by peterhoeg (62.242.xx.xx) on Thu 28 Apr 2005 at 09:02
I will strongly recommend that all workstations even on an internal protected LAN are equipped with basic firewall rules in place.

For laptops that operate in potentially hostile environments that is even more true.

Cfengine can be used to distribute the scripts.

[ Parent ]

Re: Application level firewalling
Posted by wouter (195.162.xx.xx) on Thu 12 May 2005 at 03:49

Eh... why is that? The biggest danger of workstations behind a firewall and NAT is not direct tcp/ip but email attachments, trojans and insecure use of buffers with programs that connect to the internet.

There is no reason whatsoever to run a firewall on each workstation if you disable all services (except perhaps ssh, for remote administration). It's really not going to stop anything worthwhile. And no admin likes to waste time with dumb support questions and total chaos as a cause of unnecessary complications.

Ofcourse, if you were talking about a certain commercial operating system...

[ Parent ]

Re: Application level firewalling
Posted by peterhoeg (193.163.xx.xx) on Thu 12 May 2005 at 08:43
Because when bad things do come inside, things get messy!

There are a number of valid reasons why people should be allowed to run various services, web servers, database servers and the likes on the desktop pc's which is why you simply cannot just disable everything.

But there is NO reason (of course you can find some if you really try, but that is not the purpose here) why pc's should be allowed to communicate between themselves.

So instead simply block all connection attempts to workstations (except maybe ssh, cfengine and whatever else you need for remote admin) and then leave it at that. You control it centrally and there is no trouble shooting.

The reasons are valid for all OS's.

[ Parent ]

Re: Application level firewalling
Posted by Anonymous (66.36.xx.xx) on Mon 16 May 2005 at 02:10
I believe you are wrong. If you allow a server to run on a computer, you want people to connect to it. If you block connections from other workstations, it defeats the point of having a server in the first place. If the server is only intended for use on the workstation itself, it has no buisness listening on external interfaces.

[ Parent ]

Re: Application level firewalling
Posted by debjunkie (62.206.xx.xx) on Tue 14 Jun 2005 at 23:34
I don't know if I did not understand "application level firewalling" correctly before.
As far as I know, it means that a firewall can verify the traffic on the application level layer of the OSI-model (Layer 7), to see if, i.e., the traffic to a server and to the destination port 80 is really HTTP and not something else, i.e., a backdoor malware reporting to its master by using port 80, which is allowed on most firewalls. Symantec and Checkpoint Firewalls name this feature "Application Level Gateway".
So to me this topic was misleading, and as I don't want to be unkind, I still have to say that I was disappointed, because I thought you would have found some way to do this on a debian-box...

Here are some examples I found on the net:

[ Parent ]

Re: Application level firewalling
Posted by Anonymous (174.45.xx.xx) on Sat 22 Jul 2017 at 19:41

This post is very old and the kernel has not supported --cmd-owner since 2005. See www.spinics.net/lists/netfilter/msg49716.html

[ Parent ]