From honeypots to router analysis

It all started when we received a response to one of the automatic e-mails generated by our honeypots when they detect an attack attempt or suspicious behavior. These notifications are sent to abuse contacts of the network from which the attack originated. Portscan of the WAN interface:

Impressions from the Locked Shields 2017

Locked Shields is the largest international cyber security drill. It is regularly organised since 2010 by NATO CCDOE (Cooperative Cyber Defence Centre of Excellence), and the focus of the drill is a clash between two teams. The red team attacks the blue team, which plays the role of the defender. This year, the drill was attended by a total of 19 blue teams. The teams were charged with the defense of a diverse computer infrastructure of a fictional country’s military base consisting of different servers, numerous workstations, SCADA systems, etc. The defenders were to face attackers, whose objective was to damage, compromise, or completely take down the network or its elements, or at least to make things complicated for the defenders. In addition to the technical part, the drill is focused also on strategic decision-making, cooperation with the press and the handling legal matters. We were invited by colleagues from GovCert and assigned to the “Linux team”.

Are open validating resolvers still relevant today?

For many years, our association has been running a service going by the acronym “ODVR” – Open DNSSEC Validating Resolvers. At times when DNSSEC was just beginning, we thought it was necessary to come up with an alternative to DNS resolvers provided by ISPs who introduced the validation support too slowly. Since then, we have offered a publicly available service that allows validation of domains using DNSSEC security even in those networks whose default DNS resolvers do not support this.

New statistics and increase in popularity of elliptic curves in DNSSEC

It has been almost half a year since we presented the intention to change the DNSSEC algorithm for .cz zone DNSSEC key at our IT 16.2 conference. In his presentation, our colleague Zdeněk Brůna described in detail the advantages of algorithms based on elliptic curves, especially the ECDSA algorithm. However, due to the situation where this step cannot be done because of the lack of support for this algorithm in the root zone, our activities have shifted to mainly educate and monitor the impact of this education on the state of support for this new technology. At a seminar with registrars that we held at the end of February, we noticed a positive response to some ECDSA properties, such as smaller zone file size or smaller DNS response size. Some registrars have already declared interest in switching to ECDSA. At the same time, the registrars have suggested that we publish statistics on our site showing how different DNSSEC algorithms are used in the .cz zone. We liked this idea and we are now publishing these statistics.

Are homogenic nameserver names a single point of failure?

The golden rule of security, stability, and resiliency of virtually anything is “don’t put all your eggs into one basket”. This generally applies to the DNS, and there are some recommendations to avoid having all your nameservers in one domain. I would like to show that in this case, this is not a silver bullet, it depends on many conditions, and using different domains in your nameserver set might even make things not better, but worse.

Three years with Turris

A couple of weeks ago, I got an email informing me that it had been almost three years since my entry into the Turris project, and I could now purchase the router for a symbolic price of one crown. I did that right away to test for my colleagues whether the system works well; however, it also brought back nostalgic memories. Because three years ago I had the same goal – to test whether everything was working properly – when I filled what was probably the first router lease contract. Those three years have gone by in a flash, so it is perhaps a good time to stop and look back.

Reducing TTL in the .cz zone

DNS records contain a lot of important data, including the information on how quickly such data becomes obsolete, the so-called TTL (Time To Live). TTL in the DNS indicates for how long the data can be stored on a recursive nameserver (resolver) without it being retrieved from an authoritative nameserver. The lower the TTL, the more frequently resolvers query authoritative nameservers and obtain the most recent data. At the same time, however, a short TTL causes heavier load on nameservers, and if DNS records do not change often, the TTL is usually set to several hours.