| BLOCKLISTD(8) | System Manager's Manual | BLOCKLISTD(8) | 
blocklistd —
| blocklistd | [ -dfrv] [-Ccontrolprog] [-cconfigfile] [-Ddbfile] [-Psockpathsfile] [-Rrulename] [-ssockpath] [-ttimeout] | 
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 |