Home
| Calendar
| Mail Lists
| List Archives
| Desktop SIG
| Hardware Hacking SIG
Wiki | Flickr | PicasaWeb | Video | Maps & Directions | Installfests | Keysignings Linux Cafe | Meeting Notes | Linux Links | Bling | About BLU |
That statement is not accurate. We have separate zone files for different domains: blu.org, heli-vets.org, Abreau.net, etc., but blu.org is a single zone file for all three BLU servers plus our various CNAMES, MX records, etc. On Mar 26, 2013, at 10:53 AM, Jerry Feldman <gaf at blu.org> wrote: > For your local hostnames, you would need to set up a DNS server inside of your VPN so those host names are only visible after someone has established the VPN. While we do not do a VPN for BLU.org, we do have separate zone files for each host. > > On 03/26/2013 10:21 AM, Chris O'Connell wrote: >> Tom, >> >> Thanks for taking the time to explain all of that. What I've found is that >> most of the address I can find are A, MX . As a result, when I run a >> DNSENUM against my domain externally most A records that point to our IP >> addresses. Obviously I would like to hide these (especially ones like >> remote.blah.org and vpn.blah.org). >> >> The explanation about the file system is making sense... you can view the >> file if you can guess the name. My next question is, what's the mechanism >> that allows me to view the file if I guess the name? Followed by how do I >> control it? Is this tied by binding an internal DNS server on our local >> domain to the external DNS server? >> >> Thanks again everyone. >> >> Chris >> >> >> On Mon, Mar 25, 2013 at 6:24 PM, Tom Metro <tmetro+blu at gmail.com> wrote: >> >>> Chris O'Connell wrote: >>>> I've been using DNSENUM.PL via BackTrack to do some information >>> gathering >>>> on my work's network. >>> Never heard of it, but looks like Dnsenum is documented here: >>> http://code.google.com/p/dnsenum/ >>> The purpose of Dnsenum is to gather as much information as possible >>> about a domain. The program currently performs the following >>> operations: >>> >>> 1) Get the host's addresse (A record). >>> 2) Get the namservers. >>> 3) Get the MX record. >>> 4) Perform axfr queries on nameservers and get BIND versions... >>> 5) Get extra names and subdomains via google scraping >>> (google query = "allinurl: -www site:domain"). >>> 6) Brute force subdomains from file, can also perform recursion on >>> subdomain that have NS records. >>> 7) Calculate C class domain network ranges and perform whois queries >>> on them. >>> 8) Perform reverse lookups on netranges... >>> 9) Write to domain_ips.txt file ip-blocks. >>> >>> >>>> So, not all of my DNS sub domains show up in a simple scan. >>> (Lets set aside the "subdomain" terminology discussion. In my experience >>> the term is often used even for domains that aren't delegated, which is >>> likely a misuse of the term.) >>> >>> My guess would be that Dnsenum is getting its initial list by looking at >>> names returned as a side effect of other queries. While zone transfers >>> used to be readily accessible, as Rich said they've been largely >>> disabled for security reasons (and at one time to avoid security holes >>> in BIND). However, that restriction might be IP sensitive, and you might >>> be allowed to do a zone transfer from your own LAN's IP range. You can >>> try playing around with a tool like 'dig' to explore this further yourself. >>> >>> DNS is like a file system directory where you don't have permission to >>> list the directory contents, but if you know the file name you can >>> access the file contents. I'm assuming their brute force option simply >>> goes through a list of common names, looking to see if each exists. >>> >>> But as implied by items #1 through #3 above, DNS intentionally reveals >>> some information in order to make it useful. >>> >>> Disabling zone transfers is an attempts to hide the particulars within a >>> zone, but it is imperfect at best, as this information often leaks out >>> through other means (mail headers, for example). One possibility is to >>> scan through the range of IP addresses used by your target and do >>> reverse (PTR) queries on each IP (#8 above). Of course lots of DNS >>> entries lack corresponding PTR records, so that may not turn up much. >>> >>> The source for Dnsenum can be viewed here: >>> http://code.google.com/p/dnsenum/source/browse/trunk/dnsenum.pl?r=2 >>> >>> and it looks like if you run it in verbose mode it'll tell you a bit >>> more about what queries it is performing. >>> >>> The best way to answer this question would be to obtain your zone file >>> from whoever maintains your DNS and look at how the records vary between >>> the ones that Dnsenum finds and the ones it can't. >>> >>> -Tom >>> >>> -- >>> Tom Metro >>> Venture Logic, Newton, MA, USA >>> "Enterprise solutions through open source." >>> Professional Profile: http://tmetro.venturelogic.com/ >>> >> >> > > > -- > Jerry Feldman <gaf at blu.org> > Boston Linux and Unix > PGP key id:3BC1EB90 > PGP Key fingerprint: 49E2 C52A FC5A A31F 8D66 C0AF 7CEA 30FC 3BC1 EB90 > > _______________________________________________ > Discuss mailing list > Discuss at blu.org > http://lists.blu.org/mailman/listinfo/discuss
BLU is a member of BostonUserGroups | |
We also thank MIT for the use of their facilities. |