Picture of Jürgen Kreileder

Archive for the ‘Network’ Category

Enabling IPv6 for This Site

In a few days I will start providing this site via an IPv6 address (normal IPv4 support will stay in place, of course). If you should experience problems accessing my blog, please drop me a mail.

Speedport Routers Eat Your DNS SOA Requests in Modem-Mode

Some years ago I switched to using a Speedport W701V from Deutsche Telekom on my ADSL line at home. I set it up in modem-mode and let a small Linux box handle everything else. This setup had worked fine with other modems but shortly after switching to the Speedport I noticed that my local caching DNS server didn’t work correctly anymore. I didn’t really connect the dots at this point, though.

That happened a few days later when I tried to use Apple’s Back to My Mac — it just didn’t work. After some network tracing I found out that the Apple machine sent DNS SOA requests but never got a reply back. It turned out that all SOA request got blocked somewhere. Sending requests to my own name server (host -t soa blackdown.de ns.blackdown.de) and tracing DNS there showed that no packet ever arrived.

I put the Speedport back into router-mode at this point and, who would have guessed it, SOA requests worked fine again.

After fruitless discussions with Deutsche Telekom support (it was impossible to find anyone who even remotely understood what I was talking about) and sending a bug report to AVM (the 701V actually is a FRITZ!Box) which never got an answer, I finally solved the problem by putting a Freetz firmware on the Speedport. This firmware had an option to disable the PPPoE-Filter. After disabling the filter the device worked flawlessly in modem-mode.

Now, a few days ago, I switched to VDSL and got a new router: a Speedport W920V.
First thing I did was to put it into modem-mode. And there it was again, the DNS SOA problem!

Knowing what the problem was, I found a simpler fix this time:

  1. Download the configuration from the device
  2. Manually change dnsfilter_for_active_directory = yes; to dnsfilter_for_active_directory = no; in the pppoefw section
  3. Manually change ipnetbiosfilter = yes; to ipnetbiosfilter = no; in the pppoefw section
  4. Insert a NoChecks=yes line after the Country=… line in the header to make the device accept the modified file although its checksum is wrong now
  5. Upload the modified configuration to the device

(If you have a local NTP server, you also might want to add it to the server_list in the ntpclient section while editing the configuration of the Speedport.)

cyrus_sasl patch for Exim 4

The Exim 4 source code supports authentication with SASL since version 4.43. Debian started enabling this feature in exim4_4.50-2. After I’ve had upgraded to that version and replaced my saslauthd authenticators with brand-new cyrus_sasl authenticators, I’ve noticed that auth.log got flooded with entries like ‘exim4: OTP unavailable because can't read/write key database /etc/opiekeys: No such file or directory.’

My exim configuration uses three different cyrus_sasl authenticators and each exim invocation resulted in three of these OTP warnings because exim calls sasl_listmech() for each configured authenticator. It doesn’t specify a limiting mech_list, that means SASL will test which of all installed mechs actually can be used for authentication. Debian’s SASL package includes libotp.so, so it also tries to use OTP which is not configured on my system.

There are two ways to get rid off the warnings:

  • Remove /usr/lib/sasl2/libotp.*. You’ll have to do this after each upgrade of the libsasl2-modules package.
  • Rebuild exim with this patch. The patch specifies a limiting mech_list option for SASL. This limits sasl_listmech() to the mechs used in the exim configuration. Other mechs won’t be tried anymore.

May 3rd, 2005: A slightly modified version of the patch has been integrated into Exim CVS and will be included in the next Debian release of exim4 (see Debian bug #299743)

Exim 4 and Dynamic IP-Addresses

I’ve recently changed my network connection at home to a provider which assigns dynamic addresses. Exim always provided a broken HELO/EHLO name to my smarthost since then because my externally visible hostname changes each time I connect. I’m now using Exim’s Perl interface to lookup the assigned hostname when connecting my smarthost:

  • /etc/exim4/exim.pl:
    Don’t forget to change ppp0 to the interface you want to handle!
    #! /usr/bin/perl
    # Requires libio-interface-perl
    use strict;
    use IO::Socket;
    use IO::Interface;
    sub get_remote_helo_data()
        my $s = IO::Socket::INET->new(Proto => 'udp');
        my $addr = inet_aton($s->if_addr('ppp0'));
        my $hostname = gethostbyaddr($addr, AF_INET);
        $hostname = '' if (!$hostname);
        return $hostname;
  • /etc/exim4/conf.d/main/50_exim4-localconfig_perl:
    perl_at_start = true
    perl_startup = do '/etc/exim4/exim.pl'
  • Add the following code to the appropriate transport, e.g. remote_smtp_smarthost:
    helo_data = \
      ${if >{${strlen:${perl{get_remote_helo_data}}}}{0} \
                     {${perl{get_remote_helo_data}}} \

Mitigating SSH Brute Force Attacks with ipt_recent

As my SSH server only accepts public key based authentication, I’m not really worried about brute force password attacks. But these scans tend to clobber my auth.log. So after some discussion with Andrew Pollock, I’ve written a few custom actions for my shorewall setup. They use the ipt_recent module which allows to track seen IP addresses and match against them using some criteria.

The Limit action can be used to limit accepted connections per IP and timeframe. The hardcoded limit currently is 6 connections per 60 seconds. If an IP tries to connect more often, the attempts will be DROPed.

The Whitelist action provides some simple port-knocking whitelist. If you know the WHITELIST_PORT and can lift the limits imposed by the Limit action for your IP and 60 seconds by connecting to that port.

Here’s how you can integrate those two actions:

  • Create two empty files:
    • shorewall/action.Limit
    • shorewall/action.Whitelist
  • Copy Limit and Whitelist to the shorewall directory
  • Add Limit and Whitelist to shorewall/actions
  • Set WHITELIST_PORT in shorewall/params
  • Use Limit in shorewall/rules, for instance:
    Limit:ULOG:SSH    net  fw  tcp  ssh
    Limit:ULOG:IMAP   net  fw  tcp  imap,imaps

    Note: You must use the <action>:<log>:<tag> format for the rules. Limit uses the <tag> for the ipt_recent table name.

  • Optionally add a Whitelist rule:
    Whitelist:ULOG    net  fw

If you’re running OpenSSH 3.9 or later, you additionally might want to set MaxAuthTries to 1 (see sshd_config(5)).

May 9th, 2005: I have found a bug in the ipt_recent module, see this article for more information and a fix.