UncomplicatedFirewall
Please check the status of this specification in Launchpad before editing it. If it is Approved, contact the Assignee or another knowledgeable person before making changes.
Launchpad Entry: ubuntu-firewall
Packages affected: none
Summary
Release Target: Hardy
Name: ufw (Uncomplicated Firewall)
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 be disabled on installation (ie 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/ufw/ufw.rules. This file will be used with iptables-restore and ip6tables-restore, and will be used on boot.
The tool will manage /etc/ufw/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/init.d/ufw to enable the firewall on boot (can't use if-up.d script because /usr must be mounted to use python). It should start before 'networking'.
External packages will add files to /usr/share/ufw.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:
- ACCEPT all on loopback
- ACCEPT all outgoing
- default policy of ACCEPT for incoming (configurable)
- LOG all dropped packets (perhaps use --limit 3/min --limit-burst 10 or similar)
The tool provides the following interface:
Turn firewall on and off ('disable' is default ACCEPT):
# ufw enable|disable
Toggle logging:
# ufw logging on|off
Set the default policy (ie "mostly open" vs "mostly closed":
# ufw default allow|deny * 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/ufw/maps and 'deny' removes service entry from /etc/ufw/maps: {{{ # ufw allow|deny <service>Display status of firewall and ports in the listening state, referencing /etc/ufw/maps. Numbers in parenthesis are not displayed to user:
# ufw 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
- denied service referencing package meta-data
- allowed service referencing package meta-data
- allowed service referencing /etc/services
- denied service referencing dynamically-detected service
- denied service by specifying 'protocol:port'
- allowed service referencing a package with supplied meta-data, but was replaced by one that does not
- allowed service referencing removed package meta-data
- allowed service referencing /etc/services but the service is not running
- allowed service by specifying 'protocol:port' but the service is not running
- 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.
Implementation
Rollout
upload to universe (DONE)
- announce to devel-discuss and ubuntu-server
- MIR
Status
Version 0.6 has the following implemented functionality (as described above):
- Completed
- enable/disable
- default policy
- logging
- initscript
- packaging
- default /proc adjustments (/etc/ufw/sysctl.conf)
- allow/deny (but the syntax may change)
- Partial
- status
- ipv6
- Not-implemented
- package integration
- /etc/ufw/maps
Couple of things on the immediate agenda:
- turn initscript into a proper iptables script, and get rid of ufw.rules. this allows for preserving state, no flushing, preserving user changes, etc
- use separate chains for ufw rules (currently only ufw-in)
- don't flush on adding rules
Test/Demo Plan
The source code has testing scripts. Can use (from the top-level source):
$ cd <top-level source directory> $ ./run_tests.sh -s $ sudo ./run_tests.sh -s root
Additionally, once the package is installed, can use:
$ sudo ufw status $ sudo ufw enable && sudo ufw status $ sudo ufw disable && sudo ufw status $ sudo ufw enable $ sudo ufw logging on && tail /etc/ufw/ufw.rules $ sudo ufw logging off && tail /etc/ufw/ufw.rules $ sudo ufw default allow && head /etc/ufw/ufw.rules $ sudo ufw default deny && head /etc/ufw/ufw.rules $ sudo ufw allow 53 && sudo ufw status $ sudo ufw allow 80:tcp && sudo ufw status $ sudo ufw allow from 192.168.254.254 && sudo ufw status
The README also contains information for testing.
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
The above specification is based on the meeting from 2007/10/30. Originally this specification was based on UbuntuFirewallLongTerm, but it was decided that the ideas expressed in UbuntuFirewallLongTerm were Hardy+1 or longer.
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
- 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)
- Packages need to provide metadata saying "I use this port", we need an interpreter
Comments
- What about Fedora 8's firewall config program?
- It's called system-config-firewall. Download the Fedora 8 gnome live cd to check it out.
- From what I can tell it is a python gtk front end to the iptables firewall. It might not meet all your requirements but it should be looked at as a possibility. It may depend on some Red Hat/Fedora only back end but wouldn’t it be better to extend this program instead of creating a new Ubuntu firewall config tool?
~~~~