May 2015


Networking & telecommunications and Systems administration28 May 2015 at 14:01 by Jean-Marc Liotier
1  15.895697 2600:480e:4000:c00::3 -> 2001:470:1f12:425::2 DNS 94
  Standard query 0x896c  A wwW.ruWeNZORI.net
2  15.901855 2600:480e:4000:c00::7 -> 2001:470:1f12:425::2 DNS 94
  Standard query 0xe3e6  A Www.RuWEnzoRi.neT
3  16.557423 2600:480e:4000:c00::7 -> 2001:470:1f12:425::2 DNS 93
  Standard query 0x5040  A KiVu.grabEuH.COm
4  16.566121 2600:480e:4000:c00::3 -> 2001:470:1f12:425::2 DNS 93
  Standard query 0x9c91  A KIVU.grabeUH.cOM
5  17.211708 2600:480e:4000:c00::9 -> 2001:470:1f12:425::2 DNS 94
  Standard query 0x7b36  AAAA www.RUWENzORi.net
6  17.888244 2600:480e:4000:c00::9 -> 2001:470:1f12:425::2 DNS 93
  Standard query 0xc582  AAAA KiVu.gRabEUH.com
7  18.041786 2600:480e:4000:c00::7 -> 2001:470:1f12:425::2 DNS 93
  Standard query 0xcb72  AAAA Kivu.GRABEUh.coM

Well… WTF ? Who let the script kiddies out ? No one… Surprisingly: those are actually perfectly well-formed queries, using “0x20 Bit encoding“.

This technique was introduced in a 2008 paper, “Increased DNS Forgery Resistance Through 0x20-Bit Encoding – SecURItY viA LeET QueRieS” :

“We describe a novel, practical and simple technique to make DNS queries more resistant to poisoning attacks: mix the upper and lower case spelling of the domain name in the query. Fortuitously, almost all DNS authority servers preserve the mixed case encoding of the query in answer messages. Attackers hoping to poison a DNS cache must therefore guess the mixed-case encoding of the query, in addition to all other fields required in a DNS poisoning attack. This increases the difficulty of the attack”.

For example, Tor uses it by default for name lookups that a Tor server does on behalf of its clients.

Of course, this clever exploitation of a fortuitous behaviour did not go without inducing bugs… What a surprise !

Well… One less mystery.

Debian and Networking & telecommunications and Systems administration13 May 2015 at 13:34 by Jean-Marc Liotier

Upon reboot after upgrading yet another Debian host to sweet Jessie, I  was dismayed to lose connectivity – a slight annoyance when administering through the Internet. Later, with screen & keyboard attached to the server, I found that the Intel Ethernet interface using the e1000e module had not come up on boot… A simple ‘ip link set eth0 up’ fixed that… Until the next reboot.

/etc/network/interfaces was still the same as before upgrade, complete with the necessary ‘auto eth0’ line present before the ‘iface eth0 inet static’ line. And everything was fine once the interface had been set up manually.

Looking at dmesg yielded an unusual “[    1.818847] e1000e 0000:00:19.0 eth0: Unsupported MTU setting” – strange, considering I had been using a 9000 bits MTU without issue before… That error message let me to the cause of my problem: the driver maintainer chose that from kernel 3.15 onwards, calculation of the Ethernet frame’s length always takes into account the VLAN header, even when none is present… And I was running Linux 3.16:

diff --git a/drivers/net/ethernet/intel/e1000e/netdev.c b/drivers/net/ethernet/intel/e1000e/netdev.c
index d50c91e..165f7bc 100644
--- a/drivers/net/ethernet/intel/e1000e/netdev.c
+++ b/drivers/net/ethernet/intel/e1000e/netdev.c
@@ -5687,7 +5687,7 @@ struct rtnl_link_stats64 *e1000e_get_stats64(struct net_device *netdev,
 static int e1000_change_mtu(struct net_device *netdev, int new_mtu)
 {
     struct e1000_adapter *adapter = netdev_priv(netdev);
-    int max_frame = new_mtu + ETH_HLEN + ETH_FCS_LEN;
+    int max_frame = new_mtu + VLAN_HLEN + ETH_HLEN + ETH_FCS_LEN;
 
     /* Jumbo frame support */
     if ((max_frame > ETH_FRAME_LEN + ETH_FCS_LEN) &&

As the author remarked: “The hardware has a set limit on supported maximum frame size (9018), and with the addition of the VLAN_HLEN (4) in calculating the header size (now it is 22) , the max configurable MTU is now 8996”.

So there…

diff --git a/network/interfaces b/network/interfaces
index ee4e27d..a094569 100644
--- a/network/interfaces
+++ b/network/interfaces
@@ -7,7 +7,7 @@ iface lo inet loopback

 auto eth0
 iface eth0 inet static
-       mtu 9000
+       mtu 8996
        address 10.128.0.2
        network 10.128.0.0
        netmask 255.255.255.0

And a reboot later the host is still connected – problem solved. Now to avoid fragmentation I’ll have to set a few other hosts’ MTU to 8996 too… Damn.