BLACKLISTD.CONF(5)

💅 BLACKLISTD.CONF(5) — the blacklistd.conf file format, bestie edition

Okay so this is the blacklistd.conf(5) page — yes, section 5, file formats, we're in the config weeds today and honestly? iconic. This file is where you tell blacklistd who to block, how hard, and for how long. Let's get into it 🫶

---

✨ NAME ✨

blacklistd.conf — the configuration file format for blacklistd 💖

🌸 DESCRIPTION 🌸

The blacklistd.conf file holds all the configuration entries for blacklistd(8), and it's set up in a fashion similar to inetd.conf(5). Vibes: retro but functional.

Ground rules, no cap:

• Only one entry per line is permitted. One line = one whole thought.
• Every entry must have all fields populated. No half-finished entries, we don't do that here 🙈
• Each field can be separated by a tab or a space — either slaps.
• Comments are denoted by a “#” at the beginning of a line. Put a # at the start and the line is just a little note to yourself ✨

There are two kinds of configuration lines: [local] and [remote]. By default, configuration lines are [local] — meaning the address you specify refers to the addresses on the local machine. To switch between [local] and [remote] configuration lines you can specify the stanzas: “[local]” and “[remote]”. Literally just drop the stanza in and everything after it switches teams 🦋

On [local] and [remote] lines, “*” means use the default, or wildcard match — your pick, it's serving both. In addition, for [remote] lines, “=” means use the values from the matched [local] configuration line. Chef's kiss inheritance, we love to see it 👑

The first four fields — location, type, proto, and owner — are used to match the [local] or [remote] addresses. The last 3 fields — name, nfail, and disable — are used to modify the filtering action. Matchy bits first, action bits after 💅

🎀 the location field

The first field denotes the location as an address, mask, and port. The syntax for the location is:

[<address>|<interface>[/<mask>]:]<port>

The address can be:

• an IPv4 address in numeric format,
• an IPv6 address in numeric format and enclosed by square brackets, or
• an interface name.

⚠️ Mask modifiers are not allowed on interfaces, because interfaces can have multiple addresses in different protocols where the mask has a different size. It's giving "it's complicated" 😭

The mask is always numeric, but the port can be either numeric or symbolic. Slay, flexible port.

🦋 the type, proto, and owner fields

• The second field is the socket type: stream, dgram, or numeric.
• The third field is the protocol: tcp, udp, tcp6, udp6, or numeric.
• The fourth field is the effective user (owner) of the daemon process reporting the event, either as a username or a userid.

🧚 the filter-behavior fields

The rest of the fields control the behavior of the filter. Main character energy, honestly.

The name field is the name of the packet filter rule to be used. Two little special behaviors to know about:

• If the name starts with a hyphen (“-”), then the default rulename is prepended to the given name.
• If the name contains a “/”, the remaining portion of the name is interpreted as the mask to be applied to the address specified in the rule — causing a single rule violation to block the entire subnet for the configured prefix. One boop, whole subnet blocked 🔥

The nfail field contains the number of failed attempts before access is blocked, defaulting to “*” meaning never. And the last field, duration, specifies the amount of time since the last access that the blocking rule should be active, defaulting to “*” meaning forever. The default unit for duration is seconds, but one can specify suffixes for different units, such as “m” for minutes, “h” for hours and “d” for days. Tiny letters, big consequences 💀

💜 how matching actually goes down

Matching is done first by checking the [local] rules individually, in the order of the most specific to the least specific. If a match is found, then the matching [remote] rules are applied. The name, nfail, and duration fields can be altered by the [remote] rule that matched. So the remote rule gets the final say on those three, iykyk 🌈

The [remote] rules can be used for:

• allowing specific addresses,
• changing the mask size (via name),
• the rule that the packet filter uses (also via name),
• the number of failed attempts (via nfail), or
• the duration to block (via duration).

---

🍓 FILES 🍓

• /etc/blacklistd.conf — Configuration file. That's the one, bestie 📁

⭐ EXAMPLES ⭐

        # Block ssh, after 3 attempts for 6 hours on the bnx0 interface
        [local]
        # location      type    proto   owner   name    nfail   duration
        bnx0:ssh        *       *       *       *       3       6h
        [remote]
        # Never block 1.2.3.4
        1.2.3.4:ssh     *       *       *       *       *       *
        # Never block the example IPv6 subnet either
        [2001:db8::]/32:ssh     *       *       *       *       *       *
        # For addresses coming from 8.8.0.0/16 block whole /24 networks instead
        # individual hosts, but keep the rest of the blocking parameters the same.
        8.8.0.0/16:ssh  *       *       *       /24     =       =

Obsessed with the /24 + = + = combo — "keep everything else the same, just make the mask bigger." Rude but efficient 💅

🦋 SEE ALSO 🦋

blacklistctl(8), blacklistd(8) — go read these next, they're the whole ecosystem 🫶

💀 NOTES 💀

Heads up: the blacklistd.conf file has been renamed to blocklistd.conf(8). So if you went looking and the name was different, that's why — you're not losing it, promise 🙈

👑 HISTORY 👑

blacklistd.conf first appeared in NetBSD 7. FreeBSD support for blacklistd.conf was implemented in FreeBSD 11. A whole glow-up timeline, honestly ✨

🌈 AUTHORS 🌈

Christos Zoulas — thank you for your service, king 🫡

---

that's the whole page, no skips, no summaries, every single flag and stanza intact 💖 This was brought to you by the Debian flavour of the page, dated January 13, 2026 — BLACKLISTD.CONF(5), File Formats Manual, signing off 🎀✨