User-level firewalling with Portsmith


The most critical issue with Portsmith security is that the web server is permanently accessible, more particularly so because it uses the PHP scripting language. If an attacker can compromise the authentication feature because of a vulnerability in the programming or the PHP language itself, the whole network becomes vulnerable.

The database link is another potential target. For example, imagine a black hat launching an SQL injection attack to "modify" the ruleset, making the protection the firewall is supposed to provide fairly useless.

Although research into Portsmith's PHP has not revealed any potential vulnerabilities, one cannot rule out the possibility of a successful attack. It goes without saying that you should update often. For more protection, you might also want to install Suhosin [8] or ModSecurity [9] to give you some defense against zero-day exploits.

The system is based on allowing an authenticated client's IP address for a connection. The source IP arriving at port 443 on the web server is referenced to ascertain the address. This behavior is also a potential source of danger: In the simplest case, the client might be unaware that it is hiding behind a proxy that sets up a connection to the Portsmith firewall for the web browser. This would lead to the proxy address, rather than the client address, being enabled. In turn, this scenario means that any user on the proxy is assigned the same privileges as the user client-side and, thus, can access the client user's resources.

A situation in which an attacker works through a compromised proxy server would be even worse. Considering how long the period of access is granted, this would again leave a gaping hole open for attacks.

Practical Supplement

Portsmith is a practical supplement to a conventional firewall. The solution adds dynamic, predefined enabling to the traditionally static ruleset, allowing users to initiate changes. One potential use would be hardening access to an internal web mailer or other services, such as Sun Secure Global Desktop [10]. With encrypted connections, Portsmith could serve as a VPN replacement. If you prefer a genuine VPN solution, you can easily add IPSec software, such as strongSwan [11] or OpenVPN [12].

Simply using Portsmith to grant SSH firewall access to a restricted group of users is very much over the top. Port knocking [13] is a simpler and more secure alternative. Users with dynamic IP addresses need to rely on manual techniques or an external tool such as a DynDNS service to update the configuration with an active, official IP address.

The default ruleset poses a couple of questions and could definitely be improved in places. Fortunately, changes are made easily, although a change does require manual editing of the Portsmith configuration files. Manual editing can cause complications when you update.

With respect to authentication, Portsmith unfortunately relies on its own database-oriented approach. Use of an RSA token system or single sign-on would be preferable. This would not only mean more convenience for the user, but (especially in the case of RSA) also an extra layer of security.

It would also be useful to introduce time-based controls to automatically lock temporary accounts, for example, or restrict logins to normal office hours for some users. One would hope that the system is flexible enough to support extensions of this kind.


All told, and assuming a working basic configuration and more hardening, Portsmith is a useful extension to any iptables-based firewall that is likely to make life easier for both administrators and users.


A firewall is only as good as the ruleset implemented by its packet filter. In Portsmith's case, the default policy is similar to Listing 1.

The internal network,, which is hiding behind the eth1 interface, can access the big, bad Internet without restrictions with port address translation. This approach might be fine for a home network or a small commercial setup, but it also poses many dangers.

The Portsmith homepage states "… all external ports are blocked until released after login," but the reality is a bit more complicated. Not only are ports 80 and 443 open for access to websites, but port 25 is open for mail traffic. On the other hand, any ICMP traffic reaching the external interface is blocked, although this sacrifices important troubleshooting information.

Portsmith uses the RELATED and ESTABLISHED states advantageously to automatically (statefully) allow the backchannel for existing TCP and DNS connections from the internal network. Source NAT, which is enabled for a generic IP address ( poses more questions (Listing 2).

This appears to be the remnants of a forward to the LPD port of an internal print server. Although TCP port 9100 is blocked by default, the entry could cause hard-to-find problems in a similar setup.

Fortunately, you can modify the basic policy to match your own needs. Simply delete the defaults from /usr/local/bin/fw_policy, or customize to create as complex an initial ruleset as you like. If you do not have basic iptables skills, you should turn to an expert for help.

After logging in a user and enabling an SSH connection for the user, the INPUT chain was extended as in Listing 3.

As you can see, dynamic rules come first. This avoids potential conflict with more generic existing rules. The destination ( for the new rule is somewhat disturbing, in that Portsmith's own policy states that it should be restricted to an external IP.

Listing 1

Portsmith Filter

Chain INPUT (policy DROP 22 packets, 3590 bytes)
 pkts bytes target     prot opt in     out     source               destination
    7   476 ACCEPT     all  --  eth1   *
  200 17460 ACCEPT     all  --  lo     *  
    0     0 ACCEPT     tcp  --  eth0   *             limit: avg 5/sec burst 5 tcp dpt:80
    0     0 ACCEPT     tcp  --  eth0   *             limit: avg 5/sec burst 5 tcp dpt:25
    0     0 ACCEPT     tcp  --  eth0   *             limit: avg 5/sec burst 5 tcp dpt:443
    0     0 ACCEPT     tcp  --  *      *             state RELATED,ESTABLISHED
    1    62 ACCEPT     udp  --  *      *             limit: avg 15/sec burst 5 udp spt:53 state RELATED,ESTABLISHED
    0     0 ACCEPT     icmp --  *      *           limit: avg 5/sec burst 5
Chain FORWARD (policy DROP 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination
    0     0 ACCEPT     all  --  *      *
    0     0 ACCEPT     all  --  *      *  
    0     0 ACCEPT     all  --  *      *             state RELATED,ESTABLISHED
Chain OUTPUT (policy ACCEPT 233 packets, 21730 bytes)
 pkts bytes target     prot opt in     out     source               destination

Listing 2

Source NAT


Listing 3

Modified Rules


The Author

Christian Ney works as Systems Engineer for Security at Computacenter AG & Co. oHG, where networks, security, and firewalls are his daily bread.

Buy this article as PDF

Express-Checkout as PDF
Price $2.95
(incl. VAT)

Buy Linux Magazine

Get it on Google Play

US / Canada

Get it on Google Play

UK / Australia

Related content

  • Socks 5

    Socks is a universal proxy protocol for TCP and UDP that allows internal hosts to securely pass the firewall and authenticates users. This article describes the latest version of the Socks proxy protocol and shows how to implement it.

  • Letters
  • SSPE Security Policies

    The Simple Security Policy Editor (SSPE) helps you organize your network and keep track of security policies across multiple firewalls. You can reference a central policy to generate rulesets for packet filters and VPN gateways.

  • Jitsi

    If you are looking for an alternative to commercial videoconferencing platforms, Jitsi offers an open source solution that lets you build and deploy online videoconferences.

  • Nftables

    The nftables firewall utility offers a simpler and more consistent approach for managing firewalls in Linux.

comments powered by Disqus

Direct Download

Read full article as PDF:

060-064_portsmith.pdf  (389.55 kB)