These URLs exposed me to the amazing complexity in pollen, plants, insects, and bacteria. Additionally their interactions and communications are dramatically more complex than I expected.
In the first video the amazing complexity of pollen and how that can be used to learn more about the world and the history of objects within it:
Jonathan Drori: Every pollen grain has a story
This one builds on the first (the first 2 minutes are a review) and gets into the amazing diversity, complexity, co-evolution, and deception in the plant world:
Jonathan Drori: The beautiful tricks of flowers
This one shows just how dynamic and complex the interactions plants are with each other and insects. Including chemical warfare against parasites as well as sending out signals to call in predators:
Sorry, Vegans: Brussels Sprouts Like to Live, Too
Meet the stealth bombers of the ocean and get exposed to how bacteria communicate both within and across species. Bacteria have many adaptive behaviors for defense, propagation, and attack that they coordinated within species. Bonnie Bassler on how bacteria "talk"
I hope you enjoy them.
Friday, August 12, 2011
Why DNSSEC?
DNS is critical internet infrastructure. While security steps have been taken to make DNS attacks harder (mostly not accepting records you didn't ask for and source port randomization) DNS Is still a high value target.
While SSL does provide some projection for websites, all but a very small percentage of the most careful users will miss a http to https handoff to a openssl verified website with a small typo in it.
In an ideal world the combination of protections against cache poisoning and source port randomization makes a DNS attack very difficult, around 1 in 4 billion (2^32 actually). Many things can go wrong, for instance it's not uncommon for home routers running NAT to take the very carefully random source port and rewrite it to a predictable port. If the source port can be predicted then the odds drop to 1 in 65,535. Of course a successful man in the middle (MitM) attack makes DNS a convenient way for an attacker to siphon out only the parts he wants (like a login) while making it much harder to detect since all the rest of the traffic look completely normal.
Thus for good end to end protection DNSSEC is a good step in the right direction. If interested please see my other DNSSEC posts for how to fix a (linux, OSX, or Windows) client or bind based DNS server.
While SSL does provide some projection for websites, all but a very small percentage of the most careful users will miss a http to https handoff to a openssl verified website with a small typo in it.
In an ideal world the combination of protections against cache poisoning and source port randomization makes a DNS attack very difficult, around 1 in 4 billion (2^32 actually). Many things can go wrong, for instance it's not uncommon for home routers running NAT to take the very carefully random source port and rewrite it to a predictable port. If the source port can be predicted then the odds drop to 1 in 65,535. Of course a successful man in the middle (MitM) attack makes DNS a convenient way for an attacker to siphon out only the parts he wants (like a login) while making it much harder to detect since all the rest of the traffic look completely normal.
Thus for good end to end protection DNSSEC is a good step in the right direction. If interested please see my other DNSSEC posts for how to fix a (linux, OSX, or Windows) client or bind based DNS server.
Tuesday, August 9, 2011
Protecting a domain with Bind, DNSSEC and dyndns.com
Prerequistes:
1) a working bind nameserver
2) A DNSSEC friendly registrar like dyndns.com
3) A domain, I'll use example.com for documentation purposes.
Once you have a domain example.org stored in a file db.example.org run these commands:
1. Create your key signing key (KSK). DNSKEY 257 inside the resulting key file indicates it's a KSK. Note the name of the produced KSK file for future commands:
2. Create your zone signing key (ZSK). DNSKEY 256 inside the resulting key file indicates it's a ZSK. Note the name of the produced ZSK file for future commands:
3. Create a DS key for uploading to your registrar/dyndns.com:
4. Include the keys in your zone, append these two lines to db.example.com:
5. Sign the zone, note this has to be done at least monthly:
6. Turn on dnssec in bind, usually in /etc/bind/named.conf.options, add (or uncomment) "dnssec-enable yes" and "dnssec-validation yes".
7. Copy the resulting db.example.org.signed to where ever bind previously got the zone from and run:
8. To check run (assuming a dnssec aware client):
9. Update your registrar with the DS key.
Login to your registrar, dyndns.com for this example.
Go to the "My zones/Domains"
Click on the domain to manage.
Click on "Create New DS Record"
Fill out the form with:
New Key Tag = 5 Digit number from the filename of your KSK.
DNSKEY Alg = RSA/SHA-1
Digest Type = SHA-256
Digest Value = cut/paste the 56 hex digits from the 7th column of dskey.key
10. This may take awhile to propagate. Once propagated you can check again with from any DNSSEC aware client (see other posts tagged with DNSSEC) with:
11. Implement a plan to update the serial number and resign the zone before the key expires (somewhere around 28 days). Your DNS will disappear to all DNSSEC aware clients if your key expires. I believe OSX clients are DNSSEC aware by default.
Now the rest of the world will be able to securely lookup your DNS records. Besides the obvious benefits this makes secondary uses of DNS such as SPF, DKIM, and SSH host keys more secure. SSH will not accept host keys without user intervention unless they are DNSSEC protected.
1) a working bind nameserver
2) A DNSSEC friendly registrar like dyndns.com
3) A domain, I'll use example.com for documentation purposes.
Once you have a domain example.org stored in a file db.example.org run these commands:
1. Create your key signing key (KSK). DNSKEY 257 inside the resulting key file indicates it's a KSK. Note the name of the produced KSK file for future commands:
$ dnssec-keygen -r /dev/random -f KSK -a RSASHA1 -b 2048 -n ZONE example.org
2. Create your zone signing key (ZSK). DNSKEY 256 inside the resulting key file indicates it's a ZSK. Note the name of the produced ZSK file for future commands:
$ dnssec-keygen -r /dev/random -a RSASHA1 -b 1024 -n ZONE example.org
3. Create a DS key for uploading to your registrar/dyndns.com:
$ dnssec-dsfromkey -a sha-256 Kexample.org.+<rest of KSK filename> > dskey.key
4. Include the keys in your zone, append these two lines to db.example.com:
$INCLUDE Kexample.org.+<rest of KSK filename> $INCLUDE Kexample.org.+<rest of ZSK filename>
5. Sign the zone, note this has to be done at least monthly:
$ dnssec-signzone -r /dev/random -o example.org -k Kexample.org.+<rest of KSK filename> db.example.org Kexample.org.+<rest of ZSK filename>
6. Turn on dnssec in bind, usually in /etc/bind/named.conf.options, add (or uncomment) "dnssec-enable yes" and "dnssec-validation yes".
7. Copy the resulting db.example.org.signed to where ever bind previously got the zone from and run:
rndc reload
8. To check run (assuming a dnssec aware client):
dig @<ip of your nameserver> example.com +dnssec | grep flags | head -1 ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 3, ADDITIONAL: 5
9. Update your registrar with the DS key.
Login to your registrar, dyndns.com for this example.
Go to the "My zones/Domains"
Click on the domain to manage.
Click on "Create New DS Record"
Fill out the form with:
New Key Tag = 5 Digit number from the filename of your KSK.
DNSKEY Alg = RSA/SHA-1
Digest Type = SHA-256
Digest Value = cut/paste the 56 hex digits from the 7th column of dskey.key
10. This may take awhile to propagate. Once propagated you can check again with from any DNSSEC aware client (see other posts tagged with DNSSEC) with:
$ dig @localhost example.com +dnssec | grep flags | head -1 ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 3, ADDITIONAL: 5
11. Implement a plan to update the serial number and resign the zone before the key expires (somewhere around 28 days). Your DNS will disappear to all DNSSEC aware clients if your key expires. I believe OSX clients are DNSSEC aware by default.
Now the rest of the world will be able to securely lookup your DNS records. Besides the obvious benefits this makes secondary uses of DNS such as SPF, DKIM, and SSH host keys more secure. SSH will not accept host keys without user intervention unless they are DNSSEC protected.
Improving DNS on linux laptops/desktops.
I've had various problems with OpenDNS, Pacbell, and Comcast's DNS servers. Lying about missing (or mispelled) domains, poor performance and outages. Despite a fast internet connection, I often noticed the slowest part of viewing a web page was the DNS lookup.
Of course if you are going to fix it, you might as fix it right. I recommend something with DNSSEC support, caching, and prefetching. The best I've found so far is unbound. So I recommend:
1) aptitude/yum install unbound
2) edit /etc/unbound.conf
a) change prefetch and prefetch-key to yes
b) If you want to use a DLV for those domains whose IT/ISP don't support DNSSEC update the dlv-anchor-file. More info at Wikipedias DLV entry
c) uncomment auto-trust-anchor-file: "/etc/unbound/root.key"
d) I set threads to 2
3) run unbound-anchor to update the DNSSEC root key.
4) To test look for the ad flag with the following command.
$ dig @localhost com. SOA +dnssec | grep flags | head -1 ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 14, ADDITIONAL: 1
5) Update /etc/resolv.conf with nameserver 127.0.0.1
6) If running dhclient
a) add/uncomment "prepend domain-name-servers 127.0.0.1;" in /etc/dhclient.conf
b) remove "domain-name-servers" from the request line in /etc/dhclient.conf
c) create a file in /etc/dhcp/dhclient-exit-hooks.d with the following in it:
6) If running dhclient
a) add/uncomment "prepend domain-name-servers 127.0.0.1;" in /etc/dhclient.conf
b) remove "domain-name-servers" from the request line in /etc/dhclient.conf
c) create a file in /etc/dhcp/dhclient-exit-hooks.d with the following in it:
echo "options edns0" >> /etc/resolv.confd) In ~/.ssh/config (per user config file) or /etc/ssh/ssh_config (global config file) add:
#until ssh-keygen and related tools get updated we can't do ecdsa keys HostKeyAlgorithms=ssh-rsa,ssh-dss VerifyHostKeyDNS yes StrictHostKeyChecking yes Host *.* Hostname %h Host * hostname %h.cse.ucdavis.edu
Enjoy faster and more secure DNS. DNSSEC also improves the functionality of putting SSH keys in DNS and lets people have more confidence in your SPF/DKIM records if you run a mail server.
Subscribe to:
Comments (Atom)