For the sakes of anyone experiencing this issue in future I thought I'd pop 
back to say that I found the cause a few minutes ago. Somehow when agents had 
been removed there were files for those agents left behind in the following 
path :-

/var/ossec/queue/agent-info/

I deleted those files and my "list_agents -n" is now showing what I would 
expect. I don't have any clue as to how those files were left and I didn't know 
that list_agents would refer to that folder. So I've learned something :)

Just to stress, I *was* running an old version (which I plan to upgrade now 
that I have got to the bottom of the issue).

Regards,

Chris

-- 
Chris Tweed
Technical Support
Shoe Zone

T: 0116 2223000
W: www.shoezone.com

-----Original Message-----
From: [email protected] [mailto:[email protected]] On 
Behalf Of Chris Tweed
Sent: 06 November 2014 17:10
To: '[email protected]'
Subject: [ossec-list] list_agents -n shows non-existing clients?

I regularly perform a "list_agents -n" to check for any non-connected OSSEC 
clients in our environment so that I can investigate the reason and resolve.

At present if I perform this check I get quite a long list showing clients 
which no longer exist in the client.keys file on our server. I must confess to 
periodically cleaning up the client.keys file using a text editor to remove all 
the "#*" lines as our estate can be quite fluid. However I have been doing this 
for some years now and have never encountered this issue before.

I can't understand how a client can be showing in list_agents as non-connected 
when there is no entry for it in client.keys on the server. I don't know of 
anywhere else OSSEC could be finding references to these clients which are no 
longer live in our estate (but certainly used to be live and active clients in 
the past).

Whilst I can't see that it this is actually harmful, it does make the job of 
spotting genuinely disconnected clients somewhat harder.

Is there somewhere I should be looking for a file or files which might contain 
references to these "ghost clients"? I'll admit to not knowing enough about 
OSSEC "under the hood" to know where to start looking. I've had a plough 
through the file system but haven't spotted anything obvious.

I am still running version 2.7 and intend to update to 2.8.1, however I would 
rather try to get this issue resolved before updating. It could be that 
updating clears the issue or it might carry the issue forward.

Any pointers would be appreciated, even if it's just a slap of my wrist for 
manually editing client.keys to trim out the rubbish I guess :) Maybe I 
shouldn't be doing that, even if I've never (before!) suffered any issues from 
doing so. Might it be better / quicker to simply start over with a fresh and 
up-to-date installation of OSSEC? 

We have around 600 clients (all of them Windows) so it's not a trivial job to 
roll out a fresh install - but if that's what I have to do then so be it. We 
have a single OSSEC server running under Ubuntu server 12.04.5 LTS 64 bit (as a 
Hyper-V virtual machine).

Thank you,

Chris

-- 
Chris Tweed


Please consider the environment before printing this email

CONFIDENTIALITY NOTICE
This E-Mail contains information which is confidential and privileged. If you 
have received this E-Mail in error, please telephone us immediately on +44 116 
2223000. Where opinions are expressed they are not necessarily those of Shoe 
Zone Retail Ltd.

Shoe Zone Retail Ltd
Registered Office : Haramead Business Centre, Humberstone Road, Leicester LE1 
2LH
Registered in England Number 148038

-- 

--- 
You received this message because you are subscribed to the Google Groups 
"ossec-list" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
For more options, visit https://groups.google.com/d/optout.

-- 

--- 
You received this message because you are subscribed to the Google Groups 
"ossec-list" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
For more options, visit https://groups.google.com/d/optout.

Reply via email to