Archive for August, 2008

Penetration Test != Audit != Assessment

August 19, 2008

If someone is selling you a network penetration test, and then running a vulnerability scanner and handing you a report, you’re not getting what you paid for, period.



Formal Degrees vs. Certification

August 18, 2008

I’ve never been a fan of most certifications.  I’ve always been even less a fan of formal degrees in education, at least for technology-centric industries.  I’ve always argued that my body of work is my credential, and if a potential employer were to reject my application on the basis that I didn’t have a certain piece of paper, that short-sighted employer wasn’t the type that I wanted to work for anyway.

This article, however, goes even further to suggest that College is a waste of time for an even larger group of people than just the technology-centric industries, and hints at what certifications can accomplish, given that they evolve past most of my objections with them, which are echoed throughout the article.



August 14, 2008

DEFCON is always entertaining as it’s the largest hacker conference in North America. Back to back with it’s corporate counterpart, Black Hat, it generally draws thousands of hacker-type people to Las Vegas every summer. The related parties, shenanigans, and drama surrounding it are legendary, and this year was no different.

Below are my thoughts on the talks I was able to attend.


Configuring DNSSEC in BIND

August 1, 2008

DNSSEC, which I mentioned in my previous post about mitigation for Kaminsky’s recent DNS cache poisoning flaw, are the SECurity extensions for the Domain Name System (DNS). It essentially adds cryptography to DNS, allowing authoritative nameservers to cryptographically sign their zones and resource records, which in turn allows caching/recursive nameservers to verify them. This prevents attacks against the recent cache poisoning flaw by allowing the nameserver under attack to verify that a record it receives is valid by checking the cryptographic signature against the zone’s public key. Theoretically, an attacker would not be able to forge this signature unless the zone’s keys have been compromised.

I’ve spent a bit of time over the past few days researching DNSSEC, as it’s been standardized for nearly a decade now but there hasn’t been much adoption. It’s most likely The Best™ solution for the recent vulnerability, but I’ve heard time and again that it’s too complicated and has too many controversial issues surrounding it which is why many admins haven’t adopted it into their infrastructure and still don’t plan to.

During this research, I’ve configured all of my nameservers to use  DNSSEC, both authoritative and caching/recursive. While it is a bit of a pain on the authoritative side having to deal with signature expiration, key rotation, proving your identity and ownership of the zone to a domain lookaside verification (DLV) registry and providing your DLV records, etc., configuration for caching/recursive nameservers was relatively straight-forward and simple. While this will obviously only protect you from accepting spoofed, poisoned cache entries for records within zones using DNSSEC, why would you not want to at least verify signatures for those zones that do provide them?