sshguard-users — User questions and answers, bugs, and general support

Re: [SSHGuard-users] More debugging output

[Frank S. <fst...@bi...>]

Kevin Zheng wrote:

> On 9/27/18 2:55 AM, Frank Steiner wrote:
>> Hi,
>>
>> just a little proposal for an improvment: trying to figure out why certain
>> actions get the matches/score they do, it would be very helpful if the
>> "Attack from..." messages could contain the rule that matched. Like
>> "Attack from xxx on service 100 (SSH_MAXAUTH) with danger.."
>>
>> I had to patch that myself to figure out why so many rules matched
>> for my ssh, but I just added stupid print statements in attack_scanner.c,
>> so I cannot offer a valid patch for this.
> 
> Have you tried running sshg-parser in libexec? The output is currently a
> bit cryptic, but it'll tell you which rule was matched.

Hmm, if I feed journalctl to sshg-parser I only get lines like
100 x.x.x.x 4 10
100 x.x.x.x 4 3

These are two different rules, the first one is the unknown user, the
second one the maximum reached as I patched that one to score 3.

-- 
Dipl.-Inform. Frank Steiner   Web:  http://www.bio.ifi.lmu.de/~steiner/
Lehrstuhl f. Bioinformatik    Mail: http://www.bio.ifi.lmu.de/~steiner/m/
LMU, Amalienstr. 17           Phone: +49 89 2180-4049
80333 Muenchen, Germany       Fax:   +49 89 2180-99-4049
* Rekursion kann man erst verstehen, wenn man Rekursion verstanden hat. *

Re: [SSHGuard-users] More debugging output

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

On 9/27/18 2:55 AM, Frank Steiner wrote:
> Hi,
> 
> just a little proposal for an improvment: trying to figure out why certain
> actions get the matches/score they do, it would be very helpful if the
> "Attack from..." messages could contain the rule that matched. Like
> "Attack from xxx on service 100 (SSH_MAXAUTH) with danger.."
> 
> I had to patch that myself to figure out why so many rules matched
> for my ssh, but I just added stupid print statements in attack_scanner.c,
> so I cannot offer a valid patch for this.

Have you tried running sshg-parser in libexec? The output is currently a
bit cryptic, but it'll tell you which rule was matched.

-- 
Kevin Zheng
kev...@gm... | ke...@be... | PGP: 0xC22E1090

[SSHGuard-users] More debugging output

[Frank S. <fst...@bi...>]

Hi,

just a little proposal for an improvment: trying to figure out why certain
actions get the matches/score they do, it would be very helpful if the
"Attack from..." messages could contain the rule that matched. Like
"Attack from xxx on service 100 (SSH_MAXAUTH) with danger.."

I had to patch that myself to figure out why so many rules matched
for my ssh, but I just added stupid print statements in attack_scanner.c,
so I cannot offer a valid patch for this.

cu,
Frank


-- 
Dipl.-Inform. Frank Steiner   Web:  http://www.bio.ifi.lmu.de/~steiner/
Lehrstuhl f. Bioinformatik    Mail: http://www.bio.ifi.lmu.de/~steiner/m/
LMU, Amalienstr. 17           Phone: +49 89 2180-4049
80333 Muenchen, Germany       Fax:   +49 89 2180-99-4049
* Rekursion kann man erst verstehen, wenn man Rekursion verstanden hat. *

Re: [SSHGuard-users] Scoring problems

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

Hi Frank,

Thanks for the comments.

On 9/26/18 7:38 AM, Frank Steiner wrote:
> Thus, four attacks with score 10 each are counted, giving a score of 40
> for two wrong passwords. That happens because in addition to the two
> wrong passwords (SSH_LOGINERR_PAM, I've patched the scanner to see
> which rules matched) sshguard also counts the "maximum authentication
> attempts exceeded" (ssh_maxauth) and the "Failed keyboard-interactive/pam
> for someuser" (SSH_LOGINERR_PREF).
> 
> This really makes it hard to configure sshguard in a reasonable way.
> Two wrong ftp passwords are score 20, two wrong ssh passwords are
> 40. For my config it wouldn't be neccessary to count the
> "failed keyboard-interactive" or the "max attempts" when I already
> count each wrong password.

I agree this is bad.

> I saw in the comments that the rule SSH_LOGINERR_PREF was meant for
> Ubuntu, the SSH_LOGINERR_PAM for FreeBSD/Debian, but for our SuSE
> system they match both.

As you point out, it's hard to keep the rules generally applicable but
also avoid duplicates.

> I see only two ways to solve this problem in general: Either you
> define groups of commands that mean the same  and are only counted
> as one attack. But it might  be very hard to figure out e.g which
> pam messages belong to with sshd parent process if several connections
> are done in parallel.

Exactly.

> Or you allow users to define which rules should be counted with
> which score in the config file. E.g. setting sth. likle this
> in sshguard.conf:
> 
> SSH_LOGINERR_PREF=0
> SSH_MAXAUTH=3
> 
> That would sshguard cause to ignore the "Failed keyboard-interactive/pam"
> and counting the "max attempt" message with score 3 only.
> 
> This would allow every admin to adjust scoring to his/her specific
> needs, even different settings for several hosts.

Perhaps this is the better solution.

-- 
Kevin Zheng
kev...@gm... | ke...@be... | PGP: 0xC22E1090

[SSHGuard-users] Scoring problems

[Frank S. <fst...@bi...>]

Hi,

trying to make my sshguard config valid against the currently running
ssh attacks I stepped again on the problem of multiple counts of the
same action with ssh.

Here's an example. Our ssh config has MaxAuthTries=3. Invalid ssh keys
are counted as failed try and our default is that every user has one
key for hosts inside our network. For some hosts keys are not allowed,
so ssh will accept two password tries to login.

Assuming that both are wrong, here's what journalctl shows:

Sep 26 16:14:33 galois sshd[19429]: Postponed keyboard-interactive for someuser from x.x.x.x port 39022 ssh2 [preauth]
Sep 26 16:14:36 myhost sshd[19431]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=x.x.x.x  user=someuser
Sep 26 16:14:38 myhost sshd[19429]: error: PAM: Authentication failure for someuser from x.x.x.x
Sep 26 16:14:38 myhost sshguard[17898]: matched SSH_LOGINERR_PAM
Sep 26 16:14:38 myhost sshguard[17903]: Attack from "x.x.x.x" on service 100 with danger 10.
Sep 26 16:14:38 myhost sshd[19429]: Postponed keyboard-interactive for someuser from x.x.x.x port 39022 ssh2 [preauth]
Sep 26 16:14:38 myhost sshd[19434]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=x.x.x.x  user=someuser
Sep 26 16:14:40 myhost sshd[19429]: error: PAM: Authentication failure for someuser from x.x.x.x
Sep 26 16:14:40 myhost sshd[19429]: Failed keyboard-interactive/pam for someuser from x.x.x.x port 39022 ssh2
Sep 26 16:14:40 myhost sshguard[17903]: Attack from "x.x.x.x" on service 100 with danger 10.
Sep 26 16:14:40 myhost sshd[19429]: error: maximum authentication attempts exceeded for someuser from x.x.x.x port 39022 ssh2 [preauth]
Sep 26 16:14:40 myhost sshd[19429]: Disconnecting: Too many authentication failures [preauth]
Sep 26 16:14:40 myhost sshguard[17903]: Attack from "x.x.x.x" on service 100 with danger 10.
Sep 26 16:14:40 myhost sshguard[17898]: matched SSH_LOGINERR_PAM
Sep 26 16:14:40 myhost sshguard[17898]: matched SSH_LOGINERR_PREF
Sep 26 16:14:40 myhost sshguard[17898]: matched SSH_ADDR_SUFF
Sep 26 16:14:40 myhost sshguard[17898]: matched ssh_maxauth
Sep 26 16:14:40 myhost sshguard[17898]: matched SSH_ADDR_SUFF
Sep 26 16:14:40 myhost sshguard[17903]: Attack from "x.x.x.x" on service 100 with danger 10.


Thus, four attacks with score 10 each are counted, giving a score of 40
for two wrong passwords. That happens because in addition to the two
wrong passwords (SSH_LOGINERR_PAM, I've patched the scanner to see
which rules matched) sshguard also counts the "maximum authentication
attempts exceeded" (ssh_maxauth) and the "Failed keyboard-interactive/pam
for someuser" (SSH_LOGINERR_PREF).

This really makes it hard to configure sshguard in a reasonable way.
Two wrong ftp passwords are score 20, two wrong ssh passwords are
40. For my config it wouldn't be neccessary to count the
"failed keyboard-interactive" or the "max attempts" when I already
count each wrong password.

I saw in the comments that the rule SSH_LOGINERR_PREF was meant for
Ubuntu, the SSH_LOGINERR_PAM for FreeBSD/Debian, but for our SuSE
system they match both.

I see only two ways to solve this problem in general: Either you
define groups of commands that mean the same  and are only counted
as one attack. But it might  be very hard to figure out e.g which
pam messages belong to with sshd parent process if several connections
are done in parallel.

Or you allow users to define which rules should be counted with
which score in the config file. E.g. setting sth. likle this
in sshguard.conf:

SSH_LOGINERR_PREF=0
SSH_MAXAUTH=3

That would sshguard cause to ignore the "Failed keyboard-interactive/pam"
and counting the "max attempt" message with score 3 only.

This would allow every admin to adjust scoring to his/her specific
needs, even different settings for several hosts.

cu,
Frank


-- 
Dipl.-Inform. Frank Steiner   Web:  http://www.bio.ifi.lmu.de/~steiner/
Lehrstuhl f. Bioinformatik    Mail: http://www.bio.ifi.lmu.de/~steiner/m/
LMU, Amalienstr. 17           Phone: +49 89 2180-4049
80333 Muenchen, Germany       Fax:   +49 89 2180-99-4049
* Rekursion kann man erst verstehen, wenn man Rekursion verstanden hat. *

Re: [SSHGuard-users] configure-script does not honour --libexecprefix

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

On 9/18/18 5:57 AM, Christopher Engelhard wrote:
> I'm trying to install sshguard to a non-standard location and stumbled
> upon the following problem: When setting the location using ./configure
> --prefix=<location>, sshguard installs to the specified path, but when
> executed looks for the sshg-...-binaries in /usr/local/libexec
> nonetheless. The same happens when the various paths are specified
> individually via --libexecdir=... etc. This appears to exclusively
> affect libexecdir, not e.g. sysconfdir.
> 
> Running sshguard-2.2.0 on Fedora Server 28
> Steps to reproduce:
> 1) Run ./configure --prefix=/opt && make && make install
> 2) copy example config file to /opt/etc/sshguard.conf and set backend
> 3) execute /opt/sbin/sshguard
> 
> SSHGuard will fail with the following error:
> "sshguard: '/usr/local/libexec/sshg-fw-iptables' is not executable"

Could you show your sshguard.conf?

I suspect what happened here is that you uncommented the default BACKEND
without changing it.

-- 
Kevin Zheng
kev...@gm... | ke...@be... | PGP: 0xC22E1090

[SSHGuard-users] configure-script does not honour --libexecprefix

[Christopher E. <ce...@lc...>]

Hi,
I'm trying to install sshguard to a non-standard location and stumbled 
upon the following problem: When setting the location using ./configure 
--prefix=<location>, sshguard installs to the specified path, but when 
executed looks for the sshg-...-binaries in /usr/local/libexec 
nonetheless. The same happens when the various paths are specified 
individually via --libexecdir=... etc. This appears to exclusively 
affect libexecdir, not e.g. sysconfdir.

Running sshguard-2.2.0 on Fedora Server 28
Steps to reproduce:
1) Run ./configure --prefix=/opt && make && make install
2) copy example config file to /opt/etc/sshguard.conf and set backend
3) execute /opt/sbin/sshguard

SSHGuard will fail with the following error:
"sshguard: '/usr/local/libexec/sshg-fw-iptables' is not executable"

Not much of a programmer, but please let me know if there is any way I 
can help further.

Best,
Christopher

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Re: [SSHGuard-users] Blacklisting

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

On 8/17/18 9:50 AM, Jos Chrispijn wrote:
> Can you tell me if the blacklist.db is for ip's that are banned forever
> or is it also used for certain amount of time (180, 360, 720 secs)after
> an ip is removed again from it?

Everything that goes into blacklist.db is banned permanently; the block
does not expire and is reloaded once SSHGuard restarts.

There are plans to persist regular blocks across restarts and make
blacklists a very, very long persistent ban.

-- 
Kevin Zheng
kev...@gm... | ke...@be... | PGP: 0xC22E1090

Re: [SSHGuard-users] Adding IP to blacklist manually

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

On 8/17/18 9:53 AM, Jos Chrispijn wrote:
> Kev, can you tell me how I can add an IP address manually to the
> blacklist.db?
> Is there a commandline for that or is it just open the file, copy the
> last line, change the IP address into the desired one, save it and
> restart SSHguard service?

There is no command-line. That's currently the way to do it.

-- 
Kevin Zheng
kev...@gm... | ke...@be... | PGP: 0xC22E1090

[SSHGuard-users] Adding IP to blacklist manually

[Jos C. <jo...@cl...>]

Kev, can you tell me how I can add an IP address manually to the 
blacklist.db?
Is there a commandline for that or is it just open the file, copy the 
last line, change the IP address into the desired one, save it and 
restart SSHguard service?

Thanks,
Jos

#CSSis {beautiful};

[SSHGuard-users] Blacklisting

[Jos C. <jo...@cl...>]

Can you tell me if the blacklist.db is for ip's that are banned forever 
or is it also used for certain amount of time (180, 360, 720 secs)after 
an ip is removed again from it?

Thanks,
Jos

#CSSis {beautiful};

Re: [SSHGuard-users] New 'sqlite' branch with persistent blocks

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

On 8/9/18 12:12 AM, Frank Steiner wrote:
> Remembering the temporary blocks on restart, is a great idea!
> 
> There should be a little script allowing admins to list the db and
> prune specific entries by giving an ip etc. In case one of our students
> or researchers forgot again that his username is different on his laptop
> and tried to login several times with the wrong user and got blocked :-)
> This happens from time to time, and for the moment it's easy to remove
> such entries from the txt file.

Noted, thanks for the suggestion.

-- 
Kevin Zheng
kev...@gm... | ke...@be... | PGP: 0xC22E1090

Re: [SSHGuard-users] New 'sqlite' branch with persistent blocks

[Frank S. <fst...@bi...>]

Kevin Zheng wrote:

>> Do you plan on leaving it up to the administrator to prune the blacklist
>> or will you include, by way of example in docs, a simple query on
>> dropping old records?
> 
> It will be automatic, pruning on startup and every hour or so. I just
> haven't sat down and written the query.

Remembering the temporary blocks on restart, is a great idea!

There should be a little script allowing admins to list the db and
prune specific entries by giving an ip etc. In case one of our students
or researchers forgot again that his username is different on his laptop
and tried to login several times with the wrong user and got blocked :-)
This happens from time to time, and for the moment it's easy to remove
such entries from the txt file.

cu,
Frank



-- 
Dipl.-Inform. Frank Steiner   Web:  http://www.bio.ifi.lmu.de/~steiner/
Lehrstuhl f. Bioinformatik    Mail: http://www.bio.ifi.lmu.de/~steiner/m/
LMU, Amalienstr. 17           Phone: +49 89 2180-4049
80333 Muenchen, Germany       Fax:   +49 89 2180-99-4049
* Rekursion kann man erst verstehen, wenn man Rekursion verstanden hat. *

Re: [SSHGuard-users] New 'sqlite' branch with persistent blocks

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

On 8/7/18 10:38 PM, jungle Boogie wrote:
> Nice work! It is annoying having the blacklist lost after reboots, so
> maybe this is a nice, valid solution.
> 
> Do you plan on leaving it up to the administrator to prune the blacklist
> or will you include, by way of example in docs, a simple query on
> dropping old records?

It will be automatic, pruning on startup and every hour or so. I just
haven't sat down and written the query.

-- 
Kevin Zheng
kev...@gm... | ke...@be... | PGP: 0xC22E1090

Re: [SSHGuard-users] New 'sqlite' branch with persistent blocks

[jungle B. <jun...@gm...>]

Hi Kevin,

Nice work! It is annoying having the blacklist lost after reboots, so maybe
this is a nice, valid solution.

Do you plan on leaving it up to the administrator to prune the blacklist or
will you include, by way of example in docs, a simple query on dropping old
records?

Thanks!

[SSHGuard-users] New 'sqlite' branch with persistent blocks

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

Hi there,

SSHGuard keeps an internal list in memory of recent attackers that is
lost when sshg-blocker restarts. One workaround is to enable
blacklisting and write frequent attackers to a permanent block file.

The new 'sqlite' branch on Bitbucket attempts to address this issue by
moving the in-memory list into an on-disk SQLite database. This new
branch depends on SQLite 3.

In this *experimental* branch, the '-b' flag has changed:

When '-b' is not specified, SSHGuard uses an in-memory database. If
there are no bugs, behavior should be no different than it is now.

When '-b' is specified with the argument THRESH:PATH (e.g.
120:/var/run/sshguard.db, just like now), the database is instead
written to PATH and will preserve attacks across restarts. The THRESH
specifies a blacklisting threshold, where an attacker who exceeds the
threshold will be blocked for 30 days.

WARNINGS:

The new database format is not compatible with the old blacklist format.
For now, point this to a new or non-existent file. When this is no
longer experimental, a converter script may be added.

Attacks are NOT deleted from the database AT ALL. This means the more
attacks SSHGuard sees, the bigger the database will grow. Some queries
have not been optimized and will slow down linearly with the size of the
database. Pruning old attacks will be written soon.

To use it:

https://bitbucket.org/sshguard/sshguard/branch/sqlite

Checkout by cloning the repository, then:
$ git checkout sqlite

Comments, and some initial feedback from those who are brave enough to
test this, are welcome!

-- 
Kevin Zheng
kev...@gm... | ke...@be... | PGP: 0xC22E1090

Re: [SSHGuard-users] strange log messages about dns resolving

[Frank S. <fst...@bi...>]

Daniel Aleksandersen wrote:

> OpenSUSE uses the systemd journal, doesn’t it?
> 
> Try replacing the messages file with a LOGREADER instead (this is from SSHGuard’s example conf):
> 
> LOGREADER="LANG=C /usr/bin/journalctl -afb -p info -n1 -t sshd -o cat"

Yes, that works. I missed the reason why journalctl was better than
piping the messages file, but I definitely got it now :-)

Thank you very much!

-- 
Dipl.-Inform. Frank Steiner   Web:  http://www.bio.ifi.lmu.de/~steiner/
Lehrstuhl f. Bioinformatik    Mail: http://www.bio.ifi.lmu.de/~steiner/m/
LMU, Amalienstr. 17           Phone: +49 89 2180-4049
80333 Muenchen, Germany       Fax:   +49 89 2180-99-4049
* Rekursion kann man erst verstehen, wenn man Rekursion verstanden hat. *

Re: [SSHGuard-users] strange log messages about dns resolving

[Frank S. <fra...@if...>]

Daniel Aleksandersen wrote:

> OpenSUSE uses the systemd journal, doesn’t it?
> 
> Try replacing the messages file with a LOGREADER instead (this is from SSHGuard’s example conf):
> 
> LOGREADER="LANG=C /usr/bin/journalctl -afb -p info -n1 -t sshd -o cat"

Yes, that works. I missed the reason why journalctl was better than
piping the messages file, but I definitely got it now :-)

Thank you very much!

-- 
Dipl.-Inform. Frank Steiner   Web:  http://www.bio.ifi.lmu.de/~steiner/
Lehrstuhl f. Bioinformatik    Mail: http://www.bio.ifi.lmu.de/~steiner/m/
LMU, Amalienstr. 17           Phone: +49 89 2180-4049
80333 Muenchen, Germany       Fax:   +49 89 2180-99-4049
* Rekursion kann man erst verstehen, wenn man Rekursion verstanden hat. *

Re: [SSHGuard-users] strange log messages about dns resolving

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

On 8/2/18 2:29 AM, Frank Steiner wrote:
> Hi,
> 
> I find many messages like these in my logs:
> 2018-08-02T06:15:01.862432+02:00 fermat sshguard[10448]: message
> repeated 6111 times: [ Could not resolve

This is definitely a problem in the parser. I can reproduce it in the
Git version, too.

Let me try to get a fix ASAP.

-- 
Kevin Zheng
kev...@gm... | ke...@be... | PGP: 0xC22E1090

Re: [SSHGuard-users] strange log messages about dns resolving

[Daniel A. <co...@da...>]

On Thu, Aug 2, 2018, at 12:46, Frank Steiner wrote:
> Daniel Aleksandersen wrote:
> > How are you feeding logs to SSHGuard? Could you share your configuration?
> 
> I just added these two lines at the end of /etc/sshguard.conf that came
> with sshguard-2.2.0:
> 
> BACKEND="/usr/sbin/mysshguard"
> FILES="/var/log/messages"
> 
> and left the config as is otherwise. opensuse collects everything in
> /var/log/messages, so we need to work on that file.

OpenSUSE uses the systemd journal, doesn’t it?

Try replacing the messages file with a LOGREADER instead (this is from SSHGuard’s example conf):

LOGREADER="LANG=C /usr/bin/journalctl -afb -p info -n1 -t sshd -o cat"

You can add multiple -t arguments to pull in multiple log identifiers.

Some docs:
https://doc.opensuse.org/documentation/leap/reference/html/book.opensuse.reference/cha.journalctl.html
https://www.freedesktop.org/software/systemd/man/journalctl.html

Regards,
-- 
Daniel Aleksandersen
https://www.daniel.priv.no/

Re: [SSHGuard-users] strange log messages about dns resolving

[Frank S. <fst...@bi...>]

Hi Daniel,

Daniel Aleksandersen wrote:

> How are you feeding logs to SSHGuard? Could you share your configuration?

I just added these two lines at the end of /etc/sshguard.conf that came
with sshguard-2.2.0:

BACKEND="/usr/sbin/mysshguard"
FILES="/var/log/messages"

and left the config as is otherwise. opensuse collects everything in
/var/log/messages, so we need to work on that file.

cu,
Frank

-- 
Dipl.-Inform. Frank Steiner   Web:  http://www.bio.ifi.lmu.de/~steiner/
Lehrstuhl f. Bioinformatik    Mail: http://www.bio.ifi.lmu.de/~steiner/m/
LMU, Amalienstr. 17           Phone: +49 89 2180-4049
80333 Muenchen, Germany       Fax:   +49 89 2180-99-4049
* Rekursion kann man erst verstehen, wenn man Rekursion verstanden hat. *

Re: [SSHGuard-users] strange log messages about dns resolving

[Daniel A. <co...@da...>]

How are you feeding logs to SSHGuard? Could you share your configuration?

On Thu, Aug 2, 2018, at 11:29, Frank Steiner wrote:
> Hi,
> 
> I find many messages like these in my logs:
> 2018-08-02T06:15:01.862432+02:00 fermat sshguard[10448]: message 
> repeated 6111 times: [ Could not resolve 
> 'org.freedesktop.Tracker1.Miner.Extract' to address]
> 2018-08-02T06:15:41.856787+02:00 fermat sshguard[10448]: message 
> repeated 20 times: [ Could not resolve 
> 'org.freedesktop.Tracker1.Miner.Extract' to address]
> 2018-08-02T06:15:44.902071+02:00 fermat sshguard[10448]: message 
> repeated 42 times: [ Could not resolve 'org.kde.dolphin.desktop' to 
> address]
> 2018-08-02T06:15:47.642763+02:00 fermat sshguard[10448]: Could not 
> resolve 'org.freedesktop.Tracker1.Miner.Extract' to address
> 2018-08-02T06:15:50.294792+02:00 fermat sshguard[10448]: message 
> repeated 3 times: [ Could not resolve 
> 'org.freedesktop.Tracker1.Miner.Extract' to address]
> 2018-08-02T06:15:52.619668+02:00 fermat sshguard[10448]: Could not 
> resolve 'org.kde.dolphin.desktop' to address
> 2018-08-02T06:15:53.381778+02:00 fermat sshguard[10448]: message 
> repeated 137 times: [ Could not resolve 'org.kde.dolphin.desktop' to 
> address]
> 
> Obsiously sshguard somehow considers some messages from the KDE desktop
> as attack patterns which doesn't only flood my log files but might
> also cause many unccessary dns calls or cpu works (especially the
> "repeated 6111 times" is somewhat worrying).
> 
> Below are some of the messages from dophin/tracker, maybe you can adjust
> the pattern matching so that these are ignored.
> 
> cu,
> Frank
> 
> 
> 
> 2018-08-02T06:15:07.433070+02:00 fermat 
> org.freedesktop.Tracker1.Miner.Extract[6102]: **
> 2018-08-02T06:15:07.433325+02:00 fermat 
> org.freedesktop.Tracker1.Miner.Extract[6102]: 
> ERROR:gstaudiodecoder.c:1527:gst_audio_decoder_push_buffers: assertion 
> failed: (offset + len <= av)
> 2018-08-02T06:15:07.438528+02:00 fermat sshguard[10448]: Could not 
> resolve 'org.freedesktop.Tracker1.Miner.Extract' to address
> 2018-08-02T06:15:10.243920+02:00 fermat 
> org.freedesktop.Tracker1.Miner.Extract[6102]: **
> 2018-08-02T06:15:10.244167+02:00 fermat 
> org.freedesktop.Tracker1.Miner.Extract[6102]: 
> ERROR:gstaudiodecoder.c:1527:gst_audio_decoder_push_buffers: assertion 
> failed: (offset + len <= av)
> 2018-08-02T06:15:13.259264+02:00 fermat 
> org.freedesktop.Tracker1.Miner.Extract[6102]: **
> 2018-08-02T06:15:13.259528+02:00 fermat 
> org.freedesktop.Tracker1.Miner.Extract[6102]: 
> ERROR:gstaudiodecoder.c:1527:gst_audio_decoder_push_buffers: assertion 
> failed: (offset + len <= av)
> 2018-08-02T06:15:14.848489+02:00 fermat 
> org.freedesktop.Tracker1.Miner.Extract[6102]: (tracker-extract:15277): 
> Tracker-WARNING **: Failed to update ignored file 
> 'file:///home/users/ammar/Downloads/libgd-2.1.1/examples/noIconAlpha.tga': 
> GDBus.Error:org.freedesktop.Tracker1.SparqlError.Parse: 1.267: syntax 
> error, expected variable or term
> 2018-08-02T06:15:20.330276+02:00 fermat 
> org.freedesktop.Tracker1.Miner.Extract[6102]: **
> 2018-08-02T06:15:20.330487+02:00 fermat 
> org.freedesktop.Tracker1.Miner.Extract[6102]: 
> ERROR:gstaudiodecoder.c:1527:gst_audio_decoder_push_buffers: assertion 
> failed: (offset + len <= av)
> 2018-08-02T06:15:23.285491+02:00 fermat 
> org.freedesktop.Tracker1.Miner.Extract[6102]: **
> 2018-08-02T06:15:23.285709+02:00 fermat 
> org.freedesktop.Tracker1.Miner.Extract[6102]: 
> ERROR:gstaudiodecoder.c:1527:gst_audio_decoder_push_buffers: assertion 
> failed: (offset + len <= av)
> 2018-08-02T06:15:26.283477+02:00 fermat 
> org.freedesktop.Tracker1.Miner.Extract[6102]: **
> 2018-08-02T06:15:26.283699+02:00 fermat 
> org.freedesktop.Tracker1.Miner.Extract[6102]: 
> ERROR:gstaudiodecoder.c:1527:gst_audio_decoder_push_buffers: assertion 
> failed: (offset + len <= av)
> 2018-08-02T06:15:27.842209+02:00 fermat 
> org.freedesktop.Tracker1.Miner.Extract[6102]: (tracker-extract:15616): 
> Tracker-WARNING **: Failed to update ignored file 
> 'file:///home/users/ammar/Downloads/libgd-2.1.1/examples/noIconAlpha.tga': 
> GDBus.Error:org.freedesktop.Tracker1.SparqlError.Parse: 1.267: syntax 
> error, expected variable or term
> 2018-08-02T06:15:34.608785+02:00 fermat 
> org.freedesktop.Tracker1.Miner.Extract[6102]: **
> 2018-08-02T06:15:34.609012+02:00 fermat 
> org.freedesktop.Tracker1.Miner.Extract[6102]: 
> ERROR:gstaudiodecoder.c:1527:gst_audio_decoder_push_buffers: assertion 
> failed: (offset + len <= av)
> 2018-08-02T06:15:37.263174+02:00 fermat 
> org.freedesktop.Tracker1.Miner.Extract[6102]: **
> 2018-08-02T06:15:37.263435+02:00 fermat 
> org.freedesktop.Tracker1.Miner.Extract[6102]: 
> ERROR:gstaudiodecoder.c:1527:gst_audio_decoder_push_buffers: assertion 
> failed: (offset + len <= av)
> 2018-08-02T06:15:40.268377+02:00 fermat 
> org.freedesktop.Tracker1.Miner.Extract[6102]: **
> 2018-08-02T06:15:40.268645+02:00 fermat 
> org.freedesktop.Tracker1.Miner.Extract[6102]: 
> ERROR:gstaudiodecoder.c:1527:gst_audio_decoder_push_buffers: assertion 
> failed: (offset + len <= av)
> 2018-08-02T06:15:41.849034+02:00 fermat 
> org.freedesktop.Tracker1.Miner.Extract[6102]: (tracker-extract:17051): 
> Tracker-WARNING **: Failed to update ignored file 
> 'file:///home/users/ammar/Downloads/libgd-2.1.1/examples/noIconAlpha.tga': 
> GDBus.Error:org.freedesktop.Tracker1.SparqlError.Parse: 1.267: syntax 
> error, expected variable or term
> 
> 
> 2018-08-02T06:15:44.699866+02:00 fermat org.kde.dolphin.desktop[551]: 
> org.kde.baloo: false "/org/kde/fstab/fs17.my.domain.de:/h"
> 2018-08-02T06:15:44.705027+02:00 fermat org.kde.dolphin.desktop[551]: 
> org.kde.baloo: false "/org/kde/fstab/fs16.my.domain.de:/o"
> 2018-08-02T06:15:44.710212+02:00 fermat org.kde.dolphin.desktop[551]: 
> org.kde.baloo: false "/org/kde/fstab/fs17.my.domain.de:/j"
> 2018-08-02T06:15:44.721023+02:00 fermat org.kde.dolphin.desktop[551]: 
> org.kde.baloo: false "/org/kde/fstab/fs16.my.domain.de:/p"
> 2018-08-02T06:15:44.724658+02:00 fermat org.kde.dolphin.desktop[551]: 
> org.kde.baloo: false "/org/kde/fstab/hilbert-int:/mnt/raidbiocluster"
> 2018-08-02T06:15:44.728317+02:00 fermat org.kde.dolphin.desktop[551]: 
> org.kde.baloo: false "/org/kde/fstab/einstein:/mnt/einstein"
> 2018-08-02T06:15:44.731780+02:00 fermat org.kde.dolphin.desktop[551]: 
> org.kde.baloo: false "/org/kde/fstab/fs17.my.domain.de:/l"
> 2018-08-02T06:15:44.735419+02:00 fermat org.kde.dolphin.desktop[551]: 
> org.kde.baloo: false "/org/kde/fstab/fs16.my.domain.de:/r"
> 2018-08-02T06:15:44.738813+02:00 fermat org.kde.dolphin.desktop[551]: 
> org.kde.baloo: false "/org/kde/fstab/fs16.my.domain.de:/t"
> 2018-08-02T06:15:44.742398+02:00 fermat org.kde.dolphin.desktop[551]: 
> org.kde.baloo: false "/org/kde/fstab/fs16.my.domain.de:/w"
> 2018-08-02T06:15:44.746088+02:00 fermat org.kde.dolphin.desktop[551]: 
> org.kde.baloo: false "/org/kde/fstab/fs16.my.domain.de:/st"
> 2018-08-02T06:15:44.749771+02:00 fermat org.kde.dolphin.desktop[551]: 
> org.kde.baloo: false "/org/kde/fstab/fs17.my.domain.de:/u"
> 2018-08-02T06:15:44.753462+02:00 fermat org.kde.dolphin.desktop[551]: 
> org.kde.baloo: false "/org/kde/fstab/fs17.my.domain.de:/v"
> 2018-08-02T06:15:44.757086+02:00 fermat org.kde.dolphin.desktop[551]: 
> org.kde.baloo: false "/org/kde/fstab/fs17.my.domain.de:/x"
> 2018-08-02T06:15:44.760652+02:00 fermat org.kde.dolphin.desktop[551]: 
> org.kde.baloo: false "/org/kde/fstab/fs17.my.domain.de:/y"
> 2018-08-02T06:15:44.764225+02:00 fermat org.kde.dolphin.desktop[551]: 
> org.kde.baloo: false "/org/kde/fstab/fs17.my.domain.de:/sch"
> 2018-08-02T06:15:44.767685+02:00 fermat org.kde.dolphin.desktop[551]: 
> org.kde.baloo: true "/org/kde/fstab/abel:/mnt/raidproj"
> 2018-08-02T06:15:44.771293+02:00 fermat org.kde.dolphin.desktop[551]: 
> org.kde.baloo: false "/org/kde/fstab/fs15.my.domain.de:/big"
> 2018-08-02T06:15:44.775021+02:00 fermat org.kde.dolphin.desktop[551]: 
> org.kde.baloo: false "/org/kde/fstab/hilbert-int:/var/log/apache2"
> 2018-08-02T06:15:44.778653+02:00 fermat org.kde.dolphin.desktop[551]: 
> org.kde.baloo: false "/org/kde/fstab/fs14.my.domain.de:/proj"
> 2018-08-02T06:15:44.782253+02:00 fermat org.kde.dolphin.desktop[551]: 
> org.kde.baloo: false "/org/kde/fstab/hilbert-int:/web/bio"
> 2018-08-02T06:15:44.785901+02:00 fermat org.kde.dolphin.desktop[551]: 
> org.kde.baloo: false "/org/kde/fstab/fs14.my.domain.de:/c"
> 2018-08-02T06:15:44.789337+02:00 fermat org.kde.dolphin.desktop[551]: 
> org.kde.baloo: false "/org/kde/fstab/fs14.my.domain.de:/d"
> 2018-08-02T06:15:44.793030+02:00 fermat org.kde.dolphin.desktop[551]: 
> org.kde.baloo: false "/org/kde/fstab/hilbert-int:/web/www2"
> 2018-08-02T06:15:44.796832+02:00 fermat org.kde.dolphin.desktop[551]: 
> org.kde.baloo: false "/org/kde/fstab/fs14.my.domain.de:/e"
> 2018-08-02T06:15:44.800691+02:00 fermat org.kde.dolphin.desktop[551]: 
> org.kde.baloo: false "/org/kde/fstab/hilbert-int:/mnt/raidtmpbio"
> 2018-08-02T06:15:44.804556+02:00 fermat org.kde.dolphin.desktop[551]: 
> org.kde.baloo: true "/org/kde/fstab/babbage:/export/home"
> 2018-08-02T06:15:44.808181+02:00 fermat org.kde.dolphin.desktop[551]: 
> org.kde.baloo: false "/org/kde/fstab/fs14.my.domain.de:/i"
> 2018-08-02T06:15:44.811836+02:00 fermat org.kde.dolphin.desktop[551]: 
> org.kde.baloo: false "/org/kde/fstab/hilbert-int:/mnt/raidbio"
> 2018-08-02T06:15:44.815662+02:00 fermat org.kde.dolphin.desktop[551]: 
> org.kde.baloo: false "/org/kde/fstab/fs14.my.domain.de:/k"
> 2018-08-02T06:15:44.819674+02:00 fermat org.kde.dolphin.desktop[551]: 
> org.kde.baloo: false "/org/kde/fstab/fs17.my.domain.de:/extra"
> 2018-08-02T06:15:44.823928+02:00 fermat org.kde.dolphin.desktop[551]: 
> org.kde.baloo: false "/org/kde/fstab/fs15.my.domain.de:/f"
> 2018-08-02T06:15:44.828341+02:00 fermat org.kde.dolphin.desktop[551]: 
> org.kde.baloo: false "/org/kde/fstab/hilbert-int:/web/drupalstatic/old"
> 2018-08-02T06:15:44.832414+02:00 fermat org.kde.dolphin.desktop[551]: 
> org.kde.baloo: false "/org/kde/fstab/fs16.my.domain.de:/a"
> 2018-08-02T06:15:44.836437+02:00 fermat org.kde.dolphin.desktop[551]: 
> org.kde.baloo: false "/org/kde/fstab/hilbert-int:/web/files"
> 2018-08-02T06:15:44.840300+02:00 fermat org.kde.dolphin.desktop[551]: 
> org.kde.baloo: false "/org/kde/fstab/fs15.my.domain.de:/m"
> 2018-08-02T06:15:44.844556+02:00 fermat org.kde.dolphin.desktop[551]: 
> org.kde.baloo: false "/org/kde/fstab/fs16.my.domain.de:/g"
> 2018-08-02T06:15:44.848934+02:00 fermat org.kde.dolphin.desktop[551]: 
> org.kde.baloo: false "/org/kde/fstab/fs17.my.domain.de:/b"
> 2018-08-02T06:15:44.852922+02:00 fermat org.kde.dolphin.desktop[551]: 
> org.kde.baloo: false "/org/kde/fstab/fs15.my.domain.de:/q"
> 2018-08-02T06:15:44.856990+02:00 fermat org.kde.dolphin.desktop[551]: 
> org.kde.baloo: true "/org/kde/fstab/babbage:/rpm-export"
> 2018-08-02T06:15:44.862000+02:00 fermat org.kde.dolphin.desktop[551]: 
> org.kde.baloo: false "/org/kde/fstab/fs15.my.domain.de:/s"
> 2018-08-02T06:15:44.902071+02:00 fermat sshguard[10448]: message 
> repeated 42 times: [ Could not resolve 'org.kde.dolphin.desktop' to 
> address]
> 
> 
> 
> -- 
> Dipl.-Inform. Frank Steiner   Web:  http://www.bio.ifi.lmu.de/~steiner/
> Lehrstuhl f. Bioinformatik    Mail: http://www.bio.ifi.lmu.de/~steiner/m/
> LMU, Amalienstr. 17           Phone: +49 89 2180-4049
> 80333 Muenchen, Germany       Fax:   +49 89 2180-99-4049
> * Rekursion kann man erst verstehen, wenn man Rekursion verstanden hat. *
> _______________________________________________
> sshguard-users mailing list
> ssh...@li...
> https://lists.sourceforge.net/lists/listinfo/sshguard-users
-- 
Daniel Aleksandersen
https://www.daniel.priv.no/

[SSHGuard-users] strange log messages about dns resolving

[Frank S. <fst...@bi...>]

Hi,

I find many messages like these in my logs:
2018-08-02T06:15:01.862432+02:00 fermat sshguard[10448]: message repeated 6111 times: [ Could not resolve 'org.freedesktop.Tracker1.Miner.Extract' to address]
2018-08-02T06:15:41.856787+02:00 fermat sshguard[10448]: message repeated 20 times: [ Could not resolve 'org.freedesktop.Tracker1.Miner.Extract' to address]
2018-08-02T06:15:44.902071+02:00 fermat sshguard[10448]: message repeated 42 times: [ Could not resolve 'org.kde.dolphin.desktop' to address]
2018-08-02T06:15:47.642763+02:00 fermat sshguard[10448]: Could not resolve 'org.freedesktop.Tracker1.Miner.Extract' to address
2018-08-02T06:15:50.294792+02:00 fermat sshguard[10448]: message repeated 3 times: [ Could not resolve 'org.freedesktop.Tracker1.Miner.Extract' to address]
2018-08-02T06:15:52.619668+02:00 fermat sshguard[10448]: Could not resolve 'org.kde.dolphin.desktop' to address
2018-08-02T06:15:53.381778+02:00 fermat sshguard[10448]: message repeated 137 times: [ Could not resolve 'org.kde.dolphin.desktop' to address]

Obsiously sshguard somehow considers some messages from the KDE desktop
as attack patterns which doesn't only flood my log files but might
also cause many unccessary dns calls or cpu works (especially the
"repeated 6111 times" is somewhat worrying).

Below are some of the messages from dophin/tracker, maybe you can adjust
the pattern matching so that these are ignored.

cu,
Frank



2018-08-02T06:15:07.433070+02:00 fermat org.freedesktop.Tracker1.Miner.Extract[6102]: **
2018-08-02T06:15:07.433325+02:00 fermat org.freedesktop.Tracker1.Miner.Extract[6102]: ERROR:gstaudiodecoder.c:1527:gst_audio_decoder_push_buffers: assertion failed: (offset + len <= av)
2018-08-02T06:15:07.438528+02:00 fermat sshguard[10448]: Could not resolve 'org.freedesktop.Tracker1.Miner.Extract' to address
2018-08-02T06:15:10.243920+02:00 fermat org.freedesktop.Tracker1.Miner.Extract[6102]: **
2018-08-02T06:15:10.244167+02:00 fermat org.freedesktop.Tracker1.Miner.Extract[6102]: ERROR:gstaudiodecoder.c:1527:gst_audio_decoder_push_buffers: assertion failed: (offset + len <= av)
2018-08-02T06:15:13.259264+02:00 fermat org.freedesktop.Tracker1.Miner.Extract[6102]: **
2018-08-02T06:15:13.259528+02:00 fermat org.freedesktop.Tracker1.Miner.Extract[6102]: ERROR:gstaudiodecoder.c:1527:gst_audio_decoder_push_buffers: assertion failed: (offset + len <= av)
2018-08-02T06:15:14.848489+02:00 fermat org.freedesktop.Tracker1.Miner.Extract[6102]: (tracker-extract:15277): Tracker-WARNING **: Failed to update ignored file 'file:///home/users/ammar/Downloads/libgd-2.1.1/examples/noIconAlpha.tga': GDBus.Error:org.freedesktop.Tracker1.SparqlError.Parse: 1.267: syntax error, expected variable or term
2018-08-02T06:15:20.330276+02:00 fermat org.freedesktop.Tracker1.Miner.Extract[6102]: **
2018-08-02T06:15:20.330487+02:00 fermat org.freedesktop.Tracker1.Miner.Extract[6102]: ERROR:gstaudiodecoder.c:1527:gst_audio_decoder_push_buffers: assertion failed: (offset + len <= av)
2018-08-02T06:15:23.285491+02:00 fermat org.freedesktop.Tracker1.Miner.Extract[6102]: **
2018-08-02T06:15:23.285709+02:00 fermat org.freedesktop.Tracker1.Miner.Extract[6102]: ERROR:gstaudiodecoder.c:1527:gst_audio_decoder_push_buffers: assertion failed: (offset + len <= av)
2018-08-02T06:15:26.283477+02:00 fermat org.freedesktop.Tracker1.Miner.Extract[6102]: **
2018-08-02T06:15:26.283699+02:00 fermat org.freedesktop.Tracker1.Miner.Extract[6102]: ERROR:gstaudiodecoder.c:1527:gst_audio_decoder_push_buffers: assertion failed: (offset + len <= av)
2018-08-02T06:15:27.842209+02:00 fermat org.freedesktop.Tracker1.Miner.Extract[6102]: (tracker-extract:15616): Tracker-WARNING **: Failed to update ignored file 'file:///home/users/ammar/Downloads/libgd-2.1.1/examples/noIconAlpha.tga': GDBus.Error:org.freedesktop.Tracker1.SparqlError.Parse: 1.267: syntax error, expected variable or term
2018-08-02T06:15:34.608785+02:00 fermat org.freedesktop.Tracker1.Miner.Extract[6102]: **
2018-08-02T06:15:34.609012+02:00 fermat org.freedesktop.Tracker1.Miner.Extract[6102]: ERROR:gstaudiodecoder.c:1527:gst_audio_decoder_push_buffers: assertion failed: (offset + len <= av)
2018-08-02T06:15:37.263174+02:00 fermat org.freedesktop.Tracker1.Miner.Extract[6102]: **
2018-08-02T06:15:37.263435+02:00 fermat org.freedesktop.Tracker1.Miner.Extract[6102]: ERROR:gstaudiodecoder.c:1527:gst_audio_decoder_push_buffers: assertion failed: (offset + len <= av)
2018-08-02T06:15:40.268377+02:00 fermat org.freedesktop.Tracker1.Miner.Extract[6102]: **
2018-08-02T06:15:40.268645+02:00 fermat org.freedesktop.Tracker1.Miner.Extract[6102]: ERROR:gstaudiodecoder.c:1527:gst_audio_decoder_push_buffers: assertion failed: (offset + len <= av)
2018-08-02T06:15:41.849034+02:00 fermat org.freedesktop.Tracker1.Miner.Extract[6102]: (tracker-extract:17051): Tracker-WARNING **: Failed to update ignored file 'file:///home/users/ammar/Downloads/libgd-2.1.1/examples/noIconAlpha.tga': GDBus.Error:org.freedesktop.Tracker1.SparqlError.Parse: 1.267: syntax error, expected variable or term


2018-08-02T06:15:44.699866+02:00 fermat org.kde.dolphin.desktop[551]: org.kde.baloo: false "/org/kde/fstab/fs17.my.domain.de:/h"
2018-08-02T06:15:44.705027+02:00 fermat org.kde.dolphin.desktop[551]: org.kde.baloo: false "/org/kde/fstab/fs16.my.domain.de:/o"
2018-08-02T06:15:44.710212+02:00 fermat org.kde.dolphin.desktop[551]: org.kde.baloo: false "/org/kde/fstab/fs17.my.domain.de:/j"
2018-08-02T06:15:44.721023+02:00 fermat org.kde.dolphin.desktop[551]: org.kde.baloo: false "/org/kde/fstab/fs16.my.domain.de:/p"
2018-08-02T06:15:44.724658+02:00 fermat org.kde.dolphin.desktop[551]: org.kde.baloo: false "/org/kde/fstab/hilbert-int:/mnt/raidbiocluster"
2018-08-02T06:15:44.728317+02:00 fermat org.kde.dolphin.desktop[551]: org.kde.baloo: false "/org/kde/fstab/einstein:/mnt/einstein"
2018-08-02T06:15:44.731780+02:00 fermat org.kde.dolphin.desktop[551]: org.kde.baloo: false "/org/kde/fstab/fs17.my.domain.de:/l"
2018-08-02T06:15:44.735419+02:00 fermat org.kde.dolphin.desktop[551]: org.kde.baloo: false "/org/kde/fstab/fs16.my.domain.de:/r"
2018-08-02T06:15:44.738813+02:00 fermat org.kde.dolphin.desktop[551]: org.kde.baloo: false "/org/kde/fstab/fs16.my.domain.de:/t"
2018-08-02T06:15:44.742398+02:00 fermat org.kde.dolphin.desktop[551]: org.kde.baloo: false "/org/kde/fstab/fs16.my.domain.de:/w"
2018-08-02T06:15:44.746088+02:00 fermat org.kde.dolphin.desktop[551]: org.kde.baloo: false "/org/kde/fstab/fs16.my.domain.de:/st"
2018-08-02T06:15:44.749771+02:00 fermat org.kde.dolphin.desktop[551]: org.kde.baloo: false "/org/kde/fstab/fs17.my.domain.de:/u"
2018-08-02T06:15:44.753462+02:00 fermat org.kde.dolphin.desktop[551]: org.kde.baloo: false "/org/kde/fstab/fs17.my.domain.de:/v"
2018-08-02T06:15:44.757086+02:00 fermat org.kde.dolphin.desktop[551]: org.kde.baloo: false "/org/kde/fstab/fs17.my.domain.de:/x"
2018-08-02T06:15:44.760652+02:00 fermat org.kde.dolphin.desktop[551]: org.kde.baloo: false "/org/kde/fstab/fs17.my.domain.de:/y"
2018-08-02T06:15:44.764225+02:00 fermat org.kde.dolphin.desktop[551]: org.kde.baloo: false "/org/kde/fstab/fs17.my.domain.de:/sch"
2018-08-02T06:15:44.767685+02:00 fermat org.kde.dolphin.desktop[551]: org.kde.baloo: true "/org/kde/fstab/abel:/mnt/raidproj"
2018-08-02T06:15:44.771293+02:00 fermat org.kde.dolphin.desktop[551]: org.kde.baloo: false "/org/kde/fstab/fs15.my.domain.de:/big"
2018-08-02T06:15:44.775021+02:00 fermat org.kde.dolphin.desktop[551]: org.kde.baloo: false "/org/kde/fstab/hilbert-int:/var/log/apache2"
2018-08-02T06:15:44.778653+02:00 fermat org.kde.dolphin.desktop[551]: org.kde.baloo: false "/org/kde/fstab/fs14.my.domain.de:/proj"
2018-08-02T06:15:44.782253+02:00 fermat org.kde.dolphin.desktop[551]: org.kde.baloo: false "/org/kde/fstab/hilbert-int:/web/bio"
2018-08-02T06:15:44.785901+02:00 fermat org.kde.dolphin.desktop[551]: org.kde.baloo: false "/org/kde/fstab/fs14.my.domain.de:/c"
2018-08-02T06:15:44.789337+02:00 fermat org.kde.dolphin.desktop[551]: org.kde.baloo: false "/org/kde/fstab/fs14.my.domain.de:/d"
2018-08-02T06:15:44.793030+02:00 fermat org.kde.dolphin.desktop[551]: org.kde.baloo: false "/org/kde/fstab/hilbert-int:/web/www2"
2018-08-02T06:15:44.796832+02:00 fermat org.kde.dolphin.desktop[551]: org.kde.baloo: false "/org/kde/fstab/fs14.my.domain.de:/e"
2018-08-02T06:15:44.800691+02:00 fermat org.kde.dolphin.desktop[551]: org.kde.baloo: false "/org/kde/fstab/hilbert-int:/mnt/raidtmpbio"
2018-08-02T06:15:44.804556+02:00 fermat org.kde.dolphin.desktop[551]: org.kde.baloo: true "/org/kde/fstab/babbage:/export/home"
2018-08-02T06:15:44.808181+02:00 fermat org.kde.dolphin.desktop[551]: org.kde.baloo: false "/org/kde/fstab/fs14.my.domain.de:/i"
2018-08-02T06:15:44.811836+02:00 fermat org.kde.dolphin.desktop[551]: org.kde.baloo: false "/org/kde/fstab/hilbert-int:/mnt/raidbio"
2018-08-02T06:15:44.815662+02:00 fermat org.kde.dolphin.desktop[551]: org.kde.baloo: false "/org/kde/fstab/fs14.my.domain.de:/k"
2018-08-02T06:15:44.819674+02:00 fermat org.kde.dolphin.desktop[551]: org.kde.baloo: false "/org/kde/fstab/fs17.my.domain.de:/extra"
2018-08-02T06:15:44.823928+02:00 fermat org.kde.dolphin.desktop[551]: org.kde.baloo: false "/org/kde/fstab/fs15.my.domain.de:/f"
2018-08-02T06:15:44.828341+02:00 fermat org.kde.dolphin.desktop[551]: org.kde.baloo: false "/org/kde/fstab/hilbert-int:/web/drupalstatic/old"
2018-08-02T06:15:44.832414+02:00 fermat org.kde.dolphin.desktop[551]: org.kde.baloo: false "/org/kde/fstab/fs16.my.domain.de:/a"
2018-08-02T06:15:44.836437+02:00 fermat org.kde.dolphin.desktop[551]: org.kde.baloo: false "/org/kde/fstab/hilbert-int:/web/files"
2018-08-02T06:15:44.840300+02:00 fermat org.kde.dolphin.desktop[551]: org.kde.baloo: false "/org/kde/fstab/fs15.my.domain.de:/m"
2018-08-02T06:15:44.844556+02:00 fermat org.kde.dolphin.desktop[551]: org.kde.baloo: false "/org/kde/fstab/fs16.my.domain.de:/g"
2018-08-02T06:15:44.848934+02:00 fermat org.kde.dolphin.desktop[551]: org.kde.baloo: false "/org/kde/fstab/fs17.my.domain.de:/b"
2018-08-02T06:15:44.852922+02:00 fermat org.kde.dolphin.desktop[551]: org.kde.baloo: false "/org/kde/fstab/fs15.my.domain.de:/q"
2018-08-02T06:15:44.856990+02:00 fermat org.kde.dolphin.desktop[551]: org.kde.baloo: true "/org/kde/fstab/babbage:/rpm-export"
2018-08-02T06:15:44.862000+02:00 fermat org.kde.dolphin.desktop[551]: org.kde.baloo: false "/org/kde/fstab/fs15.my.domain.de:/s"
2018-08-02T06:15:44.902071+02:00 fermat sshguard[10448]: message repeated 42 times: [ Could not resolve 'org.kde.dolphin.desktop' to address]



-- 
Dipl.-Inform. Frank Steiner   Web:  http://www.bio.ifi.lmu.de/~steiner/
Lehrstuhl f. Bioinformatik    Mail: http://www.bio.ifi.lmu.de/~steiner/m/
LMU, Amalienstr. 17           Phone: +49 89 2180-4049
80333 Muenchen, Germany       Fax:   +49 89 2180-99-4049
* Rekursion kann man erst verstehen, wenn man Rekursion verstanden hat. *

Re: [SSHGuard-users] Dynamic whitelisting IPs (Dialup/ADSL/mobile users)

[hvjunk <hv...@gm...>]

> On 23 Jul 2018, at 18:29 , Kevin Zheng <kev...@gm...> wrote:
> 
> On 7/23/18 5:44 AM, hvjunk wrote:
>> 
>>> On 23 Jul. 2018, at 14:36 , hvjunk <hv...@gm...> wrote:
>>> 
>>> Good day,
>>> 
>>> Other than an update of the whitelist file, and restarting sshguard
>>> (with all the current blocks being removed), is there another
>>> mechanism to dynamically update whitelist IPs?
>>> 
>>> The “challenge” is that I have dynamically assigned IPs, like
>>> mobile devices, that have (for various reasons) trigged the
>>> sshguard blocking. I could do the updates of the whitelist file in
>>> some way out of band, but the problem is the current blocks are
>>> then removed and “forgotten”, which I would prefer not to happen,
>>> and I don’t want to open up/whitelist /16 sized netblocks to not
>>> restart the sshguard process.
> 
> Currently, no. But there are plans to persist blocks across restarts via
> a new save file, and the same mechanism might allow runtime changes to
> the whitelist.

I would be the first to raise my hand for beta testing please ;)

> 
>>> Perhaps would the developers accept a “sshguard-control” type
>>> API/interface/program pull request?
> 
> That seems a bit complicated. Maybe changes to the file and having
> SSHGuard reload it would be better?

Hmm.. that is/was my first thought too about the whitelist file, but then I got reminded about
my problem, and that is that I’ll have to have a history file somewhere to note the previous IPs for an interface/client to remove,
which means that the file would need to be able to have comments at the end etc. to make it easy/simple to track the client’s old IP to remove etc.

That is why an dynamic control/insert mechanism was what I though would be simpler to control from other scripts etc. where you don’t need to sed/ex/awk the whitelist file

> 
>> After I sent this, I saw the source code also makes use of ipset(s),
>> and I wondered perhaps to change the sshguard rules, to also have a
>> whitelist, together with the blacklist that would be bypassing the
>> sshguard block chain?
> 
> Yes, you can work around the issue by whitelisting your addresses in the
> firewall. SSHGuard will attempt to block these addresses but if your
> rules have higher priority, they won't be blocked.

/me thinking wondering about using the ipset elsewhere in code… there is a “nomatch” option to ipset where we could insert it into the ipset with nomatch as an option. let me test/check that method

Re: [SSHGuard-users] Dynamic whitelisting IPs (Dialup/ADSL/mobile users)

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

On 7/23/18 5:44 AM, hvjunk wrote:
> 
>> On 23 Jul. 2018, at 14:36 , hvjunk <hv...@gm...> wrote:
>> 
>> Good day,
>> 
>> Other than an update of the whitelist file, and restarting sshguard
>> (with all the current blocks being removed), is there another
>> mechanism to dynamically update whitelist IPs?
>> 
>> The “challenge” is that I have dynamically assigned IPs, like
>> mobile devices, that have (for various reasons) trigged the
>> sshguard blocking. I could do the updates of the whitelist file in
>> some way out of band, but the problem is the current blocks are
>> then removed and “forgotten”, which I would prefer not to happen,
>> and I don’t want to open up/whitelist /16 sized netblocks to not
>> restart the sshguard process.

Currently, no. But there are plans to persist blocks across restarts via
a new save file, and the same mechanism might allow runtime changes to
the whitelist.

>> Perhaps would the developers accept a “sshguard-control” type
>> API/interface/program pull request?

That seems a bit complicated. Maybe changes to the file and having
SSHGuard reload it would be better?

> After I sent this, I saw the source code also makes use of ipset(s),
> and I wondered perhaps to change the sshguard rules, to also have a
> whitelist, together with the blacklist that would be bypassing the
> sshguard block chain?

Yes, you can work around the issue by whitelisting your addresses in the
firewall. SSHGuard will attempt to block these addresses but if your
rules have higher priority, they won't be blocked.

-- 
Kevin Zheng
kev...@gm... | ke...@be... | PGP: 0xC22E1090