| BLOCKLISTD(8) | System Manager's Manual | BLOCKLISTD(8) |
blocklistd —
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 specified, then it only listens to the socket
path specified by sockpath or if that is not specified
to /var/run/blocklistd.sock. Each notification
contains an (action, port, protocol, address, owner) tuple that identifies 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 getsockname(2).
By examining the port of the local side,
blocklistd can determine if the client program
“owns” the port. By examining the optional address portion 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 presume 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 control script
controlprog is invoked with arguments:
control add <rulename> <proto> <address> <mask> <port>
and should invoke a packet filter command to block the connection
specified by the arguments. The rulename argument can
be set from the command line (default blocklistd).
The script could print a numerical id to stdout as a handle for the rule
that can be used later to remove that connection, but that is not required
as all information to remove the rule is kept.
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 program as necessary.
The following options are available:
-C
controlprogadd,
rem, or flush to add,
remove or flush a firewall rule.tcp, tcp6,
udp, udp6.-c
configuration-D
dbfileblocklistd stores its
state, usually /var/db/blocklistd.db.-dblocklistd disassociates itself from the
terminal unless the -d flag is specified, in which
case it stays in the foreground.-f
control flush <rulename>
-P
sockspathsfileblocklistd will create sockets to listen to. This
is useful for chrooted environments.-R
rulenameblocklistd.-r-s
sockpathblocklistd listens to.-t
timeoutblocklistd polls the state
file to update the rules.-vblocklistd to print diagnostic messages to
stdout instead of
syslogd(8).blocklistd deals with the following signals:
HUPblocklistd to
re-read the configuration file.INT,
TERM & QUITblocklistd to exit in an
orderly fashion.USR1blocklistd to increase the
internal debugging level by 1.USR2blocklistd to decrease the
internal debugging level by 1.blocklistd first appeared in NetBSD
7. FreeBSD support for
blocklistd was implemented in FreeBSD
11.
| April 21, 2020 | NetBSD 10.1 |