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

[SSHGuard-users] [Proposal] Handle last octet range in Whitelists

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

Hi there,

in an ideal world, groups of related hosts would always be
assigned IP addresses that saw all of the group lying within
"nice" sets of CIDR boundary ranges.

Well, it's not an ideal world, and a lot people still aren't
falling asleep at night thinking about CIDR boundaries.

With that in mind, I was hoping to use the SSHGuard codebase
so as to handle a set of IPv4 addresses that some people only
ever think of, in terms of

  aaa.bbb.ccc.[ddd.eee]

and found it didn't handle them, however, I thought it could.

It can.

The attached patch adds a block of code to

   src/blocker/sshguard_whitelist.c

that does allow people, who have better things to fall asleep
at night thinking about to, to have entries in whitelist files
that adhere to that non-CIDR format.

I tried it against various instances of aaa.bbb.ccc.[143-220]
and, whilst I wouldn't recommend anyone should do that, I did
see the expected

sshguard[12345]: whitelist: add plain IPv4 aaa.bbb.cc.143.
...
sshguard[12345]: whitelist: add plain IPv4 146.118.38.220.

set of entries being added.


It's yours if you want it: it may need some extra checking.

Note that this is IPv4 only: after all, who falls asleep at
night thinking about IPv6 addresses?

Kevin

Re: [SSHGuard-users] [Proposal] Handle End-of-line comments in Whitelists

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

On 5/14/20 9:14 PM, Kevin Buckley wrote:
> The various log messages already in SSHGuard go out via syslog, vis:
> 
> $ cat sshguard_log.h
> ...
> #define sshguard_log syslog
> $
> 
> which is a nod in the direction of SSHGuard being run as a daemon.
> 
> 
> In the kind of debug message that I was thinkng about when suggesting
> "adding a debug flag", I was thinking about the case where one runs
> the blocker from the command line and so might want to see messages
> directly on the console. (The typical run daemon in non-detached mode)

Yes, you read that part correctly.

However, the blocker also passes the SSHGUARD_DEBUG environment variable
to init_log, which calls openlog() with LOG_PERROR. If your syslog
supports it, then:

LOG_PERROR    Write the message to standard error output as well to the
              system log.

I believe running sshg-blocker directly from the terminal does correctly
log to standard error.

-- 
Kevin Zheng
kev...@gm... | ke...@be...
XMPP: ke...@ee...

Re: [SSHGuard-users] [Proposal] Handle End-of-line comments in Whitelists

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

On 2020/05/15 02:36, Kevin Zheng wrote:
> 
> Currently, LOG_DEBUG lines are only displayed when SSHGUARD_DEBUG is set
> in the environment, see sshguard(8).

Another observation on that (now that I'm aware of it, that is!).

The various log messages already in SSHGuard go out via syslog, vis:

$ cat sshguard_log.h
...
#define sshguard_log syslog
$

which is a nod in the direction of SSHGuard being run as a daemon.


In the kind of debug message that I was thinkng about when suggesting
"adding a debug flag", I was thinking about the case where one runs
the blocker from the command line and so might want to see messages
directly on the console. (The typical run daemon in non-detached mode)

I had found myself sprinkling a few "fprintf(stderr, ...)" across
the codebase and so was more thinking of the "debug flag" as a way
to wrap those.

Hoping that serves to inform the discussion a little more,
Kevin

Re: [SSHGuard-users] [Proposal] Handle End-of-line comments in Whitelists

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

On 2020/05/15 02:36, Kevin Zheng wrote:
>
> Do you mean to say that you're running in an environment where setting
> environment variables is not possible?

No.

> Currently, LOG_DEBUG lines are only displayed when SSHGUARD_DEBUG is set
> in the environment, see sshguard(8).

So that's the missing piece for that then.

>> * What we originally found, after adding EOL comments to a whitelist file
>> was that SSHGuard "appeared" to work OK, except that it wasnt, and it was
>> only when we added a comment along the lines of:
>> 
>> 
>> nnn.nnn.nnn.nnn   # Host at some org but covered by range
>> nnn.nnn.nnn.0/30 above
>> 
>> that we realised that the whitelist parser (whitelist_add() function)
>> was seeing the "/" in the comment as indication of a range and then
>> "not quite getting there" when parsing the full line.
> 
> Sounds like what we should really have is a better-written parser.
> Perhaps we should write a better IP list parser ...


In all fairness, if one is happy to ONLY have comments on lines of
their own, so above or below individual entries, then the existing
parser is fine.

Furthermore, none of the example files show End-of-line comments.

However, if you do not wish to have your IP addresses and ranges
surrounded by comments, and it could make the file a bit unwiedly,
and/or the IP addresses and ranges a little harder to discern, then
the existing parser doesn't always do the right thing.

Making the latter work is what the addition of the strsep() proposal
addresses, not any percieved issue with the existing parser when
used against whitelists that dont have EOL comments.


> ... and combine the
> whitelist and blacklist parsers to support comments?

The ability to annotate a blacklist with EOL comments might add
some operational benefit, as well as providing consistency in
the way the black and white lists are handled, which then reduces
any potential for confusion and errors in the input files.

Kevin

Re: [SSHGuard-users] Asterisk support

[David M. <dm...@gm...>]

Hi Kevin,

On Thu, May 14, 2020 at 1:19 PM Kevin Zheng <kev...@gm...> wrote:
>
> Just curious -- why do you have a mandate to replace fail2ban?
>

The short version is 'it does not work reliably' - there are multiple
reasons for this, some of which are unknown to me. Asterisk patterns
in fail2ban have changed drastically between versions, python version
differences impact functionality, etc. - many moving parts to
orchestrate. I appreciate the SSHGuard preference for a small, fast,
robust application without so many external dependencies.

>
> Steps 3-6 could use some fleshing-out; I'm also available to help.
>

Thank you very much!

> Let me know how you'd like to try to proceed.

I'm going to review the documentation and familiarize myself with the
code. I've also been pointed to the CSF/LFD project, which is another
possible candidate for replacing fail2ban in my environment. I
appreciate your response and I will follow up with you once I've had
time to digest my options.

David

Re: [SSHGuard-users] [Proposal] Handle End-of-line comments in Whitelists

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

On 5/13/20 6:45 PM, Kevin Buckley wrote:
> Other than neededing to bump up the log level to LOG_ERR to see this
> working on my test system, that would clearly be a useful addition,
> however, our testing would suggest that, when the whitelist parser
> "gets it wrong", then it really gets it wrong, and just segfaults*.
> 
> My "extra flag for debuging" idea would have just seen everything
> dumped into the log stream by adding in some
> 
> if( debug_flag_used) then
>   sshguard_log(LOG_ERR, "stuff")
> fi
> 
> guards, on the understanding that, if you invoked SSHGuard with the
> debug flag, you would want to see some output without needing to alter
> anything else on the system outside of SSHGuard.

Do you mean to say that you're running in an environment where setting
environment variables is not possible?

Currently, LOG_DEBUG lines are only displayed when SSHGUARD_DEBUG is set
in the environment, see sshguard(8).

> * What we originally found, after adding EOL comments to a whitelist file
> was that SSHGuard "appeared" to work OK, except that it wasnt, and it was
> only when we added a comment along the lines of:
> 
> 
> nnn.nnn.nnn.nnn   # Host at some org but covered by range
> nnn.nnn.nnn.0/30 above
> 
> that we realised that the whitelist parser (whitelist_add() function)
> was seeing the "/" in the comment as indication of a range and then
> "not quite getting there" when parsing the full line.

Sounds like what we should really have is a better-written parser.
Perhaps we should write a better IP list parser and combine the
whitelist and blacklist parsers to support comments?

Regards,
Kevin

-- 
Kevin Zheng
kev...@gm... | ke...@be...
XMPP: ke...@ee...

Re: [SSHGuard-users] Asterisk support

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

Hi David,

On 5/14/20 11:14 AM, David Moore wrote:
> I am an asterisk administrator and developer and I am fed up with
> fail2ban. I have been following SSHGuard for some time, hoping for
> asterisk support, but still clinging to mostly-working fail2ban. That
> has changed, I now have a mandate to replace fail2ban. I have done some
> searching, I found [1] and [2] - [1] indicates that support was added at
> some point, but grepping the source tree makes me think that it is no
> longer there. I imagine this is because it was incomplete. [2] indicates
> 'Defer until fail2ban backend is available'

Just curious -- why do you have a mandate to replace fail2ban?

The 'fail2ban' backend didn't happen. That was supposed to borrow only
the attack parsers from fail2ban, so you could use them with SSHGuard.
Mostly, there was lack of time/interest.

> I am willing to do development work to enable asterisk support in
> SSHGuard. I'm wondering what the 'fail2ban backend' is, and whether it's
> available yet? I would love to read more details about the required
> process to get asterisk integrated into SSHGuard

See "Add New Signatures" in CONTRIBUTING.rst, found in the repo or
linked online here:

https://bitbucket.org/sshguard/sshguard/src/master/CONTRIBUTING.rst#rst-header-add-new-signatures

Steps 3-6 could use some fleshing-out; I'm also available to help.

Alternatively, you can replace sshg-parser entirely; all it has to do is
take lines via stdin and spit out attacks in the format expected by
SSHGuard on stdout.

Let me know how you'd like to try to proceed.

-- 
Kevin Zheng
kev...@gm... | ke...@be...
XMPP: ke...@ee...

[SSHGuard-users] Asterisk support

[David M. <dm...@gm...>]

Hello List

I am an asterisk administrator and developer and I am fed up with fail2ban.
I have been following SSHGuard for some time, hoping for asterisk support,
but still clinging to mostly-working fail2ban. That has changed, I now have
a mandate to replace fail2ban. I have done some searching, I found [1] and
[2] - [1] indicates that support was added at some point, but grepping the
source tree makes me think that it is no longer there. I imagine this is
because it was incomplete. [2] indicates 'Defer until fail2ban backend is
available'

I am willing to do development work to enable asterisk support in SSHGuard.
I'm wondering what the 'fail2ban backend' is, and whether it's available
yet? I would love to read more details about the required process to get
asterisk integrated into SSHGuard

Thank you

David



[1] https://sourceforge.net/p/sshguard/mailman/message/26670286/

[2] https://bitbucket.org/sshguard/sshguard/issues/2/new-signature-asterisk

Re: [SSHGuard-users] [Proposal] Handle End-of-line comments in Whitelists

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

On 2020/05/14 00:58, Kevin Zheng wrote:
> On 5/13/20 2:33 AM, Kevin Buckley wrote:
>> Furthermore, would there be any interest in having an extra flag, in
>> the blocker, that would "turn on" some logging of successful parsing
>> of the whitelist, that could then be used in testing (some people
>> here still aren't convinced) and, whilst I'm at that, I could even
>> expand the usage() function to spit out the option flags and a brief
>> description, rather than just, well, you know what it does at
>> present.
> 
> We can also add an sshguard_log() line right after whitelist_conf_fin()
> on src/blocker/blocker.c:132 that says how many address or address
> ranges are on the whitelist.
> 
> A patch to do that is attached; what do you think?
> 

Other than neededing to bump up the log level to LOG_ERR to see this
working on my test system, that would clearly be a useful addition,
however, our testing would suggest that, when the whitelist parser
"gets it wrong", then it really gets it wrong, and just segfaults*.

My "extra flag for debuging" idea would have just seen everything
dumped into the log stream by adding in some

if( debug_flag_used) then
   sshguard_log(LOG_ERR, "stuff")
fi

guards, on the understanding that, if you invoked SSHGuard with the
debug flag, you would want to see some output without needing to alter
anything else on the system outside of SSHGuard.

Then again, maybe all of SSHGuard's sshguard_log() lines could be wrapped
in such guards, thereby affording a fuller control of log output at
invocation, along the lines of a "multiple debug flags increase verbosity"
approach.

Clearly an idea that needs a bit more fleshing out,
Kevin

* What we originally found, after adding EOL comments to a whitelist file
was that SSHGuard "appeared" to work OK, except that it wasnt, and it was
only when we added a comment along the lines of:


nnn.nnn.nnn.nnn   # Host at some org but covered by range nnn.nnn.nnn.0/30 above


that we realised that the whitelist parser (whitelist_add() function)
was seeing the "/" in the comment as indication of a range and then
"not quite getting there" when parsing the full line.

Deep sorrow!

Re: [SSHGuard-users] [Proposal] Handle End-of-line comments in Whitelists

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

On 5/13/20 2:33 AM, Kevin Buckley wrote:
> Furthermore, would there be any interest in having an extra flag, in
> the blocker, that would "turn on" some logging of successful parsing
> of the whitelist, that could then be used in testing (some people
> here still aren't convinced) and, whilst I'm at that, I could even
> expand the usage() function to spit out the option flags and a brief
> description, rather than just, well, you know what it does at
> present.

We can also add an sshguard_log() line right after whitelist_conf_fin()
on src/blocker/blocker.c:132 that says how many address or address
ranges are on the whitelist.

A patch to do that is attached; what do you think?

-- 
Kevin Zheng
kev...@gm... | ke...@be...
XMPP: ke...@ee...

Re: [SSHGuard-users] [Proposal] Handle End-of-line comments in Whitelists

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

Hi Kevin,

On 5/13/20 2:33 AM, Kevin Buckley wrote:
> having noticed that someone added an entry, into a whitelist file,
> that was already covered by a range further up the file, it struck me
> that it might be useful if there could be comments after the
> to-be-whitelisted IP address or range, eg

That would be a welcome change.

> Looking into the code I've  the following patch would achieve the
> desired result (although strsep() isn't as portable as a much more
> convoluted strtok() based "soultion") but there may be some test
> cases you have that I can't check against.
> 
> Any clues/pointers there and/or would there be any interest in 
> developing this idea so that it does? (Or just accepting it as is, if
> it passes your tests!)

I will take a closer look soon, but I'm inclined to accept this patch
"as is". Without checking too closely, it seems like strsep() is
available on all of the platforms listed on SSHGuard's download page.

> Furthermore, would there be any interest in having an extra flag, in
> the blocker, that would "turn on" some logging of successful parsing
> of the whitelist, that could then be used in testing (some people
> here still aren't convinced) and, whilst I'm at that, I could even
> expand the usage() function to spit out the option flags and a brief
> description, rather than just, well, you know what it does at
> present.

What about a separate test program like 'sshg-whitelist' that takes IP
addresses on stdin and filters whitelisted addresses away from stdout?

And some documentation, of course, suggesting that it's there.

Regards,
Kevin

-- 
Kevin Zheng
kev...@gm... | ke...@be...
XMPP: ke...@ee...

[SSHGuard-users] [Proposal] Handle End-of-line comments in Whitelists

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

Hi there,

having noticed that someone added an entry, into a whitelist file, that was
already covered by a range further up the file, it struck me that it might
be useful if there could be comments after the to-be-whitelisted IP address
or range, eg

127.0.0.0/8		# Loopback range
nnn.nnn.nnn.nn/20	# Some Org's range

and so on, rather than having commented lines above each entries.

Looking into the code I've  the following patch would achieve the desired
result (although strsep() isn't as portable as a much more convoluted strtok()
based "soultion") but there may be some test cases you have that I can't check
against.

Any clues/pointers there and/or would there be any interest in developing this
idea so that it does? (Or just accepting it as is, if it passes your tests!)

Furthermore, would there be any interest in having an extra flag, in the blocker,
that would "turn on" some logging of successful parsing of the whitelist, that
could then be used in testing (some people here still aren't convinced) and,
whilst I'm at that, I could even expand the usage() function to spit out the
option flags and a brief description, rather than just, well, you know what it
does at present.

No probs if this doesn't "float your boat", and thanks for SSHGuard,
Kevin Buckley

That patch in the body of the email for perusal (also attached as a file)

diff -ur sshguard-2.4.0-dist/src/blocker/sshguard_whitelist.c sshguard-2.4.0/src/blocker/sshguard_whitelist.c
--- sshguard-2.4.0-dist/src/blocker/sshguard_whitelist.c        2018-12-16 10:41:51.000000000 +0800
+++ sshguard-2.4.0/src/blocker/sshguard_whitelist.c     2020-05-13 15:34:14.857159691 +0800
@@ -137,6 +137,7 @@
      char line[WHITELIST_SRCLINE_LEN];
      int lineno = 0;
      size_t len;
+    char* pos;
  
  
      if (filename == NULL) return -1;
@@ -155,6 +156,9 @@
          len = strlen(line);
          if (len == 0) continue;
          if (line[len-1] == '\n') line[len-1] = '\0';
+        /* handle EOL spaces, TABs and comments, */
+        pos = line;
+        strsep(&pos, " \t#");
          /* handling line */
          if (whitelist_add(line) != 0) {
              sshguard_log(LOG_ERR, "whitelist: Unable to handle line %d from whitelist file \"%s\".", lineno, filename);

[SSHGuard-users] SSHGuard isn’t doing anything after a reinstall/upgrade

[@lbutlr <kr...@kr...>]

After updating my system to FreeBSD 12.1 and reinstalling sshguard, it is not logging at all.

First, it is running:

root     82669   0.0  0.1   4884   2372  -  Is   06:43       0:00.00 /bin/sh /usr/local/sbin/sshguard -b /usr/local/etc/sshguard.blacklist -w /usr/local/etc/sshguard.whitelist -b 120:/var/db/sshguard/blacklist.db -i /var/run/sshguard.pid
root     82672   0.0  0.1   5924   3572  -  IC   06:43       0:00.00 /usr/local/libexec/sshg-parser
root     82673   0.0  0.1   5560   2712  -  IC   06:43       0:00.03 /usr/local/libexec/sshg-blocker -a 30 -b 120:/var/db/sshguard/blacklist.db -p 1200 -s 18000 -w /usr/local/etc/sshguard.whitelist
root     82674   0.0  0.1   4808   2348  -  I    06:43       0:00.19 /bin/sh /usr/local/libexec/sshg-fw-pf

Second, the config has not changed since FreeBSD 11.4:

BACKEND="/usr/local/libexec/sshg-fw-pf"
FILES="/var/log/auth.log /var/log/mail.log /var/log/debug.log /var/log/xferlog"
THRESHOLD=30
BLOCK_TIME=1200
DETECTION_TIME=18000
BLACKLIST_FILE=30:/var/db/sshguard/blacklist.db
WHITELIST_FILE=/usr/local/etc/sshguard.whitelist

Third, auth.log is showing attempts to login:

sshd[74508] Invalid user andrew from 154.120.242.70 port 9226
sshd[74508] Failed unknown for invalid user andrew from 154.120.242.70 port 9226 ssh2
sshd[74508] user NOUSER login class  [preauth]
sshd[74508] Connection closed by invalid user andrew 154.120.242.70 port 9226 [preauth]

There is nothing in any /var/log//* file that mentions sshguard other than the message that I deinstalled it and reinstalled it (hoping it would fix something) in /var/log/message

rc.conf has:
sshguard_enable="YES"
sshguard_safety_thresh="30"
sshguard_pardon_min_interval="600"
sshguard_prescribe_interval="7200"
sshguard_flags="-b /usr/local/etc/sshguard.blacklist -w /usr/local/etc/sshguard.whitelist”

/var/db/sshguard/blacklist.db has not been modified since Feb 16.

However, if I check pfctl -t sshgiard -vTs I do see lines like the following:
   223.171.32.56
        Cleared:     Fri Feb 28 06:43:48 2020
   223.171.32.66
        Cleared:     Fri Feb 28 06:43:49 2020
   223.171.37.178
        Cleared:     Fri Feb 28 06:43:49 2020

But still, nothing at all is logged, where I used to get a lot of logging like:

Nov 30 03:35:19 mail sshguard[53048]: Attack from "27.69.242.187" on service SSH with danger 10.
Nov 30 03:35:49 mail sshguard[53048]: Attack from "27.69.242.187" on service SSH with danger 10.
Nov 30 03:35:54 mail sshguard[53048]: Attack from "27.69.242.187" on service SSH with danger 10.
Nov 30 03:35:54 mail sshguard[53048]: Blocking "27.69.242.187/32" for 1200 secs (3 attacks in 35 secs, after 1 abuses over 35 secs.)

If it matters, I preload pfctl with 36 thousand IP blocks Ito a different table (“badguys”)

bash -c 'pfctl -t badguys -T add $(cat /usr/local/etc/ru.zone)'
bash -c 'pfctl -t badguys -T add $(cat /usr/local/etc/cn.zone)’

So, it kind of looks like sshguard is adding IP addresses to pfctl, but not to the db file and is not logging at all?

Re: [SSHGuard-users] Blocked attackers can still access docker containers

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

On 08 Feb 2020, at 13:50 , Jos Chrispijn <ssh...@cl...> wrote:
> 
> On 1-11-19 3:40, gi1...@gm... wrote:
>> You could try:
>>> 1) changing the blacklist chain to 'hook prerouting' instead of 'hook
>>> input', with a higher priority than that of chain PREROURTING, i.e.
>>> block the traffic before it even reaches the NAT chain. This should
>>> make sshguard block both container- and host-destined traffic.
>>> 
> Kev, could you implement/default that in the next update/grade of SSHGuard?
> Have a good weekend y’all!

Hmmm… a docker host, is basically a router, not a host, ie. it is a “non-standard” case.

I have a case where I’d not want that to happen, ie. the bastion/router host to get protected, but the honeypots behind it to be allowed through for capturing purposes/etc.

Rather have that a toggle for routers/hypervisors(ie. docker/kvm/lxc hosts), than a blanket setting.

Re: [SSHGuard-users] Blocked attackers can still access docker containers

[<gi1...@gm...>]

On Sat, Feb 08, 2020 at 08:25:24AM -0800, Kevin Zheng wrote:

>>>> 1) changing the blacklist chain to 'hook prerouting' instead of 'hook
>>>> input', with a higher priority than that of chain PREROURTING, i.e.
>>>> block the traffic before it even reaches the NAT chain. This should
>>>> make sshguard block both container- and host-destined traffic.
>> Kev, could you implement/default that in the next update/grade of
>> SSHGuard? Have a good weekend y'all!
> 
> I don't have a machine that I can test that on. Is somebody impacted
> by this willing to submit a patch that a few on the list can test?

It worked perfectly for me, and I can test it if you include it in the
official code.

The changes I made to get it working are at the bottom of this message.
You can use it as a patch by changing the diff filenames of course.

Best,

Gautam


--- /usr/lib/x86_64-linux-gnu/sshg-fw-nft-sets  2019-02-11 22:11:23.000000000 -0500
+++ /etc/sshguard/sshg-fw-nft-sets-local    2019-10-31 22:10:03.475621324 -0400
@@ -24,8 +24,8 @@
     run_nft "add table" "" 4
     run_nft "add table" "" 6

-    run_nft "add chain" "${NFT_CHAIN}"' { type filter hook input priority -10 ; }' 4
-    run_nft "add chain" "${NFT_CHAIN}"' { type filter hook input priority -10 ; }' 6
+    run_nft "add chain" "${NFT_CHAIN}"' { type filter hook prerouting priority -200 ; }' 4
+    run_nft "add chain" "${NFT_CHAIN}"' { type filter hook prerouting priority -200 ; }' 6

     # Create sets
     run_nft "add set" "${NFT_SET} { type ipv4_addr; flags interval; }" 4

-- 
TWELVE REASONS WHY GOD NEVER RECEIVED TENURE
12. His office hours were infrequent and usually held on a mountaintop.

Re: [SSHGuard-users] Blocked attackers can still access docker containers

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

On 2/8/20 3:50 AM, Jos Chrispijn wrote:
> On 1-11-19 3:40, gi1...@gm... wrote:
>> You could try:
>>> 1) changing the blacklist chain to 'hook prerouting' instead of 'hook
>>> input', with a higher priority than that of chain PREROURTING, i.e.
>>> block the traffic before it even reaches the NAT chain. This should
>>> make sshguard block both container- and host-destined traffic.
> Kev, could you implement/default that in the next update/grade of SSHGuard?
> Have a good weekend y'all!

I don't have a machine that I can test that on. Is somebody impacted by
this willing to submit a patch that a few on the list can test?

-- 
Kevin Zheng
kev...@gm... | ke...@be...
XMPP: ke...@ee...

Re: [SSHGuard-users] Blocked attackers can still access docker containers

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

On 1-11-19 3:40, gi1...@gm... wrote:
> You could try:
>> 1) changing the blacklist chain to 'hook prerouting' instead of 'hook
>> input', with a higher priority than that of chain PREROURTING, i.e.
>> block the traffic before it even reaches the NAT chain. This should
>> make sshguard block both container- and host-destined traffic.
Kev, could you implement/default that in the next update/grade of SSHGuard?
Have a good weekend y'all!

/jos

-- With both feed on the ground you will never make a step forward

Re: [SSHGuard-users] White Listing not workin

[@lbutlr <kr...@kr...>]

On 22 Jan 2020, at 09:54, Kevin Zheng <kev...@gm...> wrote:
> On 1/22/20 5:21 AM, jason hirsh wrote:
>> I am running SSHGuard of FreeBSD 12. and IPFW   I configured it to
>> use white list and placed my IP in the white list. Issue is that
>> SSHguard keeps adding my IP to the IPFW Blocking table.   Is white
>> listing more complicated then it appears??
> 
> Could you show your sshguard.conf and the relevant lines from rc.conf?

And the output of

ps auxww | grep sshguard

-- 
"I have not failed, I've just found 10,000 ways that won't work." -
	Thomas Edison

Re: [SSHGuard-users] White Listing not workin

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

On 1/22/20 5:21 AM, jason hirsh wrote:
> I am running SSHGuard of FreeBSD 12. and IPFW   I configured it to
> use white list and placed my IP in the white list. Issue is that
> SSHguard keeps adding my IP to the IPFW Blocking table.   Is white
> listing more complicated then it appears??

Could you show your sshguard.conf and the relevant lines from rc.conf?

-- 
Kevin Zheng
kev...@gm... | ke...@be...
XMPP: ke...@ee...

[SSHGuard-users] White Listing not workin

[jason h. <hi...@at...>]

I am running SSHGuard of FreeBSD 12. and IPFW   I configured it to use white list and placed my IP in the white list.
Issue is that SSHguard keeps adding my IP to the IPFW Blocking table.   Is white listing more complicated then it appears??

Re: [SSHGuard-users] Blocked attackers can still access docker containers

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

On 01.11.19 14:59, gi1...@gm... wrote:
> This makes sense, thanks a lot. sshguard blocks about 15 attacks an hour
> on my machine, and I haven't seen any noticeable CPU increase since I
> switched to hooking pre-routing.

Unless there's enough traffic that the firewall itself is causing
significant load, I doubt one would ever notice the difference.

Re using prerouting by default: Hooking into prerouting might also not
be quite as easy with backends that don't act directly on the firewall,
like e.g. the firewalld backend. But that's a question the devs can
answer much better than me.

Anyway, I'm glad things work for you now.

Christopher

Re: [SSHGuard-users] Blocked attackers can still access docker containers

[<gi1...@gm...>]

This makes sense, thanks a lot. sshguard blocks about 15 attacks an hour
on my machine, and I haven't seen any noticeable CPU increase since I
switched to hooking pre-routing.

Thanks again,

GI

-- 
The poor guy fell into a glass grinding machine and made a spectacle of
himself.

Re: [SSHGuard-users] Blocked attackers can still access docker containers

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

On 01.11.19 03:40, gi1...@gm... wrote:
> I hope it doesn't cause trouble with other things to switch that hook.

The main difference is that you now block before deciding how to route 
traffic instead of after, so it's a very global block. Unless your 
machine does a lot of intricate forwarding all over the place, it 
shouldn't matter.

> Do you know why sshguard doesn't hook prerouting by default?
No. But input is where most simple firewall setups have ALL their rules 
for incoming traffic, so putting sshguards there as well makes it easier 
for the non-expert to understand what their firewall is doing. It is 
also the chain in which sshguard is least likely to interfere with more
complex network setups. It also potentially reduces load by not running 
local filters on non-local traffic.

Sshguard detects attacks on local services through local logs, so it 
makes sense to block access locally and not mess with traffic forwarded 
elsewhere. In the containerized world, where suddenly the host is an 
entire network with a shared harddrive and the host interface 
essentially does nothing but forwarding, it might be worth revisiting 
that decision.

Christopher

Re: [SSHGuard-users] Blocked attackers can still access docker containers

[<gi1...@gm...>]

On Thu, Oct 31, 2019 at 05:46:40PM +0100, Christopher Engelhard wrote:

> You could try:
> 1) changing the blacklist chain to 'hook prerouting' instead of 'hook
> input', with a higher priority than that of chain PREROURTING, i.e.
> block the traffic before it even reaches the NAT chain. This should
> make sshguard block both container- and host-destined traffic.

Thank you so much! This worked. When I blindly increased the priority
last time I didn't realize it was on a different chain.

I hope it doesn't cause trouble with other things to switch that hook.

Do you know why sshguard doesn't hook prerouting by default?

GI

-- 
The path to inner peace starts with three words: "Not My Business."

Re: [SSHGuard-users] Blocked attackers can still access docker containers

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

Hi,
my guess would be that the problem lies with dockers bridge network
setup (caveat, I am in no way an expert on either containers or networking).

If I read those nftables rules correctly, then:

- chain PREROUTING checks if the package is destined for an ip assigned
to a local interface (yes), and if so, counts it and sends it to the
DOCKER chain
- chain DOCKER,
  a) if that local interface was docker0 (probably no?), resets the
counter and returns or,
  b) if it was destined for HOSTIP:2022 (that's us), resets the counter
and NATs the package to 172.17.0.3:22

So apart from the added complexity which I assume has something to do
with how Docker does networking, this is just basic NAT - anything that
is send to HOSTIP:2022 gets forwarded to 172.17.0.3:22, which is the IP
of the docker0 bridge device, correct?

If so, then chains assigned to the input hook, i.e. INPUT & blacklist
are not called [1][2] on the host, the packet goes prerouting -> forward
-> postrouting, not prerouting -> input.

You could try:
1) changing the blacklist chain to 'hook prerouting' instead of 'hook
input', with a higher priority than that of chain PREROURTING, i.e.
block the traffic before it even reaches the NAT chain. This should make
sshguard block both container- and host-destined traffic.
2) changing it to 'hook forward', i.e. catch the traffic on its new path
after the docker chains (this will effectively disable sshguard for the
host machine)
3) running sshguard inside the container, kinda not the point of
containers ....

(1) is probably the best bet, but it depends on what else your host is
doing, network-wise.

Hope this helps, somewhat
Christopher
[1] https://people.netfilter.org/pablo/docs/login.pdf
[2]
https://netdevconf.info/1.1/proceedings/papers/Bridge-filter-with-nftables.pdf