I have been running Linux off and on for special applications (program development, and network servers), since the kernel 0.8 days.

I am looking to finally upgrade my aging MS windows laptop, and would like to go with Linux as a fulltime desktop environment, but will not make the switch until I can find a credible Linux firewall.

Having been saved several times from attempts by malware to 'phone home' by an effective firewall, I will never again run a desktop environment which does not properly secure outgoing connections.

My very basic Win98 firewall (Tiny Personal Firewall) provides fairly sophisticated application level controls on network access. First it validates an application based on file size and a secure MD5 hash, then it allows it to connect in or out via the network ONLY if I allow it, then ONLY on the ports I allow, then ONLY to end point address or domains I allow, then ONLY using protocols I allow. This sounds complex, but thanks to a friendly 'would you like to create a rule' GUI that pops up when the firewall detects a new application trying to communicate, it only takes a few minutes to configure.

By comparison, every Linux firewall I have found is just a silly joke - providing essentially ZERO intrinsic security against spyware.

ZERO, nicht, nada, zip ...

I say this because all of the applications I have found so far are just lame hacks on the existing networking control filters, which err by making the STUPID assumption that you can manage outgoing security by blocking ports, or restricting protocols and services like you do to protect incoming access, while laboring under the asinine assumption that ALL APPLICATIONS SHOULD ENJOY ESSENTIALLY THE SAME OUTGOING CONNECTION PRIVILEGES.

I had high hopes for SUSE Apparmor’s application level network privilege limitations, but they do not seem to be able to provide the level of control needed.

see this link -

http://archive.cert.uni-stuttgart.de.../msg00004.html

The issue raised in the link above, is that many 'nix processes need to communicate through the loopback network interface (127.0.0.1) for local interprocess communication. Apparently, Apparmor forces 'all or nothing' limitations with regard to the network sockets interface, which makes it useless for outgoing connection management. You shut off everything, and the application is BROKEN, and if you do not, it can do any damn thing it pleases when it comes to sending your personal information out to the internet (is this perhaps fixed in Apparmor 2.3 in SUSE 11.1 ???)

Does anyone know of a Linux firewall which allows setting effective outgoing connection controls on an application-by-application basis?

- Delphin

Iptables can match all of that out-of-the-box, with the exception of the program's size/checksum. So in order to do this with Netfilter/Iptables, you'll need to patch. I did find this alternative (for checksum-based restriction), but the developer seems to have given up on that project a long time ago.

I'm not sure what patch are you talking about?

I don't see reference in the Netfilter/Iptables docs to filter rules based on the application program which is attempting access a specific domain, they just seem to have packet level/protocol level filtering that apply across the board to everything. If Firefox can talk to the internet, EVERYBODY CAN. (We're all one big happy family right?)

The problem here is that most nix nerds seem to be a bit confused about the fundamental differences between a network firewall (running on a router between two networks) vs. a personal firewall (protecting a desktop workstation).


From www.netfilter.org -

What can I do with netfilter/iptables?

• build internet firewalls based on stateless and stateful packet filtering
• use NAT and masquerading for sharing internet access if you don't have enough public IP addresses
• use NAT to implement transparent proxies
• aid the tc and iproute2 systems used to build sophisticated QoS and policy routers
• do further packet manipulation (mangling) like altering the TOS/DSCP/ECN bits of the IP header

I would agree that the above tools (though cumbersome as hell) may be useful for creating a network firewall (to isolate an intranet from the internet)

But, for a personal firewall (protecting a desktop workstation) the netfilter/iptables tools would seem to be almost useless. They can be used for locking out a few common incoming ports or services, but in a properly secured system, these ports would not have service daemons running on them anyway, and blocking a few silly common ports is meaningless as far a REAL security is concerned, because if even one outgoing port remains unblocked (lets say the one Firefox normally uses) then the malware can find it and connect out to the internet anyway.

There may be a way with a horribly convoluted script, to read PID, for running applications, look up the ports they are attempting to access and . . . No, I wouldn't wish that on my worst enemy.

Perhaps I missed something? Do you have a link to a SIMPLE example of a Netfilter/Iptables entry that will BLOCK all outside internet access for a SINGLE application? (while allowing local communication on the 127.0.0 domain for interprocess communications)

I am now looking at seLinux to see if such a global policy can be set up to allow access only to the local machine's 127.0.0 domain (to allow inter-process communication), then overridden for apps that really need outside access like Browsers, Email, and IM.

This is NOT a idle concern.

Consider the following scenario -

A wonderful new Multimedia Player "Foo Player" is released.

Without the knowledge of the rest of the team, one developer 'checks in' some library code that contains malware (as part of the MILLION PLUS LINES OF CODE comprising the "FooPlayer" and supporting codec libraries)

The malware code does the following:

(a) Scans the browser cache continuously in real time (using the permissions it gains because "FooPlayer" is a multimedia browser plugin)

(b) Finds Number Strings which resemble credit card numbers (it's easy to validate that they ARE credit card numbers using a simple, widely known algorithm)

(c) Sends your credit card info to an organized cyber crime group half way around the world, which then re-sells it to another group specializing in credit card fraud and identity theft (after which, they break into your bank account cleaning out your life’s savings)

This isn't as hard to do as you would think (LOTS of checked in 'open source' code never gets a code review by a second party. For anything coded in C or C++ remember they actually run contests from time to time for the most obscure obfuscated code, and the winners are truly unbelievable. Just throw in a lot of obscure pointers to code hidden in dereferenced 'data' blocks. Hell, the trick with C code, is to write something that someone else CAN figure out, writing stuff that is damn near impossible to figure out is easy. So, even if someone else on the team was working with the same code, the chance they would catch deliberately disguised malicious code is not great)


Now here is the really really really embarrassing part of the above scenario-

My ten year old supposedly totally non-secure version of Winblows 98 will STOP this attack dead in it's tracks.

Your cutting edge, oh-so-spiffy (I just can't believe how smart we all are) version of Unbuntu, or SUSE, or even Fedora, sporting the latest state of the art security goodies WILL NOT STOP THE ABOVE ATTACK!

THIS IS TOTALLY RIDICULOUS IN AN O.S. THAT CLAIMS TO BE SECURE!

Even if the above Netfilter/Iptables COULD be configured to stop the above attack (and I don't think it's clear that they can), the process is SO RIDICULOUSLY COMPLICATED AND ERROR PRONE, THAT THEY CAN NOT BE USED EFFECTIVELY BY 99.99% OF THE LINUX USERS.

For me, this type of attack is NOT Hypothetical, as I have seen it happen!

My Win98 firewall has blocked at least three attacks of the above sort that I know of. I know this because, I have it configured to pop up a window on unauthorized net access, and I have caught several apps that should NOT have needed to communicate with the internet trying to do so (and found out 3 or 4 weeks later that they were definitely malware when they finally started to show up in ClaimWin as TROJANS). TROJANS can do lots of nasty things, so when something like this happens, I reformat the hard drive and restore the full system from my last known clean backup.

Result – both my computer AND my bank account are still healthy after more than TEN YEARS OF SURFING THE INTERNET.

It is true that, in the case malware attack example above, Linux does have at least a few advantages. In Linux you might not have to reformat and reload your hard drive, because it’s harder for malware to break out and infect other system files, but I would probably do it anyway in the case of a known attack, just to be safe.

In any case, I’m guessing that not having to reload Linux would be small consolation WHEN YOU FIND THAT YOUR BANK ACCOUNT HAS BEEN CLEANED OUT, because your supposedly 'secure' O.S. failed to stop a malicious outgoing connection.

Bottom line – THIS IS IMPORTANT! This is the most common sort of cyber crime on the internet today!

So let me rephrase the question -

IS THERE A PRACTICAL DESKTOP FIREWALL FOR LINUX THAT CAN BE EASILY SET UP TO BLOCK UNAUTHORIZED OUTGOING CONNECTIONS?

None in particular. Iptables rules which allow you to match packets based on the checksum of the program that generated them sounds like a reasonable feature to ask for, so perhaps someone has a patch somewhere that gives Netfilter/Iptables that capability. Regarding the rest of your post, you don't really need to elaborate so much - we get what you mean, it's pretty simple, really. But yeah, I believe the answer to your question is "No".

For some reason you sound every bit of frustrated. You seem upset that the world isn't perfect. Please try to calm down.

Even with all the security measures Windows seems to try to employ, it still gets infected. Linux isn't like that at all in my experience.

Without needing to have your perfect firewall, you can have the security you need. Linux comes out of the box pretty locked down. Unless you do something as root, most of the normal binaries are read-only, with exception to anything that might be in your ~ directory. You can even mount your ~ directory with 'noexec' to keep everything in there from being able to execute. Once that simple little bit is done, you don't need your application-specific firewall. Now you CAN just use the iptables firewall to block by port/source/destination.

Use the proper tool for the job: snort with blocking capability (snort-inline)

Either that, or just block needless apps as a whole, but tools such as SELINUX should also work.

There is no ZoneAlarm-like tool for Linux, but it also doesn't need it (like the poster above me stated).

As stated above SELinux will do the job for you. SELinux uses MAC which has a policy that states exactly what the program is supposed to do and if it attempts to do something different from the policy it is killed by the kernel. There is ALOT more to securing your system then just installing a firewall. I have also been surfing the net for over 10 years and have not had an single incident to date...The only difference is that I don't run a firewall at all! If your machine is configured properly and constantly secured and validated then a firewall is just icing on the cake. Securing a machine is not a task it is a never ending process that has to be repeated on a regular basis. Secure > Validate > Pen-Test > Remediate > Repeat

I ran a colo'd server without a firewall for 3 yrs before even contemplating installing one. Basic hardening will get you far!

My thanks to Win32sux for the link to TuxGuardian.

TuxGuardian was indeed Linux’s best shot at an easy to manage outgoing firewall for Linux, and it’s a damn shame that this project seems to have been abandon.

Does anyone know of a Linux distro with TuxGuardian precompiled into the kernel? (even an older distro would be fine)

Apparmor seems to be useless at this point for network access management, and seLinux is too damn intrusive and MUCH too complicated for most folks to deal with.

To all those who have replied in this thread saying that the reason that Linux lacks this protection is because it’s sooooo secure that it doesn’t need it; thanks for confirming my faith in human nature; people never change.

More than a Decade ago (back in the heady Linux kernel 0.8 days) I was on a business trip to our companies San Jose software development lab, and decided that installing Linux on a Toshiba notebook I had with me would give me portable access to some much needed tools.

My plan was to install Linux on the Toshiba Laptop over our computer labs network by mounting the Slackware CD on a Sun Unix workstation in our lab, so I could then perform a network based install on the Laptop.

This trick was necessary back then, as most notebooks did not have CD Drives.

I found a parallel port Ethernet interface, then used my Slackware Install CD on another computer to quickly compile and test a floppy bootable Linux kernel that would support this Network interface.

Then things got sticky, because the local Sun UNIX Guru pronounced that this mount would require ‘Root Privileges’ which he refused to grant (reasonable if true, but the real truth was he was just a JERK who had already been embarrassed when I was able to get some things done for our project on a $400 surplus PC running Linux that he had NOT been able to accomplish on a $40,000 SPARC station)

I pointed out reasonably that this need not trouble him, since NFS file mounts were currently totally insecure in SUN UNIX (true at the time).

He of course EXPLODED and pointed out that the SUN Workstations were not ‘TOYS’ like my silly little Linux boxes, SO OF COURSE NFS IS SECURE.

So I went ahead and mounted the Slackware CD from my mini-root Linux floppy and preceded to install Linux right in front of him.

Then I pointed out that his being so concerned about root privileges for his work stations was a little silly since anyone who had access to the lab could log in as root any time they pleased.

He started to turn Purple, and temporarily seemed to have lost the power of rational discourse, so I simply went over to one of his unused servers, asked if it was ok to reboot it, gave it the magic multi-finger SUN secret hand shake to bring it up in Single-User ROOT mode.

I pointed out that on newer SPARC stations, SUN now had an option to disable this trick, but even then, all you had to do was to insert the OS CD, and bring up the mini-root installer and exit to root and mount the file system.

His response was to label me as some sort of dangerous ‘hacker type’ and try to get me banned from the lab.

Fortunately, one of the other programmers was a witness, and interceded with the facility manager, who instead asked me to do a security audit on the lab.

I pointed out that such an audit was not needed, I could give him an answer immediately, and asked if he would care for a demo?

I logged my now Linux bootable laptop onto the network, mounted the root partition of his workstation via NFS, renamed the password file, created a new empty password file, and logged in as root.

Elapsed time – about a minute and a half, most of that spent in booting the laptop into Linux, and logging in.

You see, the problem was this - early implementations of SUN NFS were TOTALLY INSECURE, but created the ILLUSION of security, with a stupid HACK whereby the SUN workstation originating the NFS connection would honor the remote systems workgroup and other privilege limitations.

Security on the ‘honor system’ – stupid – REALLY STUPID.

The Linux OS had not implemented this silly hack, so it could do any damn thing it pleased after mounting the remote SUN NFS file system.

SUN has long since fixed this and other security holes, and these days I am sure they build a fine product, but back then, if you didn’t take pro-active steps to fix a lot of holes, security was a JOKE.

Sorry to rehash this ancient history, but that was my first experience with arrogant nix nerd twits, who were convinced that UNIX was “The Most Secure OS” as a matter of religious faith, and so left themselves open to any number of ridiculously simple attacks.

The security of Linux systems to rootkit exploits has been strengthened over the intervening years, and I would now give Linux about a B minus grade on root access (as long as you have things properly locked down, which is NOT the case with many distributions).

On the other hand, as I have already stated, the current security level relative to spyware sending your credit card number (or other private information) out to the internet is essentially ZERO, which is a failing grade any way you look at it.

Those who have pointed out that “there isn’t much of a problem”, because Source Forge and others are doing a fairly good job of keeping malware out of the Linux software repositories, are essentially arguing for the same silly source-side ‘security on the honor system’ HACK that screwed over the security of the early SUN NFS implementations.

In other words, instead of making sure that malware can’t do any damage by gaining unauthorized access to the internet on the target system, we will just waive a magic wand so everyone in the world suddenly becomes honest and only thinks happy thoughts, and thus control the problem at it’s source. Yeah, right!

I know it's a little hard to belive that Linux doesn't have any protections against spyware.

After all, if Linux not secure against spyware, why haven’t there been more attacks?

Looking at it from the prospective of the Jerks who write spyware, I can think of several reasons, NONE of which have anything do with how ‘secure’ Linux is -

• Linux is, at best 2% of the desktop market, why bother?
  
• Of that 2%, a good percentage probably run Linux because it doesn’t cost anything, and these cheap bastards most likely don’t have anything left on their credit limit anyway, so why steal their credit card number?
  
• The Linux community has a high percentage of no-life computer geeks who have nothing better to do than work 24 hours a day on tracking me down and reporting my name and address to the authorities.

(Please Note: these are representative of the kinds of things the creeps writing spyware might be thinking, NOT the opinions of the author)

Obviously, as Linux’s market share increases, and the dynamics and demographics of the Linux community change, there will be greater incentives for spyware attacks, and given the TOTAL lack of protection against malicious outgoing connections in Linux, this will be BAD.

So, don't let the lack of interest in these attacks at the present lull you into thinking that Linux is secure against spyware, IT IS NOT!

I do apologize however, for seeming so agitated and strident. Write it off to my frustration in seeing that, after considerably more than a decade, the UNIX community seems to be just as arrogant and overconfident about security as ever.

I should have focused on the glass being half full vs. half empty, and taken solace in the feeling of continuity provided by knowing that folks haven’t changed in all these years

I do think it would be great if this type of desktop application was available for GNU/Linux. I don't really understand why developers haven't shown any serious interest in it. I don't think this type of application is necessary, per se, but it would probably make the whole firewall experience a lot nicer for newbies. Additionally, it would let non-newbies get functionality which, although currently existent, requires a lot of work. Seems like we were off to a decent start with TuxGuardian, not sure what happened.

That said, what I do whenever I want an iptables rule to apply only to a specific application is that I use the owner module with the --uid-owner match. I make the application run as a specific non-root user specially created for that application, then tell iptables to match accordingly. For example, on my parent's box I force them to use Squid (which runs as user squid), and I don't want them to be able to use the Web in any other way, so I use something like:This gets the job done, making sure only Squid is allowed to send packets out to ports 80 and 443. But being able to specify a checksum for the program instead of a username would be kinda cool too, maybe with a hypothetical match called --sha1-owner (which would let you specify the SHA1 hash of the program which generated the packet), like:From a security perspective, it might not make any difference (as both the UID and SHA1 methods would require root privileges to bypass), but the SHA1 match does lend itself better toward being implemented in a GUI firewall application, as it wouldn't require any changes be made to the system (such as creating new users with non-login shells, etc).

hi guys,

hi delphin,
wow - this topic is very2 interesting.

you did bring up a valid view - and it has been my long thought - thank you for remind us all to stay aware with those kind of threat you have mentioned (browsers, software packages etc).

but - i also agree with slimm - that nobody is perfect, and security is a never ending process - so we must act and review our (own) policies about our (own) machines, no matter how and again, we must think the way "some" think or at least leave those "some" alone - just dont disturb them, because we dont want to be disturb either. Your enemy's enemy is your friend

just a thought.

cheers

@Delphin:

I don't get it. You come in, pretty much bashing the Linux community about how insecure Linux is. You've provided pretty good examples where we could perhaps use improvement, but your tact needs work.

Linux IS more secure than Windows out of the box, due to its security methodologies, by comparison to Windows. Most of the times I've heard of a Linux box compromise was because of weak passwords and lazy/misconfigured services.

For what we don't have in actual applications, we have in other ways. For instance, win32sux has a good method for blocking everything except for squid. It just takes time to research and experiment.

As far as you using your boot CD to obtain access to the server, note that you had to have direct local access to the hardware to make that happen. It's not like with Windows, where you could easily access the drives over the network with c$ (standard hidden share).

And going on to your application specific firewall. If you're so hell-bent on why we don't have one ... Frickin' WRITE ONE! If you can't write one, don't come crying about why don't we have one. We are a Linux C-O-M-M-U-N-I-T-Y, not a Linux B-U-S-I-N-E-S-S. Only a very very small percentage of the community can actually code. Most of them have jobs and family, and not much time otherwise.

Geez.

First of all, sorry if you didn’t like the tone of my post, but please, if you are going to quote me and cite examples, you might make a little more of an effort to read what I wrote and quote me correctly.

In regard to the poor security example I gave; I pointed out that I was very quickly able to GET FULL ACCESS TO A SUPPOSEDLY SECURE SUN OS BOX's ENTIRE ROOT FILESYSTEM OVER THE NETWORK, with nothing more at my disposal than having a root account on MY OWN Linux laptop (which was not the same as the password on the box I was accessing).

Sure, you can also gain access with a boot CD, but doing it over the network without the password was the more serious example.

In fairness, this was years ago, and SUN OS is almost certainly more secure at this point, but I think it is fair to say that this was a bit WORSE than the C$ admin share examples you gave for NT, XP, etc, because the Windows default shares WILL NOT WORK if the systems have different unique admin passwords.

If you want optimism, the most optimistic I can be at this point is to say that when Linux has a larger percentage of the desktop market there will be a LOT more attacks (because the only thing preventing them now is LACK OF INTEREST, not security), but then folks will start to wise up, there will be better security tools, and things will improve dramatically.

Till then, don’t fool yourself, it’ll just get you in trouble . . .

-Delphin

This sounds like a perfectly reasonable assumption, yes.

Lack of interest on the part of the bad guys could definitely contribute to the much lower attack numbers seen by GNU/Linux desktop users (relative to Windows desktop users). What that tells you is that the threat levels for GNU/Linux desktop users are lower. Consequently, the overall risk on a GNU/Linux desktop solution is lower, which greatly helps the person in charge of the security process. This is pretty straight-forward. That said, making claims that GNU/Linux's design plays absolutely no role in this phenomenon is not as straight-forward (so don't try to make it sound like it is).

Security tools are a direct response to security threats, so yes, what you say is absolutely true. As the threats to GNU/Linux desktops evolve, so will the tools to mitigate vulnerabilities. This is the way things are on any operating system and should not come as a surprise to you or anyone else.

If you feel that the current threat landscape for GNU/Linux desktops calls for a GUI firewall that lets users create access permissions for specific programs based on their hashes, there is absolutely nothing stopping you from writing one. You could be one of the first to "wise up" and show everyone what they've been missing out on. This is one common way F/OSS is born, really, I encourage you to do it.

Linux users tend to use applications that their distro's supply, rather than running an installation program from a binary installer that they downloaded from a web site or purchased in a store. This is a behavior difference that helps prevent malware from infecting your computer in the first place. Even in windows, blocking outgoing traffic should only be used to identify malware. Blocked outgoing traffic is not protection. It is a game-over alarm. Besides, learning legitimate traffic can be difficult. The alerts for outgoing connections tend to indicate the dll used. Malware can use a legit dll illegitimately. The md5 hash of the dll won't change because it wasn't modified. If you block unexpected traffic, how do you know that your credit card information isn't being transmitted inside traffic you do expect? Another problem with add on firewalls in Windows is that well written spy ware will simply hack your firewall firewall program or md5 sum database to evade detection. Or simply temporary disable it. Once a program gets running with admin rights, it can do anything.

With much fewer or no non-os binaries running in Linux, verifying the md5's of your system's files is much easier to achieve.

The link you posted is for openSuSE 10.3. Perhaps there have been improvements to AppArmor in the meantime.

You can have a cron job run netstat --program periodically and look through the logs. You can use netfilter to log traffic. You can run an IDS external to your computer.

Verify the packages in your system. Rely on your package manager, and break the habit of installing binary code from unvetted sources. Keep your packages up to date. Keep your routers firmware up to date. Disable uPNP in the router. Use a strong username/password. Use a random key for WPA if you use it. If you use ssh, use public key authentication and a long & strong passphrase protecting your private key. Don't log into KDE or Gnome as root. Study your logs. Have the root security reports forwarded to your account and take corrective action if necessary. Run root kit hunters regularily. Learn to detect & prevent malware infections before they happen, not after.

Yes, there are a lot of habits to learn, but the same sort of things should be done if you use Windows as well. Never run as Administrator; only share what you need (e.g. don't share your C: partition), use file access controls, don't offer any world writable shares, etc. If the proper measures and habits were taken using Windows, there would be only a handful of viruses for Windows instead of hundreds of thousands.

In your scenario of a contributer submitting malicious code to a project, it would have to get by the people who accept patches. The code is accountable to the author and an programming trying it will get out'ed. He won't be able to code again, and may even have a problem getting a programming job. There was a perl programmer who had a non-malicious call home "feature" in a library he submitted to CPAN. It was for research reasons, and didn't submit any personal information, but the library was pulled immediately. While this isn't a few lines of code in a project with a million lines of code, it was a few lines submitted to the largest library repository there is. Besides, your scenario could happen with commercial software that is thought to be legitimate and legitimately calls home for updates.

I'm not saying that I can't be attacked because I use Linux. I'm saying that there are many layers to security. My reliance on packages that my distro supplies makes spyware much less likely than in Windows. I do worry about spyware scripts running in the web browser, so I use the noscript plugin in Firefox. I close the ssh port in my NAT router when I don't need it. I update the routers firmware. IMHO, live attacks from humans, are far more likely than viral type infections. A different OS has a different attack surface. There are things you can do to make Linux even more secure that it is out of the box.