Logcheck is a program that helps you in sorting out the relevant messages from the various (system) log files on Unix systems. It sifts through them on a regular basis (via crontab) and sends its findings to the system administrator by mail. That mail contains all the possibly important events, break-in attemts and other strange messages.

It was created by Psionic Software (now merged with Cisco) and is confirmed to run on many of the most popular Unix systems, including OpenBSD.

Download

Since www.psionic.com isn’t providing the package anymore (because of the merger with Cisco), you can download Logcheck from PureBSD.

You can also install the port (or package) called «logsentry». LogSentry and Logcheck are the same thing, but since Psionics merger with Cisco it lives on with a different name.

The port is located in /usr/ports/security/logsentry. The binary package has a name equal or similar to «logsentry-1.1.1p1.tgz» and can be found on any FTP site carrying OpenBSD.

Installation

By source:
cd /tmp
tar xvfz /location/of/logcheck-1.1.1.tar.gz
cd logcheck-1.1.1
make generic

By port:
cd /usr/ports/security/logsentry
make
make install

By binary package:
pkg_add logsentry-1.1.1p1.tgz

Configuration

Make sure that /usr/local/etc/logcheck.sh is setup the way you prefer.

If you do not want to have root receive mail from Logcheck, but a local user or remote user, edit the SYSADMIN variable:

SYSADMIN=alexdehaas@puur.rookgordijn.nl

All «$LOGTAIL» lines should be commented out, except the ones for the OpenBSD log files:

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

# OpenBSD 3.4
$LOGTAIL /var/cron/log > $TMPDIR/check.$$
$LOGTAIL /var/log/authlog >> $TMPDIR/check.$$
$LOGTAIL /var/log/daemon >> $TMPDIR/check.$$
$LOGTAIL /var/log/maillog >> $TMPDIR/check.$$
$LOGTAIL /var/log/messages >> $TMPDIR/check.$$
$LOGTAIL /var/log/secure >> $TMPDIR/check.$$
$LOGTAIL /var/log/wlanlog >> $TMPDIR/check.$$

Running Logcheck

Edit root’s crontab:

crontab -e

And add the following two lines:

# Security: Check every 30 minutes logfiles
*/30 * * * * /usr/local/etc/logcheck.sh

Filtering log messages

If you do or do not wish to see certain log messages mailed to you, you can edit thelogcheck.[hacking,ignore,violations,violations.ignore] files located in/usr/local/etc. All lines in those files are patterns in the regular expression format used bygrep.

• logcheck.hacking:
  This file contains lines which consist of patterns indicating an active system attack. You can add your own patterns to it when deemed necessary.
• logcheck.violations:
  This file contains lines with patterns indicating some sort of negative system activity. You can add your own patterns to it when deemed necessary.
• logcheck.violations.ignore:
  Lines of patterns in this file are used to filter out log messages thatlogcheck.violations picks up as being negative system events. In other words: the more specific pattern lines in logcheck.violations.ignore override the more generic pattern lines in logcheck.violations.

  You can add your own exceptions to it. Examples:

  sendmail.*: .*: Authentication-Warning: .*: .* owned process doing -bs
sm-mta.*: ruleset=check_relay, .* reject=.* .*


• logcheck.ignore:
  This file contains lines with keywords indicating that a message should not be reported. Normally, all log messages are reported as «unusual system activity», so you won’t miss anything not accounted for in the other logcheck files. So this is a catch-all file.

  You can add your own exceptions to it. Examples:

  dhcpd: DHCPDISCOVER from .* via xl0
dhcpd: DHCPREQUEST for 10.0.* from .* via xl0
dhcpd: DHCPOFFER on 10.0.* to .* via xl0
dhcpd: DHCPACK on 10.0.* to .* via xl0
wlanmon: WLAN bridge connection is just fine\.
syslogd: restart
spamd.*: .*\..*\..*\..*: connected \(.*\)
spamd.*: .*\..*\..*\..*: disconnected after .* seconds\.
spamd.*: .*\..*\..*\..*: \<.*\> -\> \<.*\>
spamd.*: .*\..*\..*\..*: From: .* To: .*
ftp-proxy.*: accepted connection from 10.0.0.*:.* to .*
cvs.*: connect from .*.intranet.atomicvoid.net

  Now log messages matching any of the above lines are being ignored by Logcheck.

Introduction

Probably most people know Wietse Venema’s TCP Wrapper software as a result of their usage ofinetd, the internet «super-server», in combination with tcpd. An arbitrary line of/etc/inetd.conf, the configuration file of inetd:

ident stream tcp nowait nobody /usr/libexec/tcpd /usr/libexec/identd -elo

The /usr/libexec/tcpd here is the program that takes a look at the incoming connection that inetd has accepted on behalf of the identd program. If it thinks it can allow the connection, it passes it to identd. If not, it unleashes hell (well,.. it just drops the connection) on that TCP connection and identd will never see a packet coming from the remote client.

But not only tcpd uses the wrapping functionality. By default OpenBSD’s Sendmail and SSH daemon are linked to LIBWRAP and can use its functionality too.

Access control flow/algorithm

To tell tcpd and other programs linked to LIBWRAP which connection to which daemon/service to allow, one should modify or leave alone the following two files:
/etc/hosts.allow
/etc/hosts.deny

In hosts.allow you put the remote host/local daemon combinations that you approve of having a happy TCP chatter. If a remote host, the client, likes to chat with a local daemon and that client/daemon pair has a positive match in the hosts.alllow file, the client is granted access to the daemon’s services. The hosts.deny file is ignored.

If there is no positive match, the hosts.deny is checked for a match. If the tcp wrapper can find a positive match in hosts.deny, the client is not granted access to the daemon and the TCP connection gets dropped. But if the client/daemon pair is not matched, the connection to the daemon is granted.

If one or both of the hosts access files is missing, the above explained flow treats them as if they exist, but are empty.

The control flow is a Yes-Unless kind of strategy. You can come in, unless you’re mentioned inhosts.deny. To reverse that strategy that you can configure hosts.deny to deny all access. Then all clients trying to communicatie with a daemon should be listed in hosts.allow. Then we have a No-Unless situation created.

Configuration

Here I’ll explain how to create that el neato No-Unless situation with some real life X-rated examples.

First we edit hosts.deny to disallow life, the universe and everything:

ALL: ALL

Then we edit hosts.allow to let the complete internet whisper in the ears of our SSH daemon, Sendmail and our ident daemon:

identd: ALL
sendmail: ALL
sshd: ALL

Don’t use above example if you don’t like allowing anyone to access the Sendmail daemon, ssh daemon and/or ident daemon.
The combination of the above example of the hosts.deny and hosts.allow allows the complete internet access to your sendmail, ssh daemon and ident daemon, but completely forbids anyone to access any other daemon/service you’re running.

If you’d like to have hosts on your intranet access to your POP3 daemon, but not anyone else you can do something like this in hosts.allow:

popa3d: 127.0.0.1 192.168.0.

With this rule access is granted to our POP3 daemon popa3d from localhost and the «192.168.0.» IP range. You can read «192.168.0.» like 192.168.0.*, 192.168.0.1 – 192.168.0.254, or 192.168.0.0/24. It comes down to 254 IP addresses that start with «192.168.0″.

More information

More information can be obtained by reading the following man pages:

- hosts_access(5)
- hosts_options(5)
- tcpd(8)

They provide far more advanced information then you can find here and recommended reading if you’d like to tailor the hosts access files to your own specific (and complex?) needs.

SSH client

The SSH client, /usr/bin/ssh on OpenBSD systems, is used to login on a remote host or directly execute a program remotely.
Login to remote host:

ssh -l username remote-host.example.org
ssh username@remote-host.example.org

If your username is the same on the remote end as it is where you execute the SSH client, providing a username is not necessary.

At the time of your first login attempt you’re asked by your own SSH client if you’d like to accept the public key of the remote host. Enter «yes» if you verified the authenticity of that key. That public key of the remote host is then saved to ~/.ssh/known_hosts.
That key is checked with the offered public key each time you’re connection again to this remote host. When the offered key differs from the one previously stored, your SSH client will alert you about it and terminates the connection process.
This way, accidentally logging in to a host pretending to be the host you’d like to connect with, can be prevented.
If you see such a warning from your SSH client, verify with your sysadmin if that new key is a valid/authentical public key of the host. There are valid reasons for hosts having a new public key.

scp: secure copy

scp is used to copy files securely to a remote host. Its syntax is not that different from cp orrcp. I think it’s best to just provide some examples of its usage.

Copying files from the current host to remote host:

scp onefile.tgz username@remote-host.example.org:adirectory
scp *.tgz username@remote-host.example.org:/tmp/adirectory
scp -r /tmp/backup username@remote-host.example.org:/tmp/adirectory

Copying files from remote host to this host:

scp 'username@remote-host.example.org:myfiles/onefile.tgz' .
scp 'username@remote-host.example.org:myfiles/*.tgz' .
scp -r 'username@remote-host.example.org:myfiles' /tmp/backup

sftp: secure ftp

sftp is best compared and used as a rather lite edition of a standard text-mode ftp client. As far as I can see it only differs from FTP in that it’s using encryption to transmit data and if I’m not mistaken, all communication between client and server goes through port 22.

SSH daemon

The SSH daemon is the program that accepts and handles the incoming SSH connections. It is run by default on OpenBSD systems and configured pretty secure. The only thing I changed was the option that allows remote logins to root, since I’m rather paranoid (:
To turn off the allowance of remote root logins, edit /etc/sshd_config and change thePermitRootLogin to no:

PermitRootLogin no

sftp-server

The sftp-server is the daemon or server side of the Secure FTP protocol. To be able to use sftp to your host, edit the SSH daemon configuration file /etc/sshd_config. Search for the following line and remove the hash-sign in front of it:

Subsystem sftp /usr/libexec/sftp-server

Then restart your SSH daemon.

Note: it is Considered Wise(tm) to backup any files before you edit them to something likeorigfile-dist where origfile is the name of the file you’re about to modify.

I tortured my system with the following:

1. Login to the machine as root.
   Add your own user account.
   Put that account in de group wheel, so you will be able to su to root.
2. If you’re just a little paranoid, you should edit /etc/sshd_config:
   «PermitRootLogin yes» -> «PermitRootLogin no»
   This disables root logins over the network and that’s a Good Thing(tm).
3. Different versions of OpenBSD have different services enabled/disabled by default. Check /etc/inetd.conf and /etc/rc.conf and disable what you don’t like and enable what pleases you. Use a portscanner like nmap to double check you haven’t forgotten anything to turn on or off.
4. OpenBSD’s 2.7 /etc/inetd.conf file contains some lines I like to comment out:

       ..
       finger
       ..
       comsat
       ntalk
       ..
       daytime
       time
       ..
       rstatd/1-3
       rusersd/1-3
       ..

   So I commented them out (-:

5. If portmap makes you puke, edit /etc/rc.conf and change portmap=YES into something better. For instance: portmap=NO.
6. /etc/inetd.conf contains a line for the ident daemon:
   ident stream tcp nowait nobody /usr/libexec/identd identd -elo
   But I’d like to run it through the tcp_wrapper, so I changed it to:
   ident stream tcp nowait nobody /usr/libexec/tcpd identd -elo
7. /etc/hosts.allow and /etc/hosts.deny define which hosts may or may not use certain system facilities. If you’re paranoid you place only one line in /etc/hosts.deny:

   ALL: ALL

   After that you define the hosts that do may connect to your system in /etc/hosts.allow, e.g.:

   in.proftpd: 192.168.0. trusted-host.microsoft.com .no-evil-here.net
   identd: ALL
   

8. cron is a neat, but powerful scheduler for Unices. But you might not want to have anyone being able to use it. For limited access create a file in /var/cron called allow if only a limited set of people may have a crontab. Create a deny file in that same directory if you want everyone to be able to use cron except a few nasty bastards you don’t like/trust enough.

   /var/cron/allow:

   root
alex
forge


9. Remote syslog. It is possible for whisper in syslogd‘s ear that it should send it’s log entries not only to the various files in /var/log, but also to a remote host listening to the UDP syslog port (udp/514).
   Fire up /etc/syslog.conf in vi and place anywhere you like the following line:

   *.*			@192.168.5.14

   Now syslogd will send ALL entries feeded to it also to udp/192.168.5.14:514. Be careful to only use tabs when editing /etc/syslog.conf. Spaces are poison forsyslogd.