Manually add IP address to blocklistd

1 view
Skip to first unread message

Doug Hardie

unread,
Apr 15, 2026, 5:11:03 PM (7 days ago) Apr 15
to ques...@freebsd.org
I am looking for a way to manually add an address to blocklistd. I wrote a quick program to make calls to the blocklist lib. However, all the visible calls require a connected fd. I am able to fake that. However, to do that the program needs to bind the address to the fd. That only works if the port is unused. blocklistd obtains the port from the fd, I need to add IP addresses for ports that are in use. Bind returns an error as the port is already in use. If I use a random port (unused), the the program properly adds the IP address to blocklistd's database.

I can block the IP address using a blackhole list in pf. However, then I have to remember to remove it later. Blocklistd handles the removal without any manual intervention. in most cases, I believe these addresses are not static and will eventually be provided to another user who I don't need to block. I suppose that I could write a database driven list of IP addresses that I have blocked and have it manage the removal using the blocklistd helper interface which is documented. I am not thrilled about having to duplicate functions.

-- Doug


Doug Hardie

unread,
Apr 15, 2026, 5:12:24 PM (7 days ago) Apr 15
to ques...@freebsd.org

Dag-Erling Smørgrav

unread,
Apr 16, 2026, 7:53:02 AM (7 days ago) Apr 16
to Doug Hardie, ques...@freebsd.org
Doug Hardie <bc...@lafn.org> writes:
> I am looking for a way to manually add an address to blocklistd. I
> wrote a quick program to make calls to the blocklist lib. However,
> all the visible calls require a connected fd. I am able to fake that.

The fd needs to be a a connection to or from the address you want to
block, so I very much doubt that you are able to fake that unless you
are trying to block one of your own addresses. I suppose you could
create a non-blocking socket and call connect() before passing the
socket to blocklistd, but I'm not sure if getpeername() will work unless
the connection succeeds.

tl;dr: blocklistd does not currently support what you want to do.

I suggest you contact the upstream author (Christos at Zoulas dot com /
Christos at NetBSD dot org) and ask him to implement this, or look into
doing so yourself.

DES
--
Dag-Erling Smørgrav - d...@FreeBSD.org

Doug Hardie

unread,
Apr 16, 2026, 6:47:26 PM (6 days ago) Apr 16
to Dag-Erling Smørgrav, ques...@freebsd.org
> On Apr 16, 2026, at 04:52, Dag-Erling Smørgrav <d...@freebsd.org> wrote:
>
> Doug Hardie <bc...@lafn.org> writes:
>> I am looking for a way to manually add an address to blocklistd. I
>> wrote a quick program to make calls to the blocklist lib. However,
>> all the visible calls require a connected fd. I am able to fake that.
>
> The fd needs to be a a connection to or from the address you want to
> block, so I very much doubt that you are able to fake that unless you
> are trying to block one of your own addresses.

I have successfully faked the socket and blocklistd picks up the IP address and port correctly. However, I have to bind the socket address to the socket and bind fails if the port is already in use. If it is not, then blocklistd correctly adds the IP and port into its tables.

> I suppose you could
> create a non-blocking socket and call connect() before passing the
> socket to blocklistd, but I'm not sure if getpeername() will work unless
> the connection succeeds.

A non-blocking port has the same issue with bind. It fails because the port is already in use.

>
> tl;dr: blocklistd does not currently support what you want to do.
>
> I suggest you contact the upstream author (Christos at Zoulas dot com /
> Christos at NetBSD dot org) and ask him to implement this, or look into
> doing so yourself.

I thought about modifying blocklistd, but the place where it picks up the port is not in the library, but deep in the server code. The interface between the library and the server includes the fd. So that would have to be changed to pass the port number rather than the fd. That interface is not documented so it would be a lot of work. I will contact Christos and see what he thinks. Thanks.

-- Doug


Reply all
Reply to author
Forward
0 new messages