2. FreeBSD Doc
  3. books_handbook
  4. Turkish (tr_TR)
  5. Translate

Translation

(itstool) path: sect3/para
A protocol can be used in the third field of a blacklistd rule. The following protocols can be used: <literal>tcp</literal>, <literal>udp</literal>, <literal>tcp6</literal>, <literal>udp6</literal>, or numeric. A wildcard, like in the example, is typically used to match all protocols unless there is a reason to distinguish traffic by a certain protocol.
0/3550
Context English Turkish (tr_TR) State
Enabling Blacklistd
The main configuration for blacklistd is stored in <citerefentry><refentrytitle>blacklistd.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>. Various command line options are also available to change blacklistd's run-time behavior. Persistent configuration across reboots should be stored in <filename>/etc/blacklistd.conf</filename>. To enable the daemon during system boot, add a <literal>blacklistd_enable</literal> line to <filename>/etc/rc.conf</filename> like this:
<prompt>#</prompt> <userinput>sysrc blacklistd_enable=yes</userinput>
To start the service manually, run this command:
<prompt>#</prompt> <userinput>service blacklistd start</userinput>
Creating a Blacklistd Ruleset
Rules for blacklistd are configured in <citerefentry><refentrytitle>blacklistd.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry> with one entry per line. Each rule contains a tuple separated by spaces or tabs. Rules either belong to a <literal>local</literal> or a <literal>remote</literal>, which applies to the machine where blacklistd is running or an outside source, respectively.
Local Rules
An example blacklistd.conf entry for a local rule looks like this:
[local]
ssh stream * * * 3 24h
All rules that follow the <literal>[local]</literal> section are treated as local rules (which is the default), applying to the local machine. When a <literal>[remote]</literal> section is encountered, all rules that follow it are handled as remote machine rules.
Seven fields define a rule separated by either tabs or spaces. The first four fields identify the traffic that should be blacklisted. The three fields that follow define backlistd's behavior. Wildcards are denoted as asterisks (<literal>*</literal>), matching anything in this field. The first field defines the location. In local rules, these are the network ports. The syntax for the location field is as follows:
[<replaceable>address</replaceable>|<replaceable>interface</replaceable>][/<replaceable>mask</replaceable>][:<replaceable>port</replaceable>]
Adressses can be specified as IPv4 in numeric format or IPv6 in square brackets. An interface name like <literal><replaceable>em0</replaceable></literal> can also be used.
The socket type is defined by the second field. TCP sockets are of type <literal>stream</literal>, whereas UDP is denoted as <literal>dgram</literal>. The example above uses TCP, since SSH is using that protocol.
A protocol can be used in the third field of a blacklistd rule. The following protocols can be used: <literal>tcp</literal>, <literal>udp</literal>, <literal>tcp6</literal>, <literal>udp6</literal>, or numeric. A wildcard, like in the example, is typically used to match all protocols unless there is a reason to distinguish traffic by a certain protocol.
In the fourth field, the effective user or owner of the daemon process that is reporting the event is defined. The username or <acronym>UID</acronym> can be used here, as well as a wildcard (see example rule above).
The packet filter rule name is declared by the fifth field, which starts the behavior part of the rule. By default, blacklistd puts all blocks under a pf anchor called <literal>blacklistd</literal> in <filename>pf.conf</filename> like this:
anchor "blacklistd/*" in on $ext_if
block in
pass out
For separate blacklists, an anchor name can be used in this field. In other cases, the wildcard will suffice. When a name starts with a hyphen (<literal>-</literal>) it means that an anchor with the default rule name prepended should be used. A modified example from the above using the hyphen would look like this:
ssh stream * * -ssh 3 24h
With such a rule, any new blacklist rules are added to an anchor called <literal>blacklistd-ssh</literal>.
To block whole subnets for a single rule violation, a <literal>/</literal> in the rule name can be used. This causes the remaining portion of the name to be interpreted as the mask to be applied to the address specified in the rule. For example, this rule would block every address adjoining <literal>/24</literal>.
22 stream tcp * */24 3 24h
It is important to specify the proper protocol here. IPv4 and IPv6 treat /24 differently, that is the reason why <literal>*</literal> cannot be used in the third field for this rule.
This rule defines that if any one host in that network is misbehaving, everything else on that network will be blocked, too.
The sixth field, called <literal>nfail</literal>, sets the number of login failures required to blacklist the remote IP in question. When a wildcard is used at this position, it means that blocks will never happen. In the example rule above, a limit of three is defined meaning that after three attempts to log into <application>SSH</application> on one connection, the IP is blocked.
The last field in a blacklistd rule definition specifies how long a host is blacklisted. The default unit is seconds, but suffixes like <literal>m</literal>, <literal>h</literal>, and <literal>d</literal> can also be specified for minutes, hours, and days, respectively.
The example rule in its entirety means that after three times authenticating to <application>SSH</application> will result in a new PF block rule for that host. Rule matches are performed by first checking local rules one after another, from most specific to least specific. When a match occurs, the <literal>remote</literal> rules are applied and the name, <literal>nfail</literal>, and disable fields are changed by the <literal>remote</literal> rule that matched.
Remote Rules
Remote rules are used to specify how blacklistd changes its behavior depending on the remote host currently being evaluated. Each field in a remote rule is the same as in a local rule. The only difference is in the way blacklistd is using them. To explain it, this example rule is used:

Loading…

No matching activity found.

Browse all component changes

Glossary

English Turkish (tr_TR)
numeric sayısal FreeBSD Doc
Point-to-Point protocol Noktadan Noktaya Protokolü FreeBSD Doc
protocol ilke,protokol FreeBSD Doc
TCP wrapper ağ izleme ve denetim aracı FreeBSD Doc
Traffic Shaping Trafik Biçimlendirme FreeBSD Doc
wildcard character genel arama karakteri FreeBSD Doc

Source information

Source string comment
(itstool) path: sect3/para
Source string location
book.translate.xml:63798
String age
8 months ago
Source string age
a year ago
Translation file
books/tr_TR/handbook.po, string 10455