[Bug 243164] blacklistd not handling masks correctly

[bugzilla-noreply at freebsd.org]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=243164

            Bug ID: 243164
           Summary: blacklistd not handling masks correctly
           Product: Base System
           Version: 12.1-STABLE
          Hardware: Any
                OS: Any
            Status: New
          Severity: Affects Many People
          Priority: ---
         Component: bin
          Assignee: bugs at FreeBSD.org
          Reporter: freebsd at oldach.net

I am afraid the blacklist.conf syntax and description might be a bit
misleading. According to the manpage, an IP address may be specified without
mentioning an explicit mask. The usual assumption obvioulsy being that lack of
a mask spec represents a host address: 192.168.134.99 would be identical to
192.168.134.99/32.

It appears that blacklistd behaves differntly. For the sake of the exercise
consider the following trivial (and complete) /etc/blacklistd.conf:

     # adr/mask:port         type    proto   owner   name    nfail   disable
     [local]
     ssh                     stream  *       *       *       3       3m

     # adr/mask:port         type    proto   owner   name    nfail   disable
     [remote]
     192.168.134.99:ssh      *       *       *       =       *       *

Basically meaning, ssh would be blocked for 3 minutes after 3 unsuccessful
attempts - except when ssh originates at 192.168.134.99, which will always
succeed even if invalid.

Now, I'm not connecting from that host but from 192.168.134.1. When connecting
with an invalid user, access is *NOT* blocked after 3 unsuccessful attempts.
Indeed the debug log shows a successful match:

Jan  7 18:12:08 latitude blacklistd[1565]: processing type=2 fd=6
remote=192.168.134.1:61329 msg=ssh uid=0 gid=0
Jan  7 18:12:08 latitude blacklistd[1565]: listening socket: 192.168.134.3:22
Jan  7 18:12:08 latitude blacklistd[1565]: look:       
target:192.168.134.3:22, proto:6, family:2, uid:0, name:=, nfail:*, duration:*
Jan  7 18:12:08 latitude blacklistd[1565]: check:       target:22, proto:6,
family:*, uid:*, name:*, nfail:3, duration:180
Jan  7 18:12:08 latitude blacklistd[1565]: found:       target:22, proto:6,
family:*, uid:*, name:*, nfail:3, duration:180
Jan  7 18:12:08 latitude blacklistd[1565]: conf_apply: merge:   target:22,
proto:6, family:*, uid:*, name:*, nfail:3, duration:180
Jan  7 18:12:08 latitude blacklistd[1565]: conf_apply: to:     
target:192.168.134.3:22, proto:6, family:2, uid:0, name:=, nfail:*, duration:*
Jan  7 18:12:08 latitude blacklistd[1565]: conf_apply: result: 
target:192.168.134.3:22, proto:6, family:2, uid:*, name:*, nfail:3,
duration:180
Jan  7 18:12:08 latitude blacklistd[1565]: Applied address 192.168.134.1:22
Jan  7 18:12:08 latitude blacklistd[1565]: check:      
target:192.168.134.99:22, proto:*, family:*, uid:*, name:=, nfail:*, duration:*
Jan  7 18:12:08 latitude blacklistd[1565]: found:      
target:192.168.134.99:22, proto:*, family:*, uid:*, name:=, nfail:*, duration:*
Jan  7 18:12:08 latitude blacklistd[1565]: conf_merge: merge:  
target:192.168.134.99:22, proto:*, family:*, uid:*, name:=, nfail:*, duration:*
Jan  7 18:12:08 latitude blacklistd[1565]: conf_merge: to:     
target:192.168.134.1:22, proto:6, family:2, uid:*, name:*, nfail:3,
duration:180
Jan  7 18:12:08 latitude blacklistd[1565]: conf_merge: result: 
target:192.168.134.1:22, proto:6, family:2, uid:*, name:*, nfail:*, duration:*
Jan  7 18:12:08 latitude blacklistd[1565]: Applied address 192.168.134.1:22

Note there are *two* "found:" tokens in the log (one for the [local], and one
for the [remote] part) which states that our source address (192.168.134.1)
does match against 192.168.134.99. This is obviously incorrect.

Now, let's add a proper (host) network mask to /etc/blacklistd.conf

     ...
     # adr/mask:port         type    proto   owner   name    nfail   disable
     [remote]
     192.168.134.99/32:ssh      *       *       *       =       *       *

In this case, access *IS* blocked after three unsucessful attempts. Indeed the
debug log reflects this (first attempt):

Jan  7 18:07:13 latitude blacklistd[1506]: processing type=2 fd=6
remote=192.168.134.1:61301 msg=ssh uid=0 gid=0
Jan  7 18:07:13 latitude blacklistd[1506]: listening socket: 192.168.134.3:22
Jan  7 18:07:13 latitude blacklistd[1506]: look:       
target:192.168.134.3:22, proto:6, family:2, uid:0, name:=, nfail:*, duration:*
Jan  7 18:07:13 latitude blacklistd[1506]: check:       target:22, proto:6,
family:*, uid:*, name:*, nfail:3, duration:180
Jan  7 18:07:13 latitude blacklistd[1506]: found:       target:22, proto:6,
family:*, uid:*, name:*, nfail:3, duration:180
Jan  7 18:07:13 latitude blacklistd[1506]: conf_apply: merge:   target:22,
proto:6, family:*, uid:*, name:*, nfail:3, duration:180
Jan  7 18:07:13 latitude blacklistd[1506]: conf_apply: to:     
target:192.168.134.3:22, proto:6, family:2, uid:0, name:=, nfail:*, duration:*
Jan  7 18:07:13 latitude blacklistd[1506]: conf_apply: result: 
target:192.168.134.3:22, proto:6, family:2, uid:*, name:*, nfail:3,
duration:180
Jan  7 18:07:13 latitude blacklistd[1506]: Applied address 192.168.134.1:22
Jan  7 18:07:13 latitude blacklistd[1506]: check:      
target:192.168.134.99/32:22, proto:*, family:*, uid:*, name:=, nfail:*,
duration:*
Jan  7 18:07:13 latitude blacklistd[1506]: conf_amask_eq: a1: c0a88601 != a2:
c0a88663 [0x20]
Jan  7 18:07:13 latitude blacklistd[1506]: Applied address 192.168.134.1:22

Note there is only a "found:" token against the [local] part of the
configuration file, but not against the [remote] part. Further the "check:"
line clearly states that the (hex) IP addresses 192.168.134.1 and
192.168.134.99 are not identical.

Documentation error or bug?

Note the blacklist.conf manpage contains an example without netmask, however
the description seemingly does not match behaviour:

     # Never block 1.2.3.4
     1.2.3.4:ssh     *       *       *       *       *       *

Also please not I have manually applied the review D22259 updates to my
12-STABLE machine. That does not change behaviour.

-- 
You are receiving this mail because:
You are the assignee for the bug.