iptables and path-based outbound rules?

Today I decided to set up a simple custom firewall for my netbook. iptables is great, it's quite easy to create a simple two-way firewall.

However, what I'm currently doing is this:

Code:

- Drop all traffic by default
- Allow inbound communication for established connections
- Allow outbound communication on commonly used ports

And what I'd really like is a script that does this:

Code:

- Drop all traffic by default
- Allow inbound for established connections
- Allow outbound for /usr/bin/opera on ports 80 and 443
- Allow outbound for /usr/bin/ssh on port 22
- etc.

Is there a sane way to do this with an iptables script, or is something like Shorewall needed?

 

Not possible as far as I know. The only thing you can do is only allow outbound port 22 for whatever user SSH is running as.

So if SSH runs as user.ssh you would be able to write a rule for it.

You could also try creating a network namespace for this.

 

Thanks, and wow, that's a huge bummer... Seems like a big gap in desktop security, actually.

As far as you know, do any UNIX firewalls allow an admin to write path-based rules? Or is that the exclusive province of Windows stuff?

Edit: okay, what are possible for iptables are rules per PID. So it looks like what's needed is a daemon that accepts a list of applications and ports, associates each application with its PID when it runs, applies rules per PID, and then disables those rules when the PID disappears. Time to break out that book on shell scripting...

Is there anything I should know if I attempt to write something like the above, BTW? Ways that someone could carry out a timing attack, substituting a nasty app for a good one under the same PID and fooling the daemon? Quirks of shell script security that might lead to exploits against the daemon itself? I'm still kind of a beginner at this stuff.

 

There might be a way to do path based that I don't know of but I don't think it's native to IPTables. There used to be a GUI for it but it's no longer maintained.

The user thing works well for services and whatnot. Isolating applications to users has its benefits.

I don't think outbound firewalls really mean that much to be entirely honest. Not unless you separate programs into groups because if you don't they're going to pretty much have access to any other program in their user / group.

No idea. I'll reread your post when I'm not so tired and maybe come up with something.

 

Pardon my density, but what sort of groups exactly are you referring to?

Thanks. I'm currently trying to write a reasonable facsimile of what I'm aiming for in Perl... Whether it will even run remains to be seen.

 

https://wiki.archlinux.org/index.php/Users_and_Groups

 

Okay, that's what I thought you meant. And you're right - someone running malicious code in a program that didn't have outbound privileges could just start a program that did. Makes sense, and explains why so many Windows firewalls come with MAC systems.

From the sound of it then, the script I'm working on would not be too useful without SELinux or such. I'll keep working on it though, since it may eventually be useful to someone!

 

Basically, yeah. Or they could hop to another process in the same UID.

 

I like this guy's response on OMGUbuntu when a user asked about these "application firewalls."

This guy is right.

On Windows, desktop firewalls like ZoneAlarm made the whole idea of allowing individual apps access to ports popular. They are generally referred to as application firewalls. Actually they are not really firewalls at all, but rather intrusion detection systems. That is, whenever something tries to connect to the network you get a pop-up warning you. You can either allow or decline. A true "firewall" generally blocks or allows ports, not applications (stateful firewalls). IPtables is a stateful firewall. What ZoneAlarm et al did was sort of use the word "firewall" when it really was just a mechanism to alert whenever something tried to connect to the network. This was also before Microsoft had a firewall at all inside Windows (thus third party apps were necessary since MS didn't provide any way to do it natively).

If you want to control things on an application basis and not on a port basis, then you need to control the application itself. One way to do this is with a MAC system like AppArmor. AppArmor, at least right now, does not support individual port rules, but you can decline network access all together if you want. Of course, this wont help unless you have the app in question profiled. It doesn't do much good for unknown apps that might try to connect out. So, this won't do what you want either.

So, really, there is no easy solution to do what you want. It would take some shell script hacking or perhaps someone creating a program to do it for you.

One thing you can do is disable uPnP on your router and then make IPTables rules for which ports are allowed system wide. This would stop apps from connecting to any outbound port except the ones you define. This would keep things under a bit more control, but still not perfect since a malicious app could merely connect to port 80 or whatever you allowed.

Personally I don't worry about it because I know what apps are on my system and I am not likely to fall for social engineering (running a malicious script or downloading a malicious app). If you do that then you have no need for such a "firewall."

A little googling turned up a program written to do what you want. It has a GUI and all: http://sourceforge.net/projects/leopardflower/

I have no idea how well it works as I have not tested it.

Also this link lists some of the projects to do this. There were many but many of them are out of date: http://askubuntu.com/questions/135135/alternative-to-little-snitch-app-firewall?lq=1

tuxguardian looks to be what you want, but it was last updated in 2006. However, it looked promising because it hooked directly into the kernel via LSM (and to be effective you *have* to be in the kernel. Merely writing shell scripts won't do much).

 

Leopardflower was what I was thinking of. It hasn't been maintained in a while.

 

Thank you chronomatic, that was helpful. I guess I'll be sticking with my standard iptables script.

(At least my attempt at at writing the daemon taught me some useful stuff.)

 

Not necessary on Ubuntu on which all ports are closed by default. Just download install and turn on the GUFW graphical user interface front end firewall. That's it. There is no need to mess with the command line and setting special rules for access to your network.

 

I believe there as some good reasons to block unnecessary outbound communication, involving certain remote exploits against applications (including ones that can bypass stateful firewalls). It's not vital, but from what I've heard it can help.

 

It can help if you do it right and separate the process into a new group. Otherwise not that much.

 

Using UFW it's possible to restrict applications to specific ports - remote and local. It does, of course, apply to all applications.

Code:

To                         Action      From
     --                         ------      ----
[ 1] 25,80,143,443,554,1755,1935/tcp ALLOW OUT   Anywhere (out)
[ 2] 192.168.1.254 67/tcp       ALLOW OUT   Anywhere (out)
[ 3] 192.168.1.254 53/udp       ALLOW OUT   Anywhere (out)
[ 4] 208.67.222.222 53/udp      ALLOW OUT   Anywhere (out)
[ 5] Anywhere/tcp               DENY OUT    Anywhere/tcp (out)
[ 6] Anywhere/udp               DENY OUT    Anywhere/udp (out)
[ 7] 192.168.1.254/ipv6         ALLOW OUT   Anywhere (out)
[ 8] 192.168.1.68 51400:51420/tcp ALLOW IN    Anywhere
[ 9] 25,80,143,443,554,1755,1935/tcp ALLOW OUT   Anywhere (v6) (out)
[10] Anywhere/tcp (v6)          DENY OUT    Anywhere/tcp (v6) (out)
[11] Anywhere/udp (v6)          DENY OUT    Anywhere/udp (v6) (out)

Regarding the guy from OMGUbuntu who proclaims:

Regarding the guy who proclaims:

I'm perhaps missing the point, but I don't understand how a program can "simply run another program" to gain access, assuming he means outbound access to the network, unless it's a rogue/malicious program.

 

A possible alternative (which I haven't tried, though) is a script called anfd from the German ubuntuusers wiki.

 

Learning Mint v13.
I can't understand this iptables method. Where is the remote point, where is the source point?
I think I understand packet filtering rules in several firewalls in Windows but the GUI provided in Mint v13 is baffling.
Taking your quoted examples, let's say DHCP, DNS, and the remote ports 80, 443 etc, rules - how can it be FROM when it seems to be outbound to the address listed on the left?
Could you please show step by step how to make few key rules and also does what you listed actually work? Do you get IP from the router? DNS works?

Take few simple rules,
- For DNS we need in/out by UDP, using ANY local port, remote OpenDNS, port 53
- or another, DHCP after broadcast and all that
We need in/out by UDP, local port 68, remote 67 on my router IP
A laptop may need in/out by UDP, local port 68, remote 67, on some flaky unsecured gateway
- or a typical browser rule
TCP out from any local port or, better, a range of ports, to ANY IP, ports 80-83, 443, few others maybe

I tried some of it, messed up. Also I haven't found a way to move rules up and down the list.

So how can I square your quote with my simple-minded understanding of firewall rules?
Also I gather from this thread that there is no way to limit things to applications such as svchost or Opera or some mail client and no others.
I'm lost really, even though, I gather, a firewall isn't vital in Linux.

 

@act8192,

I'm no expert to be sure. I experimented based off of Google search results on how to create rules with UFW. I think with UFW, it automatically allows the required inbound connection when an outbound rule is created to allow a solicited connection to a specific remote port(s), such as for DNS or DHCP for example. This is why it's unnecessary to create, for instance, inbound for UDP port 53 or inbound port 68 for DHCP. I found Windows firewall w/advanced security works this way as well. Hope this makes sense.

"from any" for an outbound rule basically means from the local eth0 local network adapter, which will be your local ip address. In my case it's assigned by my router as 192.168.1.xx (xx = whatever 2 digit number).

*EDIT*

Code:

To                         Action      From
--                         ------      ----
80,443,554,1755,1935/tcp   ALLOW OUT   Anywhere
25,143/tcp                 ALLOW OUT   Anywhere
75.153.176.1 53/udp        ALLOW OUT   Anywhere
208.67.222.222 53/udp      ALLOW OUT   Anywhere
67/tcp                     ALLOW OUT   Anywhere
80,443,554,1755,1935/tcp   ALLOW OUT   Anywhere (v6)
67/tcp                     ALLOW OUT   Anywhere (v6)
Anywhere (v6)              ALLOW OUT   1900/tcp

username@xubuntu:~$ sudo ufw insert 3 allow out proto tcp from any port 1900

about moving rules up or down: sorry, I haven't seen how that specific operation is done. You can, however, insert a rule where you want as seen in the example given. "insert 3" = put rule in the 3rd position. "allow out" = allow outbound "proto tcp" = protocol tcp "from any" = from local ip address "port 1900" = remote port 1900

In "sudo /etc/default/ufw" I have set the

Code:

DEFAULT_OUTPUT_POLICY="DROP"

from the default =Allow ...this means I don't need to include any deny rules because outbound is already denied by default.

 

That's where the confusion lies. The Windows "firewalls" like ZA and others are not really firewalls but more of HIPS systems. That is, they alert when any program starts and wants to connect to the Internet. This is not really what a firewall does, but since everyone called them "firewalls" the term got incorrectly used.

And as HM said, outbound "firewalls" are pretty useless. All you have to do is start a program that is allowed access already and the user would be none the wiser. And you don't need root to do that. But if the attacker does get root, it's all over anyway -- he could just disable the outbound firewall.

So, as you can see, it's a waste of time. Just block all unsolicited inbound connections and you're good. If really paranoid, then set what outbound ports you want to use and anything that doesn't use one of those ports will be denied. But this is overkill and not really of much use against an attacker for the same reasons stated above.

The whole reason we even have firewalls on desktops in the first place is because Microsoft used to ship Windows with several open ports that couldn't be turned off (stuff like Netbios, network groups, etc.). Another reason is Windows was so susceptible to malware that people were constantly installing junk (intentionally or not) that would phone home and they wanted some way to see what was connecting out.

If you simply don't install stuff that you aren't aware of what it is doing, then you really have no need for a firewall on a Linux desktop (or even a server for that matter). And most Linux distros do not ship with any listening services, thus there is no need for a firewall.

 

Why bother with all this, run a good av like AVIRA and run a limited account with the windows firewall enabled.

 

@wat0114,
Refering to your kind answers in post#18
I see it. Maybe dimly. Looks like I have to read it right to left and understand that Anywhere in the From column means local

Thanks much for showing how to do it from command line. Might come useful but I wish we had Kerio on Linux.

Just few more questions/confirmations, please:
(1) when the firewall is OFF, then outbounds are allowed. Incoming is no issue due to no listening ports, right?
(2) when the firewall is ON and DEFAULT_OUTPUT_POLICY="DROP", it means Drop everything trying out, unless some rules permit, correct?
(3) when the firewall is ON but there are no rules yet - does internet work or does the default-drop blocks everything?
(4) Looking at the last line and your description - is my reading of it in my language correct? because it doesn't sound right if refers to multicast or uPnP or SSDP maybe. I read the line as Allow out from my port 1900 to any IP, by TCP for IPv6. If really multicast, shouldn't From and To be reversed then? Arrgghh - it's not going to be easy if I were to use the firewall.
In Kerio speak, please ignore block vs allow, as I'm only asking about how these To and From columns work:
I block inbound from any remote port to 1900 local. Such rule is not needed due to how Linux blocks all incoming, right?, and
I block outbound from any local port to remote port 1900. This is where I don't follow that rule.
(5) SMB filesharing rules, I suppose, will have to allow out to Windows port 445 and/or 139 on subnet 192.168.xx.0/24, and inbounds from any port in Windows to anyPorts or someSpecific on Mint. Would I need to say which NetBIOS ports on Windows?

If you can't answer it all, that's ok, because, clearly, I'll need to google out some old tutorials about that style writing filtering packets.
OP's question about not being able to allow some of these ports by specific applications bothers me too. A little bit.

 

You're welcome!

1. If you mean off as "disabled' then yes, outbound is allowed but I think also inbound is allowed. If nothing is listening on any ports, then i guess it's not an issue.

2. Correct. Plus remember it's not an application-specific firewall; whatever rules are in place affect any and all applications seeking outbound network comms.

3. The default for UFW is block incoming, allow outgoing. Internet apps like the browser, email, torrent, etc... will be permitted.

4. Sorry, my bad. I typed in a hurry I should have typed it as:

Code:

sudo ufw insert 3 allow out proto tcp [b]to[/b] any port 1900

to instead of from.

5. Sorry, this i would have to research some first.

 

Yeah, that's it.
Behold the oh-so-confident "ima LINUX user" mentality.

About a year ago, across various forums, I posted to raise a concrete example to underscore the need for marshalling outbound connections on a per-application basis... and met a flurry of "oh yer a tin-foil hat paranoia monkeyboy" etc ad hominem attacks.

EXAMPLE:
When you boot into a "live" Kubuntu (or other distro) for a test drive, you're likely immediately curious whether your soundcard was properly detected. (That's a common sticking point.) When you browse & double-click to open a music file, the default pre-installed handler (music application, chosen by the distro) is probably pre-configured to connect to hxxp ://last.fm along with perhaps TEN other "partner" internet sites ~~ under the premise of "doing you a favor" (yah, "enhancing your user experience") by downloading album art and lyrics. As an added bonus, perhaps NOT by default, but... the app will scan your drive(s), cataloging your collection and, in the process, telegraphing every title to those partners.

In earlier posts I've also bemoaned the status quo of both KDE and Gnome ~~ interprocess use of their proprietary buses cannot be marshalled by the user. You might trustingly PRESUME each knewlyinstalledapp will not access your kOntacts data via the aKonadi bus, but you cannot CONTROL/enforce such. In fact, for most kApps nowadays, aKonadi (as well as nepomuK, motherlode datastore) is a DEPENDENCY. If you dare to criticize/question the status quo, and bother to wade through the tin-foil slinging... expect some lame-azzed position like "well, you can kompile from source and remove those dependencies if ya like".

Both tuxguardian and leopardflower avoided whitelists, marshalling instead based on pid
but yeah, a miscreant app might pipe its callouts through another currently running already-blessed app instance.

Yep, I'm chagrined by the brazenness with which Mint or Ubuntu would "enhance" my in-browser searches... and further chagrined by the default selection of "interconnected suites" of applications as well as the privacy-trouncing preconfigured "default" settings for those apps. Icing on the cake is the emerging trend: lightDM + webkit-enabled greeter (webkit instance launched prior to your user session ~~ beyond your reach, beyond your control).

heh, Beavis, pass the tin foil.

 

Can you provide this concrete example, as the example you mention below is full of ambiguities ?

probably, perhaps, do you know for definite or is this FUD ?

"perhaps not by default", again are you spreading FUD or do you know for sure ?

Which proprietary buses do you refer to ?

You can disable aKonadi.

What do you think we can't control (without any facts this again is just a FUD statement)?

 

Out of sheer curiosity only, I wanted to see if Windows media player "calls home", so to speak, with Privacy settings checkboxes all cleared, and the firewall logs prove that it does, indeed, broadcast to Netnames (on WHOIS IP lookups) Microsoft and Hotmail every time - without fail - I launch it to only the Playlists window.

I'm not saying this is necessarily bad, as they might be perfectly harmless querries, but only that it in fact does happen. Some people might be under the false impression that with its Privacy options all cleared, that wmplayer.exe is kept under wraps from the network. It isn't.