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 sunyuc...@gmail.com wrote:
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 {
apply-path system ntp server *;
}
}
firewall {
family inet {
filter lo-filter {
term ntp-allow {
from {
source-prefix-list {
ntp-servers;
lo0.0-inet-address;
}
protocol udp;
destination-port ntp;
}
then accept;
}
term ntp-other-discard {
from {
protocol udp;
destination-port ntp;
}
then {
discard;
}
}
term zz-accept {
then accept;
}
}
}
}
On Sun, Feb 16, 2014 at 8: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 Junos, applying the right filters to your router's
control plane will fix the issue. You don't need to block
NTP in the data plane.
Mark.
RE: OpenNTPProject.org
For knowledge on the list. We found that our Cisco Nexus 7000s had NTP enabled on our public facing VDCs, even when the command feature ntp was not present. I had to explicitly enter no feature ntp to prevent the NTP server service from existing on our public facing 7K 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 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 peers of each other, and listening to some source of time, preferably multiple like a few on the internet from the big public pool, and if you really care about time, set up a GPS receiver or two. You can definitely go farther than the above, but that's the start to doing it right. Anything short of the above is just trusting the world at large, and you'll likely happily follow along with any time skew like that thing a few months/year ago with either tick or tock. Without the above, you don't have enough sane sources to discredit bad advisers (you need 3 for a time lock). -Blake On Mon, Feb 17, 2014 at 9: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 when you list a device as a server, it's using that as the authority on the correct time? Example: -- # peer192.168.1.1 iburst peer192.168.1.2 iburst # server ntp.colby.edu minpoll 6 maxpoll 10 iburst server bonehed.lcs.mit.edu minpoll 6 maxpoll 10 iburst On 2/17/2014 10:28 AM, Blake Dunlap wrote: 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
Re: JunOS NTP - Re: OpenNTPProject.org
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, you may need to account for it as well. If you can, just
make sure it is also listed as one of the configured servers.
John
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 hardware and software combinations for the EX line have different match conditions for ports compared to the routers. Mark. signature.asc Description: This is a digitally signed message part.
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 the incoming garbage for awhile, but NTPD will just discard it so it shouldn't cause problems). On 2/17/2014 2:23 AM, Pete Ashdown wrote: 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, because NTPD has built in rate limiting (which isn't enabled for management queries, but those are trivial to disable). Thanks for the tip, monitoring is off. I was under the impression that rate-limiting hadn't made it into a stable version of ntpd yet. Is that incorrect?
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 k...@quadranet.com wrote: add these to your ntp.conf restrict default kod nomodify notrap nopeer noquery restrict -6 default kod nomodify notrap nopeer noquery Anything below this line has been added by my company’s mail server, I have no control over it. --- This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout.
Re: OpenNTPProject.org
Better yet, why is your ntp server even reachable off net? Providing a public clock service needs a lot more configuration effort than a simple, default one -- as just demonstrated. (However, this is not to say that private servers should have management queries enabled.) On 2/17/2014 9:03 AM, 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 -- Kate Gerry Network Manager k...@quadranet.com 1-888-5-QUADRA Ext 206 | www.QuadraNet.com Dedicated Servers, Colocation, Cloud Services and more. Datacenters in Los Angeles, Dallas and Miami. Follow us on: -Original Message- From: Brian Rak [mailto:b...@gameservers.com] Sent: Sunday, February 16, 2014 6:38 PM To: 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 to iptables for this, because NTPD has built in rate limiting (which isn't enabled for management queries, but those are trivial to disable). $ ntpdc -c monlist -n clock.xmission.com remote address port local address count m ver code avgint lstint === 173.209.207.23342422 198.60.22.240 4727 3 3 0 0 0 24.155.184.100 45285 198.60.22.240 11 3 4 0 6 0 107.0.41.2 48625 198.60.22.240264 3 4 0 5 0 67.108.239.31 40642 198.60.22.240 77084 3 3 0 0 0 177.65.149.237 62212 198.60.22.240 1085 3 1 0 0 0 209.64.161.162 44786 198.60.22.240 19 3 4 0 7 0 103.7.36.3851618 198.60.22.240 4 3 3 0 8 0 173.209.207.21850616 198.60.22.240 4731 3 3 0 0 0 69.61.203.25 20766 198.60.22.240 16379 3 4 0 1 0 68.188.251.223 478 198.60.22.240 2 1 3 0 0 0 75.82.183.104123 198.60.22.240 1 3 4 0 0 0 63.64.124.129 52839 198.60.22.240 150867 3 4 0 0 0 65.201.33.150151 198.60.22.240393 3 2 0 3 0 124.228.119.10524687 198.60.22.240 31 3 3 0 4 0 64.191.150.130 319 198.60.22.2404494361 3 2 0 0 0 76.102.124.27123 198.60.22.240 2 3 4 0 0 0 72.235.200.183 123 198.60.22.240 1 3 4 0 0 0 50.73.42.121 10398 198.60.22.240 11 3 3 0 14 0 63.64.124.144 26984 198.60.22.2405823740 3 4 0 0 0 71.5.8.194 44699 198.60.22.240 3 3 4 0 0 0 143.112.64.21320 198.60.22.240182 1 3 0 6 0 72.235.19.125123 198.60.22.240 1 3 4 0 0 0 198.237.66.2 10471 198.60.22.240499 3 3 0 3 0 12.108.21.226357 198.60.22.240 10 1 3 0 14 0 174.47.116.250 463 198.60.22.240 24 3 4 0 5 0 72.1.71.73 738 198.60.22.240 19 3 3 0 8 0 67.136.57.101026 198.60.22.240243 3 3 0 5 0 64.199.163.5 306 198.60.22.240231 3 4 0 4 0 70.77.76.153 32188 198.60.22.240 1 3 4 0 0 0 There is no excuse to still be running a NTP server with monlist enabled. Fix your configuration, and you don't need IPTables rules. On 2/16/2014 1:29 PM, Pete Ashdown wrote: 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 --hitcount 20 --name ntpv4 --rsource -j BLACKHOLE $IPTABLES -A NTP -m recent --update --seconds 5 --hitcount 2 --name ntpv4blackhole --rsource -j DROP $IPTABLES -A NTP -m recent --set --name ntpv4 --rsource -j ACCEPT $IPTABLES -A INPUT -p udp -m udp --dport 123 -j NTP I've found that blocking TCP destination NTP to client servers/networks blocks legitimate NTP synchronization for their clients. Although I wish they'd all just use my on-network NTP server, I can't assume they will. Does anyone have a list or source of pool and vendor (Apple/Microsoft/etc) servers so I can permit based on source before blocking based on destination port?
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 the release of NTP you are using. H
Re: OpenNTPProject.org
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!
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-servers {
apply-path system ntp server *;
}
}
firewall {
family inet {
filter lo-filter {
term ntp-allow {
from {
source-prefix-list {
ntp-servers;
lo0.0-inet-address;
}
protocol udp;
destination-port ntp;
}
then accept;
}
term ntp-other-discard {
from {
protocol udp;
destination-port ntp;
}
then {
discard;
}
}
term zz-accept {
then accept;
}
}
}
}
On Sun, Feb 16, 2014 at 8: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 Junos, applying the right filters to your router's
control plane will fix the issue. You don't need to block
NTP in the data plane.
Mark.
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:03 PM, Kate Gerry k...@quadranet.com wrote: add these to your ntp.conf restrict default kod nomodify notrap nopeer noquery restrict -6 default kod nomodify notrap nopeer noquery I seem to recall some issue with older Windows clients using peer for synchronization. Does not having nopeer contribute to DDoS amplification?
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 pashd...@xmission.com wrote: 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 Gerry k...@quadranet.com wrote: add these to your ntp.conf restrict default kod nomodify notrap nopeer noquery restrict -6 default kod nomodify notrap nopeer noquery I seem to recall some issue with older Windows clients using peer for synchronization. Does not having nopeer contribute to DDoS amplification?
Re: OpenNTPProject.org
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 // http://www.arbornetworks.com Luck is the residue of opportunity and design. -- John Milton
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 correct time? Example: -- # peer192.168.1.1 iburst peer192.168.1.2 iburst # server ntp.colby.edu minpoll 6 maxpoll 10 iburst server bonehed.lcs.mit.edu minpoll 6 maxpoll 10 iburst On 2/17/2014 10:28 AM, Blake Dunlap wrote: 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
Re: OpenNTPProject.org
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 when you list a device as a server, it's using that as the authority on the correct time? That is not exactly correct. Listing a system as peer or server means that the time from that system will be used as input to the synchronization algorithm. The selection process may discard data depending on various criteria regardless of peer/server designation. The operations implications are the requirement for your own robust group of peers 3 and lots of servers. See • RFC 5905: Network Time Protocol Version 4: Protocol and Algorithms Specification • RFC 5906: Network Time Protocol Version 4: Autokey Specification • RFC 5907: Definitions of Managed Objects for Network Time Protocol Version 4 (NTPv4) • RFC 5908: Network Time Protocol (NTP) Server Option for DHCPv6 signature.asc Description: Message signed with OpenPGP using GPGMail
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 peers of each other, and listening to some source of time, preferably multiple like a few on the internet from the big public pool, and if you really care about time, set up a GPS receiver or two. You can definitely go farther than the above, but that's the start to doing it right. Anything short of the above is just trusting the world at large, and you'll likely happily follow along with any time skew like that thing a few months/year ago with either tick or tock. Without the above, you don't have enough sane sources to discredit bad advisers (you need 3 for a time lock). -Blake On Mon, Feb 17, 2014 at 9: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 when you list a device as a server, it's using that as the authority on the correct time? Example: -- # peer192.168.1.1 iburst peer192.168.1.2 iburst # server ntp.colby.edu minpoll 6 maxpoll 10 iburst server bonehed.lcs.mit.edu minpoll 6 maxpoll 10 iburst On 2/17/2014 10:28 AM, Blake Dunlap wrote: 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
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 --hitcount 20 --name ntpv4 --rsource -j BLACKHOLE $IPTABLES -A NTP -m recent --update --seconds 5 --hitcount 2 --name ntpv4blackhole --rsource -j DROP $IPTABLES -A NTP -m recent --set --name ntpv4 --rsource -j ACCEPT $IPTABLES -A INPUT -p udp -m udp --dport 123 -j NTP I've found that blocking TCP destination NTP to client servers/networks blocks legitimate NTP synchronization for their clients. Although I wish they'd all just use my on-network NTP server, I can't assume they will. Does anyone have a list or source of pool and vendor (Apple/Microsoft/etc) servers so I can permit based on source before blocking based on destination port?
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
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 (which isn't enabled for management queries, but those are trivial to disable). $ ntpdc -c monlist -n clock.xmission.com remote address port local address count m ver code avgint lstint === 173.209.207.23342422 198.60.22.240 4727 3 3 0 0 0 24.155.184.100 45285 198.60.22.240 11 3 4 0 6 0 107.0.41.2 48625 198.60.22.240264 3 4 0 5 0 67.108.239.31 40642 198.60.22.240 77084 3 3 0 0 0 177.65.149.237 62212 198.60.22.240 1085 3 1 0 0 0 209.64.161.162 44786 198.60.22.240 19 3 4 0 7 0 103.7.36.3851618 198.60.22.240 4 3 3 0 8 0 173.209.207.21850616 198.60.22.240 4731 3 3 0 0 0 69.61.203.25 20766 198.60.22.240 16379 3 4 0 1 0 68.188.251.223 478 198.60.22.240 2 1 3 0 0 0 75.82.183.104123 198.60.22.240 1 3 4 0 0 0 63.64.124.129 52839 198.60.22.240 150867 3 4 0 0 0 65.201.33.150151 198.60.22.240393 3 2 0 3 0 124.228.119.10524687 198.60.22.240 31 3 3 0 4 0 64.191.150.130 319 198.60.22.2404494361 3 2 0 0 0 76.102.124.27123 198.60.22.240 2 3 4 0 0 0 72.235.200.183 123 198.60.22.240 1 3 4 0 0 0 50.73.42.121 10398 198.60.22.240 11 3 3 0 14 0 63.64.124.144 26984 198.60.22.2405823740 3 4 0 0 0 71.5.8.194 44699 198.60.22.240 3 3 4 0 0 0 143.112.64.21320 198.60.22.240182 1 3 0 6 0 72.235.19.125123 198.60.22.240 1 3 4 0 0 0 198.237.66.2 10471 198.60.22.240499 3 3 0 3 0 12.108.21.226357 198.60.22.240 10 1 3 0 14 0 174.47.116.250 463 198.60.22.240 24 3 4 0 5 0 72.1.71.73 738 198.60.22.240 19 3 3 0 8 0 67.136.57.101026 198.60.22.240243 3 3 0 5 0 64.199.163.5 306 198.60.22.240231 3 4 0 4 0 70.77.76.153 32188 198.60.22.240 1 3 4 0 0 0 There is no excuse to still be running a NTP server with monlist enabled. Fix your configuration, and you don't need IPTables rules. On 2/16/2014 1:29 PM, Pete Ashdown wrote: 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 --hitcount 20 --name ntpv4 --rsource -j BLACKHOLE $IPTABLES -A NTP -m recent --update --seconds 5 --hitcount 2 --name ntpv4blackhole --rsource -j DROP $IPTABLES -A NTP -m recent --set --name ntpv4 --rsource -j ACCEPT $IPTABLES -A INPUT -p udp -m udp --dport 123 -j NTP I've found that blocking TCP destination NTP to client servers/networks blocks legitimate NTP synchronization for their clients. Although I wish they'd all just use my on-network NTP server, I can't assume they will. Does anyone have a list or source of pool and vendor (Apple/Microsoft/etc) servers so I can permit based on source before blocking based on destination port?
RE: OpenNTPProject.org
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 -- Kate Gerry Network Manager k...@quadranet.com 1-888-5-QUADRA Ext 206 | www.QuadraNet.com Dedicated Servers, Colocation, Cloud Services and more. Datacenters in Los Angeles, Dallas and Miami. Follow us on: -Original Message- From: Brian Rak [mailto:b...@gameservers.com] Sent: Sunday, February 16, 2014 6:38 PM To: 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 to iptables for this, because NTPD has built in rate limiting (which isn't enabled for management queries, but those are trivial to disable). $ ntpdc -c monlist -n clock.xmission.com remote address port local address count m ver code avgint lstint === 173.209.207.23342422 198.60.22.240 4727 3 3 0 0 0 24.155.184.100 45285 198.60.22.240 11 3 4 0 6 0 107.0.41.2 48625 198.60.22.240264 3 4 0 5 0 67.108.239.31 40642 198.60.22.240 77084 3 3 0 0 0 177.65.149.237 62212 198.60.22.240 1085 3 1 0 0 0 209.64.161.162 44786 198.60.22.240 19 3 4 0 7 0 103.7.36.3851618 198.60.22.240 4 3 3 0 8 0 173.209.207.21850616 198.60.22.240 4731 3 3 0 0 0 69.61.203.25 20766 198.60.22.240 16379 3 4 0 1 0 68.188.251.223 478 198.60.22.240 2 1 3 0 0 0 75.82.183.104123 198.60.22.240 1 3 4 0 0 0 63.64.124.129 52839 198.60.22.240 150867 3 4 0 0 0 65.201.33.150151 198.60.22.240393 3 2 0 3 0 124.228.119.10524687 198.60.22.240 31 3 3 0 4 0 64.191.150.130 319 198.60.22.2404494361 3 2 0 0 0 76.102.124.27123 198.60.22.240 2 3 4 0 0 0 72.235.200.183 123 198.60.22.240 1 3 4 0 0 0 50.73.42.121 10398 198.60.22.240 11 3 3 0 14 0 63.64.124.144 26984 198.60.22.2405823740 3 4 0 0 0 71.5.8.194 44699 198.60.22.240 3 3 4 0 0 0 143.112.64.21320 198.60.22.240182 1 3 0 6 0 72.235.19.125123 198.60.22.240 1 3 4 0 0 0 198.237.66.2 10471 198.60.22.240499 3 3 0 3 0 12.108.21.226357 198.60.22.240 10 1 3 0 14 0 174.47.116.250 463 198.60.22.240 24 3 4 0 5 0 72.1.71.73 738 198.60.22.240 19 3 3 0 8 0 67.136.57.101026 198.60.22.240243 3 3 0 5 0 64.199.163.5 306 198.60.22.240231 3 4 0 4 0 70.77.76.153 32188 198.60.22.240 1 3 4 0 0 0 There is no excuse to still be running a NTP server with monlist enabled. Fix your configuration, and you don't need IPTables rules. On 2/16/2014 1:29 PM, Pete Ashdown wrote: 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 --hitcount 20 --name ntpv4 --rsource -j BLACKHOLE $IPTABLES -A NTP -m recent --update --seconds 5 --hitcount 2 --name ntpv4blackhole --rsource -j DROP $IPTABLES -A NTP -m recent --set --name ntpv4 --rsource -j ACCEPT $IPTABLES -A INPUT -p udp -m udp --dport 123 -j NTP I've found that blocking TCP destination NTP to client servers/networks blocks legitimate NTP synchronization for their clients. Although I wish they'd all just use my on-network NTP server, I can't assume they will. Does anyone have a list or source of pool and vendor (Apple/Microsoft/etc) servers so I can permit based on source before blocking based on destination port?
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 filters is the only way to mitigate the vulnerability. For those with Juniper access: http://kb.juniper.net/InfoCenter/index?page=contentid=JSA10613actp=SUBSCRIPTION It's not clear when the software patch will be made available. As it were, ScreenOS and JUNOSe are not affected, as they don't support the MONLIST feature. Mark. signature.asc Description: This is a digitally signed message part.
Re: OpenNTPProject.org
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 nopeer noquery It might be useful to note that OS X has long since included these lines in the default NTP daemon configuration (/etc/ntp-restrict.conf) thus, “No worrys, mate. James R. Cutler - james.cut...@consultant.com PGP keys at http://pgp.mit.edu signature.asc Description: Message signed with OpenPGP using GPGMail
Re: OpenNTPProject.org
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 to the admin mode shell prompt and taking a poke around /etc. signature.asc Description: Message signed with OpenPGP using GPGMail
Re: OpenNTPProject.org
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 vulnerability. 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. 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 it's sort of weird that the service on a routing platform supports more than 'the current time is XX:YY::ZZ' anyway, eh?
Re: OpenNTPProject.org
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. Presumably it would be a one-off thing until Juniper issues a patch. As for automating it, 'expect' can be a very useful tool in situations like this. --lyndon signature.asc Description: Message signed with OpenPGP using GPGMail
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 on similar tactics for other areas of Junos (including things like Cron) that some operators have done, it is with reasonable reliability that any custom changes will not persist through software upgrades. So either you add this to the to-do list each time you upgrade code, or get Juniper to fix it natively (since it is now fixed in FreeBSD). In fairness, I haven't tried to muck about with the Junos FreeBSD shell to do this, partly for the reasons above, mostly because my life is already interesting enough :-). If someone else has and can provide a different perspective, please do. Mark. signature.asc Description: This is a digitally signed message part.
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 fix the issue. You don't need to block NTP in the data plane. Mark. signature.asc Description: This is a digitally signed message part.
Re: OpenNTPProject.org
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 Junos, applying the right filters to your router's control plane will fix the issue. You don't need to block NTP in the data plane. yes, this.
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, because NTPD has built in rate limiting (which isn't enabled for management queries, but those are trivial to disable). Thanks for the tip, monitoring is off. I was under the impression that rate-limiting hadn't made it into a stable version of ntpd yet. Is that incorrect?
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 wrote: -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 unlike 5 year old wishing nothing but world peace for christmas, endearing, but it's not going to change anything. BCP38 is completely unrealistic, many access networks are on autopilot, many don't have HW support for BCP38, one port configured has low-benefit, only that machine can stop attacking (but whole world). That does *not* make it an unworthy goal, nor should it stop people from encouraging it's implementation. - - ferg (co-author of BCP38) - -- Paul Ferguson PGP Public Key ID: 0x54DC85B2 -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iF4EAREIAAYFAlLVWXoACgkQKJasdVTchbIrtAD/T2bNNAgZOnnlniBPd6sEquxJ v01mmrhJxFTIDFq7EIkA/3vQbiwtEwBeVyCtc3coEkz50zSDh3j9QQjT+TQWCNVs =Al3Y -END PGP SIGNATURE-
Re: OpenNTPProject.org
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 equipment; uRPF, ACLs, cable IP source verify, DHCP Snooping (which works just fine with fixed-address hosts), PACLs/VACLs, et. al. are some of the more prevalent mechanisms available. In point of fact, anti-spoofing is most useful and most practical at the access-network edge, or as close to it as possible. --- Roland Dobbins rdobb...@arbor.net // http://www.arbornetworks.com Luck is the residue of opportunity and design. -- John Milton
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 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 capability for it. The longer we endorse fantasy the longer it'll take to promote practical solutions. There is nothing near consensus that IP transit should or even can be ACLd, but it's really simple and I'm happy to volunteer my time with any network wishing to implement it. Very modest amount of ports will produce significant reduction in spoofing pay-off. -- ++ytti
Re: OpenNTPProject.org
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 capability for it. That may well be the case, unfortunately; my point was that at or near the access edge is the most *technically* and *topologically* feasible place to implement antispoofing mechanisms, as you indicated in your reply. --- Roland Dobbins rdobb...@arbor.net // http://www.arbornetworks.com Luck is the residue of opportunity and design. -- John Milton
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 happening in a different backyard. Except the targets are *everybody* including the access networks. This really is if you are not part of the solution, you are part of the problem and applies 100% to access networks. 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 then follow through. If you implement BCP the publish the fact on you sites. This lets others know they are not alone in the fight to make the net a better place. e.g. We implement BCP 38 on XX% of customer links We implement BCP 38 on all of our single homed customers We implement BCP 38 on all our data centers traffic We implement BCP 38 on all our NOC traffic We implement BCP 38 on all our outgoing traffic We implement BCP 38 on all our traffic Machines get owned everywhere including data centers and NOCs. BCP 38 filters should be everywhere. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
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 and the attacks are happening in a different backyard. Except the targets are *everybody* including the access networks. This really is if you are not part of the solution, you are part of the problem and applies 100% to access networks. 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 then follow through. 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? Government regulation is also not the answer. They can't all agree on basic crap, much less on some esoteric (in their opinion) netgeekery thingie... scott
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. It's not much, but it's something. Government regulation is also not the answer. They can't all agree on basic crap, much less on some esoteric (in their opinion) netgeekery thingie... Just have the NSA paint it as a national security issue. :) Doug
Re: OpenNTPProject.org
--- 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 that not being used as a botnet will reduce their outbound traffic. It's not much, but it's something. -- Maybe it's just Hawaii, but many managers I've had would not be able to understand the importance of that. CEOs? ferget it! Plus I've done only eyeball networks since the early 2000s, so outbound is orders of magnitude lower than inbound and that also means I'm probably biased. I do those things trying to be a good netizen, but I don't tell the managers. It's not even on their radars. Further, I have met a lot of enterprise-level network folks along the way that don't know and/or just don't care. Government regulation is also not the answer. They can't all agree on basic crap, much less on some esoteric (in their opinion) netgeekery thingie... Just have the NSA paint it as a national security issue. :) -- Since they're p0wning the entire internet globally that's one way to get it implemented, I suppose... :) scott
BCP38.info (was: Re: OpenNTPProject.org)
- 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 network and then follow through. 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? Government regulation is also not the answer. They can't all agree on basic crap, much less on some esoteric (in their opinion) netgeekery thingie... Then we aren't doing our educational job correctly. In part, that's my fault, because I dropped the ball on http://www.bcp38.info So let me pick the ball back up: would everyone who has asserted in this thread that BCP38 is the New Hawtness from 20 years ago, please take 30 minutes out of your weekend, and go find a place 'pon that wiki that you can usefully apply a Vulcan Nerve Pinch to make it more suitable for us to wave in front of the faces of the people about whom Scott is concerned here? I have just rewritten the front page a bit, in recognition of the fact that as it was, it did not really address that audience itself, but more detail work on the interior about who should enable BCP38 filtering, how they can do it, and why they don't -- and why those reasons are spurious -- would be very helpful. Cheers, -- jra -- Jay R. Ashworth Baylink j...@baylink.com Designer The Things I Think RFC 2100 Ashworth Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274
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 future, I hope! For now I'd just like to mention that OpenNTPD, from the OpenBSD project, is immune to the kind of large NTP amplification attacks now being discussed. It's certainly a good fit for some organizations/setups. http://www.openntpd.org Nicolai
Re: OpenNTPProject.org
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: https://www.team-cymru.org/ReadingRoom/Templates/secure-ntp-template.html Tony. -- f.anthony.n.finch d...@dotat.at http://dotat.at/ Forties, Cromarty: East, veering southeast, 4 or 5, occasionally 6 at first. Rough, becoming slight or moderate. Showers, rain at first. Moderate or good, occasionally poor at first.
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 is not unlike 5 year old wishing nothing but world peace for christmas, endearing, but it's not going to change anything. BCP38 is completely unrealistic, many access networks are on autopilot, many don't have HW support for BCP38, one port configured has low-benefit, only that machine can stop attacking (but whole world). That does *not* make it an unworthy goal, nor should it stop people from encouraging it's implementation. - - ferg (co-author of BCP38) - -- Paul Ferguson PGP Public Key ID: 0x54DC85B2 -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iF4EAREIAAYFAlLVWXoACgkQKJasdVTchbIrtAD/T2bNNAgZOnnlniBPd6sEquxJ v01mmrhJxFTIDFq7EIkA/3vQbiwtEwBeVyCtc3coEkz50zSDh3j9QQjT+TQWCNVs =Al3Y -END PGP SIGNATURE-
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. Yes, I should have specified 'BCP38 in access networks' as being completely unrealistic. (We do BCP38 on all ports and verify programmatically, but I know it's not at all practical solution globally for access). ACL in transit port is completely harmless, no announcements are needed for traffic to be accepted. There are very modest amount of transit ports globally and each port will create segmentation to the spoofing domains having immediate, significant effect on benefits of spoofed attacks. RPF obviously is non-starter for reasons you stated. I'd expect that to take 20 years or more. Even if new standards are defined, the old servers will only be removed when they physically fail. It would have to be carried over UDP initially and that support probably would have to live for 20 years. But new-l4-over-udp version could be deployable rapidly. I'm very optimistic that if we'd have useful L4 for DNS, significant portion of relevant DNS servers could be upgraded rapidly to support it. We may be able to use existing data for this, how many servers went from DNS source port to random source port to add entropy to reduce poisoning attack chance? Good portion of end users are running w7, w8, osx updating itself automatically, so end-user support could come automatically and not require action from users. phones, tablets etc have short upgrade cycles anyhow. Native-udp port could then be policed heavily, making reflected attacks pay-off poor and motivates rest of the users to take actions needed for new l4. My crazy proposal: get international agreement that sending spoofed packets Agreed, crazy. -- ++ytti
Re: OpenNTPProject.org
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 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 embedded versions of NTP including ILO/Service Processors and other parts of the “internet of things”. 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 :) ) 4) Please prevent packet spoofing where possible on your network. This will limit the impact of spoofed NTP or DNS (amongst others) packets from impacting the broader community. 5) Some vendors don’t have an easy way to alter the ntp configuration, or have not or won’t be updating NTP, you may need to use ACLs, firewall filters, or other methods to block this traffic. I’ve heard of many routers being used in attacks impacting the CPU usage. Take a moment and see if your devices respond to the following query/queries: ntpdc -n -c monlist 10.0.0.1 ntpdc -n -c loopinfo 10.0.0.1 ntpdc -n -c iostats 10.0.0.1 6) If you do VMs/Servers and have a template, please make sure that they do not respond to NTP requests. Thanks! - Jared -- Copyright 2014 Derek Andrew (excluding quotations) +1 306 966 4808 Information and Communications Technology University of Saskatchewan Peterson 120; 54 Innovation Boulevard Saskatoon,Saskatchewan,Canada. S7N 2V3 Timezone GMT-6 Typed but not read.
Re: OpenNTPProject.org
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 packet spoofing where possible on your network. This will limit the impact of spoofed NTP or DNS (amongst others) packets from impacting the broader community. BCP38! I am always surprised when people need crypto if they fail the simple things. 5) Some vendors don’t have an easy way to alter the ntp configuration, or have not or won’t be updating NTP, you may need to use ACLs, firewall filters, or other methods to block this traffic. I’ve heard of many routers being used in attacks impacting the CPU usage. Take a moment and see if your devices respond to the following query/queries: ntpdc -n -c monlist 10.0.0.1 ntpdc -n -c loopinfo 10.0.0.1 ntpdc -n -c iostats 10.0.0.1 And no matter if you use the above nmap or these instructions to check, also check your IPv6 addresses! You need 'restrict -6 default ignore' lines or similar as well, not just a restrict default ignore. — Bjoern A. Zeeb ? ??? ??? ??: '??? ??? ?? ??? ?? ?? ??? ??? ??? ? ? ?? ?? ? ', ? ?, ??? ? ?? ?, ?.???
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 going to change anything. BCP38 is completely unrealistic, many access networks are on autopilot, many don't have HW support for BCP38, one port configured has low-benefit, only that machine can stop attacking (but whole world). near term, reducing attack surface is practical to reduce impact (not a solution, just damage control) near term, transit providers who do BGP prefix-list, could use same prefix-list for ACL, segmenting spoofing domains. It's very high pay-off, couple ports configured, whole downstream branch isolated into its own spoofing domain, able to just attack targets inside same domain. mid term, transport area in IETF. DNS, NTP, SNMP, chargen et.al. could trivially change to QUIC/MinimaLT or compared, getting same 0 RTT penalty as UDP without reflection potential. -- ++ytti
