From: Lord, Chris (chris.lord@lorien.co.uk)
Date: Tue Dec 14 2004 - 19:53:22 GMT-3
Hi Tim,
My understanding is that the query-only access-group is used when this
router is acting as an ntp server and you want to filter various types
of inbound broadcast requests from ntp clients and responses back to
them.
Preventing an ntp server from responding to control queries does not
prevent it from responding to time requests for example.
Why would you want to do this? Well, once a server is syncd with its own
time-source it will answer requests from any client whether you trust
them or not and Control queries can provide ways for remote systems to
get configuration information from NTP servers.
For example, some people may leave their routers open to NTP requests
from the Internet to allow remote users to make time/control requests.
There is the possibility that an attacker could use NTP informational
queries to discover the timeservers to which your own router is
synchronized, and then through an attack such as DNS cache poisoning,
redirect your router to a system under his control. Manipulating the
time on your routers could make it difficult to identify when incidents
actually happened and could also be used to confuse any time-based
security measures you have in place. Akin's "Hardening Cisco Routers"
goes into some detail on this.
Leaving your router open to untrusted control queries could also attract
vulnerability exploits which an attacker could possibly use to crash a
router. See http://www.securityfocus.com/archive/1/174011 and
http://www.securityfocus.com/archive/1/176137 for example.
HTH,
Chris
-----Original Message-----
From: ccie2be [mailto:ccie2be@nyc.rr.com]
Sent: 14 December 2004 21:36
To: Lord, Chris
Cc: Group Study
Subject: Re: NTP Broadcast
Hey Chris,
Do you know anything about ntp control queries?
There's a command, ntp access-group query-only <acl #>, which only
allows
these control queries.
I have no idea why anyone would want to configure ntp and then only
allow
control queries. Doesn't make any sense to me.
Do you have any ideas about this?
Tim
----- Original Message -----
From: "Lord, Chris" <chris.lord@lorien.co.uk>
To: "ccie2be" <ccie2be@nyc.rr.com>; <ccielab@groupstudy.com>
Sent: Tuesday, December 14, 2004 3:41 PM
Subject: RE: NTP Broadcast
> Hi Tim,
>
> Yes, I tried it and things work ok either way in the lab, which is why
I
> was intrigued by the book's recommendations. It just made me wonder
> whether there was some subtle reason why ntp broadcast was better over
> NBMA than using a server/client configuration.
>
> Cheers,
>
> Chris
>
> -----Original Message-----
> From: ccie2be [mailto:ccie2be@nyc.rr.com]
> Sent: 14 December 2004 17:29
> To: Lord, Chris; ccielab@groupstudy.com
> Subject: Re: NTP Broadcast
>
> Chris,
>
> I doubt that that is completely true.
>
> I haven't tested this, but I think that if the hub router is
configured
> to
> broadcast ntp to the spokes and the spokes are configured to listen
for
> ntp
> broadcasts, all will be fine. But, I think ntp will also work if the
> ntp
> clients are configured with the ntp server ip address and the ntp
server
> is
> configured with ntp master regardless of which router is the hub and
> which
> routers are spokes in the f/r network.
>
> When I get a chance I lab this up and see what happens.
>
> HTH, Tim
> ----- Original Message -----
> From: "Lord, Chris" <chris.lord@lorien.co.uk>
> To: <ccielab@groupstudy.com>
> Sent: Wednesday, November 10, 2004 10:22 AM
> Subject: NTP Broadcast
>
>
> > Hi Group,
> >
> > I am trying to clarify whether there are any special requirements
for
> configuring ntp over a frame relay nbma cloud and was wondering if
> anyone
> could help. I have always configured the peering or server
relationships
> manually and it seems to work ok. However, in Benjamin's CCIE Security
> Guide
> it says that "Rx must be must be configured to send NTP traffic over
the
> frame relay cloud with the command ntp broadcast". Both static and
> broadcast
> methods seem to work ok in the lab. Does anyone have a view on this.
> >
> > TIA,
> >
> > Chris Lord
> > #13925
> >
> >
> >
> >
> >
**********************************************************************
> > The information contained in this email is confidential and is
> intended
> for the recipient only. If you have received it in error, please
notify
> us
> immediately by reply email and then delete it from your system. Please
> do
> not copy it or use it for any purposes, or disclose its contents to
any
> other person or store or copy this information in any medium. The
views
> contained in this email are those of the author and not necessarily
> those of
> Lorien plc.
> >
> > Thank you for your co-operation.
> >
**********************************************************************
> >
> >
>
This archive was generated by hypermail 2.1.4 : Mon Jan 03 2005 - 10:31:27 GMT-3