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

[SSHGuard-users] sshd and connections resulting in "kex_exchange_identification" errors

[Greg B. <gbe...@ya...>]

Hi,

My sshd server sits on port 443 so I can get to it from behind corp 
firewalls. So it gets a lot of http requests, which result in things like:

     Nov 20 02:12:12 server sshd[1170601]: error: 
kex_exchange_identification: banner line contains invalid characters

No IP is reported, so sshguard can't do anything about these. I'd like to 
block them - seems reasonable that a hack, or at least a DOS, could happen 
at that early point in sshd's protocol.

Does anybody have experience blocking based on these connection attempts?


Best regards,

~gb

Re: [SSHGuard-users] Should sshguard check iptables setup?

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

On 2021/11/19 07:58, Kevin Zheng wrote:
> 
> I'm not very familiar with iptables. How does this happen (that the
> table gets unlinked), and is there a command that sshguard can run to
> double check the iptables setup?

Here are a couple of stanza of Makefile code (not the full
Makefile) that check to see if you have the SSHGuard chain
and a jump rule, and tells you where to stick it, if you
haven't, but doesn't do any manipulation of things for you.
You could probably extract the code to a script, but some
of us still like Make.

Typically, if you have an IPtables setup that hasn't been
initialised for SSHGuard, though we're on SLES boxes, not
Ubuntu, as the original poster was, you would see something
akin to:

# make check-and-insert

No IPv4 sshguard chain exists: you should type

  /usr/sbin/iptables -N sshguard

No IPv6 sshguard chain exists: you should type

  /usr/sbin/ip6tables -N sshguard

You need to insert an IPv4 rule here, as follows

  /usr/sbin/iptables -I input_ext 4 \
   -m multiport -p tcp --destination-ports 22 -j sshguard

You need to insert an IPv6 rule here, as follows

  /usr/sbin/ip6tables -I input_ext 8 \
   -m multiport -p tcp --destination-ports 22 -j sshguard
#


where the 4 and 8 are specific to the IPTables environment
being interrogated. You may see other numbers.

Similarly, organisations that move SSH off port 22, might
also need to alter the 22 in the snippets.

Note also that the name of the chain being looked for,
so as to identify where to insert the jump, "input_ext",
may be different in your IPTables environment, but the
principles encoded above should still be valid.



IPT4=/usr/sbin/iptables
IPT6=/usr/sbin/ip6tables
SSHG_CHAIN=sshguard

check-and-insert: pull-the-chain where-to-stick-it

pull-the-chain:
         @$(IPT4) -L $(SSHG_CHAIN) -n >& /dev/null ; \
         if [ 1 == $$? ] ; then \
         echo "No IPv4 $(SSHG_CHAIN) chain exists: you should type" ; \
         echo "" ; \
         echo " /usr/sbin/iptables -N $(SSHG_CHAIN)" ; \
         else \
         echo "An IPv4 $(SSHG_CHAIN) chain already exists" ; \
         fi ; \
         $(IPT6) -L $(SSHG_CHAIN) -n >& /dev/null ; \
         if [ 1 == $$? ] ; then \
         echo "" ; \
         echo "No IPv6 $(SSHG_CHAIN) chain exists: you should type" ; \
         echo "" ; \
         echo " /usr/sbin/ip6tables -N $(SSHG_CHAIN)" ; \
         else \
         echo "An IPv6 $(SSHG_CHAIN) chain already exists" ; \
         fi

where-to-stick-it:
         @$(IPT4) -L input_ext -n | grep -q "^$(SSHG_CHAIN)" ; \
         if [ 0 == $$? ] ; then \
         echo "An IPv4 jump to the $(SSHG_CHAIN) chain rule already exists" ; \
         else \
         $(IPT4) -L input_ext -n --line-numbers | grep -q "dpt:22" ; \
         if [ 0 == $$? ] ; then \
         line=`iptables  -L input_ext -n --line-numbers | grep "dpt:22" | cut -d\  -f 1` ; \
         echo "" ; \
         echo "You need to insert an IPv4 rule here, as follows" ; \
         echo "" ; \
         echo " /usr/sbin/iptables -I input_ext $$line \\" ; \
         echo "  -m multiport -p tcp --destination-ports 22 \
         -j $(SSHG_CHAIN)" ; \
         echo "" ; \
         else \
         echo "No IPv4 rule to stick it before exists" ; \
         fi ; \
         fi ; \
         $(IPT6) -L input_ext -n | grep -q "^$(SSHG_CHAIN)" ; \
         if [ 0 == $$? ] ; then \
         echo "An IPv6 jump to the $(SSHG_CHAIN) chain rule already exists" ; \
         else \
         $(IPT6) -L input_ext -n --line-numbers | grep -q "dpt:22" ; \
         if [ 0 == $$? ] ; then \
         line=`ip6tables -L input_ext -n --line-numbers | grep "dpt:22" | cut -d\  -f 1` ; \
         echo "" ; \
         echo "You need to insert an IPv6 rule here, as follows" ; \
         echo "" ; \
         echo " /usr/sbin/ip6tables -I input_ext $$line \\" ; \
         echo "  -m multiport -p tcp --destination-ports 22 \
         -j $(SSHG_CHAIN)" ; \
         echo "" ; \
         else \
         echo "No IPv6 rule to stick it before exists" ; \
         fi ; \
         fi

HTH.
(Usual terms and conditions apply if you choose to use it in
  any way. No salesman will call: you will not be contacted
  for feedback.)

Kevin

Re: [SSHGuard-users] Should sshguard check iptables setup?

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

Hi Greg,

On 11/18/21 3:02 PM, Greg Bell via sshguard-users wrote:
> My iptables setup broke somehow - the INPUT table wasn't linked to the 
> sshguard table, so blocking wasn't actually happening.
> 
> I only discovered it after seeing a few thousand attempts to 
> authenticate as 'root' from the same IP, in logwatch's daily email.
> 
> Can/should sshguard check for this situation?

I'm not very familiar with iptables. How does this happen (that the 
table gets unlinked), and is there a command that sshguard can run to 
double check the iptables setup?

Thanks,
Kevin

[SSHGuard-users] Should sshguard check iptables setup?

[Greg B. <gbe...@ya...>]

Hi sshguard peeps,

My iptables setup broke somehow - the INPUT table wasn't linked to the 
sshguard table, so blocking wasn't actually happening.

I only discovered it after seeing a few thousand attempts to authenticate 
as 'root' from the same IP, in logwatch's daily email.

Can/should sshguard check for this situation?

Re: [SSHGuard-users] Connection to ssh is an "attack"?

[kaycee gb <kis...@ho...>]

Le Thu, 18 Nov 2021 22:47:24 +1100,
Greg Bell via sshguard-users <ssh...@li...> a écrit :

> Hi,
> 
> Running 2.3.1 on Ubuntu 20.04.
> 
> I noticed from the logs that simply connecting to sshd counts as an 
> "attack", before I even enter my password. So ssh'ing, ctrl-c'ing before 
> doing anything, then repeating a few times locks out that IP.
> 
> Is this intentional?
> 
> 
> 
> _______________________________________________
> sshguard-users mailing list
> ssh...@li...
> https://lists.sourceforge.net/lists/listinfo/sshguard-users

Hi,

Latest version available upstream is 2.4.2 and IIRC something related to ssh
logins has been addressed in this version. 

As to how to get latest version in ubuntu, I don't know :/ 

K.

Re: [SSHGuard-users] Connection to ssh is an "attack"?

[Nico S. <nic...@un...>]

I would say it should be like this, as you can exhaust the ssh
connection pool by just doing that. See sshd_config option MaxStartups.

Cheers,

Nico

Greg Bell via sshguard-users <ssh...@li...> writes:

> Hi,
>
> Running 2.3.1 on Ubuntu 20.04.
>
> I noticed from the logs that simply connecting to sshd counts as an
> "attack", before I even enter my password. So ssh'ing, ctrl-c'ing
> before doing anything, then repeating a few times locks out that IP.
>
> Is this intentional?
>
>
>
> _______________________________________________
> sshguard-users mailing list
> ssh...@li...
> https://lists.sourceforge.net/lists/listinfo/sshguard-users


--
Sustainable and modern Infrastructures by ungleich.ch

[SSHGuard-users] Connection to ssh is an "attack"?

[Greg B. <gbe...@ya...>]

Hi,

Running 2.3.1 on Ubuntu 20.04.

I noticed from the logs that simply connecting to sshd counts as an 
"attack", before I even enter my password. So ssh'ing, ctrl-c'ing before 
doing anything, then repeating a few times locks out that IP.

Is this intentional?

[SSHGuard-users] SSHGuard errata: whitelisting IPv6 addresses

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

Hi there,

I'm writing to report an errata affecting whitelisting IPv6 addresses in 
SSHGuard versions 1.5 through 2.4.2.

PROBLEM

Whitelisting an IPv6 address causes an extra zero byte to be written 
beyond the end of a stack variable due to a logic error in memset().

IMPACT

Whitelisting an IPv6 address may cause sshg-blocker to abort on startup 
  due to a stack check failure if compiled with '-fstack-protector'.

If stack checks are not enabled, the security impact is still likely low 
because the overflow is always one zero byte, regardless of the 
whitelist input. Further, the whitelist is configured by the system 
administrator.

In practice, this crash only seems to happen on 32-bit systems. The 
exact cause is unknown, but likely due to differences in structure 
alignment and padding ("slop") between 32 and 64-bit systems. On 64-bit 
systems, the extra byte may just be written to struct padding.

WORKAROUND

Do not whitelist IPv6 addresses.

SOLUTION

Either:

1. Upgrade to Git version 0403ed3b or later, or,

2. Apply the attached source patch to the 2.4.2 release and reinstall.

Thanks,
Kevin

Re: [SSHGuard-users] Adding support for bind/named

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

Hi Nico,

On 8/4/21 1:46 AM, Nico Schottelius wrote:
> that's great! I just tried to compile sshguard on Alpine Linux using
> 
> autoreconf -i
> ./configure
> make
> > make[1]: *** No rule to make target 'doc/sshguard-setup.7', needed by 
'all-am'.  Stop.

You are missing rst2man, the program used to generate the man pages.

We'll try to fix the Git build without rst2man, but usually this isn't 
an issue because we ship the generated man pages in release tarballs.

For now, you can install rst2man (usually in a package named 
python-docutils or the like) or wait to see if we can fix the rules :)

Regards,
Kevin

Re: [SSHGuard-users] Adding support for bind/named

[Nico S. <nic...@un...>]

Hey Kevin,

that's great! I just tried to compile sshguard on Alpine Linux using

autoreconf -i
./configure
make

However there seems to be a rule missing:

--------------------------------------------------------------------------------
  506 sets of reallocations needed
  819121 total table entries needed
  CC       attack_scanner.o
  CC       parser.o
  CCLD     sshg-parser
make[3]: Leaving directory '/home/nico/temp/sshguard/src/parser'
make[2]: Leaving directory '/home/nico/temp/sshguard/src/parser'
make[2]: Entering directory '/home/nico/temp/sshguard/src'
sed -e 's|@libexecdir[@]|/usr/local/libexec|g' -e 's|@sysconfdir[@]|/usr/local/etc|g' -e 's|@sshguardversion[@]|2.4.2|g' ./sshguard.in > sshguard
make[2]: Leaving directory '/home/nico/temp/sshguard/src'
make[1]: Leaving directory '/home/nico/temp/sshguard/src'
make[1]: Entering directory '/home/nico/temp/sshguard'
make[1]: *** No rule to make target 'doc/sshguard-setup.7', needed by 'all-am'.  Stop.
make[1]: Leaving directory '/home/nico/temp/sshguard'
make: *** [Makefile:481: all-recursive] Error 1
--------------------------------------------------------------------------------

I've below attached the full output - in case this is helpful. Not
urgent from my side, just wanted to give a heads up.

Best regards,

Nico

[10:42] nb3:sshguard% autoreconf -i
configure.ac:6: warning: 'AM_CONFIG_HEADER': this macro is obsolete.
configure.ac:6: You should use the 'AC_CONFIG_HEADERS' macro instead.
./lib/autoconf/general.m4:2434: AC_DIAGNOSE is expanded from...
aclocal.m4:855: AM_CONFIG_HEADER is expanded from...
configure.ac:6: the top level
configure.ac:15: warning: The macro `AC_PROG_CC_C99' is obsolete.
configure.ac:15: You should run autoupdate.
./lib/autoconf/c.m4:1659: AC_PROG_CC_C99 is expanded from...
configure.ac:15: the top level
configure.ac:19: warning: AC_PROG_LEX without either yywrap or noyywrap is obsolete
./lib/autoconf/programs.m4:716: _AC_PROG_LEX is expanded from...
./lib/autoconf/programs.m4:709: AC_PROG_LEX is expanded from...
aclocal.m4:724: AM_PROG_LEX is expanded from...
configure.ac:19: the top level
configure.ac:40: warning: AC_OUTPUT should be used without arguments.
configure.ac:40: You should run autoupdate.
configure.ac:18: installing './ar-lib'
configure.ac:12: installing './compile'
configure.ac:7: installing './install-sh'
configure.ac:7: installing './missing'
configure.ac:9: installing './tap-driver.sh'
src/blocker/Makefile.am:5: warning: source file '../common/service_names.c' is in a subdirectory,
src/blocker/Makefile.am:5: but option 'subdir-objects' is disabled
automake: warning: possible forward-incompatibility.
automake: At least one source file is in a subdirectory, but the 'subdir-objects'
automake: automake option hasn't been enabled.  For now, the corresponding output
automake: object file(s) will be placed in the top-level directory.  However, this
automake: behavior may change in a future Automake major version, with object
automake: files being placed in the same subdirectory as the corresponding sources.
automake: You are advised to start using 'subdir-objects' option throughout your
automake: project, to avoid future incompatibilities.
src/blocker/Makefile.am:5: warning: source file '../common/simclist.c' is in a subdirectory,
src/blocker/Makefile.am:5: but option 'subdir-objects' is disabled
src/blocker/Makefile.am: installing './depcomp'
src/fw/Makefile.am:26: warning: source file '../common/simclist.c' is in a subdirectory,
src/fw/Makefile.am:26: but option 'subdir-objects' is disabled
configure.ac: installing './ylwrap'
parallel-tests: installing './test-driver'
[10:42] nb3:sshguard% ./configure && make
checking whether to enable maintainer-specific portions of Makefiles... yes
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for a race-free mkdir -p... /bin/mkdir -p
checking for gawk... no
checking for mawk... no
checking for nawk... no
checking for awk... awk
checking whether make sets $(MAKE)... yes
checking whether make supports nested variables... yes
checking whether make supports nested variables... (cached) yes
checking whether make supports the include directive... yes (GNU style)
checking for gcc... gcc
checking whether the C compiler works... yes
checking for C compiler default output file name... a.out
checking for suffix of executables...
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether the compiler supports GNU C... yes
checking whether gcc accepts -g... yes
checking for gcc option to enable C11 features... none needed
checking whether gcc understands -c and -o together... yes
checking dependency style of gcc... gcc3
checking for stdio.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for strings.h... yes
checking for sys/stat.h... yes
checking for sys/types.h... yes
checking for unistd.h... yes
checking for wchar.h... yes
checking for minix/config.h... no
checking whether it is safe to define __EXTENSIONS__... yes
checking whether _XOPEN_SOURCE should be defined... no
## -------------- ##
## Program Checks ##
## -------------- ##
checking for ranlib... ranlib
checking for bison... bison -y
checking for ar... ar
checking the archiver (ar) interface... ar
checking for flex... flex
checking for lex output file root... lex.yy
checking for lex library... none needed
checking for library containing yywrap... no
checking whether yytext is a pointer... yes
## ----------------------------------- ##
## Headers, Types, and Compiler Checks ##
## ----------------------------------- ##
checking for getopt.h... yes
checking for sys/capsicum.h... no
checking for sys/capability.h... yes
checking for cap_enter... no
checking for cap_rights_limit... no
checking for rst2man... no
checking for rst2man.py... no
configure: WARNING: rst2man not found; using pre-built man pages
## ----------------- ##
## Library Functions ##
## ----------------- ##
checking for library containing gethostbyname... none required
checking for library containing pthread_create... none required
checking for library containing socket... none required
checking that generated files are newer than configure... done
configure: creating ./config.status
config.status: creating Makefile
config.status: creating src/Makefile
config.status: creating src/blocker/Makefile
config.status: creating src/fw/Makefile
config.status: creating src/parser/Makefile
config.status: creating src/common/config.h
config.status: executing depfiles commands
Making all in src
make[1]: Entering directory '/home/nico/temp/sshguard/src'
Making all in blocker
make[2]: Entering directory '/home/nico/temp/sshguard/src/blocker'
  CC       service_names.o
  CC       simclist.o
  CC       attack.o
  CC       blocker.o
  CC       blocklist.o
  CC       hash_32a.o
  CC       sshguard_blacklist.o
  CC       sshguard_options.o
  CC       sshguard_whitelist.o
  CCLD     sshg-blocker
make[2]: Leaving directory '/home/nico/temp/sshguard/src/blocker'
Making all in fw
make[2]: Entering directory '/home/nico/temp/sshguard/src/fw'
  CC       hosts.o
  CC       simclist.o
  CCLD     sshg-fw-hosts
cat sshg-fw-firewalld.sh ./sshg-fw.in > sshg-fw-firewalld
cat sshg-fw-ipfilter.sh ./sshg-fw.in > sshg-fw-ipfilter
cat sshg-fw-ipfw.sh ./sshg-fw.in > sshg-fw-ipfw
cat sshg-fw-ipset.sh ./sshg-fw.in > sshg-fw-ipset
cat sshg-fw-iptables.sh ./sshg-fw.in > sshg-fw-iptables
cat sshg-fw-nft-sets.sh ./sshg-fw.in > sshg-fw-nft-sets
cat sshg-fw-null.sh ./sshg-fw.in > sshg-fw-null
cat sshg-fw-pf.sh ./sshg-fw.in > sshg-fw-pf
make[2]: Leaving directory '/home/nico/temp/sshguard/src/fw'
Making all in parser
make[2]: Entering directory '/home/nico/temp/sshguard/src/parser'
  YACC     attack_parser.c
updating attack_parser.h
make  all-am
make[3]: Entering directory '/home/nico/temp/sshguard/src/parser'
  CC       attack.o
  CC       attack_parser.o
  LEX      attack_scanner.c
flex version 2.6.4 usage statistics:
  scanner options: -dvI8 -Cem
  18166/19000 NFA states
  22041/27000 DFA states (375740 words)
  97 rules
  Compressed tables always back-up
  29/40 start conditions
  8595 epsilon states, 5778 double epsilon states
  1390/1400 character classes needed 29476/29500 words of storage, 0 reused
  1806822 state/nextstate pairs created
  161491/1645331 unique/duplicate transitions
  26373/27000 base-def entries created
  383018/384000 (peak 720753) nxt-chk entries created
  21660/360000 (peak 359556) template nxt-chk entries created
  163083 empty table entries
  7356 protos created
  4332 templates created, 12219 uses
  83/256 equivalence classes created
  5/256 meta-equivalence classes created
  4184 (4800 saved) hash collisions, 139509 DFAs equal
  506 sets of reallocations needed
  819121 total table entries needed
  CC       attack_scanner.o
  CC       parser.o
  CCLD     sshg-parser
make[3]: Leaving directory '/home/nico/temp/sshguard/src/parser'
make[2]: Leaving directory '/home/nico/temp/sshguard/src/parser'
make[2]: Entering directory '/home/nico/temp/sshguard/src'
sed -e 's|@libexecdir[@]|/usr/local/libexec|g' -e 's|@sysconfdir[@]|/usr/local/etc|g' -e 's|@sshguardversion[@]|2.4.2|g' ./sshguard.in > sshguard
make[2]: Leaving directory '/home/nico/temp/sshguard/src'
make[1]: Leaving directory '/home/nico/temp/sshguard/src'
make[1]: Entering directory '/home/nico/temp/sshguard'
make[1]: *** No rule to make target 'doc/sshguard-setup.7', needed by 'all-am'.  Stop.
make[1]: Leaving directory '/home/nico/temp/sshguard'
make: *** [Makefile:481: all-recursive] Error 1


Kevin Zheng <kev...@gm...> writes:

> Hi Nico,
>
> I've added the "query denied" signature for named in 961b590.
>
> Regards,
> Kevin


--
Sustainable and modern Infrastructures by ungleich.ch

Re: [SSHGuard-users] Adding support for bind/named

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

Hi Nico,

I've added the "query denied" signature for named in 961b590.

Regards,
Kevin

Re: [SSHGuard-users] Adding support for bind/named

[Nico S. <nic...@un...>]

Hey Kevin,

I've checked the source and unfortunately it does not look simple for me
to add the patterns. Meanwhile I've checked the logs of various routers
and all of them have the same pattern (and also interestingly a lot of
the same domain name that is being tried).

Best regards,

Nico

--
Sustainable and modern Infrastructures by ungleich.ch

Re: [SSHGuard-users] Adding support for bind/named

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

Hi Nico,

On 7/27/21 11:53 PM, Nico Schottelius wrote:
> Jul 28 08:45:16 router1 named[135105]: client @0x7f13c4158c00 172.117.192.180#3074 (pizzaseo.com): query (cache) 'pizzaseo.com/RRSIG/IN' denied
> 
> every few seconds. The reason why this is an attack is that the servers
> are resolvers for the DC and authoritative for various domains - so
> internal recursive queries are allowed, external aren't.

This seems reasonable to me.

If you'd like to try to add this signature yourself and submit a patch, 
we have some brief instructions here:

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

Otherwise, I can help take a look at adding this signature in the next 
couple of days.

Regards,
Kevin

[SSHGuard-users] Adding support for bind/named

[Nico S. <nic...@un...>]

Good morning,

I was wondering what you think about adding support for suspicious
DNS requests? We have quite a lot of DNS servers that report messages
such as

Jul 28 08:45:16 router1 named[135105]: client @0x7f13c4158c00 172.117.192.180#3074 (pizzaseo.com): query (cache) 'pizzaseo.com/RRSIG/IN' denied

every few seconds. The reason why this is an attack is that the servers
are resolvers for the DC and authoritative for various domains - so
internal recursive queries are allowed, external aren't.

I think the pattern would be something on the line of

named.*client.*\(.*\)#.*denied$

with $1 having the address.

Best regards,

Nico

--
Sustainable and modern Infrastructures by ungleich.ch

Re: [SSHGuard-users] Tiny fix to security/sshguard to allow use of daemon_flags

[kaycee gb <kis...@ho...>]

Le Fri, 16 Jul 2021 20:00:05 -0400,
"Sven F." <sve...@gm...> a écrit :

> On Fri, Jul 16, 2021 at 3:03 PM Kevin Zheng <kev...@gm...> wrote:
...
> > The home page is out of date. I will go update the home page.
> >
> > Originally, SSHGuard allowed piping logs to its standard input, for the
> > purpose of piping from syslog. However, folks were unhappy about
> > SSHGuard restarting every 24-hours or so, forgetting the attackers that
> > it had kept in memory.  
> 
> Attackers are supposed to be in a pf table , extern to the daemon

pf table is freed when daemon is stopped.

...

K.

Re: [SSHGuard-users] Tiny fix to security/sshguard to allow use of daemon_flags

[Sven F. <sve...@gm...>]

On Fri, Jul 16, 2021 at 3:03 PM Kevin Zheng <kev...@gm...> wrote:
>
> Hi all,
>
> On 7/16/21 12:41 PM, Sven F. wrote:
> > The website first page:
> >
> > sshguard can read log messages from standard input (suitable for
> > piping from syslog)
> >
> > But since (openbsd 6.8) 2.4.1
> >
> > # cat /var/log/authlog | sshguard
> > sshguard: /etc/sshguard.conf is missing FILES and LOGREADER; please specify one
> >
> > It s in the release note of 2.4.0:
> >
> > No longer accept logs given via standard input
> >
> > And it makes no sense at all given the statement of the home page
> The home page is out of date. I will go update the home page.
>
> Originally, SSHGuard allowed piping logs to its standard input, for the
> purpose of piping from syslog. However, folks were unhappy about
> SSHGuard restarting every 24-hours or so, forgetting the attackers that
> it had kept in memory.

Attackers are supposed to be in a pf table , extern to the daemon

>
> I don't know if OpenBSD's syslog has this behavior, but my man page says
> (about piping output to commands):
>
>   The command itself runs
>   with stdout and stderr redirected to /dev/null.  Upon receipt of a
>   SIGHUP, syslogd(8) will close the pipe to the process.  If the
>   process did not exit voluntarily, it will be sent a SIGTERM signal
>   after a grace period of up to 60 seconds.
>
> It was decided that it was better not to support piping from standard
> input, than to deal with this.

How is this a problem ? closing stdin will trigger a read at 0,
a lot of basix unix command run | like | that

-TERM is just improving the situation in case the sub program got stuck

>
> > Is there a proposed workaround using a silly LOGREADER ?
>
> I believe your workaround works, but please be aware of the above issue
> if you choose to pipe from syslogd.

I have no idea what issue you're talking about
and the daemon is broken out of the box without STDIN ( se below )

>
> Since I have you OpenBSD folks around, how's pledge() support working
> out? I have not tested on OpenBSD for some time now.
>

Much poorly ( 200% cpu crap loop unkillable using default config )

# kdump  -f /tmp/ktrace.out  | tail
 83231 sshg-blocker CALL  sched_yield()
 83231 sshg-blocker RET   sched_yield 0
 83231 sshg-blocker RET   sched_yield 0
 83231 sshg-blocker CALL  sched_yield()
 83231 sshg-blocker CALL  sched_yield()


This is all very confusing

> Thanks,
> Kevin



-- 
--
---------------------------------------------------------------------------------------------------------------------
Knowing is not enough; we must apply. Willing is not enough; we must do

Re: [SSHGuard-users] Tiny fix to security/sshguard to allow use of daemon_flags

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

Hi all,

On 7/16/21 12:41 PM, Sven F. wrote:
> The website first page:
> 
> sshguard can read log messages from standard input (suitable for
> piping from syslog)
> 
> But since (openbsd 6.8) 2.4.1
> 
> # cat /var/log/authlog | sshguard
> sshguard: /etc/sshguard.conf is missing FILES and LOGREADER; please specify one
> 
> It s in the release note of 2.4.0:
> 
> No longer accept logs given via standard input
> 
> And it makes no sense at all given the statement of the home page
The home page is out of date. I will go update the home page.

Originally, SSHGuard allowed piping logs to its standard input, for the 
purpose of piping from syslog. However, folks were unhappy about 
SSHGuard restarting every 24-hours or so, forgetting the attackers that 
it had kept in memory.

I don't know if OpenBSD's syslog has this behavior, but my man page says 
(about piping output to commands):

  The command itself runs
  with stdout and stderr redirected to /dev/null.  Upon receipt of a
  SIGHUP, syslogd(8) will close the pipe to the process.  If the
  process did not exit voluntarily, it will be sent a SIGTERM signal
  after a grace period of up to 60 seconds.

It was decided that it was better not to support piping from standard 
input, than to deal with this.

> Is there a proposed workaround using a silly LOGREADER ?

I believe your workaround works, but please be aware of the above issue 
if you choose to pipe from syslogd.

Since I have you OpenBSD folks around, how's pledge() support working 
out? I have not tested on OpenBSD for some time now.

Thanks,
Kevin

Re: [SSHGuard-users] Tiny fix to security/sshguard to allow use of daemon_flags

[Sven F. <sve...@gm...>]

On Fri, Jul 16, 2021 at 1:13 PM Sven F. <sve...@gm...> wrote:
>
>
>
> On Tue, Mar 23, 2021 at 7:11 AM Andreas Kusalananda Kähäri <and...@ab...> wrote:
>>
>> A user contacted me about the security/sshguard port.  They wanted to
>> use daemon_flags with the port, which means this needs to be added to
>> the pexp expression in the rc.d file.
>>
>> The attached patch does this in the similar manner as is done for e.g.
>> sshd and unbound.
>>
>>
>> Regards,
>> Andreas (port maintainer)
>>
>> --
>> Andreas (Kusalananda) Kähäri
>> SciLifeLab, NBIS, ICM
>> Uppsala University, Sweden
>>
>> .
>
>
> Running current i had issue with sshguard
>
> Note:
> OpenBSD j1800 6.9 GENERIC.MP#129 amd64
> # grep pexp /etc/rc.d/rc.subr
> [..]
> pexp="$(eval echo ${daemon}${daemon_flags:+ ${daemon_flags}})"
>
> sshg-blocker ran full cpu load and rcctl restart did not kill it,
> only kill -9 was able to stop the process.
>
> I also notice than in 6.8 reading STDIN was broken
>
> I was able to ktrace sshg-blocker :
>
> # kdump  -f /tmp/ktrace.out  | head
>  83231 sshg-blocker RET   sched_yield 0
>  83231 sshg-blocker RET   sched_yield 0
>  83231 sshg-blocker CALL  sched_yield()
>  83231 sshg-blocker CALL  sched_yield()
>  83231 sshg-blocker RET   sched_yield 0
>
> # kdump  -f /tmp/ktrace.out  | tail
>  83231 sshg-blocker CALL  sched_yield()
>  83231 sshg-blocker RET   sched_yield 0
>  83231 sshg-blocker RET   sched_yield 0
>  83231 sshg-blocker CALL  sched_yield()
>  83231 sshg-blocker CALL  sched_yield()
>  83231 sshg-blocker RET   sched_yield 0
>  83231 sshg-blocker RET   sched_yield 0
>  83231 sshg-blocker CALL  sched_yield()
>  83231 sshg-blocker CALL  sched_yield()
>  83231 sshg-blocker PSIG  SIGKILL SIG_DFL
>
> I can perform compilation and test
>
> I will now try to run sshguard with STDIN as an input ,
> I have no method to produce the problem so far.
>
> # sshguard -v
> SSHGuard 2.4.1
>
>

The website first page:

sshguard can read log messages from standard input (suitable for
piping from syslog)

But since (openbsd 6.8) 2.4.1

# cat /var/log/authlog | sshguard
sshguard: /etc/sshguard.conf is missing FILES and LOGREADER; please specify one

It s in the release note of 2.4.0:

2.4.0

[..]

Removed

No longer accept logs given via standard input

And it makes no sense at all given the statement of the home page

Is there a proposed workaround using a silly LOGREADER ?

like ?
# grep LOGREADER /etc/sshguard.conf
#LOGREADER="LANG=C /usr/bin/journalctl -afb -p info -n1 -t sshd -t
sendmail -o cat"
LOGREADER=/bin/cat
# SSHGUARD_DEBUG=1 cat /var/log/authlog | sshguard
Terminated

Best.


--
--
---------------------------------------------------------------------------------------------------------------------
Knowing is not enough; we must apply. Willing is not enough; we must do

Re: [SSHGuard-users] Dumb Question for the year

[Christos C. <ch...@cr...>]

> On 17 Jun 2021, at 22:13, jason hirsh <hi...@at...> wrote:
> 
> 
> 
>> Begin forwarded message:
>> 
>> From: Jason Hirsh <ka...@ma... <mailto:ka...@ma...>>
>> Subject: Dumb Question for the year
>> Date: June 17, 2021 at 3:12:09 PM EDT
>> To: ssh...@li... <mailto:ssh...@li...>
>> 
>> I am running FreeBSD 13
>> 
>> I was doing some firewall work and I noticed the table 22 only has entries that I have manually added.
>> 
>> II use to start start SSHguard at through rc.conf
>> 
>> I go to stop using service SSHguard stop and it asks if it is running referring me to /var/run     It does not show
>> 
>> I try “service sshguard start”. and I get no errors.  I to the stop again and again the same go look at /var/run
>> 
>> I try ps -aux to find process… nothing related shows.
>> 
>> From this I sort of assume no sshguard
>> 
>> Any thoughts or suggestions??
> 

Did you add sshguard_enable="YES" in /etc/rc.conf ?

[SSHGuard-users] Dumb Question for the year

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

> Begin forwarded message:
> 
> From: Jason Hirsh <ka...@ma...>
> Subject: Dumb Question for the year
> Date: June 17, 2021 at 3:12:09 PM EDT
> To: ssh...@li...
> 
> I am running FreeBSD 13
> 
> I was doing some firewall work and I noticed the table 22 only has entries that I have manually added.
> 
> II use to start start SSHguard at through rc.conf
> 
> I go to stop using service SSHguard stop and it asks if it is running referring me to /var/run     It does not show
> 
> I try “service sshguard start”. and I get no errors.  I to the stop again and again the same go look at /var/run
> 
> I try ps -aux to find process… nothing related shows.
> 
> From this I sort of assume no sshguard
> 
> Any thoughts or suggestions??

Re: [SSHGuard-users] getting sshguard to work on macOS Big Sur

[Jin C. <js...@al...>]

> On Jun 15, 2021, at 10:15 PM, Kevin Zheng <kev...@gm...> wrote:
> 
> Hi Jin,
> 
> On 6/15/21 11:31 AM, Jin Choi wrote:
>> I noticed that sshguard was not working for me on recent versions of macOS because the necessary information from sshd wasn’t getting reported by the log stream. I dug into it a little bit and found the following to work (from https://superuser.com/questions/1565891/how-to-get-ssh-logs-and-send-to-remote-syslog-server-in-macos <https://superuser.com/questions/1565891/how-to-get-ssh-logs-and-send-to-remote-syslog-server-in-macos>):
>> LOGREADER="/usr/bin/log stream --process sshd --info --style syslog --predicate \"messageType = 'info'\""
> 
> Thanks for reporting this. Do you know if this new syntax is backwards-compatible with older versions like Catalina?

I just tried it in a 10.14 VM and it works there. In fact, it seems to more reliably report the info necessary for sshguard than the old method without the spew of unrelated messages from subsystems.

Re: [SSHGuard-users] getting sshguard to work on macOS Big Sur

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

Hi Jin,

On 6/15/21 11:31 AM, Jin Choi wrote:
> I noticed that sshguard was not working for me on recent versions of 
> macOS because the necessary information from sshd wasn’t getting 
> reported by the log stream. I dug into it a little bit and found the 
> following to work (from 
> https://superuser.com/questions/1565891/how-to-get-ssh-logs-and-send-to-remote-syslog-server-in-macos 
> <https://superuser.com/questions/1565891/how-to-get-ssh-logs-and-send-to-remote-syslog-server-in-macos>):
> 
> LOGREADER="/usr/bin/log stream --process sshd --info --style syslog 
> --predicate \"messageType = 'info'\""

Thanks for reporting this. Do you know if this new syntax is 
backwards-compatible with older versions like Catalina?

> Also, pfctl is no longer enabled on startup by default. The easiest way 
> to get it enabled persistently without trying to mess with SIP protected 
> files is to enable “stealth mode” in the system firewall 
> (https://stackoverflow.com/questions/51017493/how-to-enable-pfctl-on-boot-time-on-mac-os 
> <https://stackoverflow.com/questions/51017493/how-to-enable-pfctl-on-boot-time-on-mac-os>).

This would be good to add to the sshguard-setup(7) man page.

[SSHGuard-users] getting sshguard to work on macOS Big Sur

[Jin C. <js...@al...>]

I noticed that sshguard was not working for me on recent versions of macOS because the necessary information from sshd wasn’t getting reported by the log stream. I dug into it a little bit and found the following to work (from https://superuser.com/questions/1565891/how-to-get-ssh-logs-and-send-to-remote-syslog-server-in-macos <https://superuser.com/questions/1565891/how-to-get-ssh-logs-and-send-to-remote-syslog-server-in-macos>):

LOGREADER="/usr/bin/log stream --process sshd --info --style syslog --predicate \"messageType = 'info'\""


Also, pfctl is no longer enabled on startup by default. The easiest way to get it enabled persistently without trying to mess with SIP protected files is to enable “stealth mode” in the system firewall (https://stackoverflow.com/questions/51017493/how-to-enable-pfctl-on-boot-time-on-mac-os <https://stackoverflow.com/questions/51017493/how-to-enable-pfctl-on-boot-time-on-mac-os>).

Re: [SSHGuard-users] Stale threshold (detection time ?) after one temporary block

[kaycee gb <kis...@ho...>]

Le Tue, 25 May 2021 19:01:03 +0000,
jack keradec <cm...@li...> a écrit :

> 
> 
> ________________________________
> >De : kaycee gb <kis...@ho...>
> >Envoyé : mardi 25 mai 2021 16:41
> >À : "ssh...@li...\"
> ><ssh...@li...>"@mail.lacabanedeladmin.trickip.net
> ><"ssh...@li...\"
> >><ssh...@li...>"@mail.lacabanedeladmin.trickip.net>
> >>Objet : [SSHGuard-users] Stale threshold (detection time ?) after one
> >>temporary block
> >
> >Hello,
> >
> >I read for detection_time:
> >># Remember potential attackers for up to DETECTION_TIME seconds before
> >># resetting their score. (optional, default 1800)
> >
> >I have a detection time set let say to 6 hours. I can see in logs that an
> >attacker is still tracked after a longer period (after 2, 3, 4 days ... ).
> 
> What I understand is that after the DETCTION-TIME period, the attacker can
> come back to try to connect w/ ssh. 
I thought it was working like that too. 

>And the cycle begins again (nb of
> tentave/seconds, banned a litlle, etc...)
But for the cycle to begins again you have to forget totally about the attacker.
As I see it now, it is not the case. Or maybe I just don't found that part
in the code yet. 
> 
> But yes, the question "what happens to offenders" is still a gooq question.
> --
> cmic, ssh-guard on Debian 10
> 
> >
> >Looking again in code, I see that after stale_threshold "attackers" are
> >purged from "limbo" list. But when they had been temporary blocked, they are
> >no longer in this list but in "offenders". I do see nowhere that attackers
> >are purged from "offenders" list.
> >
> >How is SSHGuard supposed to work in this case ?
> >
> >Thanks,
> >K.
> 
> 
> _______________________________________________
> sshguard-users mailing list
> ssh...@li...
> https://lists.sourceforge.net/lists/listinfo/sshguard-users

[SSHGuard-users] Stale threshold (detection time ?) after one temporary block

[kaycee gb <kis...@ho...>]

Hello,

I read for detection_time:
># Remember potential attackers for up to DETECTION_TIME seconds before
># resetting their score. (optional, default 1800)

I have a detection time set let say to 6 hours. I can see in logs that an
attacker is still tracked after a longer period (after 2, 3, 4 days ... ). 

Looking again in code, I see that after stale_threshold "attackers" are purged
from "limbo" list. But when they had been temporary blocked, they are no longer
in this list but in "offenders". I do see nowhere that attackers are purged from
"offenders" list. 

How is SSHGuard supposed to work in this case ? 

Thanks,
K.