can be described as a general rule based monitoring system which can run system commands in phases
Nuhe is a log monitoring system, which is capable of action when rulesare matched againsts log(s) activity. Motive for Nuhe development started from security point of view and one purpose is to use it as a intrusion protection system that can react against certain kind of log activity. You can also use Nuhe as a vanilla "log filtering" system, that detects events from logs, logs them, but does not react against them.
NUHE(1) General Commands Manual NUHE(1)
NAME
Nuhe - Action capable log file monitor and log analyzer
SYNOPSIS
nuhed [-rfhv] [-c <configfile>] [-s <file1> <file2> ...]
DESCRIPTION
Nuhe is a rule based log monitoring system, which is capable of action when rules are matched againsts log(s)
activity. Default Nuhe mode is to run on background (daemon), but it can also be used in foreground and log anaâ
lyzer mode. Log analyzer mode just analyzes given logs and prints results to stdout; no action is taken when
Nuhe is in analyzer mode.
AUTHOR
Tuomo Makinen <tjam@users.sourceforge.net>
Let me know if you found bugs or have ideas how to improve Nuhe. You can send comments, suggestions, fixes,
critics and Nuhe rules to me.
OPTIONS
-h Displays a brief usage summary.
-c <file>
Configuration file for Nuhe log monitor.
-r Redirect logging to stdout.
-s <file1> <file2> ...
Log files to scan; Nuhe will analyze each file against rules and print output to stdout.
-v Show version of Nuhe log monitor.
FILES
Configuration file
/usr/local/etc/nuhed/nuhed.conf
Default rule files
/usr/local/etc/nuhed/general.rules
/usr/local/etc/nuhed/openssh.rules
/usr/local/etc/nuhed/iptables.rules
/usr/local/etc/nuhed/ftpd.rules
/usr/local/etc/nuhed/email.rules
Saved pending events:
/usr/local/etc/nuhed/nevents.asc
Private key:
/usr/local/etc/nuhed/nuhed.key
/usr/local/etc/nuhed/nuhed.crt
Trusted CA file:
/usr/local/etc/nuhed/CAnuhe.pem
Logging file:
/var/log/nuhed.log
Pid file
/var/run/nuhed.pid
NUHE RULES
Default rule files for Nuhe are:
general.rules
general purpose rules
openssh.rules
OpenSSH specific rules
iptables.rules
Linux iptables specific rules
ftpd.rules
Ftp server specific rules
email.rules
Pop3 and Imap4 server specific rules
You can modify and add rules or add new rule files in nuhed.conf. Rule is composed of
action handler name, Pcre regular expression pattern and description fields.
e.g.
failed_passwd "Failed password for \S+ from (\S+)" "Failed user login"
With Pcre regular expressions you can specify match pattern againts contents of
monitored files.
Every rule needs action handler and action handlers can be shared between multiple
rules.
e.g.
failed_passwd
{
loglevel alert
}
This example is simplest form of action handler; it just logs every match and does not
use event handler.
Loglevel can be one of the following:
crit generates critical alert
alert generates normal alert
info generates informative alert
none does nothing (no logging)
Action handlers can have many more options, here is a summary of them:
rststring "Accepted password for (\S+) from (\S+)"
With rststring you can specify Pcre pattern which is used to reset event. Resetable
event is indentified by Pcre substrings; substrings from reset string and rule should
be same. You can specify rststring multiple times for one action.
rstphases 0 1
With rstphases you can specify action phases which allow event reset. If you want to
allow reset in every phase rstphases value must be 'all'.
rsttable 0:0 1:1 2:2
^ ^
| |
| ------- rststring substring
--------- rule substring
With rsttable you can specify which substrings from original rule are matched for
rststring substrings, when event is indentified. If sequence of substrings for rule
and reset string are same rsttable can be omitted.
manysources all
With manysources you can specify if event's counter is incremented only when match
is found from original alert source or if multiple alert sources are allowed.
By default multiple alert sources are allowed. If you do not want this, manysources
value must be 'one'.
logthreshold event
With logthreshold you can specify Nuhe to log alert only when action for event is
triggered.
usesubstr $1 .. $9
usesubstr specifies Pcre substrings which are used to identify events. By default
all matched substrings are used for event indentification.
ignorelist <string1> \
<string2> \
<stringN>
ignorelist is a list of strings which are ignored by event handler.
timelimit[n]
Timelimit specifies time value in seconds which is used together with eventcount to
trigger action for event (specified with command).
eventcount[n]
Eventcount specifies amount of events which must happen in specified time limit,
before action (speficied with command) for event is triggered.
command[n]
Specifies external command to be run after maximum number of events has occured in
specified time limit.
Here is an example of action that just executes some script after rule is matched:
failed_passwd
{
loglevel alert
command[0] "myscript.sh"
eventcount[0] 0
timelimit[0] 0
}
You can specify amount of alerts which should occur in specified time value before
command is executed:
failed_passwd
{
loglevel alert
command[0] "myscript.sh"
eventcount[0] 3
timelimit[0] 60
}
This action triggers external command after three alerts has occured in 60 seconds.
You can also run different commands in phases:
failed_passwd
{
loglevel alert
command[0] "firstscript.sh $1"
eventcount[0] 3
timelimit[0] 60
command[1] "secondscript.sh $1"
eventcount[1] 0
timelimit[1] 60
}
Now "secondscript.sh" is executed after 60 seconds "firstscript.sh" was executed.
If eventcount is set to 0, events are not used to trigger command; time limit is the
only criteria in second phase of action.
We also gave one parameter for scripts; substring no. 1. Substrings starts from 0, which
is whole string that is matched by Pcre. In our example rule, substring no. 1 captured
IP address from string.
You can also specify strings to be ignored when event is registered. Event is indentified
by matched Pcre substrings. Using ignorelist can be handy in some situations, like in our
example action below (failed_passwd) that runs iptables command (you surely want to add
some IP addresses in ignorelist, so that attacker can't DoS you with IP spoofing).
failed_passwd
{
loglevel alert
ignorelist 192.168.1.1 \
192.168.1.2
command[0] "/sbin/iptables -I INPUT 1 -p tcp -i eth0 -s $1 --dport 22 -j DROP"
eventcount[0] 3
timelimit[0] 60
command[1] "/sbin/iptables -D INPUT 1 -p tcp -i eth0 -s $1 --dport 22 -j DROP"
eventcount[1] 0
timelimit[1] 1800
}
Another way to fine tune action handler is to use usesubstr to specify substrings which are
used to indentify event (by default all substrings are used). Take a look at failed_passwd
action; it uses substring no. 1 to indentify event only by IP address.
failed_passwd
{
loglevel alert
usesubstring $1
ignorelist 192.168.1.1 \
192.168.1.2
command[0] "/sbin/iptables -I INPUT 1 -p tcp -i eth0 -s $1 --dport 22 -j DROP"
eventcount[0] 3
timelimit[0] 60
command[1] "/sbin/iptables -I INPUT 1 -p tcp -i eth0 -s $1 --dport 22 -j DROP"
eventcount[1] 0
timelimit[1] 1800
}
Without usesubstr $1 substring no. 0 is also matched and it changes with different
username; now event is updated (eventcount incremented) only if substring
no. 1 (IP address) is indentical to registered event.
Let's say that your SSH login attempt fails two times, then you login succesfully
and after that your login attempt fail again; all this happens in time specified by
timelimit[0]. What happens now is that Nuhe counts three events for failed_passwd
action and runs command[0], even there is one succesful login.
You can use rststring to prevent this happening; rststring Pcre pattern is used to
discard event if it is matched to line read from monitored files.
failed_passwd
{
loglevel alert
rststring "Accepted password for (\S+) from (\S+)"
rstphases 0
usesubstring $1
ignorelist 192.168.1.1 \
192.168.1.2
command[0] "/sbin/iptables -I INPUT 1 -p tcp -i eth0 -s $1 --dport 22 -j DROP"
eventcount[0] 3
timelimit[0] 60
command[1] "/sbin/iptables -I INPUT 1 -p tcp -i eth0 -s $1 --dport 22 -j DROP"
eventcount[1] 0
timelimit[1] 1800
}
You can also use 'cleaner' phases for actions. Cleaner phase is a "reserved" phase which is
triggered by user action. Cleaner phases can be useful, when you use single phase action and
want to execute subsequent action manually. Cleaner actions can be used when Nuhe sensor is
connected to Nuhe node manager.
Cleaner phase does not use eventcount and timelimit parameters and command parameter is
specified as command[x].
Here is example of failed_passwd action handler with cleaner phase.
failed_passwd
{
loglevel alert
rststring "Accepted password for (\S+) from (\S+)"
rstphases 0
usesubstring $1
ignorelist 192.168.1.1 \
192.168.1.2
command[0] "/sbin/iptables -I INPUT 1 -p tcp -i eth0 -s $1 --dport 22 -j DROP"
eventcount[0] 3
timelimit[0] 60
command[x] "/sbin/iptables -I INPUT 1 -p tcp -i eth0 -s $1 --dport 22 -j DROP"
}
DEC 16, 2007 NUHE(1)
Browse and search your logfile content, create custom searches.Create actions based on rules defined in the rule editor.
Security
React to any log activity and trigger actions on target host based on defined rules. Automatically detect and filter logfile content based on severity.
Container
Features simplified docker container installation and fully automated sensor installer. The core software which contains Nuhed Manager, Nuhed Sensor and Nuhed Log Manager are all open source.