docker-ce + Debian Buster + iptables

docker doesn’t work on Debian Buster by default, thanks to nft …

I found docker wouldn’t start for me on my Buster desktop.
journalctl -u docker -f showed :

Aug 15 09:35:50 walnut dockerd[28612]: failed to start daemon: Error initializing network controller: error obtaining controller instance: failed to create NAT chain DOCKER: iptables failed: iptables -t nat -N DOCKER: iptables v1.8.2 (nf_tables):  CHAIN_ADD failed (No such file or 

Aug 15 09:35:50 walnut dockerd[28612]:  (exit status 4)

Fixing, yet again, seems a case of replacing nft/nftables stuff with the legacy iptables counterparts –

update-alternatives --set ip6tables /usr/sbin/ip6tables-legacy
update-alternatives --set iptables /usr/sbin/iptables-legacy

fail2ban, Debian buster/10 and iptables vs nftables

Buster forces a move to nftables, unfortunately fail2ban thinks it’s still using iptables, so nothing gets blocked. To fix ….

Buster forces a move to nftables, unfortunately fail2ban thinks it’s still using iptables, so nothing gets blocked. To fix ….

(fail2ban in Buster also seems to require systemd – and no longer reads from e.g. /var/log/mail.log, which is a bit disappointing but oh well…)

After messing about trying to get nftables working – where trying to use the default /etc/nftables.conf file just results in an error a bit like :

/etc/nftables.conf:6:15-19: Error: Could not process rule: No such file or directory

        chain input {

I gave up, and found the Debian Wiki Page which gives :

update-alternatives --set iptables /usr/sbin/iptables-legacy
update-alternatives --set ip6tables /usr/sbin/ip6tables-legacy
update-alternatives --set arptables /usr/sbin/arptables-legacy
update-alternatives --set ebtables /usr/sbin/ebtables-legacy

Which now allows fail2ban to actualy block things (via /var/log/fail2ban.log etc).

Google Titan Security Key on Linux

Fixing udev so a Titan security key works on Linux …

When trying to use these new fangled things on Debian (Stretch) I needed to edit/create /etc/udev/rules.d/titan.rules and put in it something like the following – else nothing happens when you try using them …

KERNEL=="hidraw", SUBSYSTEM=="hidraw", ATTRS{idVendor}=="096e", ATTRS{idProduct}=="0858", TAG+="uaccess"
KERNEL=="hidraw", SUBSYSTEM=="hidraw", ATTRS{idVendor}=="096e", ATTRS{idProduct}=="085b", TAG+="uaccess"

This is based on e.g. the ‘dmesg’ output looking something like :

[  194.111391] usb 1-3.3.2: new full-speed USB device number 11 using xhci_hcd
 [  194.320740] usb 1-3.3.2: New USB device found, idVendor=096e, idProduct=0858, bcdDevice=46.00
 [  194.320753] usb 1-3.3.2: New USB device strings: Mfr=1, Product=2, SerialNumber=0
 [  194.320757] usb 1-3.3.2: Product: U2F
 [  194.320760] usb 1-3.3.2: Manufacturer: FT
 [  194.328476] hid-generic 0003:096E:0858.0005: hiddev1,hidraw2: USB HID v1.00 Device [FT U2F] on usb-0000:00:14.0-3.3.2/input0

(The wireless device has a different idProduct from the USB only one, hence the two rules).