|
PIX Logging Architecture v2.00: Installation, Configuration and Usage Guide [Author: Kris Philipsen - kris@logging-architecture.net] [Sun, Mar 25, 2007] [version #2.00/2] Table of Contents 1. Introduction 2. Features 3. Deployment Options 3.1 PLA Infrastructure Layout 3.2 PLA Centralized Deployment 3.3 PLA Distributed Deployment 3.4 PLA Traffic Requirements 4. PLA Installation 4.1 Installation Requirements 4.2 Installlation Matrix 4.3 Installing Parsing Scripts 4.4 Installing Web-based Front End 4.5 Upgrading from PIX Logging Architecture v2.00 Beta 1 5. PLA Configuration 5.1 Configuring MySQL Database 5.2 Configuring Syslog 5.3 Configuring PIX Firewall 5.3.1 Configuring System Logging 5.3.2 Configuring IDS Logging 5.4 Configuring Apache 5.5 Configuring PLA Parsing Daemon 5.5.1 Configure Required Variables 5.5.2 Configure Recommended Variables 5.5.3 Configure Optional Variables 5.5.4 Configure Automatic Startup 5.6 Configuring PLA Web-based Front End 6. Using PIX Logging Architecture v2.00 6.1 Basic Usage 6.2 Overview of PLA Menus 6.3 PLA Security Dashboard 6.4 Log Viewing 6.4.1 PIX Traffic Logs Viewing 6.4.2 PIX IDS Logs Viewing 6.4.3 PIX Informatinal Logs Viewing 6.5 Log Searching 6.5.1 PIX Traffic Logs Search 6.5.2 PIX IDS Logs Search 6.5.3 PIX Informatinal Logs Search 6.6 Configuring Display Filtering 6.6.1 Creating a Display Filter Manually 6.6.2 Creating a Display Filter With Cloning 6.6.3 Creating a Display Filter from PIX Log Entry 6.7 Configuring Traffic Descriptions 6.7.1 Creating a Traffic Description Manually 6.7.2 Creating a Traffic Description With Cloning 6.7.3 Creating a Traffic Description from PIX Log Entry 6.8 Configuring Traffic Queries 6.8.1 Creating a Traffic Query Manually 6.8.2 Creating a Traffic Query With Cloning 6.8.3 Creating a Traffic Query from PIX Log Entry 6.9 Running Traffic Queries 6.10 Configuring Parse Filtering 6.10.1 Creating a Parse Filter Manually 6.10.2 Creating a Parse Filter With Cloning 6.10.3 Creating a Parse Filter from PIX Log Entry 6.11 Executing Log Purges 7. PIX Logging Architecture Best Practices 7.1 Scaling the Deployment 7.2 Recommended Deployment Strategy 7.3 Parsing Fun! 7.3.1 Parsing Message Types 1 and 2 7.3.2 Parsing Message Type 0 8. Additional Information 8.1 The People Behind PLA 8.2 Acknowledgements and Kudos 8.3 Support The PLA Project 8.4 PLA Resources 1. Introduction The PIX Logging Architecture [PLA] provides a centralized method for correlating and displaying logs generated by Cisco PIX Firewalls. Cisco PIX supports logging to a syslog host. PLA uses this feature in order to parse these logs, based on their type (traffic, ids or informational) and then push them into a MySQL database. A web-based frontend queriesthe MySQL database for the entries and then displays them according to the various options available in the PLA web-based frontend.
PIX Logging Architecture v2.00 is the second release of PLA, being released about 3 years
after the original release, many changes and improvements have been made to the original
code and many new features have been introduced in order to make PLA more suitable for
different infrastructures. For those who were familiar with PLA v1.01, you'll get a whole
realm of new features with this release whilst still maintaining the same look and feel.
However, I've come along way with this project since 2003 so you'll find that some things
have been changed since the original PLA v1.01 release. Amongst the major changes you'll
find the following:
2. Features
The main purpose of PIX Logging Architecture is to provide a framework for treating, correlating
and consulting logs of different devices.
Parsing/Database Highlights:
Web-based Front-end Highlights:
3. Deployment Options 3.1 PLA Infrastructure Layout
As previously mentioned, the PLA Infrastructure parses logs sent by a Cisco PIX Firewall, and then pushes
them to a MySQL database. The parsing is done on the system defined as the syslog host for the Cisco PIX
Firewall, the parsing script then uses the Perl DBI module to enter the logging information into the
MySQL database.
3.2 PLA Centralized Deployment When using the PLA Centralized Deployment option, all PLA components are located on the same systems. This deployment could be used for various reasons, such as shortage of machines, centralized management policy. The following components are centralized on a single component:
+---+ syslog +------------------------+
|PIX| ----------> | PLA Centralized System |
+---+ +------------------------+
| (1) Parse Syslog |
| (2) Populate Database |
| (3) Provide Web-based |
| frontend |
+------------------------+
3.3 PLA Distributed Deployment
When using the PLA Distributed Deployment option, each PLA component or a group of PLA components are located
on various systems.
+---+ syslog +------------------------+ +------------------------+
|PIX| ----------> | PLA Distributed System | | PLA Distributed System |
+---+ | Logging Host | | DB + Web Frontend |
+------------------------+ Perl::DBI +------------------------+
| (1) Parse Syslog | -----------> | (2) Populate Database |
+------------------------+ | (3) Provide Web-based |
| frontend |
+------------------------+
Note: Similarly, the database component can be seperated from the web-based front-end so that each component runs on a dedicated device. Such configurations may be optimal if you want to optimize the device resource utilisation. Moreover, certain security considerations may opt for such a distributed approach ensuring that DMZ devices are seperated from Internal systems and traffic only moves in a certain direction. 3.4 PLA Traffic Requirements
As for traffic requirements, depending on your deployment strategy, certain openings may need to be made to your
firewall rules to allow traffic between the various PLA components. The following traffic patterns exist:
4. PLA Installation 4.1 Installation Requirements
The PLA Infrastructure requires certain components to be installed in order to function properly. The following
components must be installed:
The PLA scripts are written in Perl, and should therefore work on any system supporting Perl. I'm personnally running this infrastructure on Linux, and I've had no problems so far. If you run this on any other platforms, i.e. ActivePerl on Windows or so, please send me an email (kris@logging-architecture.net) so I can add your platform to the compatibility list. You can obtain a copy of the latest PIX Logging Architecture v2.00 software at http://www.logging-architecture.net/pla2/ 4.2 Installation Matrix
If you're opting for the distributed installation, it's important to know which components need to be installed where:
4.3 Installing Parsing Scripts
The parsing script is located in the "scripts/parsing/" directory of the PLA Software Package (the "tar.gz" file).
This script must be installed on the system which received the system logs (syslog) and is used to identify which log entries
should be pushed to the database, this script requires both Perl and Perl::DBI. Personally, I've put this script
in an "/usr/sbin" directory.
The parsing script is called "pla_parsed" and is a Perl script which runs in daemon mode so you just need to start it and it keeps running in the background. I've also included the "rc.pla_parsed" script which needs to be put into the /etc/init.d to automatically start the PLA Parse Daemon (pla_parsed) on system startup. If you move the pla_parsed script to another directory than "/usr/sbin" the "rc.pla_parsed" script will need to be updated. The script will need to be linked to the correct runlevel for it to started and stopped automatically.
This script also requires a specific syslog configuration, which is shown in the Configuration section of this document. The "pla_parsed" script works as follows:
2. Connect to the Database and extract the parse_filter table (for identifying parsing filters) 3. Start reading the syslog messages file to which the PIX/FWSM logs are logged. 4. Match incoming message with syslog_message table extract and determine if a match exists. 5. If a match exists, check whether the traffic matches a parse filter and if not, log the data to the PLA database. 6. If no match exists, determine whether to log the data to a flat temporary undefined traffic file. 4.4 Installing Web-based Front End
The web-based frontend is a collection of Perl/CGI scripts located in the "scripts/frontend/" directory of the
PLA software package. These scripts query the MySQL database for information and entries pertaining to the
Cisco PIX/FWSM logs. These scripts should be copied to a scripts executable directory on your web server. For example
the "/cgi-bin/" directory on many web servers. In the configuration section of this document I've explained how
to configure a directory to be script executable within Apache. For example, on my web server I've created a "pla2"
directory in the main Apache HTML documents directory (DirectoryRoot - "/usr/local/apache2/htdocs") and set this to
scripts executable.
4.5 Upgrading from PIX Logging Architecture v2.00 Beta 1
If you're upgrading to PIX Logging Architecture v2.00 from PIX Logging Architecture v2.00 Beta 1, the transition is quite smooth and will only involve a few minutes work.
This file can easily be imported into the PLA database using the following method (please note that this will scratch the current syslog message parsing table so if you created your own entries be sure to back these up beforehand and create them later!):
Note: Don't forget to configure the PLA v2.00 "conf.pl" file in the PLA Web Based Front-End directory with the same settings as you were using with PLA v2.00 Beta 1.
Note: Don't forget to configure the PLA v2.00 Parsing Daemon (pla_parsed) with the same settings as you were using with PLA v2.00 Beta 1. 5. Configuration 5.1 Configuring MySQL
Since MySQL (the database) is the principal component empowering the PLA infrastructure, it needs to be configured
properly.
Secondly, a user must be created that is allowed full access only to the "pix" database. This user will be used both by the PLA Parsing script to push data into the database, and by the PLA Web-based Frontend to retrieve information from the database. The user can be created in the following manner:
Note: Remember your user and password, you'll need to use these as variables in the PLA scripts. Note: Whenever a series of newly supported log messages have been added to PLA and properly tested, they are added to what is known as the Supported System Log Messages page. This web page contains a list of all supported log messages along with a link to an SQL file which contains a series of statements which recreates the "syslog_message" table. It is recommended to update this table regularly as it will increase the number of supported logged events. At the time of this writing, the latest version of this file is dating back to November 12, 2006 (syslog_message-20061112.sql.txt) and is available at http://www.logging-architecture.net/pla2/release/supportedmessages.html under the "Latest Syslog Messages File" section. The format of this file is "syslog_message-YYYYMMDD.sql.txt". This file can easily be imported into the PLA database using the following method (please note that this will scratch the current syslog message parsing table so if you created your own entries be sure to back these up beforehand and create them later!):
5.2 Configuring Syslog
The syslog host will receive the alerts sent by the Cisco PIX/FWSM Firewall(s).
The "local6.*" facility is used here because I chose "logging facility 22" on the Cisco PIX Firewall, therefore this may need to be changed if you're using a different logging facility. The following table shows the mapping between Unix and Cisco Logging Facilities:
Note: The "/var/log/<firewall-name>.log" file may also be different in your configuration, but do note that you will need to define this file as a variable ($pix_log_file) in the PLA parsing script (pla_parsed). Note: Don't forget to restart syslogd after you've made these changes! 5.3 Configuring Cisco PIX Firewall
In order to get a Cisco PIX Firewall to be compatible with the PIX Logging Architecture, several configuration
statements will have to be added on the Cisco PIX Firewall:
Notes:
5.3.2 Configuring IDS Logging The following commands should be used to set up IDS logging on the Cisco PIX Firewall:
Notes:
5.4 Configuring Apache
The Apache web server is used to house the scripts which power the PLA web-based front end. Whether you run Apache 1.x, 2.0.x or 2.2.x is your choice, however you may have to make some changes to the configuration in order to allow the scripts to correctly execute (in other words, the Apache needs to know that these scripts are executable and should thus show you the output of the scripts rather than the scripts code itself).
Next, we'll configure Apache as follows: The following lines will need to be added to the "httpd.conf" file following the <Directory /usr/local/apache2/htdocs> section. For example:
5.5 Configuring PLA Parsing Daemon
The PLA Parsing Daemon (pla_parsed) script, located on the syslog host, will need to be configured with several
parameters before PLA can work correctly.
In theory, at this point the PLA Parsing Daemon should work, however you may need to edit your configuration a little bit more in order to ensure all works correctly. 5.5.2 Configure Recommended Variables
This basically defines what your syslog layout looks like. The "$regex_log_begin" variable looks at everything before the PIX/FWSM log message. For example in the following PIX system log entry:
The "$regex_log_begin" is only concerned with anything before the ": %PIX-6-305011", so in other words:
The variables starting with "$var_" match certain criteria which are parsed in order to push them into the database and would look as follows if I filled them out:
However all you'll need to do is fill out the position starting from the beginning of the "$regex_log_begin" variable. This may all look a bit complicated if you're not used to regular expressions but if usually the standard format defined in the pla_parsed script should work for all. The reason I've added this section is because I've noticed that different syslog daemons sometimes display a slightly different log format. Please note if you're using FWSM with context's enabled, the log format is somewhat different because they've added a "CONTEXT" field to their logs, so you'll need to define the syslog section as follows (and replace the "<CONTEXT>" variable by the name of your context ofcourse!):
The following is what an FWSM 3.x log entry looks like:
So the $regex_log_begin for the FWSM 3.x logs would look like:
5.5.3 Configure Optional Variables Several optional variables can be configured in the "pla_parsed" (PLA Parsing Daemon - /usr/sbin/pla_parsed) script:
5.5.4 Configure Automatic Startup The PLA Parse Daemon (pla_parsed) is a daemonized script thus it runs in the background. It can be started automatically at Operating System startup using the runlevel (rc) script "rc.pla_parsed". You just need to ensure that the pla_parsed script is started when the MySQL database server has already been started to ensure the PLA Parse Daemon can retrieve data from and write data to the PLA database. You'll have to link the startup script (i.e. "/etc/init.d/rc.pla_parsed) to a runlevel and set it to be executable as follows:
Note: It is recommended that at this time you do not yet start the PLA Parsing Daemon. Please refer to section "7.2 Recommended Deployment Strategy" for more information on recommended steps for deploying PIX Logging Architecture. If you'd like to manually start the PLA Parsing Daemon:
If you'd like to manually stop the PLA Parsing Daemon:
5.6 Configuring Web-Based Front End
First of all, make sure the scripts in the "scripts/frontend/" directory of the PLA Package are copied to a
directory configured to execute Perl/CGI scripts. This is the same directory you defined when configuring Apache.
6. Using PIX Logging Architecture v2.00 6.1 Basic Usage
The PIX Logging Architecture web based front-end can be reached by typing in the URL as defined on the web server with the
"pix_traffic_logs" extension. So consider the application is installed on the 127.0.0.1 IP address in the pla2 directory then
the browser needs to point to:
6.2 Overview of PLA Menus
PIX Logging Architecture consists of a hierachical structure of menus allowing for easy navigation, use and configuration of the PLA web-based front-end. The following structure is used for the web-based front-end:
| +--- Drops and Accepts Statistics | +--- Protocol Redistribution Statistics | +--- Cumulative Logged Traffic Statistics | +--+ PIX Traffic Logs (main menu) | +--- PIX Traffic Log Details | +--+ PIX IDS Logs (main menu) | +--- PIX IDS Log Details | +--+ PIX Informational Logs (main menu) | +--+ PIX Search Logs (main menu) | +--- PIX Search Traffic Logs (sub menu) | +--- PIX Search IDS Logs (sub menu) | +--- PIX Search Informational Logs (sub menu) | +--+ PIX Traffic Queries (main menu) | +--+ PLA Configuration (main menu) | +--+ PIX Traffic Log Configuration (sub menu) | +--- Display Filter Configuration (sub menu choice) | +--- Description Configuration (sub menu choice) | +--- Traffic/User-defined Query Configuration (sub menu choice) | +--+ PIX IDS Logs Configuration (sub menu) | +--- Display Filter Configuration (not active yet) | +--+ PLA Global Configuration (sub menu) | +--- Objects Configuration (not active yet) | +--- Log Message Parsing Configuration (not active yet) | +--- Incident Management (sub menu choice) | +--- Log Purging Configuration (sub menu choice) | +--- Parse Filter Configuration (sub menu choice) | +--+ PLA About (main menu) 6.3 PLA Security Dashboard
Menu Item: (Main Menu) > "Security Dasbboard"
Graph View (Right Side):
You can easily select a date by clicking on the "Date" link which will pop up a calendar where you can select your Security Dashboard display date. However please note that after the date selection has been made, you have to choose to which view you want to apply this, you can do this by either selecting "Global View" or any of the firewall names/IP's from the "-customize view-" drop down menu. 6.3-3: Security Dashboard Calendar - Date Selection 
In order to get a more detailed view into the data presented on the Security Dasbhoard page, you can click on the red and green links under the Top Dropped and Top Accepted items. These will show you all the logs matching the count which is depicted in the List View. It is also possible to click on the Graphs in the Graph View on the right hand side in order to get a global picture of the Drops and Accepts, Protocol Redistribution and Cumulative Logged Traffic over a 24-hour, 7 day, 30 day and 12 month time period. 6.4 Log Viewing
The main functionality of PIX Logging Architecture is to allow logs to be parsed, correlated and available for viewing. PLA currently distinguishes between 3 types of logs; PIX Traffic Logs, PIX IDS Logs and PIX Informational Logs. Each of these logs has a dedicated log viewing page which allows the logged data to be consulted.
On this page it is possible to select a few criteria including the date, log resource (firewall) and whether the displayed information should contain the plain IP information or whether the addresses need to be resolved. Please note that traffic which has been filtered using a traffic display filter will not be shown in the "Traffic Logs" windows. You can easily select a date by clicking on the "Date" link which will pop up a calendar where you can select you log date as shown in the following screenshot: 6.4.1-3: PIX Traffic Logs Calendar - Date Selection 
When opening the PIX Traffic Logs page, PLA will by default only show the first 50 matching logs, allowing you to navigate through the subsequent logs with the "Next" and "Previous" links. However it is possible to change this "paging" feature to allow for more logs to be shown on a single page. At present you can choose between 50, 100, 250, 500 and 1000 logs per page. In order to change the number of logs which are displayed per page, you can modify the paging option with the dropdown in the top righthand corner: 6.4.1-4: PIX Traffic Logs Paging 
When opening the PIX Traffic Logs page, PLA will by default sort on the log time (Ascending) starting with the oldest records for the selected date and ending with the newest records. It is possible to change this view by applying a sorting selection. Currently the following sorting selections are available:
6.4.1-5: PIX Traffic Logs Sorting 
In order to get more information about a certain log entry, click on the table row to display the "PIX Traffic Log Detail" page, which contains more specific information such as Xlate (Translation) information, Database Matches, and several Options. These options allow you to create filters, queries and descriptions on the fly. More information can be found later on in the traffic filters section of this document. The following screenshot shows an example of the PIX Traffic Log Detail page: 6.4.1-6: PIX Traffic Log Detail 
Two noteworthy features on the PIX Traffic Log Detail page require some additional elaboration: The following parameters on the PIX Traffic Log Detail page support the PLA Graphs feature:
The following screenshot shows an example of the PLA Graph for the Destination Port (10000) in the previous screenshot: 6.4.1-7: PLA Graphs 
6.4.2 PIX IDS Logs Viewing Menu Item: (Main Menu) > "IDS Logs" 6.4.2-1: Main Menu View 
The PIX IDS Logs view is used to display the PIX IDS Logs. The general view shows the following columns in a list format:
On this page it is possible to select a few criteria including the date, log resource and whether the displayed information should contain the plain IP information or whether the addresses need to be resolved. The date selection calendar as well as paging features on this page are identical to those of the PIX Traffic Logs page so please refer to the PIX Traffic Logs section of this chapter. However, the PIX IDS Logs sorting feature is somewhat different from the PIX Traffic Logs in that the column names are different and thus the sorting selection varies slightly. By default, the PIX IDS Logs page will sort based on log time in an ascending manner starting with the oldest records for the selected date and ending with the newest records. It is possible to change this view by applying a sorting selection. Currently the following sorting selections are available:
In order to get more information about a certain log entry, click on the table row to display the "PIX IDS Log Detail" page, which contains more specific information such as Database Matches, and several Options. At the time of this writing the only options available for the PIX IDS Log Detail is to link the Log ID to an incident. 6.4.3 PIX Informational Logs Viewing Menu Item: (Main Menu) > "Informational Logs" 6.4.3-1: Main Menu View 
The PIX Informational Logs view is used to display the PIX Informational Logs. Informational Logs include items such as SSH logins, configuration modifications, interfaces ups/downs and the like. The general view shows the following columns in a list format:
On this page it is possible to select a few criteria including the date, log resource and whether the displayed information should contain the plain IP information or whether the addresses need to be resolved. The date selection calendar as well as paging features on this page are identical to those of the PIX Traffic Logs page so please refer to the PIX Traffic Logs section of this chapter. However, the PIX Informational Logs sorting feature is somewhat different from the PIX Traffic and IDS Logs in that the column names are different and thus the sorting selection varies slightly. By default, the PIX Informational Logs page will sort based on log time in an ascending manner starting with the oldest records for the selected date and ending with the newest records. It is possible to change this view by applying a sorting selection. Currently the following sorting selections are available:
6.5 Log Searching
Besides showing a general view of the logs, it is also possible to carry out specific and granular searches against the database for entries which match the search criteria. PIX Logging Architecture v2.00 allows searching of PIX Traffic, IDS and Informational logs.
Note: When you want to use an "ANY" wildcard, please leave the field blank (in other words; you don't need to fill in the "%" to match the Any condition). Below are some examples to clarify these searches and the usage of wildcards: Example 1 - One ANY Wildcard
Example 2 - One ANY Wildcard and One SPECIFIC Wildcard
Example 3 - Multiple ANY Wildcards
In addition to the criteria listed above, it is also possible to resolve the hostnames and services when performing the search, in order to do this, please select "Yes" on the "Resolve Hostnames" section of the search page. The default behavior is not to resolve hostnames. PLA Traffic Logs search by default do not take into account Traffic Log Display filters, which means that even if you've defined a traffic log display filter for some or all of the results in your search query, they will still appear. It is possible to change this behavior and tell the PIX Traffic Logs search to take into account the Display Filters by selecting "Yes" in the "Enable Display Filters" section. The following screenshot shows all available options on the PIX Traffic Logs Search page: 6.5.1-2: PIX Traffic Log Search 
6.5.2 PIX IDS Logs Search Menu Item: (Main Menu) > "Search" Menu Item: (Sub Menu) > "IDS Logs" 6.5.2-1: Main Menu View 
PIX IDS Logs can be searched based on a set of defined criteria. Within these searches a number of wildcards can be used with the "%" (percentage) character, which is the default SQL wildcard. The following lists all the fields which are allowed as search input:
Note: when you want to use an "ANY" wildcard, please leave the field blank (in other words; you don't need to fill in the "%" to match the Any condition). In addition to the criteria listed above, it is also possible to resolve the hostnames and services when performing the search, in order to do this, please select "Yes" on the "Resolve Hostnames" section of the search page. The default behavior is not to resolve hostnames. The following screenshot shows all available options on the PIX IDS Logs Search page: 6.5.2-2: PIX IDS Log Search 
6.5.3 PIX Informational Logs Search Menu Item: (Main Menu) > "Search" Menu Item: (Sub Menu) > "Info Logs" 6.5.3-1: Main Menu View 
PIX Informational Logs can be searched based on a set of defined criteria. Within these searches a number of wildcards can be used with the "%" (percentage) character, which is the default SQL wildcard. The following lists all the fields which are allowed as search input:
The following screenshot shows all available options on the PIX Informational Logs Search page: 6.5.3-2: PIX Informational Log Search 
6.6 Configuring Display Filtering
Sometimes you may have legal requirements from the governing industry bodies to log certain types of traffic, however you may not want them to show up when you're displaying your traffic logs because they're considered overhead traffic. Examples of such traffic may be outbound DNS, SMTP, HTTP requests which may "pollute" your log files since they are usually overall present in high numbers.
Example 2 - One ANY Wildcard and One SPECIFIC Wildcard
Of course you don't have to worry about writing these filters in the text based form like I just did here, you'll have the web interface to configure them, but I'm just showing you how the evaluation of the criteria works and how you can use wildcards (either by leaving the fields blank for an "Any" match or by using the "%" wildcard character for partial matches). There's three ways of creating a traffic display filter: 6.6.1 Creating a Display Filter Manually Menu Item: (Main Menu) > "Configuration" Menu Item: (Sub Menu) > "Traffic Logs" Menu Item: (Sub Menu Choice) > "Configure Display Filters" 6.6.1-1: Main Menu View 
The page you get when you click on the "Configure Display Filters" link represents the main menu for the Traffic Display Filter configuration. 6.6.1-2: Main Display Filter Configuration 
The page lists all your traffic filters and gives you a little menu on the top when you click on the plus-sign in front of the "Traffic Filter Options" link on the top. Using this menu you can create a new filter, search for certain variables within existing filters and show filters based on certain criteria. These latter two I'll let you find out later since they're quite trivial to use, so I'll focus on the Creation part. Creating a Traffic Display Filter manually involves several steps:
6.6.1-3: Expanding and Creating Title Menu 
Step 2 - You'll now get a page with all blank form fields, some of which are input boxes, others are drop down menus. The following lists all the required form criteria and whether wildcards can be used: Click on the "Create" button to create the filter or on the "Reset" button to reset the form The following screenshot shows a Display Filter which filters all TCP traffic from 10.10.10.x to any destination on destination port 445 (basically MS DCE traffic). 6.6.1-4: Creating a Traffic Filter 
Step 3 - Once you've created the filter you'll get a page with the summary of the filter you've just created. You've got three options from this page: The following screenshot shows a successful Display Filter creation for the above defined criteria: 6.6.1-5: Successful Display Filter Creation 
Step 4 - When you click on the "Back to the Display Filter" configuration page, you should see the list of all created traffic filters including the one you just created. When you create a filter it is enabled by default, which means that any traffic which matches the filter will not be displayed in the traffic logs view (and traffic logs searches if selecting "Enable Display Filters"). However, it is possible to disable the filter temporarily by clicking on the "disable" button in the options section of the traffic display filter main page. Other options include "clone" (which will be discussed shortly), edit (which allows you to edit the specific filter) and remove (which will permanently remove the traffic display filter). You can view the filter details by clicking on the filter name column (first column starting from the left). The following screenshot shows the Main Display Filter Configuration after we've created our display filter: 6.6.1-6: Main Display Filter Configuration after Creation 
Menu Item: (Main Menu) > "Configuration" Menu Item: (Sub Menu) > "Traffic Logs" Menu Item: (Sub Menu Choice) > "Configure Display Filters" Menu Item: (Options Choice) > "[ clone ]" (within a selected traffic display filter in the "options" column) 6.6.2-1: Main Menu View 
The purpose of Traffic Display Filter Cloning is to re-use criteria entered within another filter and cloning them in order to create a new filter. So basically if we have a filter "A" which has DNS traffic defined between a specific source and destination IP pair and you want to add another destination for that same source IP and same traffic (DNS), you can clone filter "A" to create filter "B". Using the process of cloning you don't have to create an entirely new filter because you can just copy over the criteria from another filter. Basically what a clone does is it gives you the same page as you would have for creating a new filter, however several of the parameters are already filled in according to a pre-defined template, being the traffic display filter you're cloning from. In addition, a clone will add the "CLONED:" keyword in front of the Filter Name and Filter Description fields so that you don't create filters with duplicate names. Once you've got the cloned filter create window open, you can edit any variables you want in order to create the new filter, in the same manner as you would edit an existing filter. The following screenshot shows the Cloned Traffic Display Filter Configuration after we've created our display filter: 6.6.2-2: Cloned Traffic Display Filter Configuration 
Note: The same wildcards apply as for the "Creating a New Traffic Filter" section. Since creating a cloned traffic display filter involves mainly similar steps to creating a new filter, I will not repeat the entire process, however it is important to know that you can clone a traffic filter at three locations:
6.6.3 Creating a Display Filter From PIX Log Entry Menu Item: (Main Menu) > "Traffic Logs" Menu Item: (Select) > Select a Traffic Log which has been logged by the firewall. Menu Item: (Expand) > "Options" Menu Item: (Select) > "Display Filter" - "Create a display filter from PIX Log ID." 6.6.3-1: Main Menu View 
While it is useful to be able to create Traffic Display Filters manually or cloning them. You're most likely creating the traffic display filters because of certain log entries you've seen. Therefore I've added the option to create a Traffic Display Filter straight from a PIX Traffic Log entry. This saves a lot of time since you don't have to worry about copy/pasting information across and it works in a similar way as cloning a Traffic Display filter in that it takes the information from the specific PIX Log Entry and allows you to edit it as you see fit. Note: The same wildcards apply as for the "Creating a New Traffic Filter" section. 6.7 Configuring Traffic Descriptions
Oftentimes you may come across traffic which may at first sight be unknown, especially some of the TCP/UDP high ports which are often used for Trojans as well as several legitimate applications (especially those very useful backup applications and the likes;). However, whilst traffic on port 80 and port 25 are well known services, an incoming scan on UDP/17500 may not be for example. That's why I've added the Traffic Descriptions functionality to PIX Logging Architecture, which is a feature that allows a user to define a description for a certain type of traffic. When the user clicks on the traffic details for this unknown traffic, each time it matches a traffic description, the description will be shown. Traffic Descriptions are accumulative, which means you can define multiple traffic descriptions for the same type of traffic and PIX Logging Architecture will then show you all of them. Traffic Descriptions are configured in a similar manner as Traffic Display Filters.
6.7.1-3: Expanding and Creating Title Menu 
Step 2 - You'll now get a page with all blank form fields, some of which are input boxes, others are drop down menus. The following lists all the required form criteria and whether wildcards can be used: Click on the "Create" button to create the description or on the "Reset" button to reset the form. The following screenshot shows a Description which triggers on all TCP traffic from 10.10.10.x to any destination on destination port 445 (basically MS DCE traffic). 6.7.1-4: Creating a Traffic Description 
Step 3 - Once you've created the description you'll get a page with the summary of the Traffic Description you've just created. You've got three options from this page: The following screenshot shows a successful Description creation for the above defined criteria: 6.7.1-5: Successful Traffic Description Creation 
Step 4 - When you click on the "Back to the Traffic Description" configuration page, you should see the list of all created traffic description including the one you just created. Options on this page include "clone" (which will be discussed shortly), edit (which allows you to edit the selected description) and remove (which will permanently remove the traffic description). You can view the description details by clicking on the Description Name column (first column starting from the left). The following screenshot shows the Main Traffic Description Configuration after we've created our Traffic Description: 6.7.1-6: Main Traffic Description Configuration after Creation 
Menu Item: (Main Menu) > "Configuration" Menu Item: (Sub Menu) > "Traffic Logs" Menu Item: (Sub Menu Choice) > "Configure Descriptions" Menu Item: (Options Choice) > "[ clone ]" (within a selected traffic description in the "options" column) 6.7.2-1: Main Menu View 
The purpose of Traffic Description Cloning is to re-use criteria entered within another description and cloning them in order to create a new query. So basically if we have a description "A" which has DNS traffic defined between a specific source and destination IP pair and you want to add another destination for that same source IP and same traffic (DNS), you can clone query "A" to create description "B". Using the process of cloning you don't have to create an entirely new description because you can just copy over the criteria from another description. Basically what a clone does is it gives you the same page as you would have for creating a new description, however several of the parameters are already filled in according to a pre-defined template, being the traffic description you're cloning from. In addition, a clone will add the "CLONED:" keyword in front of the Description Name and Description Detail fields so that you don't create descriptions with duplicate names. Once you've got the cloned description create window open, you can edit any variables you want in order to create the new description, in the same manner as you would edit an existing description. The following screenshot shows the Cloned Traffic Description Configuration after we've created our display filter: 6.7.2-2: Cloned Traffic Description Configuration 
Note: The same wildcards apply as for the "Creating a New Traffic Description" section. Since creating a cloned traffic description involves mainly similar steps to creating a new description, I will not repeat the entire process, however it is important to know that you can clone a traffic description at three locations:
6.7.3 Creating a Traffic Description From a PIX Log Entry Menu Item: (Main Menu) > "Traffic Logs" Menu Item: (Select) > Select a Traffic Log which has been logged by the firewall. Menu Item: (Expand) > "Options" Menu Item: (Select) > "Descriptions" - "Create a description from PIX Log ID." 6.7.3-1: Main Menu View 
While it is useful to be able to create Traffic Descriptions manually or cloning them. You're most likely creating the traffic description because of certain log entries you've seen when looking through the PIX Traffic logs. Therefore I've added the option to create a Traffic Description straight from a PIX Traffic Log entry. This saves a lot of time since you don't have to worry about copy/pasting information across and it works in a similar way as cloning a Traffic Description in that it takes the information from the specific PIX Log Entry and allows you to edit it as you see fit. Note: The same wildcards apply as for the "Creating a New Traffic Description" section. 6.8 Configuring Traffic Queries
Sometimes there's recurring traffic which you look for on a daily basis and you would like to run recurring searching for this type of traffic. While running a traffic logs search is not a bad idea, it requires you to input the parameters every time. Therefore I've created a Traffic Query, which is basically "Set of Saved Search Parameters" which can then be given a name and ran at a later time. The advantage of using queries is that you do not need to re-type the parameters all ovah again with each recurring seach you do for similar traffic. Traffic Queries are configured in a similar manner as Traffic Display Filters.
6.8.1-3: Expanding and Creating Title Menu
Step 2 - You'll now get a page with all blank form fields, some of which are input boxes, others are drop down menus. The following lists all the required form criteria and whether wildcards can be used: Click on the "Create" button to create the Traffic Query or on the "Reset" button to reset the form. The following screenshot shows a Query which matches all TCP traffic from 10.10.10.x to any destination on destination port 445 (basically MS DCE traffic). 6.8.1-4: Creating a Traffic Query 
Step 3 - Once you've created the description you'll get a page with the summary of the Traffic Query you've just created. You've got three options from this page: The following screenshot shows a successful Traffic Query creation for the above defined criteria: 6.8.1-5: Successful Traffic Query Creation 
Step 4 - When you click on the "Back to the Traffic Query" configuration page, you should see the list of all created traffic queries including the one you just created. Options on this page include "clone" (which will be discussed shortly), edit (which allows you to edit the selected query) and remove (which will permanently remove the traffic query). You can view the query details by clicking on the Query Name column (first column starting from the left). The following screenshot shows the Main Traffic Query Configuration after we've created our Traffic Query: 6.8.1-6: Main Traffic Query Configuration after Creation 
Menu Item: (Main Menu) > "Configuration" Menu Item: (Sub Menu) > "Traffic Logs" Menu Item: (Sub Menu Choice) > "Configure Queries" Menu Item: (Options Choice) > "[ clone ]" (within a selected traffic queries in the "options" column) 6.8.2-1: Main Menu View 
The purpose of Traffic Query Cloning is to re-use criteria entered within another query and cloning them in order to create a new query. So basically if we have a Traffic Query "A" which has DNS traffic defined between a specific source and destination IP pair and you want to add another destination for that same source IP and same traffic (DNS), you can clone Traffic Query "A" to create Traffic Query "B". Using the process of cloning you don't have to create an entirely new query because you can just copy over the criteria from another query. Basically what a clone does is it gives you the same page as you would have for creating a new query, however several of the parameters are already filled in according to a pre-defined template, being the traffic query you're cloning from. In addition, a clone will add the "CLONED:" keyword in front of the Query Name and Query Detail fields so that you don't create traffic queries with duplicate names. Once you've got the cloned query create window open, you can edit any variables you want in order to create the new query, in the same manner as you would edit an existing query. The following screenshot shows the Cloned Traffic Query Configuration after we've created our display filter: 6.8.2-2: Cloned Traffic Query Configuration 
Note: The same wildcards apply as for the "Creating a New Traffic Query" section. Since creating a cloned traffic query involves mainly similar steps to creating a new query, I will not repeat the entire process, however it is important to know that you can clone a traffic dquery at three locations:
6.8.3 Creating a Traffic Query From a PIX Log Entry Menu Item: (Main Menu) > "Traffic Logs" Menu Item: (Select) > Select a Traffic Log which has been logged by the firewall. Menu Item: (Expand) > "Options" Menu Item: (Select) > "Queries" - "Create a query from PIX Log ID." 6.8.3-1: Main Menu View 
While it is useful to be able to create Traffic Queries manually or cloning them. You're most likely creating the traffic query because of certain log entries you've seen when looking through the PIX Traffic logs and would like to set up a recurring query. Therefore I've added the option to create a Traffic Query straight from a PIX Traffic Log entry. This saves a lot of time since you don't have to worry about copy/pasting information across and it works in a similar way as cloning a Traffic Query in that it takes the information from the specific PIX Log Entry and allows you to edit it as you see fit. Note: The same wildcards apply as for the "Creating a New Traffic Query" section. 6.9 Running Traffic Queries
Menu Item: (Main Menu) > "Queries"
6.10 Configuring Parse Filtering
In addition to Traffic Display filtering which filters out logged data from being displayed to the user, it is possible to also filter out traffic before it gets logged to the PLA database. There may be certain types of traffic which are overhead and you may not way to see logged, such as Nokia VRRP traffic, Multicast traffic, bulk HTTP, HTTPS, DNS and other type of traffic. Filtering out this traffic at the parsing stage ensures that the PLA database does not get "polluted" with unnecessarily logged traffic
and helps maintain the database in keeping its size smaller. I've added Parse Filters exactly for this purpose. The way a parse filter works is by defining the criteria for traffic which should be filtered. For example:
Example 2 - Multiple ANY Wildcards (2)
As you can see in the above example, only a <leave_blank> wildcard may be used by leaving the field blank and matching the entire field. Partial matching wildcards using the "%" (percentage) character are NOT ALLOWED in the parse filters. Notes: There's three ways of creating a parse filter: 6.10.1 Creating a Parse Filter Manually Menu Item: (Main Menu) > "Configuration" Menu Item: (Sub Menu) > "Global Configuration" Menu Item: (Sub Menu Choice) > "Configure Parse Filter" 6.10.1-1: Main Menu View 
The page you get when you click on the "Configure Parse Filter" link represents the main menu for the Parse Filter configuration. 6.10.1-2: Main Parse Configuration 
The page lists all your parse filters and gives you a little menu on the top when you click on the plus-sign in front of the "Parse Filter Options" link on the top. Using this menu you can create a new filter, search for certain variables within existing filters and show filters based on certain criteria. These latter two I'll let you find out later since they're quite trivial to use, so I'll focus on the Creation part. Creating a Parse Filter manually involves several steps:
6.10.1-3: Expanding and Creating Title Menu 
Step 2 - You'll now get a page with all blank form fields, some of which are input boxes, others are drop down menus. The following lists all the required form criteria and whether wildcards can be used: Click on the "Create" button to create the filter or on the "Reset" button to reset the form The following screenshot shows a Display Filter which filters all TCP traffic from 10.10.10.1 to any destination on destination port 445 (basically MS DCE traffic). 6.10.1-4: Creating a Parse Filter 
Step 3 - Once you've created the filter you'll get a page with the summary of the filter you've just created. You've got three options from this page: The following screenshot shows a successful Parse Filter creation for the above defined criteria: 6.10.1-5: Successful Parse Filter Creation 
Step 4 - When you click on the "Back to the Parse Filter" configuration page, you should see the list of all created parse filters including the one you just created. When you create a filter it is enabled by default, which means that any traffic which matches the filter will not be logged into the database. However, it is possible to disable the filter temporarily by clicking on the "disable" button in the options section of the parse filter main page. Other options include "clone" (which will be discussed shortly), edit (which allows you to edit the specific filter) and remove (which will permanently remove the tparse filter). You can view the filter details by clicking on the filter name column (first column starting from the left). The following screenshot shows the Main Parse Filter Configuration after we've created our display filter: 6.10.1-6: Main Parse Filter Configuration after Creation 
Menu Item: (Main Menu) > "Configuration" Menu Item: (Sub Menu) > "Global Configuration" Menu Item: (Sub Menu Choice) > "Configure Parse Filter" Menu Item: (Options Choice) > "[ clone ]" (within a selected parse filter in the "options" column) 6.10.2-1: Main Menu View 
The purpose of Parse Filter Cloning is to re-use criteria entered within another filter and cloning them in order to create a new filter. So basically if we have a filter "A" which has DNS traffic defined between a specific source and destination IP pair and you want to add another destination for that same source IP and same traffic (DNS), you can clone filter "A" to create filter "B". Using the process of cloning you don't have to create an entirely new filter because you can just copy over the criteria from another filter. Basically what a clone does is it gives you the same page as you would have for creating a new filter, however several of the parameters are already filled in according to a pre-defined template, being the traffic display filter you're cloning from. In addition, a clone will add the "CLONED:" keyword in front of the Filter Name and Filter Description fields so that you don't create filters with duplicate names. Once you've got the cloned filter create window open, you can edit any variables you want in order to create the new filter, in the same manner as you would edit an existing filter. The following screenshot shows the Cloned Parse Filter Configuration after we've created our display filter: 6.10.2-2: Cloned Parse Filter Configuration 
Note: The same wildcards apply as for the "Creating a New Parse Filter" section. Only <leave_blank> wildcards are allowed within the Parse Filter creation. Since creating a cloned Parse Filter involves mainly similar steps to creating a new filter, I will not repeat the entire process, however it is important to know that you can clone a Parse filter at three locations:
6.10.3 Creating a Parse Filter From a PIX Log Entry Menu Item: (Main Menu) > "Traffic Logs" Menu Item: (Select) > Select a Traffic Log which has been logged by the firewall. Menu Item: (Expand) > "Options" Menu Item: (Select) > "Parse Filter" - "Create a parse filter from PIX Log ID." 6.10.3-1: Main Menu View 
While it is useful to be able to create Parse Filters manually or cloning them. You're most likely creating the parse filters because of certain log entries you've seen. Therefore I've added the option to create a Parse Filter straight from a PIX Traffic Log entry. This saves a lot of time since you don't have to worry about copy/pasting information across and it works in a similar way as cloning a Parse filter in that it takes the information from the specific PIX Log Entry and allows you to edit it as you see fit. Note: The same wildcards apply as for the "Creating a New Parse Filter" section. Only <leave_blank> wildcards are allowed within the Parse Filter creation. 6.11 Executing Log Purges
When running PLA in an environment with a high amount of traffic you can easily start filling up the PLA database. In order to keep tabs on the size of the PLA database, I've added the Log Purging feature, which allows users to delete PLA log entries older than a certain date. While it is not possible to manually specify a log purging policy, several policies have been pre-defined which can be used to purge the PLA database.
The following screenshot shows the Log Purging Main Page: 6.11-2: Main Log Purging Page 
Once you've clicked on one of the log purging policies, you will be taken to the log purging confirmation page, which shows various details such as the date prior to which logs will be purged, the number of records that will be purged and which require you to confirm two check boxes before being able to successfully carry out the purging of the logs. The following information is provided on the log purging confirmation page:
The following check boxes need to be checked in order to allow the log purging to take place:
The following screenshot shows the Log Purging Policy Validation Page: 6.11-3: Log Purging Policy Validation Page 
After these check boxes have been checked, you can click on the "Purge Logs" button to start the log purging process, which will take you to the "Log Purging Execution" Page. The "Log Purging Execution" page contains the following elements:
The following screenshot shows the execution of a Log Purging Policy: 6.11-4: Log Purging Policy Execution 
Note: Purging the logs may take a while and eventually time out (HTTP timeout to the PLA web-based front end) due to the size of the database, however the purging jobs will keep running on the PLA system. 7. PIX Logging Architecture Best Practices 7.1 Scaling The Deployment When considering a PIX Logging Architecture deployment (which you most likely are since you've read all this way through the document;) it is important to properly scale the machines running the infrastructure. Of course the usage of the machines depends a great deal on the number of logs you're going to have, the number of queries you're gonna throw at the database and so-forth. However here's some general considerations regarding the deployment of PIX Logging Architecture v2.00:
Note: Rather than separating each of these components on a dedicated server, you can also install all of these components on the same system. 7.2 Recommended Deployment Strategy
Whilst it is perfectly possible to install the different components of the PIX Logging Architecture infrastructure and let the logs come in, this may not be the most efficient approach. You may have traffic logged that you don't want to log. You may be logging certain log messages which are not necessarily useful to you, etc.. etc.. I've done several PIX Logging Architecture v2.00 deployments, both on small as well as on large networks and it's sometimes a very painful thing to find out that you're getting 100+ log entries a second into the database and then need to start figuring out what logs you should be filtering. Thus to minimize such "nightmares", out of my experience I'd like to share the following recommended deployment steps with you:
2. Download the latest version of the syslog_message table which you can find on the PLA website at http://www.logging-architecture.net/pla2/release/supportedmessages.html 3. Start running the PLA Database and the PLA web-based front end - DO NOT activate the PLA Parsing Daemon yet! 4. If you already know which specific traffic you do not want to log, start creating Parse Filters for this traffic. 5. If you already know which specific traffic you want to log but not display, start creating Traffic Display Filters for this traffic. 6. If available, a trending of network traffic top services and top connections would be a plus, if not you'll have to handle in a "best effort" methodology, but try and find out what overhead traffic may be transitting your networks, and create very broad (display and/or parse) filters for these types of traffic. Typical "high overhead traffic filters" are:
- Source_IP: ANY | Source_Port: ANY | Destination_IP: Any | Destination_Port: 443 - Source_IP: ANY | Source_Port: ANY | Destination_IP: Any | Destination_Port: 8080 - Source_IP: ANY | Source_Port: ANY | Destination_IP: Any | Destination_Port: 25 - Source_IP: ANY | Source_Port: ANY | Destination_IP: Any | Destination_Port: 110 - Source_IP: ANY | Source_Port: ANY | Destination_IP: Any | Destination_Port: 53 - Source_IP: ANY | Source_Port: ANY | Destination_IP: Any | Destination_Port: 139 (that's always an evil one;) - Source_IP: ANY | Source_Port: ANY | Destination_IP: Any | Destination_Port: 445 (another evil one perhaps?;) 7. Activate Syslogd Remote Log reception on the Logging Host and configure the PIX/FWSM to log to this host - DO NOT activate the PLA Parsing Daemon yet! 8. Let Syslogd run for a predefined time period (1 hour is usually always a good sampling already) and look through the log file, ensure that the log messages which are indicated in the log file match those defined as parsing criteria in the "syslog_messages" table of the PLA database. For a list of all log messages which are logged or specifically excluded, please refer to the PIX Logging Architecture v2.00 web site. Also create traffic display filters and parse filters for any traffic which you may have noticed in the log file and do not want to log or display. 9. Create Traffic Queries for known and unknown traffic so you can easily identify these types of traffic. 10. Activate Syslogd Remote Log reception once more and start running the PLA Parsing Daemon (pla_parsed). 11. Connect to the PLA web-based front end and ensure that messages are entered correctly into the database. 12. Continue configuring Traffic Display Filters and Parse Filters as you see the accumulation of log traffic. 7.3 Parsing Fun
The PIX Logging Architecture Parsing Daemon (pla_parsed) uses a predefined set of criteria to be able to match incoming logs to known parsing formats and thus extrapolate the required information from the log file. The way this is done is using a "syslog_message" table within the PLA database which contains all the known log formats and defines what should be logged and should not be logged. The purpose of this section is to explain how parsing is done so that if you need to change anything to the PLA database parsing you'll know what to look for. No web-based front end is available for editing the syslog_messages table and thus you'll have to get your hands dirty inside the PLA database to be able to create some new log messages. I've provided this chapter for a good understanding how the PIX Logging Architecture's Parsing Daemon (pla_parsed) evaluates the log messages and to understand the construction of the "syslog_message" table so you can start added your own log messages which may not yet included in the default set of PLA supported log messages.
+--------------------+-----------------+------+-----+---------+----------------+ | Field | Type | Null | Key | Default | Extra | +--------------------+-----------------+------+-----+---------+----------------+ | field_id | int(8) unsigned | | PRI | NULL | auto_increment | | message_id | varchar(20) | YES | | NULL | | | message_type | int(8) | YES | | NULL | | | message_regex | varchar(255) | YES | | NULL | | | message_time | varchar(32) | YES | | NULL | | | message_action | varchar(32) | YES | | NULL | | | regex_src_ip | int(8) unsigned | YES | | NULL | | | regex_dst_ip | int(8) unsigned | YES | | NULL | | | regex_src_pt | int(8) unsigned | YES | | NULL | | | regex_dst_pt | int(8) unsigned | YES | | NULL | | | regex_xlate_src_ip | int(8) unsigned | YES | | NULL | | | regex_xlate_dst_ip | int(8) unsigned | YES | | NULL | | | regex_xlate_src_pt | int(8) unsigned | YES | | NULL | | | regex_xlate_dst_pt | int(8) unsigned | YES | | NULL | | | regex_idsmsg | int(8) unsigned | YES | | NULL | | | regex_proto | int(8) unsigned | YES | | NULL | | | regex_flags | int(8) unsigned | YES | | NULL | | | regex_time | int(8) unsigned | YES | | NULL | | | regex_sig | int(8) unsigned | YES | | NULL | | | regex_msg | int(8) unsigned | YES | | NULL | | | regex_iface | int(8) unsigned | YES | | NULL | | +--------------------+-----------------+------+-----+---------+----------------+ 21 rows in set (0.00 sec) PLA basically supports 3 types of log messages ("message_type" field) defined by the adjacent message types:
7.3.1 Parsing Message Types 1 and 2 The following happens when Parsing Message Types 1 (Traffic Logs) & 2 (IDS Logs):
Just to give an idea on how this works, I'll give a practical example. Lets say a log message comes in of with the message_id PIX-6-302015. Below is the message followed by a table which lists the syslog_message field name, syslog_message field value for this log message as defined in the database.
The following table lists the parsing record that the PLA database has for the "PIX-6-302015" log message: +--------------------+------------------------------------------------------------------------------------------------+ | Field | Value | +--------------------+------------------------------------------------------------------------------------------------+ | field_id | 4 | | message_id | PIX-6-302015 | | message_type | 1 | | message_regex | Built outbound (.*) connection .* for .*:(.*)/(.*) .(.*)/(.*). to .*:(.*)/(.*) .(.*)/(.*).. | | message_time | %b %d %Y %H:%M:%S | | message_action | ACCEPT | | regex_src_ip | 6 | | regex_dst_ip | 2 | | regex_src_pt | 7 | | regex_dst_pt | 3 | | regex_xlate_src_ip | 8 | | regex_xlate_dst_ip | 4 | | regex_xlate_src_pt | 9 | | regex_xlate_dst_pt | 3 | | regex_idsmsg | 0 | | regex_proto | 1 | | regex_flags | 0 | | regex_time | 0 | | regex_sig | 0 | | regex_msg | 0 | | regex_iface | 0 | +--------------------+------------------------------------------------------------------------------------------------+ So if we were to take the log message shown above and fill in the variables, i.e. when evaluating the log message using the regular expression, we come up with the following results: message_regex = "Built outbound UDP connection 6914 for outside:82.131.5.64/1254 (82.131.5.64/1254) to inside:10.1.10.8/48733 (80.200.224.122/2159)" message_action = ACCEPT regex_src_ip (position #4 in message_regex) = 10.1.10.8 regex_dst_ip (position #2 in message_regex) = 82.131.5.64 regex_src_pt (position #7 in message_regex) = 48733 regex_dst_pt (position #3 in message_regex) = 1254 regex_xlate_src_ip (position #8 in message_regex) = 80.200.224.122 regex_xlate_dst_ip (position #4 in message_regex) = 82.131.5.64 regex_xlate_src_pt (position #9 in message_regex) = 2159 regex_xlate_dst_pt (position #3 in message_regex) = 1254 regex_proto (position #1 in message_regex) = UDP Based on this extrapolated information, the PLA Parsing Daemon then generates a log entry which it will push to the database, unless the specific log entry matches a known parse filter. So if you wish to write your own parsing criteria you can write them as shown above and thus keep PLA up to date. I myself will do my best to keep the PLA database as up to date as possible. At the time of this writing, I've got a total number of 51 Traffic and IDS log formats defined for PIX and FWSM together. Note: Remember that when you want to define Traffic or IDS log criteria, be specific and include the Regex statement followed by the proper positions for the different variables. 7.3.2 Parsing Message Type 0 Message Type 0 serves a double purpose:
Two conditions exist: 1. IF (message_type = 0 and message_action = 1) then the log should be included as an informational log entry.
Thus the following message:
Will be logged as an informational log message with the following information field: "Teardown PPPOE Tunnel, tunnel_id = 0, remote_peer_ip = 80.200.224.1" 2. IF (message_type = 0 and message_action = 0) then the log should be excluded and not even considered by PLA Parse Daemon.
For example, PIX Log Message PIX-6-305011 (which describes Port Address Translation) for dynamic port openings is not logged to the PLA database because it creates a lot of overhead information and thus has been excluded with the excluded log message (message_type = 0 and message_action = 0) setting. Thus the following message:
Will be discarded by the PLA Parsing Daemon because it matches an excluded log message id (PIX-6-305011) with the (message_type = 0 and message_action = 0) setting. 8. Additional Information 8.1 The People Behind PIX Logging Architecture
I'd like to take this opportunity to introduce the people who have worked on making PIX Logging Architecture a reality and are continuing efforts on making this a great and useful piece of software!
8.2 Acknowledgements and Kudos
Thanks to all people who have been wonderful in helping improve PIX Logging Architecture and making it into what it is today. 8.3 Support The PIX Logging Architecture Project
If you like the PIX Logging Architecture project and would like to support us there's several ways of doing this:
<a href="http://www.logging-architecture.net"><img src="http://www.logging-architecture.net/pla_banner_small.jpg" alt="PIX Logging Architecture" border="0"></a>
Please refer to the http://www.logging-architecture.net/pla2/ website for more information on this. 8.4 PIX Logging Architecture Resources
Besides this Installation, Configuration and Usage guide for PIX Logging Architecture, I've also put 5 mailing lists up regarding various topics relating to PIX Logging Architecture:
 Last Update: 25-Mar-2007 |
|
