Blacklisting vs Whitelisting

Posted July 22, 2016 by David Redekop to Blacklist Whitelist

whitelisting-blacklisting-infographic

In the context of web resources to allow or block, the traditional approach has been to block the bad. That’s blacklisting. It is the ideology of allow everything, block some.

Whitelisting, on the other hand is the opposite ideology: block everything, allow some.

This infographic is not controversial in nature, but there are legitimate reasons why whitelisting has not gained traction. However, let’s examine a few real-life examples where the trend towards whitelisting is succeeding.

iOS AppStore
While criticism over a curated AppStore has never stopped, the end result is undeniably a safer mobile app ecosystem for the normal user.

Microsoft AppLocker
From Microsoft directly:

“AppLocker contains new capabilities and extensions that allow you to create rules to allow or deny applications from running based on unique identities of files and to specify which users or groups can run those applications.”

Essentially, this is an accepted and recommended solution that whitelists executable applications in business versions of Windows, and many systems administrators literally use this approach insted of anti-virus protection, with great success!

It is only logical that DNS-based whitelisting for Internet-based resources would also be filtered using a whitelist method. It has not been widely deployed in the past due to the onboarding effort. This is where DNSthingy helps with the whitelist ecosystem including DNSthingy Whitelist Assistant Google Chrome Extension, real-time logging visibility, Whitelist Subscriptions (for sites with dependencies such as YouTube, Google, Facebook, etc.), learning mode for businesses who deploy in passive mode for 60-90 days in order to gain an organic whitelist suitable for their own enterprise.

So if you’ve wanted to give whitelisting a try, now there’s a simple and free way to try it out!

New SafeSearch option includes Bing

Posted June 27, 2016 by David Redekop to DNS Feature

SafeSearch filters the display of explicit search results in images, videos, and text.

We’re glad to be able to offer an expanded version of our Forced SafeSearch feature. Forced SafeSearch uses the network-level enforcement method offered by Bing and Google. Here’s how the feature looks on the dashboard with a simple ON/OFF button:

Force SafeSearch option on DNSthingy.com/dashboard

This setting is now on by default for new subscribers and new Blacklist rulesets. This was much requested as iOS’s Siri uses Bing exclusively.

Why we believe Forced SafeSearch is better

It is important to note that this feature is not locking SafeSearch as utilized in the past for school/home environments. Locking and other proxy methods previously in use, could easily bypass SafeSearch by using https (SSL) instead of http. Locking SafeSearch into the browser is easily bypassed with a new private/incognito window.

The combination of network-level forced SafeSearch and alternate DNS attempts being blocked (also a default with DNSthingy in router mode) makes circumvention much more difficult.

New YouTube filtering options

Posted June 10, 2016 by David Redekop to Feature

Our new Ruleset feature looks like this, and is available for any ruleset type, blacklist or whitelist:

youtube-filtering

No YouTube account login required. YouTube offers opt-in restriction mode by logged-in accounts, which can easily be circumvented by launching a different browser, or by using new incognito/private window. However, when this setting is used on a DNSthingy service, it cannot be bypassed. Attempts to do so will look like this:

Restricted Mode is enabled by your network administrator.

Here’s an example of a common YouTube search today and how the results vary by filtering level options:

Searching "Miley Cyrus" Unfiltered Moderate Strict Blocked
Search results 10 Million+ 7 Million+ 500,000 None
(all) (some filtered out) ~95% filtered out!

In addition, both moderate and strict modes filter out comments which is most often requested by our subscriber to suppressed regardless of filtering levels. The comment section will state this:

Restricted Mode has hidden comments for this video.

You might also notice that no matter what the YouTube account settings are at, your DNSthingy is considered a network-level enforcement option, so it overrides your YouTube account.

When using network-level enforcement of filtering options, it doesn’t matter how YouTube is watched, as all of these are covered:

  • YouTube app on mobile
  • YouTube via browser on mobile
  • YouTube via desktop browser
  • YouTube via incognito/private window
  • YouTube embedded on a website/blog post

And finally, you can set different rulesets for different devices. Our solution is the only one in existence that can offer network-level enforcement options with different settings per device or group of devices. Here’s how our subscribers typically use it:

Role Forced YouTube Safety Mode
Parents/Business Owners Off (with optional account-level opt-in, but note it is easy to circumvent)
Staff/PG13+ Moderate
Children 12 and under Strict (or, if necessary, it can be blocked entirely on a blacklist)

We’ve had some great feedback from early adopters and are thrilled to make this available to all of our subscribers.

New platform release available

Posted May 23, 2016 by David Redekop to Feature

DNSthingy services are now available as a preview release that can be installed on pfSense® software from ESF.

Minimimum system requirement is simply any existing pfSense® installation version 2.3+. pfSense® is a platform chosen by many seasoned IT veterans that focus on managed gateways for a variety of business sectors. Based on FreeBSD, this platform’s strength is in its stability and subscription-free operating system. While DNSthingy is subscription-based, it is still a fit based on the high number of requests over the past while to offer our services on this platform.

For a preview-release installation and a free evaluation, simply contact our support team. We are looking in particular for more multi-WAN environments as well as usage of several VLANs with restrictive/hardened environments.

pfSense® is a registered trademark owned by Electric Sheep Fencing LLC and is used herein with permission.
More information as to pfSense® can be found at www.pfsense.org.

Schedule Internet Access Rules

Posted April 12, 2016 by David Redekop to Feature

Did you know you can schedule your Internet access rules?

Here’s a screenshot of a sample schedule in use by one of our homeschoolers, designed to minimize distractions during the schooldays, while providing entertainment and social media access in specific times of the day:

Scheduled Internet Access

You can completely customize it your own. Here are some typical use cases:

  • Your small business likes to keep staff focused on specific tasks during specific hours. Create a ruleset and a schedule that whitelists only required services for required times.
  • While the office is closed, no Internet access is required except for services such as operating system updates and online backups. Create a schedule that these are the only services allowed during closed hours.
  • Not sure what your Internet-of-Things devices are doing? Schedule them to be online only when they’re in use.

Here’s a short 3-minute video to give you an alternate example:

Malware protection from mistyped .OM URLs

Posted March 16, 2016 by David Redekop to Blacklist

Thanks to Lifehacker for reporting this:

Next time you accidentally type .om instead of .com in your browser, beware of malware. A new scam targets URL typos and tries to install dangerous software on your computer.

If you want to protect your entire network from this, simply go from OFF to ON in your DNSthingy.com/dashboard:

better-safe-than-sorry

Now if you mistype yourcompany.com as yourcompany.om in the browser URL, you’ll be protected like this:

yourcompany-om

Of course, if you need to visit legitimate websites that use the .om extension, those can easily be added to a rainbow list. One of the frequent uses of a rainbow list is to create an “exception to the rule”.

Authoritative DNS made easy

Posted February 15, 2016 by David Redekop to DNS Feature

How often do you end up having to remember IP addresses to access internal resources such as a NAS or any of your IoT devices? Consider using names instead of IP addresses:

Before After
By IP address By memorable name
Example: http://192.168.1.10 Example http://MyNAS.local
Hard to remember Easy to remember
Might change with a factory reset Never needs to change
Incompatible with future network schemes Never needs to change
Will need to change with IPv6 Never needs to change

A better practice is to simply choose an easy-to-remember name and use your DNSthingy to create an authoritative list and enable it on your rulesets. Now you’ll never have to remember the IP address by simply following these steps, for example, if you had a NAS at 192.168.1.10 you wish to access by various names:

  1. From DNSthingy.com/dashboard, login and create a new authoritative list like this:
    Create an authoritative list
  2. Fill in the IP address and the full list of names you want to work, similar to this:
    Edit the list names
  3. Finally, enable the list in your rulesets so it looks like this:
    Authoritative list enabled

That’s it! You’re all set! Now you can always access your NAS via http://mynas.local or http://nas.local or http://yournas.local or http://newnas.local.

Important: this feature requires version 2.7.0 which will be automatically upgraded for all subscribers and non-subscribers alike.

Ad-free iOS apps

Posted December 17, 2015 by David Redekop to Blacklist Case Study DNS

iOS apps, especially with little children, are often completely unusable unless the ads and trackers are all blocked. Many parents are used to putting an app in airplane mode before letting kids play. Unfortunately that disqualifies all apps that require connectivity.

DNSthingy ad-blocking disabled: DNSthingy ad-blocking enabled:
with-iAd without-iAd

While Apple has their own iAd ecosystem, many mobile apps use alternate ad providers (mopub is a popular one), which are already blocked in our default blacklists.

But to have a truly beautiful iOS app experience and cover all the bases, follow these steps for the ruleset applied to your iOS devices:

  1. block-ads

    The blacklist above does not include hosts that prevent services from working.

  2. Now you want to create a separate list (Dashboard -> Manage Rules -> My Lists -> Create a List -> blacklist) called iAds and include these hosts:

    iadsdk.apple.com
    iad.apple.com

  3. Finally, go to your Ruleset and turn it on like this:

    block-iAds

Note: blocking Apple iAds will prevent iTunes radio (does anyone still listen to that?) from working as well as the occasional tracked ad. For most subscribers, this is a small price to pay for a superior iOS app experience.

Enjoy!

Real SSL certificate on our firmware

Posted December 7, 2015 by David Redekop to Feature Security

Securing the world of Internet communications with self-signed SSL certificates has had an unintended consequence:

invalid certificate

We would like to undo this. The reasons why prosumer-grade or even commercial-grade routers have never done this is two-fold:

  1. The nature of manual firmware upgrade cycles. Manufacturers have traditionally waited for the end-user to download and apply firmware upgrades.
  2. Certificates have an actual expiry date. Therefore, if the end-user does not upgrade the certificate (i.e. firmware), the certificate expires, in which case it’s even worse than a self-signed or unsigned certificate as some browsers don’t even allow for an override to continue.

Since DNSthingy firmware in prosumer gateways are upgraded without the option of opting out, it opened the door for us to include a real SSL certificate and at the very least contribute to the undoing of the comfort level of self-signed or unsigned certificates. When you access the gateway of any of our ASUS routers flashed with DNSthingy firmware and inspect the SSL certificate, this is what you will see:

mybox.management certificate

We recognize that this approach could be analyzed as a weakness insomuch as reverse engineers could capture the private key off any of our firmware devices. That means in combination with DNS poisoning in a man-in-the-middle scenario + possession of the private key, our domain mybox.management could be abused. However, the domain mybox.management is used nowhere else except on the devices themselves, and is irrelevant to our device-to-controller communications. From our perspective, the upside is dramatically more pronounced than the down-side.

In related news, we salute the efforts of letsencrypt.org‘s sponsors to make SSL everywhere more accessible and affordable. Beta is now open to the public.

Case Study: save thousands on video bandwidth

Posted December 2, 2015 by David Redekop to Blacklist Case Study

In many parts of the world, even the western world, bandwidth is expensive. One of our subscribers is out in the “middle of nowhere” as they call it, far away from any affordable fibre, DSL or cable, and the only connectivity option is a metered LTE connection.

It didn’t take long to find out that their $1,100+/month bill came from the video content being consumed by the 30+ stone quarry labourers near the office during their breaks and lunches. As probably is common in many parts of the world, they were browsing YouTube, Netflix and Facebook.

The owners felt they had two basic options:

  1. Disallow staff the usage of WiFi altogether. This would have an impact on morale and may not be an effective move.
  2. Disallow the bandwidth-consuming services and explain to the staff the high cost of bandwidth in this geographic region.

They chose the latter option, and it was literally as simple as creating a DNSthingy black list with these domains in a list called Bandwidth hogs:

youtube.com
netflix.com
netflix.net
video-ord1-1.xx.fbcdn.net
lp.longtailvideo.com
cdn.liveleak.com

However, the owners wanted to naturally exempt themselves from this blacklist, so they simply created two rulesets as follows:

Ruleset How it's used For which devices
#1 Bandwidth hogs blacklist applied Ruleset applies to all devices as well as new ones by default (i.e. when a new wifi device joins for the first time)
#2 Bandwidth hogs blacklist not applied Ruleset applies to owners' devices

On the DNSthingy dashboard, here’s how it looks now:
Explanation How it looks
Block the bad (ruleset used by default) Bandwidth hog ON
Business Owners (ruleset applied to owners' devices) Bandwidth hog OFF
This is how it looks when rulesets are assigned (under Dashboard -> Manage Network -> Devices): Manage Devices - Owners

This subscriber is going to save an estimated $10,000 in bandwidth costs this year based on the above steps.

  • This approach still allows for general Facebook access, but the videos do not play and therefore bandwidth is saved.
  • This blacklist is available for you to subscribe to, so when domains are added to it in the future, you automatically benefit. Once you’re logged into your own dashboard, simply visit:

https://www.dnsthingy.com/dashboard/share_accept/agtzfmRuc3RoaW5neXITCxIKQnVuZGxlTGlzdBjBn_4RDA
(will open new tab/window)

You will then need to Subscribe (inherit changes by the author, yours truly), or Make a copy (manage your own changes in the future) as shown in this screenshot:

subscribe-copy

If you have a favourite list of your own, you can use the share feature (available on any list in your account) and share the URL with others to subscribe. A public-facing site for those that want to share their list is in development.