> Nuhed download
NuhedManager
can be described as a general rule based monitoring system which can run system commands in phases
Nuhedman installation | Sensor installation | Nuhed man page | Nuhed readme





nuhed


NuhedManager

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

Certificate

/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)




cloud service
Browse and search your logfile content, create custom searches.Create actions based on rules defined in the rule editor.

security 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.

file browser 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.

Download
 
nuhedman-2.0.36 for linux 2024-11-10 Download Docker container package


Nuhed client sensor and log manager client source packages
nuhed-1.0.12
Download
nuhedlogd-1.0.12
Download