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 --

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: 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: 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: 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