Re: JunOS NTP - Re: OpenNTPProject.org

On Tuesday, February 18, 2014 04:14:59 PM Jared Mauch wrote: > So, be careful as the Juniper solution varies depending > on the platform involved. > > Make sure you check your devices. It took a few > iterations for us to get the right filters on > everything. Indeed. In particular, different

Re: JunOS NTP - Re: OpenNTPProject.org

On Tue, 18 Feb 2014 09:14:59 -0500 Jared Mauch wrote: > >prefix-list ntp-servers { > >apply-path "system ntp server <*>"; Some people also have a 'boot-server [server]' statement. In the off chance that address is different than those listed in the server statements, you may need to

RE: OpenNTPProject.org

interfaces. Thanks, Mike -Original Message- From: Blake Dunlap [mailto:iki...@gmail.com] Sent: Monday, February 17, 2014 11:03 AM To: nanog@nanog.org Subject: Re: OpenNTPProject.org If you're trying to actually run a ntp server setup as opposed to just trusting the world, I str

JunOS NTP - Re: OpenNTPProject.org

So, be careful as the Juniper solution varies depending on the platform involved. Make sure you check your devices. It took a few iterations for us to get the right filters on everything. - Jared On Feb 17, 2014, at 12:26 AM, Yucong Sun wrote: > Just for the reference, here is a more comple

Re: OpenNTPProject.org

If you're trying to actually run a ntp server setup as opposed to just trusting the world, I strongly suggest reading the documentation for the service, as most people don't deploy it correctly while they think they have. At minimum, you want a cluster of 3 - 4 servers internally, configured as pe

Re: OpenNTPProject.org

On Feb 17, 2014, at 10:38 AM, Anthony Williams wrote: > Blake: > > Just to make sure I've got this down, listing a device as a "peer" in > the ntp.conf file will create a situation where both devices are saying, > "I know what time it is" and splitting the difference? Whereas when you > list a

Re: OpenNTPProject.org

Blake: Just to make sure I've got this down, listing a device as a "peer" in the ntp.conf file will create a situation where both devices are saying, "I know what time it is" and splitting the difference? Whereas when you list a device as a "server", it's using that as the authority on the corr

Re: OpenNTPProject.org

On Feb 17, 2014, at 10:14 PM, Pete Ashdown wrote: > Does not having "nopeer" contribute to DDoS amplification? No: --- Roland Dobbins // Luck

Re: OpenNTPProject.org

Peer means it considers the other side an equal and they will mutually skew time together. If you have peer on for devices you don't consider your time servers, you're opening yourself up to problems. -Blake On Mon, Feb 17, 2014 at 9:14 AM, Pete Ashdown wrote: > On 2/17/14, 7:26 AM, George, We

Re: OpenNTPProject.org

On 2/17/14, 7:26 AM, George, Wes wrote: > I’ll note that this is less than 140 chars, and therefore fits nicely in a > tweet. > > If you’re on twitter, Signal boost the PSA, please. > > My edited example: https://twitter.com/wesgeorge/status/435404354242478080 > > Wes George > > > > On 2/16/14, 10:

Re: OpenNTPProject.org

Just for the reference, here is a more complete solution for Junos (took me a while searching the web to figure it out), hope it helps someone. policy-options { prefix-list lo0.0-inet-address { apply-path "interfaces lo0 unit 0 family inet address <*>"; } prefix-list ntp-server

Re: OpenNTPProject.org

If somebody has contacts at Juniper who is involved in this, I'd like to get their contact information. -- Harlan Stenn http://networktimefoundation.org - be a member!

Re: OpenNTPProject.org

Kate Gerry writes: > Just add these to your ntp.conf configuration then restart the service: (Wo= > rks with all default installations that I've found) > > restrict default kod nomodify notrap nopeer noquery > restrict -6 default kod nomodify notrap nopeer noquery KOD only works with "limited" in

Re: OpenNTPProject.org

Pete Ashdown; NANOG list Subject: Re: OpenNTPProject.org Seriously, just fix your configuration. The part of NTP being abused is completely unrelated to actually synchronizing time. It's a management query, that has no real reason to be enabled remotely. You don't even need to resort

Re: OpenNTPProject.org

I’ll note that this is less than 140 chars, and therefore fits nicely in a tweet. If you’re on twitter, Signal boost the PSA, please. My edited example: https://twitter.com/wesgeorge/status/435404354242478080 Wes George On 2/16/14, 10:03 PM, "Kate Gerry" wrote: >add these to your ntp.conf >

Re: OpenNTPProject.org

Rate limitings been in place for quite some time, but I believe it's only for actual time queries. This DDOS uses monlist, which isn't subject to the same rate limits. You've disabled monlist now, so I bet you'll no longer need all the rate limiting IPTables rules. (Though, you'll still see

Re: OpenNTPProject.org

On 2/16/14, 7:38 PM, Brian Rak wrote: > Seriously, just fix your configuration. The part of NTP being abused > is completely unrelated to actually synchronizing time. It's a > management query, that has no real reason to be enabled remotely. You > don't even need to resort to iptables for this, b

Re: OpenNTPProject.org

On Sun, Feb 16, 2014 at 11:42 PM, Mark Tinka wrote: > On Monday, February 17, 2014 06:35:46 AM Lyndon Nerenberg > wrote: > >> I was suggesting it as an alternative to just chopping >> off NTP at your border. Presumably it would be a >> one-off thing until Juniper issues a patch. > > In Junos, app

Re: OpenNTPProject.org

On Monday, February 17, 2014 06:35:46 AM Lyndon Nerenberg wrote: > I was suggesting it as an alternative to just chopping > off NTP at your border. Presumably it would be a > one-off thing until Juniper issues a patch. In Junos, applying the right filters to your router's control plane will fi

Re: OpenNTPProject.org

On Monday, February 17, 2014 06:09:01 AM Lyndon Nerenberg wrote: > But doesn't the JunOS ntpd read/parse ntpd.conf? It's > worth getting to the admin mode shell prompt and taking > a poke around /etc. You can get access to the shell and edit the daemon configuration files yourself, but based o

Re: OpenNTPProject.org

On Feb 16, 2014, at 8:30 PM, Christopher Morrow wrote: > and good luck with figuring out: > 1) when you need to re-do that magic move > 2) making sure that the move is automatable over time I was suggesting it as an alternative to just chopping off NTP at your border. Presumably it would be

Re: OpenNTPProject.org

On Sun, Feb 16, 2014 at 11:09 PM, Lyndon Nerenberg wrote: > > On Feb 16, 2014, at 7:59 PM, Mark Tinka wrote: > >> Juniper's Junos implementation (which is based on FreeBSD) >> hasn't been patched >> >> Using firewall filters is the only way to mitigate the >> vulnerability. > > But doesn't the Ju

Re: OpenNTPProject.org

On Feb 16, 2014, at 7:59 PM, Mark Tinka wrote: > Juniper's Junos implementation (which is based on FreeBSD) > hasn't been patched > > Using firewall filters is the only way to mitigate the > vulnerability. But doesn't the JunOS ntpd read/parse ntpd.conf? It's worth getting to the admin mod

Re: OpenNTPProject.org

On Feb 16, 2014, at 10:03 PM, Kate Gerry wrote: > Just add these to your ntp.conf configuration then restart the service: > (Works with all default installations that I've found) > > restrict default kod nomodify notrap nopeer noquery > restrict -6 default kod nomodify notrap nopeer noquery It

Re: OpenNTPProject.org

On Monday, February 17, 2014 04:38:06 AM Brian Rak wrote: > There is no excuse to still be running a NTP server with > monlist enabled. Fix your configuration, and you don't > need IPTables rules. Juniper's Junos implementation (which is based on FreeBSD) hasn't been patched Using firewall fil

RE: OpenNTPProject.org

list Subject: Re: OpenNTPProject.org Seriously, just fix your configuration. The part of NTP being abused is completely unrelated to actually synchronizing time. It's a management query, that has no real reason to be enabled remotely. You don't even need to resort to iptables for this, b

Re: OpenNTPProject.org

Seriously, just fix your configuration. The part of NTP being abused is completely unrelated to actually synchronizing time. It's a management query, that has no real reason to be enabled remotely. You don't even need to resort to iptables for this, because NTPD has built in rate limiting (wh

Re: OpenNTPProject.org

On 2/16/14, 11:29 AM, Pete Ashdown wrote: > I've found that blocking TCP destination NTP to client servers/networks > blocks legitimate NTP synchronization for their clients. ^TCP^UDP

Re: OpenNTPProject.org

Just in case you run a legitimate open NTP server, this iptable stanza helps immensely: ## rate limit ntp $IPTABLES -N NTP $IPTABLES -N BLACKHOLE $IPTABLES -A BLACKHOLE -m recent --set --name ntpv4blackhole --rsource $IPTABLES -A BLACKHOLE -j DROP $IPTABLES -A NTP -m recent --update --seconds 5 --

Re: "trivial" changes to DNS (was: OpenNTPProject.org)

On Jan 17, 2014, at 6:44 AM, Tony Finch wrote: > Jared Mauch wrote: >> >> I can point anyone interested to the place in the >> bind source to force it to reply to all UDP queries with TC=1 >> to force TCP. should be safe on any authority servers, as a recursive >> server should be able t

Re: "trivial" changes to DNS (was: OpenNTPProject.org)

Jared Mauch wrote: > > I can point anyone interested to the place in the > bind source to force it to reply to all UDP queries with TC=1 > to force TCP. should be safe on any authority servers, as a recursive > server should be able to do outbound TCP. However see http://www.potaroo.net/is

BCP38.info (was: Re: OpenNTPProject.org)

- Original Message - > From: "Scott Weeks" > And it doesn't require governments, it just requires CEO's with the > gumption to say we are not going to accept routes from you, via > transit or direct, until you publically state that you are > implementing > BCP38 within your network and th

Re: "trivial" changes to DNS (was: OpenNTPProject.org)

In message , Cb B writes: > > On Jan 16, 2014 5:10 PM, "Mark Andrews" wrote: > > > > > > In message < > caaawwbvjkeok-ydweqd4cowj9qaatbc8mkqwnxrsud55+h9...@mail.gmail.com> > > , Jimmy Hess writes: > > > On Thu, Jan 16, 2014 at 3:05 PM, Mark Andrews wrote: > > > > > > > We don't need to change

Re: "trivial" changes to DNS (was: OpenNTPProject.org)

On Jan 16, 2014 5:10 PM, "Mark Andrews" wrote: > > > In message < caaawwbvjkeok-ydweqd4cowj9qaatbc8mkqwnxrsud55+h9...@mail.gmail.com> > , Jimmy Hess writes: > > On Thu, Jan 16, 2014 at 3:05 PM, Mark Andrews wrote: > > > > > We don't need to change transport, we don't need to port knock. We > > >

Re: "trivial" changes to DNS (was: OpenNTPProject.org)

In message , Jimmy Hess writes: > On Thu, Jan 16, 2014 at 3:05 PM, Mark Andrews wrote: > > > We don't need to change transport, we don't need to port knock. We > > just need to implementent a slightly modified dns cookies which > > reminds me that I need to review Donald Eastlake's new draft t

Re: OpenNTPProject.org

--- do...@dougbarton.us wrote: From: Doug Barton On 01/16/2014 03:45 PM, Scott Weeks wrote: > Many/most CEOs would not have an understanding of what a BCP is and > their first response likely would be to ask, "What's the business > case?" What I've tried to explain to people is that not being us

Re: OpenNTPProject.org

On 01/16/2014 03:45 PM, Scott Weeks wrote: Many/most CEOs would not have an understanding of what a BCP is and their first response likely would be to ask, "What's the business case?" What I've tried to explain to people is that not being used as a botnet will reduce their outbound traffic. I

Re: "trivial" changes to DNS (was: OpenNTPProject.org)

On Thu, Jan 16, 2014 at 3:05 PM, Mark Andrews wrote: > We don't need to change transport, we don't need to port knock. We > just need to implementent a slightly modified dns cookies which > reminds me that I need to review Donald Eastlake's new draft to be. > But a change to DNS doesn't solve t

Re: OpenNTPProject.org

--- ma...@isc.org wrote: In message <52d7e98b.4040...@userid.org>, Pierre Lamy writes: > BCP38 will only ever get implemented if governments and ruling 'net > bodies force deployment. There's otherwise very little benefit seen by > the access network providers, since the targets are other orgs an

Re: OpenNTPProject.org

In message <52d7e98b.4040...@userid.org>, Pierre Lamy writes: > BCP38 will only ever get implemented if governments and ruling 'net > bodies force deployment. There's otherwise very little benefit seen by > the access network providers, since the targets are other orgs and the > attacks are hap

Re: "trivial" changes to DNS (was: OpenNTPProject.org)

We don't need to change transport, we don't need to port knock. We just need to implementent a slightly modified dns cookies which reminds me that I need to review Donald Eastlake's new draft to be. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742

Re: "trivial" changes to DNS (was: OpenNTPProject.org)

On Thu, 16 Jan 2014 13:35:00 -0600, Jimmy Hess said: > Then the client's UDP stack must construct and send a Hashcash proof > of work, of sufficient difficulty based on the estimated query plus > response size, > up to the first full round trip; > containing a message digest of the first

Re: "trivial" changes to DNS (was: OpenNTPProject.org)

On Thu, Jan 16, 2014 at 10:48 AM, Christopher Morrow < morrowc.li...@gmail.com> wrote: > On Thu, Jan 16, 2014 at 11:39 AM, Andrew Sullivan > wrote: > > On Thu, Jan 16, 2014 at 11:32:05AM -0500, Christopher Morrow wrote: > So... what other options are there to solve the larger problem of: > "So

Re: "trivial" changes to DNS (was: OpenNTPProject.org)

On Thu, Jan 16, 2014 at 12:55:18PM -0500, Jared Mauch wrote: > I can point anyone interested to the place in the > bind source to force it to reply to all UDP queries with TC=1 > to force TCP. should be safe on any authority servers, as a recursive > server should be able to do outbound TCP.

Re: "trivial" changes to DNS (was: OpenNTPProject.org)

On Jan 16, 2014 10:16 AM, "Saku Ytti" wrote: > > On (2014-01-16 09:19 -0800), Cb B wrote: > > > I hope QUIC does not stay on UDP, as it may find itself cut off at the > > legs. > > Any new L4 would need to support both flavours, over UDP and native. Over UDP > is needed to be deployable right now

Re: "trivial" changes to DNS (was: OpenNTPProject.org)

On (2014-01-16 09:19 -0800), Cb B wrote: > I hope QUIC does not stay on UDP, as it may find itself cut off at the > legs. Any new L4 would need to support both flavours, over UDP and native. Over UDP is needed to be deployable right now and be working to vast majority of the end users. Native-onl

Re: "trivial" changes to DNS (was: OpenNTPProject.org)

On 16 Jan 2014, at 17:30 , Andrew Sullivan wrote: > On Thu, Jan 16, 2014 at 09:19:44AM -0800, Cb B wrote: >> I hate to throw the baby out with the bathwater, but in my network, IPv4 >> UDP is overstaying it's welcome. Just like IPv4 ICMP in 2001 - 2003, its >> fate is nearly certain. > > I won

Re: "trivial" changes to DNS (was: OpenNTPProject.org)

On Thu, Jan 16, 2014 at 11:39:46AM -0500, Andrew Sullivan wrote: > On Thu, Jan 16, 2014 at 11:32:05AM -0500, Christopher Morrow wrote: > > > pretty easy to believe that quic would be helpful right? > > Yes. It's also pretty easy to believe that ditching DNS completely in > favour of something w

Re: "trivial" changes to DNS (was: OpenNTPProject.org)

On Jan 16, 2014 9:31 AM, "Andrew Sullivan" wrote: > > On Thu, Jan 16, 2014 at 09:19:44AM -0800, Cb B wrote: > > I hate to throw the baby out with the bathwater, but in my network, IPv4 > > UDP is overstaying it's welcome. Just like IPv4 ICMP in 2001 - 2003, its > > fate is nearly certain. > > I w

Re: "trivial" changes to DNS (was: OpenNTPProject.org)

On Thu, Jan 16, 2014 at 09:19:44AM -0800, Cb B wrote: > I hate to throw the baby out with the bathwater, but in my network, IPv4 > UDP is overstaying it's welcome. Just like IPv4 ICMP in 2001 - 2003, its > fate is nearly certain. I won't speak about the other protocols, but I encourage you to tur

Re: "trivial" changes to DNS (was: OpenNTPProject.org)

On Jan 16, 2014 9:08 AM, "Andrew Sullivan" wrote: > > On Thu, Jan 16, 2014 at 11:48:56AM -0500, Christopher Morrow wrote: > > > > I totally agree... I was actually joking in my last note :( sorry for > > not adding the ":)" as requisite in email. > > I'm sorry my humour is now so impaired from rea

Re: "trivial" changes to DNS (was: OpenNTPProject.org)

On Thu, Jan 16, 2014 at 11:48:56AM -0500, Christopher Morrow wrote: > > I totally agree... I was actually joking in my last note :( sorry for > not adding the ":)" as requisite in email. I'm sorry my humour is now so impaired from reading 1net and other such things that I didn't figure it out! >

Re: "trivial" changes to DNS (was: OpenNTPProject.org)

On Thu, Jan 16, 2014 at 11:39 AM, Andrew Sullivan wrote: > On Thu, Jan 16, 2014 at 11:32:05AM -0500, Christopher Morrow wrote: > >> pretty easy to believe that quic would be helpful right? > > Yes. It's also pretty easy to believe that ditching DNS completely in > favour of something without 8 bi

Re: "trivial" changes to DNS (was: OpenNTPProject.org)

On Thu, Jan 16, 2014 at 11:32:05AM -0500, Christopher Morrow wrote: > pretty easy to believe that quic would be helpful right? Yes. It's also pretty easy to believe that ditching DNS completely in favour of something without 8 billion warts would be helpful. > seems totally feasible. Certai

Re: "trivial" changes to DNS (was: OpenNTPProject.org)

On Thu, Jan 16, 2014 at 11:27 AM, Andrew Sullivan wrote: > On Tue, Jan 14, 2014 at 09:18:30AM +0200, Saku Ytti wrote: >> >> mid term, transport area in IETF. DNS, NTP, SNMP, chargen et.al. could >> trivially change to QUIC/MinimaLT > > Oh, yes, it'd obviously be trivial to change DNS to use a diff

Re: "trivial" changes to DNS (was: OpenNTPProject.org)

On Thu, Jan 16, 2014 at 2:27 PM, Andrew Sullivan wrote: > On Tue, Jan 14, 2014 at 09:18:30AM +0200, Saku Ytti wrote: > > > > mid term, transport area in IETF. DNS, NTP, SNMP, chargen et.al. could > > trivially change to QUIC/MinimaLT > > Oh, yes, it'd obviously be trivial to change DNS to use a d

"trivial" changes to DNS (was: OpenNTPProject.org)

On Tue, Jan 14, 2014 at 09:18:30AM +0200, Saku Ytti wrote: > > mid term, transport area in IETF. DNS, NTP, SNMP, chargen et.al. could > trivially change to QUIC/MinimaLT Oh, yes, it'd obviously be trivial to change DNS to use a different transport. This is shown by the massive success of getting

Re: OpenNTPProject.org

On Jan 16, 2014, at 9:56 PM, Saku Ytti wrote: > It is not going to happen, the most suspect places are places where it's > going to be most difficult to get, either fully on autopilot with no technical > personnel capable or having the power to make the change or ghetto gear with > no capabili

Re: OpenNTPProject.org

On (2014-01-16 14:30 +), Dobbins, Roland wrote: > In point of fact, anti-spoofing is most useful and most practical at the > access-network edge, or as close to it as possible. We must disagree on definition of practical. Maybe if I'd reword it realistic we might be closer. It is not going

Re: OpenNTPProject.org

On Jan 15, 2014, at 12:05 AM, Saku Ytti wrote: > (We do BCP38 on all ports and verify programmatically, but I know it's not at > all practical solution globally for access). Anti-spoofing is eminently practical for most types of access network topologies using even slightly modern equipment;

Re: OpenNTPProject.org

BCP38 will only ever get implemented if governments and ruling 'net bodies force deployment. There's otherwise very little benefit seen by the access network providers, since the targets are other orgs and the attacks are happening in a different backyard. On 14/01/2014 10:36 AM, Paul Ferguson

Re: OpenNTPProject.org

On Tue, Jan 14, 2014 at 09:18:30AM +0200, Saku Ytti wrote: > DNS, NTP, SNMP, chargen et.al. could trivially change to QUIC/MinimaLT > or compared, getting same 0 RTT penalty as UDP without reflection > potential. I wouldn't say trivial, but QUIC and MinimaLT are hopefully the future. The near fut

Re: OpenNTPProject.org

On (2014-01-14 08:35 -0800), Damian Menscher wrote: > I see this as a form of BCP38, but imposed on networks by their transit > providers, rather than done voluntarily. It would be great if it could > work, but I have doubts due to asymmetric routing announcements intended > for traffic shaping.

Re: OpenNTPProject.org

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 1/13/2014 11:18 PM, Saku Ytti wrote: > On (2014-01-13 21:33 +), Bjoern A. Zeeb wrote: > >>> BCP38! I am always surprised when people need crypto if they >>> fail the simple things. > Saying that BCP38 is solution to the reflection attacks i

Re: OpenNTPProject.org

Jared Mauch wrote: > > 3) You want to upgrade NTP, or adjust your ntp.conf to include ‘limited’ > or ‘restrict’ lines or both. (I defer to someone else to be an expert > in this area, but am willing to learn :) ) There is useful guidance for Cisco, Juniper, and Unix here: https://www.team-cymru

Re: OpenNTPProject.org

On (2014-01-13 21:33 +), Bjoern A. Zeeb wrote: > BCP38! I am always surprised when people need crypto if they fail the simple > things. Saying that BCP38 is solution to the reflection attacks is not unlike 5 year old wishing nothing but world peace for christmas, endearing, but it's not goi

Re: OpenNTPProject.org

On 13 Jan 2014, at 21:13 , Derek Andrew wrote: > nmap -sU -pU:123 -Pn -n --script=ntp-monlist serverIP Make that “all server IPs” if on different subnets, address families, ... > On Mon, Jan 13, 2014 at 3:07 PM, Jared Mauch wrote: > >> 4) Please prevent packet spoofing where possible on you

Re: OpenNTPProject.org

nmap -sU -pU:123 -Pn -n --script=ntp-monlist serverIP On Mon, Jan 13, 2014 at 3:07 PM, Jared Mauch wrote: > Greetings, > > With the recent increase in NTP attacks, I wanted to advise the community > of a few things: > > There are about 1.2-1.5 million of these servers out there. > > 1) You ca

OpenNTPProject.org

Greetings, With the recent increase in NTP attacks, I wanted to advise the community of a few things: There are about 1.2-1.5 million of these servers out there. 1) You can search your IP space to find NTP servers that respond to the ‘MONLIST’ queries. 2) I’ve found some vendors have old embe