BetterTechInfo

PLA (PIX Logging Architecture) uses regular expressions (regex) to parse syslog messages received from Cisco firewalls and comes pre-configured to process the standard “syslogd” message format. Most current Linux distributions ship with rsyslog (able to log directly to MySQL) while some administrators prefer syslog-ng, any standard syslog daemon will work.

The PLA installation documentation assumes familiarity regex, so here you’ll see how to tweak PLA to parse your syslog log file.

Understanding the mechanics
Perl is actually used to tail the syslog log file looking for matches to messages described in the syslog_messages table, which are in turn loaded into the MySQL database. The processing script pla_parsed contains a regex filter that must be matched in order for the processing to occur correctly. Here, the applicable section from the PLA Documentation highlights the portion of code from the pla_parsed script we are concerned with:

### PIX Firewall Logs
### DEFINE YOUR SYSLOG LAYOUT HERE!
###$regex_log_begin = “(.*):(.*) (.*) (.*) (.*) (.*) (.*)“;
$var_pixhost=3;
$var_pixmonth=4;
$var_pixdate=5;
$var_pixyear=6;
$var_pixtime=7;

The variable regex_log_begin needs to match up all the log information up to the actual PIX, ASA, or FWSM message code in order to correlate date, time, and host for each message added to the syslog message file. Take a look at the provided sample log entry from the PLA Documentation, everything in red needs to be picked up by regex_log_begin, while the remainder is standard for Cisco firewalls and already handled by pla_parsed:

Oct 21 23:59:23 fwext-dmz-01 Oct 21 2006 23:58:23: %PIX-6-305011: Built dynamic TCP translation from inside:1.1.1.1/2244 to outside:2.2.2.2/3387

Harnessing regex
Explaining the operation of regex and wildcards is beyond the scope of this article; however, we have created a simple perl script that can be used to determine whether your syslog formating is supported by default or if changes are necessary. The pla_parser_regex_test script will let you insert new regex patterns and show you how they match up against your syslog messages. The file must be saved to your pla_parsing server and accessed in one of the following manners:

1. perl pla_parser_regex_test.txt     or
2. execute the file directly ./pla_parser_regex_test.txt (after running chmod +x)

If you still need assistance with regex, numerous guides have been written to make regex understandable but remember: we’re working with the basics of regex here - nothing fancy. In our case, adjusting the default regex to match most any syslog format is now straight forward. After noting which characters match which pattern, we can determine what changes are needed by viewing the pla_parser_regex_test script’s output:

Running perl pla_parser_regex_test.txt the first time should give you:

You supplied the following log message: 

         Feb 21 10:59:32 Feb 21 2008 10:59:32 pix4us

Resulting in these matches using a default regex filter of:

                 (.*):(.*) (.*) (.*) (.*) (.*) (.*)
_________________________________________________________
]> match 1: Feb 21 10:59
]> match 2: 32
]> match 3: Feb                          (default pixhost)
]> match 4: 21                             (default pixmonth)
]> match 5: 2008                        (default pixdate)
]> match 6: 10:59:32                  (default pixyear)
]> match 7: pix4us                       (default pixtime)
_________________________________________________________

Verify the log string you provided is correct Adjust your
regex_log_begin or var_pix settings accordingly!

If you have more than one substitution for each match, verify
the log message and the regex_log_begin filter string, you may
need to change something to get PLA running

If the default settings match up, no changes are needed.
Just run pla_parsed to start PLA 

Log parsing, traditionally, has been a problem for some trying to implement PIX Logging Architecture. The pla_parser_regex_test script is provided to help ease syslog-related installation problems. As such, pla_parser_regex_test  will immediate provide feedback with each regex change and map out the deviations from the defaul PLA settings. I’m no perl programmer, so there is some manual intervention required to load your regex changes but it is very straight forward - so we’re not responsible for any problems created in the downloading, running, or editting of the pla_parser_regex_test script.

On to rsyslogd
Take this sample rsyslog entry and notice the difference from the standard syslogd format:

Feb 21 10:59:32 Feb 21 2008 10:59:32 pix4us : %PIX-6-110001: No route to 1.1.1.1 from 3.4.5.6

Feb 21 10:59:32 Feb 21 2008 10:59:32 pix4us (This is the relevant portion of the log.)
Oct 21 23:59:23 fwext-dmz-01 Oct 21 2006 23:58:23 (Note the hostname moved.)

The rsyslog entry includes the date twice followed by the hostname of the log source versus the default format expected by pla_parsed of date hostname date. The original regex is set to pickup the first time entry’s “minutes and seconds” and picks up the next 5 words/entries separated by spaces by using wildcards (.*). Each wilcard match is then translated into the necessary variables for pla_parsed:

$regex_log_begin = “(.*):(.*) (.*) (.*) (.*) (.*) (.*)“;

Oct 21 23:59:23 fwext-dmz-01 Oct 21 2006 23:58:23

As you experiment with different filters for the regex variable, be aware you may need to change the numerical references as well. In english, as you change the regex for different syslog formats, realize that the colors in the examples above may not line up correctly.

In order to process rsyslog, the pla_parsed must take into account the placement of the date/time. The initial (.*):(.*) is used to set a starting point in syslog message string. Since this new rsyslog format includes two date entries before the host name, the following can be used to allow pla_parsed to “see” the new syslog message string:

$regex_log_begin = “(.*):(.*) (.*) (.*) (.*) (.*) (.*)“;

Feb 21 10:59:32 Feb 21 2008 10:59:32 pix4us

The regex starts out the same, but looking at the colors you will notice the location of the information needed by pla_parsed to determine date, time, and host has moved. This time the 7th wildcard will have to be setup to match the $var_pixhost variable and the other $var_’s will “slide up” one position.

As a result of using this new log message format, the variables listed below the regex pattern must be modified to tell pla_parsed which (.*) contains which element. Once again the colors below will illustrate which pattern matches which element in the syslog message:

$regex_log_begin = “(.*):(.*) (.*) (.*) (.*) (.*) (.*)“;

$var_pixhost=7;
$var_pixmonth=3;
$var_pixdate=4;
$var_pixyear=5;
$var_pixtime=6;

The numbering happens left to right and the color coding should help this make sense. This same approach of keying off the timestamping can be applied to pla_parsed in order to allow processing of syslog-ng, ksyslogd, or any other syslog message format.

The pla_parser_regex_test will illustrate the same output, without the colors:

Here the $log variable inside the script has been updated with the new example:

You supplied the following log message:

         Feb 21 10:59:32 Feb 21 2008 10:59:32 pix4us

Resulting in these matches using a default regex filter of:

                 (.*):(.*) (.*) (.*) (.*) (.*) (.*)
_________________________________________________________
]> match 1: Feb 21 10:59
]> match 2: 32
]> match 3: Feb                          (default pixhost)
]> match 4: 21                           (default pixmonth)
]> match 5: 2008                         (default pixdate)
]> match 6: 10:59:32                     (default pixyear)
]> match 7: pix4us                       (default pixtime)
_________________________________________________________

Verify the log string you provided is correct Adjust your
regex_log_begin or var_pix settings accordingly!

If you have more than one substitution for each match, verify
the log message and the regex_log_begin filter string, you may
need to change something to get PLA running

If the default settings match up, no changes are needed.

Just run pla_parsed to start PLA

Notice the output shows the matches don’t lineup with the default variables; however, the match number can be used to modify or verify the $var_ parameters.

An alternative method to match the rsyslog output involves using  “(.*):(.*)” and “((.*):(.*):(.*))” to force a match on the time elements as seem below. Once again, the color coding should help clarify what is being done in the regex filter:

Sample: Feb 21 10:59:32 Feb 21 2008 10:59:32 pix4us

$regex_log_begin = “(.*):(.*) (.*) (.*) (.*) ((.*):(.*):(.*)) (.*)“;
$var_pixhost=7;
$var_pixmonth=3;
$var_pixdate=4;
$var_pixyear=5;
$var_pixtime=6;

The numbering happens left to right and the color coding should help this make sense. The ()’s around the grey time entry are grouped together and count as one match/entity, the sixth variable. The hostname is still detected properly as the last match.

Don’t forget syslog-ng!
Now that rsyslogd is now working, take a look at syslog-ng formatted with ISODATE (the log is pre-color-coded this time):

2008-02-29T12:43:16-05:00 pix-test Feb 29 2008 12:43:16: %PIX-6-110001: No route to 1.1.1.1 from 3.4.5.6

Notice the initial date/time stamp (ISODATE) is essentially one long phrase without spaces, regex can see that as a single match of (.*). syslog-ng has many options to format the syslog-ng output, not all include the timezone offset as part of the date/time stamp. One way to parse this initial message via regex is to use the following format:

$regex_log_begin = “(.*) (.*) (.*) (.*) (.*) (.*)“;

Remeber the portion of the syslog message being parsed is a subset:

2008-02-29T12:43:16-05:00 pix-test Feb 29 2008 12:43:16

The $var_ sequence will need to be adjusted to reflect these changes:

$var_pixhost=2;
$var_pixmonth=3;
$var_pixdate=4;
$var_pixyear=5;
$var_pixtime=6;

If your syslog-ng format is output using FULLDATE, this same entry would look like this:

2008 02 29 12:43:16 pix-test Feb 29 2008 12:43:16

This time, let’s use the pla_parser_regex_test to see what needs to be done:

You supplied the following log message:

     2008 02 29 12:43:16 pix-test Feb 29 2008 12:43:16

Resulting in these matches using a default regex filter of:

                 (.*):(.*) (.*) (.*) (.*) (.*) (.*)
_________________________________________________________

]> match 1: 2008 02 29 12:43
]> match 2: 16
]> match 3: pix-test             (default pixhost)
]> match 4: Feb                    (default pixmonth)
]> match 5: 29                      (default pixdate)
]> match 6: 2008                  (default pixyear)
]> match 7: 12:43:16             (default pixtime)
_________________________________________________________

Verify the log string you provided is correct Adjust your
regex_log_begin or var_pix settings accordingly!

If you have more than one substitution for each match, verify
the log message and the regex_log_begin filter string, you may
need to change something to get PLA running

If the default settings match up, no changes are needed.

Just run pla_parsed to start PLA

Each variable lines up, so the default regex and variable settings included with pla_parsed will correctly handle this format when used in syslog-ng.

Need help with a different format?
Have problems getting your PIX logs loaded? Paste in a sample message from your syslog server (IP Addresses santized please) in a comment below.

Regardless of your firewall vendor or monitoring method, there are five (5) statistics that will expose most security attacks / threats or at least alert you to significant suspicious activity. These approaches will also expose any misconfiguration issues in networks or systems and provide a minimal firewall log review policy.

Note: In order to take advantage of these statistics not only will some form of log monitoring be required, but also firewall rules that ACCEPT traffic will need to log activity alowed. An IDS/IPS could also be used to determine the ACCEPTED statistics described below.

1. Top 5 Blocked Destinations
These Destinations could be Public or Private IP Addresses, depending on the firewall deployment. The key here is to determine whether these IP Addresses getting blocked are legitimate or the result of a virus infection, malware infestation, or well-intending user run amuck. A good monitoring system or script will provide a method to view what firewall events made up this list. In most cases, the originating system is unable to communicate with the destination host; however, the mere fact that a high volume of traffic was blocked is often an indicator of more suspicious activity.

2. Top 5 Blocked Service Ports (Destination Ports)
Reporting service ports being blocked can reassuring, but just as a high number of Destinations being blocked could be an indicator of nefarious activity, blocked ports can signal the same activity. Service ports typically available most organizations include web, secure web, email, file transfers, and streaming media. Excessive Service Ports being blocked can indicate attempted information leakage, compromised hosts, or virus activity. Excessive Service Ports being blocked can also indicate broken applications, malfunctioning server software, or hosting provider upgrades that are being blocked by your firewall. Wikipedia’s List of TCP/IP Ports can help identify malicious ports as well as standard application ports.

3. Top 5 Accepted Sources
This statistic is a reality-check for servers, power-users, and services. Most organizations deploy some form of server services that provide file sharing, electronic communications, and printing services. Organizations should expect to see those systems or hosts as their top Sources or Top Talkers and when other systems or hosts appear in this Top 5 list, some measure of caution should be exercised to ensure each source is validated. Common causes for unexpected systems appearing on this could be recent upgrade/update for application or system (AV Update across all desktops or Microsoft Patch Tuesday update), network-based backup activity, or compromised system uploading company / personal data offsite.

4. Top 5 Accepted Service Ports (Destination Ports)
Once again, organizations traditionally provide a consistent framework of services in order to conduct business. These services include file sharing, network printing, email services, and web services. If the Top 5 Accepted Service Ports for your organization are not among these ports, a deeper inspection of the identified ports may be needed. Wikipedia’s Listing of TCP/IP Ports can expedite research.

5. Bottom 5 Accepted Sources
Lastly, it is important to understand the statistical importance of the most unique sources passing through your firewall because this method of rudimentary anamoly detection can be very insightful. Here you are again looking at traffic that passed through your firewall, but you’re concerned with the most unique traffic sources because often times attackers or insiders will try to hide in plain sight hoping a high volume of network traffic will obscure they tracks. This statistic will help isolate traffic that could be probing for access by users, employees, clients, etc.

Check-out Log Management, if you don’t have any system in place to automatically generate these and other useful statistics.

Small and medium-sized businesses looking beyond $75 DSL/CableModem router/firewalls and wishing to ensure their business is secured, can look to the Cisco PIX Firewall as a stable and reliable firewall platform that is easy on the pocket. Cisco PIX firewalls are great “standard” firewalls for small and medium-sized businesses that want a firewall they can install and forget about, not that we advocate forgetting about your firewall but you might forget you have it installed because they just work!

Cisco is phasing out the PIX models in favor of the newer Adaptive Security Appliance, which means these PIX firewalls can be picked up off eBay and technology refurbishing sites for a fraction of the original cost.

If you purchase a PIX or already have one, then you know it is often hard to answer “What’s Going On”. The logging produced from a Cisco PIX firewall is difficult to manage without some form of management platform regardless of whether the Cisco’s new web-based configuration / monitoring interface is installed.

We recommend PIX Logging Architecture (PLA) for organizations interested in seeing what’s going inside their Cisco PIX firewall as a strong open-source, low investment solution. (Excellent write-up on PIX Logging Architecture.)

Organizations open to spending more capital for logging / monitoring their firewalls can check-out this article on Log Management. 

CAUTION: We’re still installing theme packs and tweaking CMS templates, but the content is rolling in.

We specialize in IT, LAN, WAN, Security, Compliance, Privacy, Project Management, Technology services and consulting.

Our mission: to self-enable small and medium-sized business by offering our 30 years of Fortune 250 consulting expertise in the form of eBooks, white papers, blog posts, and webinars.

Contact us at info@bettertechinfo.com or leave a comment.