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: Paul E. <hi...@pa...> - 2011-02-19 12:39:47
|
Hi SSH Guard community, I absolutely love SSH Guard: easy to configure and (until now) reliable. But there's a problem coming up: SSH Guard has problems blocking attackers but isn't throwing any errors. I configured Netfiler/iptables the following way (snippets to keep it small): Chain INPUT (policy DROP) ... sshguard all -- anywhere anywhere ... Chain sshguard (1 references) target prot opt source destination This is how /var/log/auth.log looks like (this is just small attack to keep it clean): (195 more (unblocked) brute-force attacks above) Feb 19 02:02:06 localhost sshd[7575]: Invalid user weblogic from 59.50.36.46 Feb 19 02:02:06 localhost sshguard[2820]: Blocking 59.50.36.46:4 for >945secs: 40 danger in 4 attacks over 9 seconds (all: 80d in 2 abuses over 651s). Feb 19 02:02:08 localhost sshd[7578]: Invalid user ircd from 59.50.36.46 (Attacker stopped 150 attacks later) As you can see SSH Guard tries to block the attacker but isn't printing out any errors. The attacker is still able to attack. Is there anything I am missing? Something I can try? Thanks for your help! :) Regards Paul Engstler Designer, Developer and Student. |
|
From: Joe G. <jg...@ns...> - 2011-01-27 22:37:38
|
> Your logs seem to say that sshguard is not receiving those messages. > > Please try out the following possibilities: > > 1) replace "|/usr/local/sbin/sshguard" with "|exec /usr/local/sbin/sshguard" in syslog.conf (and reload) I just checked, both will work, with or without additional arguments/parameters to sshguard, on a FreeBSD 8.1R box. > 2) if you still see nothing, replace > "|/usr/local/sbin/sshguard" with "|tee -a /tmp/myfile | /usr/local/sbin/sshguard" (and reload) then > see with "tail -F /tmp/myfile" if log entries are actually received. That's probably the best advice; see what's happening to the data. Here, sshguard was one of those too-good-to-be-true gadgets - it just installed, ran, and functioned out of the box. We had to tweak it just a bit to avoid it getting paranoid about our NMS port checks, but that was it. ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net "We call it the 'one bite at the apple' rule. Give me one chance [and] then I won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN) With 24 million small businesses in the US alone, that's way too many apples. |
|
From: Mij <mi...@ss...> - 2011-01-27 18:52:04
|
Hi Marcus, Your logs seem to say that sshguard is not receiving those messages. Please try out the following possibilities: 1) replace "|/usr/local/sbin/sshguard" with "|exec /usr/local/sbin/sshguard" in syslog.conf (and reload) 2) if you still see nothing, replace "|/usr/local/sbin/sshguard" with "|tee -a /tmp/myfile | /usr/local/sbin/sshguard" (and reload) then see with "tail -F /tmp/myfile" if log entries are actually received. 3) comment the sshguard line in syslog, try to run sshguard in this mode: http://www.sshguard.net/docs/setup/getlogs/raw-file/ and see if /var/log/auth.log contains notifications from sshguard. Essentially, you should find messages going: Jan 2 18:57:40 x sshd[92019]: Invalid user heroin from 70.84.184.242 Jan 2 18:57:40 x sshd[92019]: Invalid user heroin from 70.84.184.242 Jan 2 18:57:40 x sshd[92019]: Invalid user heroin from 70.84.184.242 Jan 2 18:57:41 x sshd[92022]: Invalid user heroin from 70.84.184.242 Jan 2 18:57:41 x sshguard[92021]: Blocking 70.84.184.242:4 for >630secs: 20 danger in 2 attacks over 1 seconds (all: 20d in 1 abuses over 1s). On Dec 28, 2010, at 02:34 , Marcus wrote: > I have ask the same question in forums.freebsd.org, no reply solved the problem. > > ------------ > > in /etc/syslog.conf have two lines > > auth.info;authpriv.info |/usr/local/sbin/sshguard > auth.info;authpriv.info /var/log/auth.log > > # /etc/rc.d/syslogd reload > > > /etc/pf.conf have only 5 lines > > ext_if="bce1" > table <sshguard> persist > block in quick on $ext_if from <sshguard> > pass in > pass out > > > # pfctl -f /etc/pf.conf > > # top | grep sshg > 1296 root 2 44 0 7184K 1604K nanslp 0 0:00 0.00% sshguard > > > test the brute force ssh, nothing found excecpt > ---------- > Dec 28 09:32:13 b sshguard[1445]: Started successfully [(a,p,s)=(4, > 420, 1200)], now ready to scan. > Dec 28 09:32:42 b sshd[1447]: Invalid user a from 10.0.0.88 > Dec 28 09:32:42 b sshd[1447]: error: PAM: authentication error for > illegal user a from 10.0.0.88 > Dec 28 09:32:42 b sshd[1447]: Failed keyboard-interactive/pam for > invalid user a from 10.0.0.88 port 49464 ssh2 > Dec 28 09:32:43 b sshd[1447]: error: PAM: authentication error for > illegal user a from 10.0.0.88 > Dec 28 09:32:43 b sshd[1447]: Failed keyboard-interactive/pam for > invalid user a from 10.0.0.88 port 49464 ssh2 > Dec 28 09:32:48 b sshd[1451]: Invalid user a from 10.0.0.88 > Dec 28 09:32:48 b sshd[1451]: error: PAM: authentication error for > illegal user a from 10.0.0.88 > Dec 28 09:32:48 b sshd[1451]: Failed keyboard-interactive/pam for > invalid user a from 10.0.0.88 port 49465 ssh2 > Dec 28 09:32:48 b sshd[1451]: error: PAM: authentication error for > illegal user a from 10.0.0.88 > Dec 28 09:32:48 b sshd[1451]: Failed keyboard-interactive/pam for > invalid user a from 10.0.0.88 port 49465 ssh2 > Dec 28 09:32:52 b sshd[1455]: Invalid user ab from 10.0.0.88 > Dec 28 09:32:52 b sshd[1455]: error: PAM: authentication error for > illegal user ab from 10.0.0.88 > Dec 28 09:32:52 b sshd[1455]: Failed keyboard-interactive/pam for > invalid user ab from 10.0.0.88 port 49466 ssh2 > Dec 28 09:32:52 b sshd[1455]: error: PAM: authentication error for > illegal user ab from 10.0.0.88 > Dec 28 09:32:52 b sshd[1455]: Failed keyboard-interactive/pam for > invalid user ab from 10.0.0.88 port 49466 ssh2 > Dec 28 09:32:56 b sshd[1459]: Invalid user a from 10.0.0.88 > Dec 28 09:32:56 b sshd[1459]: error: PAM: authentication error for > illegal user a from 10.0.0.88 > Dec 28 09:32:56 b sshd[1459]: Failed keyboard-interactive/pam for > invalid user a from 10.0.0.88 port 49467 ssh2 > Dec 28 09:32:56 b sshd[1459]: error: PAM: authentication error for > illegal user a from 10.0.0.88 > Dec 28 09:32:56 b sshd[1459]: Failed keyboard-interactive/pam for > invalid user a from 10.0.0.88 port 49467 ssh2 > Dec 28 09:33:00 b sshd[1463]: Invalid user a from 10.0.0.88 > Dec 28 09:33:00 b sshd[1463]: error: PAM: authentication error for > illegal user a from 10.0.0.88 > Dec 28 09:33:00 b sshd[1463]: Failed keyboard-interactive/pam for > invalid user a from 10.0.0.88 port 49468 ssh2 > Dec 28 09:33:01 b sshd[1463]: error: PAM: authentication error for > illegal user a from 10.0.0.88 > Dec 28 09:33:01 b sshd[1463]: Failed keyboard-interactive/pam for > invalid user a from 10.0.0.88 port 49468 ssh2 > Dec 28 09:33:04 b sshd[1479]: Invalid user a from 10.0.0.88 > Dec 28 09:33:05 b sshd[1479]: error: PAM: authentication error for > illegal user a from 10.0.0.88 > Dec 28 09:33:05 b sshd[1479]: Failed keyboard-interactive/pam for > invalid user a from 10.0.0.88 port 49469 ssh2 > Dec 28 09:33:05 b sshd[1479]: error: PAM: authentication error for > illegal user a from 10.0.0.88 > Dec 28 09:33:05 b sshd[1479]: Failed keyboard-interactive/pam for > invalid user a from 10.0.0.88 port 49469 ssh2 > Dec 28 09:33:09 b sshd[1483]: Invalid user a from 10.0.0.88 > Dec 28 09:33:09 b sshd[1483]: error: PAM: authentication error for > illegal user a from 10.0.0.88 > Dec 28 09:33:09 b sshd[1483]: Failed keyboard-interactive/pam for > invalid user a from 10.0.0.88 port 49470 ssh2 > Dec 28 09:33:09 b sshd[1483]: error: PAM: authentication error for > illegal user a from 10.0.0.88 > Dec 28 09:33:09 b sshd[1483]: Failed keyboard-interactive/pam for > invalid user a from 10.0.0.88 port 49470 ssh2 > > ------------------------------------------------------------------------------ > Learn how Oracle Real Application Clusters (RAC) One Node allows customers > to consolidate database storage, standardize their database environment, and, > should the need arise, upgrade to a full multi-node Oracle RAC database > without downtime or disruption > http://p.sf.net/sfu/oracle-sfdevnl > _______________________________________________ > Sshguard-users mailing list > Ssh...@li... > https://lists.sourceforge.net/lists/listinfo/sshguard-users |
|
From: Mij <mi...@ss...> - 2011-01-27 18:37:19
|
Hi John On Oct 26, 2010, at 18:34 , John Vinopal wrote: > Hi, thanks for the helpful application. I've built a FreeBSD port for 1.5rc4 and have been running it for several days. > > Here are the few issues I've noticed: > > -v reports 1.4.4 updated in r218, as 1.5 is being released soon > -i path-to-pidfile not documented in sshguard.8 committed in r219, thanks > start of process doesn't print startup log message (FreeBSD std syslog.conf) > - uses LOG_INFO, should probably use LOG_NOTICE I see no reasons against this: committed as r220 > no option to daemonize on start? any problem doing it from the start script? The shell can do that easily. > missing log message to indicate end of blocking (FreeBSD std syslog.conf) > - block and unblock should probably use same logging level > - currently block uses LOG_NOTICE and unblock LOG_INFO I believe block is quite more important than unblock. Block is the apex of an attack, whereas unblock is only a technical req for avoiding "trapping" addresses. > kill of sshguard process yields log message: > Oct 25 16:29:02 gabriella sshguard[42655]: Got CONTINUE signal, resuming activity. The logic looks sane there (sshguard.c:197), are you sending a SIGCONT? |
|
From: Mij <mi...@ss...> - 2011-01-27 07:29:20
|
Hi Julian
PATH_MAX is required by POSIX.1 from limits.h, and the _XOPEN_SOURCE
def I see passed in your gcc logs should enable that.
You could try to trace why PATH_MAX is not defined with some of these commands:
gcc -dD -E -DHAVE_CONFIG_H -I. -I. -std=c99 -Wall -D_XOPEN_SOURCE -g -O2 -c sshguard_logsuck.c
--> see PATH_MAX in output? If not, cross-check with limits.h and find the variable
closest (in the headers) to it.
gcc -dD -E -DHAVE_CONFIG_H -I. -I. -std=c99 -Wall -D_XOPEN_SOURCE -g -O2 -c sshguard_logsuck.c
--> this tells you what sequence of headers is included. If your OS has PATH_MAX (only) in
sys/syslimits.h, that should end up showing up there.
Feature-test macros normally wind up being tweaked by educated trial & error, since they
are compiler-specific but the headers are system-specific. Your OS is a special combo, so
there they could take some extra care.
On Dec 28, 2010, at 23:57 , Julián Moreno Patiño wrote:
> Hi Mij,
>
> This FTBFS could be avoided if is added in src/sshguard_logsuck.c :
>
> #ifndef PATH_MAX
> # define PATH_MAX 4096
> #endif
>
> I find best solution:
>
> #ifndef PATH_MAX
> # include <sys/syslimits.h>
> #endif
>
> In kfreeBSD PATH_MAX value is in sys/syslimits.h , please considerer added in src/sshguard_logsuck.c
>
> Kind regards,
> --
> Julián Moreno Patiño
> .''`. Debian GNU/{Linux,KfreeBSD}
> : :' : Free Operating Systems
> `. `' http://debian.org/
> `- PGP KEY ID 6168BF60
> Registered GNU Linux User ID 488513
> ------------------------------------------------------------------------------
> Learn how Oracle Real Application Clusters (RAC) One Node allows customers
> to consolidate database storage, standardize their database environment, and,
> should the need arise, upgrade to a full multi-node Oracle RAC database
> without downtime or disruption
> http://p.sf.net/sfu/oracle-sfdevnl_______________________________________________
> Sshguard-users mailing list
> Ssh...@li...
> https://lists.sourceforge.net/lists/listinfo/sshguard-users
|
|
From: Mail U. <tem...@go...> - 2011-01-26 16:03:15
|
When FreeBSD's syslogd runs with -v -v, the log changes from
Jan 26 15:18:35 box sshd[57785]: error: PAM: authentication error for
user from evil
to
Jan 26 15:18:35 <auth.err> box sshd[57785]: error: PAM: authentication
error for user from evil
The following patch fixes this problem:
--- src/parser/attack_scanner.l.ORI 2011-01-26 16:23:43.000000000 +0100
+++ src/parser/attack_scanner.l 2011-01-26 16:24:01.000000000 +0100
@@ -99,12 +99,18 @@
*/
/* handle entries with PID and without PID from processes other than
sshguard */
+{TIMESTAMP_SYSLOG}[ ]+<[[:alnum:]]+\.[[:alnum:]]+>[
]+({WORD}|{HOSTADDR})[ ]+{PROCESSNAME}"["{NUMBER}"]:" {
+ /* extract PID */
+ yylval.num = getsyslogpid(yytext, yyleng);
+ return SYSLOG_BANNER_PID;
+ }
{TIMESTAMP_SYSLOG}[ ]+({WORD}|{HOSTADDR})[ ]+{PROCESSNAME}"["{NUMBER}"]:" {
/* extract PID */
yylval.num = getsyslogpid(yytext, yyleng);
return SYSLOG_BANNER_PID;
}
+{TIMESTAMP_SYSLOG}[ ]+<[[:alnum:]]+\.[[:alnum:]]+>[
]+({WORD}|{HOSTADDR})[ ]+{PROCESSNAME}":" { return SYSLOG_BANNER; }
{TIMESTAMP_SYSLOG}[ ]+({WORD}|{HOSTADDR})[ ]+{PROCESSNAME}":" {
return SYSLOG_BANNER; }
/* metalog banner */
|
|
From: Johan B. <jo...@be...> - 2011-01-14 15:04:18
|
Hello, you should update version in config.h, was kinda confusing (at least until i figured it out :) to read 1.4 when running sshguard -v. Cheers, Johan |
|
From: Colin K. <col...@gm...> - 2011-01-13 02:51:05
|
On Wed, Jan 12, 2011 at 12:09 PM, Mij <mi...@ss...> wrote:
> As a side note, the "exited 1" message is likely up to ip6tables, since you
> mention you didn't configure its tables.
> In that case, you can get over that too.
My first guess was ip6tables since that has always caused headaches
for me. As such the patch is to change
--- sshguard-1.5rc3/src/fwalls/command_iptables.h.orig 2010-04-27
11:13:53.000000000 -0400
+++ sshguard-1.5rc3/src/fwalls/command_iptables.h 2010-04-27
12:40:16.000000000 -0400
@@ -38,7 +38,7 @@
* $SSHG_ADDRKIND the code of the address type [see
sshguard_addresskind.h] (e.g. 4)
* $SSHG_SERVICE the code of the service attacked [see
sshguard_services.h] (e.g. 10)
*/
-#define COMMAND_BLOCK "case $SSHG_ADDRKIND in 4) exec "
IPTABLES_PATH "/iptables -I sshguard -s $SSHG_ADDR -j DROP ;; 6) exec
" IPTABLES_PATH "/ip6tables -I sshguard -s $SSHG_ADDR -j DROP ;; *)
exit -2 ;; esac"
+#define COMMAND_BLOCK "case $SSHG_ADDRKIND in 4) exec "
IPTABLES_PATH "/iptables -I sshguard -s $SSHG_ADDR -j DROP ;; *) exit
-2 ;; esac"
/* iptables does not support blocking multiple addresses in one call.
* COMMAND_BLOCK_LIST can not be provided here, a sequence of calls to
@@ -50,10 +50,10 @@
* $SSHG_ADDRKIND the code of the address type [see
sshguard_addresskind.h] (e.g. 4)
* $SSHG_SERVICE the code of the service attacked [see
sshguard_services.h] (e.g. 10)
*/
-#define COMMAND_RELEASE "case $SSHG_ADDRKIND in 4) exec "
IPTABLES_PATH "/iptables -D sshguard -s $SSHG_ADDR -j DROP ;; 6) exec
" IPTABLES_PATH "/ip6tables -D sshguard -s $SSHG_ADDR -j DROP ;; *)
exit -2 ;; esac"
+#define COMMAND_RELEASE "case $SSHG_ADDRKIND in 4) exec "
IPTABLES_PATH "/iptables -D sshguard -s $SSHG_ADDR -j DROP ;; *) exit
-2 ;; esac"
/* for releasing all blocked IPs at once (blocks flush) */
-#define COMMAND_FLUSH IPTABLES_PATH "/iptables -F sshguard ; "
IPTABLES_PATH "/ip6tables -F sshguard"
+#define COMMAND_FLUSH IPTABLES_PATH "/iptables -F sshguard ; "
#endif
------
Sorry if the mail program breaks the patch file but you'll get the
gist of it. I don't know if it would be easy to add a check to
configure.ac for this, perhaps something like:
iptables)
AC_CHECK_PROG(hasip6tables, iptables, `which ip6tables | xargs
dirname`, "")
if test x$hasip6tables = x
then
AC_DEFINE(IPTABLES_HAS_IP6TABLES,1, [can use ip6tables])
fi
then update command_iptables.h to have COMMAND_BLOCK, COMMAND_RELEASE
and COMMAND_FLUSH use either iptables or iptables and ip6tables. E.g.
/* for releasing all blocked IPs at once (blocks flush) */
#ifdef IPTABLES_HAS_IP6TABLES
#define COMMAND_FLUSH IPTABLES_PATH "/iptables -F sshguard ; "
IPTABLES_PATH "/ip6tables -F sshguard"
#else
#define COMMAND_FLUSH IPTABLES_PATH "/iptables -F sshguard"
#end
Sorry this isn't a full patch, it is just an idea that occurred to me
as I was writing.
Regards,
Colin.
--
Colin Keith
Systems Administrator
Hagen Software Inc.
|
|
From: Mij <mi...@ss...> - 2011-01-12 17:27:19
|
Hi Peter, Hmm I didn't expect NetBSD to be this far from _BSD_SOURCE's semantics. Does it help if you (manually) run that failing gcc command with -D_XOPEN_SOURCE=500 instead? I might take a look at it from a VirtualBox machine in the future. On Sep 18, 2010, at 18:17 , Peter Kerwien wrote: > When building sshguard-1.5rc4 on NetBSD-5.0.2 (amd64) it fails with the > following error message: > > $> ./configure --prefix=/usr/local --with-firewall=pf > --with-pfctl=/sbin/pfctl > $> gmake > ... > gcc -DHAVE_CONFIG_H -I. -I. -std=c99 -Wall -D_XOPEN_SOURCE -g -O2 > -MT sshguard_whitelist.o -MD -MP -MF .deps/sshguard_whitelist.Tpo -c -o > sshguard_whitelist.o sshguard_whitelist.c > sshguard_whitelist.c: In function 'whitelist_add_block4': > sshguard_whitelist.c:252: warning: implicit declaration of function > 'inet_pton' > sshguard_whitelist.c: In function 'whitelist_add_host': > sshguard_whitelist.c:345: warning: implicit declaration of function > 'getaddrinfo' > sshguard_whitelist.c:347: warning: implicit declaration of function > 'gai_strerror' > sshguard_whitelist.c:347: warning: format '%s' expects type 'char *', > but argument 4 has type 'int' > sshguard_whitelist.c:351: error: dereferencing pointer to incomplete type > sshguard_whitelist.c:351: warning: left-hand operand of comma expression > has no effect > sshguard_whitelist.c:351: warning: value computed is not used > sshguard_whitelist.c:354: error: dereferencing pointer to incomplete type > sshguard_whitelist.c:356: warning: implicit declaration of function > 'inet_ntop' > sshguard_whitelist.c:356: error: dereferencing pointer to incomplete type > sshguard_whitelist.c:356: error: dereferencing pointer to incomplete type > sshguard_whitelist.c:356: warning: comparison between pointer and integer > sshguard_whitelist.c:361: error: dereferencing pointer to incomplete type > sshguard_whitelist.c:361: error: dereferencing pointer to incomplete type > sshguard_whitelist.c:361: warning: comparison between pointer and integer > sshguard_whitelist.c:371: warning: implicit declaration of function > 'freeaddrinfo' > gmake[2]: *** [sshguard_whitelist.o] Error 1 > gmake[2]: Leaving directory `/root/tmp/sshguard/src' > gmake[1]: *** [all-recursive] Error 1 > gmake[1]: Leaving directory `/root/tmp/sshguard/src' > gmake: *** [all] Error 2 > > It seems related to arpa/inet.h and what _XOPEN_SOURCE or _NETBSD_SOURCE > is defined to. > > /Peter > > ------------------------------------------------------------------------------ > Start uncovering the many advantages of virtual appliances > and start using them to simplify application deployment and > accelerate your shift to cloud computing. > http://p.sf.net/sfu/novell-sfdev2dev > _______________________________________________ > Sshguard-users mailing list > Ssh...@li... > https://lists.sourceforge.net/lists/listinfo/sshguard-users |
|
From: Mij <mi...@ss...> - 2011-01-12 17:11:16
|
Hey Julian
thank you for keeping SSHGuard friendly to the Debian tribe.
On Jan 5, 2011, at 01:09 , Julián Moreno Patiño wrote:
> Hi Mij,
>
> Right now sshguard has init script into experimental, Thanks for your time and help !
>
> Kind regards,
>
> --
> Julián Moreno Patiño
> .''`. Debian GNU/{Linux,KfreeBSD}
> : :' : Free Operating Systems
> `. `' http://debian.org/
> `- PGP KEY ID 6168BF60
> Registered GNU Linux User ID 488513
>
>
> ---------- Forwarded message ----------
> From: Debian FTP Masters <ftp...@ft...>
> Date: 2011/1/4
> Subject: sshguard_1.5~rc4-1_amd64.changes ACCEPTED into experimental
> To: Julián Moreno Patiño <dar...@gm...>, ca...@de...
>
>
>
> Accepted:
> sshguard_1.5~rc4-1.debian.tar.bz2
> to main/s/sshguard/sshguard_1.5~rc4-1.debian.tar.bz2
> sshguard_1.5~rc4-1.dsc
> to main/s/sshguard/sshguard_1.5~rc4-1.dsc
> sshguard_1.5~rc4-1_amd64.deb
> to main/s/sshguard/sshguard_1.5~rc4-1_amd64.deb
> sshguard_1.5~rc4.orig.tar.bz2
> to main/s/sshguard/sshguard_1.5~rc4.orig.tar.bz2
>
>
> Override entries for your package:
> sshguard_1.5~rc4-1.dsc - source net
> sshguard_1.5~rc4-1_amd64.deb - optional net
>
> Announcing to deb...@li...
> Closing bugs: 595915
>
>
> Thank you for your contribution to Debian.
> ------------------------------------------------------------------------------
> Learn how Oracle Real Application Clusters (RAC) One Node allows customers
> to consolidate database storage, standardize their database environment, and,
> should the need arise, upgrade to a full multi-node Oracle RAC database
> without downtime or disruption
> http://p.sf.net/sfu/oracle-sfdevnl_______________________________________________
> Sshguard-users mailing list
> Ssh...@li...
> https://lists.sourceforge.net/lists/listinfo/sshguard-users
|
|
From: Mij <mi...@ss...> - 2011-01-12 17:09:18
|
Hi Frans, On Dec 16, 2010, at 02:53 , Frans Middelkoop wrote: > I successfully installed sshguard on our debian system using the latest Debian version (1.4). > However, after a while sshguard is stopped automatically. > From the log I read the following: > > Dec 15 06:25:01 production CRON[3260]: pam_unix(cron:session): session opened for user root by (uid=0) > Dec 15 06:25:02 production sshguard[3083]: Run command "/sbin/iptables -F sshguard ; /sbin/ip6tables -F sshguard": exited 1. > Dec 15 06:26:46 production CRON[3260]: pam_unix(cron:session): session closed for user root > > Can anybody tell me how to avoid that sshguard is stopped? Checking out your setup, SSHGuard is likely restarted by syslog by log rotation procedures, so you should not be concerned with that. If you have psychological aversion to that, consider running sshguard with native Log Sucking mode (see http://www.sshguard.net/docs/setup/getlogs/log-sucker/ ). As a side note, the "exited 1" message is likely up to ip6tables, since you mention you didn't configure its tables. In that case, you can get over that too. > Thanks in advance, > Frans > > I installed sshguard by the following procedure: > Install sshguard using aptitude. > Type: > mkfifo /var/log/sshguard.fifo > > Add the following line to /etc/rsyslog.conf: > # sshguard > auth.info;authpriv.info |/var/log/sshguard.fifo > > Make sure sshguard starts at reboot by adding the file /etc/init.d/sshguard with the following content: > #!/bin/sh > cat /var/log/sshguard.fifo | /usr/sbin/sshguard & > > Make the file be recognized as an init script by running from the command lines: > chmod +x /etc/init.d/sshguard > update-rc.d sshguard defaults 80 > > > Make the following rule set for iptables by typing on the console: > iptables -N sshguard # for regular IPv4 support: > iptables -A INPUT -j sshguard # block all traffic from abusers that sshguard regards bad > It seems that the lines below work for Ipv6 support but I did not yet use it > ip6tables -N sshguard > ip6tables -A INPUT -j sshguard > > Now make a file with these rules that iptables can read by typing: > iptables-save > /etc/myiptables.conf > > Make sure these start at bootup by creating the file /etc/network/if-pre-up.d/iptables and add the lines: > #!/bin/bash (add only if not yet there) > /sbin/iptables-restore < /etc/ myiptables.conf > > The files need to be executable so change the permissions: > chmod +x /etc/network/if-pre-up.d/iptables > chmod +x /etc/myiptables.conf > > ------------------------------------------------------------------------------ > Lotusphere 2011 > Register now for Lotusphere 2011 and learn how > to connect the dots, take your collaborative environment > to the next level, and enter the era of Social Business. > http://p.sf.net/sfu/lotusphere-d2d_______________________________________________ > Sshguard-users mailing list > Ssh...@li... > https://lists.sourceforge.net/lists/listinfo/sshguard-users |
|
From: Julián M. P. <dar...@gm...> - 2011-01-05 00:09:29
|
Hi Mij,
Right now sshguard has init script into experimental, Thanks for your time
and help !
Kind regards,
--
Julián Moreno Patiño
.''`. Debian GNU/{Linux,KfreeBSD}
: :' : Free Operating Systems
`. `' http://debian.org/
`- PGP KEY ID 6168BF60
Registered GNU Linux User ID 488513
---------- Forwarded message ----------
From: Debian FTP Masters <ftp...@ft...>
Date: 2011/1/4
Subject: sshguard_1.5~rc4-1_amd64.changes ACCEPTED into experimental
To: Julián Moreno Patiño <dar...@gm...>, ca...@de...
Accepted:
sshguard_1.5~rc4-1.debian.tar.bz2
to main/s/sshguard/sshguard_1.5~rc4-1.debian.tar.bz2
sshguard_1.5~rc4-1.dsc
to main/s/sshguard/sshguard_1.5~rc4-1.dsc
sshguard_1.5~rc4-1_amd64.deb
to main/s/sshguard/sshguard_1.5~rc4-1_amd64.deb
sshguard_1.5~rc4.orig.tar.bz2
to main/s/sshguard/sshguard_1.5~rc4.orig.tar.bz2
Override entries for your package:
sshguard_1.5~rc4-1.dsc - source net
sshguard_1.5~rc4-1_amd64.deb - optional net
Announcing to deb...@li...
Closing bugs: 595915
Thank you for your contribution to Debian.
|
|
From: Julián M. P. <dar...@gm...> - 2010-12-28 22:57:56
|
Hi Mij,
This FTBFS could be avoided if is added in src/sshguard_logsuck.c :
>
> #ifndef PATH_MAX
> # define PATH_MAX 4096
> #endif
>
I find best solution:
#ifndef PATH_MAX
# include <sys/syslimits.h>
#endif
In kfreeBSD PATH_MAX value is in sys/syslimits.h , please considerer added
in src/sshguard_logsuck.c
Kind regards,
--
Julián Moreno Patiño
.''`. Debian GNU/{Linux,KfreeBSD}
: :' : Free Operating Systems
`. `' http://debian.org/
`- PGP KEY ID 6168BF60
Registered GNU Linux User ID 488513
|
|
From: Julián M. P. <dar...@gm...> - 2010-12-28 07:10:03
|
Hi Mij,
Now I am working in a daemon for Debian, but when I try to compile sshguard
1.5 rc4 in my kfreebsd system does not work:
make[1]: se sale del directorio `/home/junix/sshguard/sshguard-1.5rc4'
dh_auto_build
make[1]: se ingresa al directorio `/home/junix/sshguard/sshguard-1.5rc4'
Making all in src
make[2]: se ingresa al directorio `/home/junix/sshguard/sshguard-1.5rc4/src'
make all-recursive
make[3]: se ingresa al directorio `/home/junix/sshguard/sshguard-1.5rc4/src'
Making all in parser
make[4]: se ingresa al directorio
`/home/junix/sshguard/sshguard-1.5rc4/src/parser'
make all-am
make[5]: se ingresa al directorio
`/home/junix/sshguard/sshguard-1.5rc4/src/parser'
gcc -DHAVE_CONFIG_H -I. -I../../src -I. -I.. -Wall -std=c99
-D_POSIX_C_SOURCE=200112L -g -O2 -c attack_parser.c
gcc -DHAVE_CONFIG_H -I. -I../../src -I. -I.. -Wall -std=c99
-D_POSIX_C_SOURCE=200112L -g -O2 -c attack_scanner.c
attack_scanner.c:11736: warning: ‘yyunput’ defined but not used
attack_scanner.c:11786: warning: ‘input’ defined but not used
rm -f libparser.a
ar cru libparser.a attack_parser.o attack_scanner.o
ranlib libparser.a
make[5]: se sale del directorio
`/home/junix/sshguard/sshguard-1.5rc4/src/parser'
make[4]: se sale del directorio
`/home/junix/sshguard/sshguard-1.5rc4/src/parser'
Making all in fwalls
make[4]: se ingresa al directorio
`/home/junix/sshguard/sshguard-1.5rc4/src/fwalls'
gcc -DHAVE_CONFIG_H -I. -I../../src -I. -I.. -Wall -std=c99
-D_POSIX_C_SOURCE=200112L -g -O2 -c command.c
rm -f libfwall.a
ar cru libfwall.a command.o
ranlib libfwall.a
make[4]: se sale del directorio
`/home/junix/sshguard/sshguard-1.5rc4/src/fwalls'
make[4]: se ingresa al directorio `/home/junix/sshguard/sshguard-1.5rc4/src'
gcc -DHAVE_CONFIG_H -I. -I. -std=c99 -Wall -D_XOPEN_SOURCE -g -O2 -c
sshguard.c
gcc -DHAVE_CONFIG_H -I. -I. -std=c99 -Wall -D_XOPEN_SOURCE -g -O2 -c
seekers.c
gcc -DHAVE_CONFIG_H -I. -I. -std=c99 -Wall -D_XOPEN_SOURCE -g -O2 -c
sshguard_whitelist.c
gcc -DHAVE_CONFIG_H -I. -I. -std=c99 -Wall -D_XOPEN_SOURCE -g -O2 -c
sshguard_log.c
gcc -DHAVE_CONFIG_H -I. -I. -std=c99 -Wall -D_XOPEN_SOURCE -g -O2 -c
sshguard_procauth.c
gcc -DHAVE_CONFIG_H -I. -I. -std=c99 -Wall -D_XOPEN_SOURCE -g -O2 -c
sshguard_blacklist.c
gcc -DHAVE_CONFIG_H -I. -I. -std=c99 -Wall -D_XOPEN_SOURCE -g -O2 -c
sshguard_options.c
gcc -DHAVE_CONFIG_H -I. -I. -std=c99 -Wall -D_XOPEN_SOURCE -g -O2 -c
sshguard_logsuck.c
sshguard_logsuck.c:67: error: ‘PATH_MAX’ undeclared here (not in a function)
sshguard_logsuck.c: In function ‘logsuck_getline’:
sshguard_logsuck.c:245: warning: format ‘%lu’ expects type ‘long unsigned
int’, but argument 3 has type ‘uintptr_t’
make[4]: *** [sshguard_logsuck.o] Error 1
make[4]: se sale del directorio `/home/junix/sshguard/sshguard-1.5rc4/src'
make[3]: *** [all-recursive] Error 1
make[3]: se sale del directorio `/home/junix/sshguard/sshguard-1.5rc4/src'
make[2]: *** [all] Error 2
make[2]: se sale del directorio `/home/junix/sshguard/sshguard-1.5rc4/src'
make[1]: *** [all-recursive] Error 1
make[1]: se sale del directorio `/home/junix/sshguard/sshguard-1.5rc4'
dh_auto_build: make -j1 returned exit code 2
make: *** [build] Error 2
This FTBFS could be avoided if is added in src/sshguard_logsuck.c :
#ifndef PATH_MAX
# define PATH_MAX 4096
#endif
But I don't know if PATH_MAX value to KfreeBSD is right.
Any suggestion for this ?
Kind regards,
--
Julián Moreno Patiño
.''`. Debian GNU/{Linux,KfreeBSD}
: :' : Free Operating Systems
`. `' http://debian.org/
`- PGP KEY ID 6168BF60
Registered GNU Linux User ID 488513
|
|
From: Marcus <f5...@gm...> - 2010-12-28 01:34:15
|
I have ask the same question in forums.freebsd.org, no reply solved the problem. ------------ in /etc/syslog.conf have two lines auth.info;authpriv.info |/usr/local/sbin/sshguard auth.info;authpriv.info /var/log/auth.log # /etc/rc.d/syslogd reload /etc/pf.conf have only 5 lines ext_if="bce1" table <sshguard> persist block in quick on $ext_if from <sshguard> pass in pass out # pfctl -f /etc/pf.conf # top | grep sshg 1296 root 2 44 0 7184K 1604K nanslp 0 0:00 0.00% sshguard test the brute force ssh, nothing found excecpt ---------- Dec 28 09:32:13 b sshguard[1445]: Started successfully [(a,p,s)=(4, 420, 1200)], now ready to scan. Dec 28 09:32:42 b sshd[1447]: Invalid user a from 10.0.0.88 Dec 28 09:32:42 b sshd[1447]: error: PAM: authentication error for illegal user a from 10.0.0.88 Dec 28 09:32:42 b sshd[1447]: Failed keyboard-interactive/pam for invalid user a from 10.0.0.88 port 49464 ssh2 Dec 28 09:32:43 b sshd[1447]: error: PAM: authentication error for illegal user a from 10.0.0.88 Dec 28 09:32:43 b sshd[1447]: Failed keyboard-interactive/pam for invalid user a from 10.0.0.88 port 49464 ssh2 Dec 28 09:32:48 b sshd[1451]: Invalid user a from 10.0.0.88 Dec 28 09:32:48 b sshd[1451]: error: PAM: authentication error for illegal user a from 10.0.0.88 Dec 28 09:32:48 b sshd[1451]: Failed keyboard-interactive/pam for invalid user a from 10.0.0.88 port 49465 ssh2 Dec 28 09:32:48 b sshd[1451]: error: PAM: authentication error for illegal user a from 10.0.0.88 Dec 28 09:32:48 b sshd[1451]: Failed keyboard-interactive/pam for invalid user a from 10.0.0.88 port 49465 ssh2 Dec 28 09:32:52 b sshd[1455]: Invalid user ab from 10.0.0.88 Dec 28 09:32:52 b sshd[1455]: error: PAM: authentication error for illegal user ab from 10.0.0.88 Dec 28 09:32:52 b sshd[1455]: Failed keyboard-interactive/pam for invalid user ab from 10.0.0.88 port 49466 ssh2 Dec 28 09:32:52 b sshd[1455]: error: PAM: authentication error for illegal user ab from 10.0.0.88 Dec 28 09:32:52 b sshd[1455]: Failed keyboard-interactive/pam for invalid user ab from 10.0.0.88 port 49466 ssh2 Dec 28 09:32:56 b sshd[1459]: Invalid user a from 10.0.0.88 Dec 28 09:32:56 b sshd[1459]: error: PAM: authentication error for illegal user a from 10.0.0.88 Dec 28 09:32:56 b sshd[1459]: Failed keyboard-interactive/pam for invalid user a from 10.0.0.88 port 49467 ssh2 Dec 28 09:32:56 b sshd[1459]: error: PAM: authentication error for illegal user a from 10.0.0.88 Dec 28 09:32:56 b sshd[1459]: Failed keyboard-interactive/pam for invalid user a from 10.0.0.88 port 49467 ssh2 Dec 28 09:33:00 b sshd[1463]: Invalid user a from 10.0.0.88 Dec 28 09:33:00 b sshd[1463]: error: PAM: authentication error for illegal user a from 10.0.0.88 Dec 28 09:33:00 b sshd[1463]: Failed keyboard-interactive/pam for invalid user a from 10.0.0.88 port 49468 ssh2 Dec 28 09:33:01 b sshd[1463]: error: PAM: authentication error for illegal user a from 10.0.0.88 Dec 28 09:33:01 b sshd[1463]: Failed keyboard-interactive/pam for invalid user a from 10.0.0.88 port 49468 ssh2 Dec 28 09:33:04 b sshd[1479]: Invalid user a from 10.0.0.88 Dec 28 09:33:05 b sshd[1479]: error: PAM: authentication error for illegal user a from 10.0.0.88 Dec 28 09:33:05 b sshd[1479]: Failed keyboard-interactive/pam for invalid user a from 10.0.0.88 port 49469 ssh2 Dec 28 09:33:05 b sshd[1479]: error: PAM: authentication error for illegal user a from 10.0.0.88 Dec 28 09:33:05 b sshd[1479]: Failed keyboard-interactive/pam for invalid user a from 10.0.0.88 port 49469 ssh2 Dec 28 09:33:09 b sshd[1483]: Invalid user a from 10.0.0.88 Dec 28 09:33:09 b sshd[1483]: error: PAM: authentication error for illegal user a from 10.0.0.88 Dec 28 09:33:09 b sshd[1483]: Failed keyboard-interactive/pam for invalid user a from 10.0.0.88 port 49470 ssh2 Dec 28 09:33:09 b sshd[1483]: error: PAM: authentication error for illegal user a from 10.0.0.88 Dec 28 09:33:09 b sshd[1483]: Failed keyboard-interactive/pam for invalid user a from 10.0.0.88 port 49470 ssh2 |
|
From: Frans M. <fr...@bl...> - 2010-12-16 02:20:50
|
I successfully installed sshguard on our debian system using the latest Debian version (1.4). However, after a while sshguard is stopped automatically. >From the log I read the following: Dec 15 06:25:01 production CRON[3260]: pam_unix(cron:session): session opened for user root by (uid=0) Dec 15 06:25:02 production sshguard[3083]: Run command "/sbin/iptables -F sshguard ; /sbin/ip6tables -F sshguard": exited 1. Dec 15 06:26:46 production CRON[3260]: pam_unix(cron:session): session closed for user root Can anybody tell me how to avoid that sshguard is stopped? Thanks in advance, Frans I installed sshguard by the following procedure: Install sshguard using aptitude. Type: mkfifo /var/log/sshguard.fifo Add the following line to /etc/rsyslog.conf: # sshguard auth.info;authpriv.info |/var/log/sshguard.fifo Make sure sshguard starts at reboot by adding the file /etc/init.d/sshguard with the following content: #!/bin/sh cat /var/log/sshguard.fifo | /usr/sbin/sshguard & Make the file be recognized as an init script by running from the command lines: chmod +x /etc/init.d/sshguard* *update-rc.d sshguard defaults 80 Make the following rule set for iptables by typing on the console: iptables -N sshguard # for regular IPv4 support: iptables -A INPUT -j sshguard # block all traffic from abusers that sshguard regards bad It seems that the lines below work for Ipv6 support but I did not yet use it ip6tables -N sshguard ip6tables -A INPUT -j sshguard Now make a file with these rules that iptables can read by typing: iptables-save > /etc/myiptables.conf Make sure these start at bootup by creating the file /etc/network/if-pre-up.d/iptables and add the lines: #!/bin/bash (add only if not yet there) /sbin/iptables-restore < /etc/ myiptables.conf The files need to be executable so change the permissions: chmod +x /etc/network/if-pre-up.d/iptables chmod +x /etc/myiptables.conf |
|
From: Сергей Ш. <de...@of...> - 2010-12-12 22:08:25
|
I just registered in mailimg list and repost my message. Sorry if it isn't necessary. Hello. I'm using sshguard and it solved a lot of my problems. after checking the documentation I still have the question. Slackware Current, sshguard 1.5 (installed from sshguard-1.5rc4-x86_64-1cf.txz), iptables 1.4.10 sshguard is configured to use blacklist /etc/sshguard.black after reboot iptables chain named "sshguard" is clean, and just new attacker's addreses are banned. for example root@server:~# iptables --numeric -L sshguard | wc -l 24 root@server:~# wc -l /etc/sshguard.black 52 /etc/sshguard.black I don't know is it right. I guess that no. Maybe you will add this feature - to clean and refill iptables "sshguard" chain after reboot (or restart sshguard) from blacklist file? I think it may be proper. best regards, Sergey Shevchenko |
|
From: Mij <mi...@ss...> - 2010-12-08 20:40:45
|
Joe, The "Registration from ... failed" signatures you detail in your submission are implemented. For the others you brief only in your email, please perform another submission on the website with a full line for each. I'm talking about: 1) .*No registration for peer '.*' (from <HOST>) 2) .*Host <HOST> failed MD5 authentication for '.*' (.*) 3) .*Failed to authenticate user .*@<HOST>.* We need this for being sure to produce an appropriately tight signature for each. On Nov 29, 2010, at 13:57 , Joe Greco wrote: > Related to http://www.sshguard.net/support/submission/detail/49ce7182028d8b6f3e3d/ > > Asterisk is a telephony PBX application; it handles VoIP and POTS phone > traffic. Because a PBX is essentially a switch for voice traffic, it's > theoretically susceptible to attack, and in fact since many people use > numeric extensions and trivial passwords, many times it turns out to be > actually susceptible to brute force attacks. > > VoIP typically uses UDP transport, so an attacker trying to guess at > your passwords will bombard your server with hundreds or thousands of > packets per second of UDP traffic, essentially DoS'ing your server. > sshguard sitting live on a logfile from syslogd looks like the ideal > application to handle this. Many other people are running things like > fail2ban but it strikes me as suboptimal and requires python anyways, > so a fast compiled daemon is a better choice. > > The patterns needed are > > .*Registration from '.*' failed for '<HOST>' - Wrong password > .*Registration from '.*' failed for '<HOST>' - No matching peer found > .*Registration from '.*' failed for '<HOST>' - Username/auth name mismatch > .*No registration for peer '.*' (from <HOST>) > .*Host <HOST> failed MD5 authentication for '.*' (.*) > .*Failed to authenticate user .*@<HOST>.* > > But so far I'm having a little trouble getting even just the first one > to work. Maybe I'm just getting the rule structure wrong, but there's > another difficulty: Asterisk may bless its logfiles with color escape > codes. I'm not sure the best way to cope with that. I was trying just > ".*" to cover for it. Shouldn't that work? > > ... JG > -- > Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net > "We call it the 'one bite at the apple' rule. Give me one chance [and] then I > won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN) > With 24 million small businesses in the US alone, that's way too many apples. > > ------------------------------------------------------------------------------ > Increase Visibility of Your 3D Game App & Earn a Chance To Win $500! > Tap into the largest installed PC base & get more eyes on your game by > optimizing for Intel(R) Graphics Technology. Get started today with the > Intel(R) Software Partner Program. Five $500 cash prizes are up for grabs. > http://p.sf.net/sfu/intelisp-dev2dev > _______________________________________________ > Sshguard-users mailing list > Ssh...@li... > https://lists.sourceforge.net/lists/listinfo/sshguard-users |
|
From: Mij <mi...@ss...> - 2010-12-08 20:11:29
|
Thanks for the question, this opens the opportunity to clarify that: 1) the blacklist file is currently a binary file, so counting lines (as in "wc -l") does not necessarily represent the number of "entries" in there. This should answer your "not all addresses seem blocked" question. 2) people already asked to make it human readable. We'll likely do that some time soon. At the time, that's not felt like a major itch, but the more requests we get, the itchier it gets. 3) tj wrote a tool to handle the (binary) blacklist file. We never integrated it into the distribution pending point 2, but if you're keen enough here it is |
|
From: Сергей Ш. <de...@of...> - 2010-12-08 07:31:54
|
Hello. I'm using sshguard and it solved a lot of my problems. after checking the documentation I still have the question. Slackware Current, sshguard 1.5 (installed from sshguard-1.5rc4-x86_64-1cf.txz), iptables 1.4.10 sshguard is configured to use blacklist /etc/sshguard.black after reboot iptables chain named "sshguard" is clean, and just new attacker's addreses are banned. for example root@server:~# iptables --numeric -L sshguard | wc -l 24 root@server:~# wc -l /etc/sshguard.black 52 /etc/sshguard.black I don't know is it right. I guess that no. Maybe you will add this feature - to clean and refill iptables "sshguard" chain after reboot (or restart sshguard) from blacklist file? I think it may be proper. best regards, Sergey Shevchenko |
|
From: Mij <mi...@ss...> - 2010-12-05 23:52:57
|
On Nov 29, 2010, at 13:57 , Joe Greco wrote: > Related to http://www.sshguard.net/support/submission/detail/49ce7182028d8b6f3e3d/ > > Asterisk is a telephony PBX application; it handles VoIP and POTS phone > traffic. Because a PBX is essentially a switch for voice traffic, it's > theoretically susceptible to attack, and in fact since many people use > numeric extensions and trivial passwords, many times it turns out to be > actually susceptible to brute force attacks. This is a relevant and significant addition. Thanks for the accurate report, I'll bring this up as prio. As we're in RC, it won't make it in trunk before 1.5 stable, but I can provide you with a separate snapshot to test with. > VoIP typically uses UDP transport, so an attacker trying to guess at > your passwords will bombard your server with hundreds or thousands of > packets per second of UDP traffic, essentially DoS'ing your server. > sshguard sitting live on a logfile from syslogd looks like the ideal > application to handle this. Many other people are running things like > fail2ban but it strikes me as suboptimal and requires python anyways, > so a fast compiled daemon is a better choice. People choose based on what Google lists higher, and google lists based on what people link. So it's a spiral where elder stuff starts advantaged. It's awesome to read enthusiastic feedback from people, but if you really want to make a concrete difference you need to blog about it, or twitter it, or about it, or link to it. > The patterns needed are > > .*Registration from '.*' failed for '<HOST>' - Wrong password > .*Registration from '.*' failed for '<HOST>' - No matching peer found > .*Registration from '.*' failed for '<HOST>' - Username/auth name mismatch > .*No registration for peer '.*' (from <HOST>) > .*Host <HOST> failed MD5 authentication for '.*' (.*) > .*Failed to authenticate user .*@<HOST>.* > > But so far I'm having a little trouble getting even just the first one > to work. Maybe I'm just getting the rule structure wrong, but there's > another difficulty: Asterisk may bless its logfiles with color escape > codes. I'm not sure the best way to cope with that. I was trying just > ".*" to cover for it. Shouldn't that work? Wildcards must be used with a grain of salt. They make the tool "dumb" about what the log entry actually mean, and this can easily lead to log injection vulnerabilities (another of the reasons why SSHGuard favors its context-free parser over bare regular expressions). Does the default configuration dump color codes? We do favor solutions working out-of-the-box, so if this is not the case we can just match the color bytes with non-ascii ranges. > > ... JG > -- > Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net > "We call it the 'one bite at the apple' rule. Give me one chance [and] then I > won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN) > With 24 million small businesses in the US alone, that's way too many apples. > > ------------------------------------------------------------------------------ > Increase Visibility of Your 3D Game App & Earn a Chance To Win $500! > Tap into the largest installed PC base & get more eyes on your game by > optimizing for Intel(R) Graphics Technology. Get started today with the > Intel(R) Software Partner Program. Five $500 cash prizes are up for grabs. > http://p.sf.net/sfu/intelisp-dev2dev > _______________________________________________ > Sshguard-users mailing list > Ssh...@li... > https://lists.sourceforge.net/lists/listinfo/sshguard-users |
|
From: Joe G. <jg...@ns...> - 2010-11-29 13:57:10
|
Related to http://www.sshguard.net/support/submission/detail/49ce7182028d8b6f3e3d/ Asterisk is a telephony PBX application; it handles VoIP and POTS phone traffic. Because a PBX is essentially a switch for voice traffic, it's theoretically susceptible to attack, and in fact since many people use numeric extensions and trivial passwords, many times it turns out to be actually susceptible to brute force attacks. VoIP typically uses UDP transport, so an attacker trying to guess at your passwords will bombard your server with hundreds or thousands of packets per second of UDP traffic, essentially DoS'ing your server. sshguard sitting live on a logfile from syslogd looks like the ideal application to handle this. Many other people are running things like fail2ban but it strikes me as suboptimal and requires python anyways, so a fast compiled daemon is a better choice. The patterns needed are .*Registration from '.*' failed for '<HOST>' - Wrong password .*Registration from '.*' failed for '<HOST>' - No matching peer found .*Registration from '.*' failed for '<HOST>' - Username/auth name mismatch .*No registration for peer '.*' (from <HOST>) .*Host <HOST> failed MD5 authentication for '.*' (.*) .*Failed to authenticate user .*@<HOST>.* But so far I'm having a little trouble getting even just the first one to work. Maybe I'm just getting the rule structure wrong, but there's another difficulty: Asterisk may bless its logfiles with color escape codes. I'm not sure the best way to cope with that. I was trying just ".*" to cover for it. Shouldn't that work? ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net "We call it the 'one bite at the apple' rule. Give me one chance [and] then I won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN) With 24 million small businesses in the US alone, that's way too many apples. |
|
From: Mij <mi...@ss...> - 2010-11-20 13:35:21
|
On Nov 19, 2010, at 17:36 , krivetko wrote: > Hi! > I want to use sshguard in my linux box (Gentoo: syslog-ng + iptables), I've installed and configured it accordingly official documentation. I have default drop policy for all default chains and a set of accepting rules. I've created sshguard chain in iptables and added default accept rule: iptables -A sshguard -j ACCEPT, after that I've tried to login with random invalid login/pass for testing. There was message in syslog-ng: > Nov 19 23:09:20 localhost sshguard[16720]: Run command "case $SSHG_ADDRKIND in 4) exec /sbin/iptables -A sshguard -s $SSHG_ADDR -j DROP ;; 6) exec /sbin/ip6tables -A sshguard -s $SSHG_ADDR -j DROP ;; *) exit -2 ;; esac": exited 0. > Of course, the blocking rule was added after accepting rule. So, I think, maybe will be more correct to add rules in iptables with "-I 1" options? They will appear at the top of the chain and "good" packets will be accepted with the last rule? Yes, SSHGuard injects "block" rule, the "accept" rule to follow is up to you. Since this seems to raise some doubts, I added a sample ruleset to the docs based on a previous post. Check that out and adjust it to your context: http://www.sshguard.net/docs/setup/firewall/netfilter-iptables/ |
|
From: Mij <mi...@ss...> - 2010-11-20 12:16:03
|
On Aug 13, 2010, at 15:54 , H ghost wrote: > Hi: > > If I can use make update or make install new version to cover directly > instead to rm files by manaully? > > and, If sshgruard support the Web/IP (d)dos defense like Deflate for iptables? > http://deflate.medialayer.com Colin has already answered appropriately; for this one, I don't get what you mean either, but from the tool description I wonder: do you really want to block people that produce a bunch of connections to your server? What about websites with many images? Mailing lists? > > Thank you > > Range 10'08/13 > ------------------------------------------------------------------------------ > This SF.net email is sponsored by > > Make an app they can't live without > Enter the BlackBerry Developer Challenge > http://p.sf.net/sfu/RIM-dev2dev _______________________________________________ > Sshguard-users mailing list > Ssh...@li... > https://lists.sourceforge.net/lists/listinfo/sshguard-users |
|
From: Mij <mi...@ss...> - 2010-11-20 12:10:07
|
On Sep 21, 2010, at 16:43 , mihkel matson wrote: > Hello, > > I use the following raw file method: > tail -n0 -f /var/log/auth.log | /usr/local/sbin/sshguard -w /etc/sshguard.wl -a 10 -b 10:/etc/sshguard.bl > > My iptables default config is > iptables -N sshguard > iptables -A INPUT -p tcp -i eth0 --dport 80 -j ACCEPT > iptables -A INPUT -p tcp -i eth0 --dport 443 -j ACCEPT > iptables -A INPUT -p tcp -i eth0 --dport 21 -j ACCEPT > iptables -A INPUT -i eth0 -p tcp --dport 22 -j sshguard > > And my chain policies are: > iptables -P INPUT DROP > iptables -P FORWARD DROP > iptables -P OUTPUT ACCEPT (just for testing purposes) > > So if I have default policy to DROP everything and if it didn't pass any of my default rules - it will be dropped, right? Yep > Until the sshguard chain is empty, I cant access to my ssh server. What could be the solution? Read the note on http://www.sshguard.net/docs/setup/firewall/netfilter-iptables/ """ Verify that you have NOT a default allow rule passing all ssh traffic higher in the chain. Verify that you have NOT a default deny rule blocking all ssh traffic in your firewall. """ :) You want to say: - block whatever SSHGuard says is dangerous - allow everything else (to ssh) in iptables parlance, could look like: iptables -N sshguard iptables -A INPUT -p tcp -i eth0 --dport 80 -j ACCEPT iptables -A INPUT -p tcp -i eth0 --dport 443 -j ACCEPT iptables -A INPUT -p tcp -i eth0 --dport 21 -j ACCEPT iptables -A INPUT -i eth0 -p tcp -j sshguard iptables -A INPUT -i eth0 -p tcp --dport 22 -j ACCEPT sshguard inserts per-address DROP rules. Whatever is not catched in that chain will be allowed onto sshd. > If I start the sshguard, will it immediately add whitelist IP-s to sshguard chain. I cant see them, is there something wrong in my logic? whitelisting is an internal thing of SSHGuard, it's not reflected in the firewall. It works like this: the parser detects an attack. If the originator is in the whitelist (internal data structure) than ignore it, else proceed. > Thank you in advance! > BR, > z > > > > ------------------------------------------------------------------------------ > Start uncovering the many advantages of virtual appliances > and start using them to simplify application deployment and > accelerate your shift to cloud computing. > http://p.sf.net/sfu/novell-sfdev2dev_______________________________________________ > Sshguard-users mailing list > Ssh...@li... > https://lists.sourceforge.net/lists/listinfo/sshguard-users |