Re: [SSHGuard-users] [Proposal] Handle End-of-line comments in Whitelists

[Kevin B. <kev...@gm...>]

On 2020/05/14 00:58, Kevin Zheng wrote:
> On 5/13/20 2:33 AM, Kevin Buckley wrote:
>> Furthermore, would there be any interest in having an extra flag, in
>> the blocker, that would "turn on" some logging of successful parsing
>> of the whitelist, that could then be used in testing (some people
>> here still aren't convinced) and, whilst I'm at that, I could even
>> expand the usage() function to spit out the option flags and a brief
>> description, rather than just, well, you know what it does at
>> present.
> 
> We can also add an sshguard_log() line right after whitelist_conf_fin()
> on src/blocker/blocker.c:132 that says how many address or address
> ranges are on the whitelist.
> 
> A patch to do that is attached; what do you think?
> 

Other than neededing to bump up the log level to LOG_ERR to see this
working on my test system, that would clearly be a useful addition,
however, our testing would suggest that, when the whitelist parser
"gets it wrong", then it really gets it wrong, and just segfaults*.

My "extra flag for debuging" idea would have just seen everything
dumped into the log stream by adding in some

if( debug_flag_used) then
   sshguard_log(LOG_ERR, "stuff")
fi

guards, on the understanding that, if you invoked SSHGuard with the
debug flag, you would want to see some output without needing to alter
anything else on the system outside of SSHGuard.

Then again, maybe all of SSHGuard's sshguard_log() lines could be wrapped
in such guards, thereby affording a fuller control of log output at
invocation, along the lines of a "multiple debug flags increase verbosity"
approach.

Clearly an idea that needs a bit more fleshing out,
Kevin

* What we originally found, after adding EOL comments to a whitelist file
was that SSHGuard "appeared" to work OK, except that it wasnt, and it was
only when we added a comment along the lines of:


nnn.nnn.nnn.nnn   # Host at some org but covered by range nnn.nnn.nnn.0/30 above


that we realised that the whitelist parser (whitelist_add() function)
was seeing the "/" in the comment as indication of a range and then
"not quite getting there" when parsing the full line.

Deep sorrow!