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 sunyuc...@gmail.com wrote:
Just for the reference,
,
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 strongly suggest reading
On Tue, 18 Feb 2014 09:14:59 -0500
Jared Mauch ja...@puck.nether.net 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,
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
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
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 k...@quadranet.com wrote:
add these to
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
to iptables
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 the
If somebody has contacts at Juniper who is involved in this, I'd like to
get their contact information.
--
Harlan Stenn st...@ntp.org
http://networktimefoundation.org - be a member!
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-servers {
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:03 PM, Kate
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 pashd...@xmission.com wrote:
On
On Feb 17, 2014, at 10:14 PM, Pete Ashdown pashd...@xmission.com wrote:
Does not having nopeer contribute to DDoS amplification?
No:
http://www.kb.cert.org/vuls/id/348126
---
Roland Dobbins rdobb...@arbor.net //
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
correct
On Feb 17, 2014, at 10:38 AM, Anthony Williams alby.willi...@verizon.com
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
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
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
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
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
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, because NTPD has
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
On Feb 16, 2014, at 10:03 PM, Kate Gerry k...@quadranet.com 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
On Feb 16, 2014, at 7:59 PM, Mark Tinka mark.ti...@seacom.mu 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
On Sun, Feb 16, 2014 at 11:09 PM, Lyndon Nerenberg lyn...@orthanc.ca wrote:
On Feb 16, 2014, at 7:59 PM, Mark Tinka mark.ti...@seacom.mu wrote:
Juniper's Junos implementation (which is based on FreeBSD)
hasn't been patched
Using firewall filters is the only way to mitigate the
On Feb 16, 2014, at 8:30 PM, Christopher Morrow morrowc.li...@gmail.com 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.
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 on
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 fix
On Sun, Feb 16, 2014 at 11:42 PM, Mark Tinka mark.ti...@seacom.mu 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
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,
On Jan 17, 2014, at 6:44 AM, Tony Finch d...@dotat.at wrote:
Jared Mauch ja...@puck.nether.net 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
Jared Mauch ja...@puck.nether.net 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
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
On Jan 15, 2014, at 12:05 AM, Saku Ytti s...@ytti.fi 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
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
On Jan 16, 2014, at 9:56 PM, Saku Ytti s...@ytti.fi 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
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
On Thu, Jan 16, 2014 at 2:27 PM, Andrew Sullivan asulli...@dyn.com 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
On Thu, Jan 16, 2014 at 11:27 AM, Andrew Sullivan asulli...@dyn.com 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
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.
On Thu, Jan 16, 2014 at 11:39 AM, Andrew Sullivan asulli...@dyn.com 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
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!
On Jan 16, 2014 9:08 AM, Andrew Sullivan asulli...@dyn.com 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
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 turn
On Jan 16, 2014 9:31 AM, Andrew Sullivan asulli...@dyn.com 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.
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 without
On 16 Jan 2014, at 17:30 , Andrew Sullivan asulli...@dyn.com 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.
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-only
On Jan 16, 2014 10:16 AM, Saku Ytti s...@ytti.fi 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
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.
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 asulli...@dyn.com
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
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 UDP
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
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
--- 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 and
On Thu, Jan 16, 2014 at 3:05 PM, Mark Andrews ma...@isc.org 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
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.
--- do...@dougbarton.us wrote:
From: Doug Barton do...@dougbarton.us
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
In message caaawwbvjkeok-ydweqd4cowj9qaatbc8mkqwnxrsud55+h9...@mail.gmail.com
, Jimmy Hess writes:
On Thu, Jan 16, 2014 at 3:05 PM, Mark Andrews ma...@isc.org wrote:
We don't need to change transport, we don't need to port knock. We
just need to implementent a slightly modified dns
On Jan 16, 2014 5:10 PM, Mark Andrews ma...@isc.org wrote:
In message
caaawwbvjkeok-ydweqd4cowj9qaatbc8mkqwnxrsud55+h9...@mail.gmail.com
, Jimmy Hess writes:
On Thu, Jan 16, 2014 at 3:05 PM, Mark Andrews ma...@isc.org wrote:
We don't need to change transport, we don't need to port
In message CAD6AjGTE-raK1AnFha+tz+WQGAuUrB7Pr0vfc3J=qnhfu63...@mail.gmail.com
, Cb B writes:
On Jan 16, 2014 5:10 PM, Mark Andrews ma...@isc.org wrote:
In message
caaawwbvjkeok-ydweqd4cowj9qaatbc8mkqwnxrsud55+h9...@mail.gmail.com
, Jimmy Hess writes:
On Thu, Jan 16, 2014 at 3:05
- Original Message -
From: Scott Weeks sur...@mauigateway.com
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
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
Jared Mauch ja...@puck.nether.net 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:
-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 is not
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.
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
nmap -sU -pU:123 -Pn -n --script=ntp-monlist serverIP
On Mon, Jan 13, 2014 at 3:07 PM, Jared Mauch ja...@puck.nether.net 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
On 13 Jan 2014, at 21:13 , Derek Andrew derek.and...@usask.ca 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 ja...@puck.nether.net wrote:
4) Please prevent
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
69 matches
Mail list logo
