Free audit logs software for linux

audit package contains the user-space utilities for creating audit rules. As well as for storing and searching the audit records generate by the audit subsystem in the Linux 2.6 kernel.
Usage:
Examples usage of utilities:
General:
Window 1:
./auditd
Window 2 (you dont have to have the daemon running to try this, but
enabled has to be 1):
./auditctl -s
./auditctl -a entry,always -S open
ls
./auditctl -d entry,always -S open
Identity tracking:
./auditctl -a exit,always -S all -F loginuid=2000
./auditctl -L 2000,"test uid"
Enhancements:
- Updates were made to system-config-audit. auditctl was updated to better handle watching of directories with older kernels.
- Memory leaks and an invalid free in auditd were fixed along with interpretations in auparse.

glibc-audit is a modified version of glibc for application developers who check their code with an automatic memory access checker such as valgrind, Insure++, or Purify.
glibc-audit has been audited and cleaned up so that reports from the developers use of a memory access checker are more likely to be interesting to the developer, with less "noise" from the C library itself. Typically, glibc-audit initializes all of its local variables and structs before use. Ordinary glibc uses uninitialized dummy variables that are "dont-care" to its logic but reported by the memory access checker.
Also, the r_debug.r_brk protocol has been enhanced to co-operate with a co-resident auditor. If the auditor sets .r_brk, then the runtime loader will call the auditor directly whenever a shared library event occurs.
This is much more convenient than using breakpoints. By default the old breakpoint protocol works just like before. The new protocol is binary compatible with the old on machines where a pointer to a function is the same size as an ordinary pointer. Platforms where a pointer to a function is larger (such as HP-PA RISC, Alpha processor, or PowerPC) are not binary backward compatible, and will have to increment r_debug.r_version. Exising clients (such as gdb) also will see an ignorable type mismatch error when they are built. But for now, it is worth more not to antagonize gdb at runtime on x86.
The patch modifies 91 files. Compared to glibc-2.3.2-27.9, the additional code occupies 18 more bytes of .text, and 24 fewer bytes in the .so. On a nano-scopic scale, the typical execution cost is 0 to 3 CPU cycles per affected routine; the estimated median total impact is less than 1 second per machine per day. In the case of *printf(), glibc-audit is faster than glibc because the cleaned-up source helps gcc-3.2 avoid generating atrocious code when initializing printf_spec.info for parse_one_spec() in stdio-common/printf-parse.h.
Glibc-audit was constructed by running a memory access checker on the internal testcases of glibc, then analyzing the reported errors and modifying the source. The process revealed 10 memory access bugs in glibc-2.3.2-11.9. Seven were fixed in glibc-2.3.2-27.9, two more have been fixed in CVS, and one is a design flaw that probably will not be fixed.
Predecessor patches to glibc-audit-1 were submitted to the glibc project, but those patches were ignored [user "guest", password "guest"], declined, or rejected. There is enough improvement in usability and reliability to publish glibc-audit-1 separately.
The unmodified glibc-2.3.2-27.9.src.rpm is available from RedHat mirrors. rpmbuild -ba --target i686 took about 4 hours and 2.5GB of disk space on a machine with 1.1GHz CPU, 384MB RAM, UDMA100 disk.
Enhancements:
- The patches were updated to glibc-2.4-4.
- A glibc bug that interfered with gdb stop-on-solib-events was fixed.
- On x86, x86-64, and PowerPC, the __NR_open system call was improved to avoid leaking information from the user to the kernel.

Domain Auditor project was written to audit and track accounts within a domain. This tool uses LDAP queries to a definable Active Directory server to find various definable classes of accounts.
Initially it will operate interactively, but capabilities may be added in the future to automate functions (i.e. generate reports on a scheduled basis). The installation script handles most installation chores, so setup is very straightforward.
The tool is beta status at this time, but is in being used to generate SOX reports for my employer.
Main features:
- Reports - This function will display a list of defined reports, when invoked it will generate a list of accounts from AD (via LDAP queries) the results returned will depend on what you have defined for the filter for any particular report class under Sysadmin
- Sys Admin - This function will allow you to changes the system settings for LDAP server and port, base DN, Bind DN, username and password, and the database settings (mySQL only at this time). You may also add the report class definitions and their matching LDAP filters within this module
- User Admin - This screen is used to define users for the system and their rights. Usernames are used as the primary value, and entered values are validated via LDAP queries
- Audit Logs - The system logs all changes to the information stored and this page will allow you to review the data from these logs

adcfw-log is a tool for analyzing firewall logs in order to extract meaningful information.
It is designed to be a standalone script with very few requirements that can generate different kinds of reports, such as fully formatted reports of what had been logged, with summaries by source or destination host, the type of service, or protocol.
There are also options to filter the input data by date, host, protocol, service, and so on.
Only netfilter log format is supported at this time.
Main features:
- support for netfilter log format
- log entries filtering based on protocol, source host, destination host, service, prefix, input and output interfaces
- specific reports based on protocol, source or destination hosts, service
- summaries based in source host, destination host, service and prefix

Pax Logging is a consolidation effort that aims to make all existing logging APIs in the Java world available for OSGi developments, driven by a Log4J backend.
Each legacy API is loaded as its own bundle. The logging service can be reloaded at run-time.
Main features:
- Log4J driving the backend implementation.
- Log4J API supported.
- Jakarta Commons Logging API supported.
- Pax Logging Service implements the standard OSGi Log Service API.
- JDK Logging API support.
- Avalon Logger API support.
- SLF4J API support.
- Knopflerfish Log service support.

Wflogs is a firewall log analysis tool. It can be used to produce a log summary report in plain text, HTML and XML, or to monitor firewalling logs in real-time.
This project is part of the WallFire project, but can be used independently.
Usage examples:
wflogs -i netfilter -o html netfilter.log > logs.html
converts the given netfilter log file into a HTML report.
wflogs --sort=protocol,-time -i netfilter -o text netfilter.log > logs.txt
converts the given netfilter log file into a sorted (by protocol number, then reverse time) text report.
wflogs -f $start_time >= [this 3 days ago] && $start_time < [this 2 days ago] && $chainlabel =~ /(DROP|REJECT)/ && $sipaddr == 10.0.0.0/8 && $protocol == tcp && ($dport == ssh || $dport == telnet) && ($tcpflags & SYN) -i netfilter -o text --summary=no
shows log entries (without summary) which match the given expression (refused connection attempts that occured 3 days ago to ssh and telnet ports coming from internal network 10.0.0.0/8).
wflogs -i netfilter -o text --resolve=0 --whois=0 netfilter.log
converts the given netfilter log file into a text report (default mode), disabling IP address reverse lookups and whois lookups.
wflogs -i netfilter -o xml netfilter.log > logs.xml
exports netfilter logs in XML.
wflogs -i ipchains -o netfilter ipchains.log > netfilter.log
converts ipchains logs into netfilter log format. So you may process them with your favorite netfilter log analyser, for example (even if the latter may not be better than wflogs itself.
wflogs -i ipfilter -o human --datalen=yes ipfilter.log
produces a report about ipfilter logfile in natural language on stdout, displaying packet length (datalen option) which is not showed by default.
wflogs -R -I
monitors logs in real-time in an interactive shell, waiting for logs in the default system logfile, in guessed format (according to the local firewalling tool).
Supported systems
WallFire is intended to work on real systems such as Unix, especially Linux and *BSD.
Current wflogs input modules are:
- netfilter (Linux 2.4 and 2.6 firewall logs)
- ipchains (Linux 2.2 firewall logs)
- ipfilter (NetBSD, FreeBSD, OpenBSD, Solaris, SunOS 4, IRIX and HP-UX running ipfilter firewall logs).
- cisco_pix (Cisco PIX filter logs)
- cisco_ios (Cisco IOS filter logs)
- snort (Snort ACLs logs)
Please note that input modules are available on any architecture on which wflogs can run (for example, you can perfectly parse Cisco PIX logs on a Linux box).
Enhancements:
- Improved matching of netfilter and ipfilter input modules.
- Added support for Cisco FWSM (PIX).
- Improved netfilter parsing.
- Compilation fixes for *BSD.
- Added wflogs.dtd.
- Added wfchkintegrity tool, which enables to monitor changes in the firewalling configuration.
- Fixed buffer sizes for some input modules.
- Fixed parsing with recent flex versions.

IMLogger provides an utility which logs instant messenger screen names logging on and off.

IMLogger provides a usable program to enable network administrators to log certain instant messaging activities (namely, login and logout). AOL is currently supported, with Yahoo, MSN, and Jabber protocols in the works.

This is very useful in Universities where campus police want to trace a SN back to a port/dorm

mod_log50x Apache module logs error 500 - 509 to logfiles. It enables you to log all error 50x status responses to logfiles.

How:

1. Either compile a apache module from the sources, or get a binary release.
2. Copy the module in the modules directory of your apache server.
3. Modify your httpd.conf to load the module:

LoadModule log50x_module modules/mod_log50x.so

4. Specify what errors should be logged in which logfile in your httpd.conf

Log50xFile /var/log/webserver50x.log
Log500File /var/log/webserver500.log
Log501File /var/log/webserver501.log
Log502File /var/log/webserver502.log
Log503File /var/log/webserver503.log
Log504File /var/log/webserver504.log
Log505File /var/log/webserver505.log
Log506File /var/log/webserver506.log
Log507File /var/log/webserver507.log
Log508File /var/log/webserver508.log
Log509File /var/log/webserver509.log

5. Restart your apache webserver


Details on the configuration options:

The Log50xFile specifies in which file all error in the range 500 - 509 should be logged.

The Log500File specifies in which file all error 500 should be logged.
The Log501File specifies in which file all error 501 should be logged.
etc.
The Log509File specifies in which file all error 509 should be logged.

It is possible to specify the same logfile multiple times, so this configuration results in all error 500 and 501 beeing logged in the same file.

Log500File /var/log/webserver500_501.log
Log501File /var/log/webserver500_501.log

When you specify the following configuration, then all error 500-509 are logged to the webserver50x logfile.

In addition to this, all error 500 are logged to the webserver500.log file.

Log50xFile /var/log/webserver50x.log
Log500File /var/log/webserver500.log