Posts

AuthenTrend ATKey.Pro: a forensic look at the CTAP 2.0 variant on Arch Linux

Image
hardware review CTAP2.0 SKU: do check the note below April 2026  ·  Arch Linux 6.18.21-1-lts  ·  libfido2 1.16.0  ·  systemd-cryptenroll  ·  Security & authentication The ATKey.Pro from AuthenTrend is a FIDO2 hardware security key with an onboard capacitive fingerprint sensor. This review tests the device thoroughly on Linux and is quite explicit about what was verified by direct command output, what was confirmed by manufacturer documentation, and what remains genuinely unknown. Important: two distinct SKUs share the ATKey.Pro name The device tested here reports AAGUID e1a96183-5016-4f24-b55b-e3ae23614cc6 , which the FIDO passkey developer registry identifies as ATKey.Pro CTAP2.0 . A separate, newer product (AAGUID e416201b-afeb-41ca-a03d-2281c28322aa ) is the ATKey.Pro CTAP2.1 , which AuthenTrend now sells and markets as "CTAP2.1 compliant." These are distinct devices with distinct firmware beh...

pam_authnft: what 'session' means to a Linux firewall

Image
  On Linux, the hard part of building a per-session firewall is not the firewall. It's deciding what "session" means in a way the kernel can match against later, without trusting anything in userspace to have told the truth. pam_authnft is the smallest concrete experiment I could build to poke at that question. It's a PAM session module that binds nftables rules to an authenticated session using the session's cgroupv2 inode as the identity. SSH in, your firewall rules appear; log out, they're gone. No setuid helper, no dedicated shell, no kernel patches. The framing I keep coming back to has four verbs. To give a session, a workload, or any other unit of activity a kernel-visible identity, you have to create it somewhere store it in something durable transport it through whatever subsystem boundaries the packets cross and verify it where the policy decision lives Most of the interesting failure modes come from one of those four steps be...

IPv6 multihoming on MikroTik RouterOS: active/standby failover between two ISPs

Image
TL;DR: I wanted IPv6 failover between two ISPs on a MikroTik RB5009. Announcing two prefixes via SLAAC technically works, but failover is slow because Router Advertisement lifetimes don't expire on demand, and LAN clients can't see upstream routing decisions anyway. As an interim workaround, a PPPoE down script that bounces the DHCPv6-PD client forces RouterOS to deprecate the dead prefix immediately, which gets failover down to about a second. The cleaner approaches are conditional Router Advertisements (RFC 8475) or Source Address Dependent Routing with RFC 8028–aware hosts (RFC 8678). Neither is a native turnkey feature on consumer/SMB gear, but both are reachable on RouterOS through scripting and policy routing, with caveats. The setup I recently bought a MikroTik RB5009UPr to replace my primary FTTH ISP's router and optics. It also replaced a PoE switch, letting me reclaim some desk space. It really is a sweet bit of kit. I then had a second fiber line from an...

Aggressive yet sane persistent SSH with systemd and autossh

Image
Not too long ago, I was contracted to assist with a K8 deployment. The developers' approach to persistent SSH tunnels left something to be desired. Autossh is a great tool for persistent SSH connections; I use it mostly for reverse port and Unix socket forwarding. No punching holes in firewalls, no exposing services to the Internet. I love it. Folksy guides like these suggest restarting autossh immediately on failure, ignoring TCP's connection teardown state entirely. That gap is exactly what this post addresses. Systemd is a better wrapper: autossh handles the connection lifecycle, systemd handles startup ordering, restart timing, and environment variables. They compose well. One caveat worth stating upfront: SSH tunnels carry TCP inside TCP, which is fine for low-volume use (a socket forward, a management port, a small database connection) but will hit congestion collapse under high load and packet loss. It is why production VPNs use UDP . For the low-volum...

Anycasting IPv6 TCP and UDP

Image
Anycasting IPv6 TCP and UDP Inspired by LinkedIn's own Samir Jaferali's post on Building your own anycast network in 9 steps . Register for an ASN via an LIR, I used  ip6.im and Fairnode , who gave me a free /39 IPv6 prefix of the type ( ASSIGNED, ALLOCATED-BY-LIR ) . PI is "ASSIGNED PI" or "ASSIGNED ANYCAST" (special). PA is ALLOCATED-BY-RIR, ALLOCATED-BY-LIR, AGGREGATED-BY-LIR and ASSIGNED. Things I wish I knew : You  cannot  announce any of your network prefixes outside of RIPE regions, these are for use in RIPE regions only. The exception to this is anycast traffic. ASN and IP prefixes that fall under RIPE can be announced and anycasted in the world as long as one PoP has a RIPE region presence. This can be as easy as a virtual machine in Europe whose location can be occasionally confirmed via traceroute. Dear APNIC, why can't you be as easy to work with? RIPE registration and role types to create: inet6num mntner organisation...

LEDE/OpenWRT on a PC Engines APU2(c4)

Image
The PC Engines APU2 is a fanless 1 Ghz quad-core AMD GX-412TC x64 Jaguar SoC 4 GB DDR3-1333 ECC DRAM 3 Intel i210AT ethernet ports mSATA slot 2 mini-pcie slots, one attached to a SIM card holder for GSM modems All in all, a pretty decent bit of kit to manage even 1 G Internet, assuming all of it isn't VPN. Mine's currently managing two 50/50 Mbit PPPoE and a VDSL 24/2 Mbit line. I bought it to keep up with the symmetric 50 mbit line I upgraded to and have resources left over for IPsec VPNs, IPv6 tunnels, cjdns tunnels, DN42 BGP VPNs and BIRD6 for my own IPv6 PI space. Standard LEDE install The LEDE devs decided not to have separate targets for the APUx series of boards and went with standard x86 target support. Patches for APU2 board support are in mainline LEDE now so they can be installed via opkg . This is great as you need just dd LEDE version >= 17.01 .1 with luci on to the SSD/HDD/SD/USB, run opkg update and then install these...

IPsec and IKEv2 Android VPN

Image
Isn't SSH everyone's favorite quick and dirty VPN? Get Putty, setup browser to use the SSH connection as a proxy and you're good to go. Not long after DARPA released ESP, IPsec emerged as the de facto standard for creating encrypted tunnels to move data over the Internet between two geographically separate networks. It works at Layer 3, it's application agnostic and built right in to TCP with tighter integration in IPv6. It's adoption outside of corporate endpoints remains less than stellar, and for good reason. A typical conversation between a young developer Alice, wanting to secure her fledgling application's communication with her Network Engineer mate Bob, who works at a multi-homed Tier 4 datacenter in VRF hell. Alice : Hey mate, I'm deploying my application via Docker and would like to use a VPN to communicate between my Docker hosts. My M2M devices use 6LoWPAN and IPsec seems perfect. Bob :  Uhh, 6LoWPAN? Not my area of expertise but ...