Application Filter
Introduction
Application filter is a data level classifier that identifies, isolates and manipulates packets from Kaazaa, HTTP, Jabber, Citrix, Bittorrent, FTP etc. protocols.
It does this by algorithmically inspecting the data encapsulated into the packet; this has two implications:
- it increases the load on the system because inspecting the data in the IP packet’s payload is processor intensive
- it can find the respective protocol regardless of port
The application filter is best suited when you try to control P2P applications that constantly change the port (or any other application that is using a non-standard port) or to separate between protocols sharing the same port (P2P using port 80).
Because is so processor intensive it is a good idea to use this tool only if you really need it because it will hamper the packet throughput on your appliance. Once identified, a packet pertaining to a certain protocol can be either logged, dropped or both.
To identify a particular protocol in a payload lump, the classifier uses a collection of definition files which describe the signature for the protocol that is being searched. These definition files can be downloaded automatically to update the classifier; new versions of definition files are periodically released by the Syneto team to cover new protocols or to adapt to changes occurred in old protocols.
Configuring And Using Application Filter
Application filter configuration page can be found in Packet Filtering > Application Filter menu. Once enabled, the service can be configured by selecting from a list the protocols (under the ‘Policy’ heading) the ones that must be dropped, logged or both. The list is activated by pressing the ‘Edit’ button from the bottom of the page.
After the policy has been defined, check for new updates, under the ‘Update definitions’ heading. You have the possibility to enable automatic updates that will search for, download and apply any new updates that may be made available by Syneto team.
If the log action has been selected, packets pertaining to a protocol will appear in the ‘Log’ tab where they can be searched based on source and destination IP and port, date interval, protocol and the action that was enforced upon the packet (i.e. if the packet was allowed or dropped). Once you’ve selected the necessary parameters for a filter, press the ‘Apply filters’ button to begin the search through the Application Filters log.
The application filter can also be configured from the SSH or serial consoles.
Figure 11-1
The config tool is the swiss-knife that helps you once again in configuring this system from the console. A first step is to enable the application filter service:
# config appfilter enable
Next, list the protocols and protocol groups for which we have a definition:
# config appfilter show
Once the protocol or group has been identified, there are four possible targets (or actions): allow_nolog, allow_log, reject_nolog and reject_log. The name of the targets is pretty suggestive. The syntax is rather simple at this point; say we want to reject all p2p traffic while logging who is doing this traffic:
# config appfilter reject_log p2p
It’s a bit more complicated to define the policy from the command line, especially if you don’t police groups but individual protocols. This command line tools is intended for quick inspection and minor changes rather than using it as a major policy editor. This tool can also start and stop the automatic update process or make a manual update:
# config appfilter update automatic
# config appfilter update manual
# config appfilter update now
The log inspection tools however were not implemented in the command line version. You will have to use the web interface to access them.
Figure 11-2