- NetBSD Manual Pages
BLOCKLISTD(8) NetBSD System Manager's Manual BLOCKLISTD(8)
Powered by man-cgi (2021-06-01).
Maintained for NetBSD
by Kimmo Suominen.
Based on man-cgi by Panagiotis Christias.
blocklistd -- block and release ports on demand to avoid DoS abuse
blocklistd [-dfrv] [-C controlprog] [-c configfile] [-D dbfile]
[-P sockpathsfile] [-R rulename] [-s sockpath] [-t timeout]
blocklistd is a daemon similar to syslogd(8) that listens to sockets at
paths specified in the sockpathsfile for notifications from other daemons
about successful or failed connection attempts. If no such file is spec-
ified, then it only listens to the socket path specified by sockspath or
if that is not specified to /var/run/blocklistd.sock. Each notification
contains an (action, port, protocol, address, owner) tuple that identi-
fies the remote connection and the action. This tuple is consulted
against entries in configfile with syntax specified in
blocklistd.conf(5). If an entry is matched, a state entry is created for
that tuple. Each entry contains a number of tries limit and a duration.
The way blocklistd does configuration entry matching is by having the
client side pass the file descriptor associated with the connection the
client wants to blocklist as well as passing socket credentials.
The file descriptor is used to retrieve information (address and port)
about the remote side with getpeername(2) and the local side with
By examining the port of the local side, blocklistd can determine if the
client program ``owns'' the port. By examining the optional address por-
tion on the local side, it can match interfaces. By examining the remote
address, it can match specific allow or deny rules.
Finally blocklistd can examine the socket credentials to match the user
in the configuration file.
While this works well for TCP sockets, it cannot be relied on for unbound
UDP sockets. It is also less meaningful when it comes to connections
using non-privileged ports. On the other hand, if we receive a request
that has a local endpoint indicating a UDP privileged port, we can pre-
sume that the client was privileged to be able to acquire that port.
Once an entry is matched blocklistd can perform various actions. If the
action is ``add'' and the number of tries limit is reached, then a con-
trol script controlprog is invoked with arguments:
control add <rulename> <proto> <address> <mask> <port>
and should invoke a packet filter command to block the connection speci-
fied by the arguments. The rulename argument can be set from the command
line (default blocklistd). The script could print a numerical id to std-
out as a handle for the rule that can be used later to remove that con-
nection, but that is not required as all information to remove the rule
If the action is ``rem'' Then the same control script is invoked as:
control rem <rulename> <proto> <address> <mask> <port> <id>
where id is the number returned from the ``add'' action.
blocklistd maintains a database of known connections in dbfile. On
startup it reads entries from that file, and updates its internal state.
blocklistd checks the list of active entries every timeout seconds
(default 15) and removes entries and block rules using the control pro-
gram as necessary.
The following options are available:
Use controlprog to communicate with the packet filter, usually
/libexec/blocklistd-helper. The following arguments are passed
to the control program:
action The action to perform: add, rem, or flush to add,
remove or flush a firewall rule.
name The rule name.
protocol The optional protocol name (can be empty): tcp, tcp6,
address The IPv4 or IPv6 numeric address to be blocked or
mask The numeric mask to be applied to the blocked or
port The optional numeric port to be blocked (can be empty).
id For packet filters that support removal of rules by
rule identifier, the identifier of the rule to be
removed. The add command is expected to return the
rule identifier string to stdout.
The name of the configuration file to read, usually
The Berkeley DB file where blocklistd stores its state, usually
-d Normally, blocklistd disassociates itself from the terminal
unless the -d flag is specified, in which case it stays in the
-f Truncate the state database and flush all the rules named
rulename are deleted by invoking the control script as:
control flush <rulename>
A file containing a list of pathnames, one per line that
blocklistd will create sockets to listen to. This is useful for
Specify the default rule name for the packet filter rules, usu-
-r Re-read the firewall rules from the internal database, then
remove and re-add them. This helps for packet filters that do
not retain state across reboots.
Add sockpath to the list of Unix sockets blocklistd listens to.
The interval in seconds blocklistd polls the state file to update
-v Cause blocklistd to print diagnostic messages to stdout instead
blocklistd deals with the following signals:
HUP Receipt of this signal causes blocklistd to re-read the configura-
INT, TERM & QUIT
These signals tell blocklistd to exit in an orderly fashion.
USR1 This signal tells blocklistd to increase the internal debugging
level by 1.
USR2 This signal tells blocklistd to decrease the internal debugging
level by 1.
/libexec/blocklistd-helper Shell script invoked to interface with the
/etc/blocklistd.conf Configuration file.
/var/db/blocklistd.db Database of current connection entries.
/var/run/blocklistd.sock Socket to receive connection notifications.
blocklistd.conf(5), blocklistctl(8), npfctl(8), syslogd(8)
blocklistd first appeared in NetBSD 7. FreeBSD support for blocklistd
was implemented in FreeBSD 11.
NetBSD 10.99 April 21, 2020 NetBSD 10.99