Setting up a local DNS adblocker to get rid of ads, trackers, telemetry, and malware on a FreeBSD jail
We all heard about adblocking at DNS level, implemented by services like
Pi-hole, or maybe just setting an external custom DNS server like
Cloudflare's 184.108.40.206 (fast & more private, not necessarily blocking requests), or
These are all great options, but in my opinion they all lack a little bit of something, or provide too much. For example, external, custom DNS servers are good for a quick & easy setup, but you lack the ability of customizing the sources or manually whitelisting or blacklisting domains, and so on. On the other hand, a service like Pi-hole is great, it allows you to set up custom sources, you can whitelist and blacklist custom domains, you can set your own provider for the upstream DNS server, but it kinda requires a Debian-based distro in order to offer an easy setup via their own installer, in order to get the web ui.
I am running this blog since the start of 2017, and while Hugo was something that I was really considering using, I ended up using
Ghost, for its beautiful editor and other UI bling blings.
Ghost in the shell
At the time, Ghost was in his early minor-only version, and the set up was more or less manual. This meant that you needed to get an archive, install dependencies (Node.JS, npm, MySQL), set them up, and you’d end up with a working CMS. Updating it, though, was rough. Back up content, download archive again, install/update npm dependencies if needed, put content back, hope it’ll work. It worked, most of the times.
A friend brought me an LG Nexus 5X which wouldn’t power up anymore, after a hard shock (a fall). A symptom being “the Google logo appearing over and over again until it ran out of battery”. Apparently the owner took it to service before, regarding the issue, but “reflashing didn’t work”.
As an owner of a Nexus 5X, I took the matter in my own hands (a.k.a. searching the interwebs - ahem, XDA - for fixes).
What I was dealing with:
- Bootloop - nothing more past the Google logo
- Wouldn’t stay powered off while charging - plug in, bootloop occurs; not an issue, but makes the charging take longer
- Able to access the bootloader menu - useful for powering off, no recovery access available
Many times, you find yourself in a situation where you have to wait for a long task to complete, maybe little to no output available, and you end up hitting that Ctrl-C, pushing a SIGINT into the CLI software.
And it quits.
Without outputting whatever you needed or even printing a little progress. And it’s a little frustrating, even though it’s probably working as expected, taking what SIGINT does in consideration.
So, how do we introduce a classic “do you really want to exit?” confirmation in a Go CLI software?
I’ll just start this post with stating that I’m not doing this with malicious intents, nor am I going to use this for other purposes than learning, or advise using this on servers others than your own. That being said, let’s get down to business.
Why an SSH brute-forcer?
Because too many people are still using password authentication with weak passwords. There are still many servers with sshd open with the default port exposed to internet, using accounts with weak passwords. Have a RaspberryPi? Put it on the Internet! Just take a look over Shodan’s raspbian with port 22 query. It’s crazy. We’re kinda fighting fire with fire.
The filesystem table, or more commonly known as fstab or /etc/fstab, is a system configuration file, which is parsed by mount during boot, and misconfiguration or typos can render the system somewhat unusable.
By default on Debian and Ubuntu systems, the root partition has the errors=remount-ro option set, which indicates that if the mount encounters any error, it should only remount the partition as read-only, to prevent damage. In that case, for example, many applications will stop working, unexpected behaviour will be present, among other issues.