edeca.net » linux

Adding fake ethernet headers to pcap files

David — Mon, 20 Jun 2011 10:32:48 +0000

Occasionally I see packet captures which have been saved as Raw IP, which can really mess up many of the tools developed to deal with pcap. Anything based on libnids, including the Perl module I maintain, cannot deal with it and will produce no (or bizarre) results. Wireshark displays these captures just fine, with “Raw packet data – no link information available” just above the IP layer.

There are many situations where packet capture will lack the ethernet header for a good reason, but if you simply want to run it through other tools that deal only with IP and above then adding a fake header is a viable choice.

Fortunately, adding a “fake” ethernet header to these pcap files using tcprewrite (part of the tcpreplay suite) is simple:

$ tcprewrite --dlt=enet --enet-dmac=00:11:22:33:44:55 --enet-smac=66:77:88:99:AA:BB --infile=input.pcap --outfile=output.pcap

Overriding the output data layer type is essential, as is providing the ethernet MAC addresses of the two endpoints. That’s all there is to it.

tcprewrite is available as part of the Debian package tcpreplay.

Limiting command runtime in Linux

David — Sun, 02 May 2010 10:55:10 +0000

It is sometimes useful to limit the running time of a process, either to stop it from using up all resources or to make sure nightly cron jobs don’t continue into working hours.

I needed this for rsync, to let a remote backup server slowly catch up if large amounts of data were added to the live server during the day. A useful post on the rsync mailing list discusses an rsync patch but also the timeout command.

After installing (the Debian package is simply timeout) it is as easy as running with the number of seconds to run for:

$ timeout 21600 rsync -a ...

It is also possible to specify the signal which will be sent to a program, which is useful if you do not want to simply send SIGKILL. I used SIGHUP in the hope that rsync would have a chance to exit gracefully:

$ timeout -1 21600 rsync -a ...

A full list of signals and their numeric values can be found in man 1 kill.

A wrapper script is also available from Johannes Buchner.

Training dspam from Thunderbird junk messages

David — Sun, 21 Feb 2010 14:53:20 +0000

Recently I have installed and configured dspam on my mailserver. It seems to work nicely but needs occasional training. I wanted to integrate this with Thunderbird so that users could automatically train dspam from their mail client.

Based on this code I knocked together a few lines of bash script which will scan junk mail directories on the server and automatically train dspam. This means that an end-user can click the “Junk” button in Thunderbird (or Mail.app, etc) and dspam will be trained for them automagically. The user could even just move the messages there manually, or use some sort of filtering or an extension.

The best bit is that it is completely transparent to the end user and doesn’t require them to forward messages with headers intact to a weird user-spam@example.net address in order to conduct training.

If you find it useful or make changes, please let me know in the comments below.

The code

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56

#!/bin/bash

########
# TrainDspam.sh
#
# Author: David Cannings
# Date: 21/02/2010
# Based on: http://tinyurl.com/yhky5w9
#
# This script scans mail directories for the Thunderbird "Junk" folder
# (or any other folder with the same name) and trains dspam with the
# messages contained within it.
#
# It can be used for periodic (e.g. daily) training of spam messages which
# a user has flagged as junk in their mail client.
#
# It will only train for accounts which appear to be using dspam.
########

########
# Configuration

# Path to mail directory, which should contain folders per domain and
# user e.g. /home/mail///
MAIL_PATH="/home/mail"

# Path to the directory containing 'dspam'
DSPAM_BIN_DIR="/usr/bin"

# Path to the directory containing the dspam user data files
DSPAM_DATA_DIR="/var/spool/dspam"

# If you want this script to delete messages from the Junk folder
# after training, set this to 1.
DELETE_MAIL=0

# DON'T EDIT BELOW THIS LINE
########

for FOLDER in `find $MAIL_PATH -name '.Junk' -type d -print`; do
DOMAIN=`echo $FOLDER | awk -F/ '{print $(NF-3)}'`
USER=`echo $FOLDER | awk -F/ '{print $(NF-2)}'`

# We only want to train for accounts that are dspam users,
# so check the data directory
if [ -d "${DSPAM_DATA_DIR}/data/${DOMAIN}/${USER}" ]; then
TRAINED_MESSAGES=0
cd $FOLDER/cur/
for MESSAGE in `ls -1`; do
TRAINED_MESSAGES=`expr $TRAINED_MESSAGES + 1`
cat $MESSAGE | $DSPAM_BIN_DIR/dspam --user ${USER}@${DOMAIN} --class=spam --source=error
[ $DELETE_MAIL -gt 0 ] && rm -f $NAME
done
echo "- Trained $TRAINED_MESSAGES messages for ${USER}@${DOMAIN}"
fi
done

Blocking SSH brute forcing using denyhosts

David — Thu, 07 Jan 2010 23:04:44 +0000

Tired of seeing repeated attempts to login to a Linux server you run? There are a number of options, all with their own benefits and disadvantages. The easiest way is to move the port that the SSH server runs on, perhaps to 2222 instead of 22. However. this can be annoying behind some firewalls and means that you need to specify the port each time you SSH to a host. This post looks at denyhosts, a viable alternative.

denyhosts will monitor your authorisation log (typically /var/log/auth.log) and ban IPs that repeatedly fail to authorise as a genuine user. It will deny future logins by adding the IP address to /etc/hosts.deny.

On a sensible Debian or Ubuntu install, getting denyhosts is as simple as running:

1	$ aptitude install denyhosts

denyhosts should work as soon as it is installed. However, a few options can be tweaked to make it work nicely. The configuration file is at /etc/denyhosts.conf.

Firstly, set a proper administration email by changing ADMIN_EMAIL. The option RESET_ON_SUCCESS might also be important to you, by setting it to yes the failure count for an IP address will be reset if there is a successful login. If you want the blocks to expire (which is more important if you use synchronisation) then you should tweak PURGE_DENY to a sensible value, for example 1 week.

Synchronisation is one nice feature of denyhosts that means that information on IPs that attempt SSH bruteforcing can be shared between servers. Information about synchronisation can be read in the FAQ but enabling it is as simple as uncommenting the SYNC_SERVER line. By default, your server will share information on bruteforcers and receive it from other administrators who run denyhosts.

You can check how denyhosts is working by watching the logfile at /var/log/denyhosts. You can see newly added blocks logged as a line like the below:

new denied hosts: ['202.107.228.xxx']

Of course, you don’t need this as you’ve already disabled SSH password logins and your firewall disables access to port 22 from anywhere except a specially crafted list of IPs. But for 5 minutes work, it provides some peace of mind.

vim vs. Linux extended ACLs

David — Sun, 02 Aug 2009 12:55:53 +0000

Extended ACLs on Linux can be incredibly useful. Permissions can actually be more secure whilst allowing a number of users or daemons access to a file, no longer are unwieldy groups necessary to allow reading or writing. But for some reason, I noticed that these extended ACLs disappeared when a file was edited in vim.

The solution is very simple, you just need to set backupcopy=yes in your .vimrc. Note that backupcopy=auto currently does not work.

The way that vim normally works is to rename the file you are working on and write a new file. This is fast and means that no files have to be deleted. Unfortunately, it also means that any special attributes that vim does not understand are lost.

Setting backupcopy=yes ensures that the original file is copied and then overwritten upon save. This takes a little longer, but will preserve the attributes correctly. More information can be found in the topic :help backupcopy inside vim.

You can check this page for a quick rundown or this one for a longer explanation on how ACLs work in Linux.