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.

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.

Click to expand...

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

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

Click to expand...

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.

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!

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?

Click to expand...

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

No, it isn't possible. It also isn't part of the traditional definition of a firewall. It is something that Microsoft came up with fairly recently in an attempt to paper around their fundamentally broken OS security problems. It is considered foolhardy and unworkable in the Linux community because one program that isn't allowed can simply run another program that is and gain access that way.

If you don't like what a program is doing on the network when you run it, then don't run that program.

Click to expand...

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."

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).

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

Click to expand...

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 is considered foolhardy and unworkable in the Linux community because one program that isn't allowed can simply run another program that is and gain access that way.

Click to expand...

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.

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).

Click to expand...

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.

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).

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.

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.

Click to expand...

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.

@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.

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

Click to expand...

You're welcome!

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?

Click to expand...

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.

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.

Re: How to set up application level firewalling?
Postby craigevil » 2012-07-31 02:47
closest thing you can get to an application firewall is iptables+squid and maybe throw in dansguardian as well. Or moblock/PeerGuardian.

The entire reason for application based firewalls in Windows was to block apps that phoned home or spyware. Nothing like that on Linux.

Click to expand...

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".

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.

Click to expand...

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).

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

Click to expand...

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

inka said:

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 ~~

Click to expand...

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

inka said:

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.

Click to expand...

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

inka said:

~~ interprocess use of their proprietary buses cannot be marshalled by the user.

Click to expand...

Which proprietary buses do you refer to ?

inka said:

You might trustingly PRESUME each knewlyinstalledapp will not access your kOntacts data via the aKonadi bus, but you cannot CONTROL/enforce such.

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.