[Okta Webinar] Learn how to a build a cloud-first strategyRegister Now

x
  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 3697
  • Last Modified:

Nagios nrpe cannot read log file

I have a Nagios server 3.0.6 running on Ubuntu 8.04 Server.  It is monitoring all things except the one below on multiple targets fine.

On a certain target, I am trying to monitor my /var/log/auth.log file for bad activity, such as failed password attempts, or attempts to login as invalid users, etc.

I am trying to do this via the check_log plugin via nrpe, but, I get a "Log check error: Log file /var/log/auth.log is not readable!" when the server checks on it.

The easiest way I have to reproduce the error is the following manually executed command from the host server:
/usr/local/nagios/libexec/check_nrpe -H target -c check_badpw

I know that it means that the file cannot be opened during the check, but, I don't understand why.

ls -l of /var/log/auth.log:
-rw-r----- 1 syslog adm 1590863 2009-05-12 10:47 /var/log/auth.log

In /etc/groups, I have added the "nagios" user to the adm group, so it should work.

Further, if I am logged in as root on the target, and do "su nagios", I can read /var/log/auth.log

Further, if I "chmod o+r /var/log/auth.log", the command executes properly.

Additionally, when I am logged into the target as root, and su to nagios and execute the command as defined in nrpe.cfg:
/usr/local/nagios/libexec/check_log -F /var/log/auth.log -O /usr/local/nagios/auth.badpasswords.log -q ": Failed password for"
it works fine.

So, I know it will work if I loosen the permissions on /var/log/auth.log, but, I'd prefer to keep them as tight as possible.

How can I determine why the check_nrpe command does not allow for reading of the /var/log/auth.log file on the target machine?
1
tomn2tsr
Asked:
tomn2tsr
  • 14
  • 9
  • 4
1 Solution
 
Kerem ERSOYPresidentCommented:
First of all to thest it use
su - nagios
not
su nagios

because when you do su naigos you don't switch environment.

When you're in su - nagios
use the command
id

to see your user and group settings and try to read file once more.

Cheers,
K.

0
 
Deepak KosarajuCommented:
Who is the owner for the nrpe process, can u check nrpe.cfg and make sure nagios is the owner and group is nagios.
0
 
tomn2tsrAuthor Commented:
Thanks for that tidbit.  I may have known that at one point, but, I guess I forgot about the "su -" command.

However, that didn't shed light on a solution, at least not to me...

Here's the output

root@target:/usr/local/nagios/libexec# su - nagios
No directory, logging in with HOME=/
$ tail /var/log/auth.log
May 12 11:14:37 xxxx
May 12 11:14:37 xxxx
May 12 11:14:39 xxxx
May 12 11:14:41 xxxx
May 12 11:14:41 xxxx
May 12 11:14:41 xxxx
May 12 11:14:41 xxxx
May 12 11:14:44 xxxx
May 12 11:14:44 xxxx
May 12 11:14:44 xxxx
$ id
uid=5308(nagios) gid=5309(nagios) groups=4(adm),5309(nagios)
$ ls -l /var/log/auth.log
-rw-r----- 1 syslog adm 1790013 2009-05-12 11:16 /var/log/auth.log
$
0
What does it mean to be "Always On"?

Is your cloud always on? With an Always On cloud you won't have to worry about downtime for maintenance or software application code updates, ensuring that your bottom line isn't affected.

 
tomn2tsrAuthor Commented:
kosarajudeepak:

In my nrpe.cfg file:

# NRPE USER
# This determines the effective user that the NRPE daemon should run as.  
# You can either supply a username or a UID.
#
# NOTE: This option is ignored if NRPE is running under either inetd or xinetd

nrpe_user=nagios



# NRPE GROUP
# This determines the effective group that the NRPE daemon should run as.  
# You can either supply a group name or a GID.
#
# NOTE: This option is ignored if NRPE is running under either inetd or xinetd

nrpe_group=nagios

So, I think it's good.
0
 
tomn2tsrAuthor Commented:
Perhaps I should specify that nrpe is run under xinetd on the target, if that makes a difference.
0
 
tomn2tsrAuthor Commented:
And, in /etc/xinetd.d/nrpe, the user and group are both "nagios"
0
 
Deepak KosarajuCommented:
what was the setting of don't blame nrpe option in nrpe.cfg
0
 
tomn2tsrAuthor Commented:
dont_blame_nrpe=0
0
 
tomn2tsrAuthor Commented:
Since you questioned it, I changed it to 1, restarted xinetd, and still had the same problem.
0
 
tomn2tsrAuthor Commented:
Here's something else I just found.

As I stated above, after an "su - nagios" on the target system, the output of id returns:
uid=5308(nagios) gid=5309(nagios) groups=4(adm),5309(nagios)

However, if I embed the id command into the check_log script on the target, and execute:
/usr/local/nagios/libexe/check_nrpe -H target -c check_badpw
from the monitoring server, the output of id shows only:
uid=5308(nagios) gid=5309(nagios)

It does not show membership to the adm group as it does above.

So, why does a call through check_nrpe ignore the pertinent data in /etc/group (that being adm contains nagios as a group)?

0
 
Deepak KosarajuCommented:
can you copy the content check_log file where you added id command and also the nrpe.cfg definition for check_badpw command.
0
 
tomn2tsrAuthor Commented:
check_log:
# If the source log file doesn't exist, exit

if [ ! -e $logfile ]; then
    $ECHO "Log check error: Log file $logfile does not exist!\n"
    exit $STATE_UNKNOWN
elif [ ! -r $logfile ] ; then
    $ECHO "Log check error: Log file $logfile is not readable!\n"
        /usr/bin/id
    exit $STATE_UNKNOWN
fi

nrpe.cfg
command[check_badpw]=/usr/local/nagios/libexec/check_log -F /var/log/auth.log -O /usr/local/nagios/auth.badpasswords.log -q ": Failed password for"
0
 
Kerem ERSOYPresidentCommented:
Hi, then you can make syslog a member to the nagios gorup instead.
0
 
tomn2tsrAuthor Commented:
KeremE:

Still same problem.
0
 
Kerem ERSOYPresidentCommented:
Another solution would be to run a cron job to collect the information and wirte under a file owned by nagios:nagios and you to read it instead of the audit.log :)

I know it is a dirty solution but anyway :)
0
 
tomn2tsrAuthor Commented:
Yea, I could do that.  But, I'm really looking for the answer to why it's not working the way I think it is supposed to work.  There must be something wrong, because, if you wanted to monitor a bunch of secured logs, you'd have to do an awful lot of "dirty" solutions.
0
 
Kerem ERSOYPresidentCommented:
Yeah but another laternative being runinng a SUID / GUID script that I even don't want to think of. It seems that nrpe is just assigning the conifgured user and group id and that it does not run it in system environment and thus obviously not checking the user environment.

May be the best thin to do is just loggig -on the forum and tell the problem to the developpers so that they will fix it for the coming releases.
 
0
 
tomn2tsrAuthor Commented:
I will probably do that, if I don't get any other suggestions/solutions here.
0
 
Kerem ERSOYPresidentCommented:
In fact I've got antoher solution. NRPE also allows the use of command prefixing. so that you can run your script with, say, sudo:

Find it here:
# COMMAND PREFIX
# This option allows you to prefix all commands with a user-defined string.
# A space is automatically added between the specified prefix string and the
# command line from the command definition.
#
# *** THIS EXAMPLE MAY POSE A POTENTIAL SECURITY RISK, SO USE WITH CAUTION! ***
# Usage scenario: 
# Execute restricted commmands using sudo.  For this to work, you need to add
# the nagios user to your /etc/sudoers.  An example entry for alllowing 
# execution of the plugins from might be:
#
# nagios          ALL=(ALL) NOPASSWD: /usr/lib/nagios/plugins/
#
# This lets the nagios user run all commands in that directory (and only them)
# without asking for a password.  If you do this, make sure you don't give
# random users write access to that directory or its contents!
 
command_prefix=/usr/bin/sudo
 
So that you can prefix your script with this and it will work with syslog instead. Of course you might ned to assign proger pervileges in sudoers table.

Open in new window

0
 
Kerem ERSOYPresidentCommented:
Another one is turning on the nrpe debugging through nrpe config and see what actually happens step-by-step

0
 
tomn2tsrAuthor Commented:
That's interesting.

However, I tried that, and, it creates a log entry in auth.log (which is what I am monitoring) complete with the command-line which was excuted.  And, since the command-line contains the search string, the string is always inserted into the log file, therefore, the string is always present at run-time, returning a positive result.

I'm sure I could get rid of the log entry, but II don't really wish to modify the default way that sudo runs either.
0
 
Kerem ERSOYPresidentCommented:
I do't suggest you to modify the dafault way that sudo runs. All I say is you need to configure sudo so that it will allow your string to run as syslog user. I mean you need to configure sudo too it is not enough just to configure nrpe :)
0
 
tomn2tsrAuthor Commented:
Right, I understood that both nrpe and the sudoers file would need to be modified, which I did.  

But, doing that, the initial problem went away, and was replaced by an always positive condition, that being, whatever string I was trying to check in auth.log was inserted into auth.log by the execution of the sudo command just before the actual check for the string was made.
0
 
Kerem ERSOYPresidentCommented:
ok it seems that sudo is returning its own status now and preventing the output from the string.
I don't know about your script but does it exit with specific exitcode. i.e., exit for modified and exit for normal termination ??

Another suggestion would be to use a script wrapper in that you'll call a string and it will call the check sudo enabled script and evaluate the result depending on the output ? Say if some string returns exit with status if not just exit?

0
 
Kerem ERSOYPresidentCommented:
If you can't be able to pass parameters back to Nagios you might as well write the result to a file in temp. Then upon completion you read that file in your wrapping script and set the exit status accordingly.
0
 
tomn2tsrAuthor Commented:
It turns out that /etc/xinetd.d/nrpe needed to contain the line:
groups = yes
so that xinetd would apply the group membership permissions as well.

0
 
Deepak KosarajuCommented:
Good Catch! Thanks for posting the Solution Gud luck
0

Featured Post

NFR key for Veeam Agent for Linux

Veeam is happy to provide a free NFR license for one year.  It allows for the non‑production use and valid for five workstations and two servers. Veeam Agent for Linux is a simple backup tool for your Linux installations, both on‑premises and in the public cloud.

  • 14
  • 9
  • 4
Tackle projects and never again get stuck behind a technical roadblock.
Join Now