[j-nsp] Loopback Filter - NTP Question

[Wojciech Owczarek]

On 4 February 2014 21:24, Chad Myers <Chad.Myers at theice.com> wrote:

> If it requires an address, you can put the loopback address 127.0.0.1/32on the loopback interface itself.
>
> It is possible to add "disable monitor" to /var/etc/ntp.conf to disable
> the monlist command.  The caveat is that a full commit (or rollback) will
> recreate ntp.conf and delete the entry.  Picking up a hint from another
> thread on the list I set up a cron job in /etc/crontab.sys to check the
> config file every few minutes.  If the entry is missing, it puts it back
> and pokes ntp to reread its configuration.  Works quite nicely although I
> think crontab.sys may get rewritten on upgrade.
>
> crontab.sys entry:
> */5     *       *       *       *       root    sh
> /var/home/cmyers/xntp-disable_monitor.sh
>
> Do a "commit full" after adding the entry to crontab.sys to get it picked
> up.
>


I think it may be more graceful to edit the user rather the system crontab.
Just run crontab -e from root or any other user, this will use
/var/cron/tabs/username. Juniper even mention cron jobs in their knowledge
base, but there's no mention of those changes being persistent across
upgrades (one way to find out). You can run periodic CLI commands and slax
scripts with the event manager ( event-options generate-event time-interval
... ), but again, you can't run individual shell commands from JunOS CLI or
slax.

As a side note to the NTP issue, I always wondered why they wouldn't allow
the user to supply their own config files for certain daemons (I mean,
making this part of the config). Maybe not for chassisd, but at least for
NTP this makes a lot of sense, and you wouldn't have to wait for a vendor's
update to remedy the monlist problem. On one hand, scary how a vendor can
completely rely on ntpd's default options and use an empty config file
(just goes to show how people take NTP for granted) - on the other hand, I
find it amusing how suddenly people are applying loopback filters in panic.
I thought it's standard practice to protect the RE as tight as possible.
Well, unless you actually serve NTP from your router to external, untrusted
clients.


Regards
Wojciech