Wednesday, September 26, 2007

(IN)Secure Mag - 13th Edition


Just a quick heads up to point out that the 13th issue of (IN)Secure mag is out. There is another bit on PCI Compliance and a piece on automated log management for HIPAA compliance in this issue that look fairly interesting. This mag is usually a pretty good read and I recommend you check it out!

Friday, September 21, 2007

GAUS 1.5 - New Features/ Bugfixes

A couple bugfixes and a few more features have been added to the Gentoo Auto-Update Script. The new features include:

  • Convenient variable enabling/disabling of functions to eliminate the tedious need to un-comment desired sections
  • Optional cleanup of /tmp directory
  • Listing of all files on the system larger than a predetermined size
  • A GAUS project wiki page


The GAUS script can be downloaded from Google Code. Please review the README.txt file for complete list of changes/ bugfixes and additional information.

Additionally, please note that due to limitations in the Google Code system, I've had to re-engineer the way GAUS self update checking works. Users of version 1.4 will not be automatically notified that version 1.5 is now available. This should be now corrected going forward.

Labels: , , ,

Tuesday, September 11, 2007

Monkey-House survives to Thailand

I'm happy to report that I once again survived my trip to Thailand. I deftly maneuvered myself through buckets of booze (pictured on left), hordes of hungry temple monkeys (below), and crazy drunken taxi drivers (something you don't want to see). In the process I managed to meet some great people, make several fantastic contacts, and might even end up with a couple of job offers after all!


Additionally, I have an update on my previous report regarding Thailand's Internet Filtering. There is a blog, FACT - Freedom Against Censorship Thailand, dedicated to the dissemination of information regarding Thailand's filtering. (Thanks Ed!) One of the interesting things they provide, is the secret block list compiled by MICT and pushed down to all of the ISPs in Thailand.

Basic DNS Auditing


I seem to run across alot of security consultants and professionals that just don't seem to have a basic understanding of DNS and what sort of basic things to look for when performing an audit. I previously posted a high level guide on DNS best practices, so this posting is meant to demonstrate the technical methods for checking some of these things. This guide only provides a basic starting point and by no means is complete and exhaustive.

The first thing I like to do when externally examining someone's DNS configuration is to perform a whois on the domain name.

# whois some-domain.com


The important part of that information is the domain servers.

Domain servers in listed order:

NS1.SOME-DOMAIN.COM
NS2.SOME-DOMAIN.COM



The other things I like to check is that the contact information is semi-generic. The place this comes in handy, is in an enterprise environment where there will enevitabley be employee turnover. If the contact information is spefic to a single user, i.e Billy J. Bob, billy.bob@some-domain.com, etc, then it becomes very painful to update this information or have changes made once that employee leaves the company. I instead prefer to see something more along the lines of hostmaster@some-domain.com or dns@some-domain.com which is a distro list pointing to operations team Billy Bob is apart of.

The next thing I check, is that the NS records supplied for that domain by the name servers, match those supplied by the whois record.

dig ns @NS1.SOME-DOMAIN.COM some-domain.com

;; QUESTION SECTION:
;some-domain.com. IN NS

;; ANSWER SECTION:
some-domain.com. 7200 IN NS ns1.some-domain.com.
some-domain.com. 7200 IN NS ns2.some-domain.com.


Any mismatch between the NS records supplied by the name server and those listed in the whois record can cause intermittent DNS resolution failures and sometimes even mail delivery problems.

For redundancy purposes, the supplied domain servers should be located in geographically diverse regions on seperate networks, and should also be carrier diverse as well. Resolving these server names and performing traceroutes to each of them should allow you to make educated inferences into whether this is true or not.

Now its time to examine the DNS servers themselves. I first like to check to see if the DNS servers will provide version information. There are two ways to do this. With dig:

dig @ns1.some-domain.com version.bind txt chaos
;; ANSWER SECTION:
VERSION.BIND. 0 CH TXT "8.3.4-REL"


Or alternatively with nslookup:

nslookup -type=txt -class=chaos version.bind ns1.some-domain.com
VERSION.BIND text = "8.3.4-REL"


The easiest way to obscure this information on a server running BIND, is to use the version statement within the options section of the named.conf file.

options {
version "None of Your Business!";
}


The next thing to check is if zone transfers are enabled. Again, there are two ways to do this. With dig:

dig @ns1.some-domain.com some-domain.com axfr


Or alternatively with nslookup:

nslookup
> server ns1.some-domain.com
Default Server: ns1.some-domain.com
> set type=any
> ls -d some-domain.com


If zone transfers are enabled, you will see something similar to the dig output below:

;; global options: printcmd
some-domain.com. 3600 IN SOA ns1.some-domain. admin.some-domain. 4 900 600 86400 3600
some-domain.com. 3600 IN NS ns1.some-domain.com
some-domain.com. 3600 IN NS ns2.some-domain.com
some-domain.com. 3600 IN MX 10 mail.some-domain.com.
mail.some-domain.com. 3600 IN A 208.209.251.12
www.some-domain.com. 3600 IN A 208.209.251.243
ns1.some-domain.com. 3600 IN A 208.209.251.8
ns2.some-domain.com. 3600 IN A 208.209.251.9
some-domain.com. 3600 IN SOA ns1.some-domain. admin.some-domain. 4 900 600 86400 3600
;; Query time: 681 msec
;; SERVER: 208.209.251.11#53(208.209.251.11)
;; WHEN: Tue Sep 11 10:04:12 2007
;; XFR size: 6 records (messages 6, bytes 429)

Remember to also check for zone transfers for the reverse DNS as well:

dig @ns1.some-domain.com 251.209.208.in-addr.arpa axfr

To prevent unauthorized zone transfers, use the allow-transfer statement within the options section of your named.conf file.

allow-transfer { ns2.some-domain.com; };

Alternatively, TSIG (Transaction SIGnature) keys can be used to authenticate zone transfer requests.

All domains should also have at least two MX records for redundancy. Like DNS servers, these servers should be on separate netblocks, and be both geographically and carrier diverse.

dig ms @ns1.some-domain.com some-domain.com

Another good thing to check for, are the presence of SPF records. To do this with dig:

dig -t TXT some-domain.com +short
"v=spf1 mx ?all"

One more common mistake is to have your public authoritative nameservers configured to allow recursion. The simplest way to check for this, is to use nslookup to send a non-related request to that server. For example:

nslookup www.monkey-house.org ns1.some-domain.com

Server: ns1.some-domain.com
Address: 208.209.251.11#53

Non-authoritative answer: Name: www.monkey-house.org Address: 216.98.141.250

For more intensive testing, I also like to run the domain through tools such as:

DNS Report -
http://www.dnsreport.com

So, how are you auditing DNS? What are your favorite tools?

Labels: ,