Free mod log spread2 software for linux

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

DKP Log Parser (DKPLP) is a tool designed to help administrate time-based and/or event-based DKP reward system in conjunction with EQDKP (or any other DKP software implementing a required interface). The project is configurable to be compatible with any game that produces any kind of log. There are currently predefined pattern sets for EverQuest, EverQuest2 and World of Warcraft (with CT RaidTracker). If you are playing another game then you can either write new patterns for it yourself, or ask the the forum (be sure to include a sample log though).
DKP Log Parsers goal is to reduce the administrative overhead of running complex DKP reward system, by parsing the logs, calculating the DKP per person and sending the results (the loot, raids, participants and DKP) directly to EQDKP (or other DKP software). Its widely configurable, allowing it to be used by the many variations of zero-sum and time-based DKP around.
Overview of how DKP Log Parser is used
DKP Log Parser is a software program run on a users desktop (Windows or Unix). It reads in the contents of a game log once a raid has been completed, parses all the information and displays the data for administrators to edit. Once happy with the information, the administrator uploads the data from their PC to the DKP Log Parser plugin on an EQDKP webserver (or any other server implementing the required DKPLP interface), where it can be viewed by all members of the DKP system.
Main features:
- Inbuilt support for Everquest, Everquest II, World of Warcrafts CT RaidTracker plugin, and Ventrilo.
- Extensible enough to be able to handle most logs.
- Time based dkp:
- Accrue DKP by minute, by interval, by event or by a combination of these.
- Zero-sum DKP can be enabled (by minute or by interval) or disabled.
- Tag certain intervals as being more or less important by using weightings to adjust the DKP.
- Data export:
- Upload data to for example EQDKP, select from a number of different data representations.
- Export to plain text
- Export to BB forum markup
- Export to wiki markup
- Export to XML
- Member list and alt character list synchronises with server, making it easy to share setups with other users.
- Optional autocompletion database to remember item names and values between sessions.
- Preprocessors available to perform other operations on the log file. The skys the limit!

Nmap Log Stripp3r program is intended to be a way to condense all, or some, of the IPs of a "random" nmap scan into a file for later usage.

Common uses are to be able to feed the file back into nmap with the -iL switch, or feeding it into another port or vulnerability scanner of your choice.

Stripp3r supports stripping the nmap log of all but the IPs of hosts running a certain service, a version of a service, or even an arbitrary banner, and writing them to a file.

This is intended to be a way to condense all the IPs of a "random" Nmap scan into a file for later useage. Common uses are to be able to feed the file back into Nmap its self with the -iL switch, or feeding it into another port or vulnerability scanner.

Useage: ./stripp3r < logfile > < output > "< version string >" -v

Pretty simple. First, you must run an Nmap scan, on random hosts.

Ex. nmap -p 80 -sV -v -iR 500000 -oN nmaplogfile.nmap

This will tell nmap to do a scan service scan of 500,000 random IP addresses for the port 80, vobosely, and save the log to a file named nmaplogfile.nmap. You can change this around, eg, scanning a different service port (if say, you were looking for computers running FTP, you would scan for port 21 instead of 80 for HTTP), scanning a different number of hosts (500,000 or so is good, takes a few hours ususally though), or saving the log file to a different filename.

Nmap will then save a list of hosts that were "up" to a log file, with some informaiton about them, specifically weather the port that you specified was open, closed, or filtered. We are interested in "open" ports, so by default, Stripp3r will take all the log
enteries that have the port your specified listed as "open" and condense them into a file, listing only the IPs, one on each line.

Ex. ./stripp3r nmaplogfile.nmap output.ips

You can be more specific, and have Stripp3r put only the IPs that are running a certain service in the output file. The service string will only register the strings matching EXACTLY, so be careful to get the case and such correct.

apache httpd 1.3.27 (wont work)
Apache 1.3.27 (wont work)
Apache httpd 1.3.27 (works!)

Ex. ./stripp3r nmaplogfile.nmap output.ips "Apache httpd 1.3.27"

If you want to try it with verbosity, say

Ex. ./stripp3r nmaplogfile.nmap output.ips "Apache httpd 1.3.27" -v

And stripp3r will print out what it finds, along with writing it to the file.

You may change, copy, and reproduce this file, as long as the author is given credit for the initial writing of the code.

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.

This patch can be used on a masquerading firewall (NAT) to keep a log of all the outgoing masqueraded TCP connections.
Its even possible to log the name of the user who has opened the connection. This can be a useful security tool for many small networks that are hidden by a masquerading box if users cannot be totally trusted. It can be used with linux 2.2.17, 2.2.19, 2.2.20 and maybe other (future) 2.2.x versions.
With this information you can know, in the above scenario, that the connection masquerader.yourdomain.com:666 [-3-] ==> crackme.victim.com:31337 [-2-] was started by attacker.yourdomain.com [-1-] from port 1234.
Now please note that this is NOT enough: if attacker.yourdomain.com is a multiuser machine at that time there could be 100 users logged in. Moreover a malicious user could attack crackme.victim.com from attacker.yourdomain.com even without being logged in (with either cron or with a background job or... etc.).
Since we dont want the users being able to hide themselves in this way, the masquerader makes a IDENT query to the client and, if IDENT is available, adds the response to the log together with [-1-], [-2-] and [-3-].
Its therefore recommended (although its optional) that you enable the IDENT service on all hosts on the internal network. Please note that if you restrict the IDENT service (e.g. with TCP wrappers) to the masquerader it wont work (exercise: can you understand why?). If your network configuration on the masquerader is OK, remote hosts wont be able to do IDENT queries (since they cant pass through the masquerader). Therefore allowing "everyone" to do IDENT queries on the clients should be safe enough. If you wish to allow remote hosts to do IDENT queries you can install a special IDENT server on the masquerade router, like pnidentd (for example).
Enhancements:
- Update for linux 2.2.19

PIX Logging Architecture [PLA] is a project allowing for correlation of Cisco PIX Firewall Traffic and IDS Logs.
Centralization of the logs is provided using a MySQL database, supported by a Web-based frontend for Log Viewing, Searching, and Event Management.
PLA is completely coded in the Perl programming language, and uses various Perl modules including Perl::DBI and
Perl::CGI.
Main features:
- Parsing of Cisco PIX Syslog Messages
- Centralized MySQL Database Logging
- Multiple Firewall Support
- Web-based frontend for:
- Cisco PIX Traffic Logs
- Cisco PIX IDS Logs
- Searching Cisco PIX Traffic and IDS Logs
- Cisco PIX Traffic and IDS Statistics
- Event Management (Incident Management)