Linux

Webex 46.8.0.35631 op Fedora 44 zit achter een gele banner met “Offline - No internet connection” terwijl elk ander programma op de machine zonder klagen het internet bereikt. Het legde de VoIP-lijn plat. Het netwerk was nooit het probleem: Cisco levert een eigen fork van OpenSSL mee en bouwde die met OPENSSLDIR op /workspace/.conan2/p/b/cisco8ee8b59cf93de/p/ssl, een map die op een buildcontainer bestaat en nergens anders, dus laadt hij geen vertrouwensankers en faalt elke handshake. Het stuk loopt op volgorde: wat de kapotte toestand echt is, de meegeleverde bibliotheek vragen waar zij denkt dat haar certificaten staan, de exacte foutcode buiten Webex reproduceren, waarom niets waarschuwt, de twee oplossingen die niet werken en waarom, en de ene die wel werkt. Dan het buildproces: ze gebruikten $ORIGIN voor de code en lieten drie datapaden absoluut, de RPM-header noemt een container-ID, dus de container zat al in de pijplijn en is nooit gebruikt om het resultaat te draaien, het pakket eist een glibc uit 2018 omdat ze niet statisch willen linken, 2,2 GB wordt twee keer uitgeleverd, en er zit geen documentatie bij en geen bestand dat als configuratie is gemarkeerd. Dan hoe het gebouwd had moeten worden, de zes oplossingen en de controle van één regel die dit vangt. En tot slot de kruiscontrole: Cisco heeft 98 vermeldingen in CISA’s catalogus van actief misbruikte kwetsbaarheden, alleen Microsoft staat hoger, en een vertrouwenspad dat niemand controleerde en een omzeiling die niemand controleerde zijn dezelfde fout met andere inzet.

Een VPN is twee taken: iets dat een virtuele link maakt, en iets dat de bytes draagt. PPP doet de eerste sinds 1994 en het kan het niet schelen wat de tweede is — daarom zijn PPTP, L2TP en elke inbellijn die je ooit gebruikt hebt hetzelfde protocol over verschillende dragers. Netcat is een drager. Dit bouwt het op beide manieren. Eerst pppd: de pty-optie en wat die met een pseudo-terminal doet, de TCP-versie die iedereen eerst probeert, waarom een streamprotocol binnen TCP onder verlies smelt, de UDP-versie die je moet nemen, de asynchrone HDLC-framing en de ACCM die bepaalt hoeveel bandbreedte er opgaat aan het escapen van stuurtekens, adressering en routering en IPV6CP, en de link overeind houden als de drager sterft zonder het te zeggen. Daarna dezelfde tunnel helemaal zonder PPP — een tap-device, één datagram per frame over UDP, het lengteprefix dat je over TCP zelf moet verzinnen, tun tegen tap, en bridging. Daarna het deel waar netcat geen antwoord op heeft: de drager in TLS wikkelen met ncat, stunnel en openssl, en in DTLS met socat, wat de vorm is die je eigenlijk wilt. Het is nooit echt het juiste gereedschap, en dat is nu juist het punt: het laat zien hoe egress zich gedraagt zodra een aanvaller root heeft binnen je netwerk en uitgaande toegang niet standaard geblokkeerd was, en waarom default-deny aan de rand de enige controle is die ooit echt was.

Ping, niet de rest van ICMP, is het risico: echo is een kanaal dat elke host met je eigen bytes moet beantwoorden, dus een netwerk dat ‘alleen ping toestaat’ heeft al een volledige VPN naar buiten. Dit loopt eerst de dreiging af — wat het je uitgaande verkeer kost, en hoe een bezoeker op je wifi of een niet-vergrendelde ethernetpoort er een kan openen — dan drie werkende tunnels op ping alleen (Hans, icmptunnel, en een korte in Python met AES-128), de haken van MTU en IPv6, en de regel die het sluit: gooi echo weg, houd de fouten, in nftables, pf, Cisco, Junos, MikroTik en Windows.

“Poort 445 wordt ergens geblokkeerd” is geen diagnose, en het is waarom firewalltickets een week tussen jou en je provider heen en weer stuiteren. Elke router op het pad is je een ICMP Time Exceeded verschuldigd als je hopbudget opraakt, en dat maakt van een time-out een afstand. Ik liep de TTL omhoog op mijn eigen lijn en vond drie storingen waarvan ik niet wist dat ik ze had: een SMB-drop elf hops ver, vervalste SMTP-resets één hop weg, en een IPv4-regel zonder IPv6-tweeling.