Free LPI 202-450 Practice Exam with Questions & Answers | Set: 4

 The htpasswd command is used to create and update user files for basic authentication of HTTP users. The command has several options, but the most relevant ones for this question are:

• -c: This option creates a new file and overwrites it if it already exists. This is not suitable for changing the password of existing users, as it would erase the previous data.
• -n: This option displays the results on standard output rather than updating a file. This is useful for generating password records for other types of data stores, but not for modifying an existing file.
• -D: This option deletes the specified user from the file. This is not what the question asks for, as it wants to change the password, not remove the user.
• -b: This option uses batch mode, which means getting the password from the command line rather than prompting for it. This option is not mentioned in the question, and it is not recommended for security reasons.

Therefore, the correct option is B, which uses the default syntax of htpasswd to change the password of an existing user in the specified file. The command will prompt for the new password and update the file accordingly.

References:

• htpasswd - Manage user files for basic authentication
• How to Create and Use .htpasswd
• Unlocking htpasswd in Linux: Comprehensive Guide with Examples

The newaliases command is a Postfix command that can be used to rebuild all of the alias database files with a single invocation and without the need for any command line arguments. The newaliases command is equivalent to running the postalias command on each file specified by the alias_database parameter in the Postfix main.cf configuration file. The newaliases command reads the text files that contain the alias definitions and creates the indexed files in dbm or db format that are used for fast lookup by the mail system. The newaliases command should be executed whenever the alias database is changed, in order to update the indexed files. For example:

newaliases

The other commands are not equivalent to the newaliases command. The makealiases command is not a valid Postfix command. The postalias command can be used to rebuild a single alias database file, but it requires the file name as an argument. The postmapbuild command is not a valid Postfix command.

References:

• LPIC-2 Exam 202 Objectives, Objective 205.3: Managing a postfix server
• Postfix Basic Configuration, Postfix Documentation
• Postfix manual - aliases(5), Postfix Documentation
• Postfix manual - newaliases(1), Postfix Documentation
• Postfix manual - postalias(1), Postfix Documentation

The Samba service that handles the membership of a file server in an Active Directory domain is winbindd. Winbindd is a daemon that provides a number of services to the Name Service Switch (NSS) capability of the system, such as resolving user and group information from a Windows NT server and authentication. Winbindd can also be used to join a Samba file server to an Active Directory domain and authenticate domain users to access the file shares12 References:

• Chapter 4. Using Samba for Active Directory Integration Red Hat Enterprise Linux 7 - Red Hat Customer Portal
• Winbind: Use of Domain Accounts - SambaWiki

The localhost interface, also known as the loopback interface, is a virtual network interface that allows a host to communicate with itself. It has the IP address 127.0.0.1 for IPv4 and ::1 for IPv6. Some applications use the localhost interface to communicate with other applications running on the same host, such as database servers, web servers, or inter-process communication. Therefore, when the default policy for the netfilter INPUT chain is set to DROP, which means that all incoming packets that do not match any rule are dropped, a rule allowing traffic to localhost should exist to avoid breaking these applications. The rule can be something like this:

iptables -A INPUT -i lo -j ACCEPT

This rule appends a new rule to the INPUT chain that accepts any packet that comes from the loopback interface (lo). The other options are incorrect for the following reasons:

• A. All traffic to localhost must always be allowed. This is false because there may be situations where traffic to localhost should be restricted or filtered, such as for security or performance reasons. For example, some malware may try to exploit vulnerabilities in applications listening on localhost, or some applications may generate excessive traffic on localhost that affects the system resources. Therefore, allowing all traffic to localhost is not always necessary or desirable.
• B. It doesn’t matter; netfilter never affects packets addressed to localhost. This is false because netfilter does affect packets addressed to localhost, unless they are explicitly allowed by a rule or the default policy. Netfilter processes all packets that enter or leave the network stack, regardless of their source or destination address. Therefore, packets addressed to localhost are subject to the same rules and policies as packets addressed to any other host.
• D. syslogd receives messages on localhost. This is false because syslogd does not necessarily receive messages on localhost. Syslogd is a daemon that handles system logging, and it can receive messages from various sources, such as local processes, files, pipes, or remote hosts. Syslogd can be configured to listen on a network socket, such as UDP port 514, but it does not have to listen on localhost. Therefore, allowing traffic to localhost is not required for syslogd to function properly.
• E. The iptables command communicates with the netfilter management daemon netfilterd on localhost to create and change packet filter rules. This is false because there is no such daemon as netfilterd, and the iptables command does not communicate with any daemon on localhost to create and change packet filter rules. The iptables command is a user-space tool that interacts directly with the netfilter kernel module through the netlink socket. Therefore, allowing traffic to localhost is not needed for the iptables command to work.

References: LPIC-2 202 exam objectives, LPIC-2 202-450 Exam Prep: Network Configuration, Netfilter - Wikipedia, Iptables Essentials: Common Firewall Rules and Commands

 TSIG stands for Transaction SIGnature, which is a mechanism for authenticating DNS messages using a shared secret key and a cryptographic hash algorithm. TSIG can be used to secure DNS updates, zone transfers, and queries between DNS servers and clients. To configure a BIND server to use TSIG, the following parameters should be added to the named.conf file:

• A key statement that defines the name, algorithm, and secret of the TSIG key. The name can be any arbitrary string, the algorithm can be one of the supported algorithms such as hmac-md5, hmac-sha1, hmac-sha256, etc., and the secret can be a base64-encoded string that represents the shared secret key. For example:

key “server.example.com” { algorithm hmac-md5; secret “skrKc4DoTzi/takIlPi7JZA==”; };

• A server statement that specifies the IP address or hostname of the remote server that will use the TSIG key, and the name of the key that should be used for communication. For example:

server 192.168.1.10 { keys { “server.example.com”; }; };

• A zone statement that indicates the zone name, type, and file of the zone that will use TSIG, and the name of the key that should be used for updates or transfers. For example:

zone “example.com” { type master; file “example.com.zone”; allow-update { key “server.example.com”; }; allow-transfer { key “server.example.com”; }; };

Option E shows the correct configuration parameters that should be added if the server should use the algorithm hmac-md5 and the key skrKc4DoTzi/takIlPi7JZA==. The other options are incorrect because they either use the wrong syntax, the wrong algorithm, the wrong key name, or the wrong secret.

References:

• LPIC-2 exam 202 objectives, topic 208.2, “Securing a DNS server”
• BIND 9 Administrator Reference Manual, chapter 6, “Access Control Lists and TSIG”
• How to Configure DNS Server with TSIG on CentOS 8