The last, but not least, aspect to configure in LogIDS is the rules definition, handled by the file rules.txt. You will probably think I'm repeating myself, but great care has been put here also to provide with flexibility and ease of use. There are some details about the file rules.txt that you have to take into account however, if you want to achieve the desired results. It is with this file that you can alter LogIDS's behaviour and react to your liking to the various log entries it gets supplied with.
A rule is defined in three basic parts: the application that generates the log that the rule should apply to, a condition and an action item. These parts are all on the same line, separated by a comma. The application name have to match one of the applications you have defined the logs for in the file filter.txt (it can also be a * wildcard, although I'm not sure about the usefulness of this). The condition statement is in the form expr1 cond expr2
, where expr1
is one of the fields of the log that you want to check a condition upon, cond
is the reserved word for the condition you want to implement, and expr2
is the value that you want to test your field value against. The action is, at this version level, either display, alert, warning (or warn), icon, drop
or reject
. We will look deeper at the condition and the action fields in more details in the following paragraphs.
First of all, in the condition statement expr2 can have the wildcard value * (works with condition 'eq' only). Also, doing a condition check on only one value can be somewhat limitating, so the LogIDS rules engine allows for multiple conditions linked by AND
or OR
mega-conditions. If we take statement = expr1 cond expr2
, for simpler explanation purposes, we could have a condition check that could look like this : statement1 AND statement2 OR statement3 AND statement4
... You have to take note although that these mega-conditions AND and OR are evaluated sequentially, no matter what the normal mathematical conventions are on the precedence of these operators. For example, for the line we just gave as an example, the full condition would be evaluated as follows:
(conditions and mega-conditions are evaluated one after the other)
((((expr11 cond1 expr21) AND (expr12 cond1 expr22)) OR (expr13 cond3 expr23)) AND (expr14 cond4 expr24)) ...
as opposed to traditional mathematical logical operators precedence conventions, which would interpret the previous line as :
(AND mega-conditions have precedence on ORs)
((expr11 cond1 expr21) AND (expr12 cond2 expr22)) OR ((expr13 cond3 expr23) AND (expr14 cond4 expr24))...
which could generate different results. Take great care in this detail when writing up your rules.
expr1
is any field you have defined for this application's log in the file filter.txt. You can make a variety of checks to any of the fields you want, so you can refine your rules base as much as you want. Don't forget that depending on the format of some of your logs, LogIDS will prepare some of the information automatically available in variables that were not necessary defined as such in filter.txt (field source that breaks down in fields src_ip and src_port, for example, see previous chapter).
The allowed reserved words for 'cond' are the following : =, ==, <=, >=, !=, eq, ne, gt, ge, lt, le, ct, nc. = and == are equivalent, and with <=, >= and != these should be used to test numerical values only and are self-explanatory. eq, ne, gt, ge, lt and le are the same as their counterpart in Perl, which is string equals, not equals, greater than, greater or equal, lesser than and lesser or equal. ct and nc stands for string 'contains' or 'not contains' the value it is matched against. This is similar in implementation than Perl's =~m// and !(=~m//), or grep and !(grep) if you prefer. This allow for more flexible string pattern matching that simply eq and ne.
For expr2
in your condition string, you can use a wildcard * (valid for condition 'eq' only), and you can test IP addresses with eq or ne using wildcards just like we do in netdef.txt, which is in the form of 10.0.0.*. If the string contains more that a single word, you need to replace the empty spaces with _, so it does not interfere with the rest of the condition, which is space-delimited. You can also replace your whole condition string with a *, which will means that this rule will always check true when applied.
As mentioned earlier, the action field can have 6 properties (more may be defined in the future, depending on feedback from users); display, alert, warning, icon, drop and reject. We will look more in details about what each of these action statements actually mean. The simplest one of them is WARNING. This will cause the system to emit a beep sound each time this rule checks OK (to actually have a PC-speaker beep, you need to go in the Control Panel, go in the Sounds applet, and put the "Exclamation" and "Default Beep" to None. Playing Windows default wav files reduces drastically LogIDS performance). A bit more drastic, ALERT will behave in the same way, but with three beeps instead of one. If you have an application that reports large volume of data in a short amount of time, and you want sound alerts on these items, maybe you'll find the rule WARNING is more appropriate than ALERT, because the system can make a lot of noise if too many ALERT items are reported simultaneously. Another easy one is ICON=, where you can specify a 40 X 40 pixels icon to depict graphically the event the rule just checked true. For example, it could be the picture of a virus icon when the antivirus reports a virus, or a "virus cleaned" icon with the antivirus reports that the virus has been cleaned. I have made several icons depicting various kind of events that could be reported with the programs I was playing with when developing LogIDS, feel free to make your own depicting events that are related to your own environment. Feel free to send them to me so I can share them with the rest of the community on my website.
Another important action statement is DISPLAY=, where you get to choose which fields from your log record you find relevant to print in the test window associated with the reporting machine. You simply put the list of fields you want to be printed and by separating them with # (as '_', ',' and ' ' are already used in other segments of the rule line), in the order of appearance that you wish to dispose them. If you want to display the whole record with the fields in their original order, simply leave the list empty. DROP is used for the cases where you make a rule to determine non-important data that you don't necessarily want to be displayed in the graphical interface, but you still want to keep an eye on in the case it could be useful. DROP will print the whole record on the LogIDS console, the DOS-looking window behind the graphical console. REJECT can be used in the same conditions, but with REJECT the record will not get printed to the console. Only a notification of a REJECTed record will be displayed on the console.
Still coming back to our example model we have built upon since the beginning of this document, a very generic rules.txt file could look like this:
ZoneAlarm,host eq *,alert
ZoneAlarm,host eq *,display=type#date#time#ip#source#dest#transport
ZoneALARM,transport eq tcp,icon=desktopoutbounddenied.bmp
antivirus,ip eq *,alert
Antivirus,message eq infected,display=date#time#ip#username#virusname#infectedfile
Antivirus,message eq infected,icon=virus.bmp
Antivirus,message eq infected,alert
Antivirus,message eq cleaned,display=date#time#ip#username#virusname#infectedfile
Antivirus,message eq cleaned,icon=viruscleaned.bmp
Application Event,ip eq *,reject
Security Event,ip eq *,reject
System Event,ip eq *,reject
Snort,ip eq *,display=application#line
Running Services,ip eq *,display=display#servfilename#state#startup
Open shares,ip eq *,display=loghost#share#usergroup#rights#path
Startup config,ip eq *,display=loghost#line
ADS Scanner,ip eq * AND ads ct started,display=loghost#ads#size
ADS Scanner,ip eq * AND ads ct started,alert
Integrity checker,ip eq * AND line nc started,display=loghost#line
Integrity checker,ip eq * AND line nc started,alert
*,*,reject
Because of the nature of the rules.txt file, where you have to specify multiple rules in order to apply several actions on the same conditions, all rules are checked, and all rules that check OK are applied. This is why you can specify a *,*,reject rule at the very beginning of your rules file (although not necessarily recommended), and all the other rules will still be checked and applied if valid. This is somewhat different from firewall rules definition, for example, where only the first matching rule is applied. Also, if LogIDS have to deal with a log line that does not match any rules, it will be DROPed automatically (it will be printed on the console window). A rule in the form of *,*,reject may not necessarily be a good rule example, as it will cause LogIDS to report a REJECTed line at each line it reports, even if these lines have other rules that are previously applied to them. Still, I have put it here to give an example of the syntax and behaviour. Due to LogIDS 2.0 improved rule matching algorithm, the *,* rule will behave differently. It will be applied only if no other matching application has been found for the reporting item. This way, it acts more like a "catch-all" rule to handle unexpected log filenames. Still, use of the *,* rule should be considered as experimental only at this stage.
Now that we have configured all aspects of LogIDS properly, we are ready to launch it and test it.
6. Defining your log files filters
8. Graphical interface options