You can subscribe to this list here.
| 2007 |
Jan
|
Feb
|
Mar
(10) |
Apr
(7) |
May
(6) |
Jun
(13) |
Jul
(4) |
Aug
|
Sep
|
Oct
(17) |
Nov
(5) |
Dec
(4) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2008 |
Jan
(2) |
Feb
|
Mar
|
Apr
(4) |
May
(2) |
Jun
(7) |
Jul
(10) |
Aug
(4) |
Sep
(14) |
Oct
|
Nov
(1) |
Dec
(7) |
| 2009 |
Jan
(17) |
Feb
(20) |
Mar
(11) |
Apr
(14) |
May
(8) |
Jun
(3) |
Jul
(22) |
Aug
(9) |
Sep
(8) |
Oct
(6) |
Nov
(4) |
Dec
(8) |
| 2010 |
Jan
(17) |
Feb
(9) |
Mar
(15) |
Apr
(24) |
May
(14) |
Jun
(1) |
Jul
(21) |
Aug
(6) |
Sep
(2) |
Oct
(2) |
Nov
(6) |
Dec
(9) |
| 2011 |
Jan
(11) |
Feb
(1) |
Mar
(3) |
Apr
(4) |
May
|
Jun
|
Jul
(2) |
Aug
(3) |
Sep
(2) |
Oct
(29) |
Nov
(1) |
Dec
(1) |
| 2012 |
Jan
(1) |
Feb
(1) |
Mar
|
Apr
(13) |
May
(4) |
Jun
(9) |
Jul
(2) |
Aug
(2) |
Sep
(1) |
Oct
(2) |
Nov
(11) |
Dec
(4) |
| 2013 |
Jan
(2) |
Feb
(2) |
Mar
(4) |
Apr
(13) |
May
(4) |
Jun
|
Jul
|
Aug
(1) |
Sep
(5) |
Oct
(3) |
Nov
(1) |
Dec
(3) |
| 2014 |
Jan
|
Feb
(3) |
Mar
(3) |
Apr
(6) |
May
(8) |
Jun
|
Jul
|
Aug
(1) |
Sep
(1) |
Oct
(3) |
Nov
(14) |
Dec
(8) |
| 2015 |
Jan
(16) |
Feb
(30) |
Mar
(20) |
Apr
(5) |
May
(33) |
Jun
(11) |
Jul
(15) |
Aug
(91) |
Sep
(23) |
Oct
(10) |
Nov
(7) |
Dec
(9) |
| 2016 |
Jan
(22) |
Feb
(8) |
Mar
(6) |
Apr
(23) |
May
(38) |
Jun
(29) |
Jul
(43) |
Aug
(43) |
Sep
(18) |
Oct
(8) |
Nov
(2) |
Dec
(25) |
| 2017 |
Jan
(38) |
Feb
(3) |
Mar
(1) |
Apr
|
May
(18) |
Jun
(2) |
Jul
(16) |
Aug
(2) |
Sep
|
Oct
(1) |
Nov
(4) |
Dec
(14) |
| 2018 |
Jan
(15) |
Feb
(2) |
Mar
(3) |
Apr
(5) |
May
(8) |
Jun
(12) |
Jul
(19) |
Aug
(16) |
Sep
(8) |
Oct
(13) |
Nov
(15) |
Dec
(10) |
| 2019 |
Jan
(9) |
Feb
(3) |
Mar
|
Apr
(2) |
May
|
Jun
(1) |
Jul
|
Aug
(5) |
Sep
(5) |
Oct
(12) |
Nov
(4) |
Dec
|
| 2020 |
Jan
(2) |
Feb
(6) |
Mar
|
Apr
|
May
(11) |
Jun
(1) |
Jul
(3) |
Aug
(22) |
Sep
(8) |
Oct
|
Nov
(2) |
Dec
|
| 2021 |
Jan
(7) |
Feb
|
Mar
(19) |
Apr
|
May
(10) |
Jun
(5) |
Jul
(7) |
Aug
(3) |
Sep
(1) |
Oct
|
Nov
(10) |
Dec
(4) |
| 2022 |
Jan
(17) |
Feb
|
Mar
(7) |
Apr
(3) |
May
|
Jun
(1) |
Jul
(3) |
Aug
|
Sep
|
Oct
(6) |
Nov
|
Dec
|
| 2023 |
Jan
|
Feb
(5) |
Mar
(1) |
Apr
(3) |
May
|
Jun
(3) |
Jul
(2) |
Aug
|
Sep
|
Oct
|
Nov
(6) |
Dec
|
| 2024 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(3) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2025 |
Jan
|
Feb
|
Mar
(15) |
Apr
(8) |
May
(10) |
Jun
|
Jul
|
Aug
|
Sep
(6) |
Oct
|
Nov
|
Dec
|
|
From: Kevin Z. <kev...@gm...> - 2021-12-02 18:57:26
|
Hi Amit, On 12/1/21 11:41 AM, Amit Das wrote: > # Log reader command (optional, no default) > LOGREADER="LANG=C /usr/bin/journalctl -afb -p info -n1 -t sshd -t vsftpd > -o cat" Could you check that your LOGREADER command is actually giving you the log output from sshd? That is, run this command at the command line, and see if any failed login messages are coming through: $ /usr/bin/journalctl -afb -p info -n1 -t sshd -t vsftpd -o cat If they are coming through, pipe the output to `sshg-parser -a` and make sure the attacks you expect to be recognized are marked with an asterisk. Regards, Kevin |
|
From: Kevin Z. <kev...@gm...> - 2021-12-01 19:52:48
|
Hi Amit, It sounds like Ubuntu 18 and 20 broke SSHGuard for many users, not just you. I don't have the resources (an Ubuntu installation and experience using it) to troubleshoot. Do you know who the maintainer for SSHGuard on Ubuntu is and put us in touch, maybe in this thread? Thanks, Kevin |
|
From: Amit D. <ami...@gm...> - 2021-12-01 19:41:57
|
Hi Kevin, Thanks for the response. Could you please describe exactly what troubleshooting steps you tried? On ubuntu 16.04 apt install sshguard. Sucessfully works no issues on tests also. On ubuntu 18 and ubuntu 20 did "apt install sshguard". Version installed 1.7.3. sshguard status running. Did multiple attempts (more than 30) to ssh from different ip address but in auth logs i see sessions closing everytime Expected auth logs should be sshgurad to block the unauthrized attempts. As i have already install on more than 50 vms without testing on ubuntu 18 and 20 its difficult to build from source code and run on all machines. For example if i want to install sshguard on 50 vms (ubuntu 20) do i need compile build from source code on all VMs. " apt get install sshguard" will not work? Can you give more details about your setup and configuration? We can't help you if you don't. In sshguard troubleshooting it says: Check the paths first: where is iptables, or pfctl, or ipfw? You may need to specify their path explicitly from ./configure if they are not in standard paths nor in system's PATH.. I have ufw enabled and added the backend as # Full path to backend executable (required, no default) BACKEND="/usr/lib/sshguard/sshg-fw-iptables" # Log reader command (optional, no default) LOGREADER="LANG=C /usr/bin/journalctl -afb -p info -n1 -t sshd -t vsftpd -o cat" # How many problematic attempts trigger a block THRESHOLD=20 # Blocks last at least 180 seconds BLOCK_TIME=180 # The attackers are remembered for up to 3600 seconds DETECTION_TIME=3600 # Blacklist threshold and file name BLACKLIST_FILE=100:/var/db/sshguard/blacklist.db # IPv6 subnet size to block. Defaults to a single address, CIDR notation. (optional, default to 128) IPV6_SUBNET=64 # IPv4 subnet size to block. Defaults to a single address, CIDR notation. (optional, default to 32) IPV4_SUBNET=24 Restarted sshguard and ufw. Followed this document also which didnt work. Finally installed iptables. and updated the backend. This are the steps i followed. Please suggest me what i have missed here. Thanks amit On Wed, Dec 1, 2021 at 2:02 AM Kevin Zheng <kev...@gm...> wrote: > Hi Amit, > > On 11/30/21 11:51 AM, Amit Das wrote: > > I have used sshguard on ubuntu 16 without any issues. Recently i > > installed on ubuntu 18 and ubuntu 20 servers which is not working as > > expected. Went through few threads like > > > https://askubuntu.com/questions/1245543/how-do-i-configure-sshguard-in-ubuntu-20-04 > > < > https://askubuntu.com/questions/1245543/how-do-i-configure-sshguard-in-ubuntu-20-04> > > > which didn't help much. In my auth logs i can see closed sessions for > > unauthorized users sshd sessions but not blocking me even after > > multiple attempts. > > Could you please describe exactly what troubleshooting steps you tried? > Can you give more details about your setup and configuration? We can't > help you if you don't. > > Have you looked at the troubleshooting section of the sshguard-setup man > page? Which troubleshooting steps have you tried, if any? > > Regards, > Kevin > |
|
From: Kevin Z. <kev...@gm...> - 2021-11-30 20:32:56
|
Hi Amit, On 11/30/21 11:51 AM, Amit Das wrote: > I have used sshguard on ubuntu 16 without any issues. Recently i > installed on ubuntu 18 and ubuntu 20 servers which is not working as > expected. Went through few threads like > https://askubuntu.com/questions/1245543/how-do-i-configure-sshguard-in-ubuntu-20-04 > <https://askubuntu.com/questions/1245543/how-do-i-configure-sshguard-in-ubuntu-20-04> > which didn't help much. In my auth logs i can see closed sessions for > unauthorized users sshd sessions but not blocking me even after > multiple attempts. Could you please describe exactly what troubleshooting steps you tried? Can you give more details about your setup and configuration? We can't help you if you don't. Have you looked at the troubleshooting section of the sshguard-setup man page? Which troubleshooting steps have you tried, if any? Regards, Kevin |
|
From: Amit D. <ami...@gm...> - 2021-11-30 19:51:21
|
Hi, I have used sshguard on ubuntu 16 without any issues. Recently i installed on ubuntu 18 and ubuntu 20 servers which is not working as expected. Went through few threads like https://askubuntu.com/questions/1245543/how-do-i-configure-sshguard-in-ubuntu-20-04 which didn't help much. In my auth logs i can see closed sessions for unauthorized users sshd sessions but not blocking me even after multiple attempts. Also *backends *i dont see few packages /usr/lib/sshguard/sshd-fw or netfiler or iptables path. I am using ufw rules. There is a bug stating ip tables links broken. https://bugs.launchpad.net/ubuntu/+source/sshguard/+bug/1884848 Is this what i am missing here ? I have installed sshguard on 100s vms without testing on latest OS. Is there any simple way like may be apt commands to install latest version without compiling from source code. Please let me know simple solution. Thanks, amit |
|
From: Burton S. <Bu...@Bu...> - 2021-11-22 13:09:18
|
I think you will need to patch sshd... Find the line that generates that message and add the source IP to it. Then you'll be able to add the signature line to sshguard. -----Burton -----Original Message----- Message: 1 Date: Sat, 20 Nov 2021 07:13:19 +1100 From: Greg Bell <gbe...@ya...> To: ssh...@li... Subject: [SSHGuard-users] sshd and connections resulting in "kex_exchange_identification" errors Message-ID: <894...@ya...> Content-Type: text/plain; charset=utf-8; format=flowed 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 ------------------------------ ------------------------------ Subject: Digest Footer _______________________________________________ sshguard-users mailing list ssh...@li... https://lists.sourceforge.net/lists/listinfo/sshguard-users ------------------------------ End of sshguard-users Digest, Vol 117, Issue 3 ********************************************** |
|
From: Greg B. <gbe...@ya...> - 2021-11-19 20:13:38
|
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 |
|
From: Kevin B. <kev...@gm...> - 2021-11-19 02:01:29
|
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
|
|
From: Kevin Z. <kev...@gm...> - 2021-11-18 23:59:00
|
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 |
|
From: Greg B. <gbe...@ya...> - 2021-11-18 23:03:12
|
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? |
|
From: kaycee gb <kis...@ho...> - 2021-11-18 12:54:52
|
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. |
|
From: Nico S. <nic...@un...> - 2021-11-18 12:21:52
|
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 |
|
From: Greg B. <gbe...@ya...> - 2021-11-18 11:47:54
|
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? |
|
From: Kevin Z. <kev...@gm...> - 2021-09-01 17:53:48
|
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
|
|
From: Kevin Z. <kev...@gm...> - 2021-08-04 17:30:27
|
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 |
|
From: Nico S. <nic...@un...> - 2021-08-04 08:46:50
|
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 |
|
From: Kevin Z. <kev...@gm...> - 2021-08-04 05:15:13
|
Hi Nico, I've added the "query denied" signature for named in 961b590. Regards, Kevin |
|
From: Nico S. <nic...@un...> - 2021-07-28 11:31:13
|
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 |
|
From: Kevin Z. <kev...@gm...> - 2021-07-28 07:15:28
|
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 |
|
From: Nico S. <nic...@un...> - 2021-07-28 07:09:55
|
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 |
|
From: kaycee gb <kis...@ho...> - 2021-07-17 10:14:32
|
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. |
|
From: Sven F. <sve...@gm...> - 2021-07-17 00:00:43
|
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 |
|
From: Kevin Z. <kev...@gm...> - 2021-07-16 19:03:53
|
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 |
|
From: Sven F. <sve...@gm...> - 2021-07-16 17:41:45
|
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
|
|
From: Christos C. <ch...@cr...> - 2021-06-17 20:40:40
|
> 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 ? |