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

Re: [Sshguard-users] sshguard terminating

[James H. <jam...@gm...>]

I most often saw the xlock error on boot when firewalld (a not vary
dynamic, dynamic firewall) and sshguard were both running through iptables
commands to bring up the firewall.

On Fri, Aug 14, 2015 at 7:25 AM, Kevin Zheng <kev...@gm...> wrote:

> On 08/14/2015 09:06, jonetsu wrote:
> > This is a Debian platform.  The version is 1.5.
>
> If possible, you should upgrade to 1.6.0.
>
> > I got the tarball generated by the web site and looked at the
> > Changes file under 1.6 section, and did not see anything
> > pertaining to this lock problem.  The code does not mention
> > 'xlock' specifically.
>
> You're looking for the last line of the v1.6.0 ChangeLog:
>
> "Wait for xtables lock when using iptables command (James Harris)"
>
> > If I consider sshguard as a black box, then what I thought of
> > doing is to add a --wait (-w) switch to my iptables call, which
> > will make iptables wait until the xlock is removed.  That amount
> > of time looks like rather short, since the xlock condition does
> > not happen every time.  Looks like it's dependent on the CPU being
> > jusy a bit too busy at that time, from some other process.
>
> This is how the issue was fixed in v1.6.0.
>
> > I'm curious about how a lock problem appeared *within*
> > sshguard...  Can you explain what the problem was ?
>
> My guess is that another program is running 'iptables', or another
> SSHGuard command did not finish. I'm not entirely sure because I don't
> run 'iptables' myself.
>
> Best,
> Kevin Zheng
>
> --
> Kevin Zheng
> kev...@gm... | ke...@kd... | PGP: 0xC22E1090
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Sshguard-users mailing list
> Ssh...@li...
> https://lists.sourceforge.net/lists/listinfo/sshguard-users
>



-- 
James Harris
Software Engineer
jam...@gm...

Re: [Sshguard-users] sshguard terminating

[jonetsu <jo...@te...>]

> From: jonetsu <jo...@te...> 
> Date: 08/14/15 12:35 

> I already have.  238 was from 'Download' tab -> 'From Source' ->
> 'latest release' link.  238 does not have ChangeLog file. 


Sorry, that link is for the 1.5 source release.


Is there another web site than sshguard.net ?


Thanks.

Re: [Sshguard-users] sshguard terminating

[jonetsu <jo...@te...>]

> From: "Kevin Zheng" <kev...@gm...> 
> Date: 08/14/15 10:25 

> If possible, you should upgrade to 1.6.0.

> You're looking for the last line of the v1.6.0 ChangeLog:

> "Wait for xtables lock when using iptables command (James Harris)"

What I got today is sshguard-code-238-trunk (automatically
generated tarball) and it does not have that file.  I got the 238
because the download link in the sshguard page offered 1.5 which
I already have.  238 was from 'Download' tab -> 'From Source' ->
'latest release' link.  238 does not have ChangeLog file. How to
get the 1.6.0 release ?


Thanks.

Re: [Sshguard-users] sshguard terminating

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

On 08/14/2015 09:06, jonetsu wrote:
> This is a Debian platform.  The version is 1.5.

If possible, you should upgrade to 1.6.0.

> I got the tarball generated by the web site and looked at the
> Changes file under 1.6 section, and did not see anything
> pertaining to this lock problem.  The code does not mention
> 'xlock' specifically.

You're looking for the last line of the v1.6.0 ChangeLog:

"Wait for xtables lock when using iptables command (James Harris)"

> If I consider sshguard as a black box, then what I thought of
> doing is to add a --wait (-w) switch to my iptables call, which
> will make iptables wait until the xlock is removed.  That amount
> of time looks like rather short, since the xlock condition does
> not happen every time.  Looks like it's dependent on the CPU being
> jusy a bit too busy at that time, from some other process.

This is how the issue was fixed in v1.6.0.

> I'm curious about how a lock problem appeared *within*
> sshguard...  Can you explain what the problem was ?

My guess is that another program is running 'iptables', or another
SSHGuard command did not finish. I'm not entirely sure because I don't
run 'iptables' myself.

Best,
Kevin Zheng

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

Re: [Sshguard-users] sshguard terminating

[jonetsu <jo...@te...>]

> From: "Kevin Zheng" <kev...@gm...> 
> Date: 08/13/15 23:18 

Hello,


> What operating system are you running? What version of
> SSHGuard? The fix for the iptables lock landed shortly before
> 1.6.0.


This is a Debian platform.  The version is 1.5.


>> My question is: does sshguard execute any iptables command when
>> terminating ?


> Yes, it runs iptables to flush blocked addresses.


I got the tarball generated by the web site and looked at the
Changes file under 1.6 section, and did not see anything
pertaining to this lock problem.  The code does not mention
'xlock' specifically.


If I consider sshguard as a black box, then what I thought of
doing is to add a --wait (-w) switch to my iptables call, which
will make iptables wait until the xlock is removed.  That amount
of time looks like rather short, since the xlock condition does
not happen every time.  Looks like it's dependent on the CPU being
jusy a bit too busy at that time, from some other process.


I'm curious about how a lock problem appeared *within*
sshguard...  Can you explain what the problem was ?


Thanks !

Re: [Sshguard-users] sshguard terminating

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

On 08/13/2015 21:28, jo...@te... wrote:
> I have a daemon manager that starts and stops sshguard.  This daemon
> manager is a library used by an application.  At one point in time a
> command is sent to this manager to terminate sshguard and that is
> executed in a thread.  Meanwhile, the application goes on by calling
> iptables.  From time to time, that iptables command fails with iptables
> reporting that there is a xlock on iptables since another application
> is using it.  

What operating system are you running? What version of SSHGuard? The fix
for the iptables lock landed shortly before 1.6.0.

> My question is: does sshguard execute any iptables command when
> terminating ?

Yes, it runs iptables to flush blocked addresses.

Best,
Kevin Zheng

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

[Sshguard-users] sshguard terminating

[<jo...@te...>]

Hello,

I have a daemon manager that starts and stops sshguard.  This daemon
manager is a library used by an application.  At one point in time a
command is sent to this manager to terminate sshguard and that is
executed in a thread.  Meanwhile, the application goes on by calling
iptables.  From time to time, that iptables command fails with iptables
reporting that there is a xlock on iptables since another application
is using it.  

My question is: does sshguard execute any iptables command when
terminating ?

Thanks.

Re: [Sshguard-users] Is sshguard working?

[James H. <jam...@gm...>]

The drop or reset is another reason to use a table and allow the end user
define the rule/action.  I can see some people will want drop others want
reset, some may prefer logging, and some might want to redirect to a
honeypot. I would suggest that sshguard should do the one thing well, scan
for attacks and place the source of those attack on a well know
table/list.  This requires users to execute a few command, create table,
reference table but that puts the responsibility of doing the correct thing
clearly in their hands.

On Thu, Aug 13, 2015 at 12:56 PM, Willem Jan Withagen <wj...@di...>
wrote:

> On 13-8-2015 17:10, Kevin Zheng wrote:
> > On 08/12/2015 20:32, li...@la... wrote:
> >> I downloaded the development version. Running sshguard -v indicates
> 1.6.0.
> >
> > You'll need to add a rule that looks something like this:
> >
> > reset ip from table (22) to me
> >
> > Keep in mind that 'ipfw' is a first-rule-wins firewall, which means that
> > if you have a rule that allows SSH connections, your SSHGuard rule must
> > have a higher rule number in order to block attacks. If you are adding
> > the rule from a shell, parenthesis must be escaped.
>
> I understand what you say, but I think you ment to say the lowest
> number? Since parsing start at the lowest (first-rule) number.
> >
> > # ipfw add 50 reset ip from table \(22\) to me
>
> I would not even reset the connection.
> Just drop/deny it, and the client needs to time it out.
>
> These are bad guys, anything you can do to delay them should be done.
>
> --WjW
>
>
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Sshguard-users mailing list
> Ssh...@li...
> https://lists.sourceforge.net/lists/listinfo/sshguard-users
>



-- 
James Harris
Software Engineer
jam...@gm...

Re: [Sshguard-users] Is sshguard working?

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

On 13-8-2015 17:10, Kevin Zheng wrote:
> On 08/12/2015 20:32, li...@la... wrote:
>> I downloaded the development version. Running sshguard -v indicates 1.6.0.
> 
> You'll need to add a rule that looks something like this:
> 
> reset ip from table (22) to me
> 
> Keep in mind that 'ipfw' is a first-rule-wins firewall, which means that
> if you have a rule that allows SSH connections, your SSHGuard rule must
> have a higher rule number in order to block attacks. If you are adding
> the rule from a shell, parenthesis must be escaped.

I understand what you say, but I think you ment to say the lowest
number? Since parsing start at the lowest (first-rule) number.
> 
> # ipfw add 50 reset ip from table \(22\) to me

I would not even reset the connection.
Just drop/deny it, and the client needs to time it out.

These are bad guys, anything you can do to delay them should be done.

--WjW

Re: [Sshguard-users] Is sshguard working?

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

On 08/12/2015 20:32, li...@la... wrote:
> I downloaded the development version. Running sshguard -v indicates 1.6.0.

You'll need to add a rule that looks something like this:

reset ip from table (22) to me

Keep in mind that 'ipfw' is a first-rule-wins firewall, which means that
if you have a rule that allows SSH connections, your SSHGuard rule must
have a higher rule number in order to block attacks. If you are adding
the rule from a shell, parenthesis must be escaped.

# ipfw add 50 reset ip from table \(22\) to me

Best,
Kevin Zheng

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

Re: [Sshguard-users] Is sshguard working?

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

I downloaded the development version. Running sshguard -v indicates 1.6.0.


  Original Message  
From: Kevin Zheng
Sent: Wednesday, August 12, 2015 8:58 AM
To: ssh...@li...
Reply To: ssh...@li...
Subject: Re: [Sshguard-users] Is sshguard working?

On 08/11/2015 23:51, li...@la... wrote:
> I'm running FreeBSD and ipfw. However, I got the impression the
> documentation needed to be updated.

Right, but what version of SSHGuard are you running?

Thanks,
Kevin Zheng

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

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

Re: [Sshguard-users] Is sshguard working?

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

On 08/11/2015 23:51, li...@la... wrote:
> I'm running FreeBSD and ipfw. However, I got the impression the
> documentation needed to be updated.

Right, but what version of SSHGuard are you running?

Thanks,
Kevin Zheng

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

Re: [Sshguard-users] Is sshguard working?

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

On 12-8-2015 04:55, Kevin Zheng wrote:
> On 08/11/2015 16:20, mij wrote:
>> If that point has come, let’s party, but please make sure the option is uniformly
>> available on all supported platforms before pulling the trigger.
>
> I believe the only systems using 'ipfw' are FreeBSD and OS X. I'll find
> out when tables were introduced in FreeBSD. New Macs are replacing
> 'ipfw' with 'pf', so they will be using that backend.

'mmm,

Nice question.

I'd say that was when we went from ipfw to ipfw2...
And ipfw has now become ipfw again.

Tables are at least supported in all versions that are not EoL, and the 
full range of 8.x

This is from soem systems I have about:
7.3-STABLE FreeBSD 7.3-STABLE #0: Wed Jun 30 22:15:57 CEST 2010
AND
6.4-PRERELEASE FreeBSD 6.4-PRERELEASE #85: Wed Nov 12 12:46:53 CET 2008

      ipfw table number add addr[/masklen] [value]
      ipfw table number delete addr[/masklen]
      ipfw table {number | all} flush
      ipfw table {number | all} list

So I'd expect just about everybody with IPFW to have tables.
And if not, then their version is so old that they better know what they 
are doing. Because maintaining these systems needs a lot of expertise to 
fix security bugs....

hope that helps,
--WjW

Re: [Sshguard-users] Is sshguard working?

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

I'm running FreeBSD and ipfw. However, I got the impression the documentation needed to be updated.


  Original Message  
From: Kevin Zheng
Sent: Tuesday, August 11, 2015 7:53 PM
To: ssh...@li...
Reply To: ssh...@li...
Subject: Re: [Sshguard-users] Is sshguard working?

On 08/10/2015 14:26, li...@la... wrote:
> Is that rule the only line I need to add to get sshguard locking out
> the bad boys? I've been waiting for the documentation. ‎Not that I'm
> bugging anyone. ;-) I know I'm dealing with volunteers.

It's a hard question to answer because I don't know what version you're
running, or what firewall backend you're using.

For documentation, do people prefer the website, the README, or the man
pages? Ideally all of them would be updated but I'd like to make
something authoritative that is consistently updated.

Thanks,
Kevin Zheng

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

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

Re: [Sshguard-users] Is sshguard working?

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

On 08/11/2015 16:20, mij wrote:
> If that point has come, let’s party, but please make sure the option is uniformly
> available on all supported platforms before pulling the trigger.

I believe the only systems using 'ipfw' are FreeBSD and OS X. I'll find
out when tables were introduced in FreeBSD. New Macs are replacing
'ipfw' with 'pf', so they will be using that backend.

Thanks,
Kevin Zheng

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

Re: [Sshguard-users] Is sshguard working?

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

On 08/10/2015 14:26, li...@la... wrote:
> Is that rule the only line I need to add to get sshguard locking out
> the bad boys? I've been waiting for the documentation. ‎Not that I'm
> bugging anyone. ;-) I know I'm dealing with volunteers.

It's a hard question to answer because I don't know what version you're
running, or what firewall backend you're using.

For documentation, do people prefer the website, the README, or the man
pages? Ideally all of them would be updated but I'd like to make
something authoritative that is consistently updated.

Thanks,
Kevin Zheng

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

Re: [Sshguard-users] Is sshguard working?

[mij <mi...@ss...>]

Hello folks

> I think I like this option the most. This is already what the 'pf'
> backend does. The reason I was considering automatically adding the
> rules was because that's what the original 'ipfw' backend did, but
> seeing that it now uses tables that is no longer necessary.

Correct; as information, the reason why the ipfw and iptables backend were
written to enter individual rules is, neither supported the equivalent of “tables”
at the time of writing.

If that point has come, let’s party, but please make sure the option is uniformly
available on all supported platforms before pulling the trigger.

michele

Re: [Sshguard-users] Is sshguard working?

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

On 08/10/2015 14:58, James Harris wrote:
> This is how the iptables backend works. Sshguard puts all rules into a
> table 'sshguard' it is then left to the user to use that table in the
> correct place. Which as pointed out, is one rule. Personally I like this
> design as it requires a level of interaction and understanding by the
> user. It also means sshguard can run in a completely normal mode of
> operation but not actually block during an evaluation period.

I think I like this option the most. This is already what the 'pf'
backend does. The reason I was considering automatically adding the
rules was because that's what the original 'ipfw' backend did, but
seeing that it now uses tables that is no longer necessary.

Best,
Kevin Zheng

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

Re: [Sshguard-users] Is sshguard working?

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

On 10-8-2015 21:58, James Harris wrote:
> This is how the iptables backend works. Sshguard puts all rules into a
> table 'sshguard' it is then left to the user to use that table in the
> correct place. Which as pointed out, is one rule. Personally I like this
> design as it requires a level of interaction and understanding by the
> user. It also means sshguard can run in a completely normal mode of
> operation but not actually block during an evaluation period.

Well things get even better when we get to 11.0

# ipfw table sshguard add 1.1.1.1
DEPRECATED: inserting data info non-existent table sshguard. (auto-created)
added: 1.1.1.1/32 0

# ipfw table sshguard list
--- table(sshguard), set(0) ---
1.1.1.1/32 0

And thus we do not need to use numbers.
# ipfw add 5000 deny ip from table\(sshguard\) to any
05000 deny ip from table(sshguard) to any
# ipfw list
00100 allow ip from any to any via lo0
00200 deny ip from any to 127.0.0.0/8
00300 deny ip from 127.0.0.0/8 to any
00400 deny ip from any to ::1
00500 deny ip from ::1 to any
00600 allow ipv6-icmp from :: to ff02::/16
00700 allow ipv6-icmp from fe80::/10 to fe80::/10
00800 allow ipv6-icmp from fe80::/10 to ff02::/16
00900 allow ipv6-icmp from any to any ip6 icmp6types 1
01000 allow ipv6-icmp from any to any ip6 icmp6types 2,135,136
05000 deny ip from table(sshguard) to any
65000 allow ip from any to any
65535 deny ip from any to any

--WjW


> On Aug 10, 2015 11:52 AM, "Willem Jan Withagen" <wj...@di...
> <mailto:wj...@di...>> wrote:
> 
>     On 10-8-2015 20:27, Kevin Zheng wrote:
>     > On 08/10/2015 13:04, Willem Jan Withagen wrote:
>     >> 50000 is a very high number, while you would like to lock out bad
>     guys
>     >> as early as possible....
>     >> For me it is like the 6th or 7th rule in the firewall
>     >
>     > Right, the intention is to use a high number so that the rules set by
>     > SSHGuard do not override the users' own rules.
> 
>     That's why I prefer it not to do that automagic.
>     and that is also the advantage of the table....
>     It requires only one rule, which can be loaded at start of the system
>     and at the correct place.
> 
>     sshguard then only needs to deal with the table.
>     Wether the table is empty or not is irelevant for the functioning of the
>     firewall.
> 
>     Having it at a high number and thus implicitly at the end has the FW run
>     a lot of rules against the access of the bad-guy.
> 
>     Now the bad-guy is looking for holes in the system, so the less rules he
>     gets to sample, the beter it is...
> 
>     I posted part of my FW code a few days back.
> 
>     >> I would consider that a real bad design....
>     >> IMHO Stuffing automagical things in a firewall is asking for a lot of
>     >> unexpected trouble...
>     >
>     > I share your concern, but it is partially mitigated by the fact
>     that the
>     > rule number is so high; more likely than not it will not trample
>     on the
>     > users' own rules. There is also precedent: since the 'ipfw'
>     backend was
>     > conceived it has always added firewall rules automatically.
>     >
>     > But I'm open to suggestions on how I can do better.
> 
>     How about a big notice on how to activate it in the regular FW code.
>     Once the user has done that it require very little service until the
>     next OS upgrade, where mergemaster will show the diff, and you need to
>     integrate it again.
>     It also removes the risk of trampeling on user rules.
> 
>     On the other hand:
>             add 2 rules at 2500,
>     and notice that both get executed. One really explicitly needs to remove
>     the lines. But then that would make for a very obvfuscated system.
> 
>     --WjW
> 
>     >
>     > Thanks,
>     > Kevin Zheng
>     >
> 
> 
>     ------------------------------------------------------------------------------
>     _______________________________________________
>     Sshguard-users mailing list
>     Ssh...@li...
>     <mailto: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] Is sshguard working?

[James H. <jam...@gm...>]

This is how the iptables backend works. Sshguard puts all rules into a
table 'sshguard' it is then left to the user to use that table in the
correct place. Which as pointed out, is one rule. Personally I like this
design as it requires a level of interaction and understanding by the user.
It also means sshguard can run in a completely normal mode of operation but
not actually block during an evaluation period.
On Aug 10, 2015 11:52 AM, "Willem Jan Withagen" <wj...@di...> wrote:

> On 10-8-2015 20:27, Kevin Zheng wrote:
> > On 08/10/2015 13:04, Willem Jan Withagen wrote:
> >> 50000 is a very high number, while you would like to lock out bad guys
> >> as early as possible....
> >> For me it is like the 6th or 7th rule in the firewall
> >
> > Right, the intention is to use a high number so that the rules set by
> > SSHGuard do not override the users' own rules.
>
> That's why I prefer it not to do that automagic.
> and that is also the advantage of the table....
> It requires only one rule, which can be loaded at start of the system
> and at the correct place.
>
> sshguard then only needs to deal with the table.
> Wether the table is empty or not is irelevant for the functioning of the
> firewall.
>
> Having it at a high number and thus implicitly at the end has the FW run
> a lot of rules against the access of the bad-guy.
>
> Now the bad-guy is looking for holes in the system, so the less rules he
> gets to sample, the beter it is...
>
> I posted part of my FW code a few days back.
>
> >> I would consider that a real bad design....
> >> IMHO Stuffing automagical things in a firewall is asking for a lot of
> >> unexpected trouble...
> >
> > I share your concern, but it is partially mitigated by the fact that the
> > rule number is so high; more likely than not it will not trample on the
> > users' own rules. There is also precedent: since the 'ipfw' backend was
> > conceived it has always added firewall rules automatically.
> >
> > But I'm open to suggestions on how I can do better.
>
> How about a big notice on how to activate it in the regular FW code.
> Once the user has done that it require very little service until the
> next OS upgrade, where mergemaster will show the diff, and you need to
> integrate it again.
> It also removes the risk of trampeling on user rules.
>
> On the other hand:
>         add 2 rules at 2500,
> and notice that both get executed. One really explicitly needs to remove
> the lines. But then that would make for a very obvfuscated system.
>
> --WjW
>
> >
> > Thanks,
> > Kevin Zheng
> >
>
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Sshguard-users mailing list
> Ssh...@li...
> https://lists.sourceforge.net/lists/listinfo/sshguard-users
>

Re: [Sshguard-users] Is sshguard working?

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

Is that rule the only line I need to add to get sshguard locking out the bad boys? I've been waiting for the documentation. ‎Not that I'm bugging anyone. ;-) I know I'm dealing with volunteers. 

  Original Message  
From: Kevin Zheng
Sent: Monday, August 10, 2015 10:05 AM
To: ssh...@li...
Reply To: ssh...@li...
Subject: Re: [Sshguard-users] Is sshguard working?

Hi Mark,

On 08/10/2015 11:11, Mark Felder wrote:
> Kevin, is this the patch in question?
> 
> https://bitbucket.org/sshguard/sshguard/commits/da561435cc29c22ee3b545b61e76aa318ec8fd0f/raw/

I've attached the patch that fixes 'ipfw' support. You can generate this
yourself by running:

$ git diff v1.6.1 origin/1.6

Most of this diff consists of deletions. You can safely ignore the hunk
that deletes 'src/fwalls/ipfw.c' if you're putting this in ports.

Keep in mind that in order to use this, users will have to add a rule to
their 'ipfw' ruleset that blocks addresses from table 22:

# ipfw add 50000 deny ip from table\(22\) to me

This will likely change in 1.7, where I think I'll have sshguard insert
this rule automatically. Apologies for the trouble here. I don't think
the release plan of backporting bug fixes is working too well; I'm
thinking about making releases at regular intervals from 'master'
instead. But that's a whole different topic.

Thanks,
Kevin Zheng

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

Re: [Sshguard-users] Is sshguard working?

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

On 10-8-2015 20:27, Kevin Zheng wrote:
> On 08/10/2015 13:04, Willem Jan Withagen wrote:
>> 50000 is a very high number, while you would like to lock out bad guys
>> as early as possible....
>> For me it is like the 6th or 7th rule in the firewall
> 
> Right, the intention is to use a high number so that the rules set by
> SSHGuard do not override the users' own rules.

That's why I prefer it not to do that automagic.
and that is also the advantage of the table....
It requires only one rule, which can be loaded at start of the system
and at the correct place.

sshguard then only needs to deal with the table.
Wether the table is empty or not is irelevant for the functioning of the
firewall.

Having it at a high number and thus implicitly at the end has the FW run
a lot of rules against the access of the bad-guy.

Now the bad-guy is looking for holes in the system, so the less rules he
gets to sample, the beter it is...

I posted part of my FW code a few days back.

>> I would consider that a real bad design....
>> IMHO Stuffing automagical things in a firewall is asking for a lot of
>> unexpected trouble...
> 
> I share your concern, but it is partially mitigated by the fact that the
> rule number is so high; more likely than not it will not trample on the
> users' own rules. There is also precedent: since the 'ipfw' backend was
> conceived it has always added firewall rules automatically.
> 
> But I'm open to suggestions on how I can do better.

How about a big notice on how to activate it in the regular FW code.
Once the user has done that it require very little service until the
next OS upgrade, where mergemaster will show the diff, and you need to
integrate it again.
It also removes the risk of trampeling on user rules.

On the other hand:
	add 2 rules at 2500,
and notice that both get executed. One really explicitly needs to remove
the lines. But then that would make for a very obvfuscated system.

--WjW

> 
> Thanks,
> Kevin Zheng
> 

Re: [Sshguard-users] Is sshguard working?

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

On 10-8-2015 20:36, Mark Felder wrote:
> 
> 
> On Mon, Aug 10, 2015, at 13:32, Willem Jan Withagen wrote:
>> On 10-8-2015 20:28, Mark Felder wrote:
>>>
>>>
>>> On Mon, Aug 10, 2015, at 12:05, Kevin Zheng wrote:
>>>> Hi Mark,
>>>>
>>>> On 08/10/2015 11:11, Mark Felder wrote:
>>>>> Kevin, is this the patch in question?
>>>>>
>>>>> https://bitbucket.org/sshguard/sshguard/commits/da561435cc29c22ee3b545b61e76aa318ec8fd0f/raw/
>>>>
>>>> I've attached the patch that fixes 'ipfw' support. You can generate this
>>>> yourself by running:
>>>>
>>>> $ git diff v1.6.1 origin/1.6
>>>>
>>>> Most of this diff consists of deletions. You can safely ignore the hunk
>>>> that deletes 'src/fwalls/ipfw.c' if you're putting this in ports.
>>>>
>>>
>>> Do I understand the important parts of the patch correctly?
>>>
>>> 1) configure.ac copying command_ipfw.h to command.h
>>> 2) creation of src/fwalls/command_ipfw.h
>>>
>>>
>>> If so, I can easily fix the FreeBSD port if ipfw support is broken.
>>
>> One of the things I was looking at, is check if the type selection could
>> be done thru 'make config'.
>> That would make it just one port with many faces...
>> Haven't gotten around to it, but I expect it not to be rocket science.
>>
> 
> This is intentionally not wanted because the "default" option is the
> only thing that would be available on the public package mirrors. With
> the current port having master and slave ports all of the backends of
> sshguard are built into packages ready for installation by the end user.
> 
> This can all go away once FreeBSD and pkgng have deployed support for
> subpackages & flavors.

Oke, makes sense...

--WjW

Re: [Sshguard-users] Is sshguard working?

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

On Mon, Aug 10, 2015, at 13:32, Willem Jan Withagen wrote:
> On 10-8-2015 20:28, Mark Felder wrote:
> > 
> > 
> > On Mon, Aug 10, 2015, at 12:05, Kevin Zheng wrote:
> >> Hi Mark,
> >>
> >> On 08/10/2015 11:11, Mark Felder wrote:
> >>> Kevin, is this the patch in question?
> >>>
> >>> https://bitbucket.org/sshguard/sshguard/commits/da561435cc29c22ee3b545b61e76aa318ec8fd0f/raw/
> >>
> >> I've attached the patch that fixes 'ipfw' support. You can generate this
> >> yourself by running:
> >>
> >> $ git diff v1.6.1 origin/1.6
> >>
> >> Most of this diff consists of deletions. You can safely ignore the hunk
> >> that deletes 'src/fwalls/ipfw.c' if you're putting this in ports.
> >>
> > 
> > Do I understand the important parts of the patch correctly?
> > 
> > 1) configure.ac copying command_ipfw.h to command.h
> > 2) creation of src/fwalls/command_ipfw.h
> > 
> > 
> > If so, I can easily fix the FreeBSD port if ipfw support is broken.
> 
> One of the things I was looking at, is check if the type selection could
> be done thru 'make config'.
> That would make it just one port with many faces...
> Haven't gotten around to it, but I expect it not to be rocket science.
> 

This is intentionally not wanted because the "default" option is the
only thing that would be available on the public package mirrors. With
the current port having master and slave ports all of the backends of
sshguard are built into packages ready for installation by the end user.

This can all go away once FreeBSD and pkgng have deployed support for
subpackages & flavors.

Re: [Sshguard-users] Is sshguard working?

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

On 08/10/2015 13:32, Willem Jan Withagen wrote:
> One of the things I was looking at, is check if the type selection could
> be done thru 'make config'.
> That would make it just one port with many faces...
> Haven't gotten around to it, but I expect it not to be rocket science.

It would be harder to build binary packages that way. OpenBSD does it
nicely with 'flavors'; FreeBSD's equivalent are slave ports.

Best,
Kevin Zheng

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