[j-nsp] Loopback Filter - NTP Question

[Chad Myers]

If it requires an address, you can put the loopback address 127.0.0.1/32 on 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.
===
% cat xntp-disable_monitor.sh

# Basic stuff
NTP_CONF=/var/etc/ntp.conf
NTP_PROC=$(ps ax | grep xntpd | grep -v grep | awk '{printf $1}')
CHECK_ONLY=0
VERBOSE=0
my_id=$(id -u)

Print_Help ()
{
        echo "Usage: $(basename ${0}) [-q|-v] [-c]"
        echo " -q: quiet, no status messages"
        echo " -v: verbose, display status messages"
        echo " -c: check current configuration only, no changes [0=config is correct, 1+=missing config]"
        exit 255
}

# # Get command line options
# if test ${#} -eq 0
# then
#       # No command line option specified.
#       Print_Help
# fi

while getopts "qvc" opt
do
        case ${opt} in
                q) VERBOSE=0 ;;
                v) VERBOSE=1 ;;
                c) CHECK_ONLY=1 && VERBOSE=1 ;;
                *) Print_Help ;;
        esac
done

# Check the config file
if [ -r ${NTP_CONF} ]
then
        egrep "^disable monitor[ \t]*$" ${NTP_CONF} 2>&1 >/dev/null
        CFG_Status=$?
else
        echo "ERROR: Unable to read ${NTP_CONF}"
        exit 2
fi

if [ ${CFG_Status} -eq 0 ]
then
        [ ${VERBOSE} -eq 1 ] && echo "${NTP_CONF} contains the 'disable monitor' entry already."
        exit 0
fi

# Option is missing
[ ${VERBOSE} -eq 1 ] && echo "${NTP_CONF} is missing the 'disable monitor' entry."
[ ${CHECK_ONLY} -eq 1 ] && exit 1

# Need to be root to change anything
[ ${my_id} -ne 0 ] && echo "ERROR: You must be root to make any changes!" && exit 1

[ ${VERBOSE} = 1 ] && echo "Adding the 'disable monitor' entry"
echo "" >> ${NTP_CONF}
echo "disable monitor" >> ${NTP_CONF}
[ ${VERBOSE} = 1 ] && echo "Sending SIGHUP to xntpd (pid ${NTP_PROC}) so it re-reads its configuration."
kill -HUP ${NTP_PROC}
[ ${VERBOSE} = 1 ] && echo "Done."
exit 0
===


Cheers!

-Chad


On Feb 4, 2014, at 2:43 PM, Paul Stewart wrote:

> Hi there
>
> We are still finding some JunOS devices vulnerable in our network to the NTP
> issue.  For devices with an IP address on the loopback this has proven to be
> just an update to existing firewall filters where we allow the remote NTP
> servers we query from and include the loopback IP itself.
>
> Most of the remaining devices do not have an IP address on the loopback
> which has presented a new challenge we were not expecting.  If we apply an
> updated loopback firewall filter and attempt to filter NTP only to specific
> sources it will fail every time if there is no actual IP address on the
> loopback.
>
> Juniper says we must put an IP address on the loopback to work around this
> issue so I am wondering what other folks are doing in these specific
> situations?
>
> There are several options which to me the best would be to have Juniper
> actually fix this issue with a proper NTP implementation
>
> Thanks for any input
>
> Paul
>
>
>
>
> _______________________________________________
> juniper-nsp mailing list juniper-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
>


This message may contain confidential information and is intended for specific recipients unless explicitly noted otherwise. If you have reason to believe you are not an intended recipient of this message, please delete it and notify the sender. This message may not represent the opinion of IntercontinentalExchange, Inc. (ICE), its subsidiaries or affiliates, and does not constitute a contract or guarantee. Unencrypted electronic mail is not secure and the recipient of this message is expected to provide safeguards from viruses and pursue alternate means of communication where privacy or a binding message is desired.