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

Re: [Sshguard-users] core dump after upgrade due to blacklist

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

On 09/25/2015 12:02, Chris St Denis wrote:
> I upgraded from 1.6.0 to 1.6.1 and it started crashing on load.

Are you using 'ipfw' with the blacklist?

Best,
Kevin Zheng

-- 
Kevin Zheng
kev...@gm... | ke...@kd... | PGP: 0xC22E1090

Re: [Sshguard-users] New ipfw backend

[Mark F. <fe...@Fr...>]

On Sun, Jun 21, 2015, at 23:43, SASAKI Katuhiro wrote:
> Hi.
> 
> > In light of the recent `ipfw` issues I've decided to re-implement the
> > `ipfw` backend using the command framework that is used for nearly all
> > of the other backends.
> > 
> Great!
> 
> > Please don't test this in a production environment, and if you test it
> > at all, be aware that bad things can happen. Please take a look at the
> > patch before you try to run this code.
> > 
> I tested the patch with 1.6.0 on my FreeBSD 10.1R/i386. Two problems
> below are found.
> 
> 1. In the viewpoint of ipfw , tables are specified by number (0 to
> 65535). We can't assign the name like "sshguard" for tables. It
> became necessary to replace "sshguard" with some number (22, for
> example).
> 

IPFW had a huge overhaul last fall.
https://svnweb.freebsd.org/base/head/sbin/ipfw/ipfw.8?revision=272840&view=markup

root@gw:~ # uname -a
FreeBSD gw.feld.me 11.0-CURRENT FreeBSD 11.0-CURRENT #46 r288524M: Sat
Oct  3 06:41:42 CDT 2015     
root@gw:~ # ipfw table sshguard add 1.2.3.4/32
DEPRECATED: inserting data into non-existent table sshguard.
(auto-created)
added: 1.2.3.4/32 0
root@gw:~ # ipfw table sshguard list
--- table(sshguard), set(0) ---
1.2.3.4/32 0

> 2. Command "ipfw table [table number] add" can receive only one target
> (IP address, and some other search keys) at a time. Using loop in
> "COMMAND_BLOCK_LIST" looks reasonable for me.
> 
> Attached is patch for
> 0001-Reimplement-ipfw-backend-using-command-framework.patch.
> 
> Thank you.
> 

The release notes for the new IPFW changes mention "Batched add/delete
has been added to tables code" but I'm not sure how that is supposed to
work.


-- 
  Mark Felder
  ports-secteam member
  fe...@Fr...

[Sshguard-users] core dump after upgrade due to blacklist

[Chris St D. <ch...@ct...>]

I upgraded from 1.6.0 to 1.6.1 and it started crashing on load.

    Bus error (core dumped)

Here is a backtrace, tho it doesn't look that useful. I still have the 
core file so I can generate better ones with instructions.

    #0  0x0000000800c24b33 in getenv () from /lib/libc.so.7
    [New Thread 801406800 (LWP 101216/sshguard)]
    [New Thread 801406400 (LWP 101479/sshguard)]
    (gdb) bt
    #0  0x0000000800c24b33 in getenv () from /lib/libc.so.7
    #1  0x0000000800c04479 in tzset () from /lib/libc.so.7
    #2  0x0000000800c04c56 in ctime_r () from /lib/libc.so.7
    #3  0x0000000800c01ca1 in vsyslog () from /lib/libc.so.7
    #4  0x0000000800c01b7b in syslog () from /lib/libc.so.7
    #5  0x0000000000404125 in ?? ()
    #6  0x00000000004028a6 in ?? ()
    #7  0x000000000040236f in ?? ()
    #8  0x00000008006c4000 in ?? ()
    #9  0x0000000000000000 in ?? ()

A little experimenting showed that it was being caused by something in 
the blacklist file. Renaming the file and letting it create a new one 
fixed it.

Here is a copy of the file. Hopefully a dev can reproduce the crash with it.

    # SSHGuard blacklist file ( http://www.sshguard.net/ ).
    # Format of entries: BLACKLIST_TIMESTAMP|SERVICE|ADDRESS_TYPE|ADDRESS
    1437287630|100|4|5.231.228.91
    1437315019|100|4|222.186.52.213
    1437516671|100|4|58.52.134.5
    1437651459|100|4|222.186.42.218
    1438097148|100|4|104.149.197.97
    1438128829|100|4|222.186.56.112
    1438296390|100|4|5.255.144.81
    1438391422|100|4|125.39.170.138
    1438435051|100|4|169.54.233.117
    1438538121|100|4|111.73.46.231
    1438547318|100|4|111.20.145.210
    1438584253|100|4|222.186.34.86
    1438786729|100|4|203.124.106.16
    1438924282|100|4|218.2.22.36
    1439138420|100|4|117.21.191.209
    1439162584|100|4|222.186.21.46
    1439215230|100|4|222.186.30.21
    1439247605|100|4|114.241.155.156
    1439247705|100|4|114.241.130.204
    1439247740|100|4|114.241.137.4
    1439247948|100|4|123.123.213.36
    1439247981|100|4|114.241.157.237
    1439248058|100|4|114.241.135.160
    1439248113|100|4|123.123.215.187
    1439248458|100|4|123.123.214.60
    1439468360|100|4|61.186.245.211
    1439468360|100|4|113.204.53.134
    1439540283|100|4|169.54.233.126
    1439811166|100|4|211.37.45.100
    1439948790|100|4|119.254.16.13
    1440049115|100|4|103.254.110.52
    1440349237|100|4|219.235.4.119
    1440558369|100|4|61.160.212.144
    1440810164|100|4|169.54.233.120
    1441038197|100|4|61.183.35.86
    1441257970|100|4|222.186.15.92
    1441346100|100|4|221.12.5.107
    1441599273|100|4|221.231.6.245
    1441780504|100|4|222.186.190.55
    1442222411|100|4|222.186.56.107
    1442434123|100|4|222.186.56.114
    1442490491|100|4|169.54.233.121
    1443104332|100|4|222.186.30.202

Other info

    root@Rin:/ # sshguard -v
    sshguard 1.6.1

    root@Rin:/ # uname -a
    FreeBSD Rin.ctgameinfo.com 10.1-RELEASE-p15 FreeBSD 10.1-RELEASE-p15
    #0: Tue Jul 21 18:00:00 UTC 2015
    ro...@am...:/usr/obj/usr/src/sys/GENERIC amd64

Re: [Sshguard-users] SSHGuard and IPSet

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

On 09/24/2015 11:20, spaceman wrote:
> Just a thought but it might make sense for SSHGuard to ipsets rather
> than massive long chains in iptables. My blacklist is now 69 addresses
> long which starts to look unwieldy (and no doubt mine is relatively
> small compared to others).

Sounds promising. It seems to resemble ipfw and pf tables, which are
being used in the ipfw and pf backends.

Unfortunately I don't run either iptables or ipset, so I don't think I'd
be able to test any ipset backend I write.

Some interesting changes are also happening in the 'newfw' branch
(delegating firewall actions to a helper program), and that might be a
useful point to get ipset support in.

Thoughts from people running iptables?

Thanks,
Kevin Zheng

-- 
Kevin Zheng
kev...@gm... | ke...@kd... | PGP: 0xC22E1090

[Sshguard-users] SSHGuard and IPSet

[spaceman <spa...@an...>]

Hi,

Just a thought but it might make sense for SSHGuard to ipsets rather than 
massive long chains in iptables. My blacklist is now 69 addresses long which 
starts to look unwieldy (and no doubt mine is relatively small compared to 
others).

I got the idea from here which might explain what I mean better:
http://www.linuxjournal.com/content/advanced-firewall-configurations-ipset

Regards,
spaceman

[Sshguard-users] Tor and sshguard (was "Re: Block CMS-type logins")

[Richard J. <rjt...@sa...>]

We make a point to whitelist Tor exits because some of our legitimate users 
behind censorship systems (corp, edu, gov, etc.) use it to reach us. This 
is arranged in pf.conf in our case, with an allow rule that takes 
precedence over sshguard table entries. Tor sure beats teaching folks how 
to install and use Iodine. :)

The consensus doc held by any Tor node (exit or not) can tell you which 
exit nodes allow traffic outbound to port 22, and/or the alt ports you set 
up for sshd to listen upon. The Tor project also has web apps and DNS-based 
services for providing that consensus info, if you really care.

That said, there's no real point in treating Tor exit nodes specially if 
you're not going to exempt them. If some bad actor abuses them to try 
guessing login credentials, sshguard will do its thing just as it does for 
the overwhelming majority of non-Tor-related IP addresses used for guessing 
creds. No need for extra effort there.

That lack of need for extra effort applies in general to Tor. We find, both 
here and at a mid-sized edu, that Tor usually doesn't even show up in the 
volume of web guessers, SQL explorers, scanners, etc. Possibly this is 
because Tor is slower than other methods and has nowhere near the reach of
even a mid-sized botnet. When we hunt through possibly malicious flows, we
can spot 1 connection out of 200k that's from a Tor exit.

So we work on Tor exit lists only because we whitelist them. It's a waste 
of effort for us to track them otherwise.

Richard



On September 15, 2015 06:36:51 li...@la... wrote:

>
> http://sourceforge.net/projects/swatch/
>
> Thanks. I will give it a try.??
>
> I noticed a ssh attack via a Tor exit node. The user got sshguard banned 
> eventually, but it makes me ???wonder if Tor changes IP enough to avoid 
> banning in some cases. You would probably want to ban any ssh from a Tor 
> exit node on the first try.
> ?? Original Message ??
> From: Willem Jan Withagen
> Sent: Tuesday, September 15, 2015 12:44 AM
> To: ssh...@li...
> Reply To: ssh...@li...
> Subject: Re: [Sshguard-users] Block CMS-type logins
>
> On 15-9-2015 01:01, li...@la... wrote:
>> I don't use any CMS like drupal, WordPress, etc. Is there a way to block
>> ???IP addresses that waste their time trying to log into services I don't
>> provide. Clearly such attempts are from hackers/bots.
>>
>> These attempts show up in the nginx access log rather than auth.log.
>
> I'm using swatch for this. It is written in perl, and understanding perl
> helps.
>
> Not an elaborate tool as sshguard, but it does get the job mostely done.
> And the big advantace is that it uses regular expressions to match the
> logfiles.
> What is not so great is the implementation of the penalty system to
> decide to start blacklisting a host.
>
> no community to ask questions, not much info on the man-page
>
> I've got rules like:
> # No need to fetch config.inc.php EVER
> watchfor /([0-9]+\.[0-9]+\.[0-9]+\.[0-9]+)\] (.*config.inc.php)/i
> exec /sbin/ipfw table 80 add $1
> exec /bin/echo $2 for $1
> exec /usr/bin/logger -p security.notice $2 for $1
>
> --WjW
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Sshguard-users mailing list
> Ssh...@li...
> https://lists.sourceforge.net/lists/listinfo/sshguard-users
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Sshguard-users mailing list
> Ssh...@li...
> https://lists.sourceforge.net/lists/listinfo/sshguard-users

Re: [Sshguard-users] Block CMS-type logins

[<li...@la...>]

http://sourceforge.net/projects/swatch/

Thanks. I will give it a try. 

I noticed a ssh attack via a Tor exit node. The user got sshguard banned eventually, but it makes me ‎wonder if Tor changes IP enough to avoid banning in some cases. You would probably want to ban any ssh from a Tor exit node on the first try.
  Original Message  
From: Willem Jan Withagen
Sent: Tuesday, September 15, 2015 12:44 AM
To: ssh...@li...
Reply To: ssh...@li...
Subject: Re: [Sshguard-users] Block CMS-type logins

On 15-9-2015 01:01, li...@la... wrote:
> I don't use any CMS like drupal, WordPress, etc. Is there a way to block
> ‎IP addresses that waste their time trying to log into services I don't
> provide. Clearly such attempts are from hackers/bots.
>
> These attempts show up in the nginx access log rather than auth.log.

I'm using swatch for this. It is written in perl, and understanding perl 
helps.

Not an elaborate tool as sshguard, but it does get the job mostely done.
And the big advantace is that it uses regular expressions to match the 
logfiles.
What is not so great is the implementation of the penalty system to 
decide to start blacklisting a host.

no community to ask questions, not much info on the man-page

I've got rules like:
# No need to fetch config.inc.php EVER
watchfor /([0-9]+\.[0-9]+\.[0-9]+\.[0-9]+)\] (.*config.inc.php)/i
exec /sbin/ipfw table 80 add $1
exec /bin/echo $2 for $1
exec /usr/bin/logger -p security.notice $2 for $1

--WjW

------------------------------------------------------------------------------
_______________________________________________
Sshguard-users mailing list
Ssh...@li...
https://lists.sourceforge.net/lists/listinfo/sshguard-users

Re: [Sshguard-users] Block CMS-type logins

[Willem J. W. <wj...@di...>]

On 15-9-2015 01:01, li...@la... wrote:
> I don't use any CMS like drupal, WordPress, etc. Is there a way to block
> ‎IP addresses that waste their time trying to log into services I don't
> provide. Clearly such attempts are from hackers/bots.
>
> These attempts show up in the nginx access log rather than auth.log.

I'm using swatch for this. It is written in perl, and understanding perl 
helps.

Not an elaborate tool as sshguard, but it does get the job mostely done.
And the big advantace is that it uses regular expressions to match the 
logfiles.
What is not so great is the implementation of the penalty system to 
decide to start blacklisting a host.

no community to ask questions, not much info on the man-page

I've got rules like:
# No need to fetch config.inc.php EVER
watchfor /([0-9]+\.[0-9]+\.[0-9]+\.[0-9]+)\] (.*config.inc.php)/i
         exec /sbin/ipfw table 80 add $1
         exec /bin/echo $2 for $1
         exec /usr/bin/logger -p security.notice $2 for $1

--WjW

[Sshguard-users] Block CMS-type logins

[<li...@la...>]

<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"><style> body {  font-family: "Calibri","Slate Pro",sans-serif,"sans-serif"; color:#262626 }</style> </head> <body lang="en-US"><div>I don't use any CMS like drupal, WordPress, etc.&nbsp;<span style="font-family: Calibri, 'Slate Pro', sans-serif, sans-serif;">Is there a way to block ‎IP addresses that waste their time trying to log into services I don't provide. Clearly such attempts are from hackers/bots.</span></div><div><span style="font-family: Calibri, 'Slate Pro', sans-serif, sans-serif;"><br></span></div><div>These attempts show up in the nginx access log rather than auth.log.</div><div><br></div><div></div></body></html>

[Sshguard-users] Handling SIGTSTP and SIGCONT

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

Hi there,

I'm currently taking a look at SSHGuard's signal handling routines. Is
anyone using the SIGTSTP/SIGCONT interface? Is it worth keeping?

Code-wise, it is trivial. The motivation for this post was noticing a
signal-unsafe call to sshguard_log() in the signal handler. If people
deem it a worthy feature this will be rewritten in a signal-safe way.

Thanks,
Kevin Zheng

-- 
Kevin Zheng
kev...@gm... | ke...@kd... | PGP: 0xC22E1090

Re: [Sshguard-users] syslog compression freebsd

[Bradley G. <pi...@ma...>]

> On Sep 3, 2015, at 1:28 PM, Mark Felder <fe...@fr...> wrote:
> 
> On Wed, Sep 2, 2015, at 08:20, Willem Jan Withagen wrote:
>> On 2-9-2015 13:19, li...@la... wrote:
>>> When in doubt, boot! So yes, I restarted. 
>>> 
>>> I have to say I never put two identical flags on a command, so this certainly is a first. 
>>> 
>>> Here is the double dash c discussed :
>>> 
>>> http://www.syslog.org/forum/syslog-and-syslogd/how-to-set-syslog-to-not-sho-'last-message-repeatedandquo/‎
>> 
>> syslogd also has the -s where more s's mean more security
>> -s      Operate in secure mode.  Do not log messages from remote
>>        machines.  If specified twice, no network socket will be opened
>>        at all, which also disables logging to remote machines.
>> 
>> And give me some more time, and I'll think of more commands where this
>> is used.
> 
> Everywhere for extra verbosity:  -vvvv  (ssh, for example)


Could not remember examples, been a while, but ssh -vvv is a good example of flag count effecting behavior.

Thank you.

—
Brad

Re: [Sshguard-users] syslog compression freebsd

[Mark F. <fe...@Fr...>]

On Wed, Sep 2, 2015, at 08:20, Willem Jan Withagen wrote:
> On 2-9-2015 13:19, li...@la... wrote:
> > When in doubt, boot! So yes, I restarted. 
> > 
> > I have to say I never put two identical flags on a command, so this certainly is a first. 
> > 
> > Here is the double dash c discussed :
> > 
> > http://www.syslog.org/forum/syslog-and-syslogd/how-to-set-syslog-to-not-sho-'last-message-repeatedandquo/‎
> 
> syslogd also has the -s where more s's mean more security
> -s      Operate in secure mode.  Do not log messages from remote
>         machines.  If specified twice, no network socket will be opened
>         at all, which also disables logging to remote machines.
> 
> And give me some more time, and I'll think of more commands where this
> is used.
> 


Everywhere for extra verbosity:  -vvvv  (ssh, for example)

Re: [Sshguard-users] SSHGuard with CentOS 7

[. g. <fre...@ho...>]

> Date: Wed, 2 Sep 2015 19:44:13 -0700
> Subject: Re: [Sshguard-users] SSHGuard with CentOS 7
> No support for firewalld yet, but writing a new backend is easy,
> provided you have the machine and manual pages to test on.

Hi:
　I just can edit firewall rule with vi and rule file....
(I don't understand use command to set rule)

　I have a CentOS7 vm, if I want to try it,
where can I see the  manual pages?

Thank you
 		 	   		  

Re: [Sshguard-users] SSHGuard with CentOS 7

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

On 09/02/2015 19:04, . ghost wrote:
> 　I would like to know if sshguard not work with Firewalld on CentOS 7 yet?
> It would be support in later version?

No support for firewalld yet, but writing a new backend is easy,
provided you have the machine and manual pages to test on.

Best,
Kevin Zheng

-- 
Kevin Zheng
kev...@gm... | ke...@kd... | PGP: 0xC22E1090

[Sshguard-users] SSHGuard with CentOS 7

[. g. <fre...@ho...>]

Hi:
　I would like to know if sshguard not work with Firewalld on CentOS 7 yet?
It would be support in later version?

Thank you

　　　　　　　　　　　　　　　　　　　newbie 15'09/03
 		 	   		  

Re: [Sshguard-users] syslog compression freebsd

[Willem J. W. <wj...@di...>]

On 2-9-2015 13:19, li...@la... wrote:
> When in doubt, boot! So yes, I restarted. 
> 
> I have to say I never put two identical flags on a command, so this certainly is a first. 
> 
> Here is the double dash c discussed :
> 
> http://www.syslog.org/forum/syslog-and-syslogd/how-to-set-syslog-to-not-sho-'last-message-repeatedandquo/‎

syslogd also has the -s where more s's mean more security
-s      Operate in secure mode.  Do not log messages from remote
        machines.  If specified twice, no network socket will be opened
        at all, which also disables logging to remote machines.

And give me some more time, and I'll think of more commands where this
is used.

--WjW


> 
>   Original Message  
> From: Willem Jan Withagen
> Sent: Wednesday, September 2, 2015 12:30 AM
> To: ssh...@li...
> Reply To: ssh...@li...
> Subject: Re: [Sshguard-users] syslog compression freebsd
> 
> On 2-9-2015 02:02, li...@la... wrote:
>>
>> I noticed the post regarding syslog compression. I put this in
>> rc.conf, just addding the dash c to the syslogd_flags:
>>
>> syslogd_enable="YES" # Run syslog daemon (or NO).
>> syslogd_program="/usr/sbin/syslogd" # path to syslogd, if you want a
>> different one.
>> syslogd_flags="-s -c" # Flags to syslogd (if
>> enabled).
>>
>> But I still get compression.
>>
>> Sep 1 05:58:42 theranch sshd[3218]: error: PAM: authentication error
>> for root from 221.203.142.71 Sep 1 05:58:43 theranch last message
>> repeated 2 times
> 
> Trivial question, but just to make sure:
> You did restart syslogd?
> 
> 'service syslogd restart'
> 
> --WjW
> 
> 
> 
> ------------------------------------------------------------------------------
> Monitor Your Dynamic Infrastructure at Any Scale With Datadog!
> Get real-time metrics from all of your servers, apps and tools
> in one place.
> SourceForge users - Click here to start your Free Trial of Datadog now!
> http://pubads.g.doubleclick.net/gampad/clk?id=241902991&iu=/4140
> _______________________________________________
> Sshguard-users mailing list
> Ssh...@li...
> https://lists.sourceforge.net/lists/listinfo/sshguard-users
> 
> ------------------------------------------------------------------------------
> Monitor Your Dynamic Infrastructure at Any Scale With Datadog!
> Get real-time metrics from all of your servers, apps and tools
> in one place.
> SourceForge users - Click here to start your Free Trial of Datadog now!
> http://pubads.g.doubleclick.net/gampad/clk?id=241902991&iu=/4140
> _______________________________________________
> Sshguard-users mailing list
> Ssh...@li...
> https://lists.sourceforge.net/lists/listinfo/sshguard-users
> 

Re: [Sshguard-users] syslog compression freebsd

[<li...@la...>]

When in doubt, boot! So yes, I restarted. 

I have to say I never put two identical flags on a command, so this certainly is a first. 

Here is the double dash c discussed :

http://www.syslog.org/forum/syslog-and-syslogd/how-to-set-syslog-to-not-sho-'last-message-repeatedandquo/‎

  Original Message  
From: Willem Jan Withagen
Sent: Wednesday, September 2, 2015 12:30 AM
To: ssh...@li...
Reply To: ssh...@li...
Subject: Re: [Sshguard-users] syslog compression freebsd

On 2-9-2015 02:02, li...@la... wrote:
>
> I noticed the post regarding syslog compression. I put this in
> rc.conf, just addding the dash c to the syslogd_flags:
>
> syslogd_enable="YES" # Run syslog daemon (or NO).
> syslogd_program="/usr/sbin/syslogd" # path to syslogd, if you want a
> different one.
> syslogd_flags="-s -c" # Flags to syslogd (if
> enabled).
>
> But I still get compression.
>
> Sep 1 05:58:42 theranch sshd[3218]: error: PAM: authentication error
> for root from 221.203.142.71 Sep 1 05:58:43 theranch last message
> repeated 2 times

Trivial question, but just to make sure:
You did restart syslogd?

'service syslogd restart'

--WjW



------------------------------------------------------------------------------
Monitor Your Dynamic Infrastructure at Any Scale With Datadog!
Get real-time metrics from all of your servers, apps and tools
in one place.
SourceForge users - Click here to start your Free Trial of Datadog now!
http://pubads.g.doubleclick.net/gampad/clk?id=241902991&iu=/4140
_______________________________________________
Sshguard-users mailing list
Ssh...@li...
https://lists.sourceforge.net/lists/listinfo/sshguard-users

Re: [Sshguard-users] syslog compression freebsd

[Willem J. W. <wj...@di...>]

On 2-9-2015 02:02, li...@la... wrote:
>
> I noticed the post regarding syslog compression. I put this in
> rc.conf, just addding the dash c to the syslogd_flags:
>
> syslogd_enable="YES" # Run syslog daemon (or NO).
> syslogd_program="/usr/sbin/syslogd" # path to syslogd, if you want a
> different one.
> syslogd_flags="-s -c" # Flags to syslogd (if
> enabled).
>
> But I still get compression.
>
> Sep 1 05:58:42 theranch sshd[3218]: error: PAM: authentication error
> for root from 221.203.142.71 Sep 1 05:58:43 theranch last message
> repeated 2 times

Trivial question, but just to make sure:
	You did restart syslogd?

'service syslogd restart'

--WjW

Re: [Sshguard-users] Using the sshguard blacklist DB

[Willem J. W. <wj...@di...>]

On 1-9-2015 22:57, Kevin Zheng wrote:
> On 08/31/2015 16:51, Willem Jan Withagen wrote:
>> I used whitelist for a function you just described as: do-not-balcklist.
>> And I totally agree....
>> Most of the time I'm fishing for blocked customers that repeatedly tried
>> the wrong password to update their website over sftp.
>> And always the same customers... :(
>> Sp they are not whitelisted in the FW sense, since they still need to
>> follow all the FW rules. But I really would like for them not to end up
>> in the blacklist over and over....
>>
>> So then reread my request as:
>> 	Once on the do-not-block
>> 	Also do not insert in FW upon restart.
>
> Let me make sure I understand your feature request:
>
> Replace the current "whitelist" system with a "do-not-blacklist" scheme.
> Addresses on the list are still blocked after repeated attempts, but are
> never added to the blacklist.

The name of the list is only wording, I'm all ears for a good 
suggestion. And if whitelist is wat to use, fine with me.
I would leave the way it works like it is:
- If an ipnr. matches the "whitelist/DNB", do not block it, do not put 
it in the blacklist.db

> Here it gets a little fuzzy:
>
> If an address is both in the blacklist and the do-not-blacklist (DNB)
> list, the blacklist should "win". An example would be if
> do-not-blacklist lists a subnet, but one of the addresses in it is
> blacklisted. This means that if someone makes it into the blacklist, you
> will need to remove it from the blacklist and add it to the DNB. This
> seems like an acceptable trade-off for the complexity required.

Now when we stop and restart sshguard is where the trick is.
When processing the blacklist to reinstall it, first match the entries 
in the DNB and if they match, do not add them to the firewall.
Perhaps generate a message or log informing about the skip.

In my case the DNB has priority over the blacklist.

And remember, winning is limitted, It just means the the ipnr is allowed 
to run against the remainder of the rules in the firewall.

--WjW

Re: [Sshguard-users] syslog compression freebsd

[Willem J. W. <wj...@di...>]

On 2-9-2015 02:02, li...@la... wrote:
>
> I noticed the post regarding syslog compression. I put this in
> rc.conf, just addding the dash c to the syslogd_flags:
>
> syslogd_enable="YES" # Run syslog daemon (or NO).
> syslogd_program="/usr/sbin/syslogd" # path to syslogd, if you want a
> different one.
> syslogd_flags="-s -c" # Flags to syslogd (if
> enabled).
>
> But I still get compression.
>
> Sep 1 05:58:42 theranch sshd[3218]: error: PAM: authentication error
> for root from 221.203.142.71 Sep 1 05:58:43 theranch last message
> repeated 2 times

Otehr issue will be that you need 2* -c, since sshguard is not logging 
thru a pipe, but probably calling it via syslog(3)

-c      Disable the compression of repeated instances of the same line
         into a single line of the form ``last message repeated N times''
         when the output is a pipe to another program.  If specified
         twice, disable this compression in all cases.

--WjW

[Sshguard-users] syslog compression freebsd

[<li...@la...>]

I noticed the post regarding syslog compression. I put this in
rc.conf, just addding the dash c to the syslogd_flags:

syslogd_enable="YES" # Run syslog daemon (or NO).
syslogd_program="/usr/sbin/syslogd" # path to syslogd, if you want a
different one. 
syslogd_flags="-s -c" # Flags to syslogd (if
enabled).

But I still get compression. 

Sep 1 05:58:42 theranch sshd[3218]: error: PAM: authentication error
for root from 221.203.142.71 Sep 1 05:58:43 theranch last message
repeated 2 times

Re: [Sshguard-users] Using the sshguard blacklist DB

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

On 08/31/2015 16:51, Willem Jan Withagen wrote:
> I used whitelist for a function you just described as: do-not-balcklist.
> And I totally agree....
> Most of the time I'm fishing for blocked customers that repeatedly tried
> the wrong password to update their website over sftp.
> And always the same customers... :(
> Sp they are not whitelisted in the FW sense, since they still need to
> follow all the FW rules. But I really would like for them not to end up
> in the blacklist over and over....
> 
> So then reread my request as:
> 	Once on the do-not-block
> 	Also do not insert in FW upon restart.

Let me make sure I understand your feature request:

Replace the current "whitelist" system with a "do-not-blacklist" scheme.
Addresses on the list are still blocked after repeated attempts, but are
never added to the blacklist.

Here it gets a little fuzzy:

If an address is both in the blacklist and the do-not-blacklist (DNB)
list, the blacklist should "win". An example would be if
do-not-blacklist lists a subnet, but one of the addresses in it is
blacklisted. This means that if someone makes it into the blacklist, you
will need to remove it from the blacklist and add it to the DNB. This
seems like an acceptable trade-off for the complexity required.

Thanks,
Kevin Zheng

-- 
Kevin Zheng
kev...@gm... | ke...@kd... | PGP: 0xC22E1090

Re: [Sshguard-users] Using the sshguard blacklist DB

[Willem J. W. <wj...@di...>]

On 1-9-2015 01:48, Kevin Zheng wrote:
> On 08/31/2015 15:10, Willem Jan Withagen wrote:
>> I manage whitelists for a large set of servers in several ranges.
>> And on average are non-routable nets not my biggest problem.
>> But the whitelist contains mainly groups of gateways allowed to get
>> access to certain blocks of servers.
> 
> I'm not familiar with large setups so I'd be curious to learn more about
> your particular use case. Is maintaining whitelists significantly easier
> than maintaining firewall rules across several machines?

Well your other Email made things more clear...

I'll give you my 2cts vision on how we look out this:
A firewall whitelist are exactly those adresses that are 200% trusted.
And are used early in the FW to prevent lockouts. So they rarely change.
And it mainly allows for ssh only...

Then there is the list with bad-guys, they get denied ASAP.
So that is all the way at the front of the rules... Don't give 'm a
chance to look at any ports.

And then there is everybody in between that. And even they are not
completely equal.... There are things called customers, that actually
work on the servers and pay bills...
And then there are clients, every body else on the internet, they access
the websites and services on the servers.

Now the customers don't want to get blocked... but they still need
conform to the rules. So we let them jump the block with bad-guy denies,
right to the front of the set of rules that allow access to the
services. It they by accident try to sftp as root 4 times, they still
don't get blacklisted.
This is sort of the do-not-block list.

Then there is the clients. They need to first pass the bad-guys deny
tables. Once don that, then need to match the allow rules for the
services. If they are using the wrong access pattern, they become
abusers, they go into the blacklist. (Which is in our case a set of deny
tables; A table per type of violation. We also use portsentry, swatch,
and maillog/error.log/access.log scanning to block abusers)

Usually when the tables with customers are nicely kept, we do not have
to go and look for customers that have become abusers. :)

> 
>> I see it rather simple:
>> 	whitelist members are not to blocked because they are trusted.
>> All others are up for possible rejection.
>> So if I change the whitelist, I'd like that to take priority over
>> blacklisting. Now it is the other way around: blacklisting has priority.
> 
> I think this is a fair request, because whitelist entries are added
> manually, while blacklist entries are automatic. But James has a good
> point earlier that it might be better implemented using firewall rules.
> 
> The big "plus" of using SSHGuard's whitelist is that the same whitelist
> can be used across multiple machines possibly running different
> firewalls, without maintaining separate lists for each. Are there other
> advantages of this whitelist system? Is it important enough to keep?

Well I think 'whitelist' is a term that give confusion. As it is not up
to sshguard to whiltelist.... sshguard can only decide not to insert an
entry into a FW. But that is not going to be whitelisting.
do-not-block (or something of the same meaning) would beter fit as a name.

>> Now what I suggested (and prefer)  is that sshguard does the smart-grep.
> 
> By "smart-grep," do you mean removing the intersection of the two sets?

What I would suggest is for the intersection not to go into the FW
tables. But maybe as per James suggestion, do keep 'm in the blacklist.
In our case I;d remove them from the blacklist, because I do not want to
immediately block an ex-customer once he has left our service.
I'd give hime the benefit of the doubt.

--WjW

> Thanks,
> Kevin Zheng
> 

Re: [Sshguard-users] Is sshguard working?

[Willem J. W. <wj...@di...>]

On 1-9-2015 02:03, Kevin Zheng wrote:
> On 08/31/2015 10:39, do...@sa... wrote:
>> My question goes back to the original question except that I am apparently the 
>> only one on the list using inetd. My initial reasons for this being I am several 
>> hours away from my servers and this seemed more prudent as testing mistakes are 
>> slightly less fatal than with ipfw. And much more easily circumvented.
> 
> I don't think it should matter whether you're running from 'inetd' or
> not, since all of the logs go through syslog. That's running, right?
> 
>> Anyway, the inet version exhibits the same characteristic as originally 
>> described. That is I see 50-100 entries logged within a minute before sshguard 
>> gets a block inserted. Restarting inetd is not required to pickup changes in the 
>> file. I was assuming this to be a scheduling issue. In my case all the instances 
>> of this are with PAM errors.
> 
> Can you give me a few examples of the log entries you want blocked? I
> want to make sure that SSHGuard is actually picking them up as attacks.
> 
>> One way to do this would be to launch all 100 (or so) attempts. The time stamps 
>> suggests they are arriving about 1/sec but this could be PAM queuing the 
>> requests.
> 
> I'm not sure; I don't know much about PAM.

And make sure that syslogd is not summarizing the reporting.
look at the -c option of syslogd:
 -c      Disable the compression of repeated instances of the same line
        into a single line of the form ``last message repeated N times''
        when the output is a pipe to another program.  If specified
        twice, disable this compression in all cases.

--WjW

Re: [Sshguard-users] Is sshguard working?

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

On 08/31/2015 10:39, do...@sa... wrote:
> My question goes back to the original question except that I am apparently the 
> only one on the list using inetd. My initial reasons for this being I am several 
> hours away from my servers and this seemed more prudent as testing mistakes are 
> slightly less fatal than with ipfw. And much more easily circumvented.

I don't think it should matter whether you're running from 'inetd' or
not, since all of the logs go through syslog. That's running, right?

> Anyway, the inet version exhibits the same characteristic as originally 
> described. That is I see 50-100 entries logged within a minute before sshguard 
> gets a block inserted. Restarting inetd is not required to pickup changes in the 
> file. I was assuming this to be a scheduling issue. In my case all the instances 
> of this are with PAM errors.

Can you give me a few examples of the log entries you want blocked? I
want to make sure that SSHGuard is actually picking them up as attacks.

> One way to do this would be to launch all 100 (or so) attempts. The time stamps 
> suggests they are arriving about 1/sec but this could be PAM queuing the 
> requests.

I'm not sure; I don't know much about PAM.

Best,
Kevin Zheng

-- 
Kevin Zheng
kev...@gm... | ke...@kd... | PGP: 0xC22E1090