abck / abck.1
.TH abck 1 TundraWare
abck \- Process intrusion attempts found in the system log.
abck [-dehilmsv]
\'abck\' is an interactive tool to examine intrusion attempts and
decide what, if anything, to do about them.  It reads through
/var/log/messages looking for evidence of an intrusion attempt. Upon
finding such a record, \'abck\' qualifies it against information
supplied by the user on the command line to determine if the record is
to be processed.  As packaged, \'abck\' handles several common types
of intrusion attempt records, but it can easily be expanded to handle

\'abck\' determines whether the record contains the name or IP address
of the source of the attack.  If it finds an IP address, it will
attempt to reverse the address into a name.  If it cannot find a
legitimate reverse, it will try to find the authority responsible for
that address.

Each matching record is presented to the user.  The user can do a
\'whois \' lookup on the record, pick or edit the domain name that
will be notified about the attack attempt, permanently forget the
record without processing it, skip the record, or quit the

Once the user has selected the domain to be notified (i.e., they
did not skip or forget a given record), \'abck\' formats and sends an
email to the \'abuse\' and \'root\' accounts at that domain, notifying
them of the intrusion attempt.  This email is also sent to the
\'root\' user on the machine that was invaded.  The email contains all
the relevant information about the machine which was attacked and
appends a copy of the log record containing evidence of the attempt.

Very often, an intruder will try several different means of entry,
thereby generating multiple log events.  This is common, for example,
if an attacker is running a port scanning program.  As \'abck\' runs ,
it keeps track of the attackers for which the user sends a
notification email. (The user may not necessarily send an email for
each and every intrusion attempt.)  If \'abck\' sees this intruder's
host name/address again later in the log, it will automatically send
the notification to the same place as the user originally selected
without any user interaction.

\'abck\' keeps track of the records that the user has either processed
(by sending an email notification) or \'forgotten\' (see below).
These records will not appear again in subsequent invocations of
\'abck\' (except with the \-s option; all matching records are
displayed, even if they've previously been processed).  This
information is kept in $HOME/.abck_history.

You may also specify a list of IPs or hostnames which \'abck\' is to
ignore by default.  This is useful when you do not wish to process
"attacks" from friendly locations or you wish to ignore intrusion
attempts from particular hosts for some other reason.  You can override
this default behavior using the -i and -l command line switches.

For details on how to specify what you want ignored, see the "FILES"
section below.

.B -d #
Only go back # days in the log.

.B -e string
Only process attack records which do not contain \'string\'.

.B -h
Display help information.

.B -i
Do not ignore the IPs/Hostnames found specified in
.B ~/.abck_ignored
Mutually exclusive with -l option.  Last one on command line
is obeyed.

.B -l
List ignored records as they are encountered.  List all ignored
IPs/Hostnames at the end of the program run.  Mutually exclusive with
-i option.  Last one on command line is obeyed.

.B -m string
Only process attack records if they contain \'string\'.

.B -s
Don't actually process the matching records, just display them.

.B -v
Display detailed version information.

Each time the record of an intrusion attempt is found which matches
the command line-selected constraints, it is presented to the user
for disposition.  A typical prompt looks like this:

Log Record:
 Matching log entry found in /var/log/messages

Who Gets Message For: <>? []

Pressing \'Enter\' accepts the default notification destination of
\'\'. Email is thus sent to \'\',
\'\', and \'root@local.machine...\'.  \'abck\' then
moves on to the next log entry.

Notice that this is the only way to actually send a notification
email.  The commands below allow the user to modify the notification
domain, but only when the user responds with a blank line, will email
actually be sent.

The user can also issue a number of commands at the prompt to do
further lookups on the attacker or modify the domain to be notified.

.B f

Forget this record entirely without processing it.  This means it will
not show up again in subsequent runs of \'abck\'.

.B l
Move left one subdomain in the default destination.

.B q
Quit the program.  This causes an immediate exit.  No history
information is written to disk, even if some records have been
processed and notification sent.

.B r
Move right one subdomain in the default destination. \'abck\' will
prevent the user from doing this beyond the point there are less than
two domains showing.  (A user can enter a destination with only one
level of domain manually.  This is useful for testing because it
allows \'localhost\' to be entered as the point of notification.)

.B s
Skip this record for now.  The next time \'abck\' is run, this record
will be presented the user again for disposition.

.B w
Run a \'whois\' lookup on the address/name found in the original log
entry.  This is helpful when reverse lookups fail and may provide
further information about the origin of the attack.

.B Any other string
Replace the current default domain to notify with this string.


As \'abck\' scans the system log, it looks for two keywords:
\'refused\' and \'unauthorized\'.  If it finds any of these keywords
anywhere in a given log record, it presents that record to the user
for disposition.

You can trivially add other \'trigger words\' to the list of
things \'abck\' looks for as signs of intrusion.  Suppose you
have an intrusion detection  program which writes log records like this:

Jul 27 00:27:35 eskimo inetd[56691]: Intruder foiled

To get \'abck\' to present records like this to the user for disposition,
you only need two things.  First, you need a unique trigger word that
only appears in records of this type, say, \'foiled\'.  Then, you need
to know which field within that record contains either the host name or
IP address of the attacker.  The first field is 0, so in this example,
it would be field 6.

To get \'abck\' to recognize this type of record, merely add this 
information to the
.B AttackKeys
data structure in the program.  This
is a Python dictionary, so all entries are of the form:

"keyword" : Fieldnum,


.B ~/.abck_history
\- History of all records user has either processed or forgotten.

.B ~/.abck_ignored
\- List of all IPs or Hostnames you want to ignore by default.  Must
have only one entry per line with no whitespace or comment characters.
You may enter partial entries so that they match multiple attacking hosts.
The rule is that partial entries for IPs should be truncated on the right
and partial entries for Hostnames should be truncated on the left.  For
example, 192.168.3 will ignore everything from -
Similarly, the entry: will ignore any host in that domain
regardless of the less signficant subdomains.

You must have a reasonably current copy of 'python' installed for \'abck\'
to operate. Also, the \'dig\' and \'whois\' programs must be on the system
in a directory somewhere in $PATH.

None known as of this release, but the code is getting kind of ugly from
constant hacking.  Maintenance is starting to be painful.

abck is Copyright(c) 2001, 2002 TundraWare Inc.
For terms of use, see the abck-License.txt file in the program distribution.
If you install abck on a FreeBSD system using the 'ports' mechanism, you will
also find this file in /usr/local/share/doc/abck.
Tim Daneliuk