sshguard-users

Re: [Sshguard-users] Is sshguard working?

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

On 10-8-2015 19: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.
> 
> 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

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

> This will likely change in 1.7, where I think I'll have sshguard insert
> this rule automatically. 

I would consider that a real bad design....
IMHO Stuffing automagical things in a firewall is asking for a lot of
unexpected trouble...

--WjW

Re: [Sshguard-users] Is sshguard working?

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

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.

> 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.

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?

[<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?

[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?

[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?

[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?

[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: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?

[<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 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?

[<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/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 added:
{fwcmd} add reset ip from 'table(22)' to me

When I restart the firewall, I get
/etc/rc.firewall: add: not found

Is this a syntax issue, or is the table not created?


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

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

------------------------------------------------------------------------------
_______________________________________________
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/20/2015 20:46, li...@la... wrote:
> I added:
> {fwcmd} add reset ip from 'table(22)' to me

{fwcmd} must be prefixed with a '$' because it is a shell variable:

${fwcmd} add 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...>]

Yeah, I had the $ in the actual file, it just didn't make it to the email. ( I've noticed failing to match curly brackets locks up my VPS, but that is another story.) 

So basically I had entered what you suggested. Who creates this table?

  Original Message  
From: Kevin Zheng
Sent: Thursday, August 20, 2015 6:51 PM
To: ssh...@li...
Reply To: ssh...@li...
Subject: Re: [Sshguard-users] Is sshguard working?

On 08/20/2015 20:46, li...@la... wrote:
> I added:
> {fwcmd} add reset ip from 'table(22)' to me

{fwcmd} must be prefixed with a '$' because it is a shell variable:

${fwcmd} add reset ip from 'table(22)' to me

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

Re: [Sshguard-users] Is sshguard working?

[SASAKI K. <cr...@sa...>]

How is next commnd ?
% sudo ipfw table 22 list

On my FreeBSD 10.1, it looks fine.

On Thu, 20 Aug 2015 19:19:39 -0700
li...@la... wrote:

> Yeah, I had the $ in the actual file, it just didn't make it to the email. ( I've noticed failing to match curly brackets locks up my VPS, but that is another story.) 
> 
> So basically I had entered what you suggested. Who creates this table?
> 
Tables are automatically created. And we can use there.
>From my /etc/rc.ipfw script.
> ...
> # Allow "mandatory" ICMP/ICMP6 in.
> ${fwcmd} add pass icmp from any to any icmptypes 3,4,11 keep-state
> if [ $ipv6_available -eq 0 ]; then
>         ${fwcmd} add pass ipv6-icmp from any to any icmp6type 3 keep-state
> fi
> 
> # New sshguard uses table.
> ${fwcmd} add deny log all from "table(22)" to any
> 
> # Allow packets for which a state has been built.
> ${fwcmd} add check-state
> ...
These rules works fine.


-- 
                     SASAKI Katuhiro

                 mailto: cr...@sa...

Re: [Sshguard-users] Is sshguard working?

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

‎I cut the table down a bit and I also logged some of the blocking notices. It looks like the offending IPs do enter the table, but the blocking is not occurring, probably due to the "reset" line not being parsed.

I'm assuming table(22) is linked to port 22, hence ssh.

# ipfw table 22 list
1.93.23.118/32 0
1.233.92.197/32 0
5.56.59.73/32 0
5.196.76.172/32 0
12.237.115.7/32 0
23.94.30.10/32 0
23.101.27.189/32 0
24.97.197.131/32 0
87.106.187.166/32 0
87.106.217.214/32 0
87.230.86.157/32 0
89.248.171.19/32 0
91.236.74.6/32 0
93.174.93.63/32 0
93.174.93.129/32 0
93.174.93.146/32 0
94.102.49.33/32 0
94.102.49.197/32 0
180.211.164.131/32 0
182.74.190.170/32 0
182.100.67.4/32 0
182.100.67.52/32 0
182.100.67.59/32 0
182.100.67.113/32 0
183.56.131.43/32 0
183.195.251.112/32 0
185.11.165.178/32 0
218.65.30.23/32 0
218.65.30.38/32 0
218.65.30.61/32 0
218.65.30.73/32 0
218.65.30.92/32 0
218.65.30.217/32 0
218.87.109.60/32 0
218.87.109.62/32 0
218.87.111.71/32 0
218.87.111.107/32 0
218.87.111.108/32 0
218.87.111.109/32 0
218.87.111.110/32 0
218.87.111.116/32 0
218.87.111.117/32 0
218.94.94.86/32 0
219.144.162.174/32 0
219.235.1.84/32 0
220.178.7.181/32 0


Aug 21 07:08:05 theranch sshguard[808]: blacklist: added 93.174.93.63
Aug 21 07:08:05 theranch sshguard[808]: Blocking 93.174.93.63:4 for
>0secs: 40 danger in 4 attacks over 1 seconds (all: 40d in 1 abuses

Aug 21 04:19:02 theranch sshguard[808]: blacklist: 218.65.30.61 is already blacklisted
Aug 21 04:19:02 theranch sshguard[808]: Blocking 218.65.30.61:4 for >0secs: 40 danger in 3 attacks over 1 seconds (all: 40d in 1 abuses over 1s).
Aug 21 04:19:02 theranch sshguard[808]: Blocking command failed. Exited: -1

Aug 21 02:11:16 theranch sshguard[808]: blacklist: 182.100.67.113 is already blacklisted
Aug 21 02:11:16 theranch sshguard[808]: Blocking 182.100.67.113:4 for >0secs: 40 danger in 3 attacks over 2 seconds (all: 40d in 1 abuses over 2s).
Aug 21 02:11:16 theranch sshguard[808]: Blocking command failed. Exited: -1

  Original Message  
From: SASAKI Katuhiro
Sent: Thursday, August 20, 2015 8:39 PM
To: ssh...@li...
Reply To: ssh...@li...
Subject: Re: [Sshguard-users] Is sshguard working?

How is next commnd ?
% sudo ipfw table 22 list

On my FreeBSD 10.1, it looks fine.

On Thu, 20 Aug 2015 19:19:39 -0700
li...@la... wrote:

> Yeah, I had the $ in the actual file, it just didn't make it to the email. ( I've noticed failing to match curly brackets locks up my VPS, but that is another story.) 
> 
> So basically I had entered what you suggested. Who creates this table?
> 
Tables are automatically created. And we can use there.
>From my /etc/rc.ipfw script.
> ...
> # Allow "mandatory" ICMP/ICMP6 in.
> ${fwcmd} add pass icmp from any to any icmptypes 3,4,11 keep-state
> if [ $ipv6_available -eq 0 ]; then
> ${fwcmd} add pass ipv6-icmp from any to any icmp6type 3 keep-state
> fi
> 
> # New sshguard uses table.
> ${fwcmd} add deny log all from "table(22)" to any
> 
> # Allow packets for which a state has been built.
> ${fwcmd} add check-state
> ...
These rules works fine.


-- 
SASAKI Katuhiro

mailto: cr...@sa...

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?

[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 21-8-2015 10:11, li...@la... wrote:
> ‎I cut the table down a bit and I also logged some of the blocking notices. It looks like the offending IPs do enter the table, but the blocking is not occurring, probably due to the "reset" line not being parsed.
>
> I'm assuming table(22) is linked to port 22, hence ssh.

Hi,

It is actually my suggestion long, long ago.
And indeed it suggests the reasons why an IP got blocked.
and indeed 22 = ssh, is ssh-bad-guys.

if you type ípfw list' you should see your reset somewhere.
Put if you just type:
	${fwcmd} add deny log all from "table(22)" to any
on the commandline, the rules gets added at the END of the FW-rules.
And there it does not do anything....

You needs to select a sensible place in the order of the rules, and 
insert it at the right place by going:
	${fwcmd} add <RULENR> deny log all from "table(22)" to any

If you do that in the /etc/rc.firewall file, then sequencing gets done 
automagically.
	
--WjW


> # ipfw table 22 list
> 1.93.23.118/32 0
> 1.233.92.197/32 0
> 5.56.59.73/32 0
> 5.196.76.172/32 0
> 12.237.115.7/32 0
> 23.94.30.10/32 0
> 23.101.27.189/32 0
> 24.97.197.131/32 0
> 87.106.187.166/32 0
> 87.106.217.214/32 0
> 87.230.86.157/32 0
> 89.248.171.19/32 0
> 91.236.74.6/32 0
> 93.174.93.63/32 0
> 93.174.93.129/32 0
> 93.174.93.146/32 0
> 94.102.49.33/32 0
> 94.102.49.197/32 0
> 180.211.164.131/32 0
> 182.74.190.170/32 0
> 182.100.67.4/32 0
> 182.100.67.52/32 0
> 182.100.67.59/32 0
> 182.100.67.113/32 0
> 183.56.131.43/32 0
> 183.195.251.112/32 0
> 185.11.165.178/32 0
> 218.65.30.23/32 0
> 218.65.30.38/32 0
> 218.65.30.61/32 0
> 218.65.30.73/32 0
> 218.65.30.92/32 0
> 218.65.30.217/32 0
> 218.87.109.60/32 0
> 218.87.109.62/32 0
> 218.87.111.71/32 0
> 218.87.111.107/32 0
> 218.87.111.108/32 0
> 218.87.111.109/32 0
> 218.87.111.110/32 0
> 218.87.111.116/32 0
> 218.87.111.117/32 0
> 218.94.94.86/32 0
> 219.144.162.174/32 0
> 219.235.1.84/32 0
> 220.178.7.181/32 0
>
>
> Aug 21 07:08:05 theranch sshguard[808]: blacklist: added 93.174.93.63
> Aug 21 07:08:05 theranch sshguard[808]: Blocking 93.174.93.63:4 for
>> 0secs: 40 danger in 4 attacks over 1 seconds (all: 40d in 1 abuses
>
> Aug 21 04:19:02 theranch sshguard[808]: blacklist: 218.65.30.61 is already blacklisted
> Aug 21 04:19:02 theranch sshguard[808]: Blocking 218.65.30.61:4 for >0secs: 40 danger in 3 attacks over 1 seconds (all: 40d in 1 abuses over 1s).
> Aug 21 04:19:02 theranch sshguard[808]: Blocking command failed. Exited: -1
>
> Aug 21 02:11:16 theranch sshguard[808]: blacklist: 182.100.67.113 is already blacklisted
> Aug 21 02:11:16 theranch sshguard[808]: Blocking 182.100.67.113:4 for >0secs: 40 danger in 3 attacks over 2 seconds (all: 40d in 1 abuses over 2s).
> Aug 21 02:11:16 theranch sshguard[808]: Blocking command failed. Exited: -1
>
>    Original Message
> From: SASAKI Katuhiro
> Sent: Thursday, August 20, 2015 8:39 PM
> To: ssh...@li...
> Reply To: ssh...@li...
> Subject: Re: [Sshguard-users] Is sshguard working?
>
> How is next commnd ?
> % sudo ipfw table 22 list
>
> On my FreeBSD 10.1, it looks fine.
>
> On Thu, 20 Aug 2015 19:19:39 -0700
> li...@la... wrote:
>
>> Yeah, I had the $ in the actual file, it just didn't make it to the email. ( I've noticed failing to match curly brackets locks up my VPS, but that is another story.)
>>
>> So basically I had entered what you suggested. Who creates this table?
>>
> Tables are automatically created. And we can use there.
>>From my /etc/rc.ipfw script.
>> ...
>> # Allow "mandatory" ICMP/ICMP6 in.
>> ${fwcmd} add pass icmp from any to any icmptypes 3,4,11 keep-state
>> if [ $ipv6_available -eq 0 ]; then
>> ${fwcmd} add pass ipv6-icmp from any to any icmp6type 3 keep-state
>> fi
>>
>> # New sshguard uses table.
>> ${fwcmd} add deny log all from "table(22)" to any
>>
>> # Allow packets for which a state has been built.
>> ${fwcmd} add check-state
>> ...
> These rules works fine.
>
>

Re: [Sshguard-users] Is sshguard working?

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

I think I understand how the rule-number works. Doing the ipfw list, unless a number is specified, all the denies are at the end. That is where my new rule is at the moment. 

How about if I made the new rule be number 2450? 

# 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
01100 check-state
01200 allow tcp from me to any established
01300 allow tcp from me to any setup keep-state
01400 allow udp from me to any keep-state
01500 allow icmp from me to any keep-state
01600 allow ipv6-icmp from me to any keep-state
01700 allow udp from 0.0.0.0 68 to 255.255.255.255 dst-port 67 out
01800 allow udp from any 67 to me dst-port 68 in
01900 allow udp from any 67 to 255.255.255.255 dst-port 68 in
02000 allow udp from fe80::/10 to me dst-port 546 in
02100 allow icmp from any to any icmptypes 8
02200 allow ipv6-icmp from any to any ip6 icmp6types 128,129
02300 allow icmp from any to any icmptypes 3,4,11
02400 allow ipv6-icmp from any to any ip6 icmp6types 3
02500 allow tcp from any to me dst-port 22
02600 allow tcp from any to me dst-port 25
02700 allow tcp from any to me dst-port 80
02800 allow tcp from any to me dst-port 143
02900 allow tcp from any to me dst-port 443
03000 allow tcp from any to me dst-port 465
03100 allow tcp from any to me dst-port 500
03200 allow tcp from any to me dst-port 993
03300 allow tcp from any to me dst-port 4500
03400 allow tcp from any to me dst-port 110 in setup
03500 allow tcp from any to me dst-port 995 in setup
03600 allow tcp from any to me dst-port 25 in setup
03700 allow tcp from me to any dst-port 25 out setup
03800 allow tcp from any to me dst-port 465 in setup
03900 allow tcp from any to me dst-port 143 in setup
04000 allow tcp from any to me dst-port 993 in setup
65000 count ip from any to any
65100 allow log udp from any to any dst-port 500 keep-state
65200 allow log udp from any 500 to any keep-state
65300 allow log udp from any to any dst-port 4500 keep-state
65400 allow log udp from any 4500 to any keep-state
65500 deny log ip from table(22) to any
65500 deny { tcp or udp } from any to any dst-port 135-139,445 in
65500 deny { tcp or udp } from any to any dst-port 1026,1027 in
65500 deny { tcp or udp } from any to any dst-port 1433,1434 in
65500 deny ip from any to 255.255.255.255
65500 deny ip from any to 224.0.0.0/24 in
65500 deny udp from any to any dst-port 520 in
65500 deny tcp from any 80,443 to any dst-port 1024-65535 in
65500 deny log logamount 500 ip from any to any
65535 deny ip from any to any‎

‎

  Original Message  
From: Willem Jan Withagen
Sent: Friday, August 21, 2015 2:57 AM
To: ssh...@li...
Reply To: ssh...@li...
Subject: Re: [Sshguard-users] Is sshguard working?

On 21-8-2015 10:11, li...@la... wrote:
> ‎I cut the table down a bit and I also logged some of the blocking notices. It looks like the offending IPs do enter the table, but the blocking is not occurring, probably due to the "reset" line not being parsed.
>
> I'm assuming table(22) is linked to port 22, hence ssh.

Hi,

It is actually my suggestion long, long ago.
And indeed it suggests the reasons why an IP got blocked.
and indeed 22 = ssh, is ssh-bad-guys.

if you type ípfw list' you should see your reset somewhere.
Put if you just type:
${fwcmd} add deny log all from "table(22)" to any
on the commandline, the rules gets added at the END of the FW-rules.
And there it does not do anything....

You needs to select a sensible place in the order of the rules, and 
insert it at the right place by going:
${fwcmd} add <RULENR> deny log all from "table(22)" to any

If you do that in the /etc/rc.firewall file, then sequencing gets done 
automagically.

--WjW

‎

Re: [Sshguard-users] Is sshguard working?

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

On 22-8-2015 06:53, li...@la... wrote:
> I think I understand how the rule-number works. Doing the ipfw list, unless a number is specified, all the denies are at the end. That is where my new rule is at the moment. 

That will work.
BUT why not much sooner, like on after rule 500?
The sooner the better.

It kills the icmp to those hosts, but then they are bad-guys.
And by putting the rule on 2450, you will allow traffic from your host
the setup a connection to a bad host. I would not want that either.

By denying before any check-state, keep=state, established a connection
will never be able to work.

That is why I have them very early in my list.

--WjW


> How about if I made the new rule be number 2450? 
> 
> # 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
> 01100 check-state
> 01200 allow tcp from me to any established
> 01300 allow tcp from me to any setup keep-state
> 01400 allow udp from me to any keep-state
> 01500 allow icmp from me to any keep-state
> 01600 allow ipv6-icmp from me to any keep-state
> 01700 allow udp from 0.0.0.0 68 to 255.255.255.255 dst-port 67 out
> 01800 allow udp from any 67 to me dst-port 68 in
> 01900 allow udp from any 67 to 255.255.255.255 dst-port 68 in
> 02000 allow udp from fe80::/10 to me dst-port 546 in
> 02100 allow icmp from any to any icmptypes 8
> 02200 allow ipv6-icmp from any to any ip6 icmp6types 128,129
> 02300 allow icmp from any to any icmptypes 3,4,11
> 02400 allow ipv6-icmp from any to any ip6 icmp6types 3
> 02500 allow tcp from any to me dst-port 22
> 02600 allow tcp from any to me dst-port 25
> 02700 allow tcp from any to me dst-port 80
> 02800 allow tcp from any to me dst-port 143
> 02900 allow tcp from any to me dst-port 443
> 03000 allow tcp from any to me dst-port 465
> 03100 allow tcp from any to me dst-port 500
> 03200 allow tcp from any to me dst-port 993
> 03300 allow tcp from any to me dst-port 4500
> 03400 allow tcp from any to me dst-port 110 in setup
> 03500 allow tcp from any to me dst-port 995 in setup
> 03600 allow tcp from any to me dst-port 25 in setup
> 03700 allow tcp from me to any dst-port 25 out setup
> 03800 allow tcp from any to me dst-port 465 in setup
> 03900 allow tcp from any to me dst-port 143 in setup
> 04000 allow tcp from any to me dst-port 993 in setup
> 65000 count ip from any to any
> 65100 allow log udp from any to any dst-port 500 keep-state
> 65200 allow log udp from any 500 to any keep-state
> 65300 allow log udp from any to any dst-port 4500 keep-state
> 65400 allow log udp from any 4500 to any keep-state
> 65500 deny log ip from table(22) to any
> 65500 deny { tcp or udp } from any to any dst-port 135-139,445 in
> 65500 deny { tcp or udp } from any to any dst-port 1026,1027 in
> 65500 deny { tcp or udp } from any to any dst-port 1433,1434 in
> 65500 deny ip from any to 255.255.255.255
> 65500 deny ip from any to 224.0.0.0/24 in
> 65500 deny udp from any to any dst-port 520 in
> 65500 deny tcp from any 80,443 to any dst-port 1024-65535 in
> 65500 deny log logamount 500 ip from any to any
> 65535 deny ip from any to any‎
> 
> ‎
> 
>   Original Message  
> From: Willem Jan Withagen
> Sent: Friday, August 21, 2015 2:57 AM
> To: ssh...@li...
> Reply To: ssh...@li...
> Subject: Re: [Sshguard-users] Is sshguard working?
> 
> On 21-8-2015 10:11, li...@la... wrote:
>> ‎I cut the table down a bit and I also logged some of the blocking notices. It looks like the offending IPs do enter the table, but the blocking is not occurring, probably due to the "reset" line not being parsed.
>>
>> I'm assuming table(22) is linked to port 22, hence ssh.
> 
> Hi,
> 
> It is actually my suggestion long, long ago.
> And indeed it suggests the reasons why an IP got blocked.
> and indeed 22 = ssh, is ssh-bad-guys.
> 
> if you type ípfw list' you should see your reset somewhere.
> Put if you just type:
> ${fwcmd} add deny log all from "table(22)" to any
> on the commandline, the rules gets added at the END of the FW-rules.
> And there it does not do anything....
> 
> You needs to select a sensible place in the order of the rules, and 
> insert it at the right place by going:
> ${fwcmd} add <RULENR> deny log all from "table(22)" to any
> 
> If you do that in the /etc/rc.firewall file, then sequencing gets done 
> automagically.
> 
> --WjW
> 
> ‎
> 
> ------------------------------------------------------------------------------
> _______________________________________________
> Sshguard-users mailing list
> Ssh...@li...
> https://lists.sourceforge.net/lists/listinfo/sshguard-users
> 

Re: [Sshguard-users] Is sshguard working?

[SASAKI K. <cr...@sa...>]

Hi.

On Fri, 21 Aug 2015 21:53:35 -0700
li...@la... wrote:

> I think I understand how the rule-number works. Doing the ipfw list, unless a number is specified, all the denies are at the end. That is where my new rule is at the moment. 
> 
> How about if I made the new rule be number 2450? 
> 
> # ipfw list
> 00100 allow ip from any to any via lo0
> 00200 deny ip from any to 127.0.0.0/8
...
> 01000 allow ipv6-icmp from any to any ip6 icmp6types 2,135,136
> 01100 check-state
> 01200 allow tcp from me to any established
> 01300 allow tcp from me to any setup keep-state
...
> 02500 allow tcp from any to me dst-port 22
> 02600 allow tcp from any to me dst-port 25
> 02700 allow tcp from any to me dst-port 80
> 02800 allow tcp from any to me dst-port 143
> 02900 allow tcp from any to me dst-port 443
> 03000 allow tcp from any to me dst-port 465
> 03100 allow tcp from any to me dst-port 500
> 03200 allow tcp from any to me dst-port 993
> 03300 allow tcp from any to me dst-port 4500
> 03400 allow tcp from any to me dst-port 110 in setup
> 03500 allow tcp from any to me dst-port 995 in setup
> 03600 allow tcp from any to me dst-port 25 in setup
> 03700 allow tcp from me to any dst-port 25 out setup
> 03800 allow tcp from any to me dst-port 465 in setup
> 03900 allow tcp from any to me dst-port 143 in setup
> 04000 allow tcp from any to me dst-port 993 in setup
> 65000 count ip from any to any
> 65100 allow log udp from any to any dst-port 500 keep-state
> 65200 allow log udp from any 500 to any keep-state
> 65300 allow log udp from any to any dst-port 4500 keep-state
> 65400 allow log udp from any 4500 to any keep-state
> 65500 deny log ip from table(22) to any
> 65500 deny { tcp or udp } from any to any dst-port 135-139,445 in
...

IPFW is an packet filtering system that is referred to as “first match
wins". So, incoming ssh packet that is permitted by rule 2500 does not
reach rule 65500 denying rule.
Inserting a rule that blocks IP-addresses listed in table 22 between
rule 1000 and rule 1100 seems better for me.


-- 
                     SASAKI Katuhiro

                 mailto: cr...@sa...

Re: [Sshguard-users] Is sshguard working?

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

I put the rule at 550. However, I'm not sure it is blocking properly, or this particular attack is something sshguard does not block.



‎Aug 22 18:41:37 theranch sshd[75277]: Did not receive identification string from 106.37.194.226
Aug 22 18:46:57 theranch sshd[75300]: reverse mapping checking getaddrinfo for 226.194.37.106.static.bjtelecom.net [106.37.194.226] failed - POSSIBLE BREAK-IN ATTEMPT!
Aug 22 18:46:58 theranch sshd[75300]: Received disconnect from 106.37.194.226: 11: Bye Bye [preauth]
Aug 22 18:52:31 theranch sshd[75309]: reverse mapping checking getaddrinfo for 226.194.37.106.static.bjtelecom.net [106.37.194.226] failed - POSSIBLE BREAK-IN ATTEMPT!
Aug 22 18:52:31 theranch sshd[75309]: Invalid user ghost from 106.37.194.226
Aug 22 18:52:31 theranch sshd[75309]: input_userauth_request: invalid user ghost [preauth]
Aug 22 18:52:31 theranch sshd[75309]: Received disconnect from 106.37.194.226: 11: Bye Bye [preauth]
Aug 22 18:52:31 theranch sshguard[808]: blacklist: added 106.37.194.226
Aug 22 18:52:31 theranch sshguard[808]: Blocking 106.37.194.226:4 for >0secs: 40 danger in 4 attacks over 653 seconds (all: 40d in 1 abuses over 653s).
Aug 22 18:56:54 theranch sshd[75332]: Received disconnect from 43.229.53.69: 11:  [preauth]
Aug 22 18:58:25 theranch sshd[75335]: reverse mapping checking getaddrinfo for 226.194.37.106.static.bjtelecom.net [106.37.194.226] failed - POSSIBLE BREAK-IN ATTEMPT!
Aug 22 18:58:25 theranch sshd[75335]: Invalid user admin from 106.37.194.226
Aug 22 18:58:25 theranch sshd[75335]: input_userauth_request: invalid user admin [preauth]
Aug 22 18:58:25 theranch sshd[75335]: Received disconnect from 106.37.194.226: 11: Bye Bye [preauth]
Aug 22 19:14:59 theranch sshd[75391]: Invalid user chocolate from 121.12.125.23
Aug 22 19:14:59 theranch sshd[75391]: input_userauth_request: invalid user chocolate [preauth]
Aug 22 19:15:00 theranch sshd[75391]: Connection closed by 121.12.125.23 [preauth]
Aug 22 19:15:47 theranch sshd[75396]: reverse mapping checking getaddrinfo for 226.194.37.106.static.bjtelecom.net [106.37.194.226] failed - POSSIBLE BREAK-IN ATTEMPT!
Aug 22 19:15:47 theranch sshd[75396]: Invalid user deploy from 106.37.194.226
Aug 22 19:15:47 theranch sshd[75396]: input_userauth_request: invalid user deploy [preauth]
Aug 22 19:15:47 theranch sshd[75396]: Received disconnect from 106.37.194.226: 11: Bye Bye [preauth]
Aug 22 19:21:06 theranch sshd[75405]: reverse mapping checking getaddrinfo for 226.194.37.106.static.bjtelecom.net [106.37.194.226] failed - POSSIBLE BREAK-IN ATTEMPT!
Aug 22 19:21:06 theranch sshd[75405]: Invalid user git from 106.37.194.226
Aug 22 19:21:06 theranch sshd[75405]: input_userauth_request: invalid user git [preauth]
Aug 22 19:21:07 theranch sshd[75405]: Received disconnect from 106.37.194.226: 11: Bye Bye [preauth]
Aug 22 19:26:28 theranch sshd[75426]: reverse mapping checking getaddrinfo for 226.194.37.106.static.bjtelecom.net [106.37.194.226] failed - POSSIBLE BREAK-IN ATTEMPT!
Aug 22 19:26:28 theranch sshd[75426]: Invalid user git from 106.37.194.226
Aug 22 19:26:28 theranch sshd[75426]: input_userauth_request: invalid user git [preauth]
Aug 22 19:26:28 theranch sshd[75426]: Received disconnect from 106.37.194.226: 11: Bye Bye [preauth]
Aug 22 19:31:48 theranch sshd[75437]: reverse mapping checking getaddrinfo for 226.194.37.106.static.bjtelecom.net [106.37.194.226] failed - POSSIBLE BREAK-IN ATTEMPT!
Aug 22 19:31:48 theranch sshd[75437]: Invalid user oracle from 106.37.194.226
Aug 22 19:31:48 theranch sshd[75437]: input_userauth_request: invalid user oracle [preauth]
Aug 22 19:31:48 theranch sshd[75437]: Received disconnect from 106.37.194.226: 11: Bye Bye [preauth]
Aug 22 19:37:07 theranch sshd[75459]: reverse mapping checking getaddrinfo for 226.194.37.106.static.bjtelecom.net [106.37.194.226] failed - POSSIBLE BREAK-IN ATTEMPT!
Aug 22 19:37:07 theranch sshd[75459]: Invalid user test from 106.37.194.226
Aug 22 19:37:07 theranch sshd[75459]: input_userauth_request: invalid user test [preauth]
Aug 22 19:37:07 theranch sshd[75459]: Received disconnect from 106.37.194.226: 11: Bye Bye [preauth]
Aug 22 19:42:23 theranch sshd[75468]: reverse mapping checking getaddrinfo for 226.194.37.106.static.bjtelecom.net [106.37.194.226] failed - POSSIBLE BREAK-IN ATTEMPT!
Aug 22 19:42:23 theranch sshd[75468]: Invalid user tomcat from 106.37.194.226
Aug 22 19:42:23 theranch sshd[75468]: input_userauth_request: invalid user tomcat [preauth]
Aug 22 19:42:23 theranch sshd[75468]: Received disconnect from 106.37.194.226: 11: Bye Bye [preauth]
Aug 22 19:49:33 theranch sshd[75494]: Received disconnect from 43.229.53.69: 11:  [preauth]
Aug 22 19:50:48 theranch sshd[75500]: Did not receive identification string from 125.122.221.95
Aug 22 19:54:04 theranch sshd[75504]: reverse mapping checking getaddrinfo for 226.194.37.106.static.bjtelecom.net [106.37.194.226] failed - POSSIBLE BREAK-IN ATTEMPT!
Aug 22 19:54:04 theranch sshd[75504]: Invalid user tomcat from 106.37.194.226
Aug 22 19:54:04 theranch sshd[75504]: input_userauth_request: invalid user tomcat [preauth]
Aug 22 19:54:04 theranch sshd[75504]: Received disconnect from 106.37.194.226: 11: Bye Bye [preauth]
Aug 22 19:57:18 theranch sshd[75524]: Received disconnect from 222.186.21.225: 11:  [preauth]
Aug 22 19:59:37 theranch sshd[75528]: reverse mapping checking getaddrinfo for 226.194.37.106.static.bjtelecom.net [106.37.194.226] failed - POSSIBLE BREAK-IN ATTEMPT!
Aug 22 19:59:37 theranch sshd[75528]: Invalid user tomcat4 from 106.37.194.226
Aug 22 19:59:37 theranch sshd[75528]: input_userauth_request: invalid user tomcat4 [preauth]
Aug 22 19:59:37 theranch sshd[75528]: Received disconnect from 106.37.194.226: 11: Bye Bye [preauth]
Aug 22 20:02:32 theranch sshd[75550]: Did not receive identification string from 14.159.103.107
Aug 22 20:04:47 theranch sshd[75554]: reverse mapping checking getaddrinfo for 226.194.37.106.static.bjtelecom.net [106.37.194.226] failed - POSSIBLE BREAK-IN ATTEMPT!
Aug 22 20:04:47 theranch sshd[75554]: Invalid user postgres from 106.37.194.226
Aug 22 20:04:47 theranch sshd[75554]: input_userauth_request: invalid user postgres [preauth]
Aug 22 20:04:48 theranch sshd[75554]: Received disconnect from 106.37.194.226: 11: Bye Bye [preauth]
Aug 22 20:10:07 theranch sshd[75565]: reverse mapping checking getaddrinfo for 226.194.37.106.static.bjtelecom.net [106.37.194.226] failed - POSSIBLE BREAK-IN ATTEMPT!
Aug 22 20:10:07 theranch sshd[75565]: Invalid user postgres from 106.37.194.226
Aug 22 20:10:07 theranch sshd[75565]: input_userauth_request: invalid user postgres [preauth]
Aug 22 20:10:07 theranch sshd[75565]: Received disconnect from 106.37.194.226: 11: Bye Bye [preauth]
Aug 22 20:15:23 theranch sshd[75586]: reverse mapping checking getaddrinfo for 226.194.37.106.static.bjtelecom.net [106.37.194.226] failed - POSSIBLE BREAK-IN ATTEMPT!
Aug 22 20:15:23 theranch sshd[75586]: Invalid user offline from 106.37.194.226
Aug 22 20:15:23 theranch sshd[75586]: input_userauth_request: invalid user offline [preauth]
Aug 22 20:15:23 theranch sshd[75586]: Received disconnect from 106.37.194.226: 11: Bye Bye [preauth]
Aug 22 20:20:37 theranch sshd[75598]: reverse mapping checking getaddrinfo for 226.194.37.106.static.bjtelecom.net [106.37.194.226] failed - POSSIBLE BREAK-IN ATTEMPT!
Aug 22 20:20:37 theranch sshd[75598]: Invalid user oracle from 106.37.194.226
Aug 22 20:20:37 theranch sshd[75598]: input_userauth_request: invalid user oracle [preauth]
Aug 22 20:20:37 theranch sshd[75598]: Received disconnect from 106.37.194.226: 11: Bye Bye [preauth]
Aug 22 20:25:51 theranch sshd[75620]: reverse mapping checking getaddrinfo for 226.194.37.106.static.bjtelecom.net [106.37.194.226] failed - POSSIBLE BREAK-IN ATTEMPT!
Aug 22 20:25:51 theranch sshd[75620]: Invalid user public from 106.37.194.226
Aug 22 20:25:51 theranch sshd[75620]: input_userauth_request: invalid user public [preauth]
Aug 22 20:25:51 theranch sshd[75620]: Received disconnect from
106.37.194.226: 11: Bye Bye [preauth]

# 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
00550 deny log ip from table(22) 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