[Solved] hosts.deny vs. hosts.allow

Hi,
I was looking for some detailed documentation about hosts.deny and hosts.allow. I have a vague idea that this is what is called "tcp wrappers", but I'm not sure. Can someone point me to some relevant documentation? I couldn't find anything in the wiki.
Last edited by kikinovak (2011-01-22 08:51:28)

man 5 hosts_access
And yes, it is tcp_wrappers.

Similar Messages

[SOLVED] how do hosts.allow and hosts.deny work?

I understand the basic concepts of hosts.allow and hosts.deny, but I am interested in how it works. What actually blocks access to the services? Do they do it themselves? Or it is something in the kernel that does it?
For example, if I have this in my hosts.allow:
sshd:all
#mysqld: all
And this is my hosts.deny:
ALL: ALL: DENY
This will result in people being able to connect to sshd but not mysqld. Are sshd and mysqld programmed to read these hosts.allow and hosts.deny files? Or is there something stopping the connection before it even gets to the daemon?
The hosts.allow and hosts.deny man pages refer to tcpd, but it is not running on my system. Also, hosts.allow and hosts.deny never show up in the output of `lsof`. hosts.allow and hosts.deny belong to the tcp_wrappers package, but there is nothing else in the package that illuminates my question.
Last edited by partner55083777 (2010-03-15 12:35:51)

Thanks guys.
However most common network service daemons today can be linked against libwrap directly.
Sure enough,
$ ldd /usr/sbin/sshd
linux-vdso.so.1 => (0x00007123451ff000)
libwrap.so.0 => /usr/lib/libwrap.so.0 (0x00007fffbd6d000)
libpam.so.0 => /lib/libpam.so.0 (0x00007f99765f1000)
$
Here is also a little bit more information about libwrap:
http://en.wikipedia.org/wiki/Libwrap
Last edited by partner55083777 (2010-03-15 20:03:11)

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.

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.

Daemons for hosts.allow and hosts.deny?

I want to use hosts.allow and hosts.deny to restrict access to my servers, but I'm not sure what daemons to use in the config files for services like remote desktop or server admin. Is there any way to specify those services? Can you do it with port numbers instead of service names (man 5 hosts_access wasn't very clear to me).
For services like http and ssh, its a no-brainer, but I can't figure out the Apple specific stuff.
Thanks,
Miles
11 G4 XServes... Mac OS X (10.4.5)

If you are referring to the python script, "denyhosts" that works in conjunction with xinetd, this simply works under 10.3.x, I've used it once successfully. It needs to be configured correctly, but it does work. Did not try it with 10.4, but...
the far better option is described by Leland.

How to use the hosts.allow option in Directory Server?

I would like to limit access to a directory server instance to localhost. I see in the Directory Server Control Center that there is an option to do this with a hosts.allow and/or hosts.deny file.
What do I enter as the service name for the instance in the hosts.allow file?
Thank you.

See:
http://docs.sun.com/app/docs/doc/820-2491/6ne3dhdgt?l=en&a=view#gcwym
And perhaps more useful:
http://docs.sun.com/app/docs/doc/820-2495/6ne3hbg4j?l=en&a=view
This feature is basically an app-specific instance of TCP wrappers, so look up "TCP wrappers" in your favorite search engine for more.

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

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.

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.

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)

[solved] "permission denied" even though I am logged in as root

Hi, I just installed Arch and now I am trying to add repositories to pacman.
I am currently logged in as root
[root@arch ~]#
Now I am trying to access /etc/pacman.conf by typing
/etc/pacman.conf
wich returns
-basch: /etc/pacman.conf: Permission denied
So I checked the forum and the wiki how to check permissions for files. found this wiki.archlinux.org/index.php/File_Permi … ermissions
so I did
# cd /etc
# ls -l
wich gave me
-rw-r--r-- 1 root root 2862 Jun 18 06:01 pacman.conf
If I read this correctly it says that "root" can read and write. But I am logged in as "root" so why can I not edit the file?
Last edited by ningfengrui (2013-08-21 09:50:17)

No problem at all & welcome to arch.
If you had not been so new, I would not of been this kind to you because the first result of a google search of "basch: /etc/pacman.conf: Permission denied" would have given you the answer you needed
But hey! we all make the same mistake, but be sure to search for the answer before you ask here.
Also, you need to edit the title of your original post to read "[Solved] "permission denied" even though I am logged in as root"
lecture over ! & again, welcome to arch

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

Will the rdsesion host allow you to remotley access without any cals?

Hi,
so I was just wondering before I purchase any rdscal license for server 2008r2, is the rdsession host accessable via internet(mainly a remote office) when there are no licenses installed other than the 120 day trial.

Hi,
Thank you for your posting in windows Server Forum.
Yeah, agree with words of TP. You can able to access 2 RDP session without purchasing any single RDS CAL or license server installed. As that is used only for administrative purpose.
More information:
Overview of Remote Desktop Licensing
http://technet.microsoft.com/en-us/library/cc725933.aspx
Hope it helps!
Thanks,
Dharmesh

[Solved] hosts file with ipv6 disabled

Hello community!
So I have disabled ipv6, as it was causing various issues and Comcast has not yet implemented ipv6 in my area. Disabling was no problem, but nowhere can i find information regarding whether or not to keep the ipv6 line in the hosts file. Should I comment it out?
For clarity I am referring to the ::1 line. Will commenting it out be problematic, or will keeping it be problematic, or does it not really matter? I know having an improperly configured hosts file can cause all sorts of network issues, so I am very curious.
Right now I have it commented out, and I have not noticed any real problems, but I also have a Realtek wireless card using rtl8192ce, which is not the most stable driver/connection. Thus my connection is kind of intermittently crappy. So I am curious if I am making my connection crappier than it was before.
Thanks in advance!
Edit: Of course as soon as I posted this, I found an answer. The Debian wiki recommends commenting it out when completely disabling ipv6. So to those who at least read my post, thanks!
Last edited by WonderWoofy (2012-08-19 20:19:44)

@WonderWoofy,
Do you have a link for the Debian wiki? I'd like to understand the reasoning.
To be honest, I didn't even realise that line was for ipv6. Since I've disabled it in sysctl.conf, I should probably consider commenting it out, too. Right now, I seem to be loading firewall modules for ipv6, mind, which seems like slightly more security than can be strictly necessary if the thing is disabled...
@ghen,
It isn't, that I know of, a matter of "figuring it out correctly". Having ipv6 enabled can screw up ipv4 connections. Having it enabled prevents me from connecting to the internet at all on one of the networks I use. As I understand it, a properly configured network shouldn't do this but when the official IT support people say the problem is that you have ipv6 enabled, you don't have much choice. (And it isn't as if there's anything to be gained by having it enabled.)

[Solved] hosts.deny vs. hosts.allow

Similar Messages

Maybe you are looking for