Part 2 – A more advanced firewall configuration
The first part of this series of articles covered a basic firewall setup for desktop user needs, including FTP, HTTP, HTTPS, and Email with IMAP and SMTP. In this (second) part, I’ll now cover how to create a more secure firewall than the one just covered. This will cover rule deletion and creation, blocking unauthorized inward connections (not accounted for the in first rule set) and blocking outbound packet in a more strict fashion. The third –last and final– section gives a quick run down of the advanced rule set, and highlights the concepts of allowing and blocking IP addresses, allowing free access of ports per app, firewall logging, editing of ufw files, and –finally– presents a couple of caveats –such as associated with pinging.
Notice that in the above example, the DNS port did not have to be reserved, and note that it’s not the tightest firewall configuration, either. Testing IM (on Debian Lenny). Empathy (2.26.2, with telepathy “guts” from unstable), aMSN (0.98.1-1), and Pidgin (2.6.4-1) confirmed these IMs still get through to the MSN and GMail services, despite that IM used ports that are not assigned as open –although these services are less stable than if their official ports are open. A more secure setup considers two aspects, 1) port server destination (“in” or “out”) and 2) does not to allow out-going communication if not already considered in the rule set (with the ufw default “deny out to any”).
To make use of the prior scenario, rules must be entered with the word “out” within the command –therefore rejecting communication initiated from outside (even if through open ports labeled out). Strictly use “out” (instead of “in”), unless there is a specific reason to set a port to “in” because “out” is safer. “out” curves attacks that start from the outside –although this is of little consequence if you have malware installed that makes use of open ports cleared for initial outward bound packets. The following is an example of the mentioned syntax.
# ufw allow out 53/udp
What’s great about the “out” and “in” functionality is that this effectively turns ports unidirectional. Let’s say (for some reason) a port is open for inward packets, then outward packets through the very port will not traverse. Even general open ports submitted (without “in” or “out” specification) will not have packets traverse –probably because they are auto-magically applied as “in”, under these conditions. This added layer of security is not found on run of the mill firewalls, and certainly not default in ipfw in OS X.
First of all, make sure ufw is enabled and set the unsolicited incoming default to deny.
# ufw enable
# ufw default deny
You can see an ordered list of your rules with the following.
# ufw status numbered
The numbering is intentional as rules are used in that very order. After creating the initial list, you can insert rules with this syntax,
“ufw insert 1 allow out 53/udp”
where “insert” tells ufw of what you’re attempting and “1” (could be any number) corresponding to the ordinal you want a rule to take on, meaning it’ll be processed in the listed order from top to bottom (from 1st to last).
Delete rules of previous example (from previous article)
If you created a primitive rule set like that in the first section of this article, delete it. Although this section will not delete the entire previous rule set, it demonstrates how to do it by example. The previous rules could be deleted and cast again in two passes, but first take a look at your rules with the following command. It’ll list out the firewall rules.
# ufw status numbered
Now let’s focus on deleting one particular rule. Note there are two forms of syntax for deleting a rule. One, for deleting rules that don’t specify packet direction (a “general allow”), as with the rules in the previous firewall configuration.
# ufw status numbered
 21/tcp ALLOW OUT Anywhere
# ufw delete allow 21/tcp
And there is another –although similar– deletion syntax for a rule that does specify inward or outward communication (whose rule creation is covered in the next section). Note that contrary to the general rules, these do have brackets at the end of the line containing either “in” or “out” (as displayed by the output of the status numbered command). Let’s say the one rule that needs to be deleted is the following. ie.,
[ 2] 21,80,443/tcp ALLOW OUT Anywhere
The above requires …
# ufw delete allow out 21,80,443/tcp
There is mention of “rule deletion by corresponding number” on the ufw ToDo list. So rule deletion will become uniform in the future. (It already has, since of at least version ufw 0.30.1-1ubuntu1 on Ubuntu 11.04, Natty Narwhal)
Rule set creation
Enabling basic connectivity (in two lines)
Note: The last line in this example is going to prohibit anything not specifically allowed up above (on the rule set list). Thus, order is important. In fact, that’s how the list is processed, from above to below. The consequence being, if something has been denied access early on (above), don’t expect to (re)gain access later on (farther down) on the list.
As previously mentioned, all udp or tcp port rules could be issued in two passes, although this article will use multiple lines for each protocol. Two rules would put all udp ports on one line and all tcp ports on another. ie.,
# ufw allow out 53/udp
# ufw allow out 21,80,443,587,993/tcp
Successfully added rules will output “Rule inserted”.
In the first line above, 53/udp is needed to allow for DNS requests (whereas it wasn’t necessary in the previous rule list in the previous article). I assume this is not needed if you install your own localhost DNS server. The second line guarantees access to ftp (21), Internet (80 and 443), SMTP mail (587, and 993 for SSL) services.
Instant messenger concerns and rule creation
Enabling basic instant messaging (in one line)
As mentioned earlier, in testing IM or GTalk/XMMP VOIP connectivity, no serious problems manifest with the earlier simple firewall settings (meaning they get through well enough despite not assigning ports for IM). In contrast, IM connectivity issues will arise with this more prohibitive firewall configuration, specifically with the tested services –MSN and GTalk/Jabber. This is not a bug. It’s a feature, because if connectivity problems exist –it’s a sure tell sign the firewall is functional. Still, further configuration is needed to let IMs pass through this more prohibitive firewall.
GTalk and Jabber (XMPP) both use 5223/tcp. 5223 is unofficial for Jabber, whereas 5222/tcp is official. You can select one over the other in your choice of program, but it seems that 5222/udp is necessary for VOIP connections as it’s default for signaling and RTP. Indeed –from readings on admins trying to block IMs– GTalk (which is Jabber[Jingle] based) seems to use 5222, 5223, 443 and 80 ports (all tcp). Furthermore, Jabber file transfers occur at 8010/tcp.
To take care of all Jabber IM (including VOIP and file transfer) connectivity issues in one line, including 1863 for MSN text messaging because it’s udp –as is Jabber, issue the following. You can throw in an IRC port, too, if you use IRC (ie., 6667 or whatever your particular program uses).
# ufw allow out 6667,1863,5222,5223,8010/tcp
Update: Google states that Google Talk (instant messenger and VOIP) does not need both 5222/tcp and 440/tcp –just one or the other. I prefer to have both ports assigned for the RTP reason stated earlier, but your mileage may vary. The server is talk.google.com, if one is wondering.
Enabling instant messaging file transfers & VOIP (in two lines)
To configure MSN, note that file transfer and voice ports are both udp and tcp. Remember, MSN text messaging (1863/tcp) was thrown in earlier with Jabber, so only file transferring (6891-6900) and MSN VOIP (6901) need be set up. Ranges, such as 6891-6900, are specified with a colon as in 6891:6900. Ideally, one would need not specify a protocol because this port range is both udp and tcp. Unfortunately, inputting ranges without a protocol is not allowed.
# ufw allow out 6891:6900,6901
ERROR: Must specify ‘tcp’ or ‘udp’ with multiple ports
At least, one way to circumvent this is to ascribe a separate line for both udp and tcp.
# ufw allow out 6891:6900,6901/udp
# ufw allow out 6891:6900,6901/tcp
Adapt these principles in handling ports for other programs/protocols.
Note: Don’t leave a space between commas and port numbers. The insert command works with ranges as with other commands. Remember to specify a number when doing so.
Although the above has been tried and tested successfully, there are articles suggesting the opening of port 5269/tcp to allow GMail users access from internal gateways, but this is using Office Communicator on the Windows side (Office Communications Server 2007).
You should enable firewall persistence, so that the firewall is automatically enabled on reboots. If you started out with my previous article, you’ve already made the necessary adjustment. Regardless with which article you started, the file /etc/ufw/ufw.conf should have a “yes” as in the following example.
#set to yes to start on boot
Make the necessary modification with your favourite editor.
Last line of the rule set
As suggested at the start of this example, blocking connections (not allowed on the rule set) is not accounted for the in the first firewall rule set (mentioned in the first installment of this series of articles) –or as of yet in this set. Take care of that problem with the following.
# ufw deny in to any
That will show up under the numbered rule listing in the following fashion (“sudo ufw status numbered”).
“Anywhere DENY IN Anywhere”
The above rule should be last (at the very bottom). If for any reason it eventually makes it farther up on the rule set list (such as by having added another rule recently without the insert command and consequently having it take the last place), delete the (above) intended last rule.
# ufw delete deny in to any
And then simply add it again. It’ll become the last rule once again.
# ufw deny in to any
Note: You could also delete the ill placed rule and then place it into proper sequence using the insert command (two commands).
Last but not least, always restart ufw after making changes.
# ufw disable && ufw enable
Now if all this seems too contorted to go through in every install, an executable list can easily be made listing all your the firewall configuration commands, but I’ll leave that to your discretion. A sample script is illustrated below. It’s best to be root to execute the below script for reasons explained below in my May 7, 2012 entry. Ubuntu users: to gain root privileges, pass “sudo su” in a terminal.
# Complex firewall
# Allows remote DNS requests, not needed in simple rule set
ufw allow out 53/udp
# FTP, HTTP, HTTPS, SMTP, IMAP
ufw allow out 21,80,443,587,993/tcp
ufw allow out 6667,1863,5222,5223,8010/tcp
# VOIP & file transfers
ufw allow out 6891:6900,6901/udp
ufw allow out 6891:6900,6901/tcp
# Last rule: Blocks connections not allowed in rule set
ufw deny in to any
ufw disable && ufw enable
The last line informs if ufw is enabled to start on boot-up.
The first section covered how to setup to meet a basic desktop user’s firewall needs, these being FTP, HTTP, HTTPS, and Email. This (second) part covered how to create a more secure firewall than the basic setup, rule deletion and creation, and port server destination (effectively blocking unauthorized incoming connections) –as well as outgoing in a more strict way than previously covered.
by Maurice Cepeda
UPDATE: August 21, 2010
This ultra secure firewall settings (presented in this article installment) seem to block the downloading of additional repository key signatures from line command. For example, to install bleeding edge Scribus from the Scribus Team repositories (see <http://www.scribus.net/?q=debian>), the following does not work.
gpg –keyserver wwwkeys.eu.pgp.net –recv-keys EEF818CF
Unless you figure out which port apt uses for this (and open it), you can momentarily turn the firewall off and perform the above command. If you’re behind a router, you should be fine as most routers have firewalls, and would make it the moving target scenario anyway.
You might also get away doing things the GUI way (Synaptic), if that’s your cup of tea –but I don’t recommend it as I believe that uses apt-get (and you’re not supposed to mix aptitude and apt-get use –although, these are signature keys and not packages). On the other hand and as of recent, the testing version of Scribus seems to have been added to the Debian repositories as (if memory serves) scribus-ng.
UPDATE: January 25, 2011
I’ve recently noticed the same issue (as above) with a firmware download in regards to an Ndiswrapper install.
UPDATE: September 3, 2011
I’ve also noticed connectivity problems with downloaders such as axel and aria2c. I’ve already written a hybrid firewall in an attempt to address the issue. I’ll report back if this is successful.
UPDATE: September 6, 2011
The above issues can be solved simply by replacing the
ufw deny out to any
ufw deny in to any
which brings one’s attention to the fact that you may want to use the more strict setup (the one with issues) for server units, and the lax one for desktop stations.
I’ve changed the manual to reflect this change in the last line. As of at least version ufw 0.30.1-1ubuntu (and now using Ubuntu), this seems to have become necessary –even for Internet surfing.
UPDATE: May 7, 2012
The axel and aria2c had nothing to do with the firewall but with using the system settings to use a local proxy. So no worries, unless you route all your traffic through the system proxy. If you want to use a local proxy, but avoid these sorts of issues, use application specific utilities to select your proxy (as in Firefox or SeaMonkey proxy settings).
In fact, I’ve wondered if all the problems I’ve had were mis-attributed to this firewall rather than local proxy system settings. What does this mean? Try the prohibitive firewall first (using “ufw deny out to any”), then adjust to accommodate any problems that creep up (unless you need to send all your traffic through a local proxy, in which care you should be willing to deal with issues as they appear). I’m sure to try out the prohibitive rules again myself and report back. If they pan out, I’ll make the appropriate changes to the instructions.
Nope, it seems that, at least version 0.31.1-1 of ufw really messes up connectivity with the “ufw deny out to any”. So stick to “ufw deny in to any” as in my article in present condition.
The other oddity that this version of ufw gave me –at least on Ubuntu 12.04 LTS (Precise Pangolin)– is that you can add and delete rules and even turn the firewall off with sudo, but you need to be root (as in #) to start it again. If you don’t have a root account, typical of Ubuntu, try “sudo su” to gain root access.
All rights reserved. All brands mentioned are properties of their respective owners. This article does not guarantee nor does it insinuate results of any sort –as it’s written under the WFM (Works For Me) premise, and for informational purposes. By reading this article, the reader forgoes any accountability of the writer. The reading and consequential use of this article implies acceptance of the stipulations mentioned herein.