NTP Query!

Discussion in 'Networks' started by Jellyman_4eva, Jul 22, 2007.

  1. Jellyman_4eva

    Jellyman_4eva Byte Poster

    213
    4
    34
    Hi all,

    This is a query to the network guru's out there to see if they can help/explain a scenario to me. (I know I have done CCNA but it was a while ago and it is not helping)..

    I have recently come into an environment which I believe has the following setup:

    DC's --> 2 x 6509 Load Balancing --> ISA Firewall --> Internet

    The problem I was having was that the PDC had errors stating it could not sync to time.windows.com. Now all the DC's have their default gateway set to the IP of the 6509 setup. When I mentioned this to someone in passing they suggested I created a persistent route to the ISA firewall for the IP address of time.windows.com (Thus bypassing the 6509's). The moment I did this and hit resync the DC picked up the correct time and since then has had no problems...

    Unfortunately the person I spoke to has disappeared! I have absolutely no idea why this works and why it did not work previously... can anyone shed any light on this?
     
    Certifications: MCDST, MCITP-EDST/EDA/EA/SA/ MCSA 2K3/2K8, MCSE+M 2K3/2K8, ISA/TMG, VCP3/4, CCNA, Exchange, SQL, Citrix, A+, N+, L+, Sec+, Ser+, JNCIA-SSL, JNCIS-SSL
    WIP: Lots
  2. zebulebu

    zebulebu Terabyte Poster

    3,748
    330
    187
    You need to understand how Windows maintains a list of authoritative time sources. There's a Technet and KB article that explains it far better than I ever could - I'll dig it out and post the link.

    Basically, Windows can either sync with an internal hardware clock, or an authoritative source. In most domains, you would configure an NTP server via an external route on your firewall by allowing NTP traffic (UDP port 123) in and out of your F/W to a specific internal IP (the internal time server) - then configure all your internal clients to point to that client as a time source.

    I wouldn't use time.windows.com though - I'd be much more inclined to use the US military or UK atomic clocks as an authoritative external source. ALso - you should be aware that there is a slight risk involved in doing this - NTP is not in the slightest bit secure and it has been the target of a number of attacks in the past. That said, so long as you're not a total wally and ensure that you open up only a single internal address and ensure that the NTP traffic is firewalled, you should be OK.

    I think the load balancing thing is a red herring - you need to configure one internal address for best practice, but I'm sure you could pass traffic to/from both servers through the firewall without it causing an issue.

    EDIT: Here's the link
     
    Certifications: A few
    WIP: None - f*** 'em
  3. Jellyman_4eva

    Jellyman_4eva Byte Poster

    213
    4
    34
    Thanks for the reply.. I have read the article which you are talking about and I have been instructed by my superiors to use an external time server rather than the hardware clock etc (Its only a registry edit away anyway if they change their mind). The other DC's pick up their time from the PDC and as such all the clients pick up their time from whatever DC they log on to so it all works OK (All of this I believe is default stuff).

    I would be interested in any information you have about the security implications and how I can get around them... As far as I am aware (Not definite on this), the ISA box does not allow UDP 123 inbound to anything unless solicited by an internal client.

    I only used time.windows.com because I knew it was there and I was following the article (May change this at some point!).

    I am just having real trouble working out exactly why it does not seem to work through the load balancers but does work when going directly through the ISA via the static route.
     
    Certifications: MCDST, MCITP-EDST/EDA/EA/SA/ MCSA 2K3/2K8, MCSE+M 2K3/2K8, ISA/TMG, VCP3/4, CCNA, Exchange, SQL, Citrix, A+, N+, L+, Sec+, Ser+, JNCIA-SSL, JNCIS-SSL
    WIP: Lots
  4. AJ

    AJ 01000001 01100100 01101101 01101001 01101110 Administrator

    6,897
    182
    221
    have a check in the isa monitoring logd and see what they say. There is a ruke in ISA that allows time sync through. <ake sure that this is allowed. I think it is in the system rules. Also, if you have a managed router, they allow port 123.
     
    Certifications: MCSE, MCSA (messaging), ITIL Foundation v3
    WIP: Breathing in and out, but not out and in, that's just wrong
  5. zebulebu

    zebulebu Terabyte Poster

    3,748
    330
    187
    Well, apart from a couple of vulnerabilities in some NTP implementations that were discovered a while back, the risk from NTP is more of a 'theoretical risk' - the type of risk that doesn't require immediate mitigation against, but should nevertheless be put on any organisation's Risk Register.

    The thinking goes something like this:

    NTP works on UDP - so packets can be spoofed to appear from anywhere a user likes.

    The NTP system requires a port to be opened on your firewall - always a risk.

    A malicious hacker could compromise a host outside your firewall (something you can do nothing about) and possibly create a DOS attack by spoofing incorrect timestamps on NTP packets.

    Again - this is entirely theoretical - what if a determined hacker wanted to DOS your network? They may be able to spoof a packet (or packets) to appear to be from your authoritative time source (which they may have obtained by other methods) which, when they are passed through your (misconfigured) firewall, have the effect of setting the timesource on your WIndows server to be - ooh, lets say 1969 - possibly wreaking havoc with your internal UNIX systems?

    Whilst the above attack is pure fantasy (like anything you might see in a movie on hax0rs) it shows that - without the port being opened on the firewall - there is NO risk. Anything you implement that requires a connection to the outside world carries an inherent risk - no matter how small.

    At work our NTP server is internal - it connects via a practically unbreakable VPN to the Rugby atomic clock - but it's still down on my Risk Register (albeit as a '1' - the lowest score possible) because there is always the chance that someone could compromise either the VPN or the service from Rugby.

    I ALWAYS think like a bad guy - I think that's why I'm so well-suited to security :biggrin
     
    Certifications: A few
    WIP: None - f*** 'em

Share This Page

Loading...
  1. This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
    By continuing to use this site, you are consenting to our use of cookies.