AnsweredAssumed Answered

OpenFire Audit logging and other observations

Question asked by Simon Waters on Jul 5, 2017
Latest reply on Jul 6, 2017 by Simon Waters

Just reviewing 4.1.4 (I know it was installed and ready on my test box) from an audit/logging perspective, to understand what it currently does/doesn't do.


We may or may not be able to contribute to some of these ideas depending on project work here but I thought I'd put some of the observations here, in case I've missed something, or there are other ways to achieve things not immediately apparent to me.


Security Audit log doesn't include client IP address, it can usually be found from other logs, but usually IP address is one of the key pieces of information. Is there a particular philosophy on what is being logged here?


Security Audit log doesn't log adding a plugin (disabling plugins is recorded), seems inconsistent.


Failed attempts to login to the web console generate log file entries that suggest is has triggered LoginLimitManager, but I couldn't see org.jivesoftware.admin.LoginLimitManager configuration exposed anywhere?!  Noted also the action is not logged in Security Audit log, nor do the IPAddress or UserAccount lock events stop people logging in from that IP or username (which is probably fine as a default).



Also noted these areas where there didn't seem to be a plugin or tool currently suited to:


Automatically Disabling inactive accounts.


Alerting on, or restricting, activity outside of specified business hours.


XMPP authentication failures are logged by default as "debug" events, meaning they aren't even recorded in the default configuration. I assume for big XMPP deployments these would be horribly noisy to record. I didn't find anything discussing monitoring or acting on same. Was considering something like AppSensor to bring a little bit more self awareness to the server, but I'm sure someone will already have done some work here.