202-450 LPIC-2 - Exam 202 (part 2 of 2), version 4.5 Questions and Answers

 The host allow option in the smb.conf file specifies the hosts or networks that are allowed to access the Samba server. The hosts can be specified by name, IP address, or network address with a netmask. The host allow option can also include the special name localhost, which refers to the local machine. The host allow option can be overridden by the host deny option, which specifies the hosts or networks that are denied access to the Samba server. The host deny option has a higher priority than the host allow option.

In this question, the host allow option is set to 192.168.1.100 192.168.2.0/24 localhost, which means that only the host with the IP address 192.168.1.100, the hosts on the network 192.168.2.0/24 (from 192.168.2.1 to 192.168.2.254), and the local machine can access the Samba server. This explains why a wireless laptop with an IP address 192.168.2.93 can access the Samba server, but a workstation on the wired network with an IP address 192.168.1.177 cannot. Almost every machine on the wired network is unable to access the Samba server because they are not included in the host allow option.

To fix this problem, the host allow option should be changed to include the entire wired network, which is assumed to be 192.168.1.0/24 (from 192.168.1.1 to 192.168.1.254). This can be done by using the network address and the netmask, or by using a range of IP addresses. The host allow option should also keep the wireless network and the localhost in the list, so that the existing access is not denied. Therefore, the correct answer is E. host allow = 192.168.1.0/255.255.255.0 192.168.2.0/255.255.255.0 localhost. This will allow any host on either network, or the local machine, to access the Samba server, without denying access to anyone else.

 The line A is valid in a configuration file in /etc/pam.d/ because it follows the correct syntax and semantics of a PAM configuration file. The syntax of a PAM configuration file is:

module_interface control_flag module_name module_arguments

The module_interface specifies the type of authentication action that the module can perform. There are four types of module interface: auth, account, password, and session. The control_flag specifies how important the success or failure of the module is to the overall authentication process. There are four types of control flag: required, requisite, sufficient, and optional. The module_name specifies the name of the library that contains the module. The module_arguments are optional parameters that can modify the behavior of the module.

The line A has the following components:

• module_interface: auth, which means the module is used for user authentication.
• control_flag: required, which means the module must succeed for authentication to continue. If the module fails, the failure is recorded and the rest of the modules are executed.
• module_name: pam_unix.so, which means the module is the standard Unix authentication module that verifies the user’s password against the /etc/passwd and /etc/shadow files.
• module_arguments: try_first_pass nullok, which means the module tries to use the password that was previously entered by the user (if any), and allows users with empty passwords to log in.

The line B is invalid because it has the wrong order of the fields. The control_flag should come before the module_name, not after. The line C is invalid because it uses parentheses and colons instead of spaces to separate the fields. The line D is invalid because it has the wrong syntax for the control_flag. The control_flag should be a single word, not a word in parentheses.

 The OpenLDAP attribute olcBackend is used to specify the backend type for a database entry in the cn=config DIT. The backend type determines how the data is stored and accessed by the OpenLDAP server. There are several backend types available, but not all of them can be used with the olcBackend attribute. The backend types that can be used with the olcBackend attribute are:

• bdb: The Berkeley Database backend, which uses the Berkeley DB library to store the data in files on disk. This backend supports transactions, indexing, replication, and caching. It is the default backend for OpenLDAP and is recommended for most applications.
• ldap: The LDAP backend, which uses another LDAP server as the data source. This backend allows the OpenLDAP server to act as a proxy or a gateway to another LDAP server. It can be used to merge data from multiple LDAP servers, to provide access control or schema mapping, or to implement load balancing or failover.
• text: The text backend, which uses plain text files to store the data. This backend is mainly used for testing purposes or for simple applications that do not require advanced features. It does not support indexing, replication, or caching.

The backend types that cannot be used with the olcBackend attribute are:

• xml: The XML backend, which uses XML files to store the data. This backend is experimental and not recommended for production use. It does not support indexing, replication, or caching.
• passwd: The passwd backend, which uses the /etc/passwd and /etc/group files as the data source. This backend is deprecated and should not be used. It does not support indexing, replication, or caching.

References:

• How To Configure OpenLDAP and Perform Administrative LDAP Tasks
• OpenLDAP Online Configuration Reference - Tyler’s Guides

 In a BIND zone file, the @ character indicates the name of the zone as defined in the zone statement in named.conf. This is also known as the current origin of the zone file. The @ character is a shortcut that allows the zone file to refer to the zone name without typing it fully. For example, if the zone name is example.com, then the @ character can be used instead of example.com. in the zone file. This can save space and avoid typos123 References:

• LPIC-2 Overview
• LPIC-2 202-450
• What’s the meaning of ‘@’ in a DNS zone file? - Server Fault

To create a hidden Samba share, similar to the Windows Administration Share, the share name must end with a dollar sign ().Thiswillpreventthesharefrombeinglistedinthebrowselist,butitcanstillbeaccessedbytypingthefullsharename.OptionAshowsanexampleofahiddenSambasharenamedconfidential, with some additional parameters to configure the share. Option B is incorrect because the share name does not end with a dollar sign. Option C is incorrect because the share name is not enclosed in brackets. Option D is incorrect because the share name contains a space, which is not allowed. Option E is incorrect because the share name is not a valid file name12 References:

• Hiding samba share from browse list for unauthorised users
• Creating a samba share where everyone has write access

To allow X connections to be forwarded from or through an SSH server, the configuration keyword that must be set to yes in the sshd configuration file is XllForwarding. This keyword enables X11 forwarding, which is a mechanism that allows graphical applications to be run on a remote host and displayed on a local host. The sshd configuration file is usually located at /etc/ssh/sshd_config, and the XllForwarding keyword can be set globally or per host. For example:

XllForwarding yes

This will enable X11 forwarding for all hosts. To enable X11 forwarding for a specific host, use the Match directive, followed by the Host keyword and the host name or pattern. For example:

Match Host example.com XllForwarding yes

This will enable X11 forwarding only for the host example.com.

References:

• X11 Forwarding using SSH
• sshd_config - OpenSSH SSH daemon configuration file
• How To Configure X11 Forwarding Using SSH In Linux

 To log into a remote SSH server using SSH keys, the client needs to generate a public and private key pair using the ssh-keygen utility. The private key (~/.ssh/id_rsa) should be kept secret and protected by a passphrase, while the public key (~/.ssh/id_rsa.pub) should be copied to the remote server’s authorized_keys file (~/.ssh/authorized_keys) using the ssh-copy-id utility or manually. The authorized_keys file contains the public keys of the clients that are allowed to log into the server using SSH keys. The client can then use the ssh command with the -i option to specify the private key file to authenticate to the server without entering a password. References:

• LPIC-2 Exam 202 Objectives, Topic 212: System Security, 212.3 Secure shell (SSH) (weight: 4)
• How To Configure SSH Key-Based Authentication on a Linux Server

How To Configure SSH Key-Based Authentication on a Linux Server

 In the main Postfix configuration file, which is usually /etc/postfix/main.cf, service definitions are continued on the next line by starting the following line with white space indentation. This means that the line must begin with one or more spaces or tabs. This is useful when a service definition has many parameters or options that would make the line too long or hard to read. For example, a service definition for the smtpd daemon could look like this:

The first line defines the service name, type, private flag, unpriv flag, chroot flag, wakeup time, maxproc limit, and command. The following lines, indented with white space, define additional options for the smtpd command, such as the syslog name, the SASL authentication, and the recipient restrictions. Each option is prefixed with -o and separated by white space.

References: You can find more information about the main Postfix configuration file and the service definition syntax in the following resources:

• Postfix Basic Configuration
• Postfix Architecture Overview

The rpc.idmapd service is a new component of NFSv4 that does not exist in NFSv3. It is responsible for mapping user and group IDs between the NFS client and server, using string names instead of numeric values. This allows for better security and compatibility across different systems. The rpc.idmapd service runs on both the NFS client and server and communicates with each other using the NFSv4 protocol. The other services, rpc.statd, nfsd, and rpc.mountd, are common to both NFSv3 and NFSv4, although they have some differences in functionality and behavior. References: 1, 2, 3

The command that displays NFS kernel statistics is nfsstat. This command can be used to show information about the number and type of NFS and RPC calls made by the NFS client or server. It can also be used to reset the statistics to zero, or to display information about mounted NFS file systems. The nfsstat command is part of the nfs-utils package and can be installed on most Linux distributions. For more information about the nfsstat command, you can refer to the following resources:

• 1: A Microsoft Learn article that explains the syntax and usage of the nfsstat command on Windows Server.
• 2: A Bing search result page that shows various links and snippets related to the nfsstat command.
• 3: A Red Hat article that demonstrates how to use the nfsstat and nfsiostat commands to troubleshoot NFS performance issues on Linux.

Samba cannot use /etc/passwd and /etc/shadow directly because they store passwords in a different format than CIFS. CIFS passwords are encrypted using a one-way hash function, while Unix passwords are encrypted using a two-way cipher. Therefore, Samba needs a separate password file that stores the CIFS passwords in a compatible format. This file is usually called smbpasswd and can be created or updated using the smbpasswd command123 References:

• Chapter 9. Users and Security - Samba
• smbpasswd - Samba
• Chapter 20. samba authentication - linux-training.be

Chapter 9. Users and Security - Samba3

Chapter 9. Users and Security - Samba

The commands nc and telnet can be used to connect and interact with remote TCP network services. nc stands for netcat, a utility that can read and write data across network connections using TCP or UDP protocols. telnet is a client-server protocol that allows a user to communicate with a remote host using a virtual terminal. Both commands can be used to test the connectivity and functionality of network services such as web servers, mail servers, FTP servers, etc. by specifying the host name or IP address and the port number of the service. References:

• LPIC-2 exam 201 topics, section 205.1, “Use and configure network monitoring tools”.
• LPIC-2 exam 202 topics, section 208.1, “Implementing a web server”.
• Linux Essentials 010 exam objectives, section 4.3, “Basic network configuration and troubleshooting”.

When using a web server certificate that is signed by an intermediate certification authority, the web server must also send the intermediate certificate to the client browser, so that the browser can verify the whole chain of trust. To do this, the web server must have both the web server certificate and the intermediate certificate in one file, which is specified in the SSLCertificateFile directive of Apache HTTPD. This way, the web server can send both certificates to the client in one response. The order of the certificates in the file is important: the web server certificate must come first, followed by the intermediate certificate. The file can be created by concatenating the two certificates with a text editor or the cat command. References:

• LPIC-2 202 exam objectives, topic 218.1: Implementing HTTPS
• Apache HTTPD documentation, section: SSLCertificateFile Directive
• How to install an Intermediate SSL Certificate on Apache

 In the context of configuring Nginx for reverse proxy, the proxy_pass directive is used to specify the protocol and address of a proxied server and an optional URI to which a location should be mapped. So, in the provided configuration sample, “proxy_pass” is the missing keyword that should precede “http://proxiedserver:8080;”.

References:

• [NGINX Docs | NGINX Reverse Proxy]: The official documentation of Nginx on how to set up a reverse proxy with Nginx.
• [How To Configure Nginx as a Web Server and Reverse Proxy for Apache on One Ubuntu 20.04 Server | DigitalOcean]: A tutorial from DigitalOcean on how to configure Nginx as a web server and reverse proxy for Apache on Ubuntu 20.04, which includes the use of the proxy_pass directive.

In Apache HTTPD configuration, only one ServerName directive is allowed per VirtualHost block. The ServerName provides the hostname and port that the server uses to identify itself. If there are additional domain names pointing to the same virtual host, they should be added using the ServerAlias directive. For example, the following configuration would create a virtual host that responds to both www.example.com and www2.example.com:

ServerName www.example.com ServerAlias www2.example.com ServerAdmin webmaster@example.com DocumentRoot /var/www/ Require all granted

The ServerName and ServerAlias directives are usually included in such configuration files. To enable or disable a virtual host, we can use the a2ensite and a2dissite commands to create and remove the symbolic links in the sites-enabled directory. For more information about the ServerName and ServerAlias directives, you can refer to the following resources:

• 1: A Microsoft Learn article that explains the syntax and usage of the ServerName and ServerAlias directives on Windows Server.
• 2: A Stack Overflow question that discusses the difference between ServerName and ServerAlias in Apache configuration.
• 3: A Stack Overflow question that shows how to redirect ServerAlias to ServerName in Apache configuration.

 The dig tool is a command-line utility that can query DNS servers and display the results in a human-readable format. The output of dig includes the following sections:

• The header section, which shows the query parameters and response status.
• The question section, which repeats the query name and type.
• The answer section, which shows the resource records that match the query.
• The authority section, which shows the authoritative name servers for the queried domain.
• The additional section, which shows any additional records that may be useful.

The output format of dig is similar to the image provided in the question, which shows the following information:

• The query was for the A record of www.lpi.org.
• The response was received from the DNS server 8.8.8.8.
• The response had an opcode of QUERY, a status of NOERROR, and a flags of QR RD RA.
• The response had 1 question, 1 answer, 0 authority, and 0 additional records.
• The answer record was www.lpi.org. 300 IN A 104.21.23.156, which means that the IP address of www.lpi.org is 104.21.23.156 and has a time-to-live of 300 seconds.

References: dig manual page, dig tutorial

The doveadm who sub-command shows information about the currently connected users and their sessions. The output includes the following columns:

• user: The username of the connected user.
• ip: The IP address of the client.
• port: The port number of the client.
• service: The name of the Dovecot service, such as imap, pop3, lmtp, etc.
• protocol: The protocol version used by the client, such as IMAP4rev1, POP3, etc.
• pid: The process ID of the Dovecot process that handles the connection.
• type: The type of the connection, such as tcp, ssl, etc.
• state: The state of the connection, such as running, idle, etc.
• since: The time when the connection was established.

References:

• doveadm-who - Dovecot Wiki
• LPIC-2 exam 202 objectives, topic 211.3, “Managing Mailbox Access”

The option that would tell OpenVPN to use a dynamic source port when making a connection to a peer is nobind. This option instructs OpenVPN to not bind to a specific local port number, but instead use an ephemeral port number chosen by the operating system. This allows multiple OpenVPN instances to connect to the same remote server or peer without port conflicts. The other options are either invalid or have different meanings:

• src-port: This is not a valid OpenVPN option and will cause an error.
• remote: This option specifies the host name or IP address and port number of the remote server or peer to connect to. It does not affect the source port of the client.
• source-port: This is not a valid OpenVPN option and will cause an error.
• dynamic-bind: This is not a valid OpenVPN option and will cause an error.

References: LPIC-2 202 exam objectives, LPIC-2 202-450 Exam Prep: Network Configuration, Reference Manual For OpenVPN 2.4

 OpenVAS is a network security scanner project that, at the core, is a server with a set of network vulnerability tests (NVTs) to detect security problems in remote systems and applications. It is an open-source tool that was forked from Nessus, a popular commercial scanner. OpenVAS can perform comprehensive scans of networks and hosts, as well as web application scanning and compliance testing. It also provides a graphical user interface (GUI) and a command-line interface (CLI) for managing scans and reports. References:

• Greenbone Vulnerability Management - Gentoo wiki
• The Best Network Vulnerability Scanners Tested in 2023 - Comparitech

In the context of LDAP, when alterations need to be specified to an entry, the “changetype: modify” keyword is used in the LDIF file. This keyword indicates that modifications are to be made to the existing LDAP entry. The modify operation can be used to add, replace, or delete attributes and their values. The syntax of the modify operation is as follows:

changetype: modify add: attribute attribute: valuereplace: attribute attribute: valuedelete: attribute attribute: value

Each modify operation is separated by a hyphen (-) and a blank line separates different entries. The attribute;binary subtype can be used to indicate that the attribute values are binary data. The LDIF syntax for reading a binary value from a file is:

attribute;binary:< file:///path/to/file

References:

• LPIC-2 Exam 202 Objectives, Objective 207.3: LDAP Operations
• How To Use LDIF Files to Make Changes to an OpenLDAP System, DigitalOcean
• Modifying Entries Using ldapmodify, Oracle
• ldap - ldapadd/ldapmodify: clarifications needed about these commands, Server Fault
• Modify Attribute type definition on LDAP server, Stack Overflow

The two commands shown in the image are used to drop packets with source or destination addresses from fe80::/64 in the FORWARD chain. The first command drops packets with source addresses from fe80::/64, while the second command drops packets with destination addresses from fe80::/64. Both commands will complete without an error message or warning because the affected network is not already part of another rule. The other statements are incorrect for the following reasons:

• B. The rules disable packet forwarding because network nodes always use addresses from fe80::/64 to identify routers in their routing tables. This is false because network nodes do not use link-local addresses to identify routers in their routing tables. Instead, they use global or unique local addresses that are advertised by routers through router advertisements or DHCPv6.
• C. ip6tables returns an error for the second command because the affected network is already part of another rule. This is false because there is no indication that the affected network is already part of another rule. Even if it was, ip6tables would not return an error, but rather append the new rule to the existing ones, unless the -I option was used to insert the new rule at a specific position.
• E. The rules suppress any automatic configuration through router advertisements or DHCPv6. This is false because the rules only affect the FORWARD chain, which is used to process packets that are routed through the router. The rules do not affect the INPUT or OUTPUT chains, which are used to process packets that are destined for or originated from the router. Therefore, the rules do not interfere with the router’s ability to send or receive router advertisements or DHCPv6 messages.

References: LPIC-2 202 exam objectives, LPIC-2 202-450 Exam Prep: Network Configuration, IPv6 Firewalling with ip6tables, IPv6 Addressing and Basic Connectivity

When the rootdn and rootpw directives are not present in the slapd.conf file, the LDAP administrator account is defined in the file /etc/ldap.secret. This file contains the password for the LDAP root user, which is usually cn=admin,dc=example,dc=com. The file should be owned by root and have permissions of 600 to prevent unauthorized access. The file is referenced by the olcRootPW directive in the cn=config database, which is used to configure the LDAP server. The olcRootPW directive can also be set by using the ldappasswd command with the -Y EXTERNAL option, which allows the LDAP server to authenticate itself to itself using the SASL EXTERNAL mechanism12.

References:

• How To Configure OpenLDAP and Perform Administrative LDAP Tasks | DigitalOcean: A tutorial from DigitalOcean on how to configure OpenLDAP and perform administrative LDAP tasks, which includes the use of the /etc/ldap.secret file and the ldappasswd command.
• OpenLDAP Software 2.6 Administrator’s Guide: Configuring slapd: The official documentation of OpenLDAP on how to configure the slapd daemon, which includes the description of the olcRootPW directive and the SASL EXTERNAL mechanism.

Sieve is a language for filtering and sorting email messages on a mail server. Sieve core filters are the basic actions that can be applied to a message that matches a set of conditions. The following actions are available in Sieve core filters:

• discard: This action discards the message silently, without sending any notification to the sender or the recipient. This action is useful for deleting spam or unwanted messages.
• fileinto: This action delivers the message to a specified mailbox. The mailbox can be an existing one or a new one that is created by the action. This action is useful for organizing messages into different folders based on their content or headers.
• reject: This action rejects the message and sends a notification to the sender with a specified reason. The message is not delivered to the recipient. This action is useful for informing the sender that the message was not accepted due to some policy or error.

The other options are not valid actions in Sieve core filters. drop, relay, and fileinto are not recognized keywords by Sieve.

References:

• Sieve: An Email Filtering Language, section 2.10, “Actions”
• Sieve Tutorial, section 4, “Actions”

 The mydestination parameter in the Postfix main.cf configuration file specifies the list of domains that are delivered via the $local_transport mail delivery transport. This means that Postfix will accept mail for those domains and deliver it to local mailboxes. To accept mail for both the old and new domain names, the mydestination parameter should include both domains, separated by commas. For example:

mydestination = olddomain.com, newdomain.com, localhost

This will allow Postfix to accept mail for user@olddomain.com and user@newdomain.com and deliver it to the same local user mailbox.

References:

• LPIC-2 Exam 202 Objectives, Objective 205.3: Managing a postfix server
• Postfix Basic Configuration, Postfix Documentation
• Postfix Configuration Parameters: mydestination, Postfix Documentation
• How to configure Postfix to receive mail for multiple domains, Server Fault

The standard port used by OpenVPN is 1194. OpenVPN is a VPN daemon that supports SSL/TLS security, ethernet bridging, TCP or UDP tunnel transport, and other features. OpenVPN can be configured to listen on any port, but the default port is 1194, which is registered with the IANA for OpenVPN. The port number can be specified in the OpenVPN configuration file using the port directive. For example:

port 1194

This will instruct OpenVPN to listen on port 1194. The port number must match on both the server and the client sides of the connection. The port number can also be specified as an argument to the openvpn command. For example:

openvpn --port 1194

This will run OpenVPN with port 1194 as the default port.

References:

• Reference Manual For OpenVPN 2.6 | OpenVPN
• Reference Manual For OpenVPN 2.0 | OpenVPN
• Which ports to open for VPN PPTP, L2TP, IPsec, OpenVPN and … - ITIGIC

 The option within the ISC DHCPD configuration file that defines the IPv4 DNS server address(es) to be sent to the DHCP clients is domain-name-servers. This option takes one or more IPv4 addresses as arguments and specifies the DNS servers that the client should use for name resolution. The domain-name-servers option is part of the standard DHCP options defined in RFC 2132 and is supported by the ISC DHCP server. The domain-name-servers option can be specified globally, per subnet, per shared network, per group, or per host in the dhcpd.conf file. For example, the following line in the dhcpd.conf file will assign the DNS servers 192.168.1.1 and 192.168.1.2 to all DHCP clients:

option domain-name-servers 192.168.1.1, 192.168.1.2;

References:

• ISC DHCP 4.4 Manual Pages - dhcp-options
• [RFC 2132 - DHCP Options and BOOTP Vendor Extensions]
• isc-dhcp-server - Community Help Wiki - Official Ubuntu Documentation

The PAM module that sets and unsets environment variables is pam_env. This module allows the (un)setting of environment variables based on the rules specified in the configuration file /etc/security/pam_env.conf or an alternative file. The module can also read a file with simple KEY=VAL pairs on separate lines (/etc/environment by default) or a user-specific file ($HOME/.pam_environment by default). The pam_env module supports the use of previously set environment variables as well as PAM_ITEMs such as PAM_RHOST. The pam_env module should be the last one on the stack, as setting PAM environment variables can have side effects on other modules. The pam_env module provides the auth and session module types. References:

• pam_env - PAM module to set/unset environment variables
• pam_env(8) - Linux manual page

The redirect action in a Sieve filter forwards a message to another email address without changing the message. The redirect action takes a single argument, which is the email address to forward the message to. The syntax of the redirect action is as follows:

redirect "email_address";

The redirect action does not affect the delivery of the message to the original recipient, unless the stop or keep actions are used. The redirect action can be combined with other actions or tests to create more complex filters. For example, the following Sieve filter will forward any messages from Alice to Bob, and then stop processing the rest of the script:

require "fileinto"; if address :is "from" "alice@example.com" { redirect "bob@example.com"; stop; }

References:

• LPIC-2 Exam 202 Objectives, Objective 205.4: Managing a dovecot server
• Sieve filter (advanced custom filters) | Proton, Proton Mail Support
• Sieve: An Email Filtering Language, RFC 5228
• Sieve Email Filtering | Tiger Technologies Support, Tiger Technologies Support
• [Sieve: A Mail Filtering Language], Sieve.Info

DNSSEC adds digital signatures to DNS records, which can be verified by the clients using public keys. This way, DNSSEC ensures that the DNS responses are authentic and have not been tampered with by attackers. DNSSEC does not encrypt DNS queries or answers, nor does it authenticate the user or the nameserver123

What is DNSSEC on DNS Server in Windows Server?1

How DNSSEC Works | Cloudflare

 The error message in the image is saying that the program vsftpd is unable to find the required shared library file. This is because the program is running in a chroot jail, which restricts the program’s access to the file system. To fix this error, the required library file must be copied to the appropriate lib directory in the chroot jail. This will allow the program to access the file and run properly. References:

• LPIC-2 Overview
• LPIC-2 201-450
• LPIC-2 202-450

Fail2ban is a tool that monitors the system logs for failed login attempts and blocks the offending IP addresses using netfilter rules. Netfilter is a framework that provides packet filtering, network address translation, and other functions for the Linux kernel. Fail2ban uses the iptables command to manipulate the netfilter rules and create chains of rules that match the source IP address of the attacker and drop or reject the packets from that IP address. Fail2ban can also use other firewall tools, such as firewalld or ufw, to create the netfilter rules. Fail2ban can block the IP addresses for a specified amount of time, or permanently, depending on the configuration. Fail2ban can protect various services, such as SSH, HTTP, FTP, etc., by creating different jails for each service. A jail is a set of parameters that define how to monitor a log file, how to detect a failed login attempt, how to ban an IP address, and how long to keep the ban.

Fail2ban does not block offending SSH clients by any of the other options. It does not act as a proxy in front of SSHD, nor does it modify the SSHD configuration. It does not create null routes that drop any answer packets sent to the client, nor does it modify the TCP Wrapper configuration for SSHD.

References:

• How To Protect SSH with Fail2Ban on Ubuntu 20.04
• How To Prevent SSH Brute Force Attacks Using Fail2ban In Linux
• Fail2ban - Wikipedia
• Fail2ban Manual

 The command exportfs is used to configure which file systems a NFS server makes available to clients. The exportfs command maintains a table of exported file systems in the /etc/exports file, which specifies the directories to be shared and the options for each host or network. The exportfs command can also be used to add, remove, or refresh the exported file systems without restarting the NFS service123 References:

• 8.6. Configuring the NFS Server - Red Hat Customer Portal
• How to configure NFS on Linux - Learn Linux Configuration
• How to configure Network File System on Linux | Enable Sysadmin