Menu
▾
▴
sshguard-users — User questions and answers, bugs, and general support
You can subscribe to this list here.
| 2007 |
Jan
|
Feb
|
Mar
(10) |
Apr
(7) |
May
(6) |
Jun
(13) |
Jul
(4) |
Aug
|
Sep
|
Oct
(17) |
Nov
(5) |
Dec
(4) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2008 |
Jan
(2) |
Feb
|
Mar
|
Apr
(4) |
May
(2) |
Jun
(7) |
Jul
(10) |
Aug
(4) |
Sep
(14) |
Oct
|
Nov
(1) |
Dec
(7) |
| 2009 |
Jan
(17) |
Feb
(20) |
Mar
(11) |
Apr
(14) |
May
(8) |
Jun
(3) |
Jul
(22) |
Aug
(9) |
Sep
(8) |
Oct
(6) |
Nov
(4) |
Dec
(8) |
| 2010 |
Jan
(17) |
Feb
(9) |
Mar
(15) |
Apr
(24) |
May
(14) |
Jun
(1) |
Jul
(21) |
Aug
(6) |
Sep
(2) |
Oct
(2) |
Nov
(6) |
Dec
(9) |
| 2011 |
Jan
(11) |
Feb
(1) |
Mar
(3) |
Apr
(4) |
May
|
Jun
|
Jul
(2) |
Aug
(3) |
Sep
(2) |
Oct
(29) |
Nov
(1) |
Dec
(1) |
| 2012 |
Jan
(1) |
Feb
(1) |
Mar
|
Apr
(13) |
May
(4) |
Jun
(9) |
Jul
(2) |
Aug
(2) |
Sep
(1) |
Oct
(2) |
Nov
(11) |
Dec
(4) |
| 2013 |
Jan
(2) |
Feb
(2) |
Mar
(4) |
Apr
(13) |
May
(4) |
Jun
|
Jul
|
Aug
(1) |
Sep
(5) |
Oct
(3) |
Nov
(1) |
Dec
(3) |
| 2014 |
Jan
|
Feb
(3) |
Mar
(3) |
Apr
(6) |
May
(8) |
Jun
|
Jul
|
Aug
(1) |
Sep
(1) |
Oct
(3) |
Nov
(14) |
Dec
(8) |
| 2015 |
Jan
(16) |
Feb
(30) |
Mar
(20) |
Apr
(5) |
May
(33) |
Jun
(11) |
Jul
(15) |
Aug
(91) |
Sep
(23) |
Oct
(10) |
Nov
(7) |
Dec
(9) |
| 2016 |
Jan
(22) |
Feb
(8) |
Mar
(6) |
Apr
(23) |
May
(38) |
Jun
(29) |
Jul
(43) |
Aug
(43) |
Sep
(18) |
Oct
(8) |
Nov
(2) |
Dec
(25) |
| 2017 |
Jan
(38) |
Feb
(3) |
Mar
(1) |
Apr
|
May
(18) |
Jun
(2) |
Jul
(16) |
Aug
(2) |
Sep
|
Oct
(1) |
Nov
(4) |
Dec
(14) |
| 2018 |
Jan
(15) |
Feb
(2) |
Mar
(3) |
Apr
(5) |
May
(8) |
Jun
(12) |
Jul
(19) |
Aug
(16) |
Sep
(8) |
Oct
(13) |
Nov
(15) |
Dec
(10) |
| 2019 |
Jan
(9) |
Feb
(3) |
Mar
|
Apr
(2) |
May
|
Jun
(1) |
Jul
|
Aug
(5) |
Sep
(5) |
Oct
(12) |
Nov
(4) |
Dec
|
| 2020 |
Jan
(2) |
Feb
(6) |
Mar
|
Apr
|
May
(11) |
Jun
(1) |
Jul
(3) |
Aug
(22) |
Sep
(8) |
Oct
|
Nov
(2) |
Dec
|
| 2021 |
Jan
(7) |
Feb
|
Mar
(19) |
Apr
|
May
(10) |
Jun
(5) |
Jul
(7) |
Aug
(3) |
Sep
(1) |
Oct
|
Nov
(10) |
Dec
(4) |
| 2022 |
Jan
(17) |
Feb
|
Mar
(7) |
Apr
(3) |
May
|
Jun
(1) |
Jul
(3) |
Aug
|
Sep
|
Oct
(6) |
Nov
|
Dec
|
| 2023 |
Jan
|
Feb
(5) |
Mar
(1) |
Apr
(3) |
May
|
Jun
(3) |
Jul
(2) |
Aug
|
Sep
|
Oct
|
Nov
(6) |
Dec
|
| 2024 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(3) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2025 |
Jan
|
Feb
|
Mar
(15) |
Apr
(8) |
May
(10) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Christopher E. <ce...@lc...> - 2018-09-18 13:13:47
|
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. |
|
From: Kevin Z. <kev...@gm...> - 2018-08-18 01:02:50
|
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 |
|
From: Kevin Z. <kev...@gm...> - 2018-08-18 01:01:32
|
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 |
|
From: Jos C. <jo...@cl...> - 2018-08-17 16:53:39
|
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};
|
|
From: Jos C. <jo...@cl...> - 2018-08-17 16:50:14
|
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};
|
|
From: Kevin Z. <kev...@gm...> - 2018-08-09 17:32:30
|
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 |
|
From: Frank S. <fst...@bi...> - 2018-08-09 07:13:00
|
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. * |
|
From: Kevin Z. <kev...@gm...> - 2018-08-08 05:47:41
|
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 |
|
From: jungle B. <jun...@gm...> - 2018-08-08 05:38:24
|
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! |
|
From: Kevin Z. <kev...@gm...> - 2018-08-08 05:19:59
|
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 |
|
From: Frank S. <fst...@bi...> - 2018-08-06 11:32:19
|
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. * |
|
From: Frank S. <fra...@if...> - 2018-08-06 11:26:06
|
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. * |
|
From: Kevin Z. <kev...@gm...> - 2018-08-02 15:21:26
|
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 |
|
From: Daniel A. <co...@da...> - 2018-08-02 11:07:01
|
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/ |
|
From: Frank S. <fst...@bi...> - 2018-08-02 10:46:55
|
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. * |
|
From: Daniel A. <co...@da...> - 2018-08-02 10:39:24
|
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/ |
|
From: Frank S. <fst...@bi...> - 2018-08-02 09:48:35
|
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. * |
|
From: hvjunk <hv...@gm...> - 2018-07-23 18:30:58
|
> 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 |
|
From: Kevin Z. <kev...@gm...> - 2018-07-23 16:29:10
|
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 |
|
From: hvjunk <hv...@gm...> - 2018-07-23 12:44:26
|
> 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. > > Perhaps would the developers accept a “sshguard-control” type API/interface/program pull request? 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? |
|
From: hvjunk <hv...@gm...> - 2018-07-23 12:36:30
|
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. Perhaps would the developers accept a “sshguard-control” type API/interface/program pull request? HEndrik |
|
From: Kevin Z. <kev...@gm...> - 2018-07-14 15:21:10
|
On 07/13/2018 05:37, Jos Chrispijn wrote: > Sometimes I change some setting in ipfw and have to also restart SSHGuard. > > I do this by commandline > > /letc/rc.d/sshguard restart > > At that very moment I don't get my prompt back but get a display line > like this: > > *me@kriti > added: 88.164.126.91/32 0* > > which obviously is a sshguard action > > What I then do is hit Ctrl-C to stop these displays (it is every time > another IP) and that works. > > My question is however: do I kill the running sshguard process with that > and do I need to start it after again (which brings me in the same loop > as described above)? I'd have to take a closer look. Quick inspection shows that the rc.d script calls `daemon` because SSHGuard temporarily dropped support for writing the PID file. Now that SSHGuard can take the -i option again, perhaps `daemon` is no longer needed. -- Kevin Zheng kev...@gm... | ke...@be... | PGP: 0xC22E1090 |
|
From: Jos C. <ssh...@cl...> - 2018-07-13 10:38:11
|
Sometimes I change some setting in ipfw and have to also restart SSHGuard. I do this by commandline /letc/rc.d/sshguard restart At that very moment I don't get my prompt back but get a display line like this: *me@kriti > added: 88.164.126.91/32 0* which obviously is a sshguard action What I then do is hit Ctrl-C to stop these displays (it is every time another IP) and that works. My question is however: do I kill the running sshguard process with that and do I need to start it after again (which brings me in the same loop as described above)? thanks, Jos ** -- With both feed on the ground you will never make a step forward |
|
From: Kevin Z. <kev...@gm...> - 2018-07-11 17:19:09
|
Hi there, Since 2.x piping logs into SSHGuard via stdin gave a warning: # sshguard sshguard: Reading from stdin. You probably shouldn't be doing this. This behavior is being considered for removal because it prevents resolution of issue #90, where the driver script ignores signals sent to it. Note that killing the process indicated in the PID file set by '-i' continues to work, because that reports the PID of sshg-blocker. Does anyone still depend on this behavior? If so, please let me know why and what we can do to work around it. -- Kevin Zheng kev...@gm... | ke...@be... | PGP: 0xC22E1090 |
|
From: Kevin Z. <kev...@gm...> - 2018-07-10 16:24:44
|
On 07/10/2018 11:02, Christos Chatzaras wrote: > Greylisting allows a mail server to resend the e-mail after 5 > minutes. So if a mail server retries in 4 minutes does it block it? > Or it only blocks if a mail server tries to send it multiple times > during the first 5 minutes? Early retries are detected as 'attacks' with score 10. Attacks are not blocked unless the cumulative score in a time interval exceeds a threshold (by default 30), so a conforming mail server should not trigger the block if you use the defaults. -- Kevin Zheng kev...@gm... | ke...@be... | PGP: 0xC22E1090 |
2 messages has been excluded from this view by a project administrator.
