Using Wildcards and Regular Expressions

About this Document

This document is intended for system administrators and explains the use of wildcard characters and regular expressions, which are very powerful search tools to quickly locate multiple entries with similar, but not identical data in AXS Guard log files.

Log Formats

Parsed vs Raw Data

Raw log data (sometimes called source data, atomic data or primary data) is data that has not been processed for use, e.g. a raw firewall log entry:

11:12:36 INPUT DROP: IN=eth2 OUT= MAC=ff:ff:ff:ff:ff:ff:56:6f:01:00:00:06:08:00 SRC=10.10.10.254 DST=10.10.10.255 LEN=78 TOS=0x00 PREC=0x00 TTL=128 ID=8104 PROTO=UDP SPT=137 DPT=137 LEN=58 MARK=0x40040000  out\_dev\_type=LOCAL src\_host=windc-2019 in\_dev\_type=DMZ chain=INPUT jump=DROP

To improve readability, AXS Guard log entries are shown in a parsed state by default where possible. The parsed data is organized into columns in order to better distinguish the different data fields, but is also limited as a lot of raw data is sanitized.

An example of the same firewall log entry, but parsed:

Search Phrase Matching

Important

The AXS Guard search engine only processes raw data, not parsed data.

So when you want your search result to match INPUT DROP and eth2, you need to look at the raw data to know in which order you need to enter the search terms in the search field.

In the parsed view, eth2 appears before INPUT DROP, but in the raw view it's just the opposite. So you need to enter INPUT DROP before eth2 in the search field in order to trigger a match.

If we put eth2 before INPUT DROP, the search will not return any results (just ignore the .* characters in the image below, as we will explain their meaning later).

If we use the correct order, i.e. enter eth2 after INPUT DROP, the search will succeed.

Case Sensitivity

Before we start exploring the possibilities of regular expressions and wildcard characters, you need to be aware of case sensitivity.

The search fields contain an Aa button. If the button has a blue background, case sensitivity is enabled. This means that input is treated differently depending on whether it is in capitals or lower-case text.

We start with a case-sensitive example, looking for an exact match of input drop.

Since the log file only contains firewall actions and targets in uppercase letters, there is no match and there are no search results:

When you perform the same search using a case-insensitive search, you get the following result:

Regular Expressions & Wilcard Characters

There are plenty of websites that explain in great detail what you can do with regular expressions and wildcard characters. In this document, we only focus on a few examples that can easily help you to quickly get the desired search results.

Beginning and End of a Line

The beginning of a line is expressed by the ^ character.

Assume you want to search for all log entries that occurred between 9AM and 10AM.

You could search for 09:, but then the result will contain all occurrences of 09: somewhere in the log file, e.g. 01:03:09:ab:d5:8f or 01:09:35.

However, if you search for ^09:, the search result will only return lines that start with 09:. Since the first string in log entries consists of the time, you know that you are only looking at logs generated between 09:00:00 and 09:59:59.

The $ character represents the end of a line.

In the following example, we look for log entries ending with de, so we use the following regular expression: de$.

Wildcard Characters

You may already be familiar with wildcard characters from other types of searches, e.g. when searching for specific files or folders on your computer.

A frequently used wildcard character is *. The equivalent regular expression is .* (a period followed by an asterisk), which matches any number of any characters. A single period, i.e. . matches exactly one character, except the newline character.

So, if you want to search for log entries between 13:00 and 14:00 where the last digit is 5, you could use the following regular expression: ^13:.5. Pay attention to the . between the colon : and the number 5. This will return all entries for 13:05, 13:15, 13:25, etc.

If you want to look for a string in which a character occurs any number of times, you must use a quantifier.

Quantifiers

Quantifiers specify how many instances of a character, group or character class must be present in the input for a match to be found. The following table contains essential quantifiers that are supported by AXS Guard:

Quantifier	Description
+	Matches one or more times.
*	Matches zero or more times.
?	Matches zero or one time.
{ n }	Matches exactly n times.
{ n ,}	Matches at least n times.
{ n , m }	Matches from n to m times.

There are more combinations and possibilities, but in this document we just touch on the most essential ones. Following are a few examples.

Regex/String	abc	abbc	abbbc	ac
ab+c	match	match	match	No match
ab*c	match	match	match	match
ab?c	match	No match	No match	match
ab{2}c	No match	match	No match	No match
ab{2,}c	No match	match	match	No match
ab{1,2}c	match	match	No match	No match

So a search for ^13:5* will basically return all log entries starting with 13:. The number 5 followed by an aserisk * means that it can occur zero or more times, as shown in the following example, where the number 5 can, but does not even appear.

However, if you were to change the search query as follows: ^13:5+, it would return any time that matches 13:5, followed by any character, e.g 13:55 or even invalid times, such as 13:555, followed by any character and so on.

Character Escaping

Escape characters are special characters that can have many different functions, , e.g. ^, $, . or ?.

If you want to search for such a character using a regular expression, you need to escape it with a backslash character \. This will instruct the regex interpreter that the next character is to be interpreted literally and not as an escape character.

For example, if you want to look for a ? character, you need to escape it like so: \?.

Other examples include, but are not limited to \t to escape a tab character, \n to escape a newline character and \r to escape a carriage return. Fortunately, the AXS Guard logs won't usually require you to escape such characters.

Important

The AXS Guard tool does not allow the use of the \ escape character to prevent command injections.

Character Classes

A character class defines a set of characters, any one of which can occur in an input string for a match to succeed, for example wildcard characters.

There are other character classes that are useful to search through AXS Guard logs, for example:

• [abc] will match either a, b or c.
• [a] will match exactly the single character mentioned between the brackets.
• [a-d] will match any character in the range between a and d, including a and d.
• [^abc] will match any character that is not a, b or c.
• [^a-d] will match any character that is not in the a to d range, including a and d.

Space Character

The space character is a character that is interpreted literally by the AXS Guard search engine, for example:

Searching for DPT=88 without appending a space character:

Searching for DPT=88 with a space character appended: