networking

Frames, ships. All carry payloads

About an hour ago I found this article explaining how shippers went for even bigger ships than before, thinking economies of scale would help them make more money.

Then I read this other article about how the Port of Los Angeles is buckling under pressure by having multiple container ships at berth. The Port of New York City also reports taking on bigger ships.

I’m thinking in networking terms but

  • Bigger container ships == Ethernet Jumbo frames
  • Global shipping routes == Internet
  • Ports == Network gateways

The challenges with jumbo frames are well known. Some people hate them, others say use them with care. It all comes down to what you’re trying to do and what your equipment supports.

If you have a route across the Internet and every node between the starting point and the end point support jumbo frames, you’re set. If not, you can keep them disabled and still reap 90% of the benefits.

This is not so with actual physical matter being transported via ships. Ports can’t be replaced in a few weeks or months. Expansion of a port often takes years (NYC, LA, Duluth) and costs can run into hundreds of millions of dollars. You can’t exacly load balance across ports while you upgrade one the way you can with a network gateway. In this context, extra-jumbo container ships give rise to bursts of frantic activity at ports to get them unloaded, when the entire system relies on port activity being steady.

Add in the COVID-19 pandemic and burst activity will facilitate virus spread throughout port workers. None of this is a good combination. Wonder if there are any studies that apply IP networking concepts to the study of seafaring shipping?

Also, governments seriously need to look at how the shipping cartels operate. Cos that’s what they are, cartels.

Block attacker IP addresses, four ways

If you run WordPress you’ve seen these in your web server logs:

132.232.46.230 - - [29/Oct/2020:13:58:41 -0500] "POST /xmlrpc.php HTTP/1.1" 200 259 "-" "Apache-HttpClient/4.5.2 (Java/1.8.0_151)" "-"
132.232.46.230 - - [29/Oct/2020:13:58:44 -0500] "POST /xmlrpc.php HTTP/1.1" 200 259 "-" "Apache-HttpClient/4.5.2 (Java/1.8.0_151)" "-"
132.232.46.230 - - [29/Oct/2020:13:58:48 -0500] "POST /xmlrpc.php HTTP/1.1" 200 259 "-" "Apache-HttpClient/4.5.2 (Java/1.8.0_151)" "-"
132.232.46.230 - - [29/Oct/2020:13:58:52 -0500] "POST /xmlrpc.php HTTP/1.1" 200 259 "-" "Apache-HttpClient/4.5.2 (Java/1.8.0_151)" "-"
132.232.46.230 - - [29/Oct/2020:13:58:55 -0500] "POST /xmlrpc.php HTTP/1.1" 200 259 "-" "Apache-HttpClient/4.5.2 (Java/1.8.0_151)" "-"
132.232.46.230 - - [29/Oct/2020:13:58:58 -0500] "POST /xmlrpc.php HTTP/1.1" 200 259 "-" "Apache-HttpClient/4.5.2 (Java/1.8.0_151)" "-"

Fucken scanners just slamming xmlrpc.php looking for a way in. When this happens CPU usage just goes through the roof for as long as the scan lasts and it could be five minutes, could be six hours, could be all week; before it ends. The gods help you if you’re paying by CPU usage.

So you have to block access to the file. You could just block all access to XML-RPC but doing this will prevent the WP mobile app from working.

We’ll just block that specific IP address but we need to be quick about it; just do a quick one liner on the terminal before the OS just topples over and becomes completely unresponsive or worse.

iptables

This should work for any Linux distribution that has iptables out of the box which is basically all of them.

# iptables -I INPUT -s 132.232.46.230 -j DROP
  • -I: Insert the rule as the first rule to be applied in the INPUT chain. You could use -A (append) but the sooner we get rid of that traffic the less work the CPU has to do.
  • -s: Source address, in this case 132.232.46.230, which belongs to Tencent.
  • -j: jump to the DROP target. If you use the REJECT target you’re just creating more work for the CPU.

Documentation here but the Ubuntu how-to is far more useful in getting people started.

pf

As it is part of both FreeBSD and OpenBSD base installations it should be enabled in /etc/rc.conf but from reading the (almost useless) documentation and looking around the web You need to fuck around with pf.conf first, then you can manipulate the table. This is the first result on the web when you search for “pf block ip address”. So no one-liner that can save your life.

Edit /etc/pf.conf and add

table <badhosts> persist
block on fxp0 from <badhosts> to any
  • Create table named badhosts, and set it to be persistent in kernel memory
  • Block, on interface fxp0 (you’ll want to change this), traffic from rules in the badhosts table to any destination.

Once you have this you can manipulate the table from the command line with pfctl

# pfctl -t badhosts -T add 132.232.46.230
  • -t means pfctl will manipulate the badhosts table
  • -T will show statistics
  • add address 132.232.46.230 to the table

Fucken hell FreeBSD documentation is the fucken worst. Dryer than Melania Trump’s libido. Now, reading through the OpenBSD pf documentation it looks like you can do

# pfctl -t badhosts -T add 203.0.113.0/24

Which will create the badhosts table automatically without having to fuck around with /etc/pf.conf. Don’t know if this will work on FreeBSD though.

ipfw

It is part of the FreeBSD base installation so it does depend on ipfw being enabled in /etc/rc.conf but it looks like you can go

# ipfw add deny all from 132.232.46.230 to any
  • Add rule denying any and all fraffic from 132.232.46.230 to any destination

At least these rules are succint and easy to read. Whomever wrote the documentation seemed to pay more attention to usage at least.

Still, fuck FreeBSD.

Windows

Super easy now that PowerShell is built into Windows itself:

PS C:\WINDOWS\system32> New-NetFirewallRule -DisplayName "Block traffic from 132.232.46.230" -Direction Inbound -LocalPort Any -Protocol Any - Action Block -RemoteAddress 132.232.46.230
  • -DisplayName: The human-readable name of the firewall rule
  • -Direction: Can be Outbound or Inbound. We want Inbound obviously.
  • -LocalPort: Going with any ports because fuck crackers.
  • -Protocol: Same, block all port
  • -Action: Block traffic
  • -RemoteAddress: Specifying only 132.232.46.230

The documentation for the commandlet is super nice. No, I’m not typing ‘cmdlet’.

The old way involved so, so manny clicks. PowerShell makes it easy.


Now all of the previous bits of code cease to have any effect after a system reboot so if you want the rules to be permanent… don’t. Blackhats will just scan from different hosts and different networks so blocking an IP address permanently is just unproductive.

A better solution is to use fail2ban:

There is also CrowdSec but I haven’t personally used them.

This post came to be cos I spent 30+ minutes trying to figure out how to block traffic on a FreeBSD host and their documentation is just… inscrutable. Should you ask for help in their forums you’ll just get told to RTFM.

You end up going in circles, consuming yourself in rage and frustration which does not feel nice. Rage-posting is where it’sat.

Dell Wireless 1703 on Windows Server 2019

Recently at work I had to install this OS (with the Desktop Experience feature set) on a Dell XPS 8700. Windows was able to recognize everything properly and all components but the network adapter would show up in Device Manager. Tried the usual things to fix this:

  • Installing the driver from Dell; it would install but Windows would fail to make use of it.
  • Updating the driver using “Search automatically for updated driver software”. This would fail with Windows complaining about an issue with the INF.
  • Manually pick a driver from the filesystem. It would also fail with an error about the INF.

Looked at the INF file but there wasn’t anything in it that would make Windows Server just up and refuse to install the thing, and given there isn’t that much difference between Windows 10 and Windows Server the issue had to lie elsewhere.

There is one thing that Windows 10 does, however, and that’s automatically start WLAN services, since usually you’d see Windows Server be installed on enterprise hardware or have it connected to the network via Ethernet. Turns out Windows Server does not even install this feature on its own.

To install it:

  1. Click Start button.
  2. Type “Turn features on or off”.
  3. Click Next 4 times (Before you Begin, Installation Type, Server Selection (which defaults to the local server), and Features.
  4. On the Features selection list, scroll down to Wireless LAN Service and select it.
  5. Click Install and wait for the OS to do its thing.
  6. Reboot system. This is required for it all to work.

After the system comes back up the network adapter should be installed and enabled in Device Manager.

Ah, right… in addition to this it turns out the “Dell Update Application” totally does not work under this OS so you have to manually download and install all device drivers; this took me a couple of hours, so mind your clock.

You did good!

After two years…. it was time to retire my trusty Thinkpad T60 that I turned into a WiFi AP for my LAN. Its name is blackslab and it’s been with me for about 8 years now. She’s earned a nice long break.

Thinkpad T60

I had been running into a ton of issues lately:

  • There are way too many wireless networks around me. A quick look at the network selector on Windows has 11 networks in there. This was interfering with my gaming.
  • Debian is a fucking bitch to deal with these days. Systemd is polluting everything in it.
  • Network instability is a thing. After every reboot I had to manually bring the WAN interface up. It’s a thing and I just didn’t want to deal with it anymore.

So now I’m setting up FreeBSD on a small form factor PC to take its place. It’s not the cheapest when it comes to energy use but it should do the trick. In the interim I’ve got a cheap ASUS router running things since Windows ICS is so fucking unreliable; tried setting up FreeBSD through it and it was a slog.

Hopefully I’ll be able to stop banging my head against PF sometime in the next 12 hours so I can actually set the thing up as the main LAN controller.