TCP Wrapper
TCP Wrapper is a library which provides simple access control and standardized logging for supported applications which accept connections over a network. Historically, TCP Wrapper was used to support inetd services.
TCP Wrapper supports only services which were built to make use of the libwrap library. To determine whether a given executable daemon /path/to/daemon supports TCP Wrapper, check the documentation, or run:
$ ldd /path/to/daemon | grep libwrap.so
If this command returns any output, then the daemon probably supports TCP Wrapper. An alternative to TCP Wrapper support is packet filtering using iptables. Note that iptables works at the network level, while TCP Wrapper works at the application level. This means that iptables filtering is more efficient and more resistant to flaws in the software being protected, but TCP Wrapper provides support for logging, banners, and other application-level tricks which iptables cannot provide.
ChkServd TCP check failure threshold
Main >> Server Configuration >> Tweak Settings
The number of times a ChkServd TCP check must fail before notification is sent and the service is restarted. On heavily loaded systems these types of service checks fail occasionally, producing erroneous indications that services are down.
A value of 3 or higher is recommended for most systems.
TCP and UDP Ports for Cpanel Server Firewall
Incoming TCP ports
TCP_IN = “20,21,22,25,53,80,110,143,443,465,587,993,995,2077,2078,2082,2083,2086,2087,2095,2096,2242″
Outgoing TCP ports
TCP_OUT = “20,21,22,25,37,43,53,80,110,113,443,587,873,2087,2089,2703″
Incoming UDP ports
Outgoing UDP ports
UDP_OUT = “20,21,53,113,123,873,6277″
TCP Connections by State
TCP Connections by State probe identifies the total number of TCP connections, as well as the quantity of each in the following states:
TIME_WAIT — The socket is waiting after close for remote shutdown transmission so it may handle packets still in the network.
CLOSE_WAIT — The remote side has been shut down and is now waiting for the socket to close.
FIN_WAIT — The socket is closed, and the connection is now shutting down.
ESTABLISHED — The socket has a connection established.
SYN_RCVD — The connection request has been received from the network.
Using NFS over TCP
To mount a shared directory using NFS over TCP, use the “proto=tcp” mount option:
# mount -o proto=tcp :/pub /usr/local/pub
Make sure the target directory, in this example /usr/local/pub, exists on the client.
You can verify the NFS over TCP mount using the mount command:
If you need NFS, it is recommended to use NFS over TCP since NFS over UDP is not very secure. All 2.4 and 2.6 kernels support NFS over TCP on the client side. Server support for TCP appears in later 2.4 kernels, and in all 2.6 kernels.
To verify whether your server supports NFS over TCP, use the wire-test command (/usr/sbin/wire-test is part of the am-utils package). If your server supports NFS over TCP, the output looks like this:
# wire-test localhost
NFS Version and protocol tests to host “localhost”…
testing vers=2, proto=”udp” -> found version 2.
testing vers=3, proto=”udp” -> found version 3.
testing vers=2, proto=”tcp” -> found version 2.
testing vers=3, proto=”tcp” -> found version 3.
#
