DNS Server Queries (Instructor mistake?)



  • Right now I'm taking a course in network security (95% of the course is windows server 2003, the rest is vista, Linux and XP), in my Network infrastructre planning section my instructor made mention of a tip to have a DNS server that isn't associated with the domain (windows domain) as the DNS server referenced for outside queries rather than have the domain's DNS server also handle external DNS queries. The reason for this is apparently you don't want attackers being able to find out about your internal domain information. Now correct me if I'm wrong but:

    DNS client -> Domain Controller/DNS -> router -> external DNS
    
    vs
    
    DNS client -> Domain Controller/DNS -> Internal not associated DNS -> router -> external DNS
    or
    DNS client -> Internal not associated DNS -> router -> external DNS
    

    In all three cases only one piece of information is actually sent out the ns query, or should be. His worry is that the DC's DNS Database will be sent out with request queries. Is he in error is there something magical about DNS that apparently I don't know?



  • @Lingerance said:

    In all three cases only one piece of information is actually sent out the ns query, or should be. His worry is that the DC's DNS Database will be sent out with request queries. Is he in error is there something magical about DNS that apparently I don't know?

    He's an idiot, who has overheard real sysadmins talking about something and failed to comprehend it. It doesn't have anything to do with exposing your internal information, even if that would be a problem, which it wouldn't (what exactly does he think an attacker is going to do with the knowledge?).

    You shouldn't expose your internal Windows DNS server if you can avoid it because (a) the usual problem with Windows servers - they get cracked twice a week if you let connections in from the internet (b) DoS attacks could affect your local network for no good reason (c) you should be using bind on a unix server for your real-world DNS anyway, it's faster and less buggy. The only thing you should be doing with your Windows DNS server is the active directory stuff.



  • Ah, Windows domain controller... brings back the days of my twerp boss who figured a grand total of *2* servers could fulfill the workplace's entire computing needs. The PDC was also the joint's web server, and the BDC was the print server and primary (and only) file server. Except for getting zonked by Code Red (patches? we don't need no steenkin' patches) I'm surprised nothing managed to crawl into them.

    The PDC was a POS Dell Pentium Pro box with a nasty habit of spontaneous reboots, and the BDC was a homebrew (by the twerp) dual Pentium 166 on an insanely stupid Gigabyte board that had a nasty habit of killing any ethernet controllers in use. Great fun when everyone's saving their files at the end of the day, and the file server "vanishes". When I say killing, I mean as in any ethernet board you cared to use would occasionally decide to no long accept or forward packets. Didn't matter what brand or hardware revision or driver level or speed or duplex or cabling type. They all would cease responding. Of course Universal Microsoft Cure #1 (Reboot) would 'fix' things, until the next time.



  • The issue is that Windows' DNS server can't create zones that are only visible to certain networks. So every zone is resolvable on every interface, and all records will be visible if the name is guessed. Even if certain machines resolve to unroutable IP addresses for internal resources, a hacker could use that information to fool helpdesk workers or to create custom trojans that exploit internal resources, knowing the name (and probably purpose) of machines ahead of time.

     It is better to have a separate internal and external DNS server when using Windows so that you can control which records are resolvable on each machine, where one is inside the DMZ and one outside.

    Or you could just use BIND and choose to which networks you want to publish specific records and/or zones.
     



  • @kirchhoff said:

    The issue is that Windows' DNS server can't create zones that are only visible to certain networks. So every zone is resolvable on every interface, and all records will be visible if the name is guessed. Even if certain machines resolve to unroutable IP addresses for internal resources, a hacker could use that information to fool helpdesk workers or to create custom trojans that exploit internal resources, knowing the name (and probably purpose) of machines ahead of time.

    You are suggesting an attacker that is smart enough to guess DNS names from the extremely large pool of possibilities, while stupid enough not to know how to find out which IP addresses are in use from the extremely small pool of possibilities, or a helpdesk that is simultaneously smart enough to not hand out their passwords in exchange for a chocolate bar (most people fail this one) or to people who can guess the DNS names, while being stupid enough to hand out information if the attacker knows the internal IP addresses.

    I really do not find this threat model to be very likely.

     

    Your IP addresses are not a secret, and neither are your DNS records. Your system would not be more secure if they were. You do not create security by attempting to hide randomly selected pieces of information, particularly not if that information is widely known anyway.

    Security is based around locating the things that you actually want to protect and building real barriers to protect them. Real barriers either authenticate the user (by whatever means) or block all access along that path. Anything that does neither is a useless waste of time (and will probably do nothing more to an attacker than amuse them).



  • Okay, so a trojan that uses hostnames instead of simply scanning a subnet for vulnerable services is unlikely, I admit. But that's not the scenario I imagined.

    DNS is very indictative of your network resource layouts (what with all the round robin entries, functional CNAMEs, SRV records you employ to keep software reconfiguration to a minimum, right?). Analysis of your zone can give an outsider evidence of your network's size, layout, technologies employed and from this he can synthesize good guesses about your system architecture and policies.

    This information could be used to tailor and existing trojan into one which goes for low-hanging fruit; prioritizing attack vectors based on these guesses.

    What's worse is that he has a leg up on getting someone to run one of these trojans because he'll have "inside" information about the system that only an employee is likely to know (he could be dead wrong but if he guessed right then that could be the push that puts him in someone's confidence).

    An stupid example: you don't want to broadcast the fact that there's a bdc-stlouis.sales.example.com.

    Because when the ITT-tech trained MSCE with local Admin access in the St. Louis office gets a call on Patch Tuesday that he needs to run some malware scanner on the backup domain controller before that big meeting the VP of sales is going to have tommorow morning and could you please go to a TinyURL to download it, I'll GMail it to you because I'm on the road and corporate wants this DONE YESTERDAY.

    Of course, the real problem in that situation is:

    1) They ran M$ (hurrrr)
    2) They hired an idiot.

    Seriously though, they run MS because the big boss wanted Exchange. And they had to hire SOMEONE who was willing to sit in the site office to tend to the big babies in sales who can't figure out how to spell check or undock their laptops. But good god do they have a lot of people wanting to buy your widgets out in the St. Louis shipyards, oh lordy its a good thing you located that sales site office out there...

    The point is you do everything you can (that's easy to configure and manage anyway) to not leave anything interesting for people outside to find in the first place. This goes double if your organization handles in any shape: billing details (Sales, anyone?) Them's the cherries. That's when the pros dust off their thinking caps and try to find a way in that doesn't involve trying to HACK THE GIBSON.

     

    And there are non-security reasons for wanting a split DNS too (esp. wrt to email and web resources).

     
     



  • Edit timeout:

    I agree though, you need hard controls. Nothing beats TLS marshalled by a logon box. No one is going to "hack" pf. But it's a risk management excercise. You want to reduce the risk that your own employees will fuck something up. And you can't just prevent outside phones from calling the help desk or inside lines.
    One aspect of this is not letting someone on the outside know the "way things work" with any significant detail on the inside. Sanitized DNS, no public facing admin pages on internet or B2B sites, everything publically accessible in or stradding a DMZ, server header filtering, reverse proxies... you should be doing all of that.
     



  • @kirchhoff said:

    And you can't just prevent outside phones from calling the help desk or inside lines.

    But you can avoid giving the helldesk monkeys any kind of administrative access. Their job is hand-holding with user-level privileges; if they find anything that's really broken, rather than user error, they sent it up to somebody who knows what they're doing. A monkey will never be instructed to do anything more complex than flip the power switch on a server, because everything else is done by the real admins via your remote management system (whichever one you're using).

     

    One aspect of this is not letting someone on
    the outside know the "way things work" with any significant detail on
    the inside. Sanitized DNS, no public facing admin pages on internet or
    B2B sites, everything publically accessible in or stradding a DMZ, server header filtering, reverse proxies... you should be
    doing all of that.

    Security based on non-secret secrets is exactly what attackers are going to be targeting. Any attempt to "secure" things in this manner is just leaving the door open for them to walk right in. They are going to find out everything they want about how your systems work, and you cannot stop them. They will go through your trash and reassemble your shredded documents. They will pour alcohol into your helldesk monkeys until they start boasting about the systems they work on. They will call the support line pretending to be a clueless user who needs handholding to find their stuff on the fileserver. Your systems must be secure anyway. You cannot stop these things; you must stop these things from being security holes.



  • @asuffield said:

    Security based on non-secret secrets is exactly what attackers are going to be targeting. Any attempt to "secure" things in this manner is just leaving the door open for them to walk right in. They are going to find out everything they want about how your systems work, and you cannot stop them. They will go through your trash and reassemble your shredded documents. They will pour alcohol into your helldesk monkeys until they start boasting about the systems they work on. They will call the support line pretending to be a clueless user who needs handholding to find their stuff on the fileserver. Your systems must be secure anyway. You cannot stop these things; you must stop these things from being security holes.

    Thank you Kevin Mitnick.  I've been reading about him.  About half of his "hacking*" was "social engineering" where he'd get that kind of information from those kinds of people.  Your helpdesk should have no real power. 

    *Discussions of Mitnick usually contain the idea that hackers create things, whereas "crackers" break those things.  Personally, I don't think it's a big deal, because the term "hacker" has its meaning to the public and you'll never convince the public that the opposite is true.  This begs the question, though ... no I'll stop here.  I'm rambling.  Thanks for listening.
     



  • Most courses in computer ethics will tell you the difference between a hacker and a cracker. Just because the general public doesn't associate it so doesn't mean its the wrong definition.


Log in to reply