Menu
▾
▴
sshguard-users
|
From: kaycee gb <kis...@ho...> - 2021-05-05 19:58:51
|
Hello,
I use sshguard for some time now. After some weeks I started digging in the
code and found this list explanation in blocker.c about fundamental data
structures.
> * -b). After blacklisting, the block of an attacker is released, because it$
> * has already been blocked permanently.
>From this, I understand that information about attacker blacklisted is cleared
from memory/lists/running process.
The point is that after I remove the attacker's address from firewall rules,
new "attacks" are not detected and can go smoothly.
I think it has something to do with the code here:
> /* address already blocked? (can happen for 100 reasons) */$
> if (blocklist_contains(attack)) {$
> sshguard_log(LOG_INFO, "%s has already been blocked.",$
> attack.address.value);$
> return;$
> }
sshguard thinks that address is already blocked but shouldn't that address be
released and remove from hell list when blacklisting ?
In addition, when restarting, blacklist list is updated correctly from
blacklist.db and hell list is not touched. That seems more in adequation with
the explanation above.
Where am I wrong ?
K.
|
|
From: Kevin Z. <kev...@gm...> - 2021-05-05 21:08:34
|
Hi there,
On 5/5/21 12:44 PM, kaycee gb wrote:
> The point is that after I remove the attacker's address from firewall rules,
> new "attacks" are not detected and can go smoothly.
>
> I think it has something to do with the code here:
>> /* address already blocked? (can happen for 100 reasons) */$
>> if (blocklist_contains(attack)) {$
>> sshguard_log(LOG_INFO, "%s has already been blocked.",$
>> attack.address.value);$
>> return;$
>> }
>
> sshguard thinks that address is already blocked but shouldn't that address be
> released and remove from hell list when blacklisting ?
SSHGuard assumes that nobody else is changing the firewall rules under
its control while it is running. Under this assumption, it should not be
possible for an attacker who is blacklisted to show up again. If this
does happen, SSHGuard's current behavior is to warn about it without
re-blocking the attacker.
Perhaps this behavior should change.
> From this, I understand that information about attacker blacklisted is cleared
> from memory/lists/running process.
It looks like an attacker that is blacklisted is not correctly removed
from the block list. As you point out, all of this can only happen when
SSHGuard blacklists an attacker while it's running (not loaded from the
blacklist) and the administrator changes the firewall rules under
SSHGuard's control while it is running.
What should the correct behavior be?
Regards,
Kevin
|
|
From: Jim S. <jse...@Li...> - 2021-05-05 22:24:04
|
On Wed, 5 May 2021 14:08:20 -0700 Kevin Zheng <kev...@gm...> wrote: [snip] > > SSHGuard assumes that nobody else is changing the firewall rules > under its control while it is running. That seems to me a reasonable assumption on the service's part. > Under this assumption, it > should not be possible for an attacker who is blacklisted to show > up again. If this does happen, SSHGuard's current behavior is to > warn about it without re-blocking the attacker. > > Perhaps this behavior should change. I don't think so. > [snip] > As you point out, all of this can only > happen when SSHGuard blacklists an attacker while it's running (not > loaded from the blacklist) and the administrator changes the > firewall rules under SSHGuard's control while it is running. > > What should the correct behavior be? Perhaps I'm confused, but how can an application be expected to compensate for somebody or something yanking the rug out from under it behind the scenes? Mind you: I'm still using a very old version of sshguard. It's quite possible I'm missing something key in this discussion. (E.g.: What is this "blacklist" and what is a "hell list?" I looked through my sshguard mail archive and the on-line release notes. Came up bupkis.) If I'm out-of-line, please accept my apologies. Regards, Jim -- Note: My mail server employs *very* aggressive anti-spam filtering. If you reply to this email and your email is rejected, please accept my apologies and let me know via my web form at <http://jimsun.LinxNet.com/contact/scform.php>. |
|
From: kaycee gb <kis...@ho...> - 2021-05-06 12:41:43
|
Hi, Sorry I forgot the list in first reply. Le Wed, 5 May 2021 14:08:20 -0700, Kevin Zheng <kev...@gm...> a écrit : > Hi there, > > On 5/5/21 12:44 PM, kaycee gb wrote: > > The point is that after I remove the attacker's address from firewall rules, > > new "attacks" are not detected and can go smoothly. > > > > I think it has something to do with the code here: > [...] > > > > sshguard thinks that address is already blocked but shouldn't that address > > be released and remove from hell list when blacklisting ? > > SSHGuard assumes that nobody else is changing the firewall rules under > its control while it is running. Under this assumption, it should not be > possible for an attacker who is blacklisted to show up again. I agree. When an attacker is blacklisted, he can't reach the host and/or any service, so attacker is not logged and SSHGuard will not do anything. That's seems correct. >If this > does happen, SSHGuard's current behavior is to warn about it without > re-blocking the attacker. >From what I see, when an attacker is blacklisted at runtime, and you remove the rule from firewall after blacklist time, there is no warning at all. However, when you restart SSHGuard, blacklist list is populated, firewall rules are loaded. Then if you remove attacker from firewall rules, SSHGuard does it jobs in a normal way. I mean, track attacker's cumulative score and warn about it and blacklist at threshold exceed. Then again, after this runtime blacklist, if you remove attacker from firewall, we have the situation that SSHguard do not warn again. > > Perhaps this behavior should change. The behaviour you describe is correct. I just point out that there is a difference when blacklisting at runtime compared to when blacklisting at restart. At runtime that does not match, in my opinion, with what you can read in blocker.c's explanation. > > > From this, I understand that information about attacker blacklisted is > > cleared from memory/lists/running process. > > It looks like an attacker that is blacklisted is not correctly removed > from the block list. As you point out, all of this can only happen when > SSHGuard blacklists an attacker while it's running (not loaded from the > blacklist) and the administrator changes the firewall rules under > SSHGuard's control while it is running. Blacklisting in sshguard is "forever". It happens often attacker's have dynamic ips. You may want to put an attacker in blacklist for 2 or 3 days if there are too many abuses from it. But you may want to allow this ip to access your services again after that time if there is no more "attacks" during that time and that without restarting SSHGuard. So you considere this IP "safe" again, you remove the ip from firewall, but no tracking is done anymore for new attacks. > > What should the correct behavior be? Like you said above, the blacklisted IP is not removed from hell list at runtime blacklist and should be to reflect what you can find in explanation text I mention above. Except that, about this issue, everything else seems correct at this time. I have some lines of code to "fix" this. I put fix between double quotes because in my opinion there is something to fix but don't know yet your position about that. > > Regards, > Kevin Regards, K. |
|
From: kaycee gb <kis...@ho...> - 2021-05-06 14:00:28
|
Sorry I try again for the list. Hi, Le Wed, 5 May 2021 14:08:20 -0700, Kevin Zheng <kev...@gm...> a écrit : > Hi there, > > On 5/5/21 12:44 PM, kaycee gb wrote: > > The point is that after I remove the attacker's address from firewall rules, > > new "attacks" are not detected and can go smoothly. > > > > I think it has something to do with the code here: > [...] > > > > sshguard thinks that address is already blocked but shouldn't that address > > be released and remove from hell list when blacklisting ? > > SSHGuard assumes that nobody else is changing the firewall rules under > its control while it is running. Under this assumption, it should not be > possible for an attacker who is blacklisted to show up again. I agree. When an attacker is blacklisted, he can't reach the host and/or any service, so attacker is not logged and SSHGuard will not do anything. That's seems correct. >If this > does happen, SSHGuard's current behavior is to warn about it without > re-blocking the attacker. >From what I see, when an attacker is blacklisted at runtime, and you remove the rule from firewall after blacklist time, there is no warning at all. However, when you restart SSHGuard, blacklist list is populated, firewall rules are loaded. Then if you remove attacker from firewall rules, SSHGuard does it jobs in a normal way. I mean, track attacker's cumulative score and warn about it and blacklist at threshold exceed. Then again, after this runtime blacklist, if you remove attacker from firewall, we have the situation that SSHguard do not warn again. > > Perhaps this behavior should change. The behaviour you describe is correct. I just point out that there is a difference when blacklisting at runtime compared to when blacklisting at restart. At runtime that does not match, in my opinion, with what you can read in blocker.c's explanation. > > > From this, I understand that information about attacker blacklisted is > > cleared from memory/lists/running process. > > It looks like an attacker that is blacklisted is not correctly removed > from the block list. As you point out, all of this can only happen when > SSHGuard blacklists an attacker while it's running (not loaded from the > blacklist) and the administrator changes the firewall rules under > SSHGuard's control while it is running. Blacklisting in sshguard is "forever". It happens often attacker's have dynamic ips. You may want to put an attacker in blacklist for 2 or 3 days if there are too many abuses from it. But you may want to allow this ip to access your services again after that time if there is no more "attacks" during that time and that without restarting SSHGuard. So you considere this IP "safe" again, you remove the ip from firewall, but no tracking is done anymore for new attacks. > > What should the correct behavior be? Like you said above, the blacklisted IP is not removed from hell list at runtime blacklist and should be to reflect what you can find in explanation text I mention above. Except that, about this issue, everything else seems correct at this time. I have some lines of code to "fix" this. I put fix between double quotes because in my opinion there is something to fix but don't know yet your position about that. > > Regards, > Kevin Regards, K. |
|
From: Christos C. <ch...@cr...> - 2021-05-05 22:03:57
|
> On 6 May 2021, at 00:08, Kevin Zheng <kev...@gm...> wrote:
>
> Hi there,
>
> On 5/5/21 12:44 PM, kaycee gb wrote:
>> The point is that after I remove the attacker's address from firewall rules,
>> new "attacks" are not detected and can go smoothly.
>> I think it has something to do with the code here:
>>> /* address already blocked? (can happen for 100 reasons) */$
>>> if (blocklist_contains(attack)) {$
>>> sshguard_log(LOG_INFO, "%s has already been blocked.",$
>>> attack.address.value);$
>>> return;$
>>> }
>> sshguard thinks that address is already blocked but shouldn't that address be
>> released and remove from hell list when blacklisting ?
>
> SSHGuard assumes that nobody else is changing the firewall rules under its control while it is running. Under this assumption, it should not be possible for an attacker who is blacklisted to show up again. If this does happen, SSHGuard's current behavior is to warn about it without re-blocking the attacker.
>
> Perhaps this behavior should change.
>
I believe the way it works now is correct.
If you manually remove the IP from firewall table but keep the IP in blacklist.db if you reload sshguard it will block it again.
So why not remove the IP from blacklist.db and then reload sshguard?
|
|
From: kaycee gb <kis...@ho...> - 2021-05-06 12:43:57
|
Sorry forgot the list in first reply. Le Thu, 6 May 2021 00:46:25 +0300, Christos Chatzaras <ch...@cr...> a écrit : > > On 6 May 2021, at 00:08, Kevin Zheng <kev...@gm...> wrote: > > > > Hi there, > > > > On 5/5/21 12:44 PM, kaycee gb wrote: > [...] > [...] > [...] > > > > SSHGuard assumes that nobody else is changing the firewall rules under its > > control while it is running. Under this assumption, it should not be > > possible for an attacker who is blacklisted to show up again. If this does > > happen, SSHGuard's current behavior is to warn about it without re-blocking > > the attacker. > > > > Perhaps this behavior should change. > > > > I believe the way it works now is correct. > > If you manually remove the IP from firewall table but keep the IP in > blacklist.db if you reload sshguard it will block it again. > > So why not remove the IP from blacklist.db and then reload sshguard? I for example do not want to loose the score tracking for other attackers when releasing one ip ;) K. |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X