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
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, 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 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 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 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 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 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 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 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 mode shell prompt and taking a poke around /etc. signature.asc Description: Message signed with OpenPGP using GPGMail
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 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 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=content&id=JSA10613&actp=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
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
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?
Amazon network contact
Could someone from Amazon Web Services contact me off list? You appear to be having connectivity problems on the private network (10.0.0.0/8) at US-EAST-1 between two or more zones, causing dozens of alarms and failures over the last 2-3 hours...however, there is no notation on the status page or any hint whatsoever of the problem. (The alarms are coming from the instance checks on the instances...which is the network...not the status checks...which would be the instance's health inside the PVM virtualization.)
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 --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?
