BSD Breathes New Life Into Obsolete Equipment

An old laptop or desktop computer that’s seen better days might still have a little bit of use left in it for a dedicated task. Grabbing a lightweight flavor of Linux and running a web server, firewall, or Super Nintendo emulator might get a few more years out of it. You can also get pretty creative repurposing obsolete single purpose  machines, as [Kristjan] did with some old Cisco server equipment.

The computer in question isn’t something commonly found, either. It’s an intrusion detection system meant to mount in a server rack and protect the server itself from malicious activity. While [Kristjan] mentions that Cisco equipment seems to be the definition of planned obsolescence, we think that this Intel Celeron machine with an IDE hard drive may have gone around the bend quite some time ago. Regardless, it’s modern enough to put back to work in some other capacity.

To that end, a general purpose operating system was installed, and rather than use Linux he reached for BSD to get the system up and running. There’s one other catch, though, besides some cooling issues. Since the machine was meant to be used in a server, there’s no ACPI which means no software shutdown capability. Despite all the quirks, you can still use it to re-implement a network security system if you wanted to bring it full-circle.

Memcached Servers Abused For DDoS Attacks

Cloudflare announced recently that they are seeing an increase in amplification attacks using memcached servers, and that this exploit has the potential to be a big problem because memcached is capable of amplifying an attack significantly. This takes DDoS attacks to a new level, but the good news is that the problem is confined to a few thousand misconfigured servers, and the solution is to put the servers behind a tighter firewall and to disable UDP. What’s interesting is how the fundamental workings of the Internet are exploited to create and direct a massive amount of traffic.

We start with a botnet. This is when a bunch of Internet-connected devices are compromised and controlled by a malicious user. This could be a set of specific brand of web camera or printer or computer with unsecured firmware. Once the device is compromised, the malicious user can control the botnet and have it execute code. This code could mine cryptocurrency, upload sensitive data, or create a lot of web traffic directed at a particular server, flooding it with requests and creating a distributed denial of service (DDoS) attack that takes down the server. Since the server can’t distinguish regular traffic from malicious traffic, it can’t filter it out and becomes unresponsive.

This DDoS attack is limited to the size of the botnet’s bandwidth, though. If all the web cameras in the botnet are pounding a server as fast as they can, the botnet has reached its max. The next trick is called an amplification attack, and it exploits UDP. UDP (as opposed to TCP) is like the early post office; you send mail and hope it gets there, and if it doesn’t then oh well. There’s no handshaking between communicating computers. When a device sends a UDP packet to a server, it includes the return address so that the server can send the response back. If the device sends a carefully crafted fake request with a different return address, then the server will send the response to that spoofed return address.

So if the web camera sends a request to Server A and the response is sent to Server B, then Server A is unintentionally attacking Server B. If the request is the same size as the response, then there’s no benefit to this attack. If the request is smaller than the response, and Server A sends Server B a bunch of unrequested data for every request from the camera, then you have a successful amplification attack. In the case of memcached, traffic can be amplified by more than 50,000 times, meaning that a small botnet can have a huge effect.

Memcached is a memory caching system whose primary use is to help large websites by caching data that would otherwise be stored in a database or API, so it really shouldn’t be publicly accessible anyway.  And the solution is to turn off public-facing memcached over UDP, but the larger solution is to think about what things you are making available to the Internet, and how they can be used maliciously.

Router Rebooter Eliminates Hassles

Some low-end or older routers might get you a decent WiFi network in your house or apartment, but often these cheaply made devices are plagued with subtle software problems that cause the router itself to become unresponsive after a few days of operating. One solution is to just power cycle the router by hand whenever the Internet disappears, but a better solution is to build something that does that for you.

[Charlie] had this problem as the de facto IT person in his family, and didn’t want to keep getting bothered for such a simple problem. His solution involves a relay, an ESP8266, and a Wemos D1 mini. The device connects to the Internet through the router and occasionally sends out pings to another address. If it can’t ping the address successfully after a certain time period, the device power cycles the router by activating the relay.

Since this isn’t the newest idea out there, there are many ways to solve this problem if you are constantly annoyed by router issues, whether from your own router or from friends and family who treat you as their personal IT department. One solution doesn’t involve any extra hardware at all as long as you have a computer near your router/modem already, and others solve this problem when it happens to the modem rather than the router.

Continue reading “Router Rebooter Eliminates Hassles”

34C3: Roll Your Own Network Driver In Four Simple Steps

Writing your own drivers is a special discipline. Drivers on the one hand work closely with external hardware and at the same time are deeply ingrained into the operating system. That’s two kinds of specialization in one problem. In recent years a lot of dedicated networking hardware is being replaced by software. [Paul Emmerich] is a researcher who works on improving the performance of these systems.

Making software act like network hardware requires drivers that can swiftly handle a lot of small packets, something that the standard APIs where not designed for. In his talk at this year’s Chaos Commnication Congress [Paul] dissects the different approaches to writing this special flavor of drivers and explains the shortcomings of each.

Continue reading “34C3: Roll Your Own Network Driver In Four Simple Steps”

Radio Apocalypse: The GWEN System

Recent developments on the world political stage have brought the destructive potential of electromagnetic pulses (EMP) to the fore, and people seem to have internalized the threat posed by a single thermonuclear weapon. It’s common knowledge that one bomb deployed at a high enough altitude can cause a rapid and powerful pulse of electrical and magnetic fields capable of destroying everything electrical on the ground below, sending civilization back to the 1800s in the blink of an eye.

Things are rarely as simple as the media portray, of course, and this is especially true when a phenomenon with complex physics is involved. But even in the early days of the Atomic Age, the destructive potential of EMP was understood, and allowances for it were made in designing strategic systems. Nowhere else was EMP more of a threat than to the complex web of communication systems linking far-flung strategic assets with central command and control apparatus. In the United States, one of the many hardened communications networks was dubbed the Groundwave Emergency Network, or GWEN, and the story of its fairly rapid rise and fall is an interesting case study in how nations mount technical responses to threats, both real and perceived. Continue reading “Radio Apocalypse: The GWEN System”

Hacker Heroism: Building Your Way Out Of AV Hell

Many years ago, in a rainy concrete jungle on the west coast of Australia, I worked for a medium-sized enterprise doing a variety of office-based tasks. Somehow, I found myself caught up in planning a product launch event outside the official remit of my position. We got through it, but not before the audiovisual (AV) setup of the event turned into one giant hack.

The initial planning stages went remarkably smoothly until less than a month out from the big day when three weeks of frantic changes and revisions to the presentation rained down. These were some of the hardest days of my working life to date, as it seemed that we would lock in a new arrangement, only to tear it up days later as some new vital criteria came to light, throwing everything back into disarray.

Things came to a head on the night before the event. Working with two different AV teams we had planned for four projection screens and five flat screen televisions spread throughout the venue and controlled from the central AV desk. But somewhere in all those changes the televisions were set up to all display a still image, or nothing at all. I needed to show different videos on each and have the ability to black them all out.

It was at this point I realized we were screwed. The production team simply didn’t have the hardware to drive another five screens, but they could source it — for the sum of $5000. Management were furious, and were under the impression, like myself that this was what we had asked and paid for already. I was at an impasse, and beginning to wonder if I’d have a job come Monday. I wandered off to a corner to curse, and more importantly, think. After all, I’m a hacker — I can get through this.

Continue reading “Hacker Heroism: Building Your Way Out Of AV Hell”

Horns Across America: The AT&T Long Lines Network

A bewildering amount of engineering was thrown at the various challenges presented to the United States by the end of World War II and the beginning of the Cold War. From the Interstate Highway System to the population shift from cities to suburbs, infrastructure of all types was being constructed at a rapid pace, fueled by reasonable assessments of extant and future threats seasoned with a dash of paranoia, and funded by bulging federal coffers due to post-war prosperity and booming populations. No project seemed too big, and each pushed the bleeding edge of technology at the time.

Some of these critical infrastructure projects have gone the way of the dodo, supplanted by newer technologies that rendered them obsolete. Relics of these projects still dot the American landscape today, and are easy to find if you know where to look. One that always fascinated me was the network of microwave radio relay stations that once stitched the country together. From mountaintop to mountaintop, they stand silent and largely unattended, but they once buzzed with the business of a nation. Here’s how they came to be, and how they eventually made themselves relics.

Continue reading “Horns Across America: The AT&T Long Lines Network”