Date: Mon, 17 Apr 2023 16:42:32 -0700 From: Doug Hardie <bc979@lafn.org> To: questions@freebsd.org Subject: Re: Blacklistd Issues - Problem Identified Message-ID: <4E4A4B99-D8DF-4C5C-9700-C56F354A9991@sermon-archive.info> In-Reply-To: <8B1C1DCE-75CA-4CE9-A589-329519FB792E@sermon-archive.info> References: <C632EC86-6745-42F9-A5EE-FE604C7A8599@sermon-archive.info> <8B1C1DCE-75CA-4CE9-A589-329519FB792E@sermon-archive.info>
next in thread | previous in thread | raw e-mail | index | archive | help
> On Apr 17, 2023, at 15:32, Doug Hardie <bc979@lafn.org> wrote: >=20 >> On Apr 17, 2023, at 13:38, Doug Hardie <bc979@lafn.org> wrote: >>=20 >> I have been implementing blacklistd. It works fine with postfix and = my web server. However, sshd is not working. I have enabled the = UseBlacklistd configuration line. However, no amount of invalid = id/passwords generate an entry in either blacklistd or pf. Running = ktrace with invalid web requests on blacklistd shows that it obtains the = endpoints properly and calls the helper to do the work. However, when = sending invalid id/passwords via ssh, blacklistd does receive the proper = packets from sshd and it obtains the endpoints, but just ends. It never = calls the helper. I have the entry in blacklistd.conf for that port, = and blacklistd has been restarted many times. Any ideas what I need to = do to get blacklistd to record the calls. There is no table in pf for = that port. However, it appears there needs to be at least one call to = make the table appear. >=20 > Additional information. I set debug mode in blacklistd and send an = invalid ssh login: >=20 > processing type=3D4 fd=3D6 remote=3D10.0.1.6:52462 msg=3D,.lklkj uid=3D0= gid=3D0 > listening socket: 10.0.1.235:xx > look: target:10.0.1.235:xx, proto:6, family:2, uid:0, name:=3D, = nfail:*, duration:* > check: target:8001, proto:6, family:*, uid:*, name:*, nfail:2, = duration:300 > check: target:8000, proto:6, family:*, uid:*, name:*, nfail:2, = duration:300 > check: target:587, proto:6, family:*, uid:*, name:*, nfail:3, = duration:300 > check: target:xx, proto:6, family:*, uid:*, name:*, nfail:2, = duration:300 > found: target:xx, proto:6, family:*, uid:*, name:*, nfail:2, = duration:300 > conf_apply: merge: target:xx, proto:6, family:*, uid:*, name:*, = nfail:2, duration:300 > conf_apply: to: target:10.0.1.235:xx, proto:6, family:2, uid:0, = name:=3D, nfail:*, duration:* > conf_apply: result: target:10.0.1.235:xx, proto:6, family:2, uid:*, = name:*, nfail:2, duration:300 > Applied address 10.0.1.6:xx > Applied address 10.0.1.6:xx > process: initial db state for 10.0.1.6:52462: count=3D0/2 = last=3D1969/12/31 16:00:00 now=3D2023/04/17 15:04:00 > process: final db state for 10.0.1.6:52462: count=3D0/2 = last=3D1969/12/31 16:00:00 now=3D2023/04/17 15:04:00 >=20 > Blacklistd finds the proper ssh entry (port xx - it's not 22). It = does not change the state of that entry though. Running with debug for = an invalid web URL yields basically the same information except that the = initial state show a count and last time. The final state shows the = count incremented. When the web invalid URL count exceeds the = threshold, I do see an entry for "add returns OK". I don't see that for = SSH regardless of the number of attempts. After digging through the code for blacklistd I find that postfix and my = web server call blacklistd with a type of 1 (BL_ADD) and sure enough, = blacklistd calls the helper to add the pf rule. However. sshd calls = with type 4 (BL_BADUSER) and there is a note in the handling of that = type that says "Ignore for now". And that it does, i.e., nothing. So = the problem is in sshd using a type that is not implemented, or in = backlistd which does not implement the BADUSER type. I wonder if = Release 13.2 will fix either of those. -- Doug
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4E4A4B99-D8DF-4C5C-9700-C56F354A9991>