Updating your Bind DNS for latest trust anchors

A little Background on the rollover

From: https://www.icann.org/resources/pages/ksk-rollover/#overview
ICANN
 is planning to perform a Root Zone Domain Name System Security Extensions (DNSSEC) KSK rollover as required in the Root Zone KSK Operator DNSSEC Practice Statement [TXT, 99 KB].

Rolling the KSK means generating a new cryptographic public and private key pair and distributing the new public component to parties who operate validating resolvers, including: Internet Service Providers; enterprise network administrators and other Domain Name System (DNS) resolver operators; DNS resolver software developers; system integrators; and hardware and software distributors who install or ship the root’s “trust anchor.” The KSK is used to cryptographically sign the Zone Signing Key (ZSK), which is used by the Root Zone Maintainer to DNSSEC-sign the root zone of the Internet’s DNS.

Maintaining an up-to-date KSK is essential to ensuring DNSSEC-validating DNS resolvers continue to function following the rollover. Failure to have the current root zone KSK will mean that DNSSEC-validating DNS resolvers will be unable to resolve any DNS queries.

If you are running bind the quickest way to check is this:

If your configuration shows dnssec-validation yes;, you must change it to dnssec-validation auto;and restart your server before taking the steps below. This is in your named.conf

NIST releases second draft of “Guidelines for the Selection, Configuration, and Use of Transport Layer Security (TLS) Implementations.”

From an e-mail the folks at nist sent out.

NIST has released a second draft of NIST Special Publication (SP) 800-52 Revision 2,Guidelines for the Selection, Configuration, and Use of Transport Layer Security (TLS) Implementations. It provides guidance for selecting and configuring TLS protocol implementations that utilize NIST-recommended cryptographic algorithms and Federal Information Processing Standards (FIPS). The document requires that government TLS servers and clients support TLS 1.2 configured with FIPS-based cipher suites, and recommends that agencies develop migration plans to support TLS 1.3 by January 1, 2024.

A public comment period for this document is open until November 16, 2018.

CSRC Update:
https://csrc.nist.gov/news/2018/second-draft-of-TLS-guidance-now-available

Publication Details:
https://csrc.nist.gov/publications/detail/sp/800-52/rev-2/draft

CredSSP error message fix for Windows RDP

The folks over at On-Ramp Indiana found a fix for this one.
The Microsoft Tech Article can be found here…

Symptoms


Consider the following scenario:

In this scenario, you receive the following error message:

If you are getting a CredSSP error message when trying to RDP to a server add this registry key to your local computer.  It will disable CredSSP

  • [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\CredSSP\Parameters] “AllowEncryptionOracle”=dword:00000002

It’s day like this…

Today a major vulnerability was released to the public from a well-known vendor.  All of our consulting customers have been notified of this critical update.  Those whom we manage the network for already have a mitigation plan in place and a course of action.

If you are not a regular customer ask us howe.  For as little as $50 a month you can be notified of critical updates for your infrastructure. With all of the information out there, having a customized notification service for your ISP means you can spend more time making money instead of worrying about your network.  Contact us today for details on this service.

DHCP Starvation attack

DHCP starvation attacks are designed to deplete all of the addresses within the DHCP scope on a particular segment. Subsequently, a legitimate user is denied an IP address requested via DHCP and thus is not able to access the network.  Yersinia is one such free hacking tool that performs automated DHCP starvation attacks. DHCP starvation may be purely a DoS mechanism or may be used in conjunction with a malicious rogue server attack to redirect traffic to a malicious computer ready to intercept traffic. Imagine a user filling up the dhcp pool and then re-directing users to their own DHCP server.

How do you fix this?
802.11 has several mechanisms built in. DHCP Proxy is one way. Port security is another. If you are running Mikrotik there are some scripts which can alert you to rogue DHCP servers, but that is an after-the-fact kind of thing.

 

Product Review: Sync Stop

As I get ready for my trip to Vegas to attend WISPAPALLOZA 2017 the following product becomes relevant.  Security, namely Identity Theft, is becoming more and more of something we have to deal with.  Much like pickpockets, digital Identity theft is a real thing.

This is where the SyncStop by Xipiter comes in.  This is a simple device.  It allows you to charge your phone on any USB enabled connection, but does not allow syncing by cutting off access to the data pins of the USB connection at the hardware level.

If you travel alot I would suggest investing in a few of these.  Let’s face it, we try and find an outlet anywhere we can when it comes to charging our phones.  Hackers know this.  A cleverly designed “public charge station” could be easily compromised to feed your data back to a remote server in just a few minutes and you would probably never notice.

WPA is not encrypting your customer traffic

There was a Facebook discussion that popped up tonight about how a WISP answers the question “Is your network secure?” There were many good answers and the notion of WEP vs WPA was brought up.

In today’s society, you need end-to-end encryption for data to be secure. An ISP has no control over where the customer traffic is going. Thus, by default, the ISP has no control over customer traffic being secure.  “But Justin, I run WPA on all my aps and backhauls, so my network is secure.”  Again, think about end-to-end connectivity. Every one of your access points can be encrypted, and every one of your backhauls can be encrypted, but what happens when an attacker breaks into your wiring closet and installs a sniffer on a router or switch port?What most people forget is that WPA key encryption is only going on between the router/ap and the user device.  “But I lock down all my ports.” you say.  Okay, what about your upstream? Who is to say your upstream provider doesn’t have a port mirror running that dumps all your customer traffic somewhere.  “Okay, I will just run encrypted tunnels across my entire network!. Ha! let’s see you tear down that argument!”. Again, what happens when it leaves your network?  The encryption stops at the endpoint, which is the edge of your network.

Another thing everyone hears about is hotspots. Every so often the news runs a fear piece on unsecured hotspots.  This is the same concept.  If you connect to an unsecured hotspot, it is not much different than connecting to a hotspot where the WPA2 key is on a sign behind the cashier at the local coffee shop. The only difference is the “hacker” has an easier time grabbing any unsecured traffic you are sending. Notice I said unsecured.  If you are using SSL to connect to a bank site that session is sent over an encrypted session.  No sniffing going on there.  If you have an encrypted VPN the possibility of traffic being sniffed is next to none. I say next to none because certain types of VPNs are more secure than others. Does that mean the ISP providing the Internet to feed that hotspot is insecure? There is no feasible way for the ISP to provide end to end security of user traffic on the open Internet.

These arguments are why things like SSL and VPNs exist. Google Chrome is now expecting all websites to be SSL enabled to be marked as secure. VPNs can ensure end-to-end security, but only between two points.  Eventually, you will have to leave the safety and venture out into the wild west of the internet.  Things like Intranets exist so users can have access to information but still be protected. Even most of that is over encrypted SSL these days so someone can’t install a sniffer in the basement.

So what is a WISP supposed to say about security? The WISP is no more secure than any other ISP, nor are then any less secure.  The real security comes from the customer. Things like making sure their devices are up-to-date on security patches.  This includes the often forgotten router. Things like secure passwords, paying attention to browser warnings, e-mail awareness, and other things are where the real user security lies. VPN connections to work. Using SSL ports on e-mail. Using SSH and Secure RDP for network admins. Firewalls can help, but they don’t encrypt the traffic. Does all traffic need encrypted? no.

Dirty Cow is Coming – Update your *nix boxes

Dirty COW (CVE-2016-5195) is a privilege escalation vulnerability in the Linux Kernel.

This is an old vulnerability but appears to be something being exploited regularly.  In otherwords, keep your stuff up-to-date.

https://github.com/dirtycow/dirtycow.github.io/wiki/VulnerabilityDetails

https://dirtycow.ninja/

Check to see if your systems are vulnerable:
https://github.com/dirtycow/dirtycow.github.io/wiki/Check-if-your-system-is-vulnerable

Homeland Security US-Cert e-mail on Network infrastructure

A few days ago Homeland Security published an e-mail on threats to network devices and securing them.  Rather than cut and paste I exported the e-mail to a PDF. Some good best practices in here.

TA16250A The Increasing Threat to Network Infrastructure Devices and Recommended Mitigations