Re: OpenNTPProject.org

2014-02-16 Thread Pete Ashdown
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

2014-02-16 Thread Christopher Morrow
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

2014-02-16 Thread Mark Tinka
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

2014-02-16 Thread Mark Tinka
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

2014-02-16 Thread Lyndon Nerenberg
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

2014-02-16 Thread Christopher Morrow
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

2014-02-16 Thread Lyndon Nerenberg
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

2014-02-16 Thread James R Cutler
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

2014-02-16 Thread Mark Tinka
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

2014-02-16 Thread Kate Gerry
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-QUAD

Re: OpenNTPProject.org

2014-02-16 Thread Brian Rak
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

Amazon network contact

2014-02-16 Thread Blair Trosper
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

Re: OpenNTPProject.org

2014-02-16 Thread Pete Ashdown
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

2014-02-16 Thread Pete Ashdown
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 --