powered by Jive Software

OpenFire Audit logging and other observations

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.

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

Yes, it does look inconsistent [OF-1357] Security Audit should log adding a plugin - IgniteRealtime JIRA

Automatically Disabling inactive accounts.

There is an old ticket, which didn’t get much attention [OF-299] Add support for removing inactive accounts - IgniteRealtime JIRA

Thanks.

I also had some of the observations on OF-299, user search potentially needs some improvement, but I pushed that to the “worry about when we have more users” box.

But looks like we are bringing a Java dev onboard in Dave’s absence, and I’m sorting out security related issues that we would like addressed. Although I’m still waiting on a pen test report (Dave said they hadn’t found all the issues I’ve reported ), and those will presumably take priority.

Oh, i thought your name sounded familiar You can even file some of this stuff in Jira on your own

1 Like

I can, and I will raise some tickets, but thought I’d discuss here to make sure I haven’t missed too much.

I’ve spent many orders of magnitude more time security testing the OpenFire Admin interface (Also still target rich environment), than I have using it in anger, so I still feel like OpenFire/XMPP newbie at times…

Dave seemed open to some systematic fixing of the web interfaces flaws, I’m just worried there are similar issues in the XMPP side I’m missing for want of decent tooling. Mark @ Surevine is developing some testing for various XMPP but it is mostly around regression or compliance of new features, and it takes a lot of manual effort to create good tests that way.