LinuxQuestions.org
Visit Jeremy's Blog.
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Networking
User Name
Password
Linux - Networking This forum is for any issue related to networks or networking.
Routing, network cards, OSI, etc. Anything is fair game.

Notices


Reply
  Search this Thread
Old 01-30-2014, 03:31 PM   #1
ordealbyfire83
Member
 
Registered: Oct 2006
Location: Leiden, Netherlands
Distribution: LFS, Ubuntu Hardy
Posts: 305

Rep: Reputation: 89
Use iptables to allow/block specific applications?


I am aware that this question has been asked numerous times on various forums, and the most common responses seem to be that it is impossible or unnecessary. But there are many reasons why you might need this. I bring this up because there is an iptables-based tool for Android called AfWall+ (similar to DroidWall) that seems to do this and am wondering how to get this functionality for general Linux systems.

One page https://www.debian-administration.or...el_firewalling mentions a kernel parameter CONFIG_IP_NF_MATCH_OWNER and the iptables options --cmd-owner [name] and/or --pid-id [processid]. I recall reading that this functionality has been dropped after kernel 2.6.24. Likewise iptables on Debian Wheezy does not recognize these.

Rather than blocking a specific process, I would be more interested in blocking all processes from accessing the network except for the ones that I specify.

For example, in AFWall+ (on Cyanogenmod 10.0 using kernel 3.0) I have, to test things, disallowed everything except Firefox on WiFi (also AFWall+ can filter by interface, such as WiFi, cellular data, and roaming cellular data). It works "as far as I can test it." Cyanogenmod has a "Data usage monitor" so all I see in there is Firefox and Android OS. (I am not sure whether Cyanogenmod has some back door that bypasses iptables or whether something is erroneously counting data usage as it routes through the interfaces.)

I am not very knowledgeable of this but I have looked through the source code looking for anything that looks like instructions to use what is listed in the Debian tutorial and haven't found anything. In short I would like to know how AFWall+ achieves this.

Here are the iptables rules generated by AFWall+. Many thanks in advance.

Code:
Chain INPUT (policy ACCEPT)
target     prot opt source               destination         
bw_INPUT   all  --  anywhere             anywhere            

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination         
bw_FORWARD  all  --  anywhere             anywhere            
natctrl_FORWARD  all  --  anywhere             anywhere            

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination         
afwall     all  --  anywhere             anywhere            
bw_OUTPUT  all  --  anywhere             anywhere            

Chain afwall (1 references)
target     prot opt source               destination         
afwall-wifi  all  --  anywhere             anywhere            
afwall-wifi  all  --  anywhere             anywhere            
afwall-wifi  all  --  anywhere             anywhere            
afwall-wifi  all  --  anywhere             anywhere            
afwall-wifi  all  --  anywhere             anywhere            
afwall-3g  all  --  anywhere             anywhere            
afwall-3g  all  --  anywhere             anywhere            
afwall-3g  all  --  anywhere             anywhere            
afwall-3g  all  --  anywhere             anywhere            
afwall-3g  all  --  anywhere             anywhere            
afwall-3g  all  --  anywhere             anywhere            
afwall-3g  all  --  anywhere             anywhere            
afwall-3g  all  --  anywhere             anywhere            
afwall-3g  all  --  anywhere             anywhere            
afwall-3g  all  --  anywhere             anywhere            
afwall-3g  all  --  anywhere             anywhere            
afwall-3g  all  --  anywhere             anywhere            
afwall-3g  all  --  anywhere             anywhere            

Chain afwall-3g (13 references)
target     prot opt source               destination         
afwall-3g-postcustom  all  --  anywhere             anywhere            

Chain afwall-3g-fork (2 references)
target     prot opt source               destination         
afwall-3g-home  all  --  anywhere             anywhere            

Chain afwall-3g-home (1 references)
target     prot opt source               destination         
afwall-reject  all  --  anywhere             anywhere            

Chain afwall-3g-postcustom (1 references)
target     prot opt source               destination         
afwall-3g-fork  all  --  anywhere             anywhere            

Chain afwall-3g-roam (0 references)
target     prot opt source               destination         
afwall-reject  all  --  anywhere             anywhere            

Chain afwall-3g-tether (0 references)
target     prot opt source               destination         
afwall-3g-fork  all  --  anywhere             anywhere            

Chain afwall-reject (5 references)
target     prot opt source               destination         
LOG        all  --  anywhere             anywhere             limit: avg 1000/min burst 5 LOG level warning uid prefix "{AFL}"
REJECT     all  --  anywhere             anywhere             reject-with icmp-port-unreachable

Chain afwall-vpn (0 references)
target     prot opt source               destination         
afwall-reject  all  --  anywhere             anywhere            

Chain afwall-wifi (5 references)
target     prot opt source               destination         
afwall-wifi-postcustom  all  --  anywhere             anywhere            

Chain afwall-wifi-fork (2 references)
target     prot opt source               destination         
afwall-wifi-wan  all  --  anywhere             anywhere            

Chain afwall-wifi-lan (0 references)
target     prot opt source               destination         
RETURN     udp  --  anywhere             anywhere             udp dpt:domain
afwall-reject  all  --  anywhere             anywhere            

Chain afwall-wifi-postcustom (1 references)
target     prot opt source               destination         
RETURN     all  --  anywhere             anywhere             owner UID match dhcp
RETURN     all  --  anywhere             anywhere             owner UID match wifi
afwall-wifi-fork  all  --  anywhere             anywhere            

Chain afwall-wifi-tether (0 references)
target     prot opt source               destination         
afwall-wifi-fork  all  --  anywhere             anywhere            

Chain afwall-wifi-wan (1 references)
target     prot opt source               destination         
RETURN     all  --  anywhere             anywhere             owner UID match u0_a63
afwall-reject  all  --  anywhere             anywhere            

Chain bw_FORWARD (1 references)
target     prot opt source               destination         

Chain bw_INPUT (1 references)
target     prot opt source               destination         
           all  --  anywhere             anywhere             ! quota globalAlert: 2097152 bytes 
RETURN     all  --  anywhere             anywhere            
           all  --  anywhere             anywhere             owner socket exists

Chain bw_OUTPUT (1 references)
target     prot opt source               destination         
           all  --  anywhere             anywhere             ! quota globalAlert: 2097152 bytes 
RETURN     all  --  anywhere             anywhere            
           all  --  anywhere             anywhere             owner socket exists

Chain costly_shared (0 references)
target     prot opt source               destination         
penalty_box  all  --  anywhere             anywhere            

Chain natctrl_FORWARD (1 references)
target     prot opt source               destination         

Chain penalty_box (1 references)
target     prot opt source               destination
 
Old 01-30-2014, 11:43 PM   #2
Ygrex
Member
 
Registered: Nov 2004
Location: Russia (St.Petersburg)
Distribution: Debian
Posts: 666

Rep: Reputation: 68
you could ask wrong questions, if responses were «impossible» or «unnecessary», or maybe you read them wrong

netfilter allows matching packets by UID/GID owner of the associated socket, if you run each application with it's own specific user (as Android does), you can easily achieve what you need (see «owner» iptables extension)

more flexible approach would be to run the application, that you need to control, in its separate network namespace and set any iptables rules you want in that namespace (see «ip netns help»)
 
Old 01-31-2014, 06:07 AM   #3
salasi
Senior Member
 
Registered: Jul 2007
Location: Directly above centre of the earth, UK
Distribution: SuSE, plus some hopping
Posts: 4,070

Rep: Reputation: 897Reputation: 897Reputation: 897Reputation: 897Reputation: 897Reputation: 897Reputation: 897
Quote:
Originally Posted by ordealbyfire83 View Post
Rather than blocking a specific process, I would be more interested in blocking all processes from accessing the network except for the ones that I specify.
Up to a point that is possible with basic iptables. Applications used particular ports for communication and it is easy enough in iptables to allow and disallow ports. The 'well known port numbers' are documented in /etc/services, which is readable (...and grepable...).

And that's all well and good, but it depends what you are trying to protect against. So if you are concerned that someone may have loaded a particular application that is 'tricked up' to use an unusual port number, this approach does little to help. Well, you could confirm with some combination of netstat and wireshark that what is going on is what you think ought to be going on, but that doesn't protect against it changing later. Well, again, you could keep checking with netstat and wireshark...

I can't shake the feeling that you'd probably be better off with something like apparmor or selinux as that's exactly what they are designed to do (control which applications have what access to which resources - which to use might be considered distro-specific as some distros support one, some support the other and some both - you could probably make either work, if you are up for it, but 'going with the flow' is easier. Out of the two, apparmor has the less severe learning curve, but selinux is good too!).
 
Old 01-31-2014, 01:58 PM   #4
ordealbyfire83
Member
 
Registered: Oct 2006
Location: Leiden, Netherlands
Distribution: LFS, Ubuntu Hardy
Posts: 305

Original Poster
Rep: Reputation: 89
Thank you for your responses. I didn't realize that Android uses different user names for processes. I feel ignorant as I have run "top" many times and never noticed...

The ideal scenario here would be to block all traffic except for what a user wants, like say, /usr/bin/firefox. In other words block all traffic on all ports except outgoing port 80 for /usr/bin/firefox only.

Perhaps using an isolated namespace could work if everything else is blocked? I regret that I have not looked into AppArmor for some time. It looks useful, but to what extent does it support a "whitelisting" approach rather than a "blacklisting" one? I think this scenario is a bit opposite to the way that these tools were designed. A blacklisting approach treats everything in the background as trustworthy and just deals with isolated cases.

In my case, when I am connected to any (non-isolated) network, my network activity light blinks rather frequently as if something is accessing sending/receiving data. This would happen a few times a minute and running ifconfig [interface] definitely shows TX/RX bytes increasing, and if left on all day, adds up to a few megabytes, sometimes > 5-10. If one should be connected to a data network with a low quota this could be devastating. Running ps -aux doesn't seem to show anything out of the ordinary. Just assuming everything in the background is safe doesn't cut it, and I don't understand how so many linux sysadmins can be blind to the inability to only allow certain things through - anyone could easily write a modified "gedit" to spy on anything and send the data anywhere they choose over a well-known port. I understand that trust needs to be made somewhere, but removing this functionality from the Linux kernel seems a bit suspicious. If AppArmor can address issues like these, then I'd certainly be on board.
 
Old 01-31-2014, 07:32 PM   #5
salasi
Senior Member
 
Registered: Jul 2007
Location: Directly above centre of the earth, UK
Distribution: SuSE, plus some hopping
Posts: 4,070

Rep: Reputation: 897Reputation: 897Reputation: 897Reputation: 897Reputation: 897Reputation: 897Reputation: 897
Quote:
Originally Posted by ordealbyfire83 View Post
In my case, when I am connected to any (non-isolated) network, my network activity light blinks rather frequently as if something is accessing sending/receiving data. This would happen a few times a minute and running ifconfig [interface] definitely shows TX/RX bytes increasing, and if left on all day, adds up to a few megabytes, sometimes > 5-10. If one should be connected to a data network with a low quota this could be devastating. Running ps -aux doesn't seem to show anything out of the ordinary.
Well, if this is the problem description (and it may not be the whole thing, but, all the same it needs thinking about), then I'd take a different approach.

You've got 'blinkenlights' and you've got data, and that concerns you (fair enough, really); why don't you just find out what the data is? For a start, it may well not be anything that your box is originating. My suspicion - at least a suspicion that you should eliminate - is that you are counting DHCP/broadcast DNS packets (under any of its possible names, such as Avahi/Appletalk/mDNS/bonjour/rendezvous) from the network. In this case, you won't see anything odd in 'ps -aux'.

Actually, if you have experience with this style of protocol, even something like ksystemguard can give you kind of reassurance (well, at least I can look at the 'bumps' in the data display and be pretty sure what is going on), but really something like wireshark will give you a lot more analysis, and the data is easy to understand.

In this case, the data would only be going as far as the router (or other DHCP server) so that wouldn't be using up the quota that you mention?

Quote:
Originally Posted by ordealbyfire83 View Post
The ideal scenario here would be to block all traffic except for what a user wants, like say, /usr/bin/firefox. In other words block all traffic on all ports except outgoing port 80 for /usr/bin/firefox only.
Well, the bit about blocking everything except port 80 is pretty much standard fare for iptables, but whether it does everything that you want, or even what you want, is another matter. If you only allow traffic on port 80, that could be to and from any application that uses port 80. So, you have to assume that other browsers, for example, or all all right, which may or may not be what you intend. And probably there are other tools that can use port 80. And browsers could legitimately be set up to use, eg, 3128 to talk to a cache, so you'd have to decide whether that is legitimate in your context(s).

(NB: if you want the whole nine yards on iptables, there is a document over at frozentux that will help. It isn't the most compact and punchy document that you have ever read, but it is pretty comprehensive, and pretty readable, actually. Now, if you didn't like the idea of using wireshark for looking at your traffic, for some reason, you could always resort to setting up packet counters in iptables, and use that to give you a slightly more approximate view of your traffic. I don't know why you wouldn't take the wireshark approach, at least in the short term, but iptables/packet counters might be something that you'd leave in place, longer term, if you wanted to, where you probably wouldn't want to leave wireshark continuously running that long.)


Quote:
Originally Posted by ordealbyfire83 View Post
If AppArmor can address issues like these, then I'd certainly be on board.
In essence, you can define a particular application as being able to use a particular resource, or not. So, in that case, you could define that firefox, say, could use the network, but Chrome couldn't. As both of these browsers use port 80 (by default), doing that with 'basic' iptables is more difficult.

And, of course, you've got to think about everything. So, you have to work out whether there are other protocols you want to allow (DNS, ssh, sftp, nfs, samba...) and you can be sure that you'll forget at least one or two, at first. That may not be an issue, depending on how much overhead there is to put this right, but if, every time you want to add a protocol back in, you have to apply to the IT department and get someone to sign it off, that would be a bit irritating.
 
Old 02-01-2014, 12:21 AM   #6
ordealbyfire83
Member
 
Registered: Oct 2006
Location: Leiden, Netherlands
Distribution: LFS, Ubuntu Hardy
Posts: 305

Original Poster
Rep: Reputation: 89
Thank you for writing such a thorough reply. As a first step I've installed Wireshark and let it run for several hours. Aside from some routine procedures like NTP synchronization or updating data for the weather data in the clock applet (running MATE here), it looks like three main things are at work.

(1) As you mentioned, there is a lot of traffic going to and from the local router for DHCP related tasks. I know the local router has some bells and whistles like monitoring signal strength (looking at the web interface shows signal strength graphs updating a few times a minute, so I assume it is sending packets to measure this).

(2) There are a lot of things directed toward 224.0.0.251. These entries originate from elsewhere on the network but not not my computer. These specifically come from Apple gadgets (there is an iPhone, iPad, and Macbook on the network, but they aren't mine and I can't poke around with them). I am not sure why this is showing up on my system though. I have read that 224.0.0.251 might be related to Avahi, but I do not have it installed (there are a couple libavahi-* packages that may have got pulled in as dependencies, but no binary Avahi that I am aware of).

(3) This is the most discomforting - there is an inane amount of traffic going to and from a remote IP address, specifically 96.17.170.24 (on dnsstuff this comes up as Akamai technologies which basically tells me nothing). So there is indeed erroneous traffic making it beyond the local router, somewhere to the tune of several hundred kb per hour.

So, my next step is to figure out what process is sending/receiving this data...
 
Old 02-01-2014, 05:41 AM   #7
salasi
Senior Member
 
Registered: Jul 2007
Location: Directly above centre of the earth, UK
Distribution: SuSE, plus some hopping
Posts: 4,070

Rep: Reputation: 897Reputation: 897Reputation: 897Reputation: 897Reputation: 897Reputation: 897Reputation: 897
1) and 2) might be vaguely irritating, but 3) is worrying; concentrate on that (first).

Use wireshark (you could alternatively use tcpdump; wireshark has the shallower learning curve) to have a look at the traffic; what port is it on? Use netstat to have a look at what is listening on that port (something like -tulpn); are you any further forward?

And, by the way, I did think after my last missive, I should have included weather applets, things checking for system updates, etc, etc. You've spotted those, anyway, so seemingly it wasn't a big miss.

The way all of the 'something like DNS' protocols work is that, eg, the router is constantly advertising what services it makes available (and there may also be printer-related adverts, etc, etc), so that when a new computer joins the network it can get information about what is there without having to query addresses that it doesn't know. This looks like a lot of 'noise' on the network, but it is a small fraction of the networks capacity and should stay local (unless there is a bug in the router's software...which probably isn't a non-existent possibility).

You don't have to have any kind of 'avahi' app to receive this traffic, just to respond. I think, eg, networkmanager uses the data, and I've mentioned printers, default gateways, etc, before, so expect things to break if you just block it. On the other hand, the things that break can be repaired with an 'old-fashioned' network configuration, if you prefer.
 
Old 02-01-2014, 07:35 AM   #8
unSpawn
Moderator
 
Registered: May 2001
Posts: 29,415
Blog Entries: 55

Rep: Reputation: 3607Reputation: 3607Reputation: 3607Reputation: 3607Reputation: 3607Reputation: 3607Reputation: 3607Reputation: 3607Reputation: 3607Reputation: 3607Reputation: 3607
FWIW three quick Wireshark tips:
Menu > Statistics > Protocol Hierarchy: quick overview of percentage traffic per protocol (for example to see if there's more UDP than TCP),
Menu > Statistics > Conversations > Ipv4 tab and tick "Packets" column twice: sorted list of who you're talking to the most,
Menu > Analyze > Expert Info: quick overview of errors and what's inside sessions.
*Note Wireshark also comes with 'capinfos' with which you can get bit / packet rates quickly too.
*Also note the "Filter" input box in the main screen does work with suggestions, so if you know you're interested in TCP only just entering "tcp" and then "Apply" will give you only TCP/IP traffic, entering "tcp." will give you all of its filtering options or entering "udp.port == 80" then "Apply" will give you only UDP/IP traffic to port 80.
 
Old 02-01-2014, 10:00 AM   #9
ordealbyfire83
Member
 
Registered: Oct 2006
Location: Leiden, Netherlands
Distribution: LFS, Ubuntu Hardy
Posts: 305

Original Poster
Rep: Reputation: 89
Thank you for the suggestions. I wish I had something more conclusive. I left wireshark running all night, and it seems to be using a range of ports that is getting increasingly higher. While about 1 out of 6 of them are on port 80, the rest are somewhere between 4200 and 4400.

Running 'netstat -tulpn' lists all of the running servers but there is nothing unusual in the "Foreign Address" column. If I just run 'netstat' as my activity light is blinking, I see under "Active Internet connections (w/o servers)" some tcp entries with the local address as my computer : (some of these port numbers) with 96.17.170.24 with status CLOSE_WAIT. Beyond that I haven't been able to deduce what program is using this.
 
Old 02-01-2014, 01:03 PM   #10
ordealbyfire83
Member
 
Registered: Oct 2006
Location: Leiden, Netherlands
Distribution: LFS, Ubuntu Hardy
Posts: 305

Original Poster
Rep: Reputation: 89
In further investigating, a friend had suggested using 'watch.' So I ran

Code:
sudo watch lsof -i
and sure enough, in the list I was able to spot the remote IP in question and attribute it to Mate's clock applet (entry "clock-app" under COMMAND). Upon removing the applet from my panel the IP address disappeared. In running Wireshark I earlier noticed some NTP data but I would assume that was being used by the system clock, not the clock applet, and ran only very occasionally (perhaps less than once per hour). It seems nothing coming to/from the applet was for NTP purposes, as it was not coming from any of Debian's ntp servers (which I configured during the initial install ages ago). Alas, I am not sure why this applet is accessing a remote point every 10-15 seconds over some obscure ports. I have run Wireshark for almost an hour without the applet and haven't seen the IP address since.

However, upon restoring the applet it connects to 23.72.224.10, another IP address associated with akamitechnologies.com. This is true even with no locations saved for weather data. Apparently this applet is a data hog that always needs to be connected to something.

Many thanks for all of your suggestions, as I have been able to isolate the problem. Of course Mate users would like to know exactly what this applet is doing and why.
 
Old 02-04-2014, 11:43 PM   #11
rng
Senior Member
 
Registered: Aug 2011
Posts: 1,199

Rep: Reputation: 47
Quote:
If I just run 'netstat' as my activity light is blinking, I see under "Active Internet connections (w/o servers)" some tcp entries with the local address as my computer : (some of these port numbers) with 96.17.170.24 with status CLOSE_WAIT. Beyond that I haven't been able to deduce what program is using this.
One can open a terminal, login as su, and run:
Quote:
while true; do netstat -apute; echo; echo; sleep 15; done
Then one can intermittently see what programs have been using the network.
 
Old 02-05-2014, 02:26 AM   #12
unSpawn
Moderator
 
Registered: May 2001
Posts: 29,415
Blog Entries: 55

Rep: Reputation: 3607Reputation: 3607Reputation: 3607Reputation: 3607Reputation: 3607Reputation: 3607Reputation: 3607Reputation: 3607Reputation: 3607Reputation: 3607Reputation: 3607
Quote:
Originally Posted by rng View Post
Code:
while true; do netstat -apute; echo; echo; sleep 15; done
Not necessary as netstat itself already accepts a delay argument.
 
Old 02-05-2014, 05:50 AM   #13
rng
Senior Member
 
Registered: Aug 2011
Posts: 1,199

Rep: Reputation: 47
One can also use "firestarter" application which has gui and shows the applications connecting to the network and also any attacks that happen.
http://www.fs-security.com/
http://www.fs-security.com/screenshots.php
 
  


Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off



Similar Threads
Thread Thread Starter Forum Replies Last Post
How to Drop or Block Incoming Access From Specific IP Address Using Iptables jaydul Linux - Newbie 1 10-17-2013 10:10 PM
Iptables block for hosts to specific port on server? Intresting problem! LuxLuv Linux - Security 6 06-03-2013 02:18 AM
[SOLVED] Sendmail: block specific sender to specific recipient - How? thekillerbean Linux - Server 6 07-13-2010 05:13 AM
LXer: Blocking specific network applications with iptables LXer Syndicated Linux News 0 11-19-2007 07:12 PM
Iptables/Guarddog - how to block specific outgoing packets craftybytes Linux - Security 7 05-19-2006 01:26 AM

LinuxQuestions.org > Forums > Linux Forums > Linux - Networking

All times are GMT -5. The time now is 05:57 PM.

Main Menu
Advertisement
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
Open Source Consulting | Domain Registration