DNS Workshop
Fixing BIND 9.9.0 compilation on OpenBSD
Compiling the new BIND Version 9.9.0 can lead to an compilation error on systems that do not have the ENOTSUP constant defined (such as OpenBSD).
stdio.c: In function `isc_stdio_sync': stdio.c:117: error: `ENOTSUP' undeclared (first use in this function) stdio.c:117: error: (Each undeclared identifier is reported only once stdio.c:117: error: for each function it appears in.) *** Error code 1 Stop in /usr/src/bind-9.9.0/lib/isc/unix. *** Error code 1 Stop in /usr/src/bind-9.9.0/lib/isc (line 174 of Makefile). *** Error code 1 Stop in /usr/src/bind-9.9.0/lib (line 103 of Makefile). *** Error code 1 Stop in /usr/src/bind-9.9.0 (line 107 of Makefile).
ISC has already applied a patch that will be out with the next version(s). For all that want to compile and run BIND 9.9.0 now, below is a patch that works for me:
*** /usr/src/bind-9.9.0/lib/isc/include/isc/stdio.h.orig Wed Feb 29 21:04:43 2012 --- /usr/src/bind-9.9.0/lib/isc/include/isc/stdio.h Wed Feb 29 21:05:34 2012 *************** *** 22,27 **** --- 22,32 ---- /*! \file isc/stdio.h */ + /* OpenBSD doesn't have ENOTSUP, but does have EOPNOTSUPP */ + #if defined (EOPNOTSUPP) && !defined (ENOTSUP) + #define ENOTSUP EOPNOTSUPP + #endif + /*% * These functions are wrappers around the corresponding stdio functions. *
Posted at 07:32AM Mar 01, 2012 by Carsten in Servers | Comments[0]
Unbound & DNSSEC-Trigger Workshop at Augsburger Linutage
Workshop: secure DNS using Unbound and DNSSEC-Trigger
I will give a free workshop at the Augsburger Linux Infotage on Saturday, 24th March 2012 (http://www.luga.de/Aktionen/LIT-2012/Programm), on installing and using Unbound together with the new DNSSEC-Trigger tool.
Goal of this workshop is to learn about the security issues with plain DNS, how DNSSEC can help and how to deploy Unbound as a local DNSSEC validating DNS resolver to secure the personal mobile computer (laptop, netbook ...).
Please bring your own machine (WiFi required) to the workshop room "D", 11:00-13:00, pre-installed with either a flavor of Linux, MacOS X or Windows (Vista or newer, don't pretend to secure a XP machine). We will install Unbound and DNSSEC trigger during the workshop and learn some troubleshooting tricks on the way.
Posted at 01:59AM Feb 20, 2012 by Carsten in Conferences | Comments[0]
Give nsupdate a history
the useful nsupdate tool (used to send dynamic updates towards an authoritative DNS server, part of the BIND nameserver distribution, www.isc.org) does not have a commandline history, nor automatic command completion.
Luckily, on Unix systems, this missing feature can be added to nsupdate using a small tool called rlwrap. rlwrap stands for 'readline wrapper'. Readline is an open source library that implements command history and tab completion, and it is used inside many well known command line tools. However it needs to be linked at compile time to be work on a program by default. If the developer does not link readline, the functions are not part of the program.
However it is possible to start a commandline tool such as nsupdate under the control of the readline wrapper. In this case, the readline wrapper will intercept when the command line tool tries to read data from the keyboard and will add the additional readline functions to the command line tool. rlwrap is part of most Unix/Linux distributions and can often be installed using the systems package manager.
In case of nsupdate, we can start nsupdate with
$ rlwrap nsupdate
and voila, our old dog nsupdate has just learned some new tricks, it has now a command history that can be used with the cursor up and down keys (see the readline man page for a complete list of possible key bindings).
If rlwrap finds a file (named with the name of the commandline tool) containing keywords (space separated) in its search path for completion files (on my system that is /usr/share/rlwrap/completions), it will auto-complete the keywords found in the file when the user presses the tabulator key. Please find attached to this blogpost my completion file for nsupdate.
I don't not want to encourage the usage of nslookup (use dig or drill), but rewrap works also on the old steam engine called nslookup.
Please have a look at the rlwrap manual page. There are some more tricks to rlwrap that are not mentioned in this blog post.
Attachments
- rlwrap completion file for nsupdate (rename to nsupdate-completions.zip after download)
Posted at 08:03AM Jan 11, 2012 by Carsten in Servers | Comments[3]
Take your DNSSEC with a grain of salt
DNSSEC has many useful properties. One is called 'Authenticated denial of existence'. This basically means that a DNSSEC validating DNS Server can prove that domain-names and resource records do not exist in the DNS.
But how does NSEC and NSEC3 work. And how to choose good values for NSEC3 salt and iterations?
Posted at 04:24PM Dec 30, 2011 by Carsten in Protocol | Comments[4]
BIND installer packages for MacOS X 10.4/10.5 PowerPC (ppc)
Apple does not provide update to older MacOS X versions (such as 10.4 "Tiger") anymore. However these machines are still good to run a caching or an authoritative DNS Server.
MacOS X comes with ISC BIND pre-installed, but without security updates, running an old version of BIND on MacOS X is a risk.
To find out the current version of BIND installed on a machine, open the Terminal.app and enter "named -v":
$ named -v BIND 9.4.2-P2
Men & Mice is offering installation packages for MacOS X 10.4 containing the latest BIND versions. The installer packages can be downloaded for free from http://support.menandmice.com/download/bind/macosx/10.4-Tiger/.
If you are running a BIND DNS Server on MacOS X, please check the version you're running and upgrade if the version if outdated. The BIND security matrix lists all known security issues with BIND versions.
Posted at 04:15PM Dec 23, 2011 by Carsten in Servers | Comments[0]
Compiler options for creating secure DNS Server binaries (on Linux)
DNS server, as these processes recieving data from untrusted sources in the network, are vulnerable for attacks that exploit security proplems in the DNS servers program code. Special crafted DNS packets can trigger a software bug in the DNS servers code and which will execute code contained in the received data, allowing the attacker to change the behavior of the DNS software or even break into the operating system running the server.
Modern Linux systems contain exploit mitigation techniques that make it harder for attackers to sucessfully launch such attack. However most of this functions are not enabled by default, but must be enabled during compile time. This is especially imnportant if the DNS server software is custom compiled and not taken from the Linux distribution vendor. But even the binaries supplied by a Linux distribution might not have all the exploit mitigation security functions enabled.
The folks at NESO Security Labs have published a script that can be used to test existing binaries for the enabled security functions (checksec.sh script).
The screenshot below shows a BIND nameserver binary (named) with only some of the security functions enabled, and an Unbound nameserver binary that has all of the functions enabled:
The functions in detail:
RELRO
RELRO rearranges the data sections inside an ELF (Linux executable file format) executable. It also marks certain areas as 'read-only' so that these data structures cannot be overwritten while the process is running.
Details about RELRO can be found in the blog post RELRO - A (not so well known) Memory Corruption Mitigation Technique.
There are two flavors of RELRO, 'partial' and 'full'. Only 'full RELRO' offers all security measures and is recommended.
Stack canary
A STACK CANARY is a special datastructure with a distinct bit-pattern that is placed in front of important data on the stack, for example in front of the return address of an subroutine call. A popular attack is to overwrite (using a buffer overflow or similar problems) the return address of a subroutine call, so that the execution process is redirected to execute program code injected by the attacker.
When using a stack canary, the operating system will check if the bit pattern placed in front of the stack datastructure is still intact (and not overwritten). Only if this is true, the jump through the return address will be taken. The named 'stack canary' comes from canary birds used in early mining operations, where the birds where used as in indicator that the air under ground is becoming foul. See GCC Stack-Smashing Protector (ProPolice) on how the canary is implemented in the GCC compiler suite.
NX bit
NX enabled refers to the NX (non-execute) or XD (execute disable) flags found
in modern x86 CPUs (Intel and AMD). The NX flag are used to mark memory areas
that only contain data (and no program code) as 'off-limit' for the CPUs
instruction fetch. The data stored in this areas marked cannot be executed
as a program by the CPU. Because this flag is implemented directly in the CPU,
it has no overhead compared to exploit mitigation functions implemented in
software. Some Linux systems running on hardware that does not support
a 'no-execute' flag emulate this function in software.
See Wikipedia on NX bit.
PIE - Position independent code
PIE stands for 'Position Independent Executable' and describes a function where the operating system can load certain parts of the application at random positions inside the computers address space. In some attacks the attacker needs to know beforehand on which memory location a datastructure will be loaded (e.g. to jump into code that has been written using a buffer overflow). By having the operating system load the program code into different locations every time, the attacker cannot predict the memory location, which makes it harder to write a sucessful exploit.
Fortify source
In addition to the technologies above, the GCC C-Compiler can analyse the source code to be compiled and detect certain insecure sections (that might create a security problem). The compiler will replace the insecure function calls with special hardened code that will perform extra runtime checks while the process is executed. This is called FORTIFY SOURCE.
Compiler- and Linker-Flags
To enable these exploit mitigation functions in compiled binaries, special flags must be specified for the compiler (gcc) and linker.
- RELRO: LDLFAGS="-z relro -z now"
- STACK CANARY: CFLAGS="-fstack-protector" LDFLAGS="-fstack-protector"
- PIE/PIC: CFLAGS="-fPIE -fPIC" LDFLAGS="-fPIC -pie"
- NX: is enabled on the OS and BIOS level, but can be disabled in the ELF file. It should be enabled by default if not manually disabled for a binary.
- FORTHFY-SOURCE: CFLAGS="-O2 -D_FORTIFY_SOURCE=2"
Examples
example linker flags (32bit/64bit):
LDFLAGS="$LDFLAGS -fPIC -pie -z relro -z now -fstack-protector"
example c-compiler flags (32bit):
CFLAGS="-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector -fPIE -fPIC --param=ssp-buffer-size=4 -m32 -march=i686 -mtune=i686 -fasynchronous-unwind-tables"
example c-compiler flags (64 bit):
CFLAGS="-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector -fPIE -fPIC --param=ssp-buffer-size=4 -m64 -mtune=generic"
Of course the exploit mitigation techniques described here are also valid for all networked applicartions (such as SSH, webserver, NTP ...), not only for DNS server. But this is the DNS workshop ...
Resources:
- NX bit
- Security features in Ubuntu Linux
- Debian Hardining
- Basics of stack-smashing attacks and defenses against them
- Position Independent Code internals
- Buffer overflow and you
- Protections against buffer overflow
- Disabling the NX bit for specific apps
- Linux PAX security extension
Posted at 01:02PM Jul 03, 2011 by Carsten in Servers | Comments[1]
RIPE E-Learning module 2 - DNS Vulnerabilities and the 'Kaminsky attack'
The RIPE Training team has released a new eLearning course on DNS Vulnerabilities and the 'Kaminsky attack'. The course can be found at http://www.ripe.net/lir-services/training/e-learning/dnssec/dns-vulnerabilities (requires flash).
This new module explains DNS 'man-in-the-middle' attacks as well as the 'Kaminsky style' cache poisoning attacks.
Posted at 10:56AM Mar 16, 2011 by Carsten in General | Comments[0]
Configure DLV (DNSSEC Lookaside Validation) for Unbound
Not all ccTLD (Country Code Top Level Domains) ot gTLD (generic Top Level Domains) are DNSSEC signed (Status 2/2011). Domains below these unsigned TLDs are not in the 'Chain of Trust', even if they are DNSSEC signed, they cannot be validated.
Internet Software Consortium (ISC) runs a service called DLV (DNSSEC Lookaside Validation, RFC 5074). The DLV contains many trust anchors for DNS domains that are signed, but cannot be validated from the root zone down.
Instead of maintaining each trust-anchor in each validating DNS Servers configuration file, the DLV registry will contain the trust-anchors for the zones and the local validating DNS Server only needs to have one trust-anchor for the DLV zone.
A DLV registry functions like a database of trusted keys. In practice, it's a zone containing DLV records, which are functionally similar to DS records. Only one trust anchor is needed in the resolver config, to validate the DLV zone. The DLV records then validate other zones' public keys, just like DS records. Multiple DLV registries are possible, but there's one main one: dlv.isc.org. BIND 9.7+ and Unbound 1.4.1 ship with a trusted initial key for this DLV registry.
Because ISCs DLV zone is below "isc.org." and "org.", which are both signed, the trusted key can also be fetched by a validated DNS query (the resolving DNS Server must have DNSSEC and the trust-anchor for the root-zone configured:
dig dlv.isc.org. dnskey +dnssec +multi
; <<>> DiG 9.8.0rc1 <<>> dlv.isc.org. dnskey +dnssec +multi
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 50425
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;dlv.isc.org. IN DNSKEY
;; ANSWER SECTION:
dlv.isc.org. 676 IN DNSKEY 256 3 5 (
BEAAAAOlYGw53D+f01yCL5JsP0SB6EjYrnd0JYRBooAa
GPT+Q0kpiN+7GviFh+nIazoB8e2Yv7mupgqkmIjObdcb
GstYpUltdECdNpNmBvASKB9SBdtGeRvXXpORi3Qyxb9k
HGG7SpzyYbc+KDVKnzYHB94pvqu3ZZpPFPBFtCibp/mk
hw==
) ; key id = 64263
dlv.isc.org. 676 IN DNSKEY 257 3 5 (
BEAAAAPHMu/5onzrEE7z1egmhg/WPO0+juoZrW3euWEn
4MxDCE1+lLy2brhQv5rN32RKtMzX6Mj70jdzeND4XknW
58dnJNPCxn8+jAGl2FZLK8t+1uq4W+nnA3qO2+DL+k6B
D4mewMLbIYFwe0PG73Te9fZ2kJb56dhgMde5ymX4BI/o
Q+cAK50/xvJv00Frf8kw6ucMTwFlgPe+jnGxPPEmHAte
/URkY62ZfkLoBAADLHQ9IrS2tryAe7mbBZVcOwIeU/Rw
/mRx/vwwMCTgNboMQKtUdvNXDrYJDSHZws3xiRXF1Rf+
al9UmZfSav/4NWLKjHzpT59k/VStTDN0YUuWrBNh
) ; key id = 19297
dlv.isc.org. 676 IN RRSIG DNSKEY 5 3 7200 20110321090006 (
20110219090006 19297 dlv.isc.org.
MXYbzeUU+x2F1sx/5gXUFJI6np/0svU5emAaQunG5lCO
S0Hcb8QoLYaSMxy+2R38smaH7EVTPbst8gYX7t1NousC
yb02kDHOei3qioRN/LyWd7qeJPCneu/MO1xjul5PCqmV
yUlnj/5KRj3elYsdo5x5DE2D+s8ivnZBNXzAZU0EQ+pi
tt4DFVNMNqEmqwM/q/GMZ2px3VlHKMoelxpgXHK+WeDI
/19UwzuUJ6ykCa+PS9biVsCQTr+5jHnUKU/dNH7lDmfS
rdGnaZrDu+T2RoNWxM6FjqjVmJhFss/PbFgYj1xbJbjj
XX0ZBGqUEHUBfe6wOnx2jRqSvTt/RnOJTw== )
dlv.isc.org. 676 IN RRSIG DNSKEY 5 3 7200 20110321090006 (
20110219090006 64263 dlv.isc.org.
EnX0YVax8Aosb51CW13V0+V1PrvLzpe19r5PsTje7le7
N+woHkDmMDy/yPnGDbGE1Vu0Z8sh2RenhAYkUMEpboV2
jXMIhiO08FQzcvUgiZuAuDkxtYLgkHCTKBXBRKJtS0fC
QYEFA2NTCYyPviEtirXpuPg9u2BoAYCdlizUaKk= )
;; Query time: 2 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Sat Feb 19 13:33:01 2011
;; MSG SIZE rcvd: 936
Check for the "AD" flag in the DNS query (AD = Authenticated Data).
For Unbound, we need the DNSKEY record (the public key) for the Key Signing Key (KSK) of the DLV Zone. A KSK DNSKEY Record has the secure entry point flag set in the flags field, so the first field has the value "257".
We copy the line containing the KSK DNSKEY record into a file called "dlv.isc.org.key", and add the line
dlv-anchor-file: "dlv.isc.org.key"
to the Unbound configuration file "unbound.conf".
A validating Resolver with DLV configured will first...
- look if there are manual trust-anchors in the configuration
- if that is not available, it will try to get the trust from the delegation tree (DS record in the parent zone)
- if that is also not available, it will try to look up the trust-anchor in the DLV zone(s) ...
- If there is more than one DLV zone configured that will match the target name (overlapping DLV domains)
- The resolver will first try the DLV zone with the most matching labels (most specific domain), then trying the others with shorter matching labels (DLV for ?europe.company.example?, will 1st look in DLV for ?company.example?, then in DLV Zone for ?example? and then for ?.?)
- The same behavior is used for finding DLV trust anchors in a DLV zone
Because DNSSEC validation using the parent has priority over DLV, once the parent of the zone is signed, validation is done using the DS records in the parent and not using DLV.
Information about the ISC DLV registry can be found at https://dlv.isc.org/
Posted at 01:20PM Feb 19, 2011 by Carsten in Resolvers | Comments[0]
Slax Live Linux modules with BIND, Unbound and DNS Tools for DNSSEC Training
Getting a classroom full of computer ready for a DNSSEC training can be a challenge. Installing a DNSSEC capable DNS server, resolver and troubleshooting tools on each student computer can take some time. DNSSEC tools are not common in today's operating-systems.
At Men & Mice we use add-on modules for the SLAX Live Linux System (http://slax.org). The SLAX System can be started on almost any PC-like computer machine with 256MB RAM or more from a USB-Stick, CD-ROM or by PXE Network boot. Especially the PXE-Networkboot is a convenient way to boot SLAX from the trainers PC to all the machines in a classroom. The trainer can prepare training packages that will automatically appear after reboot on the students machines.
The current version of the SLAX DNSSEC Training modules contains BIND 9.6.1-P1 (package 010-bind.lzm) and Unbound 1.33, libDNS 1.6.1, Drill, DNSTOP, DOC and dnstracer (package 011-dnstools.lzm) ready to use.
The single packages can be downloaded from the Men & Mice Support Download Server.
The full SLAX 6.1.2 system including the DNS-Tools and BIND packages can be found at http://support.menandmice.com/download/training/usb/slax-dns-training-stick.tgz (217 MB).
To install SLAX from a Linux Machine, uncompress the tar-ball to an FAT formatted USB Drive and call the "boot/bootinst.sh" script. Installation from a Windows System is similar, just used the "boot/bootinst.bat" batch file.
While being created for DNSSEC and DNS Trainings, the SLAX system with the DNS Modules makes a quick-to-use troubleshooting system for both plain old DNS and DNSSEC that can be carried around.
Posted at 09:12PM Aug 21, 2009 by Carsten in Servers | Comments[0]
RIPE eLearning Course - DNS Basics
 |
The RIPE NCC eLearning Centre has released the first of a series of free DNS and DNSSEC Training courses. The courses are self-paced with nice animations.
The service is free of charge and can be found at https://e-learning.ripe.net/training/e-learning/
In the coming months more e-learning modules will be released covering the topics "DNS Vulnerabilities" and "DNSSEC".
|
Posted at 10:32AM May 19, 2009 by Carsten in General | Comments[0]
Notes from DNS Working Group at RIPE 58, Part 1
|
My notes from the RIPE 58 DNS Workinggroup (DNS-WG) sessions:
|
Posted at 12:37PM May 11, 2009 by Carsten in Conferences | Comments[0]
BIND 10 development started
The Internet Systems Consortium announced today that development on the next generation of BIND DNS Server has started. The new development is sponsored by many TLD-Registries (Japan Registry Services Co., Ltd. (JPRS) and Canadian Internet Registration Authority (CIRA) as well as Afilias, AFNIC, DENIC, IIS.SE, Nominet, NIC.br, SIDN and .za Domain Name Authority) and will take some years to complete.[Read More]
Posted at 06:03PM Apr 23, 2009 by Carsten in Servers | Comments[0]
