Preparing the Environment
Before you touch any code, make sure your Solaris system is ready for a fresh build. Tcp Wrappers needs a working compiler, the standard C development tools, and a clean directory where the source can live. If you’re using Solaris 8 on an Intel box, the path of least resistance is to pull the latest tarball from the official source and unpack it to a familiar location such as /usr/local/src. If that folder doesn’t exist yet, create it with mkdir -p /usr/local/src and give yourself ownership rights using chown -R youruser:youruser /usr/local/src. You can switch to that directory with cd /usr/local/src and fetch the archive with wget https://www.tcp-wrappers.org/tcp_wrappers-7.6.tar.gz or the equivalent ftp command. Once the download finishes, extract the contents with tar xzf tcp_wrappers-7.6.tar.gz. You’ll find a new directory named tcp_wrappers-7.6 that contains the source files and a README that contains system‑specific notes.
Solaris builds can be picky about the compiler. While the default cc is usually sufficient, many developers prefer the GNU compiler for its improved diagnostics and compatibility with modern code. Check if gcc is installed by typing gcc -v. If it reports “command not found”, install it from the Solaris Update System (SUS) or from the OpenCSW repository with pkgutil -i gcc. Once gcc is present, you’ll tell the Makefile to use it later on.
The next step is to read the README that sits at the root of the source tree. It explains the default installation prefix (usually /usr), lists optional features, and warns about any known quirks on Solaris. Skim through it before you open the Makefile - you’ll discover that the build script expects a Solaris‑specific flag, sunos5, that triggers the right compiler options and file layout. When you run make sunos5 later, the Makefile will pull in the correct definitions automatically.
Another handy preparation step is to double‑check the PATH environment. If you installed gcc to a nonstandard location, prepend its bin directory: export PATH=/opt/gcc/bin:$PATH. This guarantees that when make invokes the compiler, it finds the right binary. After adjusting the environment, run echo $PATH to verify the new order. Finally, create a backup of any existing Tcp Wrappers installation: cp -R /usr/lib/tcp_wrappers /usr/lib/tcp_wrappers.bak 2>/dev/null || true. This way you can restore the original state if something goes wrong.
With the source unpacked, the compiler available, and the environment set, you’re ready to dig into the Makefile. The next section walks through the customization steps that make the build work on your particular Solaris machine.
Customizing the Makefile
The Makefile in the Tcp Wrappers source is a mix of generic definitions and Solaris‑specific overrides. Open it with your favorite editor, for example vi Makefile, and locate the section that begins with # SysV.4 Solaris 2.x OSF AIX. Under that banner you’ll see the default installation directories: REAL_DAEMON_DIR=/usr/sbin and REAL_LIB_DIR=/usr/lib. For a typical Solaris install those values are correct, but if you plan to keep binaries in a custom location you can edit them accordingly.
One of the most common edits is telling the build system to use gcc instead of the default cc. Search for a line that reads #CC=cc and replace it with CC=gcc. The comment character (#) may appear on the same line, so you’ll need to remove it before the assignment. After that change, the compiler will emit GNU warnings and, if you have -Wall enabled, those warnings will surface during compilation.
Next, scroll through the “system dependencies” block. On Solaris you’ll find many #-prefixed flags that enable support for various services. Uncomment each flag that matches the daemons you intend to protect. For example, if you plan to wrap in.ftpd and in.telnetd, look for the lines #FTPD= -DIN_FTPD and #TELNETD= -DIN_TELNETD and remove the leading hash signs. The build system will then compile the corresponding wrappers into the source.
The IPv6 support line is another critical tweak. Search for the paragraph that mentions “IPV6” and ensure the flag IPV6= -DHAVE_IPV6 is active. With IPv6 enabled, the wrappers will be able to filter both IPv4 and IPv6 requests. If you leave the flag commented out, any IPv6 traffic will bypass the access controls entirely.
There are a few optional features you might consider. The Makefile contains a Once you’ve made all necessary edits, save the file and close the editor. To double‑check that the Makefile parses correctly, run Now that the Makefile is tuned for your system, it’s time to build the binaries. From the root of the source tree, run On a typical Solaris 8 machine, the compile finishes in a few minutes and leaves you with With the binaries ready, install them into the system. The Makefile includes a After installation, adjust the permissions to ensure that Finally, verify that the library is present in the dynamic loader path by running With Tcp Wrappers installed, the next task is to define who can connect to which services. The mechanism is straightforward: edit A common scenario is to allow the local LAN while blocking the wider internet. Edit Next, block everything else by adding a catch‑all rule in To test the setup, use Keep in mind that the order of entries matters. The system scans Most legacy Solaris services are launched by the network super‑daemon Open Some daemons live outside After editing the file, restart It’s good practice to confirm that the wrapper is in effect. Open a remote terminal on a permitted host and attempt to start a protected service, such as With Tcp Wrappers compiled, installed, and integrated into Monitoring the log file Another area to watch is the file permissions on the wrapper files. Occasionally, other administrators may inadvertently modify When updating Tcp Wrappers, the process mirrors the initial build. Download the new source, unpack it, customize the Makefile, compile with In the end, Tcp Wrappers remains one of the simplest yet most effective tools for hardening Solaris services. By following the steps above, you can keep your network services guarded with minimal overhead and maximum flexibility.#SSL= -DUSE_SSL line; uncommenting it adds SSL support to the wrappers. This is useful if you run secure variants of the daemons and want the wrappers to validate the TLS handshake before proceeding. Similarly, a #SYSLOG= -DSYSLOG flag enables logging via syslog; most Solaris deployments already ship with syslog, so enabling it keeps a record of denied and allowed connections in /var/adm/messages
make -n sunos5. The -n flag shows what the build would do without actually executing it. If you see any syntax errors or missing variables, return to the Makefile and fix them before proceeding. This pre‑flight check saves time and frustration later on.Compiling and Installing Tcp Wrappers
make sunos5. The build process will compile the core wrapper library and the individual tcpd helper executable. While it’s running, pay attention to any warnings or errors that appear; if a compiler flag is missing or an option conflicts, the build may stall.tcpd in the src directory and the library files in lib. Verify the output with ls -l src/tcpd lib/libwrap.so. The tcpd binary should be a few kilobytes, and the shared object should sit around 100 kilobytes.make install target that copies the files into the directories you specified earlier. Execute make install as root, and watch the install script copy tcpd to /usr/sbin, the library to /usr/lib, and the header files to /usr/include. It also writes the wrapper configuration files /etc/hosts.allow and /etc/hosts.deny if they are missing.tcpd runs as root and the library is accessible to other daemons. The default permissions should be rwxr-xr-x for tcpd and rw-r--r-- for libwrap.so. If you need tighter security, set chown root:root /usr/sbin/tcpd /usr/lib/libwrap.so and chmod 755 /usr/sbin/tcpd while keeping the library readable by all users.ldconfig -r /usr/lib | grep libwrap. If it appears in the output, the system will link any daemon that calls wrap automatically. If you’re using a custom library path, add /usr/lib to /etc/ld.so.conf and run ldconfig again.Configuring Access Controls
/etc/hosts.allow for allowed hosts and /etc/hosts.deny for denied hosts. Each file contains lines in the format service: address: action, where service is the daemon name, address can be a hostname, IP address, or network, and action is usually ALL to permit or block all requests from that address./etc/hosts.allow with a text editor and add a line such as:in.lpd,sshd,in.ftpd,in.telnetd: 10.0.0.0/255.255.255.0, .localdomain, .sol8.paradise.net, .bytes.paradise.net. This entry permits the listed daemons only for hosts on the 10.0.0.0 network and for any machines that resolve to the two local domain names./etc/hosts.deny. Open the file and place the following line at the top:ALL: ALL. This directive tells Tcp Wrappers to deny every request that does not match an explicit allow rule.telnet 10.0.0.2 22 from a host on the LAN and verify that the connection succeeds. Then attempt the same from an external host; the connection should drop. For a quick audit, check /var/adm/messages for entries that begin with “tcpd: deny” or “tcpd: allow”. Those lines record the decision made for each connection attempt and provide a valuable debugging trail.hosts.allow first; if a match is found there, the request is allowed immediately, regardless of hosts.deny. If no match is found in hosts.allow, it proceeds to hosts.deny. Therefore, always place specific allow rules above any generic deny rules. If you ever need to grant temporary access to a host, simply add its IP to the allow file and reload inetd afterward.Integrating with inetd
inetd. To protect them with Tcp Wrappers, you must wrap the daemon binary with /usr/sbin/tcpd in the /etc/inetd.conf file. Begin by backing up the existing configuration: cp /etc/inetd.conf /etc/inetd.conf.bak. If you want to restore a previous state later, the backup will be handy.inetd.conf for editing and locate each service that you want to protect. For example, the FTP service might appear as:ftp stream tcp6 nowait root /usr/sbin/in.ftpd in.ftpd. Replace the daemon path with /usr/sbin/tcpd followed by the original path:ftp stream tcp6 nowait root /usr/sbin/tcpd in.ftpd. The tcpd wrapper will intercept the incoming connection, consult hosts.allow and hosts.deny, and then invoke in.ftpd if the request is permitted./usr/sbin. For instance, the Remote Procedure Call wall service might be listed as:walld/1 tli rpc/datagram_v wait root /usr/lib/netsvc/rwall/rpc.rwalld rpc.rwalld. In that case you need to specify the full path to the wrapper and then to the actual daemon:walld/1 tli rpc/datagram_v wait root /usr/sbin/tcpd /usr/lib/netsvc/rwall/rpc.rwalld. Notice the two paths after the root keyword: the first is tcpd, the second is the real service binary.inetd to apply the changes. The easiest method is to send a hang‑up signal: pkill -HUP inetd. This instructs the daemon to reread inetd.conf and reopen all configured services. Verify that the process is still running with ps -ef | grep inetd. If you see the signal handled, the services are now protected by Tcp Wrappers.telnet to port 23. If the connection is accepted, check /var/adm/messages for a log line like “tcpd: allow in.telnetd from 10.0.0.2”. Then try the same from a host that isn’t allowed; the connection should fail, and the log should show a “deny” entry. These checks ensure that the integration works as expected.Final Touches
inetd, your Solaris system now enjoys a lightweight, configurable access‑control layer for all network services. To maintain a healthy environment, schedule periodic reviews of hosts.allow and hosts.deny. As your network grows, you might add new hostnames or adjust subnet masks to reflect changes in your LAN topology. Remember that each line in these files is processed in order, so keep specific allow rules near the top and leave the generic deny rule at the bottom./var/adm/messages is essential for spotting anomalies. If you notice an unusual spike in denied attempts, it could indicate a brute‑force attack or a misconfigured client. In that case, consider tightening the rules or adding a temporary block for the offending IP./usr/sbin/tcpd or /usr/lib/libwrap.so to remove the root ownership, which would break the daemon launching sequence. A quick audit with ls -l /usr/sbin/tcpd /usr/lib/libwrap.so every few weeks keeps the system in a secure state.make sunos5, and run make install. If you encounter issues, revert to the backup of the old binaries, restore the original inetd.conf from the backup, and re‑apply your configuration changes. This rollback plan protects against regressions in the new version.
No comments yet. Be the first to comment!