tcpdmatch

tcpdmatch [-d] [-i infile] [-r] service client

service
    The name of the network service to test (e.g., sshd, vsftpd). This name must match entries in /etc/hosts.allow or /etc/hosts.deny.

client
    The client hostname or IP address (e.g., example.com, 192.168.1.100) to test access for.

-d
    Enables debug mode, providing verbose output about how the rules are parsed and matched. This is useful for understanding the decision-making process.

-i infile
    Specifies an alternate configuration file to use instead of the default /etc/hosts.allow and /etc/hosts.deny. This allows testing new rules before deploying them system-wide.

-r
    Forces tcpdmatch to perform a reverse DNS lookup on the client IP address. By default, tcpdmatch might use the IP directly or rely on the system's name resolution configuration.

tcpdmatch is a diagnostic tool used to test and debug access control rules configured for TCP Wrappers services. It simulates the behavior of the tcpd daemon (or applications linked with libwrap) by evaluating the rules defined in /etc/hosts.allow and /etc/hosts.deny against a specified service and client combination.

This command does not actually connect to a service but rather processes the access control files, reporting whether access would be granted or denied based on the rules. It provides valuable insights into why a connection might be allowed or blocked, making it an essential utility for system administrators troubleshooting network service access issues controlled by TCP Wrappers. Its output clearly indicates which rule was matched, helping to pinpoint misconfigurations.

tcpdmatch only simulates the decision-making process of TCP Wrappers; it does not guarantee that the actual service will behave identically if other factors (like firewall rules or service-specific configurations) are at play. TCP Wrappers only protect services that have been compiled with support for libwrap. Many modern systems and services increasingly rely on other access control mechanisms (e.g., firewalls, Systemd socket activation rules, or application-level authentication) rather than TCP Wrappers, making its relevance less universal than in the past.

When evaluating access, TCP Wrappers (and thus tcpdmatch) first checks the rules in /etc/hosts.allow. If a match is found that grants access, the process stops, and access is allowed. If no match is found in hosts.allow, then /etc/hosts.deny is checked. If a match is found in hosts.deny, access is denied. If no match is found in either file, access is implicitly granted (default-allow policy for services not explicitly denied).

Beyond basic testing, tcpdmatch is invaluable for:
- Validating new or modified TCP Wrappers rules before deploying them to production.
- Troubleshooting 'access denied' errors reported by users or logs, by simulating the exact client/service combination.
- Understanding the precedence of rules when multiple entries might apply to a given host or service.

tcpdmatch is part of the original TCP Wrappers package developed by Wietse Venema in the early 1990s. This suite of tools was designed to provide a simple, host-based access control mechanism for services typically launched by inetd or xinetd, or services compiled with libwrap. It quickly became a standard security feature on many Unix-like operating systems before the widespread adoption of more complex firewall solutions.

hosts.allow(5), hosts.deny(5), tcpd(8), inetd(8), xinetd(8)