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.

Similar Messages

Sshd ignores /etc/hosts.allow and /etc/hosts.deny

Hello everyone,
I've just found out that sshd ignores /etc/hosts.allow and /etc/hosts.deny completely on my machine. It doesn't make use of tcp_wrappers. I am using the standard Arch package. Either my settings are wrong, or this is a severe security problem. It was a terrible surprise to find out that my server is under severe dictionary attacks all the time, despite the denyhosts script I am using.
These are my settings:
/etc/hosts.deny:
ALL: ALL
/etc/hosts.allow:
# some nfs daemons: 192.168.1.0/255.255.255.0
sshd sshd1 sshd2: ALL EXCEPT /etc/hosts.evil
mysqld: 192.168.1.0/255.255.255.0
/etc/hosts.evil:
195.113.21.131
60.10.6.53
A simple experiment to verify the settings:
[root@charon etc]# tcpdmatch -d -i /etc/xinetd.conf sshd 195.113.21.131
warning: sshd: no such process name in /etc/xinetd.conf
client: address 195.113.21.131
server: process sshd
matched: hosts.deny line 5
access: denied
[root@charon etc]# tcpdmatch -d -i /etc/xinetd.conf sshd 195.113.21.130
warning: sshd: no such process name in /etc/xinetd.conf
client: address 195.113.21.130
server: process sshd
matched: hosts.allow line 10
access: granted
This seems to be fine. But when I go to the machine 195.113.21.131, I can simply log in with no trouble at all.
This is really strange. Does it have something to do with the xinetd warning? I am not using xinetd... Maybe I'm doing something wrong. If you have experienced such a trouble, please give me a hint.

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.

/etc/hosts.allow versus iptables/firewall?

What's the relation between the /etc/hosts.allow and /etc/hosts.deny files, on the one hand, and a host firewall on the other? If I'm going to configure iptables on a machine, is there any point to having any non-trivial rules in /etc/hosts.allow and /etc/hosts.deny too? Or should I just set them to let everything connect and do all my configuration through iptables?
(Well, really, I'm going to use some iptables-for-dummies tool like ufw or firehol.)

I cannot agree that hosts.{allow,deny} are 'a lot more basic' They're different from iptables, they work on different level and offer different capabilities, but it would be much harder with iptables to grant/deny access according to:
- ident lookup
- NIS netgroup
- domain name
- consistent ip->name and name->ip mapping
and so on; man 5 hosts_access and man hosts_options contain some examples. On the actions side, in addition to granting or denying access, arbitrary command can be run in parallel or instead of called service, with some useful informations about connection available as %variables.
Tcp_wrappers do not have to be called by protected service itself; they can be used with everything that uses TCP and can be run via (x)inetd, with a little help from tcpd(8).
I prefer iptables myself (no use in letting unwanted traffic pass any further than strictly necessary), but tcp_wrappers make a really nice and useful complementary solution.

Entry in /etc/hosts.allow for insecure VNC?

I read the ssh wiki article which teaches to add an entry to /etc/hosts.allow for sshd. I am know that tunneling vnc through sshd is the way to go security wise, however, there are cases where I need to switch on un-encrypted vnc for the purposes of sharing my X11 session with family members. Anyway, my question deals with an entry in the /etc/hosts.allow for gnome's desktop sharing (which is vnc as I understand it). Does anyone know the syntax to allow vnc for any incoming connection (default port of 5900).
I have tried:
vino: ALL
Xvnc: ALL
X11vnc: ALL
None of which worked.
Thanks!

when I don't know what's the name of the process listening to specific port, I always execute
netstat -tnlp
to get the proper processes' names.

Syntax of ip ranges in /etc/hosts.allow

How does one define a range of IP addresses in the /etc/hosts.allow? Pasted from the ssh wiki article
# let everyone connect to you
sshd: ALL
# OR you can restrict it to a certain ip
sshd: 192.168.0.1
# OR restrict for an IP range
sshd: 10.0.0.0/255.255.255.0
# OR restrict for an IP match
sshd: 192.168.1.
If I just want 192.168.1.2 - 192.168.1.10 (inclusive), what would the syntax be for this?
192.168.1.2/192.168.1.10 didn't work for me.
Thanks.

You can't do this on a single line AFAIK since .2 to .10 doesn't fit in any valid CIDR mask. You will need to add a line for each host individually:
sshd: 192.168.1.2
sshd: 192.168.1.3
sshd: 192.168.1.4
sshd: 192.168.1.5
sshd: 192.168.1.6
sshd: 192.168.1.7
sshd: 192.168.1.8
sshd: 192.168.1.9
sshd: 192.168.1.10
Technically there are multiple /30 masks that fit within that, but you'd still have to have multiple lines.
Last edited by fukawi2 (2009-06-06 22:45:26)

Having issues-/etc/hosts.deny /etc/hosts.allow!

OK-I just did an install of Arch '09 x86_64 core on my HP Pavillion a810n AMD Athlon64 3300+. I got to the part about configuring and the directions just aren't very clear...What EXACTLY do I input to both deny/allow to be able to get on the net to install gnome/X, etc??
Why would anyone by default have the net services turned off when to have a Viable OS you need more packages-did someone miss that?
Thanks.

From the Beginners Guide:
If you do not plan on using the ssh daemon, leave this file at the default, (empty), for added security.
It seems you may be confusing the contents of this file with your inability to reach the network.
What is the exact error(s) you are receiving?
Did you leave the file empty (all lines commented out) ?

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 :-)

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.

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?.

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 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

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.

Pure-ftpd setup (hosts.allow & hosts.deny)

hello,
i have installed pure-ftpd. i have it in daemon section in rc.conf and it's working (wisible from outside) althought my /etc/hosts.deny is
ALL: ALL: DENY
and in /etc/hosts.allow isn't any notice about pure-ftpd (just sshd).
isn't that weird?
thanx for answers.

If your version of pure-ftpd was build without tcpwrappers, but might explain it.

Hosts.allow option spawn parameter not work

Hi,
I would like to use BlockHosts and spawn it with spawn keyword from hosts:allow, but option parameter does nothing for me.
I tried several configurations with different sshd entries and results are below
hosts.deny:
ALL:ALL:DENY
With hosts.allow:
sshd:ALL
I can connect to sshd.
With hosts.allow:
sshd:ALL:DENY
I can still connect to sshd. But I do not know why.
With hosts.allow:
sshd:ALL:spawn (echo "some tries to log" >> /var/tmp/sshd.tmp)
I can connect but nothing is written to temporary log file.
With empty hosts:allow I cannot connect to sshd.
I cannot find any clue, from man entry everything seems clear, but it does not work as it is written in doc.
Thanks,
Ondra
Last edited by xnovako2 (2010-02-20 16:53:23)

the Access files are read in order of /etc/hosts.allow, and /etc/hosts.deny
by default, /etc/hosts.deny contains ALL:ALL:DENY, only the first two are important, then third DENY is the placeholder for shell scripts, only the first two are considered, so ALL:ALL means that all daemons for all connections will not be allowed access, you can specifically add a specific service like sshd using sshd:ALL in /etc/hosts.allow to allow access.
sshd:ALL:DENY, the DENY part is the place where you should put the location of your shell script (absolute path), writing DENY will not deny it access
http://linux.die.net/man/5/hosts.allow
use the above link for a complete help on this.

Is SID allowed to show up in /etc/hosts file?

Experts:
I am looking into a /etc/hosts which has something I never saw before.
Every entry in that /etc/hosts file has a format as follows:
123.23.456.678 CHERRY CHERRY.RIO.COM SID CHERRY.BRAVO.NET
For example:
123.23.456.678 CHERRY CHERRY.RIO.COM PRO CHERRY.BRAVO.NET
Observation:
0) WHY SID (here is PRD) gets into the hosts file? Would it cause some issues?
1) each entry has 2 aliases ;
2) "nslookup CHERRY.RIO.COM "
2a) will return the correct IP address IF I run this nslookup on the server
2b) will say "non-exist domain" on my PC
3) "nslookup CHERRY.BRAVO.NET"
3a) will say "non-exist domain" IF I run nslookup on the server
3b) will give the correct IP address on my PC
Thank you for help.

Hi,
If your system in domain than the entries look like below
192.192.192.192 prdserver prdserver.na.jjjjjjj.com
Prd server is an host name where your SAP application is running/installed & prdserver.na.jjjjjjj.com is a hostname in domain
Thnaks
Karan

Tcp wrappers /etc/hosts.allow format

Similar Messages

Maybe you are looking for