Ruleset manual - F

Transkrypt

Ruleset manual - F

RULESET DEFINING MANUAL
Manual Version: 0.9.1
Software version: 0.6.0
Last Revision: June 09, 2011
CC Open Computer Systems Ltd.
Network Security
Contents
1 Introduction..............................................................................................................................4
1.1 What is a F-Deets ruleset..................................................................................................4
1.2 Where are they located.....................................................................................................4
1.3 How to modify them.........................................................................................................4
2 Ruleset elements......................................................................................................................5
2.1 Introduction......................................................................................................................5
2.2 Parsing rules.....................................................................................................................5
2.2.1 Rule...........................................................................................................................5
2.2.2 Detailed Rule............................................................................................................5
2.2.3 Detailed Rule Definition...........................................................................................6
2.2.4 Detailed Rule Reference...........................................................................................6
2.3 Rule elements...................................................................................................................6
2.3.1 Main regex................................................................................................................6
2.3.2 Check........................................................................................................................7
2.3.3 Name.........................................................................................................................7
2.3.4 Parameters.................................................................................................................7
2.3.5 Dummy parameter....................................................................................................7
2.3.6 Special Message parameter.......................................................................................8
2.3.7 Actions......................................................................................................................8
2.4 Other.................................................................................................................................9
2.4.1 Color definition.........................................................................................................9
2.4.2 Regex definition........................................................................................................9
2.4.3 Load command.........................................................................................................9
2.4.4 Comments...............................................................................................................10
2/26
ul. Rakowiecka 36
tel. +48 22 646-68-73
e-mail:[email protected]
02-532 Warszawa
fax +48 22 606-37-80
Web: http://www.cc.com.pl/
CC Otwarte Systemy Komputerowe Sp. z o.o. zarejestrowana w Wydz.XIII Gospodarczym KRS, pod nr 0000023570, zarząd:
Grzegorz Blinowski – Prezes Zarządu, Tomasz Ramsza - Członek Zarządu; Kapitał zak.:100000 PLN
Network Security
3 Creating rules.........................................................................................................................11
3.1 First rule..........................................................................................................................11
3.2 Using wildcards..............................................................................................................11
3.3 Categorizing logs............................................................................................................12
3.4 Coloring logs..................................................................................................................13
3.5 Two detailed rules in one rule........................................................................................13
3.6 Removing unwanted log fragments................................................................................15
3.7 Referencing detailed rule................................................................................................15
3.8 Modifying parameter values...........................................................................................16
3.9 Required and defining rules...........................................................................................16
3.10 Continue, skip and nomessage actions.........................................................................17
3.11 Using dummy parameters.............................................................................................17
4 How does the parser work......................................................................................................19
4.1 Ruleset loading process..................................................................................................19
4.2 Ruleset compilation........................................................................................................19
4.3 Parsing process...............................................................................................................20
5 Appendixes.............................................................................................................................21
5.1 Appendix A: A complete list of directives......................................................................21
5.2 Appendix B: Actions and their behavior........................................................................22
5.3 Appendix C: Predefined general message parameters...................................................26
5.4 Appendix D: Supported date formats.............................................................................26
3/26
ul. Rakowiecka 36
tel. +48 22 646-68-73
02-532 Warszawa
fax +48 22 606-37-80
Network Security
1 Introduction
This document describes the language used to create customized F-Deets parsing
rulesets. The rulesets define how the information from log messages transmitted to F-Deets
syslog is extracted. While relatively simple and intuitive, the F-Deets ruleset language is a
powerful tool that can be utilized to further enhance F-Deets usability.
1.1 What is a F-Deets ruleset
F-Deets ruleset is an ordered list of parsing instructions used by the paser to extract
information from logs. The rules are processed from top to bottom, one-by-one, until the log
message fits one of them. The rule is then applied to this message and the parser proceeds to
next log message.
There can be more than one ruleset. Parser will process them in the order they are
defined in configuration file until one of them recognizes the message. If it is not recognized,
the message is stored anyway (and an entry in the application log is created with WARN level
informing about unrecognizable event).
1.2 Where are they located
All rulesets are stored in {Application directory}/aid/def folder. This is the
default location the parser searches.
1.3 How to modify them
To modify a ruleset simply use a text editor of your choice. Warning: If there are any
syntaxerrors ine the ruleset file the parser service will not start. All errors will be reported at
WARN level or greater in parser log file {Application directory}/applog/aid.log.
Be sure to keep backup of the original files. In case they get corrupted you may have to
reinstall F-Deets completely to restore them.
These rulesets may be treated like a simple scripting or markup language. While
flexible, there are some restrictions that must be obeyed in order for them to work properly.
Even if the parser successfully compiles the rulesets, it may behave in a different way than the
rulesets creator intended. Make sure to verify it's behavior after creating rules.
4/26
ul. Rakowiecka 36
tel. +48 22 646-68-73
02-532 Warszawa
fax +48 22 606-37-80
Network Security
2 Ruleset elements
2.1 Introduction
The main element of a ruleset is a rule, which can consist of any number of detailed
rules (this includes no detailed rules at all). In a rule or detailed rule actions may appear. They
either modify parser's behavior or a value they are related to. Rule and detailed rule may have
a check element, which is used to check whether this rule should be applied to given message.
Detailed rules may have any number of parameters, which correspond to regex match groups
in the order they are defined in detailed rule.
The behavior of certain elements may vary depending on where they are defined. The
same action may do something for parameter than for a detailed rule.
All these elements, their behavior and usage are explained in further sections of this
manual.
The elements' directives are case insensitive, which means you can either write RD, rd,
rD or Rd. Remember that regexes are still case-sensitive!
2.2 Parsing rules
There are two types of parsing rules: Rules and Detailed Rules. A rule can consist of
any number of detailed rules. Rules contain no parsing information directly, they are used to
aggregate detailed rules into one functional entity.
2.2.1 Rule
A rule is the uppermost element of a ruleset. It usually corresponds to one message and
is designed to extract all information from this message. Rule should contain an, as simple as
possible while still distinctive, check element to increase parsing speed.
RD: a name of a rule
CH: this regex must be found in the message to match the rule
Once a message is matched against a rule, no other rules will be used for this message
unless a continue action is encountered.
2.2.2 Detailed Rule
A detailed rule is an element of a rule and it must be declared after a rule. It consists of
a regex string, possibly a check instruction, and any number of actions and parameters. The
5/26
ul. Rakowiecka 36
tel. +48 22 646-68-73
02-532 Warszawa
fax +48 22 606-37-80
Network Security
amount of parameters must be the same as amount of match groups in the regex. If the
amounts differ, parser will report error in the log file and will not start.
DR: a regex for this rule
CH: any check string
2.2.3 Detailed Rule Definition
A detailed rule definition is a named detailed rule which can be used multiple times. It
must contain a name element, and by using this name with Detailed Rule Reference
instruction it can be used in any amount of rules.
Detailed Rule Definition can occur anywhere, though it is strongly encouraged to
define them before all rules.
DRD: a regex of the detailed rule definition
N: name of the detailed rule
2.2.4 Detailed Rule Reference
After defining a named detailed rule it can be referenced in any rule. Aprat from
having body defined elsewhere, detailed rule references act exactly the same as detailed rules.
RD: any rule
DRR: an existing detailed rule name
2.3 Rule elements
So far only the ruleset logical structure has been covered. The elements of parser rules
play a different role – they define the data to be extracted and the modifications that will be
applied to this data.
2.3.1 Main regex
The main regex is located after the detailed rule directive. It can have any length and
any number of matching groups. If the regex is invalid, an error will be reported in the same
way.
DR: here goes the detailed rule's regex
The regex will be matched against the log if any part of the log matches it, i.e. regex
“cats” will be successfully matched against “Mike loves cats and dogs”. There is no need to
6/26
ul. Rakowiecka 36
tel. +48 22 646-68-73
02-532 Warszawa
fax +48 22 606-37-80
Network Security
include start/end wildcard (like ^.* or .*$) in the regex. If the regex is to complex (contains to
many .* wildcards), the parser might not be able to use it and will quit and report error in the
log.
2.3.2 Check
Check is used to verify whether given rule or detailed rule should process a log
message. A rule should contain a check element. Detailed rule may, but doesn't have to. Log
message is matched against the check regex and the rule/detailed rule is processed if and only
if the matching was successful.
RD: a traffic rule
CH: traffic
2.3.3 Name
Name element may occur only in detailed rules. By defining a name we get two
benefits: the same rule can be used again by calling detailed rule reference command and, in
case there are errors in this rule, it's name appears in the application log.
Detailed rule definitions must contain a name.
DR: traffic shaping
N: a simple name
2.3.4 Parameters
Parameter elements define the names of data extracted from log messages. Each
parameter corresponds to one match group exactly in the order they were defined. For regex:
IP=(.*) port=(.*) and two parameters IP and port, the first match group would be assigned to
IP and the second to port. The name of the parameter will be available as a column in F-Deets
gui as soon as it is encountered in a valid ruleset.
DR: param1=(\w+) param2=(\w+)
P: param1
P: param2
2.3.5 Dummy parameter
Dummy parameter is a special name which can be used to perform an otherwise
impossible modification to the log message. The value of this parameter will not be stored in
7/26
ul. Rakowiecka 36
tel. +48 22 646-68-73
02-532 Warszawa
fax +48 22 606-37-80
Network Security
the database. The usage of dummy parameters is extensively covered in Creating Rules
tutorial later in this document.
The example below shows a detailed rule which will remove “we don't like this part of
log” from incoming message.
DR: (we don't like this part of log) param2=(.*)
P: dummy
A: delete
P: param2
2.3.6 Special Message parameter
A message parameter will automatically be added to the parsed results and it will
contain the part of the log remaining after the rule has been applied (some parts of the log
may be cut using actions). If you use a parameter called message, it's value will be
overwritten automatically.
2.3.7 Actions
Actions can be used to influence parser's behavior or modify either parameter values
or the log messages. Some actions have different behavior depending on the preceding
element.
Actions can be assigned to rules, detailed rules or parameters. They do not need to
appear immediately after these elements, they will be applied to the nearest above defined
element of any of these types. An example of action-packed rule:
RD: start of line
CH: NetScreen device_id
A: continue
A: defining
A: required
DR: \w+?: NetScreen device_id=(.*?)\s
A: delete
P: MachineAlias
Some actions require additional parameter, some do not. If they do, the parameter
should be added after the action's name and be separated from it by a space.
Certain actions can not be applied in certain elements. Consult Appendix B for details.
8/26
ul. Rakowiecka 36
tel. +48 22 646-68-73
02-532 Warszawa
fax +48 22 606-37-80
Network Security
2.4 Other
Either of the following elements can occur anywhere in the ruleset file. It is strongly
encouraged, however, to keep their locations logical so the ruleset remains easily readable.
2.4.1 Color definition
Color definitions assign string aliases to RGB colors. The defined strings can then be
used in combination with color action. The definition looks like this:
color: red #FF0000
Colors do not need to be defined before they are used.
2.4.2 Regex definition
A reusable regex can be defined like this:
regex: IP \d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3}
The first string (no spaces allowed) is the regex's name and the remaining characters
are the regular expression itself. It can then be used in a detailed rule regex (or check regex) in
this way:
IP address (##IP##) is assigned
This can be especially useful for long and error-prone regexes. It also makes
modifying often-occurring regexes much simpler.
Regexes do not need to be defined before they are used.
2.4.3 Load command
Load command can be used to include a ruleset from file. You may want to have all
your regexes or colors defined in different files. Large parsers can be divided into smaller
parts for readability's sake.
If
the
file
location
is
not
absolute,
the
parser
searches
{Application directory}/aid/def folder. Using subdirectories is also possible:
load: regexes/regex_set_1.def
will try do open {Application directory}/aid/def/regexes/regex_set_1.def
file.
9/26
ul. Rakowiecka 36
tel. +48 22 646-68-73
02-532 Warszawa
fax +48 22 606-37-80
Network Security
The loaded file must be a valid ruleset file. It is not possible to have half of a rule
defined in one file, and half in the other. The loaded file can, however, reference regexes,
colors and detailed rules from the file which loaded it. The loading file may also use the
objects defined in the loaded file.
2.4.4 Comments
Comments can occur anywhere in the ruleset file. They start with # char and always
cover the while line. It is not possible to create a comment after an instruction.
10/26
ul. Rakowiecka 36
tel. +48 22 646-68-73
02-532 Warszawa
fax +48 22 606-37-80
Network Security
3 Creating rules
This sections explains in detail how to write rules for F-Deets. We believe in learning
by doing, so we will be preparing real rules for parsing messages from screenos devices.
3.1 First rule
We will start with something simple. We want to parse the following message.
Traffic shaping is turned on
Let's create a rule:
RD: traffic shaping
CH: traffic shaping is turned on
DR: traffic shaping is turned (on)
P: state
Let's go through it line by line. The RD: directive creates a new rule and assigns it the
name traffic shaping. The next line contains a check element. It means that the rule will be
applied to log message only if the message contains traffic shaping is turned on string.
DR: element defines a detailed rule with one match group. We want to extract one
information from it – the state of the traffic shaping feature – so we surround the state value
with match group delimeters ( and ) and add one parameter state.
If we applied this rule to the message, in F-Deets we would actually receive an entry
with two parameters: state with value on and parameter message containing the whole log.
3.2 Using wildcards
What would happen if we received a message:
Traffic shaping is turned off
The rule we've created before would not parse this message, since the check element
would not be fulfilled. Let's modify the rule to match the new message:
11/26
ul. Rakowiecka 36
tel. +48 22 646-68-73
02-532 Warszawa
fax +48 22 606-37-80
Network Security
RD: traffic shaping
CH: traffic shaping is turned
DR: traffic shaping is turned (.*)
P: state
We've done two things: shortened the check string by removing on from it. Now the
parser will match both messages with this check. Secondly, we switched matching group
contents to wildcard .* which means that any string can fit this match group.
Now we've got a rule that actually parses two slightly different messages. The state
value will be either on or off, and the whole message will still be saved.
3.3 Categorizing logs
Category is an important parameter and it can be set in two ways. First, we can simply
define a parameter called category and match it against any part of the message we want. For
a rule like this:
RD: traffic shaping
DR: (traffic) shaping is turned (.*)
P: category
P: state
We would get a traffic category. Notice that the category parameter has been inserted
before the state, because the match group for traffic is before the match group for state.
The second way is to use an action. Our rule would then look like this:
RD: traffic
A: category
CH: traffic
DR: traffic
P: state
shaping
traffic
shaping is turned
shaping is turned (.*)
Notice that the action is defined after the rule definition. In this case it could be
defined after detailed rule and it would have the same effect. However, if you have many
detailed rules in one rule, each detailed rule may define it's own category. If the detailed rule
is matched, it's category will replace the earlier category assigned to this log.
12/26
ul. Rakowiecka 36
tel. +48 22 646-68-73
02-532 Warszawa
fax +48 22 606-37-80
Network Security
3.4 Coloring logs
Coloring logs is achieved through a color action. If we wanted to color our rule blue, it
would look like this:
RD: traffic shaping
A: category traffic
A: color #0000FF
P: state
We can also define the color earlier as a string, using the color directive:
color: blue #0000FF
RD: traffic shaping
A: category traffic
A: color blue
P: state
The color name will be converted to the number in while compiling ruleset. If you
modify the color's value the change will not propagate to earlier-parsed logs.
3.5 Two detailed rules in one rule
One rule may contain more than one detailed rule (or might not contain any at all, the
message would only be stored then). To illustrate this we will prepare a rule for such two
messages:
NTP server is disabled on interface ethernet0/5
NTP server is enabled on interface ethernet0/4, mode: control
This message contains two parts. First defines the state of the NTP server, the second
defined the server's mode. However, the second part occurs only when the NTP server is
enabled. Let's create a rule capable of parsing both of these messages:
13/26
ul. Rakowiecka 36
tel. +48 22 646-68-73
02-532 Warszawa
fax +48 22 606-37-80
Network Security
RD: NTP server is dis/en abled
CH: NTP server is
DR: server is (enabled) on interface (.*), mode: ?(.*)
CH: enabled
P: state
P: interface
P: mode
DR: server is (disabled) on interface (.*)
CH: disabled
P: state
P: interface
Each of the detailed rules contains a check element. The first is applied only when
there is a word enabled inside the message, the second, if disabled occurs. This is a crude way
of doing this, but it certainly works. By keeping the checks simple, we ensure that the parser
works quickly.
Let's try to make a rule doing the same thing, but in a different way:
RD: NTP server is dis/en abled
CH: NTP server is
DR: server is (.*) on interface (.*)(?:$|,)
CH: enabled|disabled
P: state
P: interface
DR: mode:(.*)
CH: mode
P: mode
The first detailed rule gets the state and interface, regardless of whether the server is
on or off, and the second detailed rule finds the server's mode if it is specified.
Notice the (?:$|,) after the interface match group. Since we use a general (and greedy!)
wildcard which fits any string, for this message
NTP server is enabled on interface ethernet0/4, mode: control
the parameter interface would be equal ethernet0/4, mode: control if we hadn't used the (?:$|,).
It would also be possible to define the interface string in a better way, like this:
#regex interface [A-Za-z]+\d/\d
Which would allow us to skip the (?:$|,) wildcard.
14/26
ul. Rakowiecka 36
tel. +48 22 646-68-73
02-532 Warszawa
fax +48 22 606-37-80
Network Security
3.6 Removing unwanted log fragments
Sometimes we want to remove a part of a message. It can make the log less readable,
it can contain redundant information. We received the following message:
PASSWORD authentication successful
172.22.110.27. (2011-02-15 02:01:01)
for
admin
user
'backup'
at
host
And we want to remove the date time part at the end of the line while saving its value
as a parameter. So we prepare a detailed rule to do it:
DRD: $(\d{4}-\d{2}-\d{2}\s+\d+:\d+:\d+)$
N: time at the end of line
A: delete
P: timeserver
This is a detailed rule reference, which can be used in any rule. When building the
regex we should be as precise as possible to reduce parser's matching time.
The most important part of this rule is the delete action. Placing it after the rule
definition means, that the part of the log message matched against this regex will be removed
from the message. So after applying this rule to our message, the remaining part would be:
PASSWORD authentication
172.22.110.27.
successful
for
admin
user
'backup'
at
host
So we've gotten rid of the unwanted part. If we didn't want to store the value at the end
of the line, we would have to remove the grouping brackets from regular expression and
remove the timeserver parameter .
3.7 Referencing detailed rule
In the previous example we've defined a named detailed rule which removes a part of
a message. How do we use it in a rule? A complete rule parsing the previous message would
look like this:
15/26
ul. Rakowiecka 36
tel. +48 22 646-68-73
02-532 Warszawa
fax +48 22 606-37-80
Network Security
RD: authentication successful for admin
CH: authentication successful for admin
A: category security
DRR: time at the end of line
DR: (.*) authentication successful for
(##IP##)\.
P: auth type
P: user
P: sourceip
admin
user
'(.*)'
at
host
By using the DRR instruction we include the previously defined detailed rule in this
rule.
3.8 Modifying parameter values
After each parameter there can be any number of actions that modify it's value. The
possible actions are:
•
•
•
•
•
•
deletestr <str> - deletes str from the parameter's value
replace <str> - replaces the parameter's whole matched value with given string; if used
with dummy parameter, will replace the matched string with given string in the
message itself
insertbefore <str> - inserts the given string before the parameter's value
insertafter <str> - inserts the given string after the parameter's value
tolowercase – converts the parameters value to lowercase characters
touppercase – converts the parameters value to uppercase characters
3.9 Required and defining rules
Some actions can be applied to rules. The required action marks a rule or a detailed
rule and causes a parser to finish working when such a rule is not matched. If a message from
given device contains some distinguishing elements, such required rule can be used to boost
parser's efficiency. Instead of trying to apply all it's rules to a message, it will stop working
after not matching a required rule and proceed to next ruleset.
3Defining rules have opposite meaning. If such rule is matched, the parser will
permanently assign its ruleset to the IP address of the device that sent this message. It will not
try to use other rulesets for this device, therefore improving performance.
Great caution must be taken when creating defining and required rules. Making a too
restrictive required rule might make some messages unparseable. Making a not restrictive
enough defining rule may assign a wrong parser to a device.
Here is an example of both defining and required rule:
16/26
ul. Rakowiecka 36
tel. +48 22 646-68-73
02-532 Warszawa
fax +48 22 606-37-80
Network Security
RD: start of line
CH: NetScreen device_id
A: continue
A: defining
A: required
DR: \w+?: NetScreen device_id=(.*?)\s
A: delete
P: MachineAlias
3.10
Continue, skip and nomessage actions
A continue action can be defined for either rule or detailed rule. If rule with this action
is fulfilled, the parser will not stop processing the ruleset and will continue to next rules. This
can be useful for removing constant-syntax parts of the message, like, for example, source IP
or time.
If a skip action is defined for a rule or detailed rule, then the messages matched against
this rule will simply not be saved to F-Deets database.
Nomessage action is also defined in rule or detailed rule and, when encountered, will
tell the parser not to save the message parameter automatically. By default, the whole message
remaining at the end of the parsing will be saved as a message parameter.
3.11
Using dummy parameters
A dummy parameter has been mentioned before. It can be used to perform changes on
a part of a log message using normal grouping regexes without creating unnecessary
parameters.
For example, we have such message:
Certificate cert1 with expiration date 2011-03-21 has expired
And we want to convert it to:
Certificate cert1 has expired on 2011-03-21
To do this, we can make the following rule:
17/26
ul. Rakowiecka 36
tel. +48 22 646-68-73
02-532 Warszawa
fax +48 22 606-37-80
Network Security
RD: simple convert rule
CH: with expiration date .* has expired
DR: (with expiration date) .*( has expired)
P: dummy
A: replace has expired on
P: dummy
A: delete
The first match group will be replaces with has expired on string, and the second (after
the date) will be deleted. Neither matching group will be saved as a separate field for this log
message. The whole text, after modification, will be saved as message by default.
18/26
ul. Rakowiecka 36
tel. +48 22 646-68-73
02-532 Warszawa
fax +48 22 606-37-80
Network Security
4 How does the parser work
In order to process log messages, the rulesets first need to be loaded. The parser opens
devices.cfg file from config directory and loads all the rulesets defined there. Also, it
may associate the ruleset with an IP address if one is defined in the config file.
After the configration file has been read, all the rulesets are loaded and pre-parsed. If
there are any syntax errors, an appropriate message will be appended to aid.log in applog
directory and the parser will stop working.
When there are no syntax errors – the ruleset will be compiled. All regexes will be
prepared, regex, color and detailed rule references will be resolved. If any of these stages
fails, the parser will append a message to log and quit. After all rulesets have been
successfully loaded, the parsing commences.
All errors will cause the parser to quit. If you modified a ruleset and the parser process
doesn't start, consult aid.log for details.
4.1 Ruleset loading process
When the file is successfully opened and read, each line is parsed one by one.
Comment lines are silently skipped, so are empty lines. The order of instructions is verified
(parameter must be defined after a detailed rule, detailed rule can not be defined without a
rule, etc). The actions locations are also validated – some of them must be assigned to
parameters, some to rules. If there is a misplaced action it will be reported in this stage. The
same goes for unrecognized instructions, unrecognized actions and actions lacking required
parameters.
4.2 Ruleset compilation
In this stage all dynamic elements are resolved. This includes colors, regexes and
detailed rules. After resolving regular expressions references, the resulting expressions are
also validated.
This operation takes place after executing all load commands, so cross-file references
are possible and will not cause an error.
Unrecognized references and invalid regexes will result in the parser not running. All
errors will be reported in aid.log file.
When the ruleset is verified, the encountered parameters are synchronized with the
database. If you have used your own, new parameter names, they will be available in F-Deets
GUI after compiling was successful.
19/26
ul. Rakowiecka 36
tel. +48 22 646-68-73
02-532 Warszawa
fax +48 22 606-37-80
Network Security
4.3 Parsing process
A log message is processed by all rulesets until one of them reports that it recognized
the message. Inside one ruleset, the message is matched against all rules. If the message
fulfills the rule's check, then all of this rule's detailed rules are applied to the message.
Detailed rule may contain a check element and if it does, the message is matched
against it. If it passes or there is no such element specified, the detailed rule's main regex is
used to extract information from the message, modify the message, etc. If the rule or any of
it's detailed rules contains continue action, then parsing is continued in the same ruleset.
If there are not non-continue rules that matched against this message, the parser
proceeds to the next ruleset. The parsed message is isolated for each ruleset, so even if it has
been modified by any rules in one of the rulesets, the message will return to original for next
rulesets.
If a skip action has been applied, the log message will not be saved into F-Deets
database. For a defining action the devices.cfg configuration file will be updated with new
IP/ruleset mapping.
20/26
ul. Rakowiecka 36
tel. +48 22 646-68-73
02-532 Warszawa
fax +48 22 606-37-80
Network Security
5 Appendixes
5.1 Appendix A: A complete list of directives
Direct Name
ive
Parameters
Location
Action
RD
Rule
Definition
Name
Anywhere
Create a new rule
DR
Detailed Rule Regex
After RD
Create a new detailed
rule
DRD
Detailed Rule Regex
Definition
Anywhere
Create a new, named, Required N directive
detailed rule
DRR
Detailed Rule Name
Reference
After RD
Reference a previously
defined detailed rule
CH
Check
Regex
After RD or Check if rule applies to Should be as simple as
DR
message
possible
N
Name
Name
After DR or Associates a detailed Necessary for DRD, for DR
DRD
rule with a name
useful for debugging log files
P
Parameter
Name
After DR or Associates a matching
DRD
group with a name
A
Action
Name
parameter
After RD, DR, Creates an action for
DRD or P
given element
Name regex
Anywhere
Creates a regex alias
Preferably defined at the
beginning of a file
regex Regex
definition
Comment
load
Load
file Filename
instruction
Anywhere
Loads a definitions file
beginning of a file
color
Color
definition
Anywhere
Creates a color alias
beginning of a file
name
#RRGGBB
21/26
ul. Rakowiecka 36
tel. +48 22 646-68-73
02-532 Warszawa
fax +48 22 606-37-80
Network Security
5.2 Appendix B: Actions and their behavior
defining – if a rule with this action is fullfilled, the currently processed log is marked
as defining, which means that the IP address of the device will be permanently associated with
the parser that contains this action.
Applies to: RD, DR, DRD
required – if a rule with this action is not fulfilled, the parser stops execution and the
log message processing proceeds to next parser.
continue – if a rule with this action is fulfilled, the parser will still process next rules.
Useful for cutting unchanging elements of the message.
nomessage – if a rule with this action is fulfilled, the parser will not save the message
parameter to the database.
skip - if a rule with this action is fulfilled, the parser will not save any information
about this message to the database.
category - if a rule with this action is fulfilled, the category of the message is set to
action's parameter.
color - if a rule with this action is fulfilled, the color of the message is set to action's
parameter. The parameter can be either #RRGGBB code or an alias defined through color
instruction
delete – the action depends on the place if was used:
DR, DRD: removes the whole matched regex from the log string. For a message:
Admin user backup has logged on via SSH from 192.168.1.44:36933
and a rule:
22/26
ul. Rakowiecka 36
tel. +48 22 646-68-73
02-532 Warszawa
fax +48 22 606-37-80
Network Security
DR: Admin user (.*) has
A: delete
P: user
The message would be transformed to:
logged on via SSH from 192.168.1.44:36933
P: removes the parameter's value from the log string. The parameter is still assigned the
proper value. For a message:
and a rule:
P: user
A: delete
Admin user has logged on via SSH from 192.168.1.44:36933
Applies to: DR, DRD, P
deletestr – removes the given string from associated element.
DR, DRD: removes a string from a message. For a message:
and a rule:
A: deletestr Admin user
P: user
backup has logged on via SSH from 192.168.1.44:36933
P: removes a string from a the parameter value message. The log message remains
unchanged. For a message:
and a rule:
23/26
ul. Rakowiecka 36
tel. +48 22 646-68-73
02-532 Warszawa
fax +48 22 606-37-80
Network Security
P: user
A: deletestr bac
The user parameter's value would be
kup
The action would change if one used the dummy parameter. Consider this rule:
P: dummy
A: deletestr bac
It would transform the message, in the same way as in the first case, to:
Admin user kup has logged on via SSH from 192.168.1.44:36933
Applies to: DR, DRD, P
replace – replaces the associated parameter's value with given string. For a message:
and a rule:
P: user
A: replace AN USER
The user parameter value wolud be AN USER. However, for a message:
and a rule:
P: dummy
A: replace AN USER
It would transform the message to:
Admin user AN USER has logged on via SSH from 192.168.1.44:36933
insertbefore – insets the given string before the associated element.
DR: inserts the string before the whole matched message. For a message:
and a rule:
24/26
ul. Rakowiecka 36
tel. +48 22 646-68-73
02-532 Warszawa
fax +48 22 606-37-80
Network Security
DR: from ##IP##
A: insertbefore _protocol
The resulting message would be:
Admin user backup has logged on via SSH protocol from 192.168.1.44:36933
Remember, that for action values the _ character will be translated into space. A space at the
start/end of a value will be trimmed.
P: inserts the string before the matched parameter's value. Affects only the parameter itself.
For a message:
and a rule:
P: user
A: insertbefore mr.
The user parameter's value would be :
mr.backup
Have we used dummy parameter instead of user, the behavior would be different - the log
message would be modified. For exactly the same message and rule like this:
P: dummy
A: insertbefore mr.
The resulting message would be:
Admin user mr.backup has logged on via SSH protocol from 192.168.1.44:36933
And, of course, the dummy parameter would not be stored.
insertafter – behaves exactly like insertbefore, except that it inserts the value after
matched string or at the end of parameter.
tolowercase – converts the related string value to lowercase
Applies to: RD, DR, DRD, P
touppercase – converts the related string value to uppercase
Applies to: RD, DR, DRD, P
25/26
ul. Rakowiecka 36
tel. +48 22 646-68-73
02-532 Warszawa
fax +48 22 606-37-80
Network Security
5.3 Appendix C: Predefined general message parameters
All these names are case-insensitive. They can not, however, contain any spaces. If
they do, they will be treated as different parameters.
DeviceName
DeviceIp
TimeSource
TimeServer
SourceIp
SourceDnsName
SourcePort
DestinationIp
DestinationDnsName
DestinationPort
SourceXlatedIp
SourceXlatedPort
DestinationXlatedIp
DestinationXlatedPort
Action
Category
MessageNumber
MessageType
MachineAlias
Message
5.4 Appendix D: Supported date formats
syslogd format: month d HH:MM:SS, examples:
Oct 17 14:52:13, Dec 1 01:34:51
ISO 601: YYYY-MM-DDTHH:MM:SS+HH:MM, examples:
2011-03-25T21:46:18+02:00, 2010-11-30T01:11:34
simple date time format, examples:
2010-07-30 14:59:01, 2011-03-11 09:13:48
26/26
ul. Rakowiecka 36
tel. +48 22 646-68-73
02-532 Warszawa
fax +48 22 606-37-80

Ruleset manual - F

Transkrypt

Podobne dokumenty

KREZUS S.A.

Network Security - F

TelForceOne SA ul. Krakowska 119, 50-428 Wroc 2-25

paper_plastic_removal_EN

Company Law

Enterprise JavaBeans 3.0 Overview Audience Prerequisites Course

Kraków, 16

Microsoft Outlook