1. Creating Configuration Backups of HP Procurve Switches

    January 12, 2015

    I've created a tool called procurve-watch. It creates a backup of the running switch configuration through secure shell (using scp).

    It also diffs backed up configurations against older versions, in order to keep track of changes. If you run the script from cron every hour or so, you will be notified by email of any (running) configuration changes.

    The tool can backup hundreds of switches in seconds as it is running the configuration copy in parallel.

    A tool like Rancid may actually be the best choice for this task, but it didn't work. The latest version of Rancid doesn't support HP Procurve switches (yet) and older versions created backups containing garbled characters.

    I've released it on github, check it out and let me know if it works for you and you have suggestions to improve it further.

    Tagged as : Networking
  2. Configuring, Attacking and Securing VRRP on Linux

    January 02, 2015

    The VRRP or Virtual Router Redundancy Protocol helps you create a reliable network by using multiple routers in an active/passive configuration. If the primary router fails, the backup router takes over almost seamlessly.

    This is how VRRP works:

    vrrp

    Clients connect to a virtual IP-address. It is called virtual because the IP-address is not hard-coded to a particular interface on any of the routers.

    If a client asks for the MAC-address that is tied to the virtual IP, the master will respond with its MAC-address. If the master dies, the backup router will notice and start responding to ARP-requests.

    Let's take a look at the ARP table on the client to illustrate what is happening.

    Master is active:

    (10.0.1.140) at 0:c:29:a7:7d:f2 on en0 ifscope [ethernet]
    (10.0.1.141) at 0:c:29:a7:7d:f2 on en0 ifscope [ethernet]
    (10.0.1.142) at 0:c:29:b2:5b:7c on en0 ifscope [ethernet]
    

    Master has failed and backup has taken over:

    (10.0.1.140) at 0:c:29:b2:5b:7c on en0 ifscope [ethernet]
    (10.0.1.141) at 0:c:29:a7:7d:f2 on en0 ifscope [ethernet]
    (10.0.1.142) at 0:c:29:b2:5b:7c on en0 ifscope [ethernet]
    

    Notice how the MAC-address of the virtual IP (.140) is now that of the backup router.

    Configuring VRRP on Linux

    1. configure static IP-addresses on the primary and backup router. Do not configure the virtual IP on any of the interfaces. In my test environment, I used 10.0.1.141 for the master and 10.0.1.142 for the backup router.

    2. Because the virtual IP-address is not configured on any of the interfaces, Linux will not reply to any packets destined for this IP. This behaviour needs to be changed or VRRP will not work. Edit /etc/sysctl.conf and add this line:

      net.ipv4.ip_nonlocal_bind=1
      
    3. Run this command to active this setting:

      sysctl -p
      
    4. Install Keepalived

      apt-get install keepalived
      
    5. Sample configuration of /etc/keepalived/keepalived.conf

      vrrp_instance VI_1 {
          interface eth0
          state MASTER
          virtual_router_id 51
          priority 101
      
          authentication {
              auth_type AH
              auth_pass monkey
          }
      
          virtual_ipaddress {
              10.0.1.140
          }
      }
      
    6. Start keepalived:

      service keepalived start
      

    The only configuration difference regarding keepalived between the master and the standby router is the 'priority' setting. The master server should have a higher priority than the backup router (101 vs. 100).

    As there can be multiple VRRP configurations active within the same subnet, it is important that you make sure that you set a unique virtual_router_id.

    Please do not forget to set your own password in case you enable authentication.

    VRRP failover example

    This is what happens if the master is shutdown:

    64 bytes from 10.0.1.140: icmp_seq=148 ttl=64 time=0.583 ms
    64 bytes from 10.0.1.140: icmp_seq=149 ttl=64 time=0.469 ms
    64 bytes from 10.0.1.140: icmp_seq=150 ttl=64 time=0.267 ms
    Request timeout for icmp_seq 151
    Request timeout for icmp_seq 152
    Request timeout for icmp_seq 153
    Request timeout for icmp_seq 154
    64 bytes from 10.0.1.140: icmp_seq=155 ttl=64 time=0.668 ms
    64 bytes from 10.0.1.140: icmp_seq=156 ttl=64 time=0.444 ms
    64 bytes from 10.0.1.140: icmp_seq=157 ttl=64 time=0.510 ms
    

    After about five seconds (default) the standby router takes over and starts responding to the virtual IP.

    Security

    A host within the same subnet could just spoof VRRP packets and disrupt service.

    An attack on VRRP is not just theoretical. A tool called Loki allows you to take over the virtual IP-address and become the master router. This will allow you to create a DoS or sniff all traffic.

    VRRP security is also discussed in this document from the Loki developers.

    According to rfc3768 authentication and security has been deliberately omitted (see section 10 Security Considerations) from newer versions of the VRRP protocol RFC.

    The main argument is that any malicious device in a layer 2 network can stage similar attacks focussing on ARP-spoofing and ARP-poisoning so as the fundament is already insecure, why care about VRRP?

    I understand the reasoning but I disagree. If you do have a secure Layer 2 environment, VRRP becomes the weakest link. Either you really need to filter out VRRP traffic originating from untrusted ports/devices, or implement security on VRRP itself.

    Attacking VRRP with Loki

    I have actually used Loki on VRRP and I can confirm it works (at least) as a Denial-of-Service tool.

    I used Kali (Formerly known as Back-Track) and installed Loki according to these instructions. Please note the bottom of the page.

    What I did on Kali Linux:

    apt-get install python-dpkt python-dumbnet
    wget http://c0decafe.de/svn/codename_loki/packages/kali-1/pylibpcap_0.6.2-1_amd64.deb
    wget http://c0decafe.de/svn/codename_loki/packages/kali-1/loki_0.2.7-1_amd64.deb
    dpkg -i pylibpcap_0.6.2-1_amd64.deb
    dpkg -i loki_0.2.7-1_amd64.deb
    

    Then just run:

    loki.py
    

    vrrp attack

    This is only an issue if you already protected yourself against ARP- and IP-spoofing attacks.

    Protecting VRRP against attacks

    Keepalived offers two authentication types regarding VRRP:

    1. PASS (plain-text password)
    2. AH (IPSEC-AH (authentication header))

    The PASS option is totally useless from a security perspective.

    pass authentication

    As you can see, the password 'monkey' is visible and easily obtained from the VRRP multicast advertisements. So to me, it does not make sense to use this option. Loki just replayed the packets and could still create a DoS.

    So we are left with IPSEC-AH, wich is more promising as it actually does some cryptography using the IPSEC protocol, so there is no clear-text password to be captured. I'm not a crypto expert, so I'm not sure how secure this implementation is. Here is some more info on IPSEC-AH as implemented in Keepalived.

    AH authentication

    If I configure AH authentication, the Loki tool does not recognise the VRRP trafic anymore and it's no longer possible to use this simple script-kiddie-friendly tool to attack your VRRP setup.

    IPSEC-AH actually introduces an IPSEC-AH header between the IP section and the VRRP section of a packet, so it changes the packet format, which probably makes it unrecognisable for Loki.

    Running VRRP multicast traffic on different network segments

    It has been pointed out to me by XANi_ that it is possible with Keepalived to keep the virtual IP-address and the VRRP multicast traffic in different networks. Clients will therefore not be able to attack the VRRP traffic.

    In this case, security on the VRRP traffic is not relevant anymore and you don't really need to worry about authentication, assuming that untrusted devices don't have access to that 'VRRP' VLAN.

    Th first step is that both routers should have their physical interface in the same (untagged) VLAN. The trick is then to specify the virtual IP-addresses in the appropriate VLANs like this example:

    virtual_ipaddress {
    
        10.0.1.1/24 dev eth0.100
        10.0.2.1/24 dev eth0.200
    }
    

    In this example, virtual IP 10.0.1.1 is tied to VLAN 100 and 10.0.2.1 is tied to VLAN 200.

    If the physical router interfaces are present in the untagged VLAN 50 (example), the VRRP multicast traffic will only be observed in this VLAN.

    Some background information on working with VLANs and Keepalived.

    Closing words

    VRRP can provide a very simple solution to setup a high-availability router configuration. Security can be a real issue if untrusted devices reside in the same layer 2 network so implementing security with IPSEC-AH or network segmentation is recommended.

    Tagged as : VRRP
  3. Systemd Forward Secure Sealing of System Logs Makes Little Sense

    November 22, 2014

    Systemd is a more modern replacement of sysvinit and its in the process of being integrated into most mainstream Linux distributions. I'm a bit troubled by one of it's features.

    I'd like to discuss the Forward Secure Sealing (FSS) feature for log files that is part of systemd. FSS cryptographically signs the local system logs, so you can check if log files have been altered. This should make it more difficult for an attacker to hide his or her tracks.

    Regarding log files, an attacker can do two things:

    1. delete them
    2. alter them (remove / change incriminating lines)

    The FSS feature does not prevent any of these risks. But it does help you detect that there is something fishy going on if you would verify the signatures regularly. So basically FSS acts a bit like Tripwire.

    FSS can only tell you wether or not a log file has been changed. It cannot tell you anything else. More specifically, it cannot tell you the reason why. So I wonder how valuable this feature is.

    There is also something else. Signing (sealing) a log file is done every 15 minutes by default. This gives an attacker ample time to alter or delete the most recent log events, often exactly those events that need to be altered/deleted. Even lowering this number to 10 seconds would allow an attacker to delete (some) initial activities using automation. So how useful is this?

    What may help in determining what happened to a system is the unaltered log contents themselves. What FSS cannot do by principle is protect the actual contents of the log file. If you want to preserve log events the only secure option is to send them to an external log host (assumed not accessible by an attacker).

    However, to my surprise, FSS is presented as an alternative to external logging. Quote from Lennart Poettering:

    Traditionally this problem has been dealt with by having an external secured log server 
    to instantly log to, or even a local line printer directly connected to the log system. 
    But these solutions are more complex to set up, require external infrastructure and have 
    certain scalability problems. With FSS we now have a simple alternative that works without 
    any external infrastructure.
    

    This quote is quite troubling because it fails to acknowledge one of the raison d'être of external log hosts. It seems to suggest that FSS provides an alternative for external logging, where in fact it does not and cannot do so on principle. It can never address the fact that an attacker can alter or delete logs, whereas external logging can mitigate this risk.

    It seems to me that systemd now also wants to play the role as some crude intrusion detection system. It feels a bit like scope creep to me.

    Personally I just wonder what more useful features could have been implemented instead of allowing you to transfer a log file verification key using a QR code to your smartphone (What the hell?).

    This whole observation is not original, in the comments of the systemd author's blogpost, the same argument is made by Andrew Wyatt (two years earlier). The response from the systemd author was to block him. (see the comments of Lennart Poettering's blogpost I linked to earlier).

    Update: Andrew Wyatt behaved a bit immature towards Lennart Poettering at first so I understand some resentment from his side, but Andrews criticism was valid and never addressed by him.

    If the systemd author would just have implemented sending log events to an external log server, that would have been way more useful security-wise, I think. Until then, this may do...

    Tagged as : Logging
  4. Getting the Sitecom AC600 Wi-Fi Adapter Running on Linux

    November 01, 2014

    TL;DR Yes it works with some modifications of the driver source.

    A USB Wi-Fi adapter I used with a Raspberry Pi broke as I dropped it on the floor, so I had to replace it. I just went to a local shop and bought the Sitecom AC600 adapter as that's what they had available (with support for 5Ghz networking).

    I had some hope that I would just plug it in and it would 'just work™'. But no. Linux. In the end, the device cost me 30 euro's including taxes, but the time spend to get it to work may have made this a very expensive USB Wi-Fi dongle. And it's funny to think about the fact that the Wi-Fi dongle is almost the same price as the Raspberry Pi board itself.

    But I did get it working and I'd like to show you how.

    It started with a google for 'sitecom ac600 linux' which landed me on this page. This page told me the device uses a MediaTek chipset (MT7610U).

    So you need to download the driver from MediaTek. Here is a direct link

    So you may do something like this:

    cd /usr/src
    wget http://s3.amazonaws.com/mtk.cfs/Downloads/linux/mt7610u_wifi_sta_v3002_dpo_20130916.tar.bz2
    tar xjf mt7610u_wifi_sta_v3002_dpo_20130916.tar.bz2
    cd mt7610u_wifi_sta_v3002_dpo_20130916
    

    Now you would hope that it's just like this:

    make
    make install
    

    And we're happy right? Linux FTW! Well, NO! We're using Linux so we have to work for stuff that works right out of the box on Windows and Mac OS.

    So we first start with editing "include/os/rt_linux.h" and go to line ~279. There we make sure that we edit the struct like this:

        typedef struct _OS_FS_INFO_
     {
        kuid_t              fsuid;
        kgid_t              fsgid;
        mm_segment_t    fs;
     } OS_FS_INFO;
    

    Basically, the words int are replaced by kuid_t and kgid_t, or else, compilation will abort with an error.

    Ofcourse, the Sitecom AC600 has an USB identifier that is unknown to the driver, so after compilation, it still doesn't work.

    lsusb output:

    Bus 001 Device 004: ID 0df6:0075 Sitecom Europe B.V.
    

    So google landed me on this nice thread by 'praseodym' that explained the remaining steps. I stole the info below from this thread.

    So while we are in the source directory of the module, we are going to edit "common/rtusb_dev_id.c" and add

    {USB_DEVICE(0x0DF6,0x0075)}, /* MT7610U */
    

    So this will make the AC600 gets recognised by the driver. Now we also need to edit "os/linux/confik.mk" and change these lines like this:

    HAS_WPA_SUPPLICANT=y
    HAS_NATIVE_WPA_SUPPLICANT_SUPPORT=y
    

    So no, we are still not ready yet. I'm not 100 percent sure that this is required anymore, but I found this nice thread in Italian and a very small comment by 'shoe rat' tucked away at the end that may make the difference between a working device or not.

    We need to edit the file "os/linux/config.mk" and go to line ~663. Then, around that line, change

    CHIPSET_DAT = 2860
    

    to:

    CHIPSET_DAT = 2870
    

    Yes. Finally! Now you can do:

    make
    make install
    

    Imagine that such a 'make' takes about 20 minutes on a Raspbery Pi. No joke.

    Now you can either do this:

    modprobe mt7650u_sta
    

    You should see something like this:

    root@raspberrypi:/usr/src# lsmod
    Module                  Size  Used by
    snd_bcm2835            16181  0 
    snd_pcm                63684  1 snd_bcm2835
    snd_page_alloc          3604  1 snd_pcm
    snd_seq                43926  0 
    snd_seq_device          4981  1 snd_seq
    snd_timer              15936  2 snd_pcm,snd_seq
    snd                    44915  5 snd_bcm2835,snd_timer,snd_pcm,snd_seq,snd_seq_device
    soundcore               4827  1 snd
    mt7650u_sta           895786  1 
    pl2303                  7951  0 
    usbserial              19536  1 pl2303
    

    You should be able to see a 'ra0' device when entering ifconfig -a or iwconfig and just configure it like any wireless device (out-of-scope).

    So once up-and-running, the Sitecom AC600 works fine under Linux and even sees and connects to 5 GHz networks. But not without a caveat of-course. I needed to configure a 5 GHz channel below 100 (I chose 48) on my Apple Airport Extreme, or the Wi-Fi dongle would not see the 5GHz network and would not be able to connect to it.

    So I hope somebody else is helped by this information.

    Tagged as : Wi-Fi
  5. The ZFS Event Daemon on Linux

    August 29, 2014

    If something goes wrong with my zpool, I'd like to be notified by email. On Linux using MDADM, the MDADM daemon took care of that.

    With the release of ZoL 0.6.3, a brand new 'ZFS Event Daemon' or ZED has been introduced.

    I could not find much information about it, so consider this article my notes on this new service.

    If you want to receive alerts there is only one requirement: you must setup an MTA on your machine and that is outside the scope of this article.

    When you install ZoL, the ZED daemon is installed automatically and will start on boot.

    The configuration file for ZED can be found here: /etc/zfs/zed.d/zed.rc. Just uncomment the "ZED_EMAIL=" section and fill out your email address. Don't forget to restart the service.

    ZED seems to hook into the zpool event log that is kept in the kernel and monitors these events in real-time.

    You can see those events yourself:

    root@debian:/etc/zfs/zed.d# zpool events
    TIME                           CLASS
    Aug 29 2014 16:53:01.872269662 resource.fs.zfs.statechange
    Aug 29 2014 16:53:01.873291940 resource.fs.zfs.statechange
    Aug 29 2014 16:53:01.962528911 ereport.fs.zfs.config.sync
    Aug 29 2014 16:58:40.662619739 ereport.fs.zfs.scrub.start
    Aug 29 2014 16:58:40.670865689 ereport.fs.zfs.checksum
    Aug 29 2014 16:58:40.671888655 ereport.fs.zfs.checksum
    Aug 29 2014 16:58:40.671905612 ereport.fs.zfs.checksum
    ...
    

    You can see that a scrub was started and that incorrect checksums were discovered. A few seconds later I received an email:

    The first email:

    A ZFS checksum error has been detected:
    
      eid: 5
     host: debian
     time: 2014-08-29 16:58:40+0200
     pool: storage
     vdev: disk:/dev/sdc1
    

    And soon thereafter:

    A ZFS pool has finished scrubbing:
    
      eid: 908
     host: debian
     time: 2014-08-29 16:58:51+0200
     pool: storage
    state: ONLINE
    status: One or more devices has experienced an unrecoverable error.  An
        attempt was made to correct the error.  Applications are unaffected.
    action: Determine if the device needs to be replaced, and clear the errors
        using 'zpool clear' or replace the device with 'zpool replace'.
      see: http://zfsonlinux.org/msg/ZFS-8000-9P
     scan: scrub repaired 100M in 0h0m with 0 errors on Fri Aug 29 16:58:51 2014
    config:
    
        NAME        STATE     READ WRITE CKSUM
        storage     ONLINE       0     0     0
          mirror-0  ONLINE       0     0     0
            sdb     ONLINE       0     0     0
            sdc     ONLINE       0     0   903
    
    errors: No known data errors
    

    Awesome!

    The ZED daemon executes commands based on the event class. So it can do more than just send emails, you can customise different actions based on the event class. The event class can be seen in the zpool events output.

    One of the more interesting features is automatic replacement of a defect drive with a hot spare, so full fault tolerance is restored as soon as possible.

    I've not been able to get this to work. The ZED scripts would not automatically replace a failed/faulted drive.

    There seem to be some known issues. The fixes seem to be in a pending pull request.

    Just to make sure I got alerted, I've simulated the ZED configuration for my production environment in a VM.

    I simulated a drive failure with dd as stated earlier, but the result was that for every checksum error I received one email. With thousands of checksum errors, I had to clear 1000+ emails from my inbox.

    It seems that this option, which is uncommented by default, was not enabled.

    ZED_EMAIL_INTERVAL_SECS="3600"
    

    This option implements a cool-down period where an event is just reported once and suppressed afterwards until the interval expires.

    It would be best if this option would be enabled by default.

    The ZED authors acknowledge that ZED is a bit rough around the edges, but it sends out alerts consistently and that's what I was looking for, so I'm happy.

    Tagged as : ZFS event daemon

Page 3 / 38