<div dir="ltr"><div class="gmail_quote"><div dir="ltr">On Wed, Mar 16, 2016 at 10:00 AM Boldt, David <<a href="mailto:dboldt@usgs.gov">dboldt@usgs.gov</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">> It might be helpful to know what OS you're using, that doesn't have a netstat command.<br>
<br>
Sapphire OS, a Linux derivative of unknown provenance, customized for use in IPAM/DHCP/DNS appliances sold by BT Diamond.<br></blockquote><div><br></div><div>I'm somewhat familiar with the BT Diamond product, but not running on an appliance. It so annoys me when vendors do that. I cannot fathom why they think it's useful to anyone when they nobble an OS - I guess they call it "hardening". I suppose you're lucky that you can even get an agent installed and running on there.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I should have taken the documentation at its word, but was led astray<br>
by Internet examples which didn't make a lot of sense to me as regex<br>
expressions. Simplifying, now:.<br>
<br>
PORT LOCAL=%:61617 REMOTE=%10.160.8.132 STATE=ESTAB MIN=3 MAX=3<br>
COLOR=yellow TEXT=ActiveMQ-DHCP<br></blockquote><div><br></div><div>Yep, that should work (providing the STATE matches). Technically, a regular expression should be anchored at the beginning (with "^") and often at the end (with "$"), and special characters like "*" and "." should be escaped (with "\"), so as to ensure you don't get an accidental match. For example, your above line would match the IP address "210.160.8.132", and I'm confident you wouldn't want it to. If you need to match a whole string exactly, don't use the percent, something like "REMOTE=10.160.8.132". Otherwise, it's safest to anchor and escape; so to match a /24 subnet, you could do "REMOTE=%^10\.168\.8\."</div><div><br></div><div>A problem I once encountered is with a PROC test where I was monitoring the presence of the "named" process for BIND DNS, so I was matching "named" and requiring exactly one instance. An operator would occasionally run something like "tail /var/log/named" and this process string would also match, alerting that there were two named processes instead of one. Using "%named" was just as bad. I then switched to using a regular expression of "%^/usr/sbin/named", which improved things somewhat, but commands like "/usr/sbin/named-checkconf" also matched and caused alerts. After a few iterations, my PROC line is now:</div><div><br></div><div><div> PROC "%^/usr/sbin/named(\s*$|\s)" 1 1 "TEXT=/usr/sbin/named"</div></div><div><br></div><div>This matches only when the command starts with /usr/sbin/named and either ends there (optionally with trailing spaces) or has a space (presumably followed by command-line arguments).</div><div><br></div><div>Anyhow, the moral of the story is, regular expressions should use adequate anchoring and escaping.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">and working<br></blockquote><div><br></div><div>I'm puzzled why this works if the STATE isn't in column 5, as is the case for the "ss" command. Unless you also modified the "ss" command to create column 5, as I suggested.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">> The analysis.cfg file has several examples for the use of LOCAL. The REMOTE usage is the same.<br>
<br>
ah, but none of the LOCAL examples specifies an IP address, only port distinctions.<br></blockquote><div><br></div><div>Except for this one:</div><div><br></div><div><div># Example: Check that ONLY ports 22, 80 and 443 are open for incoming connections:</div><div># PORT STATE=LISTEN LOCAL=%0.0.0.0[.:].* EXLOCAL=%[.:](22|80|443)$ MAX=0 "TEXT=Bad listeners"</div></div><div><br></div><div>Although this perhaps isn't the best example for what you were trying to do. (Not to mention that it didn't escape the dots, nor anchor. However in this example the matching happens to be unambiguous for the possible strings - it would be unusual to see any other IP address matching the regexp in the example.)</div><div><br></div><div>Nevertheless, it looks like you have a solution. It's always nice to see Xymon working with appliances - despite the best efforts of the vendors.</div><div><br></div><div>Cheers</div><div>Jeremy</div><div><br></div></div></div>