|
From: Mij <mi...@bi...> - 2009-01-15 09:49:10
|
Committed, thanks.
Please report if the version currently in SVN still has this effect.
michele
On Jan 15, 2009, at 2:35 AM, Keven Tipping wrote:
> Found the problem.
>
> On some BSD's, fgets might be interrupted during read. This is
> different from sending the program a SIGINT (which is handled
> elsewhere and has nothing to do with this issue).
> When fgets is interrupted, it automatically returns NULL and sets
> errno to EINTR (interrupted). Since the main while loop of sshguard
> assumes that fgets doesn't return NULL so long as it's working
> properly and reading from stdin, the loop exits and shuts down
> sshguard. If sshguard is launched via syslogd, then it gets relaunched
> until fgets bombs out again, causing sshguard to shutdown. This seems
> to repeat indefinitely and there *are* cases of this happening on
> google (if you check the syslog time stamp, you can see sshguard is
> exiting at random times).
>
> I've included a patch that resolves this issue. It should be cross-
> platform compliant and basically acts as a drop-in replacement fgets
> wrapper (aptly called "safe_fgets"). It will handle EOF and error
> conditions properly, ignoring any spurious EINTR issues, since those
> are non-critical and do NOT impact the operation of the program (not
> anymore, at least).
>
> Since program signaling is handled elsewhere, sshguard will still
> properly exit and relaunch when logs are rotated via syslog/syslog-ng/
> whatever. This simply fixes the issue of sshguard exiting prematurely
> due to some weird behavior with fgets on other platforms (primarily
> BSD, it appears).
>
> I've confirmed sshguard has been running for more then ~4 hours on my
> OpenBSD box(s). It is blocking and releasing IP's properly without
> exiting inbetween. It has exited and relaunched /once/ exactly on the
> hour when authlog was rotated, but other then that it's 100% stable
> now.
>
> -KT
>
> <------SNIP SNIP------>
> --- ./sshguard.c Wed Jan 14 18:16:09 2009
> +++ /root/sshguard.c Wed Jan 14 18:15:35 2009
> @@ -89,6 +89,8 @@ static inline void attackerinit(attacker_t
> *restrict i
> static void usage(void);
> /* comparison operator for sorting offenders list */
> static int lastAttackComparator(const void *a, const void *b);
> +/* safe fgets function */
> +char *safe_fgets(char *s, int size, FILE *stream);
> /* handler for termination-related signals */
> void sigfin_handler(int signo);
> /* handler for suspension/resume signals */
> @@ -213,7 +215,7 @@ int main(int argc, char *argv[]) {
> opts.abuse_threshold, (unsigned
> int)opts.pardon_threshold, (unsigned int)opts.stale_threshold);
>
>
> - while (fgets(buf, MAX_LOGLINE_LEN, stdin) != NULL) {
> + while (safe_fgets(buf, MAX_LOGLINE_LEN, stdin) != NULL) {
> if (suspended) continue;
>
> retv = parse_line(buf);
> @@ -233,6 +235,23 @@ int main(int argc, char *argv[]) {
> exit(0);
> }
>
> +char *safe_fgets(char *s, int size, FILE *stream) {
> + for (;;) {
> + if (fgets(s, size, stream))
> + return s;
> + if (feof(stream))
> + return NULL;
> + if(!ferror(stream)) {
> + sshguard_log(LOG_ERR, "Error reading from stdin:
> unknown fgets error!");
> + exit(0);
> + }
> + if(errno != EINTR) {
> + sshguard_log(LOG_ERR, "Error reading from stdin:
> fgets returned %s", strerror(errno));
> + exit(0);
> + }
> + clearerr(stream);
> + }
> +}
>
> void report_address(attack_t attack) {
> attacker_t *tmpent = NULL;
> <------SNIP SNIP------>
>
> On Jan 14, 2009, at 2:13 PM, Keven Tipping wrote:
>
>> Nope, that's not it.
>>
>> Cron is setup to run newsyslog every hour, but SSHguard terminates
>> randomly "whenever".
>>
>> As I've said, for whatever reason fgets is returning NULL and
>> breaking
>> out of the main loop. The signal handler for sigint/sigfin isn't
>> being
>> called here as it would be if syslogd or some other program was
>> sending sshguard a sigint. I'm not sure if this is a bug with fgets,
>> OpenBSD, or syslogd, but I'll try and do some debugging today and
>> figure it out.
>>
>> -KT
>>
>> On Jan 14, 2009, at 12:01 PM, Mij wrote:
>>
>>> Hello Keven,
>>>
>>> Do you have log rotation? Log rotation causes processes to be
>>> signaled
>>> for opening the new log files. This is often the case causing those
>>> message
>>> in log files.
>>>
>>>
>>> On Jan 14, 2009, at 11:09 AM, Keven Tipping wrote:
>>>
>>>> Okay, I just did some quick debugging here.
>>>>
>>>> It appears like SSHguard is exiting the main loop in sshguard.c.
>>>> For
>>>> whatever reason, on OpenBSD 4.4, the line:
>>>> while (fgets(buf, MAX_LOGLINE_LEN, stdin) != NULL)
>>>>
>>>> Is indeed returning NULL. This causes the loop to break and exit(0)
>>>> is
>>>> called, resulting in the "Got exit signal" message. According to
>>>> google (and I'm not a programmer), this is caused either by fgets
>>>> encountering EOF or some other error.
>>>>
>>>> Any ideas to as why this is occurring?
>>>>
>>>> -KT
>>>>
>>>> On Jan 14, 2009, at 2:47 AM, Keven Tipping wrote:
>>>>
>>>>> Greetings to all.
>>>>>
>>>>> I've been trying to get SSHguard running *reliably* on several
>>>>> OpenBSD
>>>>> 4.4 boxes. They all exhibit the same problem.
>>>>>
>>>>> I've installed sshguard (both 1.4-rc2 and svn) and have it
>>>>> currently
>>>>> running as root (though I doubt this has anything to do with the
>>>>> problem) via Syslog. The relevant syslog.conf line is:
>>>>> auth.info;auth.priv |exec /usr/sbin/sshguard
>>>>>
>>>>> SSHguard launches as expected when there's authlog traffic, and
>>>>> works
>>>>> just fine. I can hammer the box from the LAN and SSHguard adds the
>>>>> IP
>>>>> addresses to the pf table. That's all fine and great.
>>>>>
>>>>> The problem is, that SSHguard constantly "exits". I'm not sure if
>>>>> this
>>>>> is a SSHguard problem or something OpenBSD related, because I
>>>>> can't
>>>>> find anything in syslog's man page about this and there's nothing
>>>>> in
>>>>> my crontabs that would otherwise interfere with SSHguard.
>>>>>
>>>>> What happens is that every ~5-20 minutes (it seems completely
>>>>> random?), SSHguard prints the following in authlog:
>>>>> "Jan 14 02:33:23 gw sshguard[28260]: Releasing 10.0.1.140 after
>>>>> 488
>>>>> seconds."
>>>>> "Jan 14 02:33:23 gw sshguard[28260]: Got exit signal, flushing
>>>>> blocked
>>>>> addresses and exiting..."
>>>>>
>>>>> 10.0.1.140 is one of /several/ systems I used to test SSHguard-
>>>>> there
>>>>> were about ~10 IP's in the blocklist in this case, the latest one
>>>>> was
>>>>> blocked/added at 02:33:07, only ~16 seconds before SSHguard once
>>>>> again
>>>>> exited for no apparent reason. Obviously, when SSHguard exited,
>>>>> the
>>>>> entire table was flushed. There's no way the last IP that was
>>>>> blocked
>>>>> had exceeded 420 seconds prior to SSHguard "getting an exit
>>>>> signal".
>>>>>
>>>>> I'm not sure why it does this. Once SSHguard cleanly exits (due to
>>>>> the
>>>>> above "signal"), syslogd restarts it as soon as there's authlog
>>>>> traffic again and SSHguard runs anywhere from 5-20 minutes before
>>>>> exiting. Rinse, repeat. It will do this all day, basically.
>>>>>
>>>>> I have no idea if this is by design, or what is going on here. Any
>>>>> ideas?
>>>>>
>>>>> Cheers,
>>>>> -KT
>>>>>
>>>>> ------------------------------------------------------------------------------
>>>>> This SF.net email is sponsored by:
>>>>> SourcForge Community
>>>>> SourceForge wants to tell your story.
>>>>> http://p.sf.net/sfu/sf-spreadtheword
>>>>> _______________________________________________
>>>>> Sshguard-users mailing list
>>>>> Ssh...@li...
>>>>> https://lists.sourceforge.net/lists/listinfo/sshguard-users
>>>>
>>>>
>>>> ------------------------------------------------------------------------------
>>>> This SF.net email is sponsored by:
>>>> SourcForge Community
>>>> SourceForge wants to tell your story.
>>>> http://p.sf.net/sfu/sf-spreadtheword
>>>> _______________________________________________
>>>> Sshguard-users mailing list
>>>> Ssh...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/sshguard-users
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> This SF.net email is sponsored by:
>>> SourcForge Community
>>> SourceForge wants to tell your story.
>>> http://p.sf.net/sfu/sf-spreadtheword
>>> _______________________________________________
>>> Sshguard-users mailing list
>>> Ssh...@li...
>>> https://lists.sourceforge.net/lists/listinfo/sshguard-users
>>
>>
>> ------------------------------------------------------------------------------
>> This SF.net email is sponsored by:
>> SourcForge Community
>> SourceForge wants to tell your story.
>> http://p.sf.net/sfu/sf-spreadtheword
>> _______________________________________________
>> Sshguard-users mailing list
>> Ssh...@li...
>> https://lists.sourceforge.net/lists/listinfo/sshguard-users
>
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by:
> SourcForge Community
> SourceForge wants to tell your story.
> http://p.sf.net/sfu/sf-spreadtheword
> _______________________________________________
> Sshguard-users mailing list
> Ssh...@li...
> https://lists.sourceforge.net/lists/listinfo/sshguard-users
|