Shitty globals 2023

 Eleven years ago I published Shitty Globals.  Funny how time flies.

This was about the network discovery tool aptly named "netdiscover", which was delivered broken in BackTrack 5.  I have been using it ever since.  I keep the code around to put it on new boxes.  I have two new Jammy Jellyfish systems I got last week and that old code finally broke.  I can no longer compile it.  I have no clue what the issue is and I spent too much time on trying to fix it.

It had to be re-compiled often because the OUI database of MAC addresses goes out of date all the time.  The database is stored in the oui.h source file.  The stock package from Ubuntu has no way to update the MAC database.  You need the code.  I found the version 0.10 code at Launchpad.  Praise Bob.

Here we are 23 years into in the 21st century and this thing still doesn't support CIDR.  And you still have to re-compile it to update the OUI database.  There were ~2600 more OUIs than when the code was published (shitty globals and all).  And I still have 4 "Unknown Vendor" MACs on my network.  I'm not complaining.  Just sayin'.

Blocking QUIC

 I trashed iptables and switched over to netfilter ("Fearless Fosdick") a while ago.  The motivation was IPv6.  I wanted to write rules that would apply to both protocol stacks at the same time instead of having separate rules for IPv4 and IPv6.

Well, at the time that didn't work out at all.

Time passed.  I figured out how to use Spectrum's native IPv6 stack, getting rid of my old Hurricane Electric 6in4 tunnel.  I upgraded netfilter to Lester Gooch #3 and tried it again.  I had much better luck.  Then, Spectrum decided to start bouncing their network, which is a BAD thing to have happening when you're working on firewall rules.  Outages two days in a row, guaranteed to secure your system.

If you have been living under a rock since the dialup day sand you don't know what QUIC is, it is essentially http and tls (https) running on UDP ports 80 and 443, respectively.  A right and proper reinvention of the wheel of TCP.  Google says you want it.  That is a lie.  They want it and you're going to take it and like it.  Browser companies fell into line and now they all support it.  There is no on/off switch.  If you find one let me know.

Your only defense is your control over your network stack.

I recently learned Microtek products don't support UDP.  I know that the default mode of RHE is to open a port on both stacks.  I was once informed by a "Secure Gateway" vendor (I think it was Bluecoat) that nobody does UDP.

Essentially, it really doesn't matter much because it's so incredibly easy to punch a udp hole in almost any firewall.  You've been hanging your ass out on the Internet all this time and you didn't even know it.  For details, look into the STUN protocol.  

You may have exacerbated this condition with IPTables by putting an "ESTABLISHED, RELATED" stanza somewhere in your ruleset (every IPtables guru/wizard/tard puts it in their online example scripts--EVERY DAMN ONE!  You would think it's a good idea but it's not).

As luck would have it, Google has a huge STUN infrastructure (surprise!) that's ready and waiting to turn your firewall into Swiss cheese.  What an incredible coincidence.  If you're running a Tor Snowflake proxy, you're using this service.  The QUIC tunnels your browser makes are persistent and ready to swallow as many ads as Google can cram into them.

Normally I do all my port blocking with DROP, which worked for the most part.  For some reason my Galaxy A9 tablet was managing to jump around those rules.  I can't explain that but I switched to REJECT first, DROP second in the forward chain and that cleaned up all the sneaky traffic.  In fact, very little traffic hits the DROP rules anymore.

Back when all the rules were DROP, the A9 droid tablet would switch to tls over udp port 80, which I thought was rather sneaky and unladylike.  Whenever I switch ports like that the ITSec noobs screech "SECURITY BY OBSCURITY!" at me.

You may have heard of DoT and DoH (DNS over http and tls respectively).  I'm not sure if anyone uses DoQ (DNS over QUIC), but if they do these rules will block that as well.  That would sort of violate the intent of running DNS over tcp in the first place but I'm sure some clown somewhere will try it.  They always do.

I believe telling you this violates Google's Terms of Service so if I disappear (again) you'll know why.