Saturday, March 10, 2018

BSides Austin 2018

Had a really interesting time at the BSides Austin conference this year. It was well worth taking a couple of days out of the office to go and catch up with some old friends, and attend some sessions. For such a large event I was pleased to recognize a fair number of faces.

I particularly enjoyed the GDPR session led by David Ochel. My take is that most Americans in data security and privacy have so far dismissed the GDPR as primarily applying in Europe. While that may be true, its effects are going to be felt far wider than that. I felt some attendees were wondering why this European privacy directive was being discussed at a seminar being run in Texas. Hopefully this at least gave them some food for thought.

If you're involved in an international business, it's likely you'll be dealing with GDPR at some point real soon now. And if you're not operating internationally, consider this: the GDPR is effectively now the gold standard for data privacy protection. Other jurisdictions are going to get drawn upwards towards it. You may find that planning to move towards meeting its requirements in the future prepares you to deal with other requirements that spring up locally along the way.

Friday, February 16, 2018

VirtualBox Laptop - DNS and Time Sync

I boot Windows 10 natively on my laptop, and use VirtualBox to run a Linux VM for when I need those tools. I would seriously consider using Hyper-V for my laptop virtualization needs if it provided accelerated graphics for Linux, but it doesn't, so I don't.

Because it's a laptop, I find that I suspend and resume quite a bit, and often when I do so I'm connecting to a new network at the same time. Even with Guest Additions installed, this can confuse the guest Linux so networking is broken (wrong DNS servers in use) and the time is way off (it didn't notice the sleep/resume). To fix these things, there are a couple of settings that I configure on every VM that I'm working with.

Both settings are configured using the vboxmanage command.

To resolve the DNS issue, I configure VirtualBox to forward DNS requests to the host OS, which then looks them up. By doing so, only the host needs to care about its network configuration changing. This is done by running:

VBoxManage.exe modifyvm "VM name" --natdnshostresolver1 on

To make sure the clock gets reset after a lengthy sleep, use the following:

VBoxManage.exe guestproperty set "VM name" "/VirtualBox/GuestAdd/VBoxService/--timesync-set-threshold" 10

This ensures that if the VM falls behind by 10 seconds or more, the Guest Additions will jump the clock forward to the current time.

Naturally, you need to stop and start the VM to pick up these changes.

Monday, February 12, 2018

Proxy ARP for Linux WiFi Bridging

I've had to remind myself how to do this 3 times in the last 3 years. Posting as a reminder to self.

Sometimes old solutions work well for modern problems. Attaching a WiFi client interface to a software bridge doesn't work too well, as by default the upstream WAP will only accept frames having a source MAC of a device that's associated. One solution for a relatively static environment is to use proxy ARP.

In this configuration example, wlan0 is the interface with the 'real' network and eth0 is the small stub network.

Enable proxy ARP and IP forwarding with the following sysctl settings:

# Don't forget to load with 'sysctl -p'
# after adding to /etc/sysctl.conf

# Enable IPv4 forwarding
net.ipv4.ip_forward = 1

# Enable proxy arp
net.ipv4.conf.all.proxy_arp = 1

Assign an IP address to the external interface and leave eth0 unnumbered. For this purpose the external interface IP could be configured with DHCP rather than static. This example is for Debian / Ubuntu, updating /etc/network/interfaces:

auto wlan0 eth0

# Main network interface
iface wlan0 inet static
    address 192.168.128.100
    netmask 255.255.255.0
    gateway 192.168.128.1
    wpa-ssid "Test WLAN"
    wpa-psk "super s33cret"

# Stub network interface
iface eth0 inet manual
    # no IP configuration here
    # add host routes as post-up scripts via this interface
    post-up ip route add 192.168.128.200/32 dev eth0

Note that the resulting 192.168.128.0/24 network is split into two broadcast domains - this configuration doesn't result in a flat layer 2 broadcast domain. As such, anything depending on L2 broadcast like DHCP won't work through this, so anything on the stub network will need static IP configuration. It may be possible to get multicast to work, but I doubt link-local multicast addresses will ever work in this configuration since they don't cross the L3 boundary by design.

You can automate this installing parprouted to manage the routes, and dhcp-helper as an application proxy to forward DHCP requests between the partitioned networks. I've had good luck with this configuration, using my Raspberry Pi to provide wireless connectivity for my wired-only TV.