Mercredi, 27 avril 2016

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.

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.

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.

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):

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.

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):

Mercredi, 13 avril 2016

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.