Also see https://wiki.ubuntu.com/UbuntuFirewall

Note that this was the original specification for UDS-Boston. This specification will have to be revised after UbuntuFirewall is implemented.

Target Release: Hardy+1

Summary

Create a high level language for iptables firewall configuration. The language would be based on OpenBSD's PF syntax, along with any improvements to make it easier for users (PF provides a compact, easy to understand firewall language). Initially, the language will consist of only a subset of PF functionality, but eventually could include queuing and traffic optimization.

In addition to the higher level language, ubuntu-firewall should provide packaging integration to make it easier for network daemon packages to integrate with the firewall.

It is important to note that this is not simply 'Yet Another Firewall Tool', but rather a high level firewall language to make firewall configuration easier for users, packaging, and tools.

• Note: This is a feature of package firehol, only that the config file that is currently packaged with it does not yet include a rules.d/ for integration with the package management. A service definitions drop-in directory is implemented since FireHOL v1.213, because the config file is is a bash script there is no problem in including a rules.d/, though. (see man firehol or http://firehol.sourceforge.net )

Release Note

ubuntu-firewall will not affect users in the default installation as the tool will not dictate a default firewall policy for all users. Users will have to explicitly enable ubuntu-firewall if they want to use it.

Rationale

Ubuntu currently does not have an integrated firewall in its base installation. Additionally, the tools that are available to create a firewall are largely based on GUI applications and/or create iptables scripts that are dependent on the tool to update them. Users are left to choose between one of the many firewall tools available, or roll their own firewall scripts. Creation and auditing of the firewall for correctness can be difficult because of the complexity of iptables and the files created by existing tools. Additionally, existing tools also do not provide package integration so that when a network daemon is installed, users have to manually determine and add the necessary firewall rules (usually with their tool of choice).

Use Cases

Bob uses a desktop system and wants to add a firewall as another layer of protection. Bob can enable ubuntu-firewall to provide this protection. When new packages are added, Bob can optionally enable the firewall rules provided by these packages.

Alice administers many server machines and wants to create a host-based firewall for them. Alice can create a base firewall policy for all the servers using the PF-based ubuntu-firewall language. Once the default policy for her servers is setup and pushed to each machine, she can then install the server packages she wants on the individual servers, and enable the firewall rules provided by those packages.

Charlie wants to configure a system to use as perimeter firewall/router. Because of ubuntu-firewall's simplified configuration syntax, the firewall can be more easily created and audited.

Assumptions

While the PF-based abstraction that ubuntu-firewall provides would be a great benefit to users on its own, to fully realize the benefits of ubuntu-firewall, packages providing network services should also provide firewall policy for the applications they provide. For example, apache2 should let ubuntu-firewall know that it provides a TCP service on port 80. It should be noted that ubuntu-firewall is still very useful on its own, so a slow transition for these packages is tolerable.

Design

1. Create the high level language for iptables firewall configuration
2. Integrate with package management by creating an /etc/uf/rules.d directory
3. Create a tool for parsing the high level language. This tool would be called 'ufctl'. Default configuration would be in /etc/uf/uf.conf. ufctl would be smart enough to turn on things like IP forwarding, depending on the configuration in uf.conf. This tool should:
   • Parse uf.conf and files in /etc/uf/rules.d
   • Load the results of the parse via iptables/proc/(and eventually ip)
   • Provide a means to specify another configuration file
   • Provide a 'dry-run' or 'config test' mechanism
4. Provide a means to load the ubuntu-firewall policy on boot

Implementation

UI Changes

There are no specific UI changes for ufctl. Simple CLI or GUI tools could eventually be created which simply add files to /etc/uf/rules.d. One implementation could similar to RedHat's system-config-securitylevel, which essentially declares what protocol and port to open.

Code Changes

Depending on the method chosen for boot integration, there may be changes to the loopback entry ('lo') in /etc/network/interfaces.

Migration

As there is currently no default firewall configuration for Ubuntu, there are no mandatory migration issues. It should be possible to generate an ubuntu-firewall policy from an existing firewall policy. Another migration issue is getting network daemon packages to provide the necessary policy files to ubuntu-firewall.

Test/Demo Plan

TBD

Outstanding Issues

• User space tools for generating policies for ubuntu-firewall

BoF agenda and discussion

Use this section to take notes during the BoF; if you keep it in the approved spec, use it for summarizing what was discussed and note any options that were rejected.

https://blueprints.edge.launchpad.net/ubuntu/+spec/ubuntu-firewall

https://wiki.ubuntu.com/UbuntuFirewall

Summary

Release Target: Hardy

Name: TBD

Create a tool for host-based iptables firewall configuration. This tool should provide an easy to use interface to the user, as well as support package integration and dynamic-detection of open ports.

Release Note

The tool will not affect users in the default installation as the tool will initially specify a default ACCEPT policy.

Rationale

Ubuntu currently does not have an integrated firewall in its base installation. The tools that are available to create a firewall are largely based on GUI applications and/or designed for advanced users. Additionally, existing tools also do not provide package integration so that when a network daemon is installed, users have to determine on their own how to integrate the application with the firewall.

Use Cases

Alice uses a desktop system and wants to add a firewall as another layer of protection. Alice can enable the firewall to provide this protection. When new packages are added, Alice can easily enable the services provided by these packages.

Bob installs a server with one network interface and wants to add a firewall as another layer of protection. Bob can enable the firewall to provide this protection, as well as monitor the status of open ports.

Assumptions

The tool will allow users to specify opening a port explicitly as well as choosing from a list of open ports. However, to fully integrate with the system, packages should provide meta-data regarding what protocol and port a particular package will need to operate with a firewall. The tool will still be useful during the transition when packages are not providing this information.

Design

The tool will manage /etc/<tool>/rules.ipv4 and /etc/<tool>/rules.ipv6. These files will be used with iptables-restore and ip6tables-restore respectively, and will be used on boot.

The tool will manage /etc/<tool>/maps. This file keeps track of how the user specified a service to the tool. It is used only for the user interface and not used in policy generation.

The package will provide /etc/network/if-up.d/<tool> to run iptables-restore and ip6tables-restore when 'lo' is brought up.

External packages will add files to /usr/share/<tool>.d that describe the service. File will use .INI format. Will support comma-separated values for protocols and ports, ranges for ports, and multiple entries per file. Examples:

[apache2]
description: Apache Webserver
protocols: tcp
ports: 80

[openvpn]
description: OpenVPN server
protocols: tcp,udp
ports: 1194

The firewall policy will be:

1. ACCEPT all on loopback
2. ACCEPT all outgoing
3. default policy of ACCEPT for incoming (configurable)
4. LOG all dropped packets (perhaps use --limit 3/min --limit-burst 10 or similar)

The tool provides the following interface:

• Set default iptables policy ('enable' is default DROP and 'disable' is default ACCEPT):

  # <tool> enable|disable

• Toggle logging:

  # <tool> logging on|off

• Set the default packages for new packages (dynamically detected ports will not be automatically allowed):

  # <tool> default allow|deny

  NEEDS DISCUSSION: This may be extraneous and confusing for the user. When a package is installed, it provides the meta-data, but rules.ipv4 and rules.ipv6 still have to be regenerated via '<tool>'. Could add debhelper hooks, or just default DENY for new services and warn when running '<tool> enable' that services have to be explicitly allowed for new packages. The second is probably fine for servers, but desktops would need a notification area alert when a new service is detected.

• Accept or drop incoming packets to <service> (can see what services are available with 'status' (see below)). <service> can be specified via service name in /etc/services, 'protocol:port', or via package meta-data. 'allow' adds service entry to /etc/<tool>/maps and 'deny' removes service entry from /etc/<tool>/maps:

  # <tool> <service> allow|deny

• Display status of firewall and ports in the listening state, referencing /etc/<tool>/maps. Numbers in parenthesis are not displayed to user:

  # <tool> status
  apache2         DENY            Apache Webserver                (1)
  openssh-server  ALLOW           SSH Logins                      (2)
  pop3s           ALLOW                                           (3)
  named           DENY            WARNING: New service running    (4)
  tcp:8082        DENY                                            (5)
  tcp:25          ALLOW                                           (6)
  ntp             ALLOW*                                          (7)
  imaps           ALLOW**                                         (8)
  tcp:23          ALLOW**                                         (9)
  jabberd2        ALLOW**                                         (10)
  
  * rule for removed package 'ntpd'
  ** services not running

  1. denied service referencing package meta-data
  2. allowed service referencing package meta-data
  3. allowed service referencing /etc/services
  4. denied service referencing dynamically-detected service
  5. denied service by specifying 'protocol:port'
  6. allowed service referencing a package with supplied meta-data, but was replaced by one that does not
  7. allowed service referencing removed package meta-data
  8. allowed service referencing /etc/services but the service is not running
  9. allowed service by specifying 'protocol:port' but the service is not running
  10. allowed service referencing package meta-data but the service is not running

Migration

As there is currently no default firewall configuration for Ubuntu, there are no mandatory migration issues. The only migration issue is getting network daemon packages to provide the necessary policy files to ubuntu-firewall.

Test/Demo Plan

TBD

Outstanding Issues

• UbuntuFirewallLongTerm describes some ideas for moving forward to extend functionality to include router/gateway configuration, NAT, QoS configuration and /proc adjustments (eg ip_forwarding, rp_filter, et al)

BoF agenda and discussion

These notes are from UDS-Boston discussion and apply to Hardy+1 as well as Hardy and UbuntuFirewall, so they are listed here too.

Meeting Notes 2007/10/29

• Goals:
  • flexible, comprehensive and easy to use firewall configuration
  • package integration
• What this spec doesn't do
  • This spec does not address UI aspects
  • This spec is not about intrusion detection (ie, we don't notify user here)
• Options

  • OpenBSD has a very convenient interface: http://www.openbsd.org/faq/pf/filter.html

    • With PF - human readable firewall config much fewer lines
    • nothing prevents user from muddling addresses and ports and zones and services, leading to support issues (user shouldn't touch metadata that package provides)
    • OpenBSD is last-match by default, iptables isn't
    • All configuration in one file (rules, /proc adjustments, QoS, etc), text file, easy to audit

  • Shorewall - shorewall.net: http://www.shorewall.net/shorewall_setup_guide.htm

    • Define zone in one file, access in another
    • Provides a way to protect you from locking yourself out (backup config)
    • Does not provide per package integration
    • Implementation is pretty horrid maze of shell scripts
  • Other
    • Packages: Firestarter (XML backend), Firehol, fwbuilder

    • SuSe had a series of twisty shell scripts that implemented a higher-level (very simple) - shell variables and such (SuSEfirewall2). Had a way to put crazy iptables stuff between the normal lanugage

    • DrakConf (mentioned outside of meeting)

• Thoughts on desirable attributes
  • Packages need to provide metadata saying "I use this port", we need an interpreter
    • What about services that change ports inside configuration (/etc/apache2/ports.conf)
  • Proper handling when opening a port (not open everything for a moment...either deny drop or something similar when rerunning whole script)
  • declarative language
  • per package meta-data (.d directory style).
  • Apache package should be able to provide enough meta-data to shape a UI say "Apache on/off"
    • or "limit to internal" or similar
  • compile from an XML file, perhaps without that XML file being made by a GUI
  • Easy to admin by modifying config files on a commmand line
  • Mechanism to test before implementation, especially so you don't lock yourself out
  • Separation between the service definition and the zone. Seems that pf syntax doesn't provide this.
  • Ability to manually handle iptables stuff between other rules in the higher level language (so you can do insane things -- packages won't do insane things, but admins might)
  • User needs to be able to turn it all off (default should be off, but turn on easy)
    • Packages might break if unaware of firewall before Hardy
  • Simple examples for simple use cases
  • Also consider simple rules that don't break packages (eg slowing flooding of brute force attacks on port 22)
  • Dynamic discovering of services
    • Could look at services from packages
    • Default open/closed? Different for packages? Default policy is configurable.
    • Let user set default policy for new services (but allow tweaking per service) but need default for default
    • Firewall should probably not break apache by default install
    • Wouldn't need package metadata if we did it dynamically
      • but may be advantage to having it optional (eg install paranoid rules package, or a package defining a range of ports)

      "<ompaul> if you auto discover it you tell me what you found and I say yes or no and add a comment - if you want me to undestand what I am doing"

  • We are adding a new non-default (installing firewall package and then it)

---

CategorySpec