APF - Advanced Policy Firewall
Advanced Policy Firewall (APF) is an iptables(netfilter) based firewall system designed around the essential needs of today’s Internet deployed servers and the unique needs of custom deployed Linux installations. The configuration of APF is designed to be very informative and present the user with an easy to follow process, from top to bottom of the configuration file. The management of APF on a day-to-day basis is conducted from the command line with the ‘apf’ command, which includes detailed usage information and all the features one would expect from a current and forward thinking firewall solution.
The technical side of APF is such that it embraces the latest stable features put forward by the iptables(netfilter) project to provide a very robust and powerful firewall. The filtering performed by APF is three fold:
- Static rule based policies (not to be confused with a “static firewall”)
- Connection based stateful policies
- Sanity based policies
The first, static rule based policies, is the most traditional method of firewalling. This is when the firewall has an unchanging set of instructions (rules) on how traffic should be handled in certain conditions. An example of a static rule based policy would be when you allow/deny an address access to the server with the trust system or open a new port with conf.apf. So the short of it is rules that infrequently or never change while the firewall is running.
The second, connection based stateful policies, is a means to distinguish legitimate packets for different types of connections. Only packets matching a known connection will be allowed by the firewall; others will be rejected. An example of this would be FTP data transfers, in an older era of firewalling you would have to define a complex set of static policies to allow FTA data transfers to flow without a problem. That is not so with stateful policies, the firewall can see that an address has established a connection to port 21 then “relate” that address to the data transfer portion of the connection and dynamically alter the firewall to allow the traffic.
The third, sanity based policies, is the ability of the firewall to match various traffic patterns to known attack methods or scrutinize traffic to conform to Internet standards. An example of this would be when a would-be attacker attempts to forge the source IP address of data they are sending to you, APF can simply discard this traffic or optionally log it then discard it. To the same extent another example would be when a broken router on the Internet begins to relay malformed packets to you, APF can simply discard them or in other situations reply to the router and have it stop sending you new packets (TCP Reset).
These three key filtering methods employed by APF are simply a generalization of how the firewall is constructed on a technical design level, there are a great many more features in APF that can be put to use. For a detailed description of all APF features you should review the configuration file /etc/apf/conf.apf which has well outlined captions above all options.
Below is a point form summary of most APF features for reference and review:
- detailed and well commented configuration file
- granular inbound and outbound network filtering
- user id based outbound network filtering
- application based network filtering
- trust based rule files with an optional advanced syntax
- global trust system where rules can be downloaded from a central management server
- reactive address blocking (RAB), next generation in-line intrusion prevention
- debug mode provided for testing new features and configuration setups
- fast load feature that allows for 1000+ rules to load in under 1 second
- inbound and outbound network interfaces can be independently configured
- global tcp/udp port & icmp type filtering with multiple methods of executing filters (drop, reject, prohibit)
- configurable policies for each ip on the system with convenience variables to import settings
- packet flow rate limiting that prevents abuse on the most widely abused protocol, icmp
- prerouting and postrouting rules for optimal network performance
- dshield.org block list support to ban networks exhibiting suspicious activity
- spamhaus Don’t Route Or Peer List support to ban known “hijacked zombie” IP blocks
- any number of additional interfaces may be configured as firewalled (untrusted) or trusted (not firewalled)
- additional firewalled interfaces can have there own unique firewall policies applied
- intelligent route verification to prevent embarrassing configuration errors
- advanced packet sanity checks to make sure traffic coming and going meets the strictest of standards
- filter attacks such as fragmented UDP, port zero floods, stuffed routing, arp poisoning and more
- configurable type of service options to dictate the priority of different types of network traffic
- intelligent default settings to meet every day server setups
- dynamic configuration of your servers local DNS revolvers into the firewall
- optional filtering of common p2p applications
- optional filtering of private & reserved IP address space
- optional implicit blocks of the ident service
- configurable connection tracking settings to scale the firewall to the size of your network
- configurable kernel hooks (ties) to harden the system further to syn-flood attacks & routing abuses
- advanced network control such as explicit congestion notification and overflow control
- special chains that are aware of the state of FTP DATA and SSH connections to prevent client side issues
- control over the rate of logged events, want only 30 filter events a minute? 300 a minute? – you are the boss
- logging subsystem that allows for logging data to user space programs or standard syslog files
- logging that details every rule added and a comprehensive set of error checks to prevent config errors
- if you are familiar with netfilter you can create your own rules in any of the policy files
- pluggable and ready advanced use of QoS algorithms provided by the Linux
- 3rd party add-on projects that compliment APF features
Supported Systems & Requirements
The APF package is designed to run on Linux based operating systems that have an operational version of the iptables (netfilter) package installed. The iptables (netfilter) package is supported on Linux kernels 2.4 and above, you can find out more details on the netfilter project at:
If the version of Linux you are using already has an included copy of iptables then chances are very high it has all the iptables modules that APF will need. If you are configuring iptables in your own custom kernel then you should be sure that the following modules are compiled with the kernel for modular support:
- ip_tables
- iptable_filter
- iptable_mangle
- ip_conntrack
- ip_conntrack_irc
- ip_conntrack_ftp
- ipt_state
- ipt_multiport
- ipt_limit
- ipt_recent
- ipt_LOG
- ipt_REJECT
- ipt_ecn
- ipt_length
- ipt_mac
- ipt_multiport
- ipt_owner
- ipt_state
- ipt_ttl
- ipt_TOS
- ipt_TCPMSS
- ipt_ULOG
If you would like to make sure you support these modules then you can take a look inside of /lib/modules/kernelver/kernel/net/ipv4/netfilter/ directory.
# ls /lib/modules/$(uname -r)/kernel/net/ipv4/netfilter/The known Linux platforms that APF will run on are very diverse and it is hard to keep track but here is a short summary:
- Redhat Enterprise AS/ES 2+
- CentOS Any
- Fedora Core Any
- Slackware 8.0+
- Debian GNU/Linux 3.0+
- Suse Linux 8.1+
- Unbuntu Any
- TurboLinux Server 9+
- TurboLinux Fuji (Desktop)
- RedHat Linux 7.3,8,9
The base system specs for APF operating as intended are not set in stone and you can easily scale the package into almost any situation that has a Linux 2.4+ kernel, iptables and bash shell with standard set of gnu-utils (grep, awk, sed and the like).
Post a Comment