logs

All posts tagged logs

Logcheck — check logs for unusual activity and emails

Posted by phatdee on May 14, 2012
Posted in: Security. Tagged: , , . 3 comments

#!/bin/sh
#
# $Id: logcheck.sh,v 1.5 2002/10/11 18:52:33 tcole Exp $
#
# logcheck.sh: Log file checker
# Written by Craig Rowland
#
# This file needs the program logtail.c to run
#
# This script checks logs for unusual activity and blatant
# attempts at hacking. All items are mailed to administrators
# for review. This script and the logtail.c program are based upon
# the frequentcheck.sh script idea from the Gauntlet(tm) Firewall
# (c)Trusted Information Systems Inc. The original authors are
# Marcus J. Ranum and Fred Avolio.
#
# Default search files are tuned towards the TIS Firewall toolkit
# the TCP Wrapper program. Custom daemons and reporting facilites
# can be accounted for as well…read the rest of the script for
# details.
#
# Version Information
#
# 1.0 9/29/96 — Initial Release
# 1.01 11/01/96 — Added working /tmp directory for symlink protection
# (Thanks Richard Bullington (rbulling@obscure.org)
# 1.1 1/03/97 — Made this script more portable for Sun’s.
# 1/03/97 — Made this script work on HPUX
# 5/14/97 — Added Digital OSF/1 logging support. Big thanks
# to Jay Vassos-Libove for
# his changes.

# CONFIGURATION SECTION

PATH=/bin:/sbin:/usr/bin:/usr/sbin:/usr/ucb:/usr/local/bin

# Logcheck is pre-configured to work on most BSD like systems, however it
# is a rather dumb program and may need some help to work on other
# systems. Please check the following command paths to ensure they are
# correct.

# Person to send log activity to.
SYSADMIN=user@example.com

# Full path to logtail program.
# This program is required to run this script and comes with the package.

LOGTAIL=/export/logsentry/bin/logtail

# Full path to SECURED (non public writable) /tmp directory.
# Prevents Race condition and potential symlink problems. I highly
# recommend you do NOT make this a publically writable/readable directory.
# You would also be well advised to make sure all your system/cron scripts
# use this directory for their “scratch” area.

TMPDIR=/export/logsentry/tmp

# The ‘grep’ command. This command MUST support the
# ‘-i’ ‘-v’ and ‘-f’ flags!! The GNU grep does this by default (that’s
# good GNUs for you Linux/FreeBSD/BSDI people 🙂 ). The Sun grep I’m told
# does not support these switches, but the ‘egrep’ command does (Thanks
# Jason ). Since grep and egrep are usually the GNU
# variety on most systems (well most Linux, FreeBSD, BSDI, etc) and just
# hard links to each other we’ll just specify egrep here. Change this if
# you get errors.

# Linux, FreeBSD, BSDI, Sun, HPUX, etc.
GREP=egrep

# The ‘mail’ command. Most systems this should be OK to leave as is.
# If your default mail command does not support the ‘-s’ (subject) command
# line switch you will need to change this command one one that does.
# The only system I’ve seen this to be a problem on are HPUX boxes.
# Naturally, the HPUX is so superior to the rest of UNIX OS’s that they
# feel they need to do everything differently to remind the rest that
# they are the best ;).

# Linux, FreeBSD, BSDI, Sun, etc.
#MAIL=mail
# Solaris
MAIL=mailx
# HPUX 10.x and others(?)
#MAIL=mailx
# Digital OSF/1, Irix
#MAIL=Mail

# File of known active hacking attack messages to look for.
# Only put messages in here if you are sure they won’t cause
# false alarms. This is a rather generic way of checking for
# malicious activity and can be inaccurate unless you know
# what past hacking activity looks like. The default is to
# look for generic ISS probes (who the hell else looks for
# “WIZ” besides ISS?), and obvious sendmail attacks/probes.

HACKING_FILE=/export/logsentry/etc/logcheck.hacking

# File of security violation patterns to specifically look for.
# This file should contain keywords of information administrators should
# probably be aware of. May or may not cause false alarms sometimes.
# Generally, anything that is “negative” is put in this file. It may miss
# some items, but these will be caught by the next check. Move suspicious
# items into this file to have them reported regularly.

VIOLATIONS_FILE=/export/logsentry/etc/logcheck.violations

# File that contains more complete sentences that have keywords from
# the violations file. These keywords are normal and are not cause for
# concern but could cause a false alarm. An example of this is the word
# “refused” which is often reported by sendmail if a message cannot be
# delivered or can be a more serious security violation of a system
# attaching to illegal ports. Obviously you would put the sendmail
# warning as part of this file. Use your judgement before putting words
# in here or you can miss really important events. The default is to leave
# this file with only a couple entries. DO NOT LEAVE THE FILE EMPTY. Some
# grep’s will assume that an EMPTY file means a wildcard and will ignore
# everything! The basic configuration allows for the more frequent sendmail
# error.
#
# Again, be careful what you put in here and DO NOT LEAVE IT EMPTY!

VIOLATIONS_IGNORE_FILE=/export/logsentry/etc/logcheck.violations.ignore

# This is the name of a file that contains patterns that we should
# ignore if found in a log file. If you have repeated false alarms
# or want specific errors ignored, you should put them in here.
# Once again, be as specific as possible, and go easy on the wildcards

IGNORE_FILE=/export/logsentry/etc/logcheck.ignore

# The files are reported in the order of hacking, security
# violations, and unusual system events. Notice that this
# script uses the principle of “That which is not explicitely
# ignored is reported” in that the script will report all items
# that you do not tell it to ignore specificially. Be careful
# how you use wildcards in the logcheck.ignore file or you
# may miss important entries.

# Make sure we really did clean up from the last run.
# Also this ensures that people aren’t trying to trick us into
# overwriting files that we aren’t supposed to. This is still a race
# condition, but if you are in a temp directory that does not have
# generic luser access it is not a problem. Do not allow this program
# to write to a generic /tmp directory where others can watch and/or
# create files!!

# Shouldn’t need to touch these…
HOSTNAME=hostname
DATE=date +%m/%d/%y:%H.%M

umask 077
rm -f $TMPDIR/check.$$ $TMPDIR/checkoutput.$$ $TMPDIR/checkreport.$$
if [ -f $TMPDIR/check.$$ -o -f $TMPDIR/checkoutput.$$ -o -f $TMPDIR/checkreport.$$ ]; then
echo “Log files exist in $TMPDIR directory that cannot be removed. This
may be an attempt to spoof the log checker.” \
| $MAIL -s “$HOSTNAME $DATE ACTIVE SYSTEM ATTACK!” $SYSADMIN
exit 1
fi

# LOG FILE CONFIGURATION SECTION
# You might have to customize these entries depending on how
# you have syslogd configured. Be sure you check all relevant logs.
# The logtail utility is required to read and mark log files.
# See INSTALL for more information. Again, using one log file
# is preferred and is easier to manage. Be sure you know what the
# > and >> operators do before you change them. LOG FILES SHOULD
# ALWAYS BE chmod 600 OWNER root!!

# Find out what OS we are running on
OS=uname -s

# Generic and Linux Slackware 3.x
#$LOGTAIL /var/log/messages > $TMPDIR/check.$$

# Linux Red Hat Version 3.x, 4.x
#$LOGTAIL /var/log/messages > $TMPDIR/check.$$
#$LOGTAIL /var/log/secure >> $TMPDIR/check.$$
#$LOGTAIL /var/log/maillog >> $TMPDIR/check.$$

# Linux Debian 2.2 and 3.0
if [ $OS = “Linux” ]; then
$LOGTAIL /var/log/messages > $TMPDIR/check.$$
$LOGTAIL /var/log/syslog >> $TMPDIR/check.$$
$LOGTAIL /var/log/auth.log >> $TMPDIR/check.$$
$LOGTAIL /var/log/mail.log >> $TMPDIR/check.$$
$LOGTAIL /var/log/daemon.log >> $TMPDIR/check.$$
fi

# FreeBSD 2.x
if [ $OS = “FreeBSD” ]; then
$LOGTAIL /var/log/messages > $TMPDIR/check.$$
$LOGTAIL /var/log/auth.log > $TMPDIR/check.$$
# I guess we don’t have that right now.
#$LOGTAIL /var/log/daemon.log > $TMPDIR/check.$$
# Lets not even look at the mail log since we probably don’t care.
#$LOGTAIL /var/log/maillog >> $TMPDIR/check.$$
fi

# BSDI 2.x
#$LOGTAIL /var/log/messages > $TMPDIR/check.$$
#$LOGTAIL /var/log/secure >> $TMPDIR/check.$$
#$LOGTAIL /var/log/maillog >> $TMPDIR/check.$$
#$LOGTAIL /var/log/ftp.log >> $TMPDIR/check.$$
# Un-comment out the line below if you are using BSDI 2.1
#$LOGTAIL /var/log/daemon.log >> $TMPDIR/check.$$

# SunOS, Sun Solaris 2.5
if [ $OS = “SunOS” ]; then
$LOGTAIL /var/log/syslog > $TMPDIR/check.$$
$LOGTAIL /var/adm/messages >> $TMPDIR/check.$$
$LOGTAIL /var/log/auth.log >> $TMPDIR/check.$$
$LOGTAIL /var/log/maillog >> $TMPDIR/check.$$
fi

# HPUX 10.x and others(?)
#$LOGTAIL /var/adm/syslog/syslog.log > $TMPDIR/check.$$

# Digital OSF/1
# OSF/1 – uses rotating log directory with date & time in name
# LOGDIRS=find /var/adm/syslog.dated/* -type d -prune -print
# LOGDIR=ls -dtr1 $LOGDIRS | tail -1
# if [ ! -d “$LOGDIR” ]
# then
# echo “Can’t identify current log directory.” >> $TMPDIR/checkrepo$
# else
# $LOGTAIL $LOGDIR/auth.log >> $TMPDIR/check.$$
# $LOGTAIL $LOGDIR/daemon.log >> $TMPDIR/check.$$
# $LOGTAIL $LOGDIR/kern.log >> $TMPDIR/check.$$
# $LOGTAIL $LOGDIR/lpr.log >> $TMPDIR/check.$$
# $LOGTAIL $LOGDIR/mail.log >> $TMPDIR/check.$$
# $LOGTAIL $LOGDIR/syslog.log >> $TMPDIR/check.$$
# $LOGTAIL $LOGDIR/user.log >> $TMPDIR/check.$$
# fi
#

# END CONFIGURATION SECTION. YOU SHOULDN’T HAVE TO EDIT ANYTHING
# BELOW THIS LINE.

# Set the flag variables
FOUND=0
ATTACK=0

# See if the tmp file exists and actually has data to check,
# if it doesn’t we should erase it and exit as our job is done.

if [ ! -s $TMPDIR/check.$$ ]; then
rm -f $TMPDIR/check.$$
exit 0
fi

# Perform Searches

# Check for blatant hacking attempts
if [ -f “$HACKING_FILE” ]; then
if $GREP -i -f $HACKING_FILE $TMPDIR/check.$$ > $TMPDIR/checkoutput.$$; then
echo >> $TMPDIR/checkreport.$$
echo “Active System Attack Alerts” >> $TMPDIR/checkreport.$$
echo “=-=-=-=-=-=-=-=-=-=-=-=-=-=” >> $TMPDIR/checkreport.$$
cat $TMPDIR/checkoutput.$$ >> $TMPDIR/checkreport.$$
FOUND=1
ATTACK=1
fi
fi

# Check for security violations
if [ -f “$VIOLATIONS_FILE” ]; then
if $GREP -i -f $VIOLATIONS_FILE $TMPDIR/check.$$ |
$GREP -v -f $VIOLATIONS_IGNORE_FILE > $TMPDIR/checkoutput.$$; then
echo >> $TMPDIR/checkreport.$$
echo “Security Violations” >> $TMPDIR/checkreport.$$
echo “=-=-=-=-=-=-=-=-=-=” >> $TMPDIR/checkreport.$$
cat $TMPDIR/checkoutput.$$ >> $TMPDIR/checkreport.$$
FOUND=1
fi
fi

# Do reverse grep on patterns we want to ignore
if [ -f “$IGNORE_FILE” ]; then
if $GREP -v -f $IGNORE_FILE $TMPDIR/check.$$ > $TMPDIR/checkoutput.$$; then
echo >> $TMPDIR/checkreport.$$
echo “Unusual System Events” >> $TMPDIR/checkreport.$$
echo “=-=-=-=-=-=-=-=-=-=-=” >> $TMPDIR/checkreport.$$
cat $TMPDIR/checkoutput.$$ >> $TMPDIR/checkreport.$$
FOUND=1
fi
fi

# If there are results, mail them to sysadmin

if [ “$ATTACK” -eq 1 ]; then
cat $TMPDIR/checkreport.$$ | $MAIL -s “$HOSTNAME $DATE ACTIVE SYSTEM ATTACK!” $SYSADMIN
elif [ “$FOUND” -eq 1 ]; then
cat $TMPDIR/checkreport.$$ | $MAIL -s “Systems Check: $HOSTNAME $DATE” $SYSADMIN
fi

# Clean Up
rm -f $TMPDIR/check.$$ $TMPDIR/checkoutput.$$ $TMPDIR/checkreport.$$

Swat — Setting up stunnel

Posted by phatdee on April 15, 2012
Posted in: Swat. Tagged: , , , . Leave a Comment

Modifications to the SWAT setup are as follows:

Install OpenSSL.

Generate certificate and private key.

root# /usr/bin/openssl req -new -x509 -days 365 -nodes -config \
/usr/share/doc/packages/stunnel/stunnel.cnf \
-out /etc/stunnel/stunnel.pem -keyout /etc/stunnel/stunnel.pem

Remove SWAT entry from [x]inetd.

Start stunnel.

root# stunnel -p /etc/stunnel/stunnel.pem -d 901 \
-l /usr/local/samba/bin/swat swat

Afterward, simply connect to SWAT by using the URL https://myhost:901, accept the certificate, and the SSL connection is up.

DNSCache and LogWatch

Posted by phatdee on October 18, 2011
Posted in: System Loggers. Tagged: , , , , . Leave a Comment

dnscache ang logwatch

There are no translations available.

 

This page is written to explain how to integrate logwatch and dnscache, a component of djbdns.

First, download the logwatch script to your server:

cd /usr/share/logwatch/scripts/services/
wget http://www.cypress-systems.net/scripts/dnscache
chmod 755 dnscache

Second, edit the script to tell logwatch where the logfile is looking for

vim /usr/share/logwatch/default.conf/services/dnscache.conf

Title = “dnscache”
LogFile = dnscache
# vi: shiftwidth=3 tabstop=3 et

 

Third, tell logwatch where the logs are exactly stored

vim /usr/share/logwatch/default.conf/logfiles/dnscache.conf

LogFile = /service/dnscache/log/main/@*.s
LogFile = /service/dnscache/log/main/current
# Keep only the lines in the proper date range…
*applytaidate
# vi: shiftwidth=3 tabstop=3 et

 

Four, run a test to see if there is any output

logwatch –service dnscache –range today –detail 10 –output stdout

djbdns log format (howto read the hexadecimal format)

Posted by phatdee on August 8, 2011
Posted in: TinyDNS djbdns. Tagged: , , , , . Leave a Comment

Here is the djbdns dnscache Log File formats, copied directly from http://dqd.com/~mayoff/notes/djbdns/dnscache-log.html

dnscache Log File Format
by Rob Mayoff

These notes are incomplete.

dnscache is part of the djbdns package, written by Daniel J. Bernstein, aka djb. I couldn’t find any documentation on its log file format, other than this explanation of one field of the stats log entry. This file contains my notes on what the log entries mean. If there are any errors here, they are mine and not djb’s.

dnscache logs IP addresses as 8 digit hexadecimal strings. For example, 127.0.0.1 is logged as 7f000001.

dnscache logs UDP ports and query IDs as 4 digit hexadecimal strings.

dnscache logs all time intervals (including TTLs) as decimal strings, in units of seconds.

dnscache logs record types numerically. For a list of record types, see RFC 1700, page 79. The common ones are 1 = A, 12 = PTR, and 15 = MX.

RFC 1035 specifies the implementation of DNS.

You can find some programs for analyzing dnscache logs at http://www.fibrespeed.net/~mbabcock/code/.

Log entry types:

cached type name
cached cname name cname
cached ns control server
cached nxdomain name
drop serial error
lame serverip name control
nodata serverip ttl type name
nxdomain serverip ttl name
query serial clientip:clientport:id type name
rr serverip ttl type name data
rr serverip ttl cname name cname
rr serverip ttl mx name preference exchanger
rr serverip ttl ns name server
rr serverip ttl ptr name pname
rr serverip ttl soa server email serial refresh retry expire minimum
sent serial length
servfail name error
starting
stats query-count cache-motion udp-active tcp-active
tcpopen clientip:clientport
tcpclose clientip:clientport error
tx gluelessness type name control serverips…

Descriptions

cached type name

dnscache needs some records and found them in the cache. It may have needed the records because the client requested them, or it may have needed the addresses of a name server in order to look up some other records.

The actual cached data is not recorded with this log entry. The cached data may include several records, but dnscache makes only one log entry.

Field Meaning
type The type of records needed.
name The domain name for which records were needed.

cached cname name cname

dnscache found the answer to a client query in its cache, and the answer was a CNAME record. In this case, dnscache starts over, looking for the same record type but with the “canonical name”.

Field Meaning
name The domain name for which the client wants records.
cname The “canonical name” for name. meaning that name should be treated as an alias for cname.

cached ns control server

dnscache needed to know the authoritative nameservers for some domain, and found a set of nameservers for the domain, or some ancestor of it, in the cache. dnscache creates one log entry for each nameserver in the set. The actual name for which dnscache needed to find nameservers is on the query log entry preceding the set of cached ns log entries.

For example:

query 673 7f000001:09b6:7c48 1 www.windows.com.
cached ns com. a.root-servers.net.
cached ns com. e.gtld-servers.net.
cached ns com. f.gtld-servers.net.
cached ns com. j.gtld-servers.net.
cached ns com. k.gtld-servers.net.
cached ns com. a.gtld-servers.net.
cached ns com. m.gtld-servers.net.
cached ns com. g.gtld-servers.net.
cached ns com. c.gtld-servers.net.
cached ns com. i.gtld-servers.net.
cached ns com. b.gtld-servers.net.
cached ns com. d.gtld-servers.net.

dnscache needed to know the authoritative nameservers for www.windows.com, and the nearest set of nameservers in its cache was the set of nameservers that are authoritative for com.

Field Meaning
control The domain name for which server is authoritative.
server The name of a server that is authoritative for control.

cached nxdomain name

dnscache needed to find records for name and found a cached nxdomain entry in the cache.

Field Meaning
name The domain name for which records were requested.

drop serial error

dnscache decided not to try to respond to a client query.

Field Meaning
serial The serial number of the client request. See query for an explanation of client request serial numbers.
error The reason dnscache dropped the request:

timed out
dnscache had MAXUDP (200) active UDP queries and received another UDP query. It dropped the oldest active query.
permission denied
dnscache received an AXFR request.
permission denied
dnscache received an AXFR request.
out of memory
dnscache could not allocate memory for parsing a query packet or building a response.
XXX more errors…

lame serverip name control

dnscache found a lame delegation. This means that the server is supposed to be authoritative for some domain, but isn’t.

Field Meaning
serverip The IP address of the lame server.
name The domain name for which records were requested.
control The domain for which the server is supposed to be authoritative, but isn’t.

nodata serverip ttl type name

dnscache received a “no data” response. This means that the server has records for the requested name, but no records of the requested type.

Field Meaning
serverip The IP address of the responding server.
ttl The time-to-live of the SOA record in the response. This is how long dnscache is allowed to cache the negative response. dnscache will not cache a negative response for more than one hour in any case.
type The requested record type.
name The domain name for which records were requested.

nxdomain serverip ttl name

dnscache received a “Name Error” response. This means that the server has no records of any type for the requested name.

Field Meaning
serverip The IP address of the responding server.
ttl The time-to-live of the SOA record in the response. This is how long dnscache is allowed to cache the negative response. dnscache will not cache a negative response for more than one hour in any case.
name The domain name for which records were requested.

query serial clientip:clientport:id type name

dnscache received a packet containing a query and intends to try to answer it.

Field Meaning
serial The number of queries dnscache received prior to this query since starting, plus one. In other words, serial number 1 is assigned to the first query received, serial number 2 is assigned to the second query received, and so on. The counter is stored using 64 bits, so chances of it wrapping are unlikely.
clientip The source IP address of the packet. Presumably this is the IP address from which the packet was sent, though it could have been spoofed.
clientport The source UDP port of the packet.
id The id from the packet. The id is chosen by the client, and the server will include it in the response.
type The type of records the client wants.
name The domain name for which the client wants records.

rr XXX

sent serial length

dnscache finished constructing a response to a query. If the query came over UDP, then dnscache also sent the response. If the query came over TCP, then dnscache did not send the response before making this log entry. (Sending over TCP may block so dnscache trickles the data out as part of its main loop.)

Field Meaning
serial The serial number of the client request to which dnscache responded. See query for an explanation of client request serial numbers.
length The number of bytes in the response.

servfail name error

dnscache sent a packet with rcode 2, “Server failure”, because it encountered an error.

Some of the errors that can make dnscache do this:

failure to allocate storage for a received DNS packet
failure to create a UDP socket
failure to set the O_NONBLOCK flag on the UDP socket
failure to bind the UDP socket to a port
failure to transmit a packet to any of up to 16 nameservers and receive a response packet with an rcode of 0 (no error) or 3 (NXDOMAIN), with four attempts per nameserver
failure to create a TCP socket
failure to set the O_NONBLOCK flag on the TCP socket
failure to bind the TCP socket to a port
failure to connect the TCP socket to any of up to 16 nameservers (one attempt per nameserver), transmit a query to the nameserver, and receive a response packet with an rcode of 0 (no error) or 3 (NXDOMAIN)

There may be other ways for dnscache to log/send servfail, but these are all the ones I have found from inspecting the source code.

Field Meaning
name The domain name for which the dnscache was trying to find records.
error As of djbdns version 1.05, the error message will always be “input/output error”, because the only call to log_servfail is in doit in query.c, like this:

errno = error_io;
if (state == 1) goto HAVEPACKET;
if (state == -1) {
log_servfail(z->name[z->level]);
goto SERVFAIL;
}

starting

dnscache logs this entry when it starts up.

stats query-count cache-motion udp-active tcp-active

This entry contains statistics about dnscache’s behavior, both since startup and at the moment the entry was logged.

Field Meaning
query-count The total number of queries received by dnscache since startup.
cache-motion The total number of bytes dnscache has stored in its cache since startup. This says nothing about the maximum size of the cache or how much data has been evicted from the cache. See djb’s explanation of cache motion for more information.
udp-active The number of queries that dnscache has received via UDP but not yet responded to or dropped.
tcp-active The number of queries that dnscache has received via TCP but not yet responded to or dropped.

tx gluelessness type name control serverips…

This line indicates that dnscache transmitted a query.

Field Meaning
gluelessness The amount of gluelessness that generated this query.

Read djb’s explanation of gluelessness.

For the case of www.monty.de, the queries dnscache sent for www.monty.de have gluelessness 0. The query sent for ns.norplex.net has gluelessness 1. The query for vserver.neptun11.de has gluelessness 2. The query sent for ns.germany.net has gluelessness 3. And so on.
type The requested record type.
name The domain name for which records are being requested.
control dnscache sends a query to a server because it has been told that the server is authoritative for the domain in question, or some ancestor thereof. The control field shows the domain for which dnscache thinks the server is authoritative.

For example, suppose the cache is empty, and you ask dnscache for the A records for example.com. First, dnscache will send a query to a root server, because the root server is authoritative for the root domain (written “.”). So the tx line for the query will have “.” in the control field.

The root server will give dnscache a list of servers that are authoritative for the com domain. dnscache will ask one of the com servers for the A records for example.com, and the log entry will have com. in the control field.

Suppose the com server says that ns.example.net is authoritative for example.com. Then when dnscache asks ns.example.net for A records for example.com, the log entry will have example.com in the control field.
serverips The IP addresses of all the authoritative servers for the control domain, in random order. dnscache transmits the query to the first server in the list. If the server doesn’t respond, dnscache moves on to the next server in the list.

(The blank space above allows the tx named anchor to appear at the top of your window.)