[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Access problem solved



On Thu, 30 Dec 1999, Carl Fink wrote:

> As a listmember pointed out, the problem was in my hosts.deny file,
> not hosts.allow.  Once I read the man page carefully I changed the
> line to ALL: ALL and telnet/ftp/smtp were locked.

/etc/hosts.allow and /etc/hosts.deny are used by tcpd and only
affects services that are run thru inetd.  inetd is a so-called
"super server" in that it monitors the ports for various services,
and when incoming connections occur, it passes control on to the
actual server daemon.  however, if you have tcpd installed (which
you do), inetd is tricked (sort of) into passing control on to
tcpd.  tcpd then consults hosts.allow and hosts.deny such as:

[from "man 5 hosts_access"]:

     - Access will be granted when a (daemon,client)  pair
       matches an entry in the /etc/hosts.allow file.

     - Otherwise,  access  will  be  denied  when  a (dae-
       mon,client)  pair   matches   an   entry   in   the
       /etc/hosts.deny file.

     - Otherwise, access will be granted.

> Oddly, this *didn't* lock http (port 80), though.  A quick check of
> inetd.conf indicated that inetd doesn't handle http connections.  So
> I edited boa.conf to only "listen" for connections from 127.0.0.1. 
> (I only have a web server at all to handle dwww.)  Now all ports are
> closed.

httpd is (usually, and in your case) run as a stand-alone server,
and not through inetd, as most web servers handle lots of requests
and it would waste system resources to run it through inetd.  and
httpd itself listens on the port, and control never gets passed on
to tcpd, so it can't refuse the connection.

> Interestingly, the scanner at www.gsr.com still shows my ftp, smtp,
> and telnet ports as "open".  My tests indicate that one can connect
> to the port, but not actually do anything before my host closes the
> connection again.  

as stated above, the connection *DOES* get established.  then tcpd
gets control and checks it's access rules.  if it finds that the
client should not be allowed to connect, it immediately drops the
connection, so you get something like this:

[hypnos@lemnos:tty3:~]$ telnet localhost
Trying 127.0.0.1...
Connected to lemnos.
Escape character is '^]'.
Connection closed by foreign host.

also, your mail server, running on port 25, probably also runs
stand-alone.  it will not be affected by hosts.allow or hosts.deny
either, so you may want to double check that it's not open.

> Someone suggested using IPCHAINS.  The thing is, my only goal is to
> lock *everyone* outside my local LAN out, while trusting everyone
> within 198.162.  If I need more complex rules, I will investigate
> IPCHAINS.

ipchains is very useful.  it takes a little bit to get used to its
syntax, and remember the various options, but once you do it's very
powerful.

in my /etc/ppp/ip-up file (executed when a ppp link is established),
a total of 5 lines which create various firewall rules.  there's one
line for each of: mail server, dns server, web server, sql server,
and x windows server.  they block incoming connections on those ports
from any packets coming in over the ppp0 interface, so anything on
the lan isn't affected.  i also have access rules in hosts.allow and
hosts.deny, but to get that far, they have to make it through the
firewall. :)

hope this little (?) explanation helps you to understand a bit :)

------------------------------------------------------
hypnos              <mailto:hypnos@m-net.arbornet.org>



Reply to: