Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
How to setup IPFW working with blacklistd
411 views
Skip to first unread message
Cos Chan
Nov 6, 2017, 3:39:08 AM11/6/17
to
Hi All
I would run IPFW with blacklistd, my FreeBSD is 11.1-RELEASE-p1.
my blacklistd is working fine to get sshd failed login attempts.
The out put:
$ sudo blacklistctl dump -b
address/ma:port id nfail last access
1.1.1.1/32:22 3/-1 2017/11/05 01:05:34
2.2.2.2/32:22 3/-1 2017/11/05 13:22:53
but I can't find information how to use the blacklistd database in IPFW
from IPFW manpage
would anybody explain that to me?
--
with kind regards
_______________________________________________
freebsd-...@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "freebsd-questi...@freebsd.org"
I would run IPFW with blacklistd, my FreeBSD is 11.1-RELEASE-p1.
my blacklistd is working fine to get sshd failed login attempts.
The out put:
$ sudo blacklistctl dump -b
address/ma:port id nfail last access
1.1.1.1/32:22 3/-1 2017/11/05 01:05:34
2.2.2.2/32:22 3/-1 2017/11/05 13:22:53
but I can't find information how to use the blacklistd database in IPFW
from IPFW manpage
would anybody explain that to me?
--
with kind regards
_______________________________________________
freebsd-...@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "freebsd-questi...@freebsd.org"
Carmel NY
Nov 6, 2017, 6:36:21 AM11/6/17
to
On Mon, 6 Nov 2017 09:38:40 +0100, Cos Chan stated:
>I would run IPFW with blacklistd, my FreeBSD is 11.1-RELEASE-p1.
>
>my blacklistd is working fine to get sshd failed login attempts.
>The out put:
>
>$ sudo blacklistctl dump -b
> address/ma:port id nfail last access
> 1.1.1.1/32:22 3/-1 2017/11/05 01:05:34
> 2.2.2.2/32:22 3/-1 2017/11/05 13:22:53
>
>but I can't find information how to use the blacklistd database in IPFW
>from IPFW manpage
>
>would anybody explain that to me?
I have no personal knowledge of "blacklistd"; however, it seems that there
should be a way of using "blacklistctl dump" in conjunction with "sed" or
perhaps "awk" to create a list that could then be fed to "ipfw".
If you could send me the output of a "blacklistctl dump -bn", I could take a
look at it for you.
--
Carmel
>I would run IPFW with blacklistd, my FreeBSD is 11.1-RELEASE-p1.
>
>my blacklistd is working fine to get sshd failed login attempts.
>The out put:
>
>$ sudo blacklistctl dump -b
> address/ma:port id nfail last access
> 1.1.1.1/32:22 3/-1 2017/11/05 01:05:34
> 2.2.2.2/32:22 3/-1 2017/11/05 13:22:53
>
>but I can't find information how to use the blacklistd database in IPFW
>from IPFW manpage
>
>would anybody explain that to me?
should be a way of using "blacklistctl dump" in conjunction with "sed" or
perhaps "awk" to create a list that could then be fed to "ipfw".
If you could send me the output of a "blacklistctl dump -bn", I could take a
look at it for you.
--
Carmel
Cos Chan
Nov 6, 2017, 7:53:29 AM11/6/17
to
On Mon, Nov 6, 2017 at 12:35 PM, Carmel NY <carm...@outlook.com> wrote:
> On Mon, 6 Nov 2017 09:38:40 +0100, Cos Chan stated:
>
> >I would run IPFW with blacklistd, my FreeBSD is 11.1-RELEASE-p1.
> >
> >my blacklistd is working fine to get sshd failed login attempts.
> >The out put:
> >
> >$ sudo blacklistctl dump -b
> > address/ma:port id nfail last access
> > 1.1.1.1/32:22 3/-1 2017/11/05 01:05:34
> > 2.2.2.2/32:22 3/-1 2017/11/05 13:22:53
> >
> >but I can't find information how to use the blacklistd database in IPFW
> >from IPFW manpage
> >
> >would anybody explain that to me?
>
> I have no personal knowledge of "blacklistd"; however, it seems that there
> should be a way of using "blacklistctl dump" in conjunction with "sed" or
> perhaps "awk" to create a list that could then be fed to "ipfw".
>
> If you could send me the output of a "blacklistctl dump -bn", I could take
> a
> look at it for you.
>
>
Here is the output, thanks in advance.
> On Mon, 6 Nov 2017 09:38:40 +0100, Cos Chan stated:
>
> >I would run IPFW with blacklistd, my FreeBSD is 11.1-RELEASE-p1.
> >
> >my blacklistd is working fine to get sshd failed login attempts.
> >The out put:
> >
> >$ sudo blacklistctl dump -b
> > address/ma:port id nfail last access
> > 1.1.1.1/32:22 3/-1 2017/11/05 01:05:34
> > 2.2.2.2/32:22 3/-1 2017/11/05 13:22:53
> >
> >but I can't find information how to use the blacklistd database in IPFW
> >from IPFW manpage
> >
> >would anybody explain that to me?
>
> I have no personal knowledge of "blacklistd"; however, it seems that there
> should be a way of using "blacklistctl dump" in conjunction with "sed" or
> perhaps "awk" to create a list that could then be fed to "ipfw".
>
> If you could send me the output of a "blacklistctl dump -bn", I could take
> a
> look at it for you.
>
>
$ blacklistctl dump -bn
122.114.165.60/32:22 3/-1 2017/11/05 01:05:34
190.85.103.147/32:22 3/-1 2017/11/05 13:22:53
201.178.120.26/32:22 3/-1 2017/11/06 11:12:21
202.29.238.153/32:22 3/-1 2017/11/05 06:06:01
182.73.165.170/32:22 3/-1 2017/11/05 14:10:25
221.143.48.178/32:22 5/-1 2017/11/05 16:42:41
79.231.116.229/32:22 3/-1 2017/11/05 01:28:14
82.146.55.148/32:22 5/-1 2017/11/05 07:11:08
190.110.193.66/32:22 6/-1 2017/11/05 11:34:14
123.207.17.180/32:22 3/-1 2017/11/05 12:20:47
123.122.237.13/32:22 3/-1 2017/11/05 14:38:37
59.63.182.63/32:22 3/-1 2017/11/05 22:50:07
106.246.253.242/32:22 6/-1 2017/11/06 05:38:54
181.113.74.63/32:22 3/-1 2017/11/05 23:12:20
202.150.141.226/32:22 6/-1 2017/11/06 05:49:00
202.210.181.191/32:22 6/-1 2017/11/05 05:34:00
106.247.228.75/32:22 3/-1 2017/11/05 17:12:57
117.3.146.38/32:22 0/-1 1970/01/01 01:00:00
124.193.150.157/32:22 3/-1 2017/11/06 09:23:56
134.249.137.72/32:22 0/-1 1970/01/01 01:00:00
This list were generated by sshd automatically. In case to use sed or awk
to create list for "ipfw", is that possible also automatically updated?
> --
> Carmel
> _______________________________________________
> freebsd-...@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-questions
> unsub...@freebsd.org"
>
--
with kind regards
Ian Smith
Nov 6, 2017, 9:10:29 AM11/6/17
to
In freebsd-questions Digest, Vol 701, Issue 1, Message: 10
On Mon, 6 Nov 2017 09:38:40 +0100 Cos Chan <rose...@gmail.com> wrote:
> Hi All
output. All I know about blacklistd(8), blacklistd.conf(5) and
blacklistctl(8) is what I just now read skimming these manual pages.
However I was surprised to see no mention of using tables rather than
add)ing or rem)oving individual firewall rules - and you can't use
'flush' on individual rules in ipfw(8), only on whole sets of rules.
Amother problem with adding/removing individual rules is you need to
allocate a large enough block of rules, then specify distinct rule
numbers to ipfw(8). Messy and error-prone, especially for deleting.
So you might need to replace or modify /usr/libexec/blacklistd-helper,
which I haven't seen but assume is a script, to use its parameters to
generate commands more like:
/sbin/ipfw table $TABLENAME add addr[/masklen] [value]
and
/sbin/ipfw table $OTHERNAME delete addr[/masklen]
as appropriate. This is immensely more efficient than adding and
deleting single rules on the fly, moreso if there are many entries.
When adding entries, the optional [value] might be a latest timestamp,
or an expiry timestamp, or anything else you might find useful.
Of course you may need a number of different tables, for blocking ssh,
webhosts, mailserver or other services, but then need just a few rules
dedicated to denying (or even specifically enabling) hosts or ports to
addr[/masklen/ entries in a particular table.
ipfw add deny tcp from table \($SPAMMERS\) to any 25,587 setup
ipfw add deny tcp from table \($SSHBADGUYS\) to me 22 setup
ipfw add deny all from table \($REALLYNASTY\) to any in
and such. Tables really are the way to go for this sort of thing.
cheers, Ian
On Mon, 6 Nov 2017 09:38:40 +0100 Cos Chan <rose...@gmail.com> wrote:
> Hi All
>
> I would run IPFW with blacklistd, my FreeBSD is 11.1-RELEASE-p1.
>
> my blacklistd is working fine to get sshd failed login attempts.
> The out put:
>
> $ sudo blacklistctl dump -b
> address/ma:port id nfail last access
> 1.1.1.1/32:22 3/-1 2017/11/05 01:05:34
> 2.2.2.2/32:22 3/-1 2017/11/05 13:22:53
>
> but I can't find information how to use the blacklistd database in IPFW
> from IPFW manpage
>
> would anybody explain that to me?
By all means work with Carmel's offer to look at parsing the database
> I would run IPFW with blacklistd, my FreeBSD is 11.1-RELEASE-p1.
>
> my blacklistd is working fine to get sshd failed login attempts.
> The out put:
>
> $ sudo blacklistctl dump -b
> address/ma:port id nfail last access
> 1.1.1.1/32:22 3/-1 2017/11/05 01:05:34
> 2.2.2.2/32:22 3/-1 2017/11/05 13:22:53
>
> but I can't find information how to use the blacklistd database in IPFW
> from IPFW manpage
>
> would anybody explain that to me?
output. All I know about blacklistd(8), blacklistd.conf(5) and
blacklistctl(8) is what I just now read skimming these manual pages.
However I was surprised to see no mention of using tables rather than
add)ing or rem)oving individual firewall rules - and you can't use
'flush' on individual rules in ipfw(8), only on whole sets of rules.
Amother problem with adding/removing individual rules is you need to
allocate a large enough block of rules, then specify distinct rule
numbers to ipfw(8). Messy and error-prone, especially for deleting.
So you might need to replace or modify /usr/libexec/blacklistd-helper,
which I haven't seen but assume is a script, to use its parameters to
generate commands more like:
/sbin/ipfw table $TABLENAME add addr[/masklen] [value]
and
/sbin/ipfw table $OTHERNAME delete addr[/masklen]
as appropriate. This is immensely more efficient than adding and
deleting single rules on the fly, moreso if there are many entries.
When adding entries, the optional [value] might be a latest timestamp,
or an expiry timestamp, or anything else you might find useful.
Of course you may need a number of different tables, for blocking ssh,
webhosts, mailserver or other services, but then need just a few rules
dedicated to denying (or even specifically enabling) hosts or ports to
addr[/masklen/ entries in a particular table.
ipfw add deny tcp from table \($SPAMMERS\) to any 25,587 setup
ipfw add deny tcp from table \($SSHBADGUYS\) to me 22 setup
ipfw add deny all from table \($REALLYNASTY\) to any in
and such. Tables really are the way to go for this sort of thing.
cheers, Ian
Michael Ross
Nov 6, 2017, 10:12:33 AM11/6/17
to
Am .11.2017, 09:38 Uhr, schrieb Cos Chan <rose...@gmail.com>:
> Hi All
>
> I would run IPFW with blacklistd, my FreeBSD is 11.1-RELEASE-p1.
>
> my blacklistd is working fine to get sshd failed login attempts.
> The out put:
>
> $ sudo blacklistctl dump -b
> address/ma:port id nfail last access
> 1.1.1.1/32:22 3/-1 2017/11/05 01:05:34
> 2.2.2.2/32:22 3/-1 2017/11/05 13:22:53
>
> but I can't find information how to use the blacklistd database in IPFW
> from IPFW manpage
>
> would anybody explain that to me?
>
Have a look at this:
> Hi All
>
> I would run IPFW with blacklistd, my FreeBSD is 11.1-RELEASE-p1.
>
> my blacklistd is working fine to get sshd failed login attempts.
> The out put:
>
> $ sudo blacklistctl dump -b
> address/ma:port id nfail last access
> 1.1.1.1/32:22 3/-1 2017/11/05 01:05:34
> 2.2.2.2/32:22 3/-1 2017/11/05 13:22:53
>
> but I can't find information how to use the blacklistd database in IPFW
> from IPFW manpage
>
> would anybody explain that to me?
>
https://people.freebsd.org/~lidl/blacklistd.html
blacklistd_enable="YES"
blacklistd_flags="-r"
sshd_flags="-o UseBlacklist=yes"
Never tried it myself.
Regards,
Michael
Cos Chan
Nov 6, 2017, 10:42:08 AM11/6/17
to
as you said but it needs ipfw-blacklist.rc for ipfw?
if [ -f "/etc/ipfw-blacklist.rc" ]; then
pf="ipfw"
. /etc/ipfw-blacklist.rc
ipfw_offset=${ipfw_offset:-2000}
fi
I could not find this file in /etc/
the rc.conf file was modified to:
blacklistd_enable="YES"
blacklistd_flags="-C /usr/libexec/blacklistd-helper"
and the blacklistd restarted but no luck yet.
>
> cheers, Ian
>
--
with kind regards
Ian Smith
Nov 6, 2017, 11:51:10 AM11/6/17
to
to put settings, or at least the needed 'ipfw_offset=4000' one.
Thanks to Michael Ross for posting the link to these instructions:
https://people.freebsd.org/~lidl/blacklistd.html
I downloaded the tarball from there and checked it out (no 11.x systems
here). I expect that article has enough info to get you going.
Also, despite no mentions in the manuals, the ipfw implementation does
indeed use tables, and in a sensible fashion, given it fits in with the
existing 'workstation' section in /etc/rc.firewall. Quite clever really.
> the rc.conf file was modified to:
>
> blacklistd_enable="YES"
> blacklistd_flags="-C /usr/libexec/blacklistd-helper"
>
> and the blacklistd restarted but no luck yet.
cheers, Ian
Cos Chan
Nov 6, 2017, 4:43:32 PM11/6/17
to
I have followed the steps but seems not working, here is the ipfw list
output:
$ sudo 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 :default
01200 allow tcp from me to any established
01300 allow tcp from me to any setup keep-state :default
01400 allow udp from me to any keep-state :default
01500 allow icmp from me to any keep-state :default
01600 allow ipv6-icmp from me to any keep-state :default
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 443
02900 allow tcp from any to me dst-port 21
65000 count ip from any to any
65100 deny { tcp or udp } from any to any dst-port 135-139,445 in
65200 deny { tcp or udp } from any to any dst-port 1026,1027 in
65300 deny { tcp or udp } from any to any dst-port 1433,1434 in
65400 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 ip from any to any
65535 deny ip from any to any
looks like the blacklist records are not added to ipfw.
I have also tried to add -C option to rc.conf:
blacklistd_enable="YES"
blacklistd_flags="-r -C /usr/libexec/blacklistd-helper"
But also not working. The ipfw list output is same as above.
>
> Also, despite no mentions in the manuals, the ipfw implementation does
> indeed use tables, and in a sensible fashion, given it fits in with the
> existing 'workstation' section in /etc/rc.firewall. Quite clever really.
>
> > the rc.conf file was modified to:
> >
> > blacklistd_enable="YES"
> > blacklistd_flags="-C /usr/libexec/blacklistd-helper"
> >
> > and the blacklistd restarted but no luck yet.
>
> Let us know how it works out?
>
> cheers, Ian
>
with kind regards
Ian Smith
Nov 7, 2017, 1:23:02 AM11/7/17
to
On Mon, 6 Nov 2017 22:43:02 +0100, Cos Chan wrote:
> On Mon, Nov 6, 2017 at 5:50 PM, Ian Smith <smi...@nimnet.asn.au> wrote:
>
> > On Mon, 6 Nov 2017 16:41:41 +0100, Cos Chan wrote:
> > > On Mon, Nov 6, 2017 at 3:09 PM, Ian Smith <smi...@nimnet.asn.au> wrote:
[ time to cut mightily .. also cc'ing blacklistd maintainer Kurt Lidl
> On Mon, Nov 6, 2017 at 5:50 PM, Ian Smith <smi...@nimnet.asn.au> wrote:
>
> > On Mon, 6 Nov 2017 16:41:41 +0100, Cos Chan wrote:
> > > On Mon, Nov 6, 2017 at 3:09 PM, Ian Smith <smi...@nimnet.asn.au> wrote:
<li...@FreeBSD.org> for whom I'll point to the start of this thread at:
https://lists.freebsd.org/pipermail/freebsd-questions/2017-November/279598.html
]
> I have also tried to add -C option to rc.conf:
>
> blacklistd_enable="YES"
> blacklistd_flags="-r -C /usr/libexec/blacklistd-helper"
>
> But also not working. The ipfw list output is same as above.
I suppose you will have created the flagfile?
# echo 'ipfw_offset=4000' > /etc/ipfw-blacklist.rc
You could put that in /etc/rc.local to be sure it survives updates.
Clearly ipfw needs to be running before blacklistd starts, as it's using
/etc/rc.firewall, which begins by flushing all rules. You could check
that's observed on startup - as I assume it must be - with:
% rcorder /etc/rc.d/* | egrep 'ipfw|blacklist'
Secondly, once ipfw's up, you could manually start blacklistd with the
-d switch (maybe -dv) to run it in forground while it's getting going to
see what it reports. -C seems to be default, but your use of -r seems
smart as ipfw doesn't maintain tables across runs (without scripting).
You could also try uncommenting the 'set -x' in blacklistd-helper to get
a blow-by-blow list (to stderr) of its progress while doing its thing,
which should provide some solid clues.
Other than that, I'm flying blind :)
> > Also, despite no mentions in the manuals, the ipfw implementation does
> > indeed use tables, and in a sensible fashion, given it fits in with the
> > existing 'workstation' section in /etc/rc.firewall. Quite clever really.
> >
> > > the rc.conf file was modified to:
> > >
> > > blacklistd_enable="YES"
> > > blacklistd_flags="-C /usr/libexec/blacklistd-helper"
> > >
> > > and the blacklistd restarted but no luck yet.
> >
> > Let us know how it works out?
cheers, Ian
Cos Chan
Nov 7, 2017, 6:10:01 AM11/7/17
to
lidl/blacklistd.html except the patch updating since my server is i386.
> Clearly ipfw needs to be running before blacklistd starts, as it's using
> /etc/rc.firewall, which begins by flushing all rules. You could check
> that's observed on startup - as I assume it must be - with:
>
> % rcorder /etc/rc.d/* | egrep 'ipfw|blacklist'
>
$ rcorder /etc/rc.d/* | egrep 'ipfw|blacklist'
/etc/rc.d/ipfw
/etc/rc.d/blacklistd
>
> Secondly, once ipfw's up, you could manually start blacklistd with the
> -d switch (maybe -dv) to run it in forground while it's getting going to
> see what it reports. -C seems to be default, but your use of -r seems
> smart as ipfw doesn't maintain tables across runs (without scripting).
>
> You could also try uncommenting the 'set -x' in blacklistd-helper to get
> a blow-by-blow list (to stderr) of its progress while doing its thing,
> which should provide some solid clues.
>
$ sudo blacklistd -dvr
and
$sudo blacklistd -dvr -C /usr/libexec/blacklistd-helper
got same result:
[local]
target type proto owner name nfail duration
25 6 * * * 2 *
22 6 * * * * *
21 6 * * * 2 *
[remote]
source type proto owner name nfail duration
Connected to blacklist server
received 0 from poll()
...
received 1 from poll()
processing type=4 fd=5 remote=121.201.96.113:19720 msg=user uid=0 gid=0
listening socket: 192.168.11.15:22
look: target:192.168.11.15:22, proto:6, family:2, uid:0, name:=, nfail:*,
duration:*
check: target:25, proto:6, family:*, uid:*, name:*, nfail:2, duration:*
check: target:22, proto:6, family:*, uid:*, name:*, nfail:*, duration:*
found: target:22, proto:6, family:*, uid:*, name:*, nfail:*, duration:*
conf_apply: merge: target:22, proto:6, family:*, uid:*, name:*,
nfail:*, duration:*
conf_apply: to: target:192.168.11.15:22, proto:6, family:2, uid:0, name:=,
nfail:*, duration:*
conf_apply: result: target:192.168.11.15:22, proto:6, family:2, uid:*,
name:*, nfail:*, duration:*
Applied address 121.201.96.113:22
Applied address 121.201.96.113:22
process: initial db state for 121.201.96.113:19720: count=3/-1
last=2017/11/07 11:09:34 now=2017/11/07 11:46:26
process: final db state for 121.201.96.113:19720: count=3/-1
last=2017/11/07 11:09:34 now=2017/11/07 11:46:26
received 1 from poll()
processing type=1 fd=5 remote=121.201.96.113:19720 msg=ssh uid=22 gid=22
listening socket: 192.168.11.15:22
look: target:192.168.11.15:22, proto:6, family:2, uid:22, name:=,
nfail:*, duration:*
check: target:25, proto:6, family:*, uid:*, name:*, nfail:2, duration:*
check: target:22, proto:6, family:*, uid:*, name:*, nfail:*, duration:*
found: target:22, proto:6, family:*, uid:*, name:*, nfail:*, duration:*
conf_apply: merge: target:22, proto:6, family:*, uid:*, name:*,
nfail:*, duration:*
conf_apply: to: target:192.168.11.15:22, proto:6, family:2, uid:22, name:=,
nfail:*, duration:*
conf_apply: result: target:192.168.11.15:22, proto:6, family:2, uid:*,
name:*, nfail:*, duration:*
Applied address 121.201.96.113:22
Applied address 121.201.96.113:22
process: initial db state for 121.201.96.113:19720: count=3/-1
last=2017/11/07 11:09:34 now=2017/11/07 11:46:26
process: final db state for 121.201.96.113:19720: count=4/-1
last=2017/11/07 11:46:26 now=2017/11/07 11:46:26
I can't see the blacklistd-helper was running.
The ipfw was running with following options in rc.conf
#ipfw
firewall_enable="YES"
firewall_quiet="YES"
firewall_type="open"
The outputs of
$ sudo ipfw list
were not changed after blacklistd running:
$ sudo 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
65535 deny ip from any to any
the output of
$ cat /etc/ipfw-blacklist.rc
ifpw_offset=4000
> Other than that, I'm flying blind :)
>
> > > Also, despite no mentions in the manuals, the ipfw implementation does
> > > indeed use tables, and in a sensible fashion, given it fits in with
> the
> > > existing 'workstation' section in /etc/rc.firewall. Quite clever
> really.
> > >
> > > > the rc.conf file was modified to:
> > > >
> > > > blacklistd_enable="YES"
> > > > blacklistd_flags="-C /usr/libexec/blacklistd-helper"
> > > >
> > > > and the blacklistd restarted but no luck yet.
> > >
> > > Let us know how it works out?
>
> And thanks for cc'ing me on these, as I take the daily questions-digest.
>
> cheers, Ian
>
with kind regards
Ian Smith
Nov 7, 2017, 10:11:08 AM11/7/17
to
On Tue, 7 Nov 2017 12:09:31 +0100, Cos Chan wrote:
> On Tue, Nov 7, 2017 at 7:17 AM, Ian Smith <smi...@nimnet.asn.au> wrote:
>
> > On Mon, 6 Nov 2017 22:43:02 +0100, Cos Chan wrote:
> >
> > > On Mon, Nov 6, 2017 at 5:50 PM, Ian Smith <smi...@nimnet.asn.au> wrote:
> > >
> > > > On Mon, 6 Nov 2017 16:41:41 +0100, Cos Chan wrote:
> > > > > On Mon, Nov 6, 2017 at 3:09 PM, Ian Smith <smi...@nimnet.asn.au>
> > wrote:
> >
> > [ time to cut mightily .. also cc'ing blacklistd maintainer Kurt Lidl
> > <li...@FreeBSD.org> for whom I'll point to the start of this thread at:
> > https://lists.freebsd.org/pipermail/freebsd-questions/
> > 2017-November/279598.html
> > ]
At this time it seems Kurt may not have received this yet ..
> On Tue, Nov 7, 2017 at 7:17 AM, Ian Smith <smi...@nimnet.asn.au> wrote:
>
> > On Mon, 6 Nov 2017 22:43:02 +0100, Cos Chan wrote:
> >
> > > On Mon, Nov 6, 2017 at 5:50 PM, Ian Smith <smi...@nimnet.asn.au> wrote:
> > >
> > > > On Mon, 6 Nov 2017 16:41:41 +0100, Cos Chan wrote:
> > > > > On Mon, Nov 6, 2017 at 3:09 PM, Ian Smith <smi...@nimnet.asn.au>
> > wrote:
> >
> > [ time to cut mightily .. also cc'ing blacklistd maintainer Kurt Lidl
> > <li...@FreeBSD.org> for whom I'll point to the start of this thread at:
> > https://lists.freebsd.org/pipermail/freebsd-questions/
> > 2017-November/279598.html
> > ]
from mx2.freebsd.org [8.8.178.116]
----- Transcript of session follows -----
<li...@pix.net>... Deferred: Operation timed out with hydra.pix.net.
Warning: message still undelivered after 4 hours
Will keep trying until message is 1 week, 3 days old
> > I suppose you will have created the flagfile?
> > # echo 'ipfw_offset=4000' > /etc/ipfw-blacklist.rc
> > You could put that in /etc/rc.local to be sure it survives updates.
>
> Exactly, I followed all steps same as https://people.freebsd.org/~
> lidl/blacklistd.html except the patch updating since my server is i386.
> > % rcorder /etc/rc.d/* | egrep 'ipfw|blacklist'
>
> the output:
> $ rcorder /etc/rc.d/* | egrep 'ipfw|blacklist'
> /etc/rc.d/ipfw
> /etc/rc.d/blacklistd
The nfail field contains the number of failed attempts before access is
blocked, defaulting to ``*'' meaning never, and the last field disable
specifies the amount of time since the last access that the blocking rule
should be active, defaulting to ``*'' meaning forever. The default unit
for disable is seconds, but one can specify suffixes for different units,
such as ``m'' for minutes ``h'' for hours and ``d'' for days.
But maybe these don't reflect your blacklistd.conf .. please show that?
And don't you need a [remote] section for matching non-local addresses -
I gather from the above it's defaulting to the [local] settings for :22,
but still '*' should mean to never fail them - or am I confused?
table; it's not clear from the above that a rule should have been added?
> The ipfw was running with following options in rc.conf
>
> #ipfw
> firewall_enable="YES"
> firewall_quiet="YES"
> firewall_type="open"
>
> The outputs of
> $ sudo ipfw list
> were not changed after blacklistd running:
>
> $ sudo 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
> 65000 allow ip from any to any
> 65535 deny ip from any to any
> the output of
> $ cat /etc/ipfw-blacklist.rc
> ifpw_offset=4000
try, just for a test, to see blacklistd-helper actually working.
% head -3 blacklistd-helper
#!/bin/sh
#echo "run $@" 1>&2
#set -x
Rather than uncommenting 'set -x' you could replace the first
commented command temporarily with such as:
echo "`date` $0 run $@" >>/var/log/blacklistd-helper.log
So you get an actual log of blacklistd's attempts to add rules?
Cheers, Ian
Cos Chan
Nov 7, 2017, 4:10:53 PM11/7/17
to
the nfail * is from my blacklist.conf, no mistake. this is blacklist.conf:
[local]
ssh stream * * * * *
ftp stream * * * 2 *
smtp stream * * * 2 *
The blacklist database is updated by sshd while I enable these options in
sshd_config:
MaxAuthTries 3
UseBlacklist yes
But in case I configure the nfail in blacklist.conf as 3 or 2, it could
never create banned records, it only made records like this:
#when the nfail is 2
200.229.186.129/32:22 1/2 2017/11/03 15:46:23
#when the nfail is 3
125.66.246.56/32:22 2/3 2017/11/02 10:49:46
#when the nfail is 1
187.108.37.126/32:22 0/1 1970/01/01 01:00:00
as you can see. Always nfail-1 but never reached maximum and ban it, the
blacklistctl dump -b outputted nothing.
I had checked sshd log and make sure that IP reached maximum 3 times failed
login attempts. No idea why blacklistd only records nfail-1 times.
I have to change it to * then it was working to have banned list but still
strange number:
115.84.233.228/32:22 3/-1 2017/11/07 02:10:24
I dont know what the "-1" means.
I didnt mention that from begging because I dont want to make this thread
too complicated. but anyway maybe it help you find the reason.
By the way, you could also see while the nfail is 1, the record's date is
strange: 1970/01/01 01:00:00. I assume that is bug.
again. here are outputs
$ sudo blacklistd -dvr -C /usr/libexec/blacklistd-helper
[local]
target type proto owner name nfail duration
25 6 * * * 2 *
22 6 * * * * *
21 6 * * * 2 *
[remote]
source type proto owner name nfail duration
Connected to blacklist server
received 0 from poll()
...
received 1 from poll()
processing type=4 fd=5 remote=200.60.117.210:37896 msg=mqm uid=0 gid=0
target type proto owner name nfail duration
25 6 * * * 2 *
22 6 * * * * *
21 6 * * * 2 *
[remote]
source type proto owner name nfail duration
Connected to blacklist server
received 0 from poll()
...
received 1 from poll()
listening socket: 192.168.11.15:22
look: target:192.168.11.15:22, proto:6, family:2, uid:0, name:=, nfail:*,
duration:*
check: target:25, proto:6, family:*, uid:*, name:*, nfail:2, duration:*
check: target:22, proto:6, family:*, uid:*, name:*, nfail:*, duration:*
found: target:22, proto:6, family:*, uid:*, name:*, nfail:*, duration:*
look: target:192.168.11.15:22, proto:6, family:2, uid:0, name:=, nfail:*,
duration:*
check: target:25, proto:6, family:*, uid:*, name:*, nfail:2, duration:*
check: target:22, proto:6, family:*, uid:*, name:*, nfail:*, duration:*
found: target:22, proto:6, family:*, uid:*, name:*, nfail:*, duration:*
conf_apply: merge: target:22, proto:6, family:*, uid:*, name:*,
nfail:*, duration:*
conf_apply: to: target:192.168.11.15:22, proto:6, family:2, uid:0, name:=,
nfail:*, duration:*
conf_apply: result: target:192.168.11.15:22, proto:6, family:2, uid:*,
name:*, nfail:*, duration:*
Applied address 200.60.117.210:22
nfail:*, duration:*
conf_apply: to: target:192.168.11.15:22, proto:6, family:2, uid:0, name:=,
nfail:*, duration:*
conf_apply: result: target:192.168.11.15:22, proto:6, family:2, uid:*,
name:*, nfail:*, duration:*
Applied address 200.60.117.210:22
process: initial db state for 200.60.117.210:37896: count=0/-1
last=1970/01/01 01:00:00 now=2017/11/07 22:01:06
process: final db state for 200.60.117.210:37896: count=0/-1
last=1970/01/01 01:00:00 now=2017/11/07 22:01:06
received 1 from poll()
processing type=1 fd=5 remote=200.60.117.210:37896 msg=ssh uid=22 gid=22
listening socket: 192.168.11.15:22
look: target:192.168.11.15:22, proto:6, family:2, uid:22, name:=,
nfail:*, duration:*
check: target:25, proto:6, family:*, uid:*, name:*, nfail:2, duration:*
check: target:22, proto:6, family:*, uid:*, name:*, nfail:*, duration:*
found: target:22, proto:6, family:*, uid:*, name:*, nfail:*, duration:*
conf_apply: merge: target:22, proto:6, family:*, uid:*, name:*,
nfail:*, duration:*
conf_apply: to: target:192.168.11.15:22, proto:6, family:2, uid:22, name:=,
nfail:*, duration:*
conf_apply: result: target:192.168.11.15:22, proto:6, family:2, uid:*,
name:*, nfail:*, duration:*
Applied address 200.60.117.210:22
look: target:192.168.11.15:22, proto:6, family:2, uid:22, name:=,
nfail:*, duration:*
check: target:25, proto:6, family:*, uid:*, name:*, nfail:2, duration:*
check: target:22, proto:6, family:*, uid:*, name:*, nfail:*, duration:*
found: target:22, proto:6, family:*, uid:*, name:*, nfail:*, duration:*
conf_apply: merge: target:22, proto:6, family:*, uid:*, name:*,
nfail:*, duration:*
conf_apply: to: target:192.168.11.15:22, proto:6, family:2, uid:22, name:=,
nfail:*, duration:*
conf_apply: result: target:192.168.11.15:22, proto:6, family:2, uid:*,
name:*, nfail:*, duration:*
Applied address 200.60.117.210:22
process: initial db state for 200.60.117.210:37896: count=0/-1
last=1970/01/01 01:00:00 now=2017/11/07 22:01:06
process: final db state for 200.60.117.210:37896: count=1/-1
last=2017/11/07 22:01:06 now=2017/11/07 22:01:06
received 1 from poll()
processing type=1 fd=5 remote=200.60.117.210:37896 msg=ssh uid=22 gid=22
listening socket: 192.168.11.15:22
look: target:192.168.11.15:22, proto:6, family:2, uid:22, name:=,
nfail:*, duration:*
check: target:25, proto:6, family:*, uid:*, name:*, nfail:2, duration:*
check: target:22, proto:6, family:*, uid:*, name:*, nfail:*, duration:*
found: target:22, proto:6, family:*, uid:*, name:*, nfail:*, duration:*
conf_apply: merge: target:22, proto:6, family:*, uid:*, name:*,
nfail:*, duration:*
conf_apply: to: target:192.168.11.15:22, proto:6, family:2, uid:22, name:=,
nfail:*, duration:*
conf_apply: result: target:192.168.11.15:22, proto:6, family:2, uid:*,
name:*, nfail:*, duration:*
Applied address 200.60.117.210:22
look: target:192.168.11.15:22, proto:6, family:2, uid:22, name:=,
nfail:*, duration:*
check: target:25, proto:6, family:*, uid:*, name:*, nfail:2, duration:*
check: target:22, proto:6, family:*, uid:*, name:*, nfail:*, duration:*
found: target:22, proto:6, family:*, uid:*, name:*, nfail:*, duration:*
conf_apply: merge: target:22, proto:6, family:*, uid:*, name:*,
nfail:*, duration:*
conf_apply: to: target:192.168.11.15:22, proto:6, family:2, uid:22, name:=,
nfail:*, duration:*
conf_apply: result: target:192.168.11.15:22, proto:6, family:2, uid:*,
name:*, nfail:*, duration:*
Applied address 200.60.117.210:22
process: initial db state for 200.60.117.210:37896: count=1/-1
last=2017/11/07 22:01:06 now=2017/11/07 22:01:06
process: final db state for 200.60.117.210:37896: count=2/-1
last=2017/11/07 22:01:06 now=2017/11/07 22:01:06
received 1 from poll()
processing type=1 fd=5 remote=200.60.117.210:37896 msg=ssh uid=22 gid=22
listening socket: 192.168.11.15:22
look: target:192.168.11.15:22, proto:6, family:2, uid:22, name:=,
nfail:*, duration:*
check: target:25, proto:6, family:*, uid:*, name:*, nfail:2, duration:*
check: target:22, proto:6, family:*, uid:*, name:*, nfail:*, duration:*
found: target:22, proto:6, family:*, uid:*, name:*, nfail:*, duration:*
conf_apply: merge: target:22, proto:6, family:*, uid:*, name:*,
nfail:*, duration:*
conf_apply: to: target:192.168.11.15:22, proto:6, family:2, uid:22, name:=,
nfail:*, duration:*
conf_apply: result: target:192.168.11.15:22, proto:6, family:2, uid:*,
name:*, nfail:*, duration:*
Applied address 200.60.117.210:22
look: target:192.168.11.15:22, proto:6, family:2, uid:22, name:=,
nfail:*, duration:*
check: target:25, proto:6, family:*, uid:*, name:*, nfail:2, duration:*
check: target:22, proto:6, family:*, uid:*, name:*, nfail:*, duration:*
found: target:22, proto:6, family:*, uid:*, name:*, nfail:*, duration:*
conf_apply: merge: target:22, proto:6, family:*, uid:*, name:*,
nfail:*, duration:*
conf_apply: to: target:192.168.11.15:22, proto:6, family:2, uid:22, name:=,
nfail:*, duration:*
conf_apply: result: target:192.168.11.15:22, proto:6, family:2, uid:*,
name:*, nfail:*, duration:*
Applied address 200.60.117.210:22
process: initial db state for 200.60.117.210:37896: count=2/-1
last=2017/11/07 22:01:06 now=2017/11/07 22:01:06
process: final db state for 200.60.117.210:37896: count=3/-1
last=2017/11/07 22:01:06 now=2017/11/07 22:01:06
seems the helper script still not running.
$ tail blacklistd-helper.log
Tue Nov 7 17:32:48 CET 2017 /usr/libexec/blacklistd-helper run flush
blacklistd
Tue Nov 7 21:14:37 CET 2017 /usr/libexec/blacklistd-helper run flush
blacklistd
Tue Nov 7 21:50:52 CET 2017 /usr/libexec/blacklistd-helper run flush
blacklistd
It looks like automatically flush but not activated by then entries adding
event.
>
> Cheers, Ian
>
--
with kind regards
siebe
Nov 8, 2017, 10:19:48 AM11/8/17
to
Am 2017-11-06 09:38, schrieb Cos Chan:
>
> I can't find information how to use the blacklistd database in IPFW
> from IPFW manpage
it's all described in /usr/libexec/blacklistd-helper
>
> I can't find information how to use the blacklistd database in IPFW
> from IPFW manpage
Cos Chan
Nov 9, 2017, 8:26:24 AM11/9/17
to
Dear All
Thanks Ian's great help, I have solved problem to post banned entries from
blacklistd to ipfw.
To my knowledge the problem is:
I setup sshd+blacklistd without ipfw at first. Then I got problem the entry
was never reached nfail number (is it a bug?).
so I have to change the nfail to * to get the entry into banned list.
But while I setup ipfw, the nfail=* would not activate blacklistd-helper so
no entry in blacklist banned list were added to ipfw.
I have modify the blacklistd nfail to 2, sshd MaxAuthTries to 3. The
blacklist entries working fine.
BUT I found another problem.
The output of blacklist dump is strange:
$ sudo blacklistctl dump
89.245.78.187/32:22 0/2 1970/01/01 01:00:00
116.193.162.203/32:22 1/2 2017/11/09 11:48:05
Since the blacklistd accepts instruction from sshd. how could be 0/2
entries presented there? I am sure my successful logins were not added to
blacklistd.
I am trying to find out the reason from log but I dont know how to see
blacklistd log. man page said that is to syslogd but what the facility it
is? or some other ways to get out log?
Thanks Ian's great help, I have solved problem to post banned entries from
blacklistd to ipfw.
To my knowledge the problem is:
I setup sshd+blacklistd without ipfw at first. Then I got problem the entry
was never reached nfail number (is it a bug?).
so I have to change the nfail to * to get the entry into banned list.
But while I setup ipfw, the nfail=* would not activate blacklistd-helper so
no entry in blacklist banned list were added to ipfw.
I have modify the blacklistd nfail to 2, sshd MaxAuthTries to 3. The
blacklist entries working fine.
BUT I found another problem.
The output of blacklist dump is strange:
$ sudo blacklistctl dump
address/ma:port id nfail last access
96.227.104.132/32:22 0/2 1970/01/01 01:00:00
89.245.78.187/32:22 0/2 1970/01/01 01:00:00
116.193.162.203/32:22 1/2 2017/11/09 11:48:05
Since the blacklistd accepts instruction from sshd. how could be 0/2
entries presented there? I am sure my successful logins were not added to
blacklistd.
I am trying to find out the reason from log but I dont know how to see
blacklistd log. man page said that is to syslogd but what the facility it
is? or some other ways to get out log?
Ian Smith
Nov 11, 2017, 7:43:34 AM11/11/17
to
On Thu, 9 Nov 2017 14:25:52 +0100, Cos Chan wrote:
> Dear All
>
> Thanks Ian's great help, I have solved problem to post banned entries from
> blacklistd to ipfw.
Well, we're some of the way there :) We really need Kurt Lidl's eyes on
> Dear All
>
> Thanks Ian's great help, I have solved problem to post banned entries from
> blacklistd to ipfw.
this to make real progress, and indications are that my and your emails
cc'ing him were still being deferred for some reason - maybe he's away?
> The original message was received at Tue, 7 Nov 2017 10:12:05 -0500 (EST)
> from mx2.freebsd.org [8.8.178.116]
>
> ----- Transcript of session follows -----
> <li...@pix.net>... Deferred: Operation timed out with hydra.pix.net.
> Warning: message still undelivered after 4 hours
> Will keep trying until message is 1 week, 3 days old
>
> ----- Transcript of session follows -----
> <li...@pix.net>... Deferred: Operation timed out with hydra.pix.net.
> Warning: message still undelivered after 4 hours
> Will keep trying until message is 1 week, 3 days old
> To my knowledge the problem is:
>
> I setup sshd+blacklistd without ipfw at first. Then I got problem the entry
> was never reached nfail number (is it a bug?).
The first issue was because of a severe deficiency in blacklistd-helper,
>
> I setup sshd+blacklistd without ipfw at first. Then I got problem the entry
> was never reached nfail number (is it a bug?).
in that it doesn't actually check that the chosen firewall is running,
and it then fails to detect commands for that firewall that do not (can
not) succeed as any sort of error! More about that below.
The second, however, was mainly that you missed that nfail set to '*'
means that the host is NOT to be blocked, no matter how many auth or
other failures that (in this case) sshd reports.
That also answers another question you had .. "nnn/-1" indicates that
nfail=* ie never to be blocked. These still get accumulated in the
database, but are not applied as ipfw block rule table entries.
> so I have to change the nfail to * to get the entry into banned list.
time - that got blacklistd to record reported failures to its database,
but not to execute the 'add' commands to blacklistd-helper, so that
address was not in fact blocked, and subsequent attempts kept trying.
> But while I setup ipfw, the nfail=* would not activate blacklistd-helper so
> no entry in blacklist banned list were added to ipfw.
> I have modify the blacklistd nfail to 2, sshd MaxAuthTries to 3. The
> blacklist entries working fine.
When ipfw is running, issuing this will show you the addresses blocked:
# ipfw table port22 list
> BUT I found another problem.
>
> The output of blacklist dump is strange:
>
> $ sudo blacklistctl dump
> address/ma:port id nfail last access
> 96.227.104.132/32:22 0/2 1970/01/01 01:00:00
> 89.245.78.187/32:22 0/2 1970/01/01 01:00:00
> 116.193.162.203/32:22 1/2 2017/11/09 11:48:05
>
> Since the blacklistd accepts instruction from sshd. how could be 0/2
> entries presented there? I am sure my successful logins were not added to
> blacklistd.
one hour (your TZ offset). It here means 'no previous entry'. Not sure
about that 0/2, but there are several different codes returned by sshd
including success, failed auth and 'abusive behaviour' .. I'm not sure
which ones your reports (including in off-list mail) indicate.
As for the mysterious 'n-1' behaviour you mentioned offlist for nfail,
in /usr/src/contrib/blacklist/bin/blacklistd.c there's this:
switch (bi->bi_type) {
case BL_ABUSE:
/*
* If the application has signaled abusive behavior,
* set the number of fails to be one less than the
* configured limit. Fallthrough to the normal BL_ADD
* processing, which will increment the failure count
* to the threshhold, and block the abusive address.
*/
if (c.c_nfail != -1)
dbi.count = c.c_nfail - 1;
/*FALLTHROUGH*/
case BL_ADD:
dbi.count++;
dbi.last = ts.tv_sec;
if (dbi.id[0]) {
/*
* We should not be getting this since the rule
* should have blocked the address. A possible
* explanation is that someone removed that rule,
* and another would be that we got another attempt
* before we added the rule. In anycase, we remove
* and re-add the rule because we don't want to add
* it twice, because then we'd lose track of it.
*/
(*lfun)(LOG_DEBUG, "rule exists %s", dbi.id);
(void)run_change("rem", &c, dbi.id, 0);
dbi.id[0] = '\0';
}
if (c.c_nfail != -1 && dbi.count >= c.c_nfail) {
int res = run_change("add", &c, dbi.id, sizeof(dbi.id));
if (res == -1)
goto out;
sockaddr_snprintf(rbuf, sizeof(rbuf), "%a",
(void *)&rss);
(*lfun)(LOG_INFO,
"blocked %s/%d:%d for %d seconds",
rbuf, c.c_lmask, c.c_port, c.c_duration);
}
break;
But if the 'add' command via blacklistd-helper fails, it will never add
the 1 .. I'm not certain about this, but it could explain what you see,
although I can't discern whether sshd is reporting BL_ADD or BL_ABUSE.
You might instead try MaxAuthTries 4 .. sshd_config(5) says:
MaxAuthTries
Specifies the maximum number of authentication attempts permitted
per connection. Once the number of failures reaches half this
value, additional failures are logged. The default is 6.
Half of 3 as an integer is only 1, but half of 4 is 2. See if it helps?
> I am trying to find out the reason from log but I dont know how to see
> blacklistd log. man page said that is to syslogd but what the facility it
> is? or some other ways to get out log?
logging goes to stderr instead of syslog. Without -v you should see it
logging to /var/log/messages. If not, try adding to /etc/syslog.conf:
!blacklistd
*.* /var/log/myblacklistd.log
then '# touch /var/log/myblacklistd.log && service syslogd restart'
Ok, problems with blacklistd-helper; the first bit verbatim, tabs lost:
#!/bin/sh
#echo "run $@" 1>&2
#set -x
# $2 rulename
# $3 protocol
# $4 address
# $5 mask
# $6 port
# $7 id
pf=
if [ -f "/etc/ipfw-blacklist.rc" ]; then
pf="ipfw"
. /etc/ipfw-blacklist.rc
ipfw_offset=${ipfw_offset:-2000}
fi
if [ -z "$pf" ]; then
pf="ipfw"
. /etc/ipfw-blacklist.rc
ipfw_offset=${ipfw_offset:-2000}
fi
for f in npf pf ipf; do
if [ -f "/etc/$f.conf" ]; then
pf="$f"
break
fi
done
fi
if [ -z "$pf" ]; then
echo "$0: Unsupported packet filter" 1>&2
exit 1
fi
Earlier you said you'd run it without /etc/ipfw-blacklist.rc existing.
In that case - UNLESS you had either /etc/pf.conf or /etc/ipf.conf lying
around from before? it should have failed with 'exit 1' .. though it's
not clear from browsing the code that even that would cause it to quit.
So once /etc/ipfw-blacklist.rc exists, that's a flag indicating you
intend using ipfw, however there's NO check that ipfw is running ..
Then - ignoring the pf) and ipf) sections - though I suspect they'd have
the same issue unless really running - here's the ipfw add bit, no tabs:
add)
case "$pf" in
[..]
ipfw)
# use $ipfw_offset+$port for rule number
rule=$(($ipfw_offset + $6))
tname="port$6"
/sbin/ipfw table $tname create type addr 2>/dev/null
Unless ipfw is running, enabled, that will fail - silently.
/sbin/ipfw -q table $tname add "$addr/$mask"
Ditto, perhaps with a message to stderr - that's simply ignored.
# if rule number $rule does not already exist, create it
/sbin/ipfw show $rule >/dev/null 2>&1 || \
/sbin/ipfw add $rule drop $3 from \
table"("$tname")" to any dst-port $6 >/dev/null && \
echo OK
;;
When both of these ipfw commands also fail, it'll only fail to echo OK.
Not that failing to echo OK seems to matter to the calling code, but
the OK is kept as 'id' which is passed to the rem)ove code, but is
unused except by the npf firewall .. 'netbsd packet filter' I guess.
I can certainly suggest patches for at least the ipfw sections - and
really, if the introductory code checks ipfw is working that should be
enough - but I'm unsure whether 'exit 1' after an error message is all
that's needed to get blacklistd to whinge loudly and refuse to continue?
This should be turned into a PR via bugzilla, but since I'm not running
11.x here, I can only really contribute if you do so and add me as a cc.
Please try to avoid top-posting on replies, thanks.
cheers, Ian
Cos Chan
Nov 13, 2017, 9:17:53 AM11/13/17
to
really working fine.
here is one strange record:
$ sudo blacklistctl dump -b | grep 1662
193.201.224.218/32:22 OK 1662/1 2017/11/13 00:31:04
This IP was blocked in ipfw from last week. while I checked it last week
Friday it was 800+/1 in blacklist and until today it become 1662.
To my knowledge the ipfw should block the connection, the times of banned
IP should be not increased?
I could see more entries with more than 3/1, for example:
89.160.221.132/32:22 OK 18/1 2017/11/13 00:01:21
60.125.42.119/32:22 OK 3/1 2017/11/12 16:13:53
166.62.35.180/32:22 OK 3/1 2017/11/10 06:36:25
202.162.221.51/32:22 OK 6/1 2017/11/10 00:42:14
168.0.114.130/32:22 OK 3/1 2017/11/10 23:40:30
95.145.71.165/32:22 OK 3/1 2017/11/11 07:07:07
123.161.206.210/32:22 OK 3/1 2017/11/12 18:14:00
203.146.208.208/32:22 OK 6/1 2017/11/10 10:16:21
149.56.223.241/32:22 OK 1/1 2017/11/12 06:09:16
121.169.217.98/32:22 OK 9/1 2017/11/12 21:59:57
211.251.237.162/32:22 OK 2/1 2017/11/13 12:08:07
103.99.0.116/32:22 OK 30/1 2017/11/10 14:56:07
These records I am not sure if they were not increased after added to ipfw
list. but the 1662 times one, I am sure it was increased after ipfw had the
ip in list.
the different logs concerning that issue:
From blacklistctl dump:
$ sudo blacklistctl dump
address/ma:port id nfail last access
195.225.116.21/32:22 0/1 1970/01/01 01:00:00
123.31.26.123/32:22 0/1 1970/01/01 01:00:00
112.148.101.13/32:22 0/1 1970/01/01 01:00:00
93.23.6.18/32:22 0/1 1970/01/01 01:00:00
5.102.197.124/32:22 0/1 1970/01/01 01:00:00
193.154.127.32/32:22 0/1 1970/01/01 01:00:00
113.232.216.41/32:22 0/1 1970/01/01 01:00:00
From sshd log:
Nov 10 17:57:41 res sshd[49839]: Invalid user pi from 193.154.127.32
Nov 10 17:57:41 res sshd[49840]: Invalid user pi from 193.154.127.32
Nov 10 17:57:41 res sshd[49840]: input_userauth_request: invalid user pi
[preauth]
Nov 10 17:57:41 res sshd[49839]: input_userauth_request: invalid user pi
[preauth]
...
Nov 11 03:50:47 res sshd[57896]: Invalid user support from 123.31.26.123
Nov 11 03:50:47 res sshd[57896]: input_userauth_request: invalid user
support [preauth]
Nov 11 03:50:47 res sshd[57896]: error: Received disconnect from
123.31.26.123 port 55811:3: com.jcraft.jsch.JSchException: Auth fail
[preauth]
Nov 11 03:50:49 res sshd[57898]: Invalid user admin from 123.31.26.123
Nov 11 03:50:49 res sshd[57898]: input_userauth_request: invalid user admin
[preauth]
Nov 11 03:50:49 res sshd[57898]: error: Received disconnect from
123.31.26.123 port 57823:3: com.jcraft.jsch.JSchException: Auth fail
[preauth]
Nov 11 03:50:51 res sshd[57900]: Invalid user admin from 123.31.26.123
Nov 11 03:50:51 res sshd[57900]: input_userauth_request: invalid user admin
[preauth]
Nov 11 03:50:51 res sshd[57900]: error: Received disconnect from
123.31.26.123 port 59819:3: com.jcraft.jsch.JSchException: Auth fail
[preauth]
Nov 11 03:50:53 res sshd[57902]: Invalid user ubnt from 123.31.26.123
Nov 11 03:50:53 res sshd[57902]: input_userauth_request: invalid user ubnt
[preauth]
Nov 11 03:50:53 res sshd[57902]: error: Received disconnect from
123.31.26.123 port 61795:3: com.jcraft.jsch.JSchException: Auth fail
[preauth]
Nov 11 03:50:55 res sshd[57904]: Invalid user PlcmSpIp from 123.31.26.123
Nov 11 03:50:55 res sshd[57904]: input_userauth_request: invalid user
PlcmSpIp [preauth]
Nov 11 03:50:55 res sshd[57904]: error: Received disconnect from
123.31.26.123 port 61920:3: com.jcraft.jsch.JSchException: Auth fail
[preauth]
Nov 11 03:50:57 res sshd[57906]: Invalid user admin from 123.31.26.123
Nov 11 03:50:57 res sshd[57906]: input_userauth_request: invalid user admin
[preauth]
Nov 11 03:50:57 res sshd[57906]: error: Received disconnect from
123.31.26.123 port 61949:3: com.jcraft.jsch.JSchException: Auth fail
[preauth]
I see 2 problems:
Problem 1:
The IP 193.154.127.32 didn't reach sshd maximum authentication (=3), it
tried only 2 times.
But in my opinion it should be recorded to blacklistd as 2/1 instead of 0/1.
Problem 2:
The IP 123.31.26.123 was trying to use different user name to login more
than 3 times. it was also recorded in blacklistd as 0/1.
In my opinion the above 2 all should be banned by blacklistd.
>
> > I am trying to find out the reason from log but I dont know how to see
> > blacklistd log. man page said that is to syslogd but what the facility
> it
> > is? or some other ways to get out log?
>
> Not sure of the facility but when using the -v switch, as you have been,
> logging goes to stderr instead of syslog. Without -v you should see it
> logging to /var/log/messages. If not, try adding to /etc/syslog.conf:
>
> !blacklistd
> *.* /var/log/myblacklistd.log
>
> then '# touch /var/log/myblacklistd.log && service syslogd restart'
>
get the log of "0/1" records yet.
really understand what you said.
I have to learn more about the script :)
>
> Please try to avoid top-posting on replies, thanks.
>
> cheers, Ian
>
--
with kind regards
Kurt Lidl
Nov 13, 2017, 12:38:26 PM11/13/17
to
Greetings all!
Sorry for not being response to your request for help sooner.
I had a bit of a hardware crisis here last week, where
what I thought was merely a blown power supply turned
out to be a failed motherboard. Getting the 2.5" SAS
drives back up and running in a different machine took
far longer than I would have guessed. That, along with
a secondary MX host that was offline for the first 36
hours after the main mail server went down was a cause
for additional excitement.
Anyway.
I've read through the mail exchange, although its a bit
hard to follow all of it.
I'll offer a couple of observations about blacklistd
and how it operates, and maybe that will shed some light
on the problem at hand. If not, well, I'd like to start
fresh with the current configuration, and what you're
seeing on your host.
Observations that might help:
1) The blacklistd support in 11.0 was broken in a couple
of significant ways. The blacklistd support in 11.1 is
thought to be fully functional. If you're not running 11.1,
you will need to update to 11.1.
2) I only use blacklistd with 'pf' in my day-to-day usage.
I extended the support in blacklistd-helper to hopefully
handle both ipfw and ipf, and it seemed to work OK for my
test setup. HOWEVER, it is entirely possible that the way
I did the ipf/ipfw support has a flaw (or more) in it.
3) The changes to the various daemons to support the
blacklist just enable sending messages (and a copy of the
fd of socket) to the blacklist daemon. The blacklist daemon
will extract information from the kernel about the socket's
other end (ie, the information about the remote system),
and stores that information in a database.
4) After the information is stored in the database, the
blacklist daemon calls the blacklistd-helper script and
that script is responsible for modifying the firewall
rules that are in effect. If the script has a bug, it's
entirely possible that the information in the database
will be out of sync with the current firewall rules in
effect.
5) If you're experiencing a situation where the number
of login attempts is greater than the cutoff for the
service (e.g., the "1662/1" noted in the email thread),
that means that whatever firewall rule that is supposed
to be blocking the service isn't blocking the traffic.
(See next item for a case where the right rules are in
the filter, but you still get a "modest" overage of
attempts vs the cutoff.)
6) On a slow-ish single-CPU host (like the sparc64 that I use
as my gateway), it's possible to get more attempts than
the cutoff for a persist, high-speed attacker.
Basically, it takes so long before the system context switches
to the blacklist daemon, and the entry gets added to the pf table.
Where "so long" is still less than a second, but the machine has
already seen 10 or 12 attempts!
For example, here's a partial list of what my gateway is reporting
right now:
root@gatekeeper-130: blacklistctl dump -a
address/ma:port id nfail last access
[...]
61.126.187.219/32:22 OK 3/3 2017/11/12 17:31:40
156.212.51.78/32:22 OK 23/3 2017/11/12 19:09:38
179.53.156.109/32:22 OK 3/3 2017/11/12 19:58:57
220.174.236.220/32:22 2/3 2017/11/12 23:39:58
198.245.63.120/32:22 OK 3/3 2017/11/13 10:36:15
You can see a couple of "normally blocked" attempts (3/3),
a single IP address that has 2 of 3 attempts, and a very,
very persistent/fast host that got in 23 attempts before
it got blocked.
7) There was a note about different usernames from the same
remote host. The blacklist support currently does not
differentiate between usernames. It is just counting the
number of attempts from a remote IP address.
There's unfinished support for having a "known bad" set of usernames,
where a single login attempt for that username will block
the remote address. This will allow (when finished), easy
blocking of the twenty or so most common usernames that are
probed.
Hopefully this will help.
-Kurt
On 11/13/17 9:17 AM, Cos Chan wrote:
>
>
> On Sat, Nov 11, 2017 at 1:42 PM, Ian Smith <smi...@nimnet.asn.au
> <mailto:smi...@nimnet.asn.au>> wrote:
>
> On Thu, 9 Nov 2017 14:25:52 +0100, Cos Chan wrote:
>
> > Dear All
> >
> > Thanks Ian's great help, I have solved problem to post banned
> entries from
> > blacklistd to ipfw.
>
> Well, we're some of the way there :) We really need Kurt Lidl's eyes on
> this to make real progress, and indications are that my and your emails
> cc'ing him were still being deferred for some reason - maybe he's away?
>
> > The original message was received at Tue, 7 Nov 2017 10:12:05
> -0500 (EST)
> > from mx2.freebsd.org <http://mx2.freebsd.org> [8.8.178.116]
> >
> > ----- Transcript of session follows -----
> > <li...@pix.net <mailto:li...@pix.net>>... Deferred: Operation timed out
> with hydra.pix.net <http://hydra.pix.net>.
> 193.201.224.218/32:22 <http://193.201.224.218/32:22> OK 1662/1
> 2017/11/13 00:31:04
>
> This IP was blocked in ipfw from last week. while I checked it last week
> Friday it was 800+/1 in blacklist and until today it become 1662.
>
> To my knowledge the ipfw should block the connection, the times of
> banned IP should be not increased?
>
> I could see more entries with more than 3/1, for example:
>
> 89.160.221.132/32:22 <http://89.160.221.132/32:22> OK 18/1
> 2017/11/13 00:01:21
> 60.125.42.119/32:22 <http://60.125.42.119/32:22> OK 3/1
> 2017/11/12 16:13:53
> 166.62.35.180/32:22 <http://166.62.35.180/32:22> OK 3/1
> 2017/11/10 06:36:25
> 202.162.221.51/32:22 <http://202.162.221.51/32:22> OK 6/1
> 2017/11/10 00:42:14
> 168.0.114.130/32:22 <http://168.0.114.130/32:22> OK 3/1
> 2017/11/10 23:40:30
> 95.145.71.165/32:22 <http://95.145.71.165/32:22> OK 3/1
> 2017/11/11 07:07:07
> 123.161.206.210/32:22 <http://123.161.206.210/32:22> OK 3/1
> 2017/11/12 18:14:00
> 203.146.208.208/32:22 <http://203.146.208.208/32:22> OK 6/1
> 2017/11/10 10:16:21
> 149.56.223.241/32:22 <http://149.56.223.241/32:22> OK 1/1
> 2017/11/12 06:09:16
> 121.169.217.98/32:22 <http://121.169.217.98/32:22> OK 9/1
> 2017/11/12 21:59:57
> 211.251.237.162/32:22 <http://211.251.237.162/32:22> OK 2/1
> 2017/11/13 12:08:07
> 103.99.0.116/32:22 <http://103.99.0.116/32:22> OK 30/1
> 2017/11/10 14:56:07
>
> These records I am not sure if they were not increased after added to
> ipfw list. but the 1662 times one, I am sure it was increased after ipfw
> had the ip in list.
>
>
> > BUT I found another problem.
> >
> > The output of blacklist dump is strange:
> >
> > $ sudo blacklistctl dump
> > address/ma:port id nfail last access
> > 96.227.104.132/32:22 <http://96.227.104.132/32:22>
> 0/2 1970/01/01 01:00:00
> > 89.245.78.187/32:22 <http://89.245.78.187/32:22> 0/2
> 1970/01/01 01:00:00
> > 116.193.162.203/32:22 <http://116.193.162.203/32:22>
> if (dbi.id <http://dbi.id>[0]) {
> /*
> * We should not be getting this since the rule
> * should have blocked the address. A possible
> * explanation is that someone removed that
> rule,
> * and another would be that we got another
> attempt
> * before we added the rule. In anycase, we
> remove
> * and re-add the rule because we don't
> want to add
> * it twice, because then we'd lose track
> of it.
> */
> (*lfun)(LOG_DEBUG, "rule exists %s", dbi.id
> <http://dbi.id>);
> (void)run_change("rem", &c, dbi.id
> <http://dbi.id>, 0);
> dbi.id <http://dbi.id>[0] = '\0';
> }
> if (c.c_nfail != -1 && dbi.count >= c.c_nfail) {
> int res = run_change("add", &c, dbi.id
> <http://dbi.id>, sizeof(dbi.id <http://dbi.id>));
> if (res == -1)
> goto out;
> sockaddr_snprintf(rbuf, sizeof(rbuf), "%a",
> (void *)&rss);
> (*lfun)(LOG_INFO,
> "blocked %s/%d:%d for %d seconds",
> rbuf, c.c_lmask, c.c_port, c.c_duration);
>
> }
> break;
>
> But if the 'add' command via blacklistd-helper fails, it will never add
> the 1 .. I'm not certain about this, but it could explain what you see,
> although I can't discern whether sshd is reporting BL_ADD or BL_ABUSE.
>
> You might instead try MaxAuthTries 4 .. sshd_config(5) says:
>
> MaxAuthTries
> Specifies the maximum number of authentication
> attempts permitted
> per connection. Once the number of failures reaches
> half this
> value, additional failures are logged. The default is 6.
>
> Half of 3 as an integer is only 1, but half of 4 is 2. See if it helps?
>
>
> I didnt change the MaxAuthTries, since I found something interesting
> from the different logs concerning that issue:
>
> From blacklistctl dump:
>
> $ sudo blacklistctl dump
> address/ma:port id nfail last access
> 78.203.146.34/32:22 <http://78.203.146.34/32:22> 0/1
> 1970/01/01 01:00:00
> 195.225.116.21/32:22 <http://195.225.116.21/32:22> 0/1
> 1970/01/01 01:00:00
> 123.31.26.123/32:22 <http://123.31.26.123/32:22> 0/1
> 1970/01/01 01:00:00
> 112.148.101.13/32:22 <http://112.148.101.13/32:22> 0/1
> 1970/01/01 01:00:00
> 93.23.6.18/32:22 <http://93.23.6.18/32:22> 0/1 1970/01/01
> 01:00:00
> 5.102.197.124/32:22 <http://5.102.197.124/32:22> 0/1
> 1970/01/01 01:00:00
> 193.154.127.32/32:22 <http://193.154.127.32/32:22> 0/1
> 1970/01/01 01:00:00
> 113.232.216.41/32:22 <http://113.232.216.41/32:22> 0/1
Cos Chan
Nov 14, 2017, 3:32:10 AM11/14/17
to
$ sudo 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
65000 allow ip from any to any
65535 deny ip from any to any
>
>
65535 deny ip from any to any
>
>
$ sudo blacklistctl dump
address/ma:port id nfail last access
...
$ sudo cat auth.log | grep 24.7.90.146
Nov 14 02:13:58 res sshd[6212]: Invalid user pi from 24.7.90.146
Nov 14 02:13:58 res sshd[6215]: Invalid user pi from 24.7.90.146
Nov 14 02:13:59 res sshd[6215]: Connection closed by 24.7.90.146 port 34746
[preauth]
Nov 14 02:13:59 res sshd[6212]: Connection closed by 24.7.90.146 port 34742
[preauth]
$ cat myblacklistd.log | grep 'Nov 14'
...
Nov 14 02:09:11 res blacklistd[5590]: blocked 202.51.74.55/32:22 for -1
seconds
Nov 14 02:11:06 res blacklistd[5590]: rule exists OK
Nov 14 02:11:06 res blacklistd[5590]: blocked 202.51.74.55/32:22 for -1
seconds
Nov 14 02:14:43 res blacklistd[5590]: blocked 66.232.147.46/32:22 for -1
seconds
Nov 14 02:16:40 res blacklistd[5590]: rule exists OK
could not see operation against that IP from blacklistd.log
Cos Chan
Nov 14, 2017, 9:39:22 AM11/14/17
to
$ sudo tail security
Nov 14 15:09:07 res kernel: ipfw: 2022 Deny TCP 182.93.152.171:6920
192.168.11.15:22 in via em0
Nov 14 15:09:21 res kernel: ipfw: 2022 Deny TCP 123.125.203.196:6920
192.168.11.15:22 in via em0
Nov 14 15:10:11 res kernel: ipfw: 2022 Deny TCP 182.93.152.171:6920
192.168.11.15:22 in via em0
Nov 14 15:10:33 res kernel: ipfw: 2022 Deny TCP 83.12.107.106:6920
192.168.11.15:22 in via em0
Nov 14 15:11:08 res last message repeated 15 times
Nov 14 15:12:32 res last message repeated 4 times
Nov 14 15:21:10 res kernel: ipfw: 2022 Deny TCP 201.147.183.55:60299
192.168.11.15:22 in via em0
Nov 14 15:21:17 res last message repeated 3 times
Nov 14 15:25:38 res kernel: ipfw: 2022 Deny TCP 105.226.55.239:48315
192.168.11.15:22 in via em0
Nov 14 15:26:18 res last message repeated 12 times
$ sudo tail auth.log
Nov 14 15:07:24 res sshd[9029]: input_userauth_request: invalid user admin
[preauth]
Nov 14 15:10:33 res sshd[9052]: Invalid user omni from 83.12.107.106
Nov 14 15:10:33 res sshd[9052]: input_userauth_request: invalid user omni
[preauth]
Nov 14 15:25:37 res sshd[9144]: reverse mapping checking getaddrinfo for
105-226-55-239.south.dsl.telkomsa.net [105.226.55.239] failed - POSSIBLE
BREAK-IN ATTEMPT!
Nov 14 15:25:37 res sshd[9144]: Invalid user admin from 105.226.55.239
Nov 14 15:25:37 res sshd[9144]: input_userauth_request: invalid user admin
[preauth]
Nov 14 15:26:08 res sshd[9152]: Received disconnect from 121.18.238.123
port 42391:11: [preauth]
Nov 14 15:26:08 res sshd[9152]: Disconnected from 121.18.238.123 port 42391
[preauth]
The IP 105.226.55.239 looks like banned by IPFW, but still connected to
sshd?
Ian Smith
Nov 15, 2017, 2:55:51 AM11/15/17
to
On Mon, 13 Nov 2017 12:37:46 -0500, Kurt Lidl wrote:
> Greetings all!
Welcome Kurt, very glad you're here!
> Sorry for not being response to your request for help sooner.
>
> I had a bit of a hardware crisis here last week, where
> what I thought was merely a blown power supply turned
> out to be a failed motherboard. Getting the 2.5" SAS
> drives back up and running in a different machine took
> far longer than I would have guessed. That, along with
> a secondary MX host that was offline for the first 36
> hours after the main mail server went down was a cause
> for additional excitement.
Sounds like lots of fun, and certainly explains the mail problems.
> Anyway.
>
> I've read through the mail exchange, although its a bit
> hard to follow all of it.
It is, and a lot of that's my fault for speculating in your absense,
however I do find this an interesting gadget, even though I'm not likely
to be running an 11.x system in the foreseeable future.
I'll get back to the rest of your observations after replying to a
couple of Cos' messages first - as briefly as possible!
cheers, Ian
> Greetings all!
Welcome Kurt, very glad you're here!
> Sorry for not being response to your request for help sooner.
>
> I had a bit of a hardware crisis here last week, where
> what I thought was merely a blown power supply turned
> out to be a failed motherboard. Getting the 2.5" SAS
> drives back up and running in a different machine took
> far longer than I would have guessed. That, along with
> a secondary MX host that was offline for the first 36
> hours after the main mail server went down was a cause
> for additional excitement.
> Anyway.
>
> I've read through the mail exchange, although its a bit
> hard to follow all of it.
however I do find this an interesting gadget, even though I'm not likely
to be running an 11.x system in the foreseeable future.
I'll get back to the rest of your observations after replying to a
couple of Cos' messages first - as briefly as possible!
cheers, Ian
Ian Smith
Nov 15, 2017, 3:25:34 AM11/15/17
to
On Mon, 13 Nov 2017 15:17:20 +0100, Cos Chan wrote:
> On Sat, Nov 11, 2017 at 1:42 PM, Ian Smith <smi...@nimnet.asn.au> wrote:
> > On Thu, 9 Nov 2017 14:25:52 +0100, Cos Chan wrote:
I'll have to cut mercilessly, trying to keep to newest issues ..
> On Sat, Nov 11, 2017 at 1:42 PM, Ian Smith <smi...@nimnet.asn.au> wrote:
> > On Thu, 9 Nov 2017 14:25:52 +0100, Cos Chan wrote:
Without seeing synchronised logs from blacklistd and blacklistd-helper
and ipfw, with clearly stated current configuration and switches, it's
very difficult to know what might be happening ..
separate connections. From above, MaxAuthTries limits the maximum
number of attempts _per_connection_. So each of these indicate only one
(or possibly two, as again from above, only those greater than half of
the maximum (here 3/2 = 1) are supposedly logged by sshd).
I don't know just what sshd reports to blacklistd in what circumstances,
nor how those are reflected in blacklistd's logging .. Kurt likely does.
> Nov 11 03:50:47 res sshd[57896]: Invalid user support from 123.31.26.123
> Nov 11 03:50:47 res sshd[57896]: input_userauth_request: invalid user
> support [preauth]
> Nov 11 03:50:47 res sshd[57896]: error: Received disconnect from
> 123.31.26.123 port 55811:3: com.jcraft.jsch.JSchException: Auth fail
> [preauth]
> Nov 11 03:50:49 res sshd[57898]: Invalid user admin from 123.31.26.123
> Nov 11 03:50:49 res sshd[57898]: input_userauth_request: invalid user admin
> [preauth]
> Nov 11 03:50:49 res sshd[57898]: error: Received disconnect from
> 123.31.26.123 port 57823:3: com.jcraft.jsch.JSchException: Auth fail
> [preauth]
> Nov 11 03:50:51 res sshd[57900]: Invalid user admin from 123.31.26.123
> Nov 11 03:50:51 res sshd[57900]: input_userauth_request: invalid user admin
> [preauth]
> Nov 11 03:50:51 res sshd[57900]: error: Received disconnect from
> 123.31.26.123 port 59819:3: com.jcraft.jsch.JSchException: Auth fail
> [preauth]
> Nov 11 03:50:53 res sshd[57902]: Invalid user ubnt from 123.31.26.123
> Nov 11 03:50:53 res sshd[57902]: input_userauth_request: invalid user ubnt
> [preauth]
> Nov 11 03:50:53 res sshd[57902]: error: Received disconnect from
> 123.31.26.123 port 61795:3: com.jcraft.jsch.JSchException: Auth fail
> [preauth]
> Nov 11 03:50:55 res sshd[57904]: Invalid user PlcmSpIp from 123.31.26.123
> Nov 11 03:50:55 res sshd[57904]: input_userauth_request: invalid user
> PlcmSpIp [preauth]
> Nov 11 03:50:55 res sshd[57904]: error: Received disconnect from
> 123.31.26.123 port 61920:3: com.jcraft.jsch.JSchException: Auth fail
> [preauth]
> Nov 11 03:50:57 res sshd[57906]: Invalid user admin from 123.31.26.123
> Nov 11 03:50:57 res sshd[57906]: input_userauth_request: invalid user admin
> [preauth]
> Nov 11 03:50:57 res sshd[57906]: error: Received disconnect from
> 123.31.26.123 port 61949:3: com.jcraft.jsch.JSchException: Auth fail
> [preauth]
be - keeping track of separate connections from the same IP address.
> I see 2 problems:
>
> Problem 1:
> The IP 193.154.127.32 didn't reach sshd maximum authentication (=3), it
> tried only 2 times.
> But in my opinion it should be recorded to blacklistd as 2/1 instead of 0/1.
report it as _one_ failure to blacklistd.
> Problem 2:
> The IP 123.31.26.123 was trying to use different user name to login more
> than 3 times. it was also recorded in blacklistd as 0/1.
>
> In my opinion the above 2 all should be banned by blacklistd.
words, I don't think this works the way you're expecting.
> > Earlier you said you'd run it without /etc/ipfw-blacklist.rc existing.
> > In that case - UNLESS you had either /etc/pf.conf or /etc/ipf.conf lying
> > around from before? it should have failed with 'exit 1' .. though it's
> > not clear from browsing the code that even that would cause it to quit.
> >
>
> No, there are not /etc/pf.conf and /etc/ipf.conf.
time, likely to stderr, and you weren't logging blacxklistd at that
time. It would be good to know what happens if blacklistd-helper fails.
Moving on ..
cheers, Ian
Ian Smith
Nov 15, 2017, 4:03:00 AM11/15/17
to
On Tue, 14 Nov 2017 15:38:51 +0100, Cos Chan wrote:
> On Tue, Nov 14, 2017 at 9:31 AM, Cos Chan <rose...@gmail.com> wrote:
> >
> > On Mon, Nov 13, 2017 at 3:17 PM, Cos Chan <rose...@gmail.com> wrote:
> >> here is one strange record:
> >>
> >> $ sudo blacklistctl dump -b | grep 1662
> >> 193.201.224.218/32:22 OK 1662/1 2017/11/13 00:31:04
> >>
> >> This IP was blocked in ipfw from last week. while I checked it last week
> >> Friday it was 800+/1 in blacklist and until today it become 1662.
> >>
> >> To my knowledge the ipfw should block the connection, the times of banned
> >> IP should be not increased?
Have you added blacklistd_flags="-r" to /etc/rc.conf? And are you
> On Tue, Nov 14, 2017 at 9:31 AM, Cos Chan <rose...@gmail.com> wrote:
> >
> > On Mon, Nov 13, 2017 at 3:17 PM, Cos Chan <rose...@gmail.com> wrote:
> >> here is one strange record:
> >>
> >> $ sudo blacklistctl dump -b | grep 1662
> >> 193.201.224.218/32:22 OK 1662/1 2017/11/13 00:31:04
> >>
> >> This IP was blocked in ipfw from last week. while I checked it last week
> >> Friday it was 800+/1 in blacklist and until today it become 1662.
> >>
> >> To my knowledge the ipfw should block the connection, the times of banned
> >> IP should be not increased?
using 'service blacklistd start' to control it? If otherwise, are
you always starting blacklistd with the -r switch? Be explicit.
If not, a fresh run of blacklistd should NOT try to remove and re-add
each of its blocked addresses, and if ipfw has been restarted, that
address will NOT be in its table of addresses to block. Might that
explain what you're seeing?
Whenever in doubt, just run 'ipfw table \(port22\) list'. Also, when
listing ipfw rules, it's helpful to use 'ipfw -t show' which shows all
rules with their packet and byte counters, plus the date last used for
each rule. Or even just 'ipfw -t show 4022' or whatever.
> >> I could see more entries with more than 3/1, for example:
> >>
> >> 89.160.221.132/32:22 OK 18/1 2017/11/13 00:01:21
> >> 60.125.42.119/32:22 OK 3/1 2017/11/12 16:13:53
> >> 166.62.35.180/32:22 OK 3/1 2017/11/10 06:36:25
> >> 202.162.221.51/32:22 OK 6/1 2017/11/10 00:42:14
> >> 168.0.114.130/32:22 OK 3/1 2017/11/10 23:40:30
> >> 95.145.71.165/32:22 OK 3/1 2017/11/11 07:07:07
> >> 123.161.206.210/32:22 OK 3/1 2017/11/12 18:14:00
> >> 203.146.208.208/32:22 OK 6/1 2017/11/10 10:16:21
> >> 149.56.223.241/32:22 OK 1/1 2017/11/12 06:09:16
> >> 121.169.217.98/32:22 OK 9/1 2017/11/12 21:59:57
> >> 211.251.237.162/32:22 OK 2/1 2017/11/13 12:08:07
> >> 103.99.0.116/32:22 OK 30/1 2017/11/10 14:56:07
> >>
> >> These records I am not sure if they were not increased after added to
> >> ipfw list. but the 1662 times one, I am sure it was increased after ipfw
> >> had the ip in list.
Remember, ipfw does not keep its tables between runs, without scripting.
connection attempts, at that time.
However ipfw only logs rules to /var/log/security that contain the 'log'
keyword, so you presumably MUST have added that, making the rule be:
02022 deny log tcp from table(port22) to any dst-port 22
---
If you didn't do that - in blacklistd-helper? or manually? - then ipfw
in 11.1 is severely broken .. please do say when you change conditions.
> $ sudo tail auth.log
> Nov 14 15:07:24 res sshd[9029]: input_userauth_request: invalid user admin
> [preauth]
> Nov 14 15:10:33 res sshd[9052]: Invalid user omni from 83.12.107.106
> Nov 14 15:10:33 res sshd[9052]: input_userauth_request: invalid user omni
> [preauth]
> Nov 14 15:25:37 res sshd[9144]: reverse mapping checking getaddrinfo for
> 105-226-55-239.south.dsl.telkomsa.net [105.226.55.239] failed - POSSIBLE
> BREAK-IN ATTEMPT!
> Nov 14 15:25:37 res sshd[9144]: Invalid user admin from 105.226.55.239
> Nov 14 15:25:37 res sshd[9144]: input_userauth_request: invalid user admin
> [preauth]
above .. but we can't see what blacklistctl reports for it. Confusing.
Might that have been reported as ABUSIVE? No matching blacklistd.log?
> Nov 14 15:26:08 res sshd[9152]: Received disconnect from 121.18.238.123
> port 42391:11: [preauth]
> Nov 14 15:26:08 res sshd[9152]: Disconnected from 121.18.238.123 port 42391
> [preauth]
>
> The IP 105.226.55.239 looks like banned by IPFW, but still connected to
> sshd?
Hope that helps.
cheers, Ian
Cos Chan
Nov 15, 2017, 6:31:13 AM11/15/17
to
>
> > I see 2 problems:
> >
> > Problem 1:
> > The IP 193.154.127.32 didn't reach sshd maximum authentication (=3), it
> > tried only 2 times.
>
> Perhaps rather, only once or twice on each of two separate connections?
>
> > But in my opinion it should be recorded to blacklistd as 2/1 instead of
> 0/1.
>
> I gather that it would take 3 failed logins on any _one_ connection to
> report it as _one_ failure to blacklistd.
>
failed once per connection, then it will never be banned by blacklistd
(unless the maxauth of sshd is 1)?
>
> > Problem 2:
> > The IP 123.31.26.123 was trying to use different user name to login more
> > than 3 times. it was also recorded in blacklistd as 0/1.
> >
> > In my opinion the above 2 all should be banned by blacklistd.
>
> Again, no single one of those connections failed 3 times. In other
> words, I don't think this works the way you're expecting.
> > > Earlier you said you'd run it without /etc/ipfw-blacklist.rc existing.
> > > In that case - UNLESS you had either /etc/pf.conf or /etc/ipf.conf
> lying
> > > around from before? it should have failed with 'exit 1' .. though it's
> > > not clear from browsing the code that even that would cause it to
> quit.
> > >
> >
> > No, there are not /etc/pf.conf and /etc/ipf.conf.
>
> So it looks like you maybe just didn't see any failure message at the
> time, likely to stderr, and you weren't logging blacxklistd at that
> time. It would be good to know what happens if blacklistd-helper fails.
>
and configurations.
here is the log to show "problem n-1/n", the blacklistd could not never
reach maximum nfail and ban the IP.
To produce the problem, I only need to remove /etc/ipfw-blacklist.rc and
there is no /etc/pf.conf or /etc/ipf.conf either.
I run blacklistd by "service blacklistd start", here is the rc.conf:
blacklistd_enable="YES"
blacklistd_flags="-r"
here is sshd_config:
AuthenticationMethods publickey
MaxAuthTries 4
UseBlacklist yes
here is ipfw in rc.conf:
#ipfw
firewall_enable="YES"
firewall_quiet="YES"
firewall_type="open"
firewall_script="/usr/local/etc/firewall.rules"
firewall_enable="YES"
firewall_quiet="YES"
firewall_type="open"
firewall_logging="YES"
modification to /usr/libexec/blacklistd-helper is to add one line for log:
# $7 id
echo "`date` $0 run $@" >>/var/log/blacklistd-helper.log
the ipfw list:
$ sudo 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
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
02022 deny log tcp from table(port22) to any dst-port 22
65000 allow ip from any to any
65535 deny ip from any to any
the rule "02022 deny log tcp from table(port22) to any dst-port 22" was
65535 deny ip from any to any
added by myself to have log from ipfw
syslog.conf:
!blacklistd
*.* /var/log/blacklistd.log
I did sshd MaxAuthTries =3 and 4.
maxauth =3, the blacklistd-helper.log:
--start sshd maxauth=3; blacklist nfail=2, disable=*; ipfw enabled, removed
/etc/ipfw-blacklist.rc--
Wed Nov 15 09:53:40 CET 2017 /usr/libexec/blacklistd-helper run flush
blacklistd
Wed Nov 15 09:55:47 CET 2017 /usr/libexec/blacklistd-helper run add
blacklistd tcp 59.120.35.74 32 22
Wed Nov 15 09:55:47 CET 2017 /usr/libexec/blacklistd-helper run add
blacklistd tcp 59.120.35.74 32 22
Wed Nov 15 09:59:21 CET 2017 /usr/libexec/blacklistd-helper run add
blacklistd tcp 193.201.224.218 32 22
Wed Nov 15 09:59:21 CET 2017 /usr/libexec/blacklistd-helper run add
blacklistd tcp 193.201.224.218 32 22
Wed Nov 15 09:59:25 CET 2017 /usr/libexec/blacklistd-helper run add
blacklistd tcp 193.201.224.218 32 22
Wed Nov 15 09:59:26 CET 2017 /usr/libexec/blacklistd-helper run add
blacklistd tcp 193.201.224.218 32 22
Wed Nov 15 09:59:26 CET 2017 /usr/libexec/blacklistd-helper run add
blacklistd tcp 193.201.224.218 32 22
....
blacklistd.log:
Nov 15 09:55:09 res blacklistd[18044]: Connected to blacklist server
Nov 15 10:14:14 res blacklistd[18045]: message too short 144
Nov 15 10:14:14 res blacklistd[18045]: no message (Connection refused)
Nov 15 10:17:33 res blacklistd[18045]: message too short 144
Nov 15 10:17:33 res blacklistd[18045]: no message (Connection refused)
Nov 15 10:17:34 res blacklistd[18045]: message too short 144
Nov 15 10:17:34 res blacklistd[18045]: no message (Connection refused)
Nov 15 10:17:44 res blacklistd[18045]: message too short 144
Nov 15 10:17:44 res blacklistd[18045]: no message (Connection refused)
Nov 15 10:17:54 res blacklistd[18045]: message too short 144
Nov 15 10:17:54 res blacklistd[18045]: no message (Connection refused)
Nov 15 10:18:20 res blacklistd[18045]: message too short 144
Nov 15 10:18:20 res blacklistd[18045]: no message (Connection refused)
Nov 15 10:18:30 res blacklistd[18045]: message too short 144
Nov 15 10:18:30 res blacklistd[18045]: no message (Connection refused)
dump:
$ sudo blacklistctl dump
address/ma:port id nfail last access
89.135.123.209/32:22 1/2 2017/11/15 10:32:53
193.201.224.218/32:22 1/2 2017/11/15 09:59:20
118.123.245.239/32:22 1/2 2017/11/15 10:15:10
$ sudo blacklistctl dump -b
address/ma:port id nfail last access
maxauth=4, the logs
$ cat blacklistd-helper.log
--start sshd maxauth=4; blacklist nfail=2, disable=*; ipfw enabled, removed
/etc/ipfw-blacklist.rc--
Wed Nov 15 10:53:39 CET 2017 /usr/libexec/blacklistd-helper run flush
blacklistd
Wed Nov 15 10:56:45 CET 2017 /usr/libexec/blacklistd-helper run flush
blacklistd
Wed Nov 15 10:58:44 CET 2017 /usr/libexec/blacklistd-helper run add
blacklistd tcp 41.73.194.139 32 22
Wed Nov 15 10:58:44 CET 2017 /usr/libexec/blacklistd-helper run add
blacklistd tcp 41.73.194.139 32 22
Wed Nov 15 11:01:04 CET 2017 /usr/libexec/blacklistd-helper run add
blacklistd tcp 83.246.164.83 32 22
Wed Nov 15 11:01:04 CET 2017 /usr/libexec/blacklistd-helper run add
blacklistd tcp 83.246.164.83 32 22
$ tail blacklistd.log
Nov 15 10:53:39 res blacklistd[21125]: Connected to blacklist server
Nov 15 10:53:53 res blacklistd[21161]: Connected to blacklist server
Nov 15 10:56:45 res blacklistd[21264]: Connected to blacklist server
Nov 15 10:56:57 res blacklistd[21312]: Connected to blacklist server
$ sudo blacklistctl dump
address/ma:port id nfail last access
83.246.164.83/32:22 1/2 2017/11/15 11:01:04
$ sudo blacklistctl dump -b
address/ma:port id nfail last access
>
>
> Moving on ..
>
> cheers, Ian
>
--
>
> cheers, Ian
>
with kind regards
Cos Chan
Nov 15, 2017, 6:47:11 AM11/15/17
to
On Wed, Nov 15, 2017 at 10:02 AM, Ian Smith <smi...@nimnet.asn.au> wrote:
> On Tue, 14 Nov 2017 15:38:51 +0100, Cos Chan wrote:
>
> > On Tue, Nov 14, 2017 at 9:31 AM, Cos Chan <rose...@gmail.com> wrote:
> > >
> > > On Mon, Nov 13, 2017 at 3:17 PM, Cos Chan <rose...@gmail.com> wrote:
>
> > >> here is one strange record:
> > >>
> > >> $ sudo blacklistctl dump -b | grep 1662
> > >> 193.201.224.218/32:22 OK 1662/1 2017/11/13 00:31:04
> > >>
> > >> This IP was blocked in ipfw from last week. while I checked it last
> week
> > >> Friday it was 800+/1 in blacklist and until today it become 1662.
> > >>
> > >> To my knowledge the ipfw should block the connection, the times of
> banned
> > >> IP should be not increased?
>
> Have you added blacklistd_flags="-r" to /etc/rc.conf? And are you
> using 'service blacklistd start' to control it? If otherwise, are
> you always starting blacklistd with the -r switch? Be explicit.
>
Yes blacklistd_flags="-r" to /etc/rc.conf and 'service blacklistd start'
> On Tue, 14 Nov 2017 15:38:51 +0100, Cos Chan wrote:
>
> > On Tue, Nov 14, 2017 at 9:31 AM, Cos Chan <rose...@gmail.com> wrote:
> > >
> > > On Mon, Nov 13, 2017 at 3:17 PM, Cos Chan <rose...@gmail.com> wrote:
>
> > >> here is one strange record:
> > >>
> > >> $ sudo blacklistctl dump -b | grep 1662
> > >> 193.201.224.218/32:22 OK 1662/1 2017/11/13 00:31:04
> > >>
> > >> This IP was blocked in ipfw from last week. while I checked it last
> week
> > >> Friday it was 800+/1 in blacklist and until today it become 1662.
> > >>
> > >> To my knowledge the ipfw should block the connection, the times of
> banned
> > >> IP should be not increased?
>
> Have you added blacklistd_flags="-r" to /etc/rc.conf? And are you
> using 'service blacklistd start' to control it? If otherwise, are
> you always starting blacklistd with the -r switch? Be explicit.
>
>
> If not, a fresh run of blacklistd should NOT try to remove and re-add
> each of its blocked addresses, and if ipfw has been restarted, that
> address will NOT be in its table of addresses to block. Might that
> explain what you're seeing?
>
> Whenever in doubt, just run 'ipfw table \(port22\) list'. Also, when
> listing ipfw rules, it's helpful to use 'ipfw -t show' which shows all
> rules with their packet and byte counters, plus the date last used for
> each rule. Or even just 'ipfw -t show 4022' or whatever.
>
02022 204 19920 Wed Nov 15 12:41:36 2017 deny log tcp from
table(port22) to any dst-port 22
>
>
> > >> I could see more entries with more than 3/1, for example:
> > >>
> > >> 89.160.221.132/32:22 OK 18/1 2017/11/13 00:01:21
> > >> 60.125.42.119/32:22 OK 3/1 2017/11/12 16:13:53
> > >> 166.62.35.180/32:22 OK 3/1 2017/11/10 06:36:25
> > >> 202.162.221.51/32:22 OK 6/1 2017/11/10 00:42:14
> > >> 168.0.114.130/32:22 OK 3/1 2017/11/10 23:40:30
> > >> 95.145.71.165/32:22 OK 3/1 2017/11/11 07:07:07
> > >> 123.161.206.210/32:22 OK 3/1 2017/11/12 18:14:00
> > >> 203.146.208.208/32:22 OK 6/1 2017/11/10 10:16:21
> > >> 149.56.223.241/32:22 OK 1/1 2017/11/12 06:09:16
> > >> 121.169.217.98/32:22 OK 9/1 2017/11/12 21:59:57
> > >> 211.251.237.162/32:22 OK 2/1 2017/11/13 12:08:07
> > >> 103.99.0.116/32:22 OK 30/1 2017/11/10 14:56:07
> > >>
> > >> These records I am not sure if they were not increased after added to
> > >> ipfw list. but the 1662 times one, I am sure it was increased after
> ipfw
> > >> had the ip in list.
>
> But perhaps ipfw was restarted, and lost either the rule or the table?
> Remember, ipfw does not keep its tables between runs, without scripting.
>
To explain to Kurt, this is concerning the issue failed number increased
> > >>
> > >> 89.160.221.132/32:22 OK 18/1 2017/11/13 00:01:21
> > >> 60.125.42.119/32:22 OK 3/1 2017/11/12 16:13:53
> > >> 166.62.35.180/32:22 OK 3/1 2017/11/10 06:36:25
> > >> 202.162.221.51/32:22 OK 6/1 2017/11/10 00:42:14
> > >> 168.0.114.130/32:22 OK 3/1 2017/11/10 23:40:30
> > >> 95.145.71.165/32:22 OK 3/1 2017/11/11 07:07:07
> > >> 123.161.206.210/32:22 OK 3/1 2017/11/12 18:14:00
> > >> 203.146.208.208/32:22 OK 6/1 2017/11/10 10:16:21
> > >> 149.56.223.241/32:22 OK 1/1 2017/11/12 06:09:16
> > >> 121.169.217.98/32:22 OK 9/1 2017/11/12 21:59:57
> > >> 211.251.237.162/32:22 OK 2/1 2017/11/13 12:08:07
> > >> 103.99.0.116/32:22 OK 30/1 2017/11/10 14:56:07
> > >>
> > >> These records I am not sure if they were not increased after added to
> > >> ipfw list. but the 1662 times one, I am sure it was increased after
> ipfw
> > >> had the ip in list.
>
> But perhaps ipfw was restarted, and lost either the rule or the table?
> Remember, ipfw does not keep its tables between runs, without scripting.
>
after the rule was in ipfw list.
Just catch "fresh" log:
$ sudo blacklistctl dump -b
address/ma:port id nfail last access
94.23.73.97/32:22 OK 2/2 2017/11/15 11:58:11
123.59.135.58/32:22 OK 3/2 2017/11/15 12:10:12
132.148.128.234/32:22 OK 2/2 2017/11/15 12:13:42
$ sudo blacklistctl dump -b
address/ma:port id nfail last access
94.23.73.97/32:22 OK 2/2 2017/11/15 11:58:11
123.59.135.58/32:22 OK 3/2 2017/11/15 12:10:12
132.148.128.234/32:22 OK 3/2 2017/11/15 12:15:40
IPFW log:
Nov 15 12:13:42 res kernel: ipfw: 2022 Deny TCP 132.148.128.234:6920
192.168.11.15:22 in via em0
Nov 15 12:14:09 res last message repeated 14 times
Nov 15 12:15:41 res last message repeated 4 times
based on the log, assume the ipfw not restarted (since no new rule added?)
and banned the IP 132.148.128.234 properly?
in case I am right, the question is why the number increased from 2/2 to
3/2?
blacklistd.log:
Nov 15 12:13:42 res blacklistd[22100]: blocked 132.148.128.234/32:22 for -1
seconds
Nov 15 12:15:40 res blacklistd[22100]: rule exists OK
Nov 15 12:15:40 res blacklistd[22100]: blocked 132.148.128.234/32:22 for -1
seconds
blacklistd-helper.log:
Wed Nov 15 12:13:42 CET 2017 /usr/libexec/blacklistd-helper run add
blacklistd tcp 132.148.128.234 32 22
Wed Nov 15 12:15:40 CET 2017 /usr/libexec/blacklistd-helper run rem
blacklistd tcp 132.148.128.234 32 22 OK
Wed Nov 15 12:15:40 CET 2017 /usr/libexec/blacklistd-helper run add
blacklistd tcp 132.148.128.234 32 22
ipfw list:
$ sudo ipfw table port22 list
--- table(port22), set(0) ---
...
132.148.128.234/32 0
...
manually.
with kind regards
Kurt Lidl
Nov 15, 2017, 11:03:05 AM11/15/17
to
On 11/15/17 6:46 AM, Cos Chan wrote:
> blacklistd.log:
> Nov 15 12:13:42 res blacklistd[22100]: blocked 132.148.128.234/32:22
> <http://132.148.128.234/32:22> for -1 seconds
> blacklistd.log:
> Nov 15 12:13:42 res blacklistd[22100]: blocked 132.148.128.234/32:22
> Nov 15 12:15:40 res blacklistd[22100]: rule exists OK
> Nov 15 12:15:40 res blacklistd[22100]: blocked 132.148.128.234/32:22
> <http://132.148.128.234/32:22> for -1 seconds
> Nov 15 12:15:40 res blacklistd[22100]: blocked 132.148.128.234/32:22
The "-1 seconds" looks fishy to me.
What is the /etc/blacklistd.conf on this machine?
-Kurt
Cos Chan
Nov 15, 2017, 4:28:22 PM11/15/17
to
On Wed, Nov 15, 2017 at 5:02 PM, Kurt Lidl <li...@freebsd.org> wrote:
> On 11/15/17 6:46 AM, Cos Chan wrote:
>
> blacklistd.log:
>> Nov 15 12:13:42 res blacklistd[22100]: blocked 132.148.128.234/32:22 <
>> http://132.148.128.234/32:22> for -1 seconds
>> Nov 15 12:15:40 res blacklistd[22100]: rule exists OK
>> Nov 15 12:15:40 res blacklistd[22100]: blocked 132.148.128.234/32:22 <
>> http://132.148.128.234/32:22> for -1 seconds
>>
>
> The "-1 seconds" looks fishy to me.
>
> What is the /etc/blacklistd.conf on this machine?
the blacklistd.conf was here under while I got above logs:
> On 11/15/17 6:46 AM, Cos Chan wrote:
>
> blacklistd.log:
>> Nov 15 12:13:42 res blacklistd[22100]: blocked 132.148.128.234/32:22 <
>> http://132.148.128.234/32:22> for -1 seconds
>> Nov 15 12:15:40 res blacklistd[22100]: rule exists OK
>> Nov 15 12:15:40 res blacklistd[22100]: blocked 132.148.128.234/32:22 <
>> http://132.148.128.234/32:22> for -1 seconds
>>
>
> The "-1 seconds" looks fishy to me.
>
> What is the /etc/blacklistd.conf on this machine?
# adr/mask:port type proto owner name nfail disable
[local]
ssh stream * * * 2 *
ftp stream * * * 2 *
smtp stream * * * 2 *
# adr/mask:port type proto owner name nfail disable
smtp stream * * * 2 *
[remote]
>
>
> -Kurt
>
>
--
with kind regards
Cos Chan
Nov 15, 2017, 5:14:08 PM11/15/17
to
On Mon, Nov 13, 2017 at 6:37 PM, Kurt Lidl <li...@freebsd.org> wrote:
> Greetings all!
>
> Sorry for not being response to your request for help sooner.
>
> I had a bit of a hardware crisis here last week, where
> what I thought was merely a blown power supply turned
> out to be a failed motherboard. Getting the 2.5" SAS
> drives back up and running in a different machine took
> far longer than I would have guessed. That, along with
> a secondary MX host that was offline for the first 36
> hours after the main mail server went down was a cause
> for additional excitement.
>
> Anyway.
>
> I've read through the mail exchange, although its a bit
> hard to follow all of it.
>
> I'll offer a couple of observations about blacklistd
> and how it operates, and maybe that will shed some light
> on the problem at hand. If not, well, I'd like to start
> fresh with the current configuration, and what you're
> seeing on your host.
>
Sorry I didn't get this email before, thanks Ian forward me this mail.
> Greetings all!
>
> Sorry for not being response to your request for help sooner.
>
> I had a bit of a hardware crisis here last week, where
> what I thought was merely a blown power supply turned
> out to be a failed motherboard. Getting the 2.5" SAS
> drives back up and running in a different machine took
> far longer than I would have guessed. That, along with
> a secondary MX host that was offline for the first 36
> hours after the main mail server went down was a cause
> for additional excitement.
>
> Anyway.
>
> I've read through the mail exchange, although its a bit
> hard to follow all of it.
>
> I'll offer a couple of observations about blacklistd
> and how it operates, and maybe that will shed some light
> on the problem at hand. If not, well, I'd like to start
> fresh with the current configuration, and what you're
> seeing on your host.
>
>
> Observations that might help:
>
> 1) The blacklistd support in 11.0 was broken in a couple
> of significant ways. The blacklistd support in 11.1 is
> thought to be fully functional. If you're not running 11.1,
> you will need to update to 11.1.
>
11:17:49 UTC 2017
ro...@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC
i386
blocked.
>
> 7) There was a note about different usernames from the same
> remote host. The blacklist support currently does not
> differentiate between usernames. It is just counting the
> number of attempts from a remote IP address.
>
> There's unfinished support for having a "known bad" set of usernames,
> where a single login attempt for that username will block
> the remote address. This will allow (when finished), easy
> blocking of the twenty or so most common usernames that are
> probed.
That is great. My problem is one connection one fail from sshd was not
>
> 7) There was a note about different usernames from the same
> remote host. The blacklist support currently does not
> differentiate between usernames. It is just counting the
> number of attempts from a remote IP address.
>
> There's unfinished support for having a "known bad" set of usernames,
> where a single login attempt for that username will block
> the remote address. This will allow (when finished), easy
> blocking of the twenty or so most common usernames that are
> probed.
registered into blacklistd as one fail.
> Hopefully this will help.
>
> -Kurt
>
>
>>
Cos Chan
Nov 16, 2017, 2:27:50 AM11/16/17
to
get wired entry.
$ sudo blacklistctl dump
address/ma:port id nfail last access
$ sudo cat auth.log | grep 57.83.1.58
Nov 16 07:04:17 res sshd[31112]: Invalid user pi from 57.83.1.58
Nov 16 07:04:17 res sshd[31113]: Invalid user pi from 57.83.1.58
Nov 16 07:04:17 res sshd[31112]: Connection closed by 57.83.1.58 port 51140
[preauth]
Nov 16 07:04:17 res sshd[31113]: Connection closed by 57.83.1.58 port 51144
[preauth]
$ cat blacklistd-helper.log | grep 'Nov 16'
...
Thu Nov 16 07:01:28 CET 2017 /usr/libexec/blacklistd-helper run add
blacklistd tcp 120.237.88.186 32 22
Thu Nov 16 07:14:05 CET 2017 /usr/libexec/blacklistd-helper run add
blacklistd tcp 139.59.111.224 32 22
No action from blacklistd-helper? how could that entry be added to database?
no logs concerning from blacklistd either
$ cat blacklistd.log | grep 'Nov 16'
...
Nov 16 07:01:28 res blacklistd[23916]: blocked 120.237.88.186/32:22 for -1
seconds
Nov 16 07:14:05 res blacklistd[23916]: blocked 139.59.111.224/32:22 for -1
seconds
Ian Smith
Nov 16, 2017, 9:54:29 AM11/16/17
to
On Wed, 15 Nov 2017 11:02:30 -0500, Kurt Lidl wrote:
> On 11/15/17 6:46 AM, Cos Chan wrote:
>
> > blacklistd.log:
> > Nov 15 12:13:42 res blacklistd[22100]: blocked 132.148.128.234/32:22
> > <http://132.148.128.234/32:22> for -1 seconds
> > Nov 15 12:15:40 res blacklistd[22100]: rule exists OK
> > Nov 15 12:15:40 res blacklistd[22100]: blocked 132.148.128.234/32:22
> > <http://132.148.128.234/32:22> for -1 seconds
>
> The "-1 seconds" looks fishy to me.
>
> What is the /etc/blacklistd.conf on this machine?
Whether or not the first block succeeded, which if it had, should have
> On 11/15/17 6:46 AM, Cos Chan wrote:
>
> > blacklistd.log:
> > Nov 15 12:13:42 res blacklistd[22100]: blocked 132.148.128.234/32:22
> > <http://132.148.128.234/32:22> for -1 seconds
> > Nov 15 12:15:40 res blacklistd[22100]: rule exists OK
> > Nov 15 12:15:40 res blacklistd[22100]: blocked 132.148.128.234/32:22
> > <http://132.148.128.234/32:22> for -1 seconds
>
> The "-1 seconds" looks fishy to me.
>
> What is the /etc/blacklistd.conf on this machine?
precluded another one two minutes later .. just on this point:
-1 here means "never remove" ie duration='*', like nfail='*' is also set
to -1 for 'never block'. Noticed in ..
[ here /usr/head/src/contrib/blacklist/ ]
bin/blacklistd.c: update(void)
[..]
if (c.c_duration == -1 || when >= ts.tv_sec) <<<----
continue;
if (dbi.id[0]) {
run_change("rem", &c, dbi.id, 0);
sockaddr_snprintf(buf, sizeof(buf), "%a", ss);
syslog(LOG_INFO, "released %s/%d:%d after %d seconds",
buf, c.c_lmask, c.c_port, c.c_duration);
}
state_del(state, &c);
One of the problems with blocklistd-helper is that return codes from it
are mostly not checked, in some cases it's run as (void)run_change(..)
so it's dependant on the helper script succeeding, and simply ignores
any indicated failure - except possibly for an add operation, where it
returns -1 if it gets a NULL response (empty string I assume) otherwise
it returns 0 after copying the output string to the id (here always OK)
.. but it seems nothing cares about the return code eithe rway ..
A bit more about making the script more robust - and more informative
for debugging, at least re ipfw - is slowly brewing, but I'm running out
of spare time at the moment, and will have to quit digging this deep
into code I'm unlikely ever to run myself :)
[ Cos, do you get any different behaviour if you set duration to some
value other than '*'? 30d should be near enough forever for testing ]
cheers, Ian
Kurt Lidl
Nov 16, 2017, 9:58:02 AM11/16/17
to
On 11/16/17 2:27 AM, Cos Chan wrote:
> In that case I test sshd MaxAuthTries=1 and blacklistd nfail=1 and still
> get wired entry.
>
> $ sudo blacklistctl dump
> address/ma:port id nfail last access
> 57.83.1.58/32:22 <http://57.83.1.58/32:22> 0/1 1970/01/01
> 01:00:00
>
> $ sudo cat auth.log | grep 57.83.1.58
> Nov 16 07:04:17 res sshd[31112]: Invalid user pi from 57.83.1.58
> Nov 16 07:04:17 res sshd[31113]: Invalid user pi from 57.83.1.58
> Nov 16 07:04:17 res sshd[31112]: Connection closed by 57.83.1.58 port
> 51140 [preauth]
> Nov 16 07:04:17 res sshd[31113]: Connection closed by 57.83.1.58 port
> 51144 [preauth]
>
> $ cat blacklistd-helper.log | grep 'Nov 16'
> ...
> Thu Nov 16 07:01:28 CET 2017 /usr/libexec/blacklistd-helper run add
> blacklistd tcp 120.237.88.186 32 22
> Thu Nov 16 07:14:05 CET 2017 /usr/libexec/blacklistd-helper run add
> blacklistd tcp 139.59.111.224 32 22
>
> No action from blacklistd-helper? how could that entry be added to database?
>
> no logs concerning from blacklistd either
>
> $ cat blacklistd.log | grep 'Nov 16'
> ...
> Nov 16 07:01:28 res blacklistd[23916]: blocked 120.237.88.186/32:22
> <http://120.237.88.186/32:22> for -1 seconds
> Nov 16 07:14:05 res blacklistd[23916]: blocked 139.59.111.224/32:22
> <http://139.59.111.224/32:22> for -1 seconds
Pre-auth failures from sshd, where the username isn't found ("Invalid
user pi"), don't count against failed login attempts, because no
authorization was ever attempted by sshd.
I made the decision not to count these against the limit in blacklistd.
There is a message sent from sshd to blacklistd when this occurs (bad
username), but this is the part that isn't implemented in the backend,
for banning addresses that hit known-bad usernames.
I suppose the case could be made that a bad username is just as serious
as a bad password for an existing username. But that's not what the
code does currently. Obviously, the code could be changed to act
differently in this case.
Blacklistd did not originally have any message types, other than
"login successful" and "login failed" for each address.
The "login successful" messages cleared all failed login attempts
for a given address. The "login failed" messages added one to the
count of failed logins for an address. If the count was over the
limit for that service (aka port), an attempt to insert rule(s)
into the packet filter to block that address.
I've added the "abusive behavior" message type, so an application
can signal blacklisted that they want the remote address blocked
immediately. The only thing that sends that is the patches to
sendmail that I have been testing. (Not even the patches in the
/usr/ports do it yet, as that capability didn't exist when I wrote
that set of patches.) The sshd daemon (currently) never sends
"abusive behavior" messages.
The "bad username" message (again, not yet implemented in the backend),
is intended to allow the administrator to configure a list of
bad usernames. If usernames on this list are flagged from an
application, the remote address is should be blocked immediately.
I've struggled a bit in terms of the design for this -- the list of
usernames cannot be tied to password file entries - obviously
one might like to have "pi" on the list of forbidden names, even
though no account exists. I've also torn about the right way
to link up the blacklist rules with the name of the list of
bad usernames to check against.
While I imagine more admins would like to have a single list of
bad usernames, and use that one list for smtp, sshd and whatever
else, others might want to have different lists for one or more
services.
I really should implement *something* and just accept that it will
be flawed and need refinement.
-Kurt
Cos Chan
Nov 16, 2017, 4:03:56 PM11/16/17
to
quite good and clear:
"The nfail field contains the number of failed attempts before access is
blocked"
In my opinion the bad username attempts are exactly same as bad password
blocked"
attempts, all of them are failed attempts.
>
> There is a message sent from sshd to blacklistd when this occurs (bad
> username), but this is the part that isn't implemented in the backend,
> for banning addresses that hit known-bad usernames.
>
> I suppose the case could be made that a bad username is just as serious
> as a bad password for an existing username. But that's not what the
> code does currently. Obviously, the code could be changed to act
> differently in this case.
>
username than bad password.
To my knowledge there could be 3 kinds of bad login attempts: bad username,
bad password and bad authentication method (this one only for sshd?).
Forget username and try several times is acceptable, same as other 2 kinds
of attempts.
And if tried too many times, it should be blocked as attack. Also same as
other 2 kinds of attempts.
I would like to see blacklistd only managing bad attempts no matter which
kind of attempt it is.
>
> I really should implement *something* and just accept that it will
> be flawed and need refinement.
>
> -Kurt
>
with kind regards
Cos Chan
Nov 16, 2017, 4:38:20 PM11/16/17
to
auth.log:
Nov 16 21:31:06 res sshd[37726]: Invalid user a from 79.175.154.178
Nov 16 21:31:06 res sshd[37726]: error: maximum authentication attempts
exceeded for invalid user a from 79.175.154.178 port 32900 ssh2 [preauth]
...
Nov 16 21:46:13 res sshd[37825]: Invalid user oracle from 79.175.154.178
Nov 16 21:46:13 res sshd[37825]: input_userauth_request: invalid user
oracle [preauth]
Nov 16 21:46:13 res sshd[37825]: error: maximum authentication attempts
exceeded for invalid user oracle from 79.175.154.178 port 53278 ssh2
[preauth]
Nov 16 21:46:13 res sshd[37825]: Disconnecting: Too many authentication
failures [preauth]
here says invalid user so should be not registered as failed attempts? But
it did.
$ sudo blacklistctl dump -b
address/ma:port id nfail last access
79.175.154.178/32:22 OK 2/2 2017/11/16 21:46:13
82.135.31.115/32:22 OK 2/2 2017/11/16 21:43:45
The blacklistd-helper.log prove it was added by the invalid user attempts :
Thu Nov 16 21:46:13 CET 2017 /usr/libexec/blacklistd-helper run add
blacklistd tcp 79.175.154.178 32 22
BTW, here shows exactly what Ian expected.
The one "maximum authentication attempts" (=2 failed attempts in my host)
means one nfail in blacklistd.
That is better to update man page which says "number of failed attempts".
And why most of invalid user attempts added as blocked entries but still
few similar attempts not added?
>
>
>
> -Kurt
>
--
with kind regards
Cos Chan
Nov 16, 2017, 4:41:42 PM11/16/17
to
the * to 30d.
I will check again tomorrow.
>
> cheers, Ian
>
--
with kind regards
Ian Smith
Nov 19, 2017, 9:43:23 AM11/19/17
to
On Sat, 18 Nov 2017 23:18:15 +0100, Cos Chan wrote:
> Michael Ross <g...@ross.cx>
Michael, you're still stuck on this loop, let us know if you want out :)
> On Thu, Nov 16, 2017 at 10:40 PM, Cos Chan <rose...@gmail.com> wrote:
> > On Thu, Nov 16, 2017 at 3:53 PM, Ian Smith <smi...@nimnet.asn.au> wrote:
[..]
> >> [ Cos, do you get any different behaviour if you set duration to some
> >> value other than '*'? 30d should be near enough forever for testing ]
> >>
> >
> > RIght, I can't see same "increased after ipfw blocked" issue while I
> > change the * to 30d.
> >
> > I will check again tomorrow.
> >
>
> 2 days test on 30d configuration, there is no issue of increasing fail
> times after IPFW.
>
> So, only * option has such issue?
Maybe. To confirm whether '*' = -1 = 'forever' duration has an issue,
I'd try changing one thing - and only one thing - for another day or so.
first take a full 'blacklistctl dump -ad > file1' for complete state.
and 'ipfw table port66 list', a copy of the config .. everything.
Update blacklistd.conf to change just that one '30d' to '*'
service blacklistd restart
Make observations :) then afterwards 'blacklistctl dump -ad >file2' etc.
Perhaps assisting debugging, in the sources I noticed something that
might benefit some users by a mention in blacklistd(8) under 'Signals'.
If you start blacklistd with the -d switch, as we've seen, it stays in
foreground and sets debug to 1 (debug++). So like before, you get lots
of debug info, but that to stdout and without timestamps.
If instead you start it without -d, blacklistd becomes a daemon and
creates its pidfile, but then doesn't seem to log much detail - which is
normally what you'd want.
But then if you signal sigusr1 (kill -USR1 /var/run/blacklistd.pid) it
increases debug by 1. sigusr2 decreases debug by 1. And sighup, like
any respectable daemon, has blacklistd reread its config - so you should
not really need to run 'service .. restart' on config changes anyway.
There's code that runs with debug > 1 and some even with debug > 2, but
that's likely overkill. But as long as you haven't used -v (to log to
stderr instead of syslog) if you set debug = 1 (or more) you should get
that copious amount of debug info you were getting, but timestamped in
your 'myblacklistd.log' to compare with sshd and blacklistd-helper logs.
Just a thought ..
cheers, Ian
> Michael Ross <g...@ross.cx>
Michael, you're still stuck on this loop, let us know if you want out :)
> On Thu, Nov 16, 2017 at 10:40 PM, Cos Chan <rose...@gmail.com> wrote:
> > On Thu, Nov 16, 2017 at 3:53 PM, Ian Smith <smi...@nimnet.asn.au> wrote:
> >> [ Cos, do you get any different behaviour if you set duration to some
> >> value other than '*'? 30d should be near enough forever for testing ]
> >>
> >
> > RIght, I can't see same "increased after ipfw blocked" issue while I
> > change the * to 30d.
> >
> > I will check again tomorrow.
> >
>
> times after IPFW.
>
> So, only * option has such issue?
Maybe. To confirm whether '*' = -1 = 'forever' duration has an issue,
I'd try changing one thing - and only one thing - for another day or so.
first take a full 'blacklistctl dump -ad > file1' for complete state.
and 'ipfw table port66 list', a copy of the config .. everything.
Update blacklistd.conf to change just that one '30d' to '*'
service blacklistd restart
Make observations :) then afterwards 'blacklistctl dump -ad >file2' etc.
Perhaps assisting debugging, in the sources I noticed something that
might benefit some users by a mention in blacklistd(8) under 'Signals'.
If you start blacklistd with the -d switch, as we've seen, it stays in
foreground and sets debug to 1 (debug++). So like before, you get lots
of debug info, but that to stdout and without timestamps.
If instead you start it without -d, blacklistd becomes a daemon and
creates its pidfile, but then doesn't seem to log much detail - which is
normally what you'd want.
But then if you signal sigusr1 (kill -USR1 /var/run/blacklistd.pid) it
increases debug by 1. sigusr2 decreases debug by 1. And sighup, like
any respectable daemon, has blacklistd reread its config - so you should
not really need to run 'service .. restart' on config changes anyway.
There's code that runs with debug > 1 and some even with debug > 2, but
that's likely overkill. But as long as you haven't used -v (to log to
stderr instead of syslog) if you set debug = 1 (or more) you should get
that copious amount of debug info you were getting, but timestamped in
your 'myblacklistd.log' to compare with sshd and blacklistd-helper logs.
Just a thought ..
cheers, Ian
Ian Smith
Nov 19, 2017, 10:30:58 AM11/19/17
to
On Mon, 20 Nov 2017 01:42:30 +1100, Ian Smith wrote:
> But then if you signal sigusr1 (kill -USR1 /var/run/blacklistd.pid) it
Sorry, that should be "# kill -s USR1 `cat /var/run/blacklistd.pid`"
> But then if you signal sigusr1 (kill -USR1 /var/run/blacklistd.pid) it
from either csh (builtin) or sh (/bin/kill).
Cos Chan
Nov 20, 2017, 11:49:43 AM11/20/17
to
On Sun, Nov 19, 2017 at 3:42 PM, Ian Smith <smi...@nimnet.asn.au> wrote:
> On Sat, 18 Nov 2017 23:18:15 +0100, Cos Chan wrote:
>
> > Michael Ross <g...@ross.cx>
>
> Michael, you're still stuck on this loop, let us know if you want out :)
>
> > On Thu, Nov 16, 2017 at 10:40 PM, Cos Chan <rose...@gmail.com> wrote:
> > > On Thu, Nov 16, 2017 at 3:53 PM, Ian Smith <smi...@nimnet.asn.au>
> wrote:
> [..]
>
> > >> [ Cos, do you get any different behaviour if you set duration to some
> > >> value other than '*'? 30d should be near enough forever for testing
> ]
> > >>
> > >
> > > RIght, I can't see same "increased after ipfw blocked" issue while I
> > > change the * to 30d.
> > >
> > > I will check again tomorrow.
> > >
> >
> > 2 days test on 30d configuration, there is no issue of increasing fail
> > times after IPFW.
> >
> > So, only * option has such issue?
>
> Maybe. To confirm whether '*' = -1 = 'forever' duration has an issue,
> I'd try changing one thing - and only one thing - for another day or so.
>
> first take a full 'blacklistctl dump -ad > file1' for complete state.
> and 'ipfw table port66 list', a copy of the config .. everything.
>
> Update blacklistd.conf to change just that one '30d' to '*'
>
> service blacklistd restart
>
> Make observations :) then afterwards 'blacklistctl dump -ad >file2' etc.
>
I followed the instruction and got bctldumpad for 30d and bctldumpad2 for *
> On Sat, 18 Nov 2017 23:18:15 +0100, Cos Chan wrote:
>
> > Michael Ross <g...@ross.cx>
>
> Michael, you're still stuck on this loop, let us know if you want out :)
>
> > On Thu, Nov 16, 2017 at 10:40 PM, Cos Chan <rose...@gmail.com> wrote:
> > > On Thu, Nov 16, 2017 at 3:53 PM, Ian Smith <smi...@nimnet.asn.au>
> wrote:
> [..]
>
> > >> [ Cos, do you get any different behaviour if you set duration to some
> > >> value other than '*'? 30d should be near enough forever for testing
> ]
> > >>
> > >
> > > RIght, I can't see same "increased after ipfw blocked" issue while I
> > > change the * to 30d.
> > >
> > > I will check again tomorrow.
> > >
> >
> > 2 days test on 30d configuration, there is no issue of increasing fail
> > times after IPFW.
> >
> > So, only * option has such issue?
>
> Maybe. To confirm whether '*' = -1 = 'forever' duration has an issue,
> I'd try changing one thing - and only one thing - for another day or so.
>
> first take a full 'blacklistctl dump -ad > file1' for complete state.
> and 'ipfw table port66 list', a copy of the config .. everything.
>
> Update blacklistd.conf to change just that one '30d' to '*'
>
> service blacklistd restart
>
> Make observations :) then afterwards 'blacklistctl dump -ad >file2' etc.
>
$ cat bctldumpad | grep [3-9]/2
(nothing since all 2/2 or 1/2)
$ cat bctldumpad2 | grep [3-9]/2
153.149.173.211/32:22 OK 3/2 2017/11/20 14:09:45
171.78.235.174/32:22 OK 4/2 2017/11/20 14:18:25
115.146.127.81/32:22 OK 3/2 2017/11/20 14:09:32
60.7.70.205/32:22 OK 3/2 2017/11/20 15:06:30
60.172.229.43/32:22 OK 3/2 2017/11/20 14:51:15
103.48.116.47/32:22 OK 3/2 2017/11/20 14:59:50
122.114.207.2/32:22 OK 3/2 2017/11/20 15:01:41
91.99.102.90/32:22 OK 3/2 2017/11/20 15:02:37
36.189.255.161/32:22 OK 3/2 2017/11/20 15:02:06
Please let me know in case you wanna see diff.
I found another thing might be interesting.
seems even I stop the IPFW the 2/2 will not be increased to 3/2 in case the
duration is 30d instead of *.
short summary :
1. while the duration is *, even IPFW blocks the IP the nfail number is
still increased. (we saw from past logs)
2. while the duration is 30d, even IPFW not running the nfail number would
not be increased to more than maximum one.
>
> Perhaps assisting debugging, in the sources I noticed something that
> might benefit some users by a mention in blacklistd(8) under 'Signals'.
>
> If you start blacklistd with the -d switch, as we've seen, it stays in
> foreground and sets debug to 1 (debug++). So like before, you get lots
> of debug info, but that to stdout and without timestamps.
>
> If instead you start it without -d, blacklistd becomes a daemon and
> creates its pidfile, but then doesn't seem to log much detail - which is
> normally what you'd want.
>
> But then if you signal sigusr1 (kill -USR1 /var/run/blacklistd.pid) it
> increases debug by 1. sigusr2 decreases debug by 1. And sighup, like
> any respectable daemon, has blacklistd reread its config - so you should
> not really need to run 'service .. restart' on config changes anyway.
>
> There's code that runs with debug > 1 and some even with debug > 2, but
> that's likely overkill. But as long as you haven't used -v (to log to
> stderr instead of syslog) if you set debug = 1 (or more) you should get
> that copious amount of debug info you were getting, but timestamped in
> your 'myblacklistd.log' to compare with sshd and blacklistd-helper logs.
>
running well. I could get detailed logs instead.
Seems the command "#kill -USR1 5028" is also working? the 5028 is
blacklistd pid I got from ps -aux.
>
> Just a thought ..
>
> cheers, Ian
>
with kind regards
0 new messages