We’ll go out on a limb and assume that anyone reading these words is probably familiar with the classic
ping command. Depending on which operating system you worship the options might be slightly different, but every variation of this simple tool does the same thing: send an ICMP echo request and wait for a response. How long it takes to get a response from the target, if it gets one at all, is shown to the user. This if often the very first step to diagnosing network connectivity issues; if this doesn’t work, there’s an excellent chance the line is dead.
But in the modern web-centric view of networking,
ping might not give us the whole picture. But nature it doesn’t take into account things like DNS lookups, and it certainly doesn’t help you determine what (if any) services the target has available to you. Accordingly, [Liu Zhiyong] has come up with a tool he calls “pingms”, which allows you to check web server latency right from your browser.
Rather than relying on ICMP, pingms performs a more realistic test. It takes the list of targets from the file “targets.js” and connects to each one over HTTP. How does it work? The code [Liu] has come up with will take each target domain name, append a random number to create a gibberish filename, and then calculate how long it takes to get a response when trying to download the file. Obviously it’s going to be getting a 404 response from the web server, but the important thing is simply that it gets the response.
With this data, [Liu] has come up with a simplistic but very slick interface which shows the user the collected data with easy to understand color-coded graphs. As interesting as it is to see how long it takes your favorite web sites or service providers to wake up and start talking, watching the colored bars hop up and down the list to sort themselves is easily our favorite part of pingms.
[Liu] has released pingms under the GPLv3 license, so if you’re looking to utilize the software for your own purposes you just need to provide a list of test targets. If you need to perform low-level diagnostics, check out this handy network tester you can build for cheap.
Probably the best example is to simply go to the site and click on “About itty bitty.” That page is itself encoded in its own URL. If you then click on the App link, you’ll see a calculator, showing that this isn’t just for snippets of text. While this does depend on the itty.bitty.site web host to provide the decoding framework, the decoding is done totally in your browser and the code is open source. What that means is you could host it on your own server, if you wanted to.
At first, this seems like a novelty until you start thinking about it. A small computer with an Internet connection could easily formulate these URLs to create web pages. A bigger computer could even host the itty.bitty server. Then there’s the privacy issue. At first, we were thinking that a page like this would be hard to censor since there is no centralized server with the content. But you still need the decoding framework. However, that wouldn’t stop a sophisticated user from “redirecting” to another — maybe private — decoding website and reading the page regardless of anyone’s disapproval of the content.
Continue reading “Tiny Websites have no Server”
Most of us accumulate stuff, like drawers full of old cables and hard drives full of data. Reddit user [BaxterPad] doesn’t worry about such things though, as he built an impressive Network Attached Storage (NAS) system that can hold over 200TB of data. That’s impressive enough, but the real artistry is in how he did this. He built this system using ODroid HC2 single board computers running GlusterFS, combining great redundancy with low power usage.
Continue reading “Neat Odroid & GlusterFS Build Stashes Data, Sips Power”
Ok, now this is something special. This is a home network and security system that would make just about anyone stop, and with jaw hanging agape, stare, impressed at the “several months of effort” it took [timekillerjay] to install their dream setup. Just. Wow.
Want a brief rundown of the diverse skill set needed to pull this off? Networking, home security, home automation, woodworking, running two thousand feet(!) of cat 6a cable, a fair hand at drywall work for the dozens upon dozens of patches, painting, staining, and — while not a skill, but is definitely necessary — an amazingly patient family.
Ten POE security cameras monitor the premises with audio recording, infrared, and motion detection capabilities. This is on top of magnetic sensors for five doors, and eleven windows that feed back to an ELK M1-Gold security system which effortlessly coordinates with an Insteon ISY994i smart home hub; this allows for automatic events — such as turning on lights after dark when a door is opened — to occur as [timekillerjay]’s family moves about their home. The ELK also allows [timekillerjay] to control other things around the house — namely the sprinkler system — via relays. [timekillerjay] says he lost track of how many smart switches are scattered throughout his home, but there are definitely 39 network drops that service the premises.
All of the crucial components are hidden in his office, behind a custom bookshelf. Building it required a few clever tricks to disguise the bookshelf for the secret door that it is, as well as selecting components with attention to how much noise they generate — what’s the point of a hidden security system if it sounds like a bunch of industrial fans?
An uninterruptible power supply will keep the entire system running for about 45 minutes if there is a power outage, with the cameras recording and system logging everything all the while. Not trusting the entrance to his vault to something from Batman, he’s also fitted the bookshelf with a 600lb magnetic lock that engages when the system is armed and the door already closed. A second UPS will keep the door secured for 6+ hours if the house loses power. Needless to say, we think this house is well secured.
When a favorite piece of hardware dies, it’s fairly common to experience a bit of dread. The thought that now you’ll have to go through the process of getting a replacement for the device can be very troubling, and is fraught with difficult questions. Is the hardware still available? Has it been made obsolete by something else in the time you’ve had it? But while it can be a hassle, there’s no question you can come out the other side better than you went in. Sometimes it takes the passing of an old piece of gear for you to really embrace what’s possible with the latest and greatest.
That’s exactly what happened to [Tyler Langlois]. When his trusty home router finally gave up the ghost, he was left with a couple of options. He could get another consumer router, upgrade to a enterprise-level model, or take the road less traveled and build his own router to his exacting specifications. Since you’re reading about it on Hackday, we’ll give you one guess as to which door he went through.
The blog post [Tyler] has written up about the saga of building his own router is an incredible resource for anyone who might be thinking of taking the plunge into DIY networking. From selecting the proper hardware to the nuances of getting all of the software packages installed, this is an absolute treasure trove. At the beginning of the post he mentions that the post shouldn’t be considered a comprehensive guide, but considering we’ve seen commercial hardware that wasn’t documented this well, we’d have to respectfully disagree on that point.
Some elements of his homespun may come as something of a surprise. For one, [Tyler] bucked the hive mentality and determined the Raspberry Pi simply wasn’t up to the task due (at least in part) to the single 100 Mbps network interface. He ended up going with an ESPRESSObin, a relatively niche Linux SBC that features an onboard gigabit switch in addition to a fairly hefty spec sheet. He also decided to forgo WiFi entirely, and leave the intricacies of wireless networking to a standalone access point from Ubiquity.
A router is often overlooked as just another piece of consumer kit sitting around the house, but it’s actually an excellent place to flex your creative and technical muscle. From adding a remote display to converting it into a mobile battle tank, there’s a lot more you can do with your router than stare at the blinkenlights.
While it might not pack the computational punch you’d usually be looking for in a server platform, you can’t beat how cheap the Raspberry Pi is. As such, it’s at the heart of many a home LAN, serving up files as a network attached storage (NAS) device. But the biggest problem with using the Pi in a NAS is that it doesn’t have any onboard hard drive interface, forcing you to use USB. Not only is this much slower, but doesn’t leave you a lot of options for cleanly hooking up your drives.
This 3D printable NAS enclosure designed by [Paul-Louis Ageneau] helps address the issue by integrating two drive bays which can accommodate 2.25 inch laptop hard disk drives and their associated IB-AC6033-U3 USB adapters. The drives simply slide into the “rails” designed into the case without the need for additional hardware. There’s even space in the bottom of the case for a USB hub to connect the drives, and a fan on the top of the case to help keep the whole stack cool. It still isn’t perfect, but it’s compact and doesn’t look half bad.
The design is especially impressive as it doesn’t require any supports, an admirable goal to shoot for whenever designing for 3D printing. As an added bonus, the entire case is designed in OpenSCAD and licensed under the GPL v3; making modification easy if you want to tweak it for your specific purposes.
This certainly isn’t the strongest Raspberry Pi enclosure we’ve ever seen, that title would have to go to the ammo case that does double duty as a media streamer, but looks like it would make a great home for that new 3 B+ you’ve got on order.
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.