Hi Dan,
Hi,
Thanks for your replies. It is a bit too late to implement Nagios but we
are getting along quite well with what we are using now.
I managed to create a work around for anyone interested.
So on the agent add:
<localfile>
<log_format>command</log_format>
<command>ntpq -pn</command>
<alias>ntp-alert</alias>
<frequency>3600</frequency>
</localfile>
The log will arrive as follows:
2015 Nov 05 10:25:29 (testserver) 10.55.33.18->ntp-alert ossec: output:
'ntp-alert': remote refid st t when poll reach
delay offset jitter
2015 Nov 05 10:25:29 (testserver) 10.55.33.18->ntp-alert ossec: output:
'ntp-alert':
==============================================================================
2015 Nov 05 10:25:29 (testserver) 10.55.33.18->ntp-alert ossec: output:
'ntp-alert': *10.55.11.213 91.121.169.20 3 u 60 64 177 0.331
-15.097 13.472
We are interested in the offset which is -15.097 in this case. As you
rightly pointed out Dan, there is no way to have greater than or less than.
So instead we check for 4 digits. That means the offset is more than a 1000
milliseconds. On the server then add the local decoder:
<decoder name="ntp-offset">
<parent>ossec</parent>
<prematch
offset="after_parent">'ntp-alert':\.+\s+\.+\s+\.+\s+\.+\s+\.+\s+\.+\s+\.+\s+\.+\s+</prematch>
<regex offset="after_prematch">^(\p\d\d\d\d)|(\d\d\d\d)</regex>
<order>extra_data</order>
</decoder>
I decided to leave this as open as possible. I used \.+ rather than \d+ or
\w+. This is to pickup numbers with decimal points plus there is no chance
of the decoder picking up another log because I am using
<alias>ntp-alert</alias> with the command.
In local rules then:
<group name="ntp-monitoring">
<rule id="100090" level="0">
<decoded_as>ossec</decoded_as>
<description>Custom NTP Monitoring Alerts</description>
</rule>
<rule id="100091" level="7">
<if_group>ntp-monitoring</if_group>
<extra_data>^12|^13|^14|^15|^16|^17|^18|^19|^2|^3|^4|^5|^6|^7|^8|^9</extra_data>
<description>High NTP offset</description>
</rule>
</group>
So this will alert us if the offset is between 1200 and 9999 milliseconds
which is perfectly fine with us. It can be modified to any range you like
by modifying the decoder and rule as required.
I just wanted to put this out there in case anyone has similar problems.
Thanks,
Robert
On Wednesday, November 4, 2015 at 5:30:25 PM UTC+1, dan (ddpbsd) wrote:
>
>
> On Nov 4, 2015 11:08 AM, "Robert Micallef" <[email protected]
> <javascript:>> wrote:
> >
> > Hi,
> >
> > I was wondering if anyone can help me configure a decoder and
> subsequently an alert for when the NTP offset becomes too high. For
> security reasons I had to configure a server to retrieve the time from
> outside and then all other servers retrieve the time from this first
> server. The problems is after a couple of months one or two servers will go
> out of sync by minutes. I tried to resolve the issue but can't figure out
> why NTP sometimes doesn't work well on some systems with basically the same
> configuration. So I am close to giving up on NTP.
> >
> > Anyway I was wondering if I can create an alert then so I can manually
> fix the problem when it happens. The problem is I don't know how to create
> a decoder for this. The command ntpq -pn gives out the output:
> >
> > remote refid st t when poll reach delay offset
> jitter
> >
> ==============================================================================
> > 10.55.11.213 91.121.169.20 3 u 840 1024 0 0.765 -1972.3
> 0.000
> >
> > Since the values change I don't know how to just get the offset and for
> instance alert us if it is over 1500 like in this case. For instance the
> poll is 840 now so 3 digits but will soon be 2 digits so I don't know how
> to have a decoder for that. And some numbers might have decimal points at
> one point and not have at another point.
> >
>
> There's no real way to do greater than or less than comparisons in ossec.
>
> > Another command which could work is ntpstat which gives the output:
> > synchronised to unspecified at stratum 4
> > time correct to within 16875 ms
> > polling server every 1024 s
> >
> > This I could create a decoder for but the output is so inaccurate that
> this is useless.
> >
> > Does anyone know how this can be done please?
> >
> > Thanks,
> > Robert
> >
> > --
> >
> > ---
> > You received this message because you are subscribed to the Google
> Groups "ossec-list" group.
> > To unsubscribe from this group and stop receiving emails from it, send
> an email to [email protected] <javascript:>.
> > For more options, visit https://groups.google.com/d/optout.
>
--
---
You received this message because you are subscribed to the Google Groups
"ossec-list" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/d/optout.