Enabling TCP Wrappers on Solaris 10

Tip of the Month: Enabling TCP Wrappers in Solaris 10

Before answering this question, let's first provide a little background. TCP Wrappers has been around for many, many years. It is used to restrict access to TCP services based on host name, IP address, network address, etc. For more detailed on what TCP Wrappers is and how you can use it, see tcpd(1M). TCP Wrappers was integrated into Solaris starting in Solaris 9 where both Solaris Secure Shell and inetd-based (streams, nowait) services were wrapped. Bonus points are awarded to anyone who knows why UDP services are not wrapped by default.

TCP Wrappers support in Secure Shell was always enabled since Secure Shell always called the TCP Wrapper function host_access(3) to determine if a connection attempt should proceed. If TCP Wrappers was not configured on that system, access, by default, would be granted. Otherwise, the rules as defined in the hosts.allow and hosts.deny files would apply. For more information on these files, see hosts_access(4). Note that this and all of the TCP Wrappers manual pages a stored under /usr/sfw/man in Solaris 10. To view this manual page, you can use the following command:

$ man -M /usr/sfw/man -s 4 hosts_access

inetd-based services use TCP Wrappers in a different way. In Solaris 9, to enable TCP Wrappers for inetd-based services, you must edit the /etc/default/inetd file and set the ENABLE_TCPWRAPPERSparameter to YES. By default, TCP Wrappers was not enabled for inetd.

In Solaris 10, two new services were wrapped: sendmail and rpcbind. sendmail works in a way similar to Secure Shell. It always calls the host_access function and therefore TCP Wrappers support is always enabled. Nothing else needs to be done to enable TCP Wrappers support for that service. On the other hand, TCP Wrappers support for rpcbind must be enabled manually using the new Service Management Framework ("SMF"). Similarly, inetd was modified to use a SMF property to control whether TCP Wrappers is enabled for inetd-based services.

Let's look at how to enable TCP Wrappers for inetd and rpcbind...

To enable TCP Wrappers support for inetd-based services, you can simply use the following commands:

# inetadm -M tcp_wrappers=true
# svcadm refresh inetd

This will enable TCP Wrappers for inetd-based (streams, nowait) services like telnet, rlogin, and ftp (for example):

# inetadm -l telnet | grep tcp_wrappers
default  tcp_wrappers=TRUE

You can see that this setting has taken effect for inetd by running the following command:

# svcprop -p defaults inetd
defaults/tcp_wrappers boolean true

Note that you can also use the svccfg(1M) command to enable TCP Wrappers for inetd-based services.

# svccfg -s inetd setprop defaults/tcp_wrappers=true
# svcadm refresh inetd

Whether you use inetadm(1M) or svccfg is really a matter of preference. Note that you can also use inetadm or svccfg to enable TCP Wrappers on a per-service basis. For example, let's say that we wanted to enable TCP Wrappers for telnet but not for ftp. By default, both the global and per-service settings for TCP Wrappers are disabled:

# inetadm -p | grep tcp_wrappers
tcp_wrappers=FALSE

# inetadm -l telnet | grep tcp_wrappers
default  tcp_wrappers=FALSE

# inetadm -l ftp | grep tcp_wrappers
default  tcp_wrappers=FALSE

To enable TCP Wrappers for telnet, use the following command:

# inetadm -m telnet tcp_wrappers=TRUE

Let's check out settings again:

# inetadm -p | grep tcp_wrappers
tcp_wrappers=FALSE

# inetadm -l telnet | grep tcp_wrappers
         tcp_wrappers=TRUE

# inetadm -l ftp | grep tcp_wrappers
default  tcp_wrappers=FALSE

As you can see, TCP Wrappers has been enabled for telnet but none of the other inetd-based services. Pretty cool, eh?

You can enable TCP Wrappers support for rpcbind by running the following command:

# svccfg -s rpc/bind setprop config/enable_tcpwrappers=true
# svcadm refresh rpc/bind

This change can be verified by running:

# svcprop -p config/enable_tcpwrappers rpc/bind
true

That is all that there is to it! Quick, easy and painless! As always, let me know what you think!

Take care!

Technorati Tag:

Comments:

Just wondering if using IP filter would not be a better way of blocking/allowing machines to connect to services? I used to use TCP Wrappers all the time, but find now, that I rarely use them in favor of using ipfilter? Is there some advantage to using both? Just curious....

Posted by Jason Grove on April 07, 2005 at 04:58 PM EDT #

Jason,

Thank you for your question. In my opinion, I agree with you - I too would rarely use TCP Wrappers in favor of IP Filter. The reasons for this are simple - IP Filter simply has a more rich feature set and offers greater flexibility for defining filtering policy. Further, if you use Solaris containers, keep in mind that the IP Filter policy is defined in the global zone (versus TCP Wrappers which is done per container). The benefit of configuring IP Filter from the global zone is that if a local zone is breached, an attacker (even with root privileges) will not be able to alter the firewall policy or touch the firewall logs since they are safely protected in the global zone.

That said, TCP Wrappers was designed to protect TCP services and it does that very well. Further it offers an easy to understand and use interface for configuring policy. The choice to use IP Filter or TCP Wrappers will likely depend on your experience and comfort level with these tools as well as on your filtering requirements. If you are looking for a more comprehensive host-based firewall solution however, I would certainly recommend IP Filter.

Thanks again!

Glenn

Posted by Glenn Brunette on April 08, 2005 at 06:17 AM EDT #

Nice article. To answer the bonus question, the UDP services are not wrappered because they are stateless so there is no connection to manage. As the first comment said, IP filter can manage services, including UDP, because it is low enough in the protocol stack to cover both UDP and TCP.

Posted by Ben Strother on August 17, 2005 at 01:20 PM EDT #

fewsffkj weflkrwef

Posted by fwref on May 03, 2006 at 07:38 AM EDT #

HI Glenn How can we enable TCP Wrapper for non inetd Services, like smtp ??? cu

Posted by Rene Buehlmann on May 18, 2006 at 02:50 AM EDT #

Rene,

SMTP (sendmail) and SSH are special cases in that they are compiled to use libwrap by default and will automatically use TCP Wrappers if the /etc/hosts.{allow,deny} files exist. See sendmail(1M) and sshd(1M) for more information. As noted in the original article, inetd-based services are configurable in their use of TCP Wrappers as is rpcbind. Other than sendmail, is there another service that interests you or does this answer your question?

Glenn

Posted by Glenn Brunette on May 18, 2006 at 08:58 AM EDT #

i am interested in allowing telnets (992) from clients except ssh from 5 admin computers. would this be possible with tcp_wrappers? basically /etc/hosts.allow will have the five names of the workstations? right? would this affect telnets as well?

Posted by abhimanyu on November 01, 2006 at 03:11 AM EST #

Let me make sure I understand you correctly. You want to allow "telnets" (telnet over SSL) from which clients?

Do you want to allow telnets from anywhere except the 5 admin systems where you want them to use SSH? Is this correct?

Please let me know.

Glenn

Posted by Glenn Brunette on November 02, 2006 at 04:11 PM EST #

I turned on TCP Wrappers for sshd and rpcbind. It works as expected for sshd, but rpcbind seems incapable of using a domain selector, e.g.,
sshd: internal.example.com
works, requiring the client to be correctly in DNS, but the same client fails to be authenticated by
rpcbind: internal.example.com
whereas IP address permission works, e.g.,
rpcbind: 10.
Can you sugest what I may be doing wrong?

Posted by Stephen P. Schaefer on December 28, 2006 at 06:03 AM EST #

How can TCP wrappers be configured to report things via syslog? (In earlier Solaris releases, we had obtained TCPwrappers as source, compiled it with an option to use "local2", then adjusted "syslog.conf" to act on that "local2". On S10 we would like to use its inbuilt TCPwrappers, but I don't see in the documentation anything about reporting events via syslog.)

Posted by David Lee on January 09, 2007 at 11:36 PM EST #

David,

TCP Wrappers uses "auth.warning" to record its events. Configure your syslog.conf file to record auth.warning and you should start seeing those events.

Take care,

Glenn

Posted by Glenn Brunette on January 10, 2007 at 01:47 AM EST #

I added the line \*.alert;auth.warning /var/log/authlog to /etc/syslogd.conf and sent a "HUP" to syslogd. I then tried to telnet into the box (telnet wasn't enabled) thinking that the attempt would be recorded. I didn't see anything. Is there some other step required? Thanks.

Posted by Anon on February 13, 2007 at 06:24 AM EST #

Anon,

It never gets that far. telnet would need to be enabled if you want TCP Wrappers to log the attempt. Honestly, better to leave it disabled and use SSH!

Glenn

Posted by Glenn Brunette on February 13, 2007 at 06:48 AM EST #

We're not using "telnet", we were trying to figure out if there was a way of seeing attempts.

Posted by Anon on February 13, 2007 at 11:27 PM EST #



The only way that I know of with what comes with Solaris out of the box is to use IP Filter. With IP Filter, you would get a syslog message like:

Feb 14 14:13:59 solaris-devx ipmon[97]: [ID 702911 local0.warning] 14:13:59.154393 ip.tun0 @0:10 b 10.1.1.1,52913 -> 192.168.1.1,23 PR tcp len 20 52 -S IN

Take care,

Glenn

Posted by Glenn Brunette on February 14, 2007 at 06:25 AM EST #

Thanks, that looks perfect.

Posted by Anon on February 16, 2007 at 05:33 AM EST #

Post a Comment:
Comments are closed for this entry.
About

gbrunett

Search

Archives
« April 2014
SunMonTueWedThuFriSat
  
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
   
       
Today