Sobering report from the World Economic forum. And, by ‘sobering,’ it means: if you don’t already have a drinking problem, this could cause one!
We talk about the IoT Christmas, and new things to watch out for:
Great interview with David Redekop of DNSthingy: Internet of things, Botnets and more… Wrap up by answering a few guest questions
If you’re interested in how threats occur in the modern days we talk about a variety of bad actor approaches and how they can be addressed or mitigated including an important role by Quad9.
Posted November 22, 2017
by David Redekop
DNSthingy’s core value is on-premise filtering with fastest possible performance (i.e. it isn’t a cloud DNS service), allowing you to apply different policies to different device groups. You’re never locked into a one-size-fits-all scenario. An IoT network should not have the same permission as a desktop or mobile device, for example.
However, once a domain is approved for upstream resolution, DNSthingy will send it to the upstream DNS resolver of your choice. This is made very easy with a customized drop-down list like this:
So, in addition to all the DNSthingy services, you can use quad9.net (18.104.22.168) as a resolver of last resort to provide additional protection.
Crunchyroll is in the top 1,000 sites globally. When a site this popular is hacked to distributed malware, it’s a big deal. Here’s an overview of how the hack worked:
The homepage suggested a new player to download, which, when you look at the source, was a actually updating the player from somewhere else *other* than crunchy roll:
It is worth noting that when websites are hacked for malicious intent, the actual payload is never hosted on the hacked site. The attacker simply changes the content of web server files so that unsuspecting visitors retrieve the malicious payload from a server elsewhere, usually one that is more completely controlled by the attacker.
In short, the victim’s computer retrieves the crunchyroll.com home page but along with it a request to download a new player from the attacker’s choosing. In this case, the IP address of 22.214.171.124 is based in the Netherlands, but even leading threat intelligence providers had no negative reputation scores for this IP address. Furthermore, the malware-laden CrunchyRoll.exe was digitally signed, allowing this to sneak by many layers of typical cybersecurity protection.
Compare that with the Zero Trust Model with what we call Don’t Talk To Strangers. “Strangers” are IP addresses that were not preceded with a DNS lookup. To use an example different from the Crunchyroll hack, consider if you want to ping 126.96.36.199 (and the result fails, in red below) vs ping google-public-dns-b.google.com (which succeeds in pinging 188.8.131.52 because it was preceded with a DNS lookup, in green below).
The zero trust model deployed in this manner protected Crunchyroll visitors from the very first moment their site was hacked. It provides the same protection for any other similar type of attack.
Posted October 31, 2017
by David Redekop
When your device auto-upgrades to version 3.2, you will enjoy the following enhancements:
1. Block page now utilizes an IP subnet (vs a single static IP on the LAN interface). This allows for faster unblock page processing, coming shortly.
2. Better NetBIOS name discovery. In cases where our service host is not the DHCP server, better name discovery is now included.
3. IP enforcement and DNS services combined into a single service. Previously there were two processes in place to facilitate load balancing across devices, but in cases where only one appliance is in use, a single process is more efficient.
4. Under mytools.management/log, logging capability has been enhanced with many view filter options (Status, IP, Name, Answer, Rule, Rule Kind, etc).
5. Logging capability addition for traffic logging in order to easily visualize blocked/allowed packets while narrowing the list down by source, destination or blocked/allowed status
Posted September 7, 2017
by David Redekop
Traditionally, DNS-level filtering for SSL has been problematic because the block page SSL certificate would never match the host header requested by the browser.
For example, https://badactor.co access would be presented with https://someblockurl.com certificate. This would result in the end-user having to approve an SSL mismatch warning, illustrated to the right, which incidentally, is exactly what bad actors would do with DNS poisoning attacks. This makes it very difficult to train end-users when to ignore and when to heed warnings like that!
Our approach is different. By default, all TCP port 443 (used for TLS/SSL connections) that attempt to connect to the block page server are rejected (a TCP reset). This achieves the following results:
End-user device response is immediate, so the user isn’t waiting and wondering what’s going on
Bandwidth usage is reduced
Device resources are never congested due to wait times
Some DNS-based SSL blocking approaches, will offer a DNS answer of 0.0.0.0 which achieves the above results as well, but then cannot present the end-user with anything helpful.
What we do want, is for the end-user to have some sort of feedback to indicate what just happened. This is where our browser extension comes in handy. To see it in action, here’s a short demonstration:
Posted August 23, 2017
by David Redekop
We’re excited to announce full support for the ASUS AC3100 (also known as AC88U) router. This router is available in many channels and makes a great home office router with solid built-in wifi capabilities.
If you already have one, follow these instructions to flash it with DNSthingy firmware and enjoy the choice of shaping your Internet as you see fit! 🙂
Traditionally, it has been difficult to block unwanted traffic that is initiated behind an Internet gateway. This is completely understandable considering that a traditional consumer, prosumer, and SMB gateways take an allow all, block some approach. This means that workarounds just need to find one protocol, destination or port that isn’t blocked, and bingo! Your egress channel is now unrestricted using that open hole.
What we are demonstrating here, though, is the opposite. A zero trust model works like this: block all, allow some. This idea of whitelisting is far from new. However, a practical and convenient way to do so has been the challenge. We would like to share with you how we implement a practical solution:
The DTTS (Don’t Talk To Strangers) is currently available for an early adopter group. If you’re interested, kindly contact us via support.