Menu
▾
▴
sshguard-users
|
From: Robin S. <ras...@gm...> - 2016-03-18 16:28:22
|
I run sshguard with ipfw on a FreeBSD 10.2 virtual box hosted by RootBSD. The relevant firewall entry is: 50000 deny ip from table(22) to me I usually access the server from my home location through a DSL line with AT&T. If I put this rule in the firewall script, then rebooting or running the script locks me out because sshguard adds my home IP to table 22. The workaround has been to remove the rule above from /etc/firewall-rules (the firewall script), make an ssh connection, add the rule: ipfw add 50000 deny ip from table\(22\) to me Then, I look for my home IP in table 22, and upon finding it, I delete it from the table. (Otherwise, any further ssh connections from my home location get blocked). But why is this happening in the first place? Robin Smith |
|
From: Kevin Z. <kev...@gm...> - 2016-03-19 00:58:03
|
Hi Robin, On 03/18/2016 09:28, Robin Smith wrote: > I run sshguard with ipfw on a FreeBSD 10.2 virtual box hosted by > RootBSD. The relevant firewall entry is: > > 50000 deny ip from table(22) to me > > I usually access the server from my home location through a DSL line > with AT&T. If I put this rule in the firewall script, then rebooting or > running the script locks me out because sshguard adds my home IP to > table 22. The workaround has been to remove the rule above from > /etc/firewall-rules (the firewall script), make an ssh connection, add > the rule: > ipfw add 50000 deny ip from table\(22\) to me > Then, I look for my home IP in table 22, and upon finding it, I delete > it from the table. (Otherwise, any further ssh connections from my home > location get blocked). > > But why is this happening in the first place? What version of SSHGuard are you running? I'm assuming that turning off SSHGuard makes this problem go away? A temporary workaround could be to use whitelisting. But that's not super helpful if your IP address at home changes. Have you taken a look at /var/log/auth.log, grepping for your home IP, and seeing if any interesting entries turn up? Older versions of SSHGuard treated "reverse getaddrinfo" mismatches as an attack. Best, Kevin -- Kevin Zheng kev...@gm... | ke...@be... | PGP: 0xC22E1090 |
|
From: Robin S. <ras...@gm...> - 2016-03-19 01:50:49
|
On Fri, Mar 18, 2016 at 7:57 PM, Kevin Zheng <kev...@gm...> wrote:
> Hi Robin,
>
> [snip]
>
> What version of SSHGuard are you running? I'm assuming that turning off
> SSHGuard makes this problem go away?
>
>
1.6.3 (the current version in the FreeBSD ports tree).
> A temporary workaround could be to use whitelisting. But that's not
> super helpful if your IP address at home changes.
>
>
But I found the problem, and I should have seen this earlier: my home IP
was blacklisted because of a few fatfingered attempts at logging in witth
password authentication from my phone.. I could clear the IP out of table
22 by using the VNC connection to my VM, and then things were fine until I
needed to do a reboot (there were a couple of security updates in 10.2
requiring a new kernel). I had already whitelisted my DSL modem's current
IP (which usually is stable unless there's a power outage), but what I
failed to realize is that the blacklist database is loaded at startup
*before* the whitelist file and, in addition, whitelisting doesn't override
the blacklist. There's a bit of code on the web for editing
/var/db/sshguard/blacklist/.db, but I used the cruder method of deleting
the blacklist database and restarting. This does make me wonder: what
exactly is the whilelisting file for, if its entires are not overridden by
whitelisting?
> Have you taken a look at /var/log/auth.log, grepping for your home IP,
> and seeing if any interesting entries turn up?
>
Yes, that's where I found when and why my IP got into the blacklist.
> Older versions of
> SSHGuard treated "reverse getaddrinfo" mismatches as an attack.
>
>
I did think about that, but iit wasn't the problem in my case.
Thanks very much for your reply. In this case, I just didn't take a close
enough look at what was going on,so I feel like an idiot. However, this
passage from the man page for sshguard is a little pussling (under the '-b
thresh:file' option):st
"Blacklisted addresses are added to file so they can be read at
the next startup. Blacklisted addresses are never automatically
unblocked, but it is good practice to periodically clean out
stale blacklist entries."
That passage implies that there is a way to "clean out stale entries" from
the blacklist database other than simply deleting the whole thing. I seem
to have missed what that is. Do you know?
Best,
Robin Smith
|
|
From: Kevin Z. <kev...@gm...> - 2016-03-19 04:30:49
|
On 03/18/2016 18:50, Robin Smith wrote: > But I found the problem, and I should have seen this earlier: my home IP > was blacklisted because of a few fatfingered attempts at logging in > witth password authentication from my phone.. I could clear the IP out > of table 22 by using the VNC connection to my VM, and then things were > fine until I needed to do a reboot (there were a couple of security > updates in 10.2 requiring a new kernel). I had already whitelisted my > DSL modem's current IP (which usually is stable unless there's a power > outage), but what I failed to realize is that the blacklist database is > loaded at startup *before* the whitelist file and, in addition, > whitelisting doesn't override the blacklist. There's a bit of code on > the web for editing /var/db/sshguard/blacklist/.db, but I used the > cruder method of deleting the blacklist database and restarting. This > does make me wonder: what exactly is the whilelisting file for, if its > entires are not overridden by whitelisting? Right. By default, the FreeBSD rc.d script enables blacklisting. The stuff you found on the web applies to earlier versions of SSHGuard, where the blacklist file is an opaque binary. Now it's plain text; open it up using a text editor and delete the lines you don't want. Remember that you'll need to restart SSHGuard for it to load the new blacklist. Currently, the blacklist is loaded before the whitelist is. If an address appears in the whitelist, it will not be blocked or blacklisted, but if it's already in the blacklist the whitelist won't unblock it. So you'll have to delete yourself from the blacklist. I consider this behavior buggy but haven't gotten around to fixing it. > Thanks very much for your reply. In this case, I just didn't take a > close enough look at what was going on,so I feel like an idiot. However, > this passage from the man page for sshguard is a little pussling (under > the '-b thresh:file' option):st > > "Blacklisted addresses are added to file so they can be read at > the next startup. Blacklisted addresses are never automatically > unblocked, but it is good practice to periodically clean out > stale blacklist entries." > > That passage implies that there is a way to "clean out stale entries" > from the blacklist database other than simply deleting the whole thing. > I seem to have missed what that is. Do you know? Yep, it's plain text now! In the next major release I hope to automatically prune the blacklist. Best, Kevin -- Kevin Zheng kev...@gm... | ke...@be... | PGP: 0xC22E1090 |
|
From: <li...@la...> - 2016-03-19 08:39:08
|
With the blacklist in plain text now, I have a suggestion. If ultimately the blacklist is going to get an automatic prune mode, i.e. it becomes dynamic, would it be possible to have a second blacklist used by sshguard but not created by sshguard. For instance, you have a list of known bad actors that you don't even want to give the chance to be blocked. Or in the case of Tor, you have a list created by "other means" that contains the current Tor exit nodes. "Other means" is the problem of the sys admin. Just specify the format. But since the second blacklist file could be dynamic, it would need to be read periodically by sshguard. Original Message From: Kevin Zheng Sent: Friday, March 18, 2016 9:31 PM To: ssh...@li... Reply To: ssh...@li... Subject: Re: [Sshguard-users] SSHGuard blocking my home DSL IP On 03/18/2016 18:50, Robin Smith wrote: > But I found the problem, and I should have seen this earlier: my home IP > was blacklisted because of a few fatfingered attempts at logging in > witth password authentication from my phone.. I could clear the IP out > of table 22 by using the VNC connection to my VM, and then things were > fine until I needed to do a reboot (there were a couple of security > updates in 10.2 requiring a new kernel). I had already whitelisted my > DSL modem's current IP (which usually is stable unless there's a power > outage), but what I failed to realize is that the blacklist database is > loaded at startup *before* the whitelist file and, in addition, > whitelisting doesn't override the blacklist. There's a bit of code on > the web for editing /var/db/sshguard/blacklist/.db, but I used the > cruder method of deleting the blacklist database and restarting. This > does make me wonder: what exactly is the whilelisting file for, if its > entires are not overridden by whitelisting? Right. By default, the FreeBSD rc.d script enables blacklisting. The stuff you found on the web applies to earlier versions of SSHGuard, where the blacklist file is an opaque binary. Now it's plain text; open it up using a text editor and delete the lines you don't want. Remember that you'll need to restart SSHGuard for it to load the new blacklist. Currently, the blacklist is loaded before the whitelist is. If an address appears in the whitelist, it will not be blocked or blacklisted, but if it's already in the blacklist the whitelist won't unblock it. So you'll have to delete yourself from the blacklist. I consider this behavior buggy but haven't gotten around to fixing it. > Thanks very much for your reply. In this case, I just didn't take a > close enough look at what was going on,so I feel like an idiot. However, > this passage from the man page for sshguard is a little pussling (under > the '-b thresh:file' option):st > > "Blacklisted addresses are added to file so they can be read at > the next startup. Blacklisted addresses are never automatically > unblocked, but it is good practice to periodically clean out > stale blacklist entries." > > That passage implies that there is a way to "clean out stale entries" > from the blacklist database other than simply deleting the whole thing. > I seem to have missed what that is. Do you know? Yep, it's plain text now! In the next major release I hope to automatically prune the blacklist. Best, Kevin -- Kevin Zheng kev...@gm... | ke...@be... | PGP: 0xC22E1090 ------------------------------------------------------------------------------ Transform Data into Opportunity. Accelerate data analysis in your applications with Intel Data Analytics Acceleration Library. Click to learn more. http://pubads.g.doubleclick.net/gampad/clk?id=278785231&iu=/4140 _______________________________________________ Sshguard-users mailing list Ssh...@li... https://lists.sourceforge.net/lists/listinfo/sshguard-users |
|
From: Robin S. <ras...@gm...> - 2016-03-19 12:12:56
|
On Fri, Mar 18, 2016 at 11:30 PM, Kevin Zheng <kev...@gm...> wrote: [snip] > > That passage implies that there is a way to "clean out stale entries" > > from the blacklist database other than simply deleting the whole thing. > > I seem to have missed what that is. Do you know? > > Yep, it's plain text now! In the next major release I hope to > automatically prune the blacklist. > > And now that I actually look, I see that /var/db/sshguard/blacklist.db is indeed plain text. I had looked not very long ago and I'm certain it was binary. Again, my apologies for not looking. Thanks, Robin Smith |
Thanks for helping keep SourceForge clean.
X