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

Guest Article: Can my router catch a virus?

Our friends over at TechWarn have their take on routers vulnerable to virus attacks

https://www.expressvpn.com/blog/can-my-router-catch-a-virus/

Big price differences between routers are often confusing to consumers as, unlike with personal computers, the quality difference is not always obvious. As routers are normally tied to a physical location, it is also rather difficult to test their reliability in different environments, unlike with highly mobile laptops or smartphones.

Routers often do not receive updates, or updates have to be manually downloaded and applied — a cumbersome process that is not an attractive option to many non-tech-savvy users.

Routers are desirable targets for attackers as they sit at a very sensitive spot on a network — right at the edge. They are a centralized point and connected to every single device in the network. Routers read all of the data that each device sends to the Internet, and if these connections are unencrypted, the router could easily inject malicious scripts and links.

Read more here..

LetsEncrypt and Mikrotik

Recently there has been some activity on integration with LetsEncrypt and Mikrotik.   WHile Mikrotik does not directly support Letsencrypt directly yet, you can make it work with this setup

https://github.com/gitpel/letsencrypt-routeros

 

 

From the GitHub Page:

How it works:

  • Dedicated Linux renew and push certificates to RouterOS / Mikrotik
  • After CertBot renew your certificates
  • The script connects to RouterOS / Mikrotik using DSA Key (without password or user input)
  • Delete previous certificate files
  • Delete the previous certificate
  • Upload two new files: Certificate and Key
  • Import Certificate and Key
  • Change SSTP Server Settings to use new certificate
  • Delete certificate and key files form RouterOS / Mikrotik storage

While not perfect is a start.

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.

 

Vulnerability in WPA2

https://arstechnica.com/information-technology/2017/10/severe-flaw-in-wpa2-protocol-leaves-wi-fi-traffic-open-to-eavesdropping/

An air of unease set into the security circles on Sunday as they prepared for the disclosure of high-severity vulnerabilities in the Wi-Fi Protected Access II protocol that make it possible for attackers to eavesdrop Wi-Fi traffic passing between computers and access points.

The proof-of-concept exploit is called KRACK, short for Key Reinstallation Attacks. The research has been a closely guarded secret for weeks ahead of a coordinated disclosure that’s scheduled for 8am Monday, East Coast time. An advisory the US CERT recently distributed to about 100 organizations described the research this way:

US-CERT has become aware of several key management vulnerabilities in the 4-way handshake of the Wi-Fi Protected Access II (WPA2) security protocol. The impact of exploiting these vulnerabilities includes decryption, packet replay, TCP connection hijacking, HTTP content injection, and others. Note that as protocol-level issues, most or all correct implementations of the standard will be affected. The CERT/CC and the reporting researcher KU Leuven, will be publicly disclosing these vulnerabilities on 16 October 2017.

 

From Mikrotik:

On October 16. CERT/CC/ICASI released a public announcement about discovered vulnerabilities in WPA2 handshake protocols that affect most WiFi users and all vendors world wide.
RouterOS v6.39.3, v6.40.4, v6.41rc are not affected!
It is important to note that the vulnerability is discovered in the protocol itself, so even a correct implementation is affected.
These organizations did contact us earlier, so we have already released fixed versions that address the outlined issues. Not all of the discovered vulnerabilities directly impact RouterOS users, or even apply to RouterOS, but we did follow all recommendations and improved the key exchange process according to the guidelines we received from the organizations who discovered the issue.
We released fixed versions last week, so if you upgrade your devices routinely, no further action is required.
CWE-323
CVE-2017-13077
CVE-2017-13078
CVE-2017-13079
CVE-2017-13080
CVE-2017-13081
CVE-2017-13082
CVE-2017-13083
CVE-2017-13084
CVE-2017-13085
CVE-2017-13086
CVE-2017-13087

 

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.

Everything you wanted to know about NTP

Network Time Protocol (NTP) is a service that can be used to synchronize time on network connected devices.   Before we dive into what NTP is, we need to understand why we need accurate time.

The obvious thing is network devices need an accurate clock.  Things like log files with the proper time stamp are important in troubleshooting.  Accurate timing also helps with security prevention measures.  Some attacks use vulnerabilities in time stamps to add in bad payloads or manipulate data. Some companies require accurate time stamps on files and transactions as well for compliance purposes.

So what are these Stratum levels I hear about?
NTP has several levels divided into stratum. All this is the distance from the reference clock source.  A clock which relays UTC (Coordinated Universal Time) that has little to no delay (we are talking nanoseconds) are Stratum-0 servers. These are not used on the network. These are usually atomic and GPS clocks.  A Stratum-0 server is connected to time servers or stratum-1 via GPS or a national time and frequency transmission.  A Stratum 1 device is a very accurate device and is not connected to a Stratum-0 clock over a network.  A Stratum-2 clock receives NTP packets from a Stratum-1 server, a Stratum-3 receives packets from a Stratum-2 server, and so on.  It’s all relative of where the NTP is in relationship to Stratum-1 servers.

Why are there levels?
The further you get away from Stratum-0 the more delay there is.  Things like jitter and network delays affect accuracy.  Most of us network engineers are concerned with milliseconds (ms) of latency.  Time servers are concerned with nanoseconds (ns). Even a server directly connected to a Stratum-0 reference will add 8-10 nanoseconds to UTC time.

My Mikrotik has an NTP server built in? Is that good enough?
This depends on what level of accuracy you want. Do you just need to make sure all of your routers have the same time? then synchronizing with an upstream time server is probably good enough. Having 5000 devices with the same time, AND not having to manually set them or keep them in sync manually is a huge deal.

Do you run a VOIP switch or need to be compliant when it comes to transactions on servers or need to be compliant with various things like Sox compliance you may need a more accurate time source.

What can I do for more accurate time?
Usually, a dedicated appliance is what many networks use.  These are purpose built hardware that receives a signal from GPS. the more accurate you need the time, the more expensive it will become.  Devices that need to be accurate to the nanosecond are usually more expensive than ones accurate to a microsecond.

If you google NTP Appliance you will get a bunch of results.  If you want to setp up from what you are doing currently you can look into these links:

http://www.satsignal.eu/ntp/Raspberry-Pi-NTP.html

How to Build a Stratum 1 NTP Server Using A Raspberry Pi

 

Building a Stratum 1 NTP Server with a Raspberry Pi