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

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

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

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

OK, going through my nft rules again, I see a chain called
"DOCKER-USER". I found the (possibly outdated) documentation here:

    https://docs.docker.com/network/iptables/

and it says:

    By default, all external source IPs are allowed to connect to the
    Docker daemon. To allow only a specific IP or network to access the
    containers, insert a negated rule at the top of the DOCKER filter
    chain. For example, the following rule restricts external access to
    all IP addresses except 192.168.1.1:

	iptables -I DOCKER-USER -i ext_if ! -s 192.168.1.1 -j DROP

So I'm guessing the documentation is outdated (iptables instead of
nftables), and also slightly incorrect (it says DOCKER instead of
DOCKER-USER).

If we could also add sshguards blacklist rule to the DOCKER-USER chain
it might solve the problem. I don't know how to do this reliably though.

GI

-- 
A plateau is a high form of flattery.

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

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

On Wed, Oct 30, 2019 at 11:14:04AM -0700, Kevin Zheng wrote:

> Thanks for the report. I think you're right in pointing out that the
> priority for SSHGuard is -10, but the priority for Docker is -100.
> 
> Is someone on the list familiar with firewalls on Linux? Is the right
> fix here just to decrease the priority for SSHGuard?

>From the nft man page:

    The priority parameter accepts a signed integer value  which
    specifies the  order  in which chains with same hook value are
    traversed. The ordering is ascending, i.e. lower priority values
    have  precedence  over higher ones.

I just opened /usr/lib/x86_64-linux-gnu/sshg-fw-nft-sets. In fw_init()
sshguard does
    
    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

I changed priority to -200 (Docker had -100), and restarted sshguard.
There was  no change in the behavior. I can still access containers from
blocked IPs.

Best,

GI

PS: If you're trying to reproduce it, it might be simpler to run a
    vanilla nginx container instead of the gitolite container I
    suggested in my last email.

	mkdir ./html

	# put static web content in ./html. Plain text files are fine

	docker run --rm --name=nginx-test \
	    -v ./html:/usr/share/nginx/html:ro -p 8080:80 -d nginx

    This exposes port 8080 on the host. The exposed port stays
    accessible from all sshguard blocked attackers.

-- 
'Civilization' -- Going from shoeless toes to toeless shoes.

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

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

Thanks for the report. I think you're right in pointing out that the
priority for SSHGuard is -10, but the priority for Docker is -100.

Is someone on the list familiar with firewalls on Linux? Is the right
fix here just to decrease the priority for SSHGuard?

Thanks,
Kevin

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

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

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

Hi All,

Thanks for sshguard; I've been using it happily for some time now.

I'm writing to report a security issue I noticed recently: In short,
blocked attackers are still able to access docker containers.

Steps to reproduce:

    1. Run any docker container with an exposed port. Personally I'm
       running https://hub.docker.com/r/jgiannuzzi/gitolite

	docker run -p 2022:22 jgiannuzzi/gitolite

    2. Attack the host machine from some remote until it gets blocked.

	    remote> repeat 10 ssh spam@host
	    ...

	    host> journalctl --unit=sshguard.service
	    ...
	    Oct 30 11:19:20 gi sshguard[962]: Blocking "HOSTIP/32" for
		960 secs (4 attacks in 345 secs, after 4 abuses over
		2721 secs.)

    3. Check that the remote attacker is blocked as expected:

	    remote> ping host
	    (no response)
	    remote> ssh host
	    (no response)

    4. The exposed ports from docker containers are still visible to
       attackers:

	    remote> ssh -p 2022 git@host
	    SUCCEEDED

Any container with an exposed port will do. Doesn't have to be the one I
used above. I used to use iptables back in the day, but looks like
modern systems use nft. I checked out the rules added. Looks like the
relevant parts (from nft list ruleset) are:

    table ip sshguard {
        set attackers {
                type ipv4_addr
                flags interval
                elements = { REMOTE_IP, ... }
        }

        chain blacklist {
                type filter hook input priority -10; policy accept;
                ip saddr @attackers drop
        }
    }

    table ip nat {
        chain PREROUTING {
	    type nat hook prerouting priority -100; policy accept;
	    fib daddr type local counter packets 64 bytes 4890 jump DOCKER
        }

        chain INPUT {
	    type nat hook input priority 100; policy accept;
        }

        chain POSTROUTING {
	    type nat hook postrouting priority 100; policy accept;
	    oifname != "docker0" ip saddr 172.17.0.0/16 counter packets 0 bytes 0 masquerade 
	    meta l4proto tcp ip saddr 172.17.0.3 ip daddr 172.17.0.3 tcp dport 22 counter packets 0 bytes 0 masquerade 
        }

	chain OUTPUT {
	    type nat hook output priority -100; policy accept;
	    ip daddr != 127.0.0.0/8 fib daddr type local counter packets 0 bytes 0 jump DOCKER
        }

        chain DOCKER {
	    iifname "docker0" counter packets 0 bytes 0 return
	    iifname != "docker0" meta l4proto tcp ip daddr HOST_IP tcp dport 2022 counter packets 0 bytes 0 dnat to 172.17.0.3:22
        }
    }

I replaced the IP addresses with HOST_IP / REMOTE_IP above. I don't
fully understand the sequence above. Perhaps because sshguard adds rules
with priority -10 and docker with prority -100?

Regardless, the upshot is that docker containers are not protected at
all by sshguard. Moreover, if your container runs a ssh service, you
can't currently use sshguard on the host to test/block ssh attacks on
the container. (This is what I was trying to setup when I found the
above problem. My container passes logs to sshguard fine, and sshguard
claims to have blocked the IP of the attacker. But it only blocks the
attacker from accessing other ports on the host. The attacker still has
full access to all container exposed ports, and so can continue with his
ssh brute force attack.)

If you know how to fix this, or if I should report this somewhere else,
please let me know.

GI

-- 
'Confidence' -- The feeling a person has before he fully understands the
situation.

Re: [SSHGuard-users] Increasing danger level?

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

On 27.10.19 17:59, @lbutlr wrote:
> However, there’s a long list of usernames that would be appropriate on my systems for this beyond root. Admin, postmaster, toor, postfix, mysql, and many many others that are attempted all the time.

You could treat attacks with invalid or disallowed-by-ssh usernames more
severly:
Sshguard assigns all matches for invalid or disallowed users the token
'ssh_illegaluser', so instead of creating your own match, you could
increase the severity of that.

To set the danger level to <number>, in attack_parser.y, line 211, change

ssh_illegaluser

to

ssh_illegaluser  { attack->dangerousness = <number>; }

That should do the trick.

Re: [SSHGuard-users] Increasing danger level?

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

On 26 Oct 2019, at 04:51, Christopher Engelhard <ce...@lc...> wrote:
> However, if you're OK with building sshguard yourself, it's not too
> difficult to add these additional rules to your local version. Have a
> look at attack_(parser.y|scanner.l) in the linked PR as a guide to the
> necessary changes.
> 
> [1]
> https://bitbucket.org/robohack/sshguard/commits/43c8542552e8f5a3413d5c5984555bea4d77bb7e?at=master

Thanks. Grabbed that and am hoping to add it in.

However, there’s a long list of usernames that would be appropriate on my systems for this beyond root. Admin, postmaster, toor, postfix, mysql, and many many others that are attempted all the time.

In fact, a mechanism in sshguard that increased the danger or decreased the threshold for non-existent accounts would be great.



-- 
"It's like those French have a different word for *everything*" - Steve
Martin