Hi there,

I have several connected questions relating to the Linux firewall (iptables/UFW/GUFW) which I'm hoping someone might have the answers to. For info, I'm running Mint KDE 17.2.

1) Despite having switched on the firewall post-installation (GUFW confirms Status: ON, Incoming: Deny, Outgoing: Allow), I have since installed Deluge and Skype, both of which as far as I know use P2P, but both which work without my having had to add rules through GUFW to allow them access.

This is confusing me greatly - why have these applications been allowed access when they should have been blocked by the firewall?

2) I have installed XAMPP for Linux, purely for testing locally-stored PHP-based websites, and am concerned that this might lead to exposure if I'm running Apache while connected to a public network. Should this be a concern to me and, if so, is there something I can modify in the firewall to restrict XAMPP to local access only?

3) One of the main reasons that I used a firewall in Windows before moving over to Linux was to have control over each application's access to the internet. Some applications obviously have need to access the internet, e.g. Firefox, Dropbox, Skype, but many applications have no need and so it was useful in Windows to use Comodo (the older friendlier version) to trap an application's first attempt to access the internet and block/allow it accordingly from then on.

I can't find a similar application-based firewall for Linux. Does such a beast exist?

Many thanks in advance.

Hi...

I've never tried them but I wonder if "fwbuilder" or "shorewall" in the (Ubuntu/Mint) repositories might be a good alternative? You can find the website for Shorewall here along with a newer stable version of the software for download.

Also, back in February, I also had a question that involved GUFW and although it was of a different nature, perhaps you might find the links other members gave me helpful. You can see the thread here.

Let us know what you find out...

Regards...

I get what your saying about skype not have access to you give it in the gui ufw. but my impression was that if YOU initiate a skype session that is ok per the UFW.


but lets say someone trys to remote ssh into your linux pc. the UFW firewall SHOULD reject that.
unless u create a firewall rule to allow it.

Firewalls are sets of rules that govern whether network traffic can be allowed to pass or not.

The norm for a firewall installed/configured on an end-user device (such as a computer) would be to disallow any incoming traffic that doesn't meet one of the two following rules: replies to existing outgoing sessions; and traffic that is destined for a service running on that machine (Apache, for example) and it has been explicitly allowed in the rule-set.

Obviously firewalls can be much more complicated than this, but this is the default position for end-user firewalls.

The first "allowing incoming traffic" rule: "replies to existing outgoing sessions" is the possible reason for your P2P software continuing to work - they make outgoing connections and any replies to them are allowed. This is the same reason why you can still browse the Internet behind a firewall - Google will necessarily need to send the results of your search back to you, so it's a set of incoming packets, but they're flagged as replies to an existing session that was initiated from your side of the firewall, so they're allowed.

cool so i am correct that it WILL block unsolicited requests while letting REPLYS such as a webpage from your browser through?

fyi this is the 1st linux forum I have joined and I am LOVING THIS!

You are absolutely correct. That is the default behaviour for end-user firewalls.

And it's great to hear that you're loving this forum. I find it's friendly and a great place to ask the kind of questions that'll earn you a good grilling in other places. That's kinda why I liked it, joined in 2001 and keep coming back!

Many thanks for your replies!

@ardvark71: I had a look at both fwbuilder and shorewall but, as far I can see, they don't provide the sort of application-based functionality for which I'm looking. I've had a scout around and the only application that I can find which does, without having the complexity of AppArmor or SELinux, is a fairly new application called "Doaune" (http://douaneapp.com/). The setup is currently quite complicated though, probably beyond my present level of expertise. Dedoimedo discusses the application here: http://www.dedoimedo.com/computers/l...-firewall.html. So, it looks like I will have to wait. Thanks for the link you provided.

@akiras rain, @Thymox: Good to know, thanks. That explains everything. I still am concerned as to how public my XAMPP Apache server is though. Perhaps I need to ask that question in a XAMPP forum?

If you're running an Apache server on your machine, then it should accept incoming packets on port 80 (the default http port) unless you've configured your XAMPP otherwise. If you are running a firewall on your machine itself (as opposed to on a network device, such as your router) that has not been configured to allow incoming traffic on port 80 (or your chosen port), then nothing other than internal traffic (ie that which originates on your machine and is destined for you machine) will reach your XAMPP Apache service (and even then, internal traffic isn't a given, depending on how you have it set up). The only time you can expect external traffic to get to your XAMPP Apache service is if you allow it in your firewall rules, or you don't run a firewall. The easiest way to check would be to use another device connected to the same network as you, and open your XAMPP Apache server machine's IP address in a browser: http://192.168.1.1 (as an example).

Which brings us to this: if you have set it all up and it allows incoming connections then, without delving into the deep and dark arts of specifying which incoming connections you want to allow, it will allow anybody to connect.

If you've set this up purely to work as a "development server" and you don't need anyone externally accessing your site/pages, then just do a quick check (get another machine and try connecting, as above). Chances are the firewall will be doing its thing and will block the incoming connections fine. If you need to access your internal-only Apache service using domain names, then simply edit the hosts file on your machine and point said domain to 127.0.0.1 - so if you're currently working on a new website for www.abc.info then you'd edit your hosts file and add 127.0.0.1 www.abc.info. This way whenever you open www.abc.info in a browser, it will point to your internal ("loopback") IP address, and your XAMPP Apache should pick it up and viola.

You're welcome, although I think I misunderstood what your needs were. I didn't realize until now what you meant by "application-based functionality." I hope you are able find something that works well for you.

Regards...

@Thymox: Many thanks indeed. I haven't manually configured iptables since installation of my operating system, but it would still be good to be assured in case some other program has done so. I'm not in my usual location at the moment, so the only opportunity to have to network my laptop to another machine in order to test whether unsolicited incoming packets on port 80 are allowed is to directly connect it to a MacBook. Do you know how this can be accomplished? I've found some tutorials on the internet but they seem to be concerned with the sharing of files and folders, not quite what I would be aiming for.

Thanks for the info on XAMPP. I've been running XAMPP purely as a development server using virtual hosts for a while now and it works like a charm.

@ardvark71: Cheers!

Just purely for personal tastes I suggest learning at least the basics of IPTables instead of playing with with one of the GUI FW front ends. You'll learn a lot more about what is passing on your network that way and how it works. I'm no IPTables guru. But it's kind of like my spanish: I can read it better than I can "speak it". In other words I can read a rule and follow it, and write basic ones, but for more complex ones I go get them pre-made from reputable sources. And there are tools that help you manipulate IPTables directly, through scripting, instead of clouding what's going on behind a GUI. For various uses (not all for end user FW, some for NTFW) I like IPKungFU for end user FW management, fwsnort for NTFW management and if you're setting up a headless server the WebMin interface has a nice FW front end in it.

Personally I don't like UFW or GUFW. I understand why they do what they do and I understand that a lot of people starting out need someone else to make some assumptions for them. But I build complex stuff that they tend to break without a lot of time and effort spent configuring them.

I'm also an ultra paranoid security nut. I believe *everybody* should run a minimum of at least an SMB grade gateway. You can build one (for less than 5 users) out of a P4 w/ 1GB RAM for about $60(US). I use IPFire to run mine and it is a *great* project. It has a GUI FW or you can use IPTables directly. You can segregate your NT in to up to 3 subnets. You can put a NIDS and a transparent AV proxy on it and so much more.

In your scenario it would have a lot of uses. You could put the server on another old junk machine instead of your main machine. (Old SMB XP servers make *great* home *nix servers. I can get them in my area for $20-50.) That would mitigate any compromise of the server, so that if it does get hit while you're learning then at least they didn't get in to your main machine. You could also drop it physically in to the DMZ zone. That way you're not exposing your LAN to the outside world. And a gateway / DMZ will give you much more granular control to set up who can or can't access the server. It will also help you learn more about how servers and networks really work by forcing you to learn how to work across different subnets. In the real world servers are not on your local machine.

In so far as local machine application level firewalls go: You won't find one b/c they are not needed for *nix applications. Doze and *nix see the world differently. Doze wants to spit out as much info as it possibly can. *Nix only broadcasts what actually needs to be broadcast; their respective applications follow the lead of their OS. On doze you need an local app level FW to stop everything on your system from constantly blabbering to the world. On *nix you don't. The exception is when you start doing stuff like using WINE to install doze programs. At which point you then need to either manually secure it in the local IPTables or secure it in your gateway FW.

And on the subject of Skype: It (and many other things) work b/c it falls,in IPTables, under the category of "established" connection. In other words you initiated a call (and I don't necessarily mean just a "phone" call w/ that term) that was broadcast to the world and requires a reply from the world to work.

Hopefully this will get you started in the right direction.

Google is your friend.

Good luck.

If you are motivated enough to actually understand iptables instead of only using their front-ends you can finetune application based access very easily.
E.g. you can group applications into specific categories and allow, limit or refuse internet access based on which group is used to run the application.

Example to run a specific application without internet access:

1) Create a group called no-internet and add your user to it.
2) Use the following rule in your iptables script:
3) Run the application with the following command:
I.e. to run firefox without internet access
Note that it might be possible to include an iptables rule as per 2) through UFW or similar, but I can't speak to that since I have never used any of these frontends. I always considered it preferrable to actually learn what's happening under the hood, as others suggested.

You should be able to read your firewall cfg (google for the location).
Try
to see the current settings. That's a root level cmd so use that or sudo (for Mint I believe).