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
|
Oct
|
Nov
|
Dec
|
From: Colin K. <col...@gm...> - 2010-08-25 16:18:49
|
If you run "make install" then it will install the files for that version. As the names are the same from one version to another it means that your old version will be over written with the new version. The running process will be the old version though so you'll then need to kill off the old process and start it running again. I posted my configs that I use for init scripts on the list a while ago. If you don't have one you're welcome to copy those, but they're basically copies of an init script for another program like ssh with the name of the program changed. You can pretty much make it as simple as: cat /etc/init.d/ssh{,d} | sed 's/ssh/sshguard/g' > /etc/init.d/sshguard (cd /etc/rc3.d; ln -s ../init.d/sshguard S11sshguard; ln -s ../init.d/sshguard K85sshguard) Depending on where ssh and sshguard are installed you'll probably need to fix the paths as well, but that is left to the viewer. I'm not sure quite what you are asking in your second question. SSHguard was originally designed to mitigate dictionary/spam attacks against SSH servers. It does this by looking at the log files for failed login attempts. It turns out that this same process is very handy for other types of log files too so the developers expanded it to include patterns in other log files such as FTP logs and mail server logs. When it sees bad behaviour - a certain number of failed attempts, for example - it issues a call to your firewall, for example iptables, ipchains, ipfw etc. to block the access. It will try to add it to a unique list for supporting firewalls. For example for iptables it adds it to the "sshguard" chain. E.g. iptables -A sshguard -s <ip> -j DROP You can modify this yourself to have it do whatever you want. Simply look at the src/fwalls/command_*.h files for the command that is being issued. For example I use iptables but I don't use IPv6 so I remove the ip6tables commands to avoid errors. This is also the same command that this ddos.sh script uses, but you could modify this to use whatever you want for example if you use the TARPIT target (sadly no longer maintained and so removed from iptables), send the IP off to a customer facing firewall box or the like. Sshguard doesn't scan web server logs but you could also use snort or similar tools. Adding patterns is a little harder than some apps because they're hard coded rather than written dynamically. But one suggestion (possible classed as horrible suggestion, but that's left to the viewer) is to fake-out SSHguard. Rather than trying to work out your own patterns you could simply tell sshguard to look at another log file besides those that you actually want to monitor. Nothing writes to this log file normally. You could then have a script that looks at the web server logs (or is written to by your web scripts, if you wanted) and if it finds something that is bad then it writes an entry to your new log file in the form of a failed SSH login. The only difference is that the IP in that fake log file entry that you write is the one that made the bad web server access. That causes sshguard to block the IP as normal. Beyond that you need to then push all traffic through the sshguard chain. So rather than just sending port 22 or port 21, etc. traffic to it, you also send port 80, or as I do, all traffic once my iptable rules have been passed (which amongst other things allow me to always have ssh access to the box just in case sshguard hiccups and adds my IP to the block list) It is really a case of piping data from one form to another just as you do all the time with unix tools. Colin. -- Colin Keith Systems Administrator Hagen Software Inc. |
From: H g. <fre...@ho...> - 2010-08-13 13:54:19
|
> > I reinstall it again, and now can start already, > > (already show in PS result) > > But, If I want to uninstall it, How should I do? > > run > find /usr -name sshguard -or -name sshguard.8 > then "rm -f " each of the two files printed 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 Thank you Range 10'08/13 |
From: <op...@ni...> - 2010-08-10 22:39:24
|
Hello, Having found out that 1.4.4 does not support vsftpd I quickly compiled 1.5 rc4 for my system. While syslog-ng log parsing works like a charm, I have problems with the Log Sucker. I started sshguard in debug mode: env SSHGUARD_DEBUG=foo sshguard -l /var/log/auth.log Then I made some bogus ftp and ssh connections from another machine: Read line from '/var/log/auth.log'. Starting parse Entering state 0 Reading a token: --accepting rule at line 110 ("Aug 10 23:57:37 charlie vsftpd[1]: ") Next token is token SYSLOG_BANNER_PID () Shifting token SYSLOG_BANNER_PID () Entering state 1 Reading a token: --accepting rule at line 220 ("pam_unix") Next token is token WORD () Error: popping token SYSLOG_BANNER_PID () Stack now 0 Cleanup: discarding lookahead token WORD () Stack now 0 Read line from '/var/log/auth.log'. Starting parse Entering state 0 Reading a token: --accepting rule at line 110 ("Aug 10 23:59:42 charlie sshd[5509]: ") Next token is token SYSLOG_BANNER_PID () Shifting token SYSLOG_BANNER_PID () Entering state 1 Reading a token: --accepting rule at line 220 ("pam_unix") Next token is token WORD () Error: popping token SYSLOG_BANNER_PID () Stack now 0 Cleanup: discarding lookahead token WORD () Stack now 0 It looks like the log entry is truncated. I am using syslog-ng 3.1.1. If I start sshguard without -l and feed it the line then it works properly: Aug 10 23:57:39 charlie vsftpd[1]: [fijam] FAIL LOGIN: Client "192.168.1.11" Starting parse Entering state 0 Reading a token: --accepting rule at line 196 ("Aug 10 23:57:39 charlie vsftpd[1]: [fijam] FAIL LOGIN: Client "") Next token is token VSFTPD_LOGINERR_PREF () Shifting token VSFTPD_LOGINERR_PREF () Entering state 22 Reading a token: --accepting rule at line 201 ("192.168.1.11") Next token is token IPv4 () Shifting token IPv4 () Entering state 50 Reducing stack by rule 23 (line 203): $1 = token IPv4 () -> $$ = nterm addr () Stack now 0 22 Entering state 69 Reading a token: --accepting rule at line 197 (""") Next token is token VSFTPD_LOGINERR_SUFF () Shifting token VSFTPD_LOGINERR_SUFF () Entering state 82 Reducing stack by rule 47 (line 339): $1 = token VSFTPD_LOGINERR_PREF () $2 = nterm addr () $3 = token VSFTPD_LOGINERR_SUFF () -> $$ = nterm vsftpdmsg () Stack now 0 Entering state 45 Reducing stack by rule 21 (line 179): $1 = nterm vsftpdmsg () -> $$ = nterm msg_single () Stack now 0 Entering state 28 Reducing stack by rule 9 (line 163): $1 = nterm msg_single () -> $$ = nterm logmsg () Stack now 0 Entering state 27 Reducing stack by rule 4 (line 125): $1 = nterm logmsg () -> $$ = nterm text () Stack now 0 Entering state 23 Reading a token: --(end of buffer or a NUL) --accepting rule at line 221 (" ") --(end of buffer or a NUL) --EOF (start condition 0) Now at end of input. Stack now 0 23 Cleanup: popping nterm text () Matched address 192.168.1.11:4 attacking service 330, dangerousness 10. Purging stale attackers. If you require any more info please let me know. Regards, J. |
From: <op...@ni...> - 2010-08-10 21:22:41
|
On Tue, Aug 10, 2010 at 9:42 PM, Mij <mi...@ss...> wrote: > Hi J, > > When you doubt that SSHGuard is detecting a message, have > a quick glance at > http://www.sshguard.net/docs/reference/attack-signatures/ > and see if that's supposed to be supported. > > In this specific case, though, notice that vsftpd support has been > added in 1.5beta3, and was not present in 1.4. > (See http://freshmeat.net/projects/sshguard/releases ). > > cheers Oh, so _that's_ why it wouldn't work. Thanks for your time. J. |
From: Mij <mi...@ss...> - 2010-08-10 20:08:57
|
Hi J, When you doubt that SSHGuard is detecting a message, have a quick glance at http://www.sshguard.net/docs/reference/attack-signatures/ and see if that's supposed to be supported. In this specific case, though, notice that vsftpd support has been added in 1.5beta3, and was not present in 1.4. (See http://freshmeat.net/projects/sshguard/releases ). cheers On Aug 10, 2010, at 21:33 , op...@ni... wrote: > Hello, > > I have been pulling my hair for the past hour trying to get sshguard > (1.4.4) to play nice with vsftpd (2.2.2). Frustrated, I tried to parse > my log message in the debug mode, here is the result: > > Started successfully [(a,p,s)=(4, 420, 1200)], now ready to scan. > [testuser] FAIL LOGIN: Client "192.168.1.12" > Starting parse > Entering state 0 > Reading a token: --accepting rule at line 183 ("[") > Next token is token '[' () > Cleanup: discarding lookahead token '[' () > Stack now 0 > >> From that I gather that sshguard did not recognize the message? Is it > a bug, or am I doing something wrong? > > Some help would be appreciated. > > Regards, > J. |
From: <op...@ni...> - 2010-08-10 19:33:29
|
Hello, I have been pulling my hair for the past hour trying to get sshguard (1.4.4) to play nice with vsftpd (2.2.2). Frustrated, I tried to parse my log message in the debug mode, here is the result: Started successfully [(a,p,s)=(4, 420, 1200)], now ready to scan. [testuser] FAIL LOGIN: Client "192.168.1.12" Starting parse Entering state 0 Reading a token: --accepting rule at line 183 ("[") Next token is token '[' () Cleanup: discarding lookahead token '[' () Stack now 0 >From that I gather that sshguard did not recognize the message? Is it a bug, or am I doing something wrong? Some help would be appreciated. Regards, J. |
From: Mij <mi...@ss...> - 2010-07-22 17:10:00
|
Early next week I am going to release 1.5 stable, reflecting the current HEAD of svn (1.4rc4). If some adopters observed bugs yet unreported or unfixed, please report them before the week end. Thanks |
From: Mij <mi...@ss...> - 2010-07-21 06:45:54
|
thanks! On Jul 20, 2010, at 17:32 , Colin Keith wrote: > I set this up on my setup: > > [/etc/sysconfig/sshguard] > SSHGUARD_WHITELIST="-w /etc/sysconfig/sshguard_friends" > # SSHGUARD_BLACKLIST="-b 40:/var/log/sshguard_blacklist" > SSHGUARD_BLACKLIST="" > SSHGUARD_LOGFILES="/var/log/ftp.log /var/log/secure /var/log/pop3.log" > SSHGUARD_PIDFILES="" > # SSHGUARD_PIDFILES="-f 100:/var/run/sshd.pid -f 310:/var/run/proftpd.pid" > > if [ "X$SSHGUARD_LOGFILES" != "X" ]; then > for log in $SSHGUARD_LOGFILES; > do > SSHGUARD_OPTS="-l $log $SSHGUARD_OPTS"; > done > fi > > SSHGUARD_OPTS="$SSHGUARD_OPTS $SSHGUARD_WHITELIST $SSHGUARD_BLACKLIST > $SSHGUARD_PIDFILES" > > > Then /etc/init.d/sshguard is a copy of some other init file that was > tweaked. Feel free to borrow/copy/ignore as any one wants. It works > for me it isn't guaranteed to work for anyone else. Of course it needs > S* and K* symlinks in /etc/rc3.d/ > > thor# ls -l /etc/rc3.d/*sshguard* > lrwxrwxrwx 1 root root 20 Jun 3 10:27 /etc/rc3.d/K85sshguard -> > /etc/init.d/sshguard > lrwxrwxrwx 1 root root 18 Jun 19 2009 /etc/rc3.d/S11sshguard -> > ../init.d/sshguard > > > -------------------- [/etc/init.d/sshguard] ------------------ > > #! /bin/bash > # processname: sshguard > # config: /etc/ssh/sshguard_config > # pidfile: /var/run/sshguard.pid > > # Source function library. > . /etc/init.d/functions > . /etc/sysconfig/sshguard > > # See how we were called. > > prog="sshguard" > > start() { > if [ ! -S $SOCK ]; then > rm -f $SOCK > mkfifo -m 0700 $SOCK > fi > > echo -n $"Starting $prog: " > /usr/local/sbin/sshguard $SSHGUARD_OPTS & > RETVAL=$? > echo > [ $RETVAL -eq 0 ] && touch /var/lock/subsys/sshguard; > return $RETVAL > } > > stop() { > echo -n $"Stopping $prog: " > killproc sshguard > RETVAL=$? > echo > [ $RETVAL -eq 0 ] && rm -f /var/lock/subsys/sshguard; > return $RETVAL > } > > restart() { > stop > start > } > > case "$1" in > start) > start > ;; > stop) > stop > ;; > restart) > restart > ;; > reload) > reload > ;; > status) > rhstatus > ;; > condrestart) > [ -f /var/lock/subsys/sshguard ] && restart || : > ;; > *) > echo $"Usage: $0 {start|stop|status|reload|restart|condrestart}" > exit 1 > esac > > -------------------- > > > Colin. > > On Sun, Jul 4, 2010 at 7:07 PM, Mij <mi...@ss...> wrote: >> I've been considering this. There are some thought holding it back, like >> - one parser is already incumbent in the code, combining two parsers is some pain >> - parsing has a terrible code/functionality ratio, it's a pity to deploy it for >> something as ancillary as configuration files >> - having configuration files would finally mark sshguard a "serious" daemon :) >> rather than a tool >> >> I've found the "envdir" configuration style (that's "configuration directory"es rather than >> files) tremendously lean and convenient from both the user and the programmer; how >> would that fit in your daemon script frame? >> >> >> On Jun 1, 2010, at 06:57 , Julián Moreno Patiño wrote: >> >>> Hi Mij, >>> >>> It would be nice to implement a configuration file sshguard.conf to enable options such as log sucker, whitelisting, blacklisting, port service and use them in different services (sshd, sendmail, exim, dovecot, etc), it's more easier and I can create more generic daemon script to Debian Distribution. >>> >>> Thank you very much, see you. >>> >>> Kind Regards, >>> >>> -- >>> Julián Moreno Patiño >>> Registered GNU Linux User ID 488513 >>> PGP KEY ID 6168BF60 >>> ------------------------------------------------------------------------------ >>> >>> _______________________________________________ >>> Sshguard-users mailing list >>> Ssh...@li... >>> https://lists.sourceforge.net/lists/listinfo/sshguard-users >> >> >> ------------------------------------------------------------------------------ >> This SF.net email is sponsored by Sprint >> What will you do first with EVO, the first 4G phone? >> Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first >> _______________________________________________ >> Sshguard-users mailing list >> Ssh...@li... >> https://lists.sourceforge.net/lists/listinfo/sshguard-users >> > > > > -- > Colin Keith > Systems Administrator > Hagen Software Inc. > > ------------------------------------------------------------------------------ > This SF.net email is sponsored by Sprint > What will you do first with EVO, the first 4G phone? > Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first > _______________________________________________ > Sshguard-users mailing list > Ssh...@li... > https://lists.sourceforge.net/lists/listinfo/sshguard-users |
From: Mij <mi...@ss...> - 2010-07-21 06:44:21
|
On Jul 19, 2010, at 18:02 , H ghost wrote: > Hi: > > I reinstall it again, and now can start already, > (already show in PS result) > But, If I want to uninstall it, How should I do? run find /usr -name sshguard -or -name sshguard.8 then "rm -f " each of the two files printed > and how you set it can run auto after boot? you can try with this, contributed by Robert: http://sourceforge.net/mailarchive/forum.php?thread_name=r2r7093dffb1005011547t6772f5e5z6ca162952634df02%40mail.gmail.com&forum_name=sshguard-users > > Thank you > > newbit 10'07/20 > > > I install sshguard on CentOS 5.5 i386 edition at a OpenVZ VPS. > I already setup sshguard.fifo & syslog.conf > When I type "/usr/local/sbin/sshguard &" I saw: > > /usr/local/sbin/sshguard: line 1: Jul: command not found > /usr/local/sbin/sshguard: line 2: syntax error near unexpected token `(' > /usr/local/sbin/sshguard: line 2: `Jul 19 06:12:54 range sshd[19693]: > pam_unix(sshd:session): session opened for user me.. > > If anything I did wrong? > 除了電子信箱,還有許多有用的功能。快來使用免費的 Windows Live Hotmail。 馬上註冊 ------------------------------------------------------------------------------ > This SF.net email is sponsored by Sprint > What will you do first with EVO, the first 4G phone? > Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first_______________________________________________ > Sshguard-users mailing list > Ssh...@li... > https://lists.sourceforge.net/lists/listinfo/sshguard-users |
From: Colin K. <col...@gm...> - 2010-07-20 15:37:37
|
Thanks. From looking at the patch it seems like it will probably be good so I added it and re-compiled it. So far it has been 2 days and it hasn't fallen over, but the situation in which that occurs is random. I tested it using: echo -n 'Test2' >> /var/log/secure which should have triggered the previous bug since there is new data but no new line. Thanks again. Colin. On Fri, Jul 16, 2010 at 5:44 PM, Mij <mi...@ss...> wrote: > Very curious, I noticed the same possibility some weeks ago, and thought "that condition for > strings of logs length must be so rare that it's more likely for me to introduce a bug in the code > for handling it" -- and just threw the assert() in there. Noot! :) > > Now committed a version for handling it as r204, thanks! > > > On Jul 8, 2010, at 14:46 , Colin Keith wrote: > >> Hi, >> >> I keep having intermittent problems with the assert in this code from >> sshguard-1.5rc3/src/sshguard_logsuck.c >> >> 351 /* read until error, newline reached, or buffer exhausted */ >> 352 i = 0; >> 353 do { >> 354 ret = read(fd, & buf[i++], 1); >> 355 } while (ret == 1 && buf[i-1] != '\n' && i < buflen-2); >> 356 assert(ret != 0); >> 357 buf[i] = '\0'; >> >> I keep getting the error message; >> >> Assertion `ret != 0' failed. >> >> I added some code to print the various values that are used: >> >> if(ret == 0) { >> sshguard_log(LOG_NOTICE, "ret = %d, i = %d, buflen = %d, buf[i-1] = >> '%c', buf = %s\n", ret, i, (int)buflen, buf[i-1], buf); >> } >> >> and from that received this output; >> >> ret = 0, i = 62, buflen = 999, buf[i-1] = 'n', buf = ul 07 16:45:26 >> thor.hagenhosting.com proftpd[18688] thor.hagenhosting.com >> (61.55.146.28[61.55.146.28]): FTP session closed. >> >> >> Why is ret == 0 bad? Doesn't that just me EOF? >> >> I'm reading from /var/log/ftp.log which is written to by syslog (it is >> just easier that way) so isn't this just saying that syslog hadn't >> finished writing the entire line to the log file while I was reading >> it and thus hit the EOF before the EOL? >> >> This is really annoying because when it happens sshguard falls over >> and so leaves the box open to annoyances again. >> >> Thanks, >> Colin. >> >> ------------------------------------------------------------------------------ >> This SF.net email is sponsored by Sprint >> What will you do first with EVO, the first 4G phone? >> Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first >> _______________________________________________ >> Sshguard-users mailing list >> Ssh...@li... >> https://lists.sourceforge.net/lists/listinfo/sshguard-users > > > ------------------------------------------------------------------------------ > This SF.net email is sponsored by Sprint > What will you do first with EVO, the first 4G phone? > Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first > _______________________________________________ > Sshguard-users mailing list > Ssh...@li... > https://lists.sourceforge.net/lists/listinfo/sshguard-users > -- Colin Keith Systems Administrator Hagen Software Inc. |
From: Colin K. <col...@gm...> - 2010-07-20 15:32:58
|
I set this up on my setup: [/etc/sysconfig/sshguard] SSHGUARD_WHITELIST="-w /etc/sysconfig/sshguard_friends" # SSHGUARD_BLACKLIST="-b 40:/var/log/sshguard_blacklist" SSHGUARD_BLACKLIST="" SSHGUARD_LOGFILES="/var/log/ftp.log /var/log/secure /var/log/pop3.log" SSHGUARD_PIDFILES="" # SSHGUARD_PIDFILES="-f 100:/var/run/sshd.pid -f 310:/var/run/proftpd.pid" if [ "X$SSHGUARD_LOGFILES" != "X" ]; then for log in $SSHGUARD_LOGFILES; do SSHGUARD_OPTS="-l $log $SSHGUARD_OPTS"; done fi SSHGUARD_OPTS="$SSHGUARD_OPTS $SSHGUARD_WHITELIST $SSHGUARD_BLACKLIST $SSHGUARD_PIDFILES" Then /etc/init.d/sshguard is a copy of some other init file that was tweaked. Feel free to borrow/copy/ignore as any one wants. It works for me it isn't guaranteed to work for anyone else. Of course it needs S* and K* symlinks in /etc/rc3.d/ thor# ls -l /etc/rc3.d/*sshguard* lrwxrwxrwx 1 root root 20 Jun 3 10:27 /etc/rc3.d/K85sshguard -> /etc/init.d/sshguard lrwxrwxrwx 1 root root 18 Jun 19 2009 /etc/rc3.d/S11sshguard -> ../init.d/sshguard -------------------- [/etc/init.d/sshguard] ------------------ #! /bin/bash # processname: sshguard # config: /etc/ssh/sshguard_config # pidfile: /var/run/sshguard.pid # Source function library. . /etc/init.d/functions . /etc/sysconfig/sshguard # See how we were called. prog="sshguard" start() { if [ ! -S $SOCK ]; then rm -f $SOCK mkfifo -m 0700 $SOCK fi echo -n $"Starting $prog: " /usr/local/sbin/sshguard $SSHGUARD_OPTS & RETVAL=$? echo [ $RETVAL -eq 0 ] && touch /var/lock/subsys/sshguard; return $RETVAL } stop() { echo -n $"Stopping $prog: " killproc sshguard RETVAL=$? echo [ $RETVAL -eq 0 ] && rm -f /var/lock/subsys/sshguard; return $RETVAL } restart() { stop start } case "$1" in start) start ;; stop) stop ;; restart) restart ;; reload) reload ;; status) rhstatus ;; condrestart) [ -f /var/lock/subsys/sshguard ] && restart || : ;; *) echo $"Usage: $0 {start|stop|status|reload|restart|condrestart}" exit 1 esac -------------------- Colin. On Sun, Jul 4, 2010 at 7:07 PM, Mij <mi...@ss...> wrote: > I've been considering this. There are some thought holding it back, like > - one parser is already incumbent in the code, combining two parsers is some pain > - parsing has a terrible code/functionality ratio, it's a pity to deploy it for > something as ancillary as configuration files > - having configuration files would finally mark sshguard a "serious" daemon :) > rather than a tool > > I've found the "envdir" configuration style (that's "configuration directory"es rather than > files) tremendously lean and convenient from both the user and the programmer; how > would that fit in your daemon script frame? > > > On Jun 1, 2010, at 06:57 , Julián Moreno Patiño wrote: > >> Hi Mij, >> >> It would be nice to implement a configuration file sshguard.conf to enable options such as log sucker, whitelisting, blacklisting, port service and use them in different services (sshd, sendmail, exim, dovecot, etc), it's more easier and I can create more generic daemon script to Debian Distribution. >> >> Thank you very much, see you. >> >> Kind Regards, >> >> -- >> Julián Moreno Patiño >> Registered GNU Linux User ID 488513 >> PGP KEY ID 6168BF60 >> ------------------------------------------------------------------------------ >> >> _______________________________________________ >> Sshguard-users mailing list >> Ssh...@li... >> https://lists.sourceforge.net/lists/listinfo/sshguard-users > > > ------------------------------------------------------------------------------ > This SF.net email is sponsored by Sprint > What will you do first with EVO, the first 4G phone? > Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first > _______________________________________________ > Sshguard-users mailing list > Ssh...@li... > https://lists.sourceforge.net/lists/listinfo/sshguard-users > -- Colin Keith Systems Administrator Hagen Software Inc. |
From: H g. <fre...@ho...> - 2010-07-19 16:02:49
|
Hi: I reinstall it again, and now can start already, (already show in PS result) But, If I want to uninstall it, How should I do? and how you set it can run auto after boot? Thank you newbit 10'07/20 I install sshguard on CentOS 5.5 i386 edition at a OpenVZ VPS. I already setup sshguard.fifo & syslog.conf When I type "/usr/local/sbin/sshguard &" I saw: /usr/local/sbin/sshguard: line 1: Jul: command not found /usr/local/sbin/sshguard: line 2: syntax error near unexpected token `(' /usr/local/sbin/sshguard: line 2: `Jul 19 06:12:54 range sshd[19693]: pam_unix(sshd:session): session opened for user me.. If anything I did wrong? _________________________________________________________________ 除了電子信箱,還有許多有用的功能。快來使用免費的 Windows Live Hotmail。 https://signup.live.com/signup.aspx?id=60969 |
From: H g. <fre...@ho...> - 2010-07-19 14:08:51
|
Hi: I install sshguard on CentOS 5.5 i386 edition at a OpenVZ VPS. I already setup sshguard.fifo & syslog.conf When I type "/usr/local/sbin/sshguard &" I saw: /usr/local/sbin/sshguard: line 1: Jul: command not found /usr/local/sbin/sshguard: line 2: syntax error near unexpected token `(' /usr/local/sbin/sshguard: line 2: `Jul 19 06:12:54 range sshd[19693]: pam_unix(sshd:session): session opened for user me.. If anything I did wrong? newbit 10'07/19 _________________________________________________________________ Hotmail 是功能強大又值得信賴的免費信箱 https://signup.live.com/signup.aspx?id=60969 |
From: Mij <mi...@ss...> - 2010-07-17 00:04:25
|
For the archives, this is the plan for addressing this problem: The Log Sucker is too important to neglect the problem. At the same time, minimizing latencies on all systems so as to recover this problem requires to implement code hooking to the least portable, most OS-specific API (poll() / kqueue() / epoll() etc) for each different system. No way we're going through this in the middle of an RC line :) Thus, the deal is release 1.5 will provide Log Sucking with the current machinery (optimized for BSD, regular for all others), but will discourage via documentation the use of Log Validation along with it. That is, in sshguard-1.5 you either use Log Validation xor you use Log Sucking. In other words, Validation won't Suck. Notice that "false positives" in validation with Log Sucking may occur only in the conjunction of these cases 1) the service handles connections by fork()ing and delegating them to children (OpenSSH and some Apache do, dropbear and nginx do not) 2) the children dies immediately after logging the sensitive signature 3) the OS does not notify SSHGuard of the new log data after writing it, but handles the child exit first Yet, the choice is to discourage the joint use of the two techniques until the case is addressed. On Jul 5, 2010, at 12:30 , Mij wrote: > Hi Robert, > > I cannot reproduce this problem on any of my machines, but here is the most likely > explanation. Log Validation works as follows: > 1. recognize an attack signature > 2. extract generating PID from it (logPID) > 3. compare logPID with the genuine PID genPID (from the pidfile). Match => ACCEPT > > The algorithm ideally stops here, but some daemons (like sshd) delegate connection > processing to children. So the algorithm goes on: > 4. ask the system for the parent-child process table > 5. check if logPID is child of genPID. Match => ACCEPT > 6. REJECT > > For daemons delegating client handling to children, what's likely happening on your > machine is that sshguard receives the message when the child has already > died after sending its log message. Sshguard has then no way to tell. > > With log sucking this is more likely to happen under non-BSD systems, where the > logic is implemented with proactive non-blocking polls (on BSD it's reactive on kqueue()). > I will consider collapsing this in a single libevent logic in the near future. > > michele > > > On May 14, 2010, at 11:19 , Robert S wrote: > >> Hi. >> >> I have tried this with log sucking and direct feed from a FIFO with >> similar results. This is certainly a lot better, but there are still >> some false positives: >> >> May 14 01:31:31 hostname sshd[21193]: User root from 64.179.173.93 not >> allowed because none of user's groups are listed in AllowGroups >> May 14 01:31:32 hostname sshguard[21993]: Ignore attack as pid '21193' >> has been forged for service 100. >> May 14 01:31:35 hostname sshd[21199]: User root from 64.179.173.93 not >> allowed because none of user's groups are listed in AllowGroups >> May 14 01:31:39 hostname sshd[21202]: User root from 64.179.173.93 not >> allowed because none of user's groups are listed in AllowGroups >> May 14 01:31:43 hostname sshd[21208]: User root from 64.179.173.93 not >> allowed because none of user's groups are listed in AllowGroups >> May 14 01:31:47 hostname sshd[21219]: User root from 64.179.173.93 not >> allowed because none of user's groups are listed in AllowGroups >> May 14 01:31:47 hostname sshguard[21993]: Blocking 64.179.173.93:4 for >>> 630secs: 40 danger in 4 attacks over 12 seconds (all: 40d in 1 abuses >> over 12s). >> May 14 02:27:55 hostname sshd[21341]: User root from 59.188.11.38 not >> allowed because none of user's groups are listed in AllowGroups >> May 14 02:27:56 hostname sshguard[21993]: Ignore attack as pid '21341' >> has been forged for service 100. >> May 14 02:27:57 hostname sshd[21343]: User root from 59.188.11.38 not >> allowed because none of user's groups are listed in AllowGroups >> May 14 02:27:58 hostname sshd[21347]: User root from 59.188.11.38 not >> allowed because none of user's groups are listed in AllowGroups >> May 14 02:28:00 hostname sshd[21350]: User root from 59.188.11.38 not >> allowed because none of user's groups are listed in AllowGroups >> May 14 02:28:02 hostname sshd[21353]: User root from 59.188.11.38 not >> allowed because none of user's groups are listed in AllowGroups >> May 14 02:28:02 hostname sshguard[21993]: Blocking 59.188.11.38:4 for >>> 630secs: 40 danger in 4 attacks over 5 seconds (all: 40d in 1 abuses >> over 5s). >> May 14 02:33:33 hostname sshd[21376]: User root from 122.166.36.130 >> not allowed because none of user's groups are listed in AllowGroups >> May 14 02:33:33 hostname sshguard[21993]: Ignore attack as pid '21376' >> has been forged for service 100. >> May 14 02:33:36 hostname sshd[21379]: User root from 122.166.36.130 >> not allowed because none of user's groups are listed in AllowGroups >> May 14 02:33:38 hostname sshd[21382]: User root from 122.166.36.130 >> not allowed because none of user's groups are listed in AllowGroups >> May 14 02:33:41 hostname sshd[21385]: User root from 122.166.36.130 >> not allowed because none of user's groups are listed in AllowGroups >> May 14 02:33:45 hostname sshd[21388]: User root from 122.166.36.130 >> not allowed because none of user's groups are listed in AllowGroups >> May 14 02:33:45 hostname sshguard[21993]: Blocking 122.166.36.130:4 >> for >630secs: 40 danger in 4 attacks over 9 seconds (all: 40d in 1 >> abuses over 9s). >> May 14 04:10:27 hostname sshd[21735]: User root from 122.0.19.18 not >> allowed because none of user's groups are listed in AllowGroups >> May 14 04:10:31 hostname sshd[21738]: User root from 122.0.19.18 not >> allowed because none of user's groups are listed in AllowGroups >> May 14 04:10:35 hostname sshd[21741]: User root from 122.0.19.18 not >> allowed because none of user's groups are listed in AllowGroups >> May 14 04:10:39 hostname sshd[21744]: User root from 122.0.19.18 not >> allowed because none of user's groups are listed in AllowGroups >> May 14 04:10:39 hostname sshguard[21993]: Blocking 122.0.19.18:4 for >>> 630secs: 40 danger in 4 attacks over 11 seconds (all: 40d in 1 abuses >> over 11s). >> >> Robert. >> >> ------------------------------------------------------------------------------ >> >> _______________________________________________ >> Sshguard-users mailing list >> Ssh...@li... >> https://lists.sourceforge.net/lists/listinfo/sshguard-users > > > ------------------------------------------------------------------------------ > This SF.net email is sponsored by Sprint > What will you do first with EVO, the first 4G phone? > Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first > _______________________________________________ > Sshguard-users mailing list > Ssh...@li... > https://lists.sourceforge.net/lists/listinfo/sshguard-users |
From: Mij <mi...@ss...> - 2010-07-16 21:44:53
|
Very curious, I noticed the same possibility some weeks ago, and thought "that condition for strings of logs length must be so rare that it's more likely for me to introduce a bug in the code for handling it" -- and just threw the assert() in there. Noot! :) Now committed a version for handling it as r204, thanks! On Jul 8, 2010, at 14:46 , Colin Keith wrote: > Hi, > > I keep having intermittent problems with the assert in this code from > sshguard-1.5rc3/src/sshguard_logsuck.c > > 351 /* read until error, newline reached, or buffer exhausted */ > 352 i = 0; > 353 do { > 354 ret = read(fd, & buf[i++], 1); > 355 } while (ret == 1 && buf[i-1] != '\n' && i < buflen-2); > 356 assert(ret != 0); > 357 buf[i] = '\0'; > > I keep getting the error message; > > Assertion `ret != 0' failed. > > I added some code to print the various values that are used: > > if(ret == 0) { > sshguard_log(LOG_NOTICE, "ret = %d, i = %d, buflen = %d, buf[i-1] = > '%c', buf = %s\n", ret, i, (int)buflen, buf[i-1], buf); > } > > and from that received this output; > > ret = 0, i = 62, buflen = 999, buf[i-1] = 'n', buf = ul 07 16:45:26 > thor.hagenhosting.com proftpd[18688] thor.hagenhosting.com > (61.55.146.28[61.55.146.28]): FTP session closed. > > > Why is ret == 0 bad? Doesn't that just me EOF? > > I'm reading from /var/log/ftp.log which is written to by syslog (it is > just easier that way) so isn't this just saying that syslog hadn't > finished writing the entire line to the log file while I was reading > it and thus hit the EOF before the EOL? > > This is really annoying because when it happens sshguard falls over > and so leaves the box open to annoyances again. > > Thanks, > Colin. > > ------------------------------------------------------------------------------ > This SF.net email is sponsored by Sprint > What will you do first with EVO, the first 4G phone? > Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first > _______________________________________________ > Sshguard-users mailing list > Ssh...@li... > https://lists.sourceforge.net/lists/listinfo/sshguard-users |
From: Adam C. <ada...@be...> - 2010-07-08 23:20:38
|
your "blind dive" looks to be spot on.... the default perms on the fifo were 600 changed to 666 and so far, no problem -- Adam Cohen / IT Manager Energy Biosciences Institute / UC Berkeley 109 Calvin Lab / 510-642-7709 http://www.energybiosciencesinstitute.org On Jul 5, 2010, at 3:37 AM, Mij wrote: > Hmm, this is weird :) > > Blind dive: does anything happen with the permissions of the FIFO? > If I recall it right, ubuntu runs syslogd as an unprivileged user. > > If you sort it out, please report your answer to the list for the archives. > > If you don't, consider using Log Sucking. > > > On May 17, 2010, at 20:42 , Adam Cohen wrote: > >> greetings, >> I'm adding sshguard (r1.5rc2) to a system running Ubuntu (8.1 / intrepid) >> >> Configure for iptables, looks good >> Built from sources, looks good >> Configure /etc/syslog.conf as below: >> >> # /etc/syslog.conf Configuration file for syslogd. >> auth.info;authpriv.info |/var/log/sshguard.fifo >> auth,authpriv.* /var/log/auth.log >> *.*;auth,authpriv.none -/var/log/syslog >> >> Restart syslog >> /etc/init.d/sysklogd restart >> >> Start sshguard >> initctl start sshguard >> >> sshguard works fine as FIFO receives messages >> >> But after a while...FIFO stops receiving messages and so sshguard gets no input to scan. This seems like an Ubuntu issue but could there be something wrong with my syslog.conf? >> >> thanks >> Adam >> >> -- >> Adam Cohen / IT Manager >> Energy Biosciences Institute / UC Berkeley >> 109 Calvin Lab / 510-642-7709 >> http://www.energybiosciencesinstitute.org >> >> ------------------------------------------------------------------------------ >> >> _______________________________________________ >> Sshguard-users mailing list >> Ssh...@li... >> https://lists.sourceforge.net/lists/listinfo/sshguard-users > > > ------------------------------------------------------------------------------ > This SF.net email is sponsored by Sprint > What will you do first with EVO, the first 4G phone? > Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first > _______________________________________________ > Sshguard-users mailing list > Ssh...@li... > https://lists.sourceforge.net/lists/listinfo/sshguard-users |
From: Colin K. <col...@gm...> - 2010-07-08 12:46:47
|
Hi, I keep having intermittent problems with the assert in this code from sshguard-1.5rc3/src/sshguard_logsuck.c 351 /* read until error, newline reached, or buffer exhausted */ 352 i = 0; 353 do { 354 ret = read(fd, & buf[i++], 1); 355 } while (ret == 1 && buf[i-1] != '\n' && i < buflen-2); 356 assert(ret != 0); 357 buf[i] = '\0'; I keep getting the error message; Assertion `ret != 0' failed. I added some code to print the various values that are used: if(ret == 0) { sshguard_log(LOG_NOTICE, "ret = %d, i = %d, buflen = %d, buf[i-1] = '%c', buf = %s\n", ret, i, (int)buflen, buf[i-1], buf); } and from that received this output; ret = 0, i = 62, buflen = 999, buf[i-1] = 'n', buf = ul 07 16:45:26 thor.hagenhosting.com proftpd[18688] thor.hagenhosting.com (61.55.146.28[61.55.146.28]): FTP session closed. Why is ret == 0 bad? Doesn't that just me EOF? I'm reading from /var/log/ftp.log which is written to by syslog (it is just easier that way) so isn't this just saying that syslog hadn't finished writing the entire line to the log file while I was reading it and thus hit the EOF before the EOL? This is really annoying because when it happens sshguard falls over and so leaves the box open to annoyances again. Thanks, Colin. |
From: Mij <mi...@ss...> - 2010-07-05 16:39:18
|
This is a nice post™. In general, of course, the fact that people use sshguard for something beyond its original purpose is nothing but good news. For your points: On Jul 5, 2010, at 13:45 , Johan Bergström wrote: > Hello, > > Since switching to 1.5, sshguard has slowly evolved in my server park from a "ssh blocker" to something completely different. The way I see it, sshguard's strengths are scanning multiple logfiles and acting upon a specific behavior. > > Instead of throwing ssh in getting pf out, I would for instance like to shove it failed wordpress attempts and feed them to a nginx config or perhaps a pf tarpit. > > With this in mind, a couple of things makes "living" with sshguard a tad more complex: > > - writing recognition patterns is a tedious and compile-time-only process this is the price tag for having a parser this powerful. We can do *everything* with it, from recognizing many log formats at once, to contextual parsing, to handling tents of attack signatures in a seamlessly maintainable way. So when confronted with "but people won't be able to hack it", we decided to stick with it and provide http://www.sshguard.net/support/attacks/submit/ as the interface for users. This is win-win: users are save the hassle of coding at all, and we guarantee a consistent, secure implementation of the signatures, and redistribution. Now if you say you submitted two months ago and your pattern is still not in, I get you :) Adding a pattern costs about 10 minutes of time start to commit, but I always go after bugs before new features. The basic problem here is that in the last year sshguard's community has clearly outgrown the team's throughput. We are set with the website (thanks to Federico), but we need more developers (since TJ was sucked away in China), and we need someone to look after the mailing list, or some more interaction between users, to allow us back to the code. > - only allows for calls to pf/iptables/whatnot "whatnot" is actually easy to translate to "what you want": one year and odds ago we introduced the "command" backend to this end, which allows to run any command for blocking/releasing/flushing/etc. See http://www.sshguard.net/feedback/firewall/submit/ and as an example instance http://sshguard.svn.sourceforge.net/viewvc/sshguard/trunk/src/fwalls/command_pf.h?revision=181&view=markup This is compile time, but easily deferrable to an external user script. > - not having a config file (recently raised on list) > > Some issues are cured with simple solutions such as letting nginx write custom logs which match a current filter and to wrap calls to pf in shell scripts - but the question remains; In what direction is sshguard heading? > > See this more as an open question rather than a feature request since it's more about roadmap than anything else. This is how we go about it: * as you observe, sshguard is a general detection/reaction platform. We will add support for detecting as many attack signatures as users submit, as long as they are fairly standard. * we always try to be as general as possible (the log formats, the attack signatures, the firewall backends are examples), as long as it makes sense: a substantial set of users will benefit, and existing users will not be adversely affected. michele > > Cheers, > Johan > > > ------------------------------------------------------------------------------ > This SF.net email is sponsored by Sprint > What will you do first with EVO, the first 4G phone? > Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first > _______________________________________________ > Sshguard-users mailing list > Ssh...@li... > https://lists.sourceforge.net/lists/listinfo/sshguard-users |
From: Mij <mi...@ss...> - 2010-07-05 16:34:07
|
Hi Daniel Skimming through the output you included: - recognition seems fine, but it appears that after your log message there is some stray blank, so sshguard doesn't want to match that as "regular". Your log message seems to be: "Jun 30 18:24:57 naruto sshd[2229]: error: PAM: authentication error for \ daniel from ec2-12-12-12-12.compute-1.amazonaws.com " (notice the trailing " ") Is that from your actual sshd daemon or you were injecting them manually? - you seem not to be running a recent version of sshguard, as the rule for multiple lines doesn't show up. Please try with a recent version. On Jul 1, 2010, at 03:36 , Daniel wrote: > Hi, > > After using sshguard successfully for a long time with the current setup, I noticed upon reboot that it was not guarding anymore. I'm using the sshguard-ipfw version. It doesn't seem to do any detection of the login failures and so doesn't respond. > It was working as recently as two weeks ago and my version has not changed. Below is the log. I'm more used to seeing this: > > system.log.1:Jun 28 04:40:55 naruto sshguard[785]: Blocking 118.97.232.236:4 for >420secs: 4 failures over 2 seconds. > > Now I get: > > Successfully resolved 'ec2-12-12-12-12.compute-1.amazonaws.com' --> 4:'12.12.12.12'. > > > Any input of why it may not be working is appriciated. > > whitelist: add '127.0.0.1' as plain IPv4. > whitelist: add plain ip 127.0.0.1. > Started successfully [(a,p,s)=(4, 420, 1200)], now ready to scan. > Starting parse > Entering state 0 > Reading a token: --accepting rule at line 102 ("Jun 30 18:24:57 naruto sshd[2229]:") > Next token is token SYSLOG_BANNER_PID () > Shifting token SYSLOG_BANNER_PID () > Entering state 1 > Reading a token: --accepting rule at line 180 (" ") > --accepting rule at line 121 ("error: PAM: authentication error for daniel from ") > Next token is token SSH_LOGINERR_PAM () > Shifting token SSH_LOGINERR_PAM () > Entering state 7 > Reading a token: --accepting rule at line 169 (" > ec2-12-12-12-12.compute-1.amazonaws.com > ") > Next token is token HOSTADDR () > Shifting token HOSTADDR () > Entering state 40 > Reducing stack by rule 18 (line 118): > $1 = token HOSTADDR () > Successfully resolved ' > ec2-12-12-12-12.compute-1.amazonaws.com > ' --> 4:'12.12.12.12'. > -> $$ = nterm addr () > Stack now 0 1 7 > Entering state 44 > Reducing stack by rule 27 (line 187): > $1 = token SSH_LOGINERR_PAM () > $2 = nterm addr () > -> $$ = nterm ssh_authfail () > Stack now 0 1 > Entering state 25 > Reducing stack by rule 20 (line 172): > $1 = nterm ssh_authfail () > -> $$ = nterm sshmsg () > Stack now 0 1 > Entering state 23 > Reducing stack by rule 9 (line 99): > $1 = nterm sshmsg () > -> $$ = nterm logmsg () > Stack now 0 1 > Entering state 35 > Reducing stack by rule 5 (line 76): > $1 = token SYSLOG_BANNER_PID () > $2 = nterm logmsg () > -> $$ = nterm syslogent () > Stack now 0 > Entering state 19 > Reducing stack by rule 1 (line 60): > $1 = nterm syslogent () > -> $$ = nterm text () > Stack now 0 > Entering state 18 > Reading a token: --accepting rule at line 180 (" ") > --accepting rule at line 179 ("via") > Next token is token WORD () > Error: popping nterm text () > Stack now 0 > Cleanup: discarding lookahead token WORD () > Stack now 0 > Starting parse > Entering state 0 > Reading a token: --accepting rule at line 102 ("Jun 30 18:24:57 naruto sshd[2235]:") > Next token is token SYSLOG_BANNER_PID () > Shifting token SYSLOG_BANNER_PID () > Entering state 1 > Reading a token: --accepting rule at line 180 (" ") > --accepting rule at line 179 ("in") > Next token is token WORD () > Error: popping token SYSLOG_BANNER_PID () > Stack now 0 > Cleanup: discarding lookahead token WORD () > Stack now 0 > Got exit signal, flushing blocked addresses and exiting... > > > -- > "America was founded by men who understood that the threat of domestic tyranny is as great as any threat from abroad. If we want to be worthy of their legacy, we must resist the rush toward ever-increasing state control of our society. Otherwise, our own government will become a greater threat to our freedoms than any foreign terrorist." > - Ron Paul, Texas Straight Talk, May 31, 2004 > ------------------------------------------------------------------------------ > This SF.net email is sponsored by Sprint > What will you do first with EVO, the first 4G phone? > Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first_______________________________________________ > Sshguard-users mailing list > Ssh...@li... > https://lists.sourceforge.net/lists/listinfo/sshguard-users |
From: Johan B. <bu...@be...> - 2010-07-05 12:05:19
|
Hello, Since switching to 1.5, sshguard has slowly evolved in my server park from a "ssh blocker" to something completely different. The way I see it, sshguard's strengths are scanning multiple logfiles and acting upon a specific behavior. Instead of throwing ssh in getting pf out, I would for instance like to shove it failed wordpress attempts and feed them to a nginx config or perhaps a pf tarpit. With this in mind, a couple of things makes "living" with sshguard a tad more complex: - writing recognition patterns is a tedious and compile-time-only process - only allows for calls to pf/iptables/whatnot - not having a config file (recently raised on list) Some issues are cured with simple solutions such as letting nginx write custom logs which match a current filter and to wrap calls to pf in shell scripts - but the question remains; In what direction is sshguard heading? See this more as an open question rather than a feature request since it's more about roadmap than anything else. Cheers, Johan |
From: Mij <mi...@ss...> - 2010-07-05 11:09:41
|
Nice to hear this sort of test cases :) Committed (r202), thanks! On May 21, 2010, at 10:16 , Johan Bergström wrote: > Hey, > > While trying to figure out why sshguard never blocked any users I found an issue that perhaps some other users has run into - sshguard seems to disregard log lines with one-letter hostnames (verified in sshguard 1.4, 1.5rc3 and r199). I'm at a Gentoo box if that should matter, with syslog-ng 3.0.4 > > I use a fictive hostname in style with a.com, and since syslog-ng defaults to options { use_fqdn(no); } the actual log stamp will be something like: > May 21 09:06:35 a sshguard[20427]: Run command "iptables -L": exited 0. > > Here's a debug session with the hostname "a": > > May 21 09:23:37 a sshd[24341]: Invalid user asd from 123.123.123.123 > Checking to refresh sources... > Refreshing sources showed 0 changes. > Checking to refresh sources... > Refreshing sources showed 0 changes. > Read line from '-'. > Starting parse > Entering state 0 > Reading a token: --accepting rule at line 206 ("May 21 09:23:37") > Next token is token TIMESTAMP_SYSLOG () > Cleanup: discarding lookahead token TIMESTAMP_SYSLOG () > Stack now 0 > > > > Here's a hostname with two characters: > > May 21 09:23:37 ab sshd[24341]: Invalid user asd from 123.123.123.123 > Checking to refresh sources... > Refreshing sources showed 0 changes. > Checking to refresh sources... > Refreshing sources showed 0 changes. > Read line from '-'. > Starting parse > Entering state 0 > Reading a token: --accepting rule at line 113 ("May 21 09:23:37 ab sshd[24341]:") > Next token is token SYSLOG_BANNER_PID () > Shifting token SYSLOG_BANNER_PID () > Entering state 1 > Reading a token: --accepting rule at line 214 (" ") > --accepting rule at line 132 ("Invalid user asd from ") > Next token is token SSH_INVALUSERPREF () > Shifting token SSH_INVALUSERPREF () > Entering state 6 > Reading a token: --accepting rule at line 194 ("123.123.123.123") > Next token is token IPv4 () > Shifting token IPv4 () > Entering state 50 > Reducing stack by rule 23 (line 203): > $1 = token IPv4 () > -> $$ = nterm addr () > Stack now 0 1 6 > Entering state 53 > Reducing stack by rule 31 (line 272): > $1 = token SSH_INVALUSERPREF () > $2 = nterm addr () > -> $$ = nterm ssh_illegaluser () > Stack now 0 1 > Entering state 31 > Reducing stack by rule 26 (line 262): > $1 = nterm ssh_illegaluser () > -> $$ = nterm sshmsg () > Stack now 0 1 > Entering state 30 > Reducing stack by rule 11 (line 169): > $1 = nterm sshmsg () > -> $$ = nterm msg_single () > Stack now 0 1 > Entering state 28 > Reducing stack by rule 9 (line 163): > $1 = nterm msg_single () > -> $$ = nterm logmsg () > Stack now 0 1 > Entering state 46 > Reducing stack by rule 5 (line 138): > $1 = token SYSLOG_BANNER_PID () > $2 = nterm logmsg () > -> $$ = nterm syslogent () > Stack now 0 > Entering state 24 > Reducing stack by rule 1 (line 122): > $1 = nterm syslogent () > -> $$ = nterm text () > Stack now 0 > Entering state 23 > Reading a token: --(end of buffer or a NUL) > --accepting rule at line 214 (" > ") > --(end of buffer or a NUL) > --EOF (start condition 0) > Now at end of input. > Shifting token $end () > Entering state 70 > Stack now 0 23 70 > Cleanup: popping token $end () > Cleanup: popping nterm text () > Matched address 123.123.123.123:4 attacking service 100, dangerousness 10. > Purging stale attackers. > > > Not sure if this really is a bug or intentional; but since you can set your hostname to one letter I guess sshguard at least should know about it. > > Cheers, > Johan > ------------------------------------------------------------------------------ > > _______________________________________________ > Sshguard-users mailing list > Ssh...@li... > https://lists.sourceforge.net/lists/listinfo/sshguard-users |
From: Mij <mi...@ss...> - 2010-07-05 10:37:51
|
Hmm, this is weird :) Blind dive: does anything happen with the permissions of the FIFO? If I recall it right, ubuntu runs syslogd as an unprivileged user. If you sort it out, please report your answer to the list for the archives. If you don't, consider using Log Sucking. On May 17, 2010, at 20:42 , Adam Cohen wrote: > greetings, > I'm adding sshguard (r1.5rc2) to a system running Ubuntu (8.1 / intrepid) > > Configure for iptables, looks good > Built from sources, looks good > Configure /etc/syslog.conf as below: > > # /etc/syslog.conf Configuration file for syslogd. > auth.info;authpriv.info |/var/log/sshguard.fifo > auth,authpriv.* /var/log/auth.log > *.*;auth,authpriv.none -/var/log/syslog > > Restart syslog > /etc/init.d/sysklogd restart > > Start sshguard > initctl start sshguard > > sshguard works fine as FIFO receives messages > > But after a while...FIFO stops receiving messages and so sshguard gets no input to scan. This seems like an Ubuntu issue but could there be something wrong with my syslog.conf? > > thanks > Adam > > -- > Adam Cohen / IT Manager > Energy Biosciences Institute / UC Berkeley > 109 Calvin Lab / 510-642-7709 > http://www.energybiosciencesinstitute.org > > ------------------------------------------------------------------------------ > > _______________________________________________ > Sshguard-users mailing list > Ssh...@li... > https://lists.sourceforge.net/lists/listinfo/sshguard-users |
From: Mij <mi...@ss...> - 2010-07-05 10:30:42
|
Hi Robert, I cannot reproduce this problem on any of my machines, but here is the most likely explanation. Log Validation works as follows: 1. recognize an attack signature 2. extract generating PID from it (logPID) 3. compare logPID with the genuine PID genPID (from the pidfile). Match => ACCEPT The algorithm ideally stops here, but some daemons (like sshd) delegate connection processing to children. So the algorithm goes on: 4. ask the system for the parent-child process table 5. check if logPID is child of genPID. Match => ACCEPT 6. REJECT For daemons delegating client handling to children, what's likely happening on your machine is that sshguard receives the message when the child has already died after sending its log message. Sshguard has then no way to tell. With log sucking this is more likely to happen under non-BSD systems, where the logic is implemented with proactive non-blocking polls (on BSD it's reactive on kqueue()). I will consider collapsing this in a single libevent logic in the near future. michele On May 14, 2010, at 11:19 , Robert S wrote: > Hi. > > I have tried this with log sucking and direct feed from a FIFO with > similar results. This is certainly a lot better, but there are still > some false positives: > > May 14 01:31:31 hostname sshd[21193]: User root from 64.179.173.93 not > allowed because none of user's groups are listed in AllowGroups > May 14 01:31:32 hostname sshguard[21993]: Ignore attack as pid '21193' > has been forged for service 100. > May 14 01:31:35 hostname sshd[21199]: User root from 64.179.173.93 not > allowed because none of user's groups are listed in AllowGroups > May 14 01:31:39 hostname sshd[21202]: User root from 64.179.173.93 not > allowed because none of user's groups are listed in AllowGroups > May 14 01:31:43 hostname sshd[21208]: User root from 64.179.173.93 not > allowed because none of user's groups are listed in AllowGroups > May 14 01:31:47 hostname sshd[21219]: User root from 64.179.173.93 not > allowed because none of user's groups are listed in AllowGroups > May 14 01:31:47 hostname sshguard[21993]: Blocking 64.179.173.93:4 for >> 630secs: 40 danger in 4 attacks over 12 seconds (all: 40d in 1 abuses > over 12s). > May 14 02:27:55 hostname sshd[21341]: User root from 59.188.11.38 not > allowed because none of user's groups are listed in AllowGroups > May 14 02:27:56 hostname sshguard[21993]: Ignore attack as pid '21341' > has been forged for service 100. > May 14 02:27:57 hostname sshd[21343]: User root from 59.188.11.38 not > allowed because none of user's groups are listed in AllowGroups > May 14 02:27:58 hostname sshd[21347]: User root from 59.188.11.38 not > allowed because none of user's groups are listed in AllowGroups > May 14 02:28:00 hostname sshd[21350]: User root from 59.188.11.38 not > allowed because none of user's groups are listed in AllowGroups > May 14 02:28:02 hostname sshd[21353]: User root from 59.188.11.38 not > allowed because none of user's groups are listed in AllowGroups > May 14 02:28:02 hostname sshguard[21993]: Blocking 59.188.11.38:4 for >> 630secs: 40 danger in 4 attacks over 5 seconds (all: 40d in 1 abuses > over 5s). > May 14 02:33:33 hostname sshd[21376]: User root from 122.166.36.130 > not allowed because none of user's groups are listed in AllowGroups > May 14 02:33:33 hostname sshguard[21993]: Ignore attack as pid '21376' > has been forged for service 100. > May 14 02:33:36 hostname sshd[21379]: User root from 122.166.36.130 > not allowed because none of user's groups are listed in AllowGroups > May 14 02:33:38 hostname sshd[21382]: User root from 122.166.36.130 > not allowed because none of user's groups are listed in AllowGroups > May 14 02:33:41 hostname sshd[21385]: User root from 122.166.36.130 > not allowed because none of user's groups are listed in AllowGroups > May 14 02:33:45 hostname sshd[21388]: User root from 122.166.36.130 > not allowed because none of user's groups are listed in AllowGroups > May 14 02:33:45 hostname sshguard[21993]: Blocking 122.166.36.130:4 > for >630secs: 40 danger in 4 attacks over 9 seconds (all: 40d in 1 > abuses over 9s). > May 14 04:10:27 hostname sshd[21735]: User root from 122.0.19.18 not > allowed because none of user's groups are listed in AllowGroups > May 14 04:10:31 hostname sshd[21738]: User root from 122.0.19.18 not > allowed because none of user's groups are listed in AllowGroups > May 14 04:10:35 hostname sshd[21741]: User root from 122.0.19.18 not > allowed because none of user's groups are listed in AllowGroups > May 14 04:10:39 hostname sshd[21744]: User root from 122.0.19.18 not > allowed because none of user's groups are listed in AllowGroups > May 14 04:10:39 hostname sshguard[21993]: Blocking 122.0.19.18:4 for >> 630secs: 40 danger in 4 attacks over 11 seconds (all: 40d in 1 abuses > over 11s). > > Robert. > > ------------------------------------------------------------------------------ > > _______________________________________________ > Sshguard-users mailing list > Ssh...@li... > https://lists.sourceforge.net/lists/listinfo/sshguard-users |
From: Mij <mi...@ss...> - 2010-07-04 23:34:11
|
I've been considering this. There are some thought holding it back, like - one parser is already incumbent in the code, combining two parsers is some pain - parsing has a terrible code/functionality ratio, it's a pity to deploy it for something as ancillary as configuration files - having configuration files would finally mark sshguard a "serious" daemon :) rather than a tool I've found the "envdir" configuration style (that's "configuration directory"es rather than files) tremendously lean and convenient from both the user and the programmer; how would that fit in your daemon script frame? On Jun 1, 2010, at 06:57 , Julián Moreno Patiño wrote: > Hi Mij, > > It would be nice to implement a configuration file sshguard.conf to enable options such as log sucker, whitelisting, blacklisting, port service and use them in different services (sshd, sendmail, exim, dovecot, etc), it's more easier and I can create more generic daemon script to Debian Distribution. > > Thank you very much, see you. > > Kind Regards, > > -- > Julián Moreno Patiño > Registered GNU Linux User ID 488513 > PGP KEY ID 6168BF60 > ------------------------------------------------------------------------------ > > _______________________________________________ > Sshguard-users mailing list > Ssh...@li... > https://lists.sourceforge.net/lists/listinfo/sshguard-users |
From: Mij <mi...@ss...> - 2010-07-04 23:33:33
|
Thanks for insisting so kindly, you got it committed as r200 (!!) as a prize. On May 21, 2010, at 22:57 , El Topo wrote: > Hi, > > I reported this bug before and it was fixed, but there is a leftover, so I am submitting a patch: > > ===begin > > Index: src/fwalls/hosts.c > =================================================================== > --- src/fwalls/hosts.c (revision 199) > +++ src/fwalls/hosts.c (working copy) > @@ -170,7 +170,6 @@ > > int hosts_updatelist() { > char buf[HOSTS_MAXCMDLEN]; > - char tempflname[30]; > FILE *tmp, *deny; > > /* open hosts.allow file */ > > ===end > > the patch is also attached. > > Thanks, > > cameos > > On Thu, Mar 11, 2010 at 2:13 PM, El Topo <ca...@gm...> wrote: > Hi, > > I found a bug in > src/fwalls/hosts.c > > 1. there is a global variable tempflname, but in fw_init() and hosts_updatelist(), local variables with the same name are also defined, this caused make_temporary_conffile() always fails. Fix: local variables should be deleted; > 2. the glboal variable tempflname should be initialized as soon as possible in fw_init(), otherwise hosts_clearsshguardblocks() tries to create temp file with invalid name (and fails). > > cameos > > <sshguard.patch>------------------------------------------------------------------------------ > > _______________________________________________ > Sshguard-users mailing list > Ssh...@li... > https://lists.sourceforge.net/lists/listinfo/sshguard-users |