(Module) Audit Log Development

Working on an Audit Log module for FreePBX to show changes made through the UI portal (and maybe file diff too, but starting with UI database changes)

Any thoughts/comments on this? Any ideas about existing functionality for this already in FreePBX?

2 Likes

Howdy! Welcome back to the forums.

There’s quite a few logs tracking user interaction, such as Apache logs and FreePBX specific logs. Improving what gets stored in those logs is one approach.

For the database changes, you might consider TRIGGER statements that capture table modifications row-by-row into another “audit” table sharing the same column structure but with additional columns for audit_timestamp, audit_user, audit_operation, etc. More details on TRIGGERs:

As for files, the Debian-native etckeeper package is pretty slick for automating configuration file version control.

Another idea regarding where to insert this work… if it sits in between all write operations and the underlying database/file system, then you could put yourself on the path to an Undo History in addition to the Audit Log.

Related, security-wise, logging the details of everything, e.g. passwords, is not good either. :slight_smile:

2 Likes

These are all really good points, thank you for taking the time to share!

I’ll consolidate your thoughts and what I’ve thought so far below.

Change sources for tracking:

  • FreePBX UI Database
  • AstDB - Asterisk database
  • File system logs

Tracking methods:

  • FreePBX Database (MariaDB): TRIGGER statements to track table modifications
  • AstDB - May have functionality similar to TRIGGERs? Alternative: crude snapshot dump + diff on interval (not very “audit”-y, more tracking at interval)
  • Diff on any new log entries since last read

(Consolidation) Outputs:

  • Simple: Plaintext log with single line entries like log file, human-friendly and quickly reviewable
  • NoSQL/Structured: JSON log with machine-friendly event objects
  • Database: Report-friendly rows with columns for data helpful in reporting

Regarding AstDB, snapshots could be a challenge on larger systems, in part because there is so much Asterisk SIP state tracked there completely outside of the confines of the FreePBX GUI. When the GUI does manipulate the AstDB, it is probably going through the plumbing to reach commands like database put here:

And here:

And here:

And here:

And maybe more… but (hopefully not) here:

Slightly aside, probably should add some upgrades from the generic command to more direct AMI commands in to the v18 milestone, so we can do nice things like DBPut and stuff… here is the GH issue.

2 Likes

Awesome, I’ll review those instances.

I might also have a converged/timeline view which compiles events/changes from all sources and shows in one combined view (also hiding extra instances when an event results in entries in all the sources.)