Over the past year or so, I've been working with other BlueSCSI developers to add Wi-Fi functionality to their open-hardware SCSI device, enabling Wi-Fi support for old Macs and other vintage computers going back some 36 years.
On the modern web, everything must be encrypted. Unencrypted websites are treated as relics of the past with browsers declaring them toxic waste not to be touched (or even looked at) and search engines de-prioritizing their content.
While this push for security is good for protecting modern communication, there is a whole web full of information and services that don't need to be secured and those trying to access them from older vintage computers or even through modern embedded devices are increasingly being left behind.
Now that my Mac 512Ke is able to use PPP for native TCP/IP, I wanted an easy way to do PPP between it and an OpenBSD server on my network. I initially did this with a physical serial cable, but was later able to do it over TCP so I could retain the use of my WiFi232.
On July 4th, 2018, I reported a security/privacy problem to Apple regarding the firmware on its now-discontinued AirPort wireless access points.
Per Apple's website, a "factory-default reset" of an AirPort should "remove any saved configurations and profiles" and should be sufficient for "selling or giving away your base station".
On at least AirPort Extreme AP firmware 7.7.9 and AirPort Express firmware 7.6.9 (the newest available for each device at the time of reporting), a "factory-default" reset just moves the configuration file to a new location on the device, and the old file and up to two additional previous configurations remain accessible on the device.
I upgraded to AT&T's U-verse Gigabit internet service in 2017 and it came with an Arris BGW-210 as the WiFi AP and router. The BGW-210 is not a terrible device, but I already had my own Airport Extreme APs wired throughout my house and an OpenBSD router configured with various things, so I had no use for this device. It's also a potentially-insecure device that I can't upgrade or fully disable remote control over.
Fully removing the BGW-210 is not possible as we'll see later, but it is possible to remove it from the routing path. This is how I did it with OpenBSD.
Seven years ago, I hacked together some code to update my Ecobee WiFi thermostat temperature depending on whether I was home. While my newer Ecobee thermostat has room occupancy sensors that make this tracking automatic, back then I had to poll my WiFi access point through SNMP to look for my phone's MAC address in its table of associated clients.
Recently I needed to do something similar to pass to my Z-Wave controller but it seems that Apple has removed SNMP support from its Airport Extreme firmware some time ago.
Last night I tried to visit one of the websites that I host on one of my dedicated servers, and to my surprise, I saw this instead of the usual content:
My first reaction was that the gzip compression had possibly broken on my server, or that it was a weird compatibility issue with Firefox 6.0 to which I had just upgraded. I enabled Firefox's Web Console to see what was actually being received (highlighting mine):
At about 9am yesterday morning, I noticed on my server monitor that the CPU utilization of one of my servers was abnormally high, in addition to a sustained 1mbit/sec of inbound traffic and 2mbits/sec of outbound traffic. syslog messages from Asterisk showed it to be a SIP brute force attack, so I dropped the offending IP (an Amazon EC2 instance IP) into /etc/idiots to block it and went back to my work.
A while later, I noticed the traffic still hadn't died down, so I reported the incident to Amazon and my server's network provider. No luck on either front; Amazon just sent back a form reply stating the incident was forwarded to the EC2 instance's owner (yeah, seriously) and the network provider said they wouldn't bother adding an ACL to their border equipment unless it was needed to protect their entire network. With the IP blocked on my server, the CPU utilization had died down and it was no longer sending out reply traffic, but I was worried about the inbound garbage traffic counting towards the server's monthly bandwidth cap.
We're coming out with a managed firewall product at work that is basically an OpenBSD machine running pf that supports VPNs and all the usual malarkey.
An issue we run into a lot with our hosted PBX service is that some customers have networks with firewalls that cause problems with TFTP, SIP, latency, etc. It makes diagnosing problems harder and often the customers think the problems are with our phone system when they're really with their firewall. So if they get our firewall, we know everything will work and we'll have the ability to change things if something doesn't work.
I got a new Cisco T1 router with enough flash memory to run an IOS version that supports IPv6. I reconfigured my network a tad and now the Cisco does the freenet tunnel and passes traffic for the rest of the machines.
Apparently the neteng group at DLS is supposed to start working on IPv6 soon. Hopefully I can get native IPv6 routed here and rt.fm can support it as well.