Microblog : A very long article Wikipedia article on the orientation of toilet paper [7 jun à 22:52] [R]

Mercredi, 27 avril 2016

DNS 2: DNSSEC

Traduction: [ Google | Babelfish ]

Catégories : [ Informatique ]

Second part of my DNS setup notes, this time about DNSSEC. The following notes assumes there is already a running instance of Bind 9 on a Debian Jessie system for an imaginary domain example.com, served by a name server named ns.example.com.

The version of Bind 9 (9.9.5) on Debian Jessie supports "inline signing" of the zones, meaning that the setup is much easier than in the tutorials mentioning dnssec-tools or opendnssec.

Again these notes are mostly based on the example from the ISC Knowledge Base.

Setting up a signed zone

If you have a delegated zone (like home.example.com from the first part), do the following for both example.com and home.example.com.

Generate the keys
On a machine with enough available entropy in /dev/random (such as a Raspberry Pi with its hardware random number generator ) run
dnssec-keygen example.com
dnssec-keygen -fk example.com

(you can add the -r /dev/urandom option to the command if you dare, if /dev/random is too slow. It can literaly take hours to generate those keys otherwise).

Transfer the keys to the server where Bind is running.

Configure Bind

Create a /etc/bind/keys directory where to put the keys. Ensure the .private files belong to root, are readable by the group bind and not by other users.

In named.conf.options add to the options block:
options {
        …
        dnssec-enable yes;
        dnssec-validation auto;
        dnssec-lookaside auto;
        …
};

Create in /var/cache/bind a symbolic link to /etc/bind/db.example.com.

In named.conf.local, in the zone "example.com" block, add
zone "example.com" {
				…
        #file "/etc/bind/db.example.com";
        file "/var/cache/bind/db.example.com";
        key-directory "/etc/bind/keys";
        auto-dnssec maintain;
        inline-signing yes;
};

Note that the db file must point to a file in /var/cache/bind, not in /etc/bind. This is because bind will create a db.example.com.signed file (among other related journal files), constructed from the path of the "file" entry in the zone declaration, and it will fail doing so if the file is in /etc/bind, because Bind would attempt to create the .signed file in this read-only directory.

Then reload the configuration with
rndc reconfig
Then check that the zone is signed with
rndc signing -list example.com

Linking the zones

Your registrar should provide a tool (most probably Web based) where to put DS records for your domain.

On the DNS server, generate a DS record with
dig @localhost dnskey example.com | /usr/sbin/dnssec-dsfromkey -f - example.com
Copy and paste these lines in the registrar's tool. After a little while, you should be able to query the DS record with
dig @localhost -t ds example.org
If you have a delegated zone such as home.example.com, generate a DS record for that zone with
dig @localhost dnskey home.example.com | /usr/sbin/dnssec-dsfromkey -f - home.example.com
and place these lines in db.example.com (i.e., the db file for the parent zone). Change the serial number of the zone in the same file and run
rndc reload
You should then be able to query the DS record with
dig @localhost -t ds home.example.org

You can use Verisign's DNS debugging tool to check that the signatures are valid and DNSViz to view the chain of signatures from the TLD DNS down to your DNS. This also helped me figure out that my zone delegation was incorrect and caused discrepancies between my primary DNS server and the secondary server.

[ Posté le 27 avril 2016 à 19:21 | 1 commentaire | ]

DNS 1: Dynamic DNS

Traduction: [ Google | Babelfish ]

Catégories : [ Informatique ]

Now that I have my own server, I can finally have my own DNS server and my own domain name for my home computer that has a (single) dynamic IP address.

The following notes assumes there is already a running instance of Bind 9 on a Debian Jessie system for an imaginary domain example.com, served by a name server named ns.example.com and you want to dynamically update the DNS records for home.example.com. This is largely based on the Debian tutorial on the subject, solving the problem that bind cannot modify files in /etc/bind.

On the server

Create a shared key that will allow to remotely update the dynamic zone:
dnssec-keygen -a HMAC-MD5 -b 128 -r /dev/urandom -n USER DDNS_UPDATE
This creates a pair of files (.key and .private) with names starting with Kddns_update.+157+. Look for the value of Key: entry in the .private file and put that value in a file named /etc/bind/ddns.key with the following content (surrounding it with double quotes):
key DDNS_UPDATE {
        algorithm HMAC-MD5.SIG-ALG.REG.INT;
        secret "THIS IS WHERE YOU PUT THE KEY";
};

You can then delete the two Kddns_update.+157+ files. Ensure that /etc/bind/ddns.key belongs to "root" and to the "bind" group, and is not readable by other users.

Then in named.conf.local, include the key file and declare a new zone:

include "/etc/bind/ddns.key";

zone "home.example.com" { type master; file "/var/cache/bind/db.home.example.com"; allow-update { key DDNS_UPDATE; }; journal "/var/cache/bind/db.home.example.com.jnl"; };

In /var/cache/bind create the file db.home.example.com by copying /etc/bind/db.empty and adapting it to your needs. For convinience, create a db.home.example.com symbolic link in /etc/bind pointing to /var/cache/bind/db.home.example.com.

In db.example.com (that is, the parent zone), add a NS entry to delegate the name home.example.com to the DNS server of the parent zone:
home.example.com NS ns.example.com

You can now reload the bind service to apply the configuration changes.

I also found examples of how to test the dynamic zone with nsupdate.

On the home computer

I decided to use ddclient 3.8.3 because it supports dynamic dns updates using the nsupdate tool. I backported that version of ddclient manually from a Debian Testing package; it's written in Perl and the backporting is trivial.

Copy /etc/bind/ddns.key from the server to /etc/ddns.key on the home computer (the one running ddclient), ensuring only root can read it. Then add the following to /etc/ddclient.conf (be careful with the commas, there is no comma at the end of the second last line):
protocol=nsupdate, \
zone=home.example.com, \
ttl=600, \
server=THE_IP_ADDRESS_OF_THE_DNS_SERVER, \
password=/etc/ddns.key \
home.example.com

You can then try out the new setup.

[ Posté le 27 avril 2016 à 18:15 | 1 commentaire | ]

Mercredi, 13 avril 2016

Minimum Password Entropy

Traduction: [ Google | Babelfish ]

Catégories : [ Informatique ]

What is the minimum entropy for my home computer's password?

In recent (post-2007) Debian (and probably other) Linux distributions, the passwords are stored in /etc/shadow using the sha512crypt algorithm. According to Per Thorsheim, with 2012 hardware, a single Nvidia GTX 580 could make 11,400 attempts at brute-force cracking such a password. This means that a log2 11,400 = 13.5 bit password could be cracked in 1 second.

To have a password that would resist a year to such a brute-force attack, one must multiply the password complexity by 86,400×365 (seconds per year) i.e., add 24.5 bits to the password for a total of 38 bits.

But this password is guaranteed to be cracked in a year. To make the probability of cracking such a password much lower, let's say less than 0.01, one must increase the password's complexity by a hundred times i.e., add 6.7 bits. We now have a minimum of 44.7 bits.

If one does not want to change the password for the next 10 years (because one is lazy), one must again increase the complexity tenfold (that's another 3.3 bits for a total of 48 bits) and account for the increase in processing power in the coming years. Between 2002 and 2011, CPU and GPU computing power has been multiplied by 10 and 100 respectively i.e., +0.37 and +0.74 bits/year. That means that the password's complexity must be increased by 0.74 ×10 = 7.4 bits. We have now reached 55.4 bits.

Now we need to guess who are the password crackers. How many such GPU will they put together? Titan has 18,688 GPUs (add another 14.2 bits to stay ahead of it), and the (more affordable) machine that cracked LinkedIn leaked passwords had 25 GPUs (requiring to add only extra 4.6 bits).

Assuming the crackers have a 25-GPU setup and not a gigantic cluster, 60 bits should be perfectly safe. If they are a government agency with huge resources and your data is worth spending the entirety of that cluster's energy for 10 years, 70 bits is still enough.

The same article also mentions an Intel i7, 6-core CPU would make 1,800 attempts per second i.e., 10.8 bits. For a password that must resist for 10 years, that would mean 49 bits. Titan has 300,000 CPU cores (50,000 times more than the i7), so that makes an extra 15.6 bits for a total of 64.6 bits. The Tianhe-2 has 3,120,000 cores, adding 19 bits to the original 49 bits, leading to 68 bits total.

In summary, 70 bits is enough. If you are lazy and not paranoid, 60 bits are still enough. If you think the crackers will not use more than 32 i7 CPUs for a month to try and break your password (adding 2.4 + 21.3 bits to the original 10.2 bits), 48.5 bits are still enough.

[ Posté le 13 avril 2016 à 19:20 | pas de commentaire | ]