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
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
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
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
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
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
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
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
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
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
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
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
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
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 --
14 matches
Mail list logo