Newsgroup: it.comp.os.linux.iniziare
Titolo: hosts.allow e hosts.deny

Devo limitare gli accessi tramite i file in oggetto qui
sotto riportati:
$ cat /etc/hosts.allow
#
# hosts.allow   This file describes the names of the hosts which are
#               allowed to use the local INET services, as decided
#               by the '/usr/sbin/tcpd' server.
#
$ cat /etc/hosts.deny
#
# hosts.deny    This file describes the names of the hosts which are
#               *not* allowed to use the local INET services, as decided
#               by the '/usr/sbin/tcpd' server.
#
# The portmap line is redundant, but it is left to remind you that
# the new secure portmap uses hosts.deny and hosts.allow.  In particular
# you should know that NFS uses portmap!
----Il mio problema e non so cosa scriverci dentro per bloccare tutti
----gli indirizzi tranne uno che si deve loggare da remoto in SSH,SCP.
Chi i può gentilmente dare una mano ;)
Grazie

 ----gli indirizzi tranne uno che si deve loggare da remoto in SSH,SCP.
Achtung! I files riguardano solamente i servizi sottomessi al tcp-wrapper
tcpd (guardare in proposito inetd, "the internet superserver daemon").
Se non lo sono, devi guardare se posseggono un loro meccanismo per stabilire
una policy delle connessioni...
Come ultima risorsa... ipchains/iptables.    ;-)
bye G.L.
--
« E' assolutamente evidente che l'arte del cinema
 si ispira alla vita, mentre la vita si ispira alla TV »
(Woody Allen)

He-Man wrote:

in /etc/hosts.allow:
# per limitare l'accesso alla sola rete 10.128.22.*
sshd: 10.128.22.*
# altrimenti il solo indirizzo ip che ti interessa.
in /etc/hosts.deny:
ALL : ALL
Ovviamente questo non e' un firewall :))
Nicola.
-- 
chi va pian va san e va lontan

 $ cat /etc/hosts.deny
man 5 hosts_access
-- 
Sono un servitore del Fuoco Segreto, e reggo la fiamma di Anor.
A nulla ti servira' il fuoco oscuro, fiamma di Udun.
Torna nell'Ombra! Non puoi passare.


E' vero, ma cosa cambia in fin dei conti???
Perdonate l'ignoranza

 E' vero, ma cosa cambia in fin dei conti???
La risposta te l'ha gia' data G.L. :
Achtung! I files riguardano solamente i servizi sottomessi al tcp-wrapper
tcpd (guardare in proposito inetd, "the internet superserver daemon").
Ad esempio httpd resta fuori da questa logica, perche' non e' un servizio
xinetd (IMHO, da me funziona cosi').


 xinetd (IMHO, da me funziona cosi').
Con le dovute eccezioni, vorrei meglio precisare: se un servizio che appare
essere standalone, usa le libwrap (e.g.: sendmail cosi' come e' compilato e
distribuito con la redhat), esso considera i files /etc/hosts.[allow|deny],
pur se non sottomesso a inetd/xinetd.
Altra precisazione: vi sono servizi (compresi apache), che possono essere
configurati in modo da girare standalone, oppure essere sottomessi a inetd.
Ulteriore precisazione (a costo di essere noioso): non tutti i servizi
sottomessi a inetd passano necessariamente per il tcp-wrapper (a tal
proposito basta vedere ad esempio se nella riga di configurazione relativa su
/etc/inetd.conf viene richiamato o meno il tcpd...)


 su /etc/inetd.conf viene richiamato o meno il tcpd...)
Ma inetd esiste ancora? Sulla mia RH9.0 non ce n'e' piu' traccia. O ti
riferisci sempre a xinetd? Mi risulta che xinetd abbia sostituito inetd
(tutto IMHO naturalmente).
Grazie, Nicola.


 (tutto IMHO naturalmente).
Su slack AFAIK c'e` ancora. Comunque xinetd, AFAIK, puo` usare
sia le libwrap (e quindi il discorso continua a valere) sia il
suo meccanismo interno
-- 
 Francesco Romani - Ikitt  | Describe your vision, the meaning is missing |
*** mailserver: 
freemail.it
| Won't anybody listen?                        |

 (tutto IMHO naturalmente).
Vale cio' che ha giustamente detto lkitt.
