TCP Wrappers on Solaris

Could someone either provide a link to the Solaris 8 forum
Or..
I have downloaded and installed (pkgadd) tcp_wrappers-7.6-sol8-sparc-local.gz for Solaris 8 SPARC
from sunfreeware
I used the advanced option as per this pkg instructions
I am getting the following in syslog:
"refused connect from 0.0.0.0"
and at the commandline for
telnet myhost
I get:
Connection closed by foreign host
The /etc/hosts.deny has: ALL: ALL
the /etc/hosts.allow has: in.telnetd: 100.100. (shortned IP address for the subnet)
and ALL: 127.0.0.1
I am using a space between the in.telnetd: and the ip address not a tab.
The /etc/inet/inetd.conf looks like this:
"telnet stream tcp6 nowait root /usr/local/bin/tcpd in.telnetd"
default is IPv4
Thanks for your help

Thanks ... much appreciated...
It worked...
The reason I did not do this is because the inetd.conf says that tcp6 is supported for telnet and when I installed this system many years ago (Boy do I remember, it was just after Bossy our cow had a new... ) i selected IPv4..
Lesson learned!
Thanks

Similar Messages

Veritas and Solaris 9 bulitin tcp wrappers

Does anyone know if the tcp wrappers that is bulitin to the
Solaris 9 OS will work on non-Sun products?
We use veritas to backup our servers, each host has a number
of entries in the /etc/inet/inetd.conf file to execute portions of
the veritas backup suite.
Once we enabled tcp-wrappers on Solaris 9 systems
veritas would not run, disabling tcp-wrappers veritas
executes as it did before.
NOTE: we were using Wietsmans' tcp-wrappers self compiled and
executed from a non-standard location but the veritas
services lists in the /etc/inet/inetd.conf file were not wrapped
Comments/suggestions appreciated
John

If ENABLE_TCPWRAPPERS is on in /etc/default/inetd then all tcp connections get wrapped automatically. Even without a specific "tcpd" entry in /etc/inetd.conf...
So you will need to add specific entries for netbackup in /etc/hosts.allow and /etc/hosts.deny to allow the netbackup connections.

How to define tcp wrappers for a new service in Solaris 10?

Hi all, I need to setup tcp wrappers for a third-party software product with /etc/hosts.allow.
I installed Trillium software on a new Solaris 10 server. It added this entry to /etc/inetd.conf:
dscserv0_rel1300 stream tcp nowait tsadmin /usr/bin/env env -i HOME=/home/tsadmin LOGNAME=tsadmin /opt/trilv13/TrilliumSoftware/server/metabase/bin/mtb_server
After the install, I ran inetconv and this new SMF service was created:
*# svcs -a|grep dsc*
online 13:22:57 svc:/network/dscserv0_rel1300/tcp:default
Here's the problem: After this, all new connections were denied by default. I had to disable tcp wrappers with this command:
inetadm -m svc:/network/dscserv0_rel1300/tcp:default tcp_wrappers=FALSE
I would prefer to enable tcp wrappers, and put an entry into /etc/hosts.allow, but I can't figure out what service name to put into /etc/hosts.allow. I've read through the man pages but I can't identify the service name to use for this new service, and it won't accept the FMRI or an abbreviation of it either.
How do I identify the service name to put into /etc/hosts.allow?

At OS level, before entering Sql*Plus, do :
$ EDITOR=vi; export EDITOR
$ sqlplus ......
Message was edited by:
Paul M.
Ciao Nicolas :-)

Securing RPC services with TCP Wrappers

Hello All,
I have two node cluster running solaris 10. Since SVM needs few rpc services like metad,metamedd and metamhd, I dont want to disable them. But at the same time, wants to block them from outside world.
But readme page of TCP Wrappers (http://www.sunfreeware.com/README.tcpwrappers) says "The wrappers do not work with RPC services over TCP. These services are registered as rpc/tcp in the inetd configuration file". And other internet sources says same. So my question is this valid still?. Or it is possible to filter RPC services using TCP Wrappers.
When I tested this with following entries in /etc/hosts.allow and /etc/hosts.deny, my two nodes did not give any trouble after couple of reboots. SVM is working fine. So I wonder whether RPC services area really blocked (other than the local host) or not.
Content of /etc/hosts.deny
===========================
rpcbind: ALL : severity debug
rpc.metad: ALL : severity debug
rpc.metamhd: ALL : severity debug
rpc.metamedd: ALL : severity debug
rpc.metacld: ALL : severity debug
Content of /etc/hosts.allow
=======================================
rpcbind: KNOWN : severity debug
rpc.metad: localhost : severity debug
rpc.metamhd: localhost : severity debug
rpc.metamedd: localhost : severity debug
rpc.metacld: localhost : severity debug
Any hints/information regarding this will be really appreciated.

Hello Mark,
Sorry that I missed to thank you in your last post.
If I get it right, The RPC bind program is used to maintain a table of dynamically allocated ports for RPC-based services.
From internet, "The file /etc/rpc contains a list of network services. Typically, when a remote machine wants to connect to one of those services on your machine, it first issues a query to the rpcbind program running on your computer. It knows the name of the services it wants to connect with, but doesn't know what port number to use. Your rpcbind will respond with a port number. The remote host will then attempt a connection to the specified port."
Also, Note that blocking rpcbind doesn't block access to the/etc/rpc services altogether. It does block access for those programs which do an rpcinfo query in order to reach those services. So other possible ways also exist to make remote connection without querying. Here lies the problem. I wanted to secure RPC services completely.
Coming to metad, it is true that ldd will result nothing related to libwrap*. But inetadm tells different story
inetadm -l /network/rpc/meta | grep -i wrap
default tcp_wrappers=TRUE
So encapsulating with tcpd should work for metad and other RPC services, I believe.
What is your opinion on this?.

Tftpd and TCP wrappers

I'm unable to wrap the tftpd service on our system. The server is not denying tftp (get) requests from arbitrary Internet hosts, in spite of:
/etc/hosts.deny:
in.tftpd: ALL
TCP wrappers is enabled for tftpd:
# inetadm -l svc:/network/tftp/udp6:default
SCOPE NAME=VALUE
name="tftp"
endpoint_type="dgram"
proto="udp6"
isrpc=FALSE
wait=TRUE
exec="/usr/sbin/in.tftpd -s /tftpboot"
user="root"
default bind_addr=""
default bind_fail_max=-1
default bind_fail_interval=-1
default max_con_rate=-1
default max_copies=-1
default con_rate_offline=-1
default failrate_cnt=40
default failrate_interval=60
default inherit_env=TRUE
default tcp_trace=TRUE
tcp_wrappers=TRUE
TCP wrappers is working properly for other services like sshd. The system is also up-to-date on all Solaris 10 patches.
Any suggestions?

Note sshd has libwrap, and tftpd doesn't:
% ldd /usr/sbin/in.tftpd
libsocket.so.1 => /usr/lib/libsocket.so.1
libnsl.so.1 => /usr/lib/libnsl.so.1
libc.so.1 => /usr/lib/libc.so.1
libmp.so.2 => /usr/lib/libmp.so.2
libmd5.so.1 => /usr/lib/libmd5.so.1
libscf.so.1 => /usr/lib/libscf.so.1
libdoor.so.1 => /usr/lib/libdoor.so.1
libuutil.so.1 => /usr/lib/libuutil.so.1
libm.so.2 => /usr/lib/libm.so.2
/platform/SUNW,Sun-Fire-V240/lib/libc_psr.so.1
/platform/SUNW,Sun-Fire-V240/lib/libmd5_psr.so.1
% ldd /usr/lib/ssh/sshd
libsocket.so.1 => /usr/lib/libsocket.so.1
libnsl.so.1 => /usr/lib/libnsl.so.1
libz.so.1 => /usr/lib/libz.so.1
libpam.so.1 => /usr/lib/libpam.so.1
libbsm.so.1 => /usr/lib/libbsm.so.1
libwrap.so.1 => /usr/sfw/lib/libwrap.so.1
libcrypto.so.0.9.7 => /usr/sfw/lib/libcrypto.so.0.9.7
libgss.so.1 => /usr/lib/libgss.so.1
libcmd.so.1 => /usr/lib/libcmd.so.1
libcontract.so.1 => /usr/lib/libcontract.so.1
libc.so.1 => /usr/lib/libc.so.1
libmp.so.2 => /usr/lib/libmp.so.2
libmd5.so.1 => /usr/lib/libmd5.so.1
libscf.so.1 => /usr/lib/libscf.so.1
libsecdb.so.1 => /usr/lib/libsecdb.so.1
libnvpair.so.1 => /usr/lib/libnvpair.so.1
libdoor.so.1 => /usr/lib/libdoor.so.1
libuutil.so.1 => /usr/lib/libuutil.so.1
libm.so.2 => /usr/lib/libm.so.2
/platform/SUNW,Sun-Fire-V240/lib/libc_psr.so.1
/platform/SUNW,Sun-Fire-V240/lib/libmd5_psr.so.1
My suggestion is to use the tcpd program. I don't think it comes with the default install (I can't find it) but it is in the Sun Freeware packages (/usr/sfw/sbin/tcpd) and it's easly to compile on your own. Then old school it into inetd:
tftp dgram udp6 wait root /usr/sfw/sbin/tcpd in.tftpd -s /tftpboot
Then inetconv it.

Tcp wrappers /etc/hosts.allow format

since most of the services that were originally run from
the /etc/inet/inetd.conf file on pre-Solaris 10 systems
are now run from smf, what are the "in.*" service names
that should be placed in the /etc/hosts.allow file?
also is there a "safe_finger" available for use that can
be used in the /etc/hosts.deny file or should the
"standard" Solaris 10 finger be used?
Thanks

elasticdog wrote:So should our package not have the ListenAddress 0.0.0.0 line uncommented by default? My guess would be that since it listens on all local addresses by default, we're just overwriting that when specifying 0.0.0.0, which isn't valid. That was users don't have to specify their local IP address. Unless I'm wrong, shouldn't this be a bug/feature request for the packager?
This doesn't seem to be a package bug... IMHO, sshd must respect all the settings in hosts.deny and hosts.allow, regardless the IP address it listens on. The behaviour I noticed seems to be much more complicated. Basic settings (daemon name mentioned in hosts.*) worked, as far as I didn't want a "per IP" configuration. For example, including the daemon in hosts.allow really enabled remote connections, but any closer specifications (subdomains, EXCEPT operator...) were ignored. Access was simply granted without further evaluation. Excluding sshd from hosts.allow worked as one would assume. When I specified ListenAddress, everything started to work properly. This is mysterious. There are millions of computers using tcp wrappers and ssh, so it's hard to believe there could be a bug.

How to enable TCP Wrappers with SMF services?

I am using a site.xml file to enable/disable services during a Jumpstart configuration. This works great.
However, I can't yet figure out how to configure the various properties of those services, such as enabling TCP Wrappers for a service. I can set the properties of a service and verify that they are set, but a "svccfg extract" does not capture that information.
Is this a short coming of svccfg extract? Or are the properties of a service stored and configured elsewhere?

That will work, as will any path underneath
/var/svc/manifest.Got it working...Exported the inetd configuration, set tcp_wrappers to false, dropped inetd.xml into my jumpstart tree, jumped a box, and tcp_wrappers came up enabled by default for my inetd services!
What is the difference between the /var/svcs/profile and /var/svcs manifest directory? Is profile for enabling/disabling services and manifest for service configuration?
Does /var/svcs/profile/site.xml and /var/svcs/manifest/whatever.xml get read on every system boot? If not, what is the appropriate procedure to "reinitialize" smf if you want to change the existing behaviour by having it reread those files?
Hmm. The defaults get written on the inetd serviceI believe, so exporting that would give you the
fragment
you want.It did, and I was able to accomplish what I needed to do.
Sorry that it's such a slog in the meanwhile.Will there be something before FCS in a couple weeks?
I can definetly see the managability and robustness of SMF. It's just going to take time to learn it, and documentation is needed for that.
Thanks for all your help!

Filtering TCP connections on Solaris 9 and 10

I need to develop a driver to filter TCP packets on Solaris 9 and 10. My understanding is that I need to develop a STREAMS module to do this. Searching the forums and reading the docs it does NOT look like a STREAMS module can be inserted between IP and TCP in the stack. Instead it looks like I have to insert my module between the NIC driver and the IP stack. Is that correct? Is there an alternative interface (hook) in the IP stack that would allow me access to TCP packets?
Assuming STREAMS is the way to go, can anyone point me to some example code to get a jump start on this project?
Thanks in advance for your time and feedback
Tom Fortmann
Xcape Solutions

Hello Aerosmith,
On Solaris 9, do you see any window with a progress bar at Adobe Reader startup saying "Adding font folders to cache"? I assume you're launching Adobe Reader without any document from commandline -- approx how many seconds does it take for Adobe Reader to launch?
Thanks,
Gaurav

Get rid of tcp wrappers?

Hi!
I'm not sure this is the right forum, but I'll go with it anyways.
The first thing I noticed when beginning to fill up my newly installed Arch linux with software was that most of the networkrelated packages was compiled with tcp wrappers (ssh for example, but several others aswell).
I really don't like the usage of tcp wrappers. If I want security, I use iptables.
Is there a way to get rid of the entire tcp wrappers thing and still use the packages, or do I have to compile everything on my own?
Regards
/Diddi

Daenyth wrote:Click
In other words, you'd have to recompile the packages.

TCP Wrappers not working

I want to block all traffic except those rules listed in /etc/hosts.allow.
And I don't want nfs clients from anywhere to connect to my server.
But for some reason both of my configuration files are totally ignored by arch:
/etc/hosts.allow
/etc/hosts.deny
# /etc/hosts.allow
sshd: ALL
nfsd : 192.168.10.
portmap: ALL
mountd: ALL
httpd: ALL
mysqld: ALL : ALLOW
tor: ALL
# End of file
# /etc/hosts.deny
ALL: ALL: DENY
# End of file
Last edited by yassin (2008-04-10 20:43:45)

#archlinux @ Freenode
[20:23] < yassin> http://bbs.archlinux.org/viewtopic.php?id=46907
[20:23] < yassin> any suggestions?
[20:26] < tomkx> yassin - yes. For those who can't/won't click your link, ask an intelligent question that
summarises your problem as briefly as possible, but with enough detail to enable anyone who's
interested to answer you without asking for more information
[20:26] < yassin> ok
[20:26] < yassin> my TCP wrappers isn't working, /ets/hosts.deny & /etc/hosts.allow are totally ignored
[20:29] < yassin> tomkx: well the problem is everyone can connect to every port
[20:29] < yassin> like as if TCP wrappers wouldn't be running
[20:30] < yassin> tomkx: for example I have in hosts.allow - nfsd : 192.168.10.
[20:31] < yassin> and in hosts.deny - ALL: ALL: DENY
[17:32] < yassin> tomkx: any ideas?
[17:35] < tomkx> yassin - I was expecting something like "but nfs clients from anywhere can connect to my
server". In other words, you haven't actually described a specific problem yet (and that includes
your forum post)
[17:36] < yassin> tomkx: good point there
[17:36] < yassin> well yes, that is pretty much the problem
[17:39] < yassin> tomkx: I updated the post now
[17:42] < yassin> tomkx: that's not really the problem if we are specific, since I've got the right
configurations, the problem is they are being ignored by arch
[17:43] < yassin> tomkx: so I'd say my problem description was correct: "TCP Wrappers not working"
Last edited by yassin (2008-04-10 20:50:57)

TCP wrappers not logging?

I recently opened up my SSH server to the world (so i can log in from outside my home network to my server). Did some reading up, found out TCP wrappers acts as an intermediary to decide whether or not a request for a given application gets acknowledged.
SSH logs authentication attempts to /var/log/auth.log. So far, so good. I tried logging in from work, got bounced. Found the entries in that file.
Today, I tried to log in again, got bounced (again ), however, no sign of it in auth.log. I wanted to check what TCP wrappers had to tell me about this, only to find out it (tcpd) does not seem to log anywhere? /etc/syslog-ng.conf has no tcpd entries.
Since the contents of syslog-ng.conf look a bit complicated, can someone enlighten me on how to add tcpd logging facilities to it, and also tell why is it not enabled by default?
The tcpd manual refers to the system logging utility for further info on its logs, and since it has no own config file, there doesn't seem to be a way to set up tcpd independently to log its activities somewhere.

B wrote:The thing is: i see the sshd entry in auth.log, which means tcp_wrappers allowed the connection to pass through (if not it should have never reached sshd, right?).
No. Sshd checks hosts.* rules by itself (via libwrap functions), and tcpd is never run. So, it is sshd which logs the connection, successful or not. See, there's an exempt from auth.log; the connection was refused because of hosts.* settings:
Jun 13 21:42:06 kreml sshd[19994]: refused connect from 87.207.23.75
B wrote:Last night there weren't even any entries in auth.log, so that's why I'd like to have tcp_wrappers logging the
attempts it bounces (if possible).
Maybe the connection wasn't refused by wrapper (leaving alone how called), but by some other means? Anyway, you won't find tcpd entries in logs nor syslogd configuration, it is rarely used nowadays, in favor of direct linking with libwrap.
Of course, I'm talking about Arch defaults here, you can arrange your config to make use of tcpd.

Tcp wrappers and ipv6?

Hi,
(Sorry for the [probably] duplicate thread; does anyone know how to search 'as a phrase' with PHPBB so I can find it if this has been mentioned before?)
TCP-wrappers (pacman package tcp_wrappers 7.6-6) does not seem to have IPv6 support. It kept saying "refused connect from 0.0.0.0" and after googling that (which does support phrase searching everything pointed to it being an IPv6/v4 issue. So, I disabled IPv6 in sshd (the service that was giving me trouble), and sure enough I started getting proper hostnames instead of 0.0.0.0 .
Pacman says my tcp_wrappers is up-to-date; is there another package source somewhere from which I can easily get the IPv6 version?
~Felix.

Well, it's not on any of the Arch repos, if that's what you mean. You'd need to get the source tarball and build it yourself. Alternatively, you could post a request for it in the AUR Package Requests forum - someone might do a PKGBUILD for it.

TCP wrappers not supported in sshd?

It seems that support for tcp wrappers is not compiled into the sshd service for Mountain Lion. sshd ignores the contents of the "/etc/hosts.deny" file, that for example "denyhosts" produces. Why is this do you think, and is there some workaround? Seems like tcp wrappers have been supported forever, before Mountain Lion.

I consider this a really cheesy and hopefully very temporary workaround. It may not be recommended, use at your own risk, your universe may collapse into a black hole, etc., etc. But it worked.
If you still have a 10.7 install on another volume, you can copy the old sshd binary and missing libwrap library file to your 10.8 boot disk and run it. Quick and dirty run down (this is not detailed for those not versed in command line):
Pre) Make sure you stop the default sshd daemon via the sharing control panel. (Uncheck "Remote login.) Otherwise you will have a conflict on port 22 when you try to start the old.
1) Mount the 10.7 volume. For my example I'll call mine "Mac 10.7 HD"
2) sudo cp /Volumes/"Mac 10.7 HD"/usr/lib/libwrap.7.dylib /usr/lib/.
3) sudo cp /Volumes/"Mac 10.7 HD"/usr/sbin/sshd /usr/sbin/sshd2 (or "sshd-old" or whatever you like, just don't overwrite the exisitng sshd or you won't be able to revert later.)
4) sudo /usr/sbin/sshd2 (start the daemon)
Note you can't use the sharing control panel to control this version and if you wanted it start between reboots you would have to create a separate launchctl script for it.
Linc, another good lead, thanks. I probably should be spending my time looking around for alternatives than hacking away at my install.

(To SUN DTS) Where is tcp.c in solaris 8 open source foundation?

Dear SUN DTS,
I have downloaded the solaris 8 open source foundation. But I cannot find tcp.c file. Ip.c was there as ip.c.export. Is this SUN's purpose not giving out the tcp.c, or this is someone's mistake when packaging. Without it, the source foundation is not complete.
Thanks
Ken

Hi Ken,
As per the source license agreement, you should pursue questions about the source with the product team on the Solaris 8 Foundation Source Discussion Forum.
Sorry for any inconvenience.
Best regards,
Ralph
SUN DTS

X11vnc-0.9.6 (version update and tcp wrappers support)

# $Id$
# Maintainer: unmaintained
pkgname=x11vnc
pkgver=0.9.6
pkgrel=1
pkgdesc="a VNC server for real X displays"
arch=("i686" "x86_64")
license=("GPL2")
#source=(http://dl.sourceforge.net/sourceforge/libvncserver/$pkgname-$pkgver.tar.gz)
url="http://www.karlrunge.com/x11vnc/"
source=("$url/$pkgname-$pkgver.tar.gz")
depends=('openssl' 'libjpeg' 'zlib' 'libx11' 'libxtst' 'libxinerama' 'libxdamage' 'libxrandr' 'avahi')
build() {
cd $startdir/src/$pkgname-$pkgver
env CPPFLAGS=-DUSE_LIBWRAP LDFLAGS=-lwrap ./configure
make || return 1
make prefix=$startdir/pkg/usr install || return 1
md5sums=('2d5a80271a11230ab8b26d10f0c5b563')
the daemon name for /etc/hosts.deny /etc/hosts.allow is vnc
Last edited by metalfan (2008-12-13 18:40:14)

Tea2 wrote:
graysky wrote:@Tea2 - I think it's due to the staleness of the package as well as the need for the devs to provide extra work just to keep the rest of the packages functional working around it. I think ufw is a pretty good alternative.
Forgive my ignorance but what sort of work are you talking about? Surely, the work needed to keep a package working with another is upstream work, with the package maintainers ensuring that the dependencies are in order?
On the issue of alternatives, personally I hate iptables. It's more complex than it needs to be; the process of adding a single rule is a little bit tricky. Then there's no assurance it actually worked, since the syntax of a single command is a little bit confusing. I have no real issue with iptables other than it's ugly. Since Arch is based on the KISS philosophy, should we not keep the hosts files based on their simplicity? I have not used ufw, but I've checked it out in the wiki and it actually looks pretty good and I think I'll get it installed on my VPS asap so I can start experimenting with it.
I can understand removing tcp_wrappers from the default installation stack, but completely removing the option is going too far. I'm sure it can be quite comfortable in [extra] or something.
I imagine that there are many users that feel the same way that you do, so I recommend putting it into the AUR.

TCP Wrappers on Solaris

Similar Messages

Maybe you are looking for