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.

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.

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

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.

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

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.

Assist , how do i allow hosts in inside segment to reach out segment and vice versa taking into account the security levels

ASA Version 7.0(8)
hostname BUJ-IT-ASA-LAN-2
domain-name leo.bi
enable password MgKXXPviZgW4zhKc encrypted
passwd 2KFQnbNIdI.2KYOU encrypted
names
dns-guard
interface Ethernet0/0
description connects ucom lan
nameif inside
security-level 100
ip address 192.168.0.13 255.255.248.0
interface Ethernet0/1
description out interface
nameif outside
security-level 0
ip address 192.168.254.1 255.255.255.0
interface Ethernet0/2
shutdown
no nameif
no security-level
no ip address
interface Ethernet0/3
shutdown
no nameif
no security-level
no ip address
interface Management0/0
shutdown
nameif management
security-level 100
ip address 192.168.1.1 255.255.255.0
management-only
ftp mode passive
same-security-traffic permit inter-interface
same-security-traffic permit intra-interface
pager lines 24
logging asdm informational
mtu management 1500
mtu inside 1500
mtu outside 1500
no failover
asdm image disk0:/asdm-508.bin
no asdm history enable
arp timeout 14400
timeout xlate 3:00:00
timeout conn 1:00:00 half-closed 0:10:00 udp 0:02:00 icmp 0:00:02
timeout sunrpc 0:10:00 h323 0:05:00 h225 1:00:00 mgcp 0:05:00
timeout mgcp-pat 0:05:00 sip 0:30:00 sip_media 0:02:00
timeout uauth 0:05:00 absolute
username UcomIT password Tx95VR7l4gIiavnh encrypted
aaa authentication ssh console LOCAL
http server enable
http 192.168.1.0 255.255.255.0 management
http 192.168.0.0 255.255.248.0 inside
no snmp-server location
no snmp-server contact
snmp-server enable traps snmp authentication linkup linkdown coldstart
crypto ipsec security-association lifetime seconds 28800
crypto ipsec security-association lifetime kilobytes 4608000
telnet timeout 5
ssh 192.168.0.0 255.255.248.0 inside
ssh timeout 5
ssh version 2
console timeout 0
dhcpd address 192.168.1.2-192.168.1.254 management
dhcpd lease 3600
dhcpd ping_timeout 50
dhcpd enable management
class-map inspection_default
match default-inspection-traffic
policy-map global_policy
class inspection_default
inspect dns maximum-length 512
inspect ftp
inspect h323 h225
inspect h323 ras
inspect rsh
inspect rtsp
inspect esmtp
inspect sqlnet
inspect skinny
inspect sunrpc
inspect xdmcp
inspect sip
inspect netbios
inspect tftp
inspect icmp
service-policy global_policy global
Cryptochecksum:ba068a6f85d256ce9351d903c60873e5
: end

Hi,
Its success really depends on the rest of the network that I dont know about.
If you hosts that you are using to PING/ICMP through the ASA are connected to the same network as the ASAs interface then you will have to make sure that the hosts both have routes towards the other network.
Also if on the "outside" of the ASA there are additional networking devices then you have to configure default route on the ASA also as mentioned in the other discussion.
route outside 0.0.0.0 0.0.0.0
The above replys ACL was just an example of the configuration format. If you wanted to allow ICMP then you would also have to allow ICMP
access-list OUTSIDE-IN permit icmp 192.168.254.0 255.255.255.0 192.168.0.0 255.255.248.0 echo
I dont see anything else wrong with the ASA configuration related to ICMP other than possibly the lacking of default route and allowing the ICMP from the "outside" with the ACL "OUTSIDE-IN".
Go through the network setup from one host to the other. On each step confirm that that device has route towards both of the networks. Otherwise the devices will naturally not be able to forward the ICMP messages from end to end.
- Jouni

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

Client host rejected: Access denied

Getting a ton of bounced back emails most likely the address is no longer in use but I filtered out any of the emails that say so. I'm no professional at this thats why I'm looking for help here. I tried searching for the problem on the forum but found
stuff about server 2003.
Im getting alot of the kickbacks saying Client host rejected: Access denied
I've tried emailing the recipient on my personal Gmail and recieved the same error. can we safely say that the addresses are no longer in use that i'm getting these kickbacks? heres the full header for anyone
who wants to look.
The original message was received at Wed, 5 Mar 2014 15:29:34 -0500 from odbmap07.extra.chrysler.com [129.9.107.35]
   ----- The following addresses had permanent fatal errors ----- <mail address here>
    (reason: 554 5.7.1 <unknown[151.171.97.83]>: Client host rejected: Access denied)
   ----- Transcript of session follows ----- ... while talking to odbmap07.out.extra.chrysler.com.:
<<< 554 5.7.1 <unknown[151.171.97.83]>: Client host rejected: Access denied
554 5.0.0 Service unavailable
We are using someone to host our email server for more information.
I use a program called G-Lock easy mail to send out our newsletter.

Hi,
Which email client are you using to send and receive emails? G-Lock?
Please refer to the links below and check if they help:
http://www.symantec.com/business/support/index?page=content&id=TECH169847
http://support.mailhostbox.com/email-administrators-guide/error-codes
In addition, if you are not using Microsoft Outlook as your email client, it's better to contact the support for your mail client for further assistance.
Best Regards,
Steve Fan
TechNet Community Support

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)

Can't Disable "Allow Host Cache Flushing"

I have problems if I have "Allow Host Cache Flushing" on when I digitize video. When I turn it off I have no problem whatsoever. The problem I have is that when I turn it off it won't stay. I'll press okay and then go and check it again and it is checked. Does anybody know what is going on.
I had just brought a 1.5 hr program online and now all the video has dropped frames because it didn't stick.
Dual 2.0 G5 Mac OS X (10.4.7) FCP 5.0.4, XRaid Admin Software 1.5

I have the same problem and it's not the cache batteries. It's just a preference corruption, whose solution I do not know. I doubt you are doing anything wrong. Any time I noticed a dropped from on capture, I go to the Raid Admin and re-do the performance settings, then it works fine for a long time.
Steve Covello
double wide post

OAM - Preferred HTTP Host vs Host Identifiers

Hi all,
I think I am missing something regarding Preferred HTTP Hosts and Host Identifiers. This is what the documentation says about them:
"The Access System offers two methods for identifying Web servers that are hosting protected resources:
* Preferred Host
* Host Identifiers
You can specify either a Preferred Host or a Host Identifier"
However, regarding the Preferred HTTP Host, it also says it is a required field when configuring a WebGate and that the Preferred HTTP Host must be one of the entered in the Host Identifier List.
So I guess that when one intends to use Host Identifiers, the preferred host identifier must be defined as well, but somehow it will be ignored and the Host Identifier will be used instead?
Any help would be greatly appreciated.
Thanks

Regarding the 'required' field - this is a bug (maybe someone will come out of the wood work and disagree with me?) - what version of the product are you working with?
The theory goes like this: Host Identifiers are the line between the real world network and the inner workings of the product. If you want OAM to deliver AAA services, then you have to successfully cross this line. You successfully cross this line by issuing a HTTP request with a host component that matches one of the values in a Host Identifier's Host Name Variations list (If you want to avoid OAM AAA Services, you deliberately avoid this matching). One thing to be clear about - Host Identifiers are not optional if you are protecting HTTP resources. They are required.
Clearly, there is a security concern at play based on this thinking. What if you forget to add an addressable pattern to the variations list and someone walks around your security by IP address or localhost, for example? Preferred HTTP Host instructs the WebGate plugin to explicitly set the host component of every request to the value specified. Usually you intend this to match a value in the Host Name Variations list and your worries are gone.
There are some web architectures using virtual hosting where you deliberately do not want to mutate all host values into the same string - that's why this field should not be required.
The way to manage security risk when not using the Preferred HTTP Host is to combine the use of Host Name Variation values with the Deny On Not Protected flag on the WebGate. This way, the system will only allow traffic that you have specifically configured to be exposed.
Hope that all makes sense and helps somewhat.
Mark

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

Similar Messages

Maybe you are looking for