Newsgroup: it.comp.os.linux.sys
Titolo: SAMBA e firewall... porta 139?!?

CIao a tutti!
Ho un server Linux (in casa) che condivide dei file con SAMBA. Ora mi sorge
un dubbio: anche con Linux deve essere aperta la porta 139 per condividere i
files (come su Winzozz!)??? Vorrei infatti partire a commentare nel file
/etc/services le porte che non mi servono, evitando di fare tutto da
firewall (ipchains)...
Grazie per ogni aiuto/suggerimento...

Si, la porta 139 è usata, ma devi lavorare con ipchains, /etc/services serve per
identificare un nome al numero della porta..
..sei il tuo firewall si basa sul togliere i nome alla porte...sei nei guai...

In un messaggio del Mon, 12 Feb 2001 11:09:00 +0100 OxygeN scriveva:

Certo che deve essere aperta ma gli accessi a Samba li regoli dal tuo
/etc/smb.conf con i parametri globali 'hosts allow' e 'hosts deny'
piuttosto che con ipchains.
-- 
Pierluigi De Rosa (
tho...@durin.khazad-dum.net
).
<<      LINUX: the choice of a GNU generation     >>
<<   For my real address... ask the Balrog.       >>
* Sostenete la Lega per la Soppressione dei Troll *

 ha scritto nel
messaggio news:3A87BBF0...@lastminutetour.com...


Il tcpwrappers è comandato inetd.conf, ep ri servizi, e come diceva
Pierluigi da hosta.allow e deny per le auotirzzazioni.
Sono dell'idea comquneu che è meglio lasciare ad ipchains il ruolo fi filtro
per tutt el erichieste alla porta 139 non proveniente dalla rete locale...

..sei il tuo firewall si basa sul togliere i nome alla porte...sei nei guai...
Ahia... temo che tu abbia ragionissima =:-O
-- 
Crononauta
==========               | togli 'sse' dall'indirizzo  | 
ICQ UIN: 4005815         | per rispondermi in e-mail   | 
IDAnet: 
http://adcserver1.biodip.unimi.it/IDA/index.html
GP Legends: 
http://www.multiplayer.it/driving/index.html

firewall (ipchains)...
Mmmhhh... io avevo un firewall configurato come si deve, tranne UNA
porta, e mi hanno rootato il server. 
Se il tuo livello di conoscenza del firewall è quello di commentare le
porte in /etc/services, mi sa che a breve ti farai *molto* male.
/etc/services è unicamente informativo, serve solo a dare un nome alle
porte quando fai un neststat, ovvero invece di scriverti (per
esempio):
TCP	localhost:25	
0.0.0.0:0
	LISTENING	[1]
lui "sa" che la 25 è la porta dell'smtp e ti presenterà la riga come:
TCP	localhost:smtp	
0.0.0.0:0
	LISTENING	[2]
Se commenti la riga relativa alla porta 25 in /etc/services,
semplicemente il sistema non saprà più che nome dare alla porta 25
quando chiedi un netstat, e se farai un netstat -a otterrai una riga
come la [1]; se invece decommenti la riga, otterrai [2].
Nulla cambia circa l'apertura o chiusura della porta in questione. 
Ti consiglio seriamente di leggere gli how-to di
http://www.pluto.linux.it
 sul firewall.
Eventualmente parti da quello di mr.Shark, non ricordo l'url ma basta
che scorri la lista dei messaggi sul ng e ne trovi uno suo, nella
firma c'è l'indirizzo.
Scusa la durezza, ma se le tue premesse sono quelle, e magari hai pure
un'installazione di default di qualche distribuzione con un bind non
aggiornato (ovvero < 8.3), il tuo server durerà ben poco.
Se non è già stato rootato.


 ha scritto nel messaggio
news:3a87c607....@news.libero.it...


 E con i "tcpwrappers" che cosa posso ottenere??? E dove li configuro?
# man hosts_access


 ha scritto nel messaggio
news:968m70$ahs$1...@durin.khazad-dum.net...


Tcp wreppers è semplicemente, coem quando accendi la macchian e ti regoli lo
specchietto.
Lo devi fare subito, appena hai finito l'istallazione, metti in hosts.deny
ALL:ALL
e in hosta.allow localhost, e se c'è l'hai la tua rete..
poi studi ipcahisn, ma quello lo devi fare....

 Ah, inoltre: con un kernel 2.4 uso ancora ipchains per firewalling???
No, ora devi usare iptables.


 ha scritto nel
messaggio news:3A87E8D4...@lastminutetour.com...


 > Cmq mi dite che partire con i TCPwrappers è una buona cosa o faccio fare


Non quotare 50 righe per nulla please =)
Ciao
-- 
(N) (a) (i) (l) (m) (a) (n)
  ] - remove (dot) from my email address to reply - [
      ] - 
http://setiathome.ssl.berkeley.edu
 - [

mio PC a casa...
L'iptables-HOWTO non esiste ancora mi  pare. Cerca il NAT-HOWTO c'e` una
sezione  su iptables.  Puoi  usare  ipchains sul  2.4  usando un  modulo
speciale che ne mantiene la compatibilita` ma e` meglio che ti "traduci"
il firewall di shark da ipchains  a iptables che e` molto meglio secondo
me.


Linux alla rete, mentre da rete a Linux ci riesco!
Non ti so che dire, non ho nemmeno capito bene che intendi! =:-O


 # man hosts_access
A proposito, non ho capito una cosa: Se in hosts.deny scrivo 
"nomeservizio: All" e in hosts.allow "stessoservizio_di_prima: local, 
192.168.0.0/16
", che fa il tcpwrapper? 
-- 
* Jotaro Kujo *
 Can't you see the end
 Twentieth Century Man ? 

 se ti spaccano il server entrano in LAN.
Eh, pero' se uno ha una rete casalinga e non ha la possibilita' di avere 
un gateway E un file_server, e' costretto a tenerli uniti, su un solo pc. 
Ad esempio io ho file_server, news_server, gateway, firewall, 
print_server su un solo pc.


 guarda prima in hosts.allow e se ci trova quello che gli serve non degna di
Ok, grazie.


print_server su un solo pc.
E allora scusa ma con chi devi condividere i dati??? :-)
Samba  et similia  li installi  se  devi condividere  il filesystem  con
macchine windows, il  che implica avere almeno due pc!  Il linux puņ ben
fare da gateway, il windows da file-server.
Cmq quando chiudi le porte 137:139 dall'esterno, fine del problema.
-- 
Crononauta
==========              |  togli 'sse' dall'indirizzo  | 
ICQ UIN: 4005815        |  per rispondermi in  e-mail  | 
IDAnet: 
http://adcserver1.biodip.unimi.it/ida/index.html
GP Legends: 
http://www.multiplayer.it/driving/index.html


192.168.0.0/16
", che fa il tcpwrapper? 
La logica di funzionamento è sempre "deny then allow". Prima viene letto
deny, e  vengono bloccati i servizi  indicati; poi viene  letto allow, e
vengono riaperti quelli indicati.
E' buona norma, per non lasciare buchi, mettere:
ALL:ALL
in deny, e  poi aprire uno alla volta solo i  servizi che ti interessano
(e per gli ip che ti interessano) in allow.
Se metti  ALL:ALL anche in allow,  è evidente che non  hai chiuso nulla,
perché prima chiudi tutto in deny, poi lo riapri in allow.


 uno sguardo hosts.deny (cfr. Linux Network Admimistrator's Guide)
Uhm... allora com'e' che se metto in hosts.deny "leafnode: ALL" e in 
hosts.allow "leafnode: 
192.168.0.0/24
" non riesco a connettermi dalla 
lan? Se piallo hosts.deny, invece, tutto ok.


 Cmq quando chiudi le porte 137:139 dall'esterno, fine del problema.
Appunto. Quindi non e' un grosso problema.


 
192.168.0.0/16
", che fa il tcpwrapper? 
Nella man page e' scritto, qual'e' la precedenza di lettura dei file
di configurazione. Viene prima hosts.allow comunque. In ogni caso,
come ho gia' detto
# man 5 hosts_access


 vengono riaperti quelli indicati.
Non mi pare proprio.. rileggi *meglio* la man page.


Non mi pare proprio.. rileggi *meglio* la man page.
...uhm... potrei sbagliare sull'ordine di lettura dei due file, anche
se mi pareva di ricordare una logica di "deny then allow" in qualche
guida, forse ma fondamentalmente non cambia mica poi niente, all'atto
pratico:
Se viene letto prima deny, e bloccato tutto, e poi allow, e viene
riaperto (p.e.) telnet, come risultato ho il telnet accessibile e
tutto il resto chiuso.
Se viene prima letto allow, dove c'č solo telnet accessibile, mentre
per tutto il resto non c'č menzione, e allora va a leggere deny e
trova ALL:ALL e quindi blocca tutto... il risultato č sempre che
telnet č accessibile e tutto il resto chiuso :-)
In ogni modo, "vince" allow, questo sě: se metto ALL:ALL in *entrambi*
i file, avrň tutti i servizi accessibili, e non bloccati.
A me viene piů semplice pensare (da un punto di vista di ragionamento
logico), che prima viene chiuso deny e poi riaperto allow, tanto il
risultato č lo stesso.
Perň effettivamente... la domanda che viene č: e se io non metto
niente in entrambi che succede?
Si passa o no? Se la politica č di leggere prima deny poi allow...
passa tutto... viceversa passa niente... uhm...
-- 
Crononauta
==========               | togli 'sse' dall'indirizzo  | 
ICQ UIN: 4005815         | per rispondermi in e-mail   | 


lan? Se piallo hosts.deny, invece, tutto ok.
Per come la vedo io fai prima a mettere hosts.allow a all:all e poi rendere
i servizi della macchina disponibili solo sulla rete interna. Hai
flessibilita' maggiore.
...
 Can't you see the end
 Twentieth Century Man ?
Ma non era twentieth century schizoid man?
King crimson? Forbidden? Di chi era la canzone che non mi ricordo...
--
  	Giuseppe "Cowo" Corbelli  -->>  Riding on Linux-2.2.16
    **ANTI-SPAM** -- **Substitute IHATESPAM with cowo to reply by mail**
  -<! I Never Wanted To Be What They Told Me To Be
  		Fulfill My Fate Then I'll Be Free >!-
  			Blind Guardian - Mordred's Song

 telnet č accessibile e tutto il resto chiuso :-)
Un file vuoto e' considerato come esistente, sbagli..
-- 
|Pierluigi De Rosa (
tho...@durin.khazad-dum.net
)|
|     E' nato il Cosenza Linux User Group	|
|   mail -s help 
cslug-...@lists.linux.it
	|
|      IRC: #cslug - 
irc.openprojects.net
	|

file inesistente e uno vuoto sono la stessa cosa per il wrapper.
Scusa ma...:
* Caso 1, "allow then deny"
allow ALL:localhost
deny ALL:ALL
L'algoritmo decisionale sarà qualcosa di questo tipo:
Arriva una richiesta di accesso.
Processa host.allow.
	L'accesso ha un match nel file?
	sì (accesso da localhost): fai passare, stop.
	no (accesso <> da localhost): passa a host.deny.
		Processa host.deny:
		C'è un match?
		si (ovviamente, qualunque accesso): blocca;
		no (impossibile, con ALL:ALL): fa passare.
* Caso 2, "deny then allow"
deny ALL:ALL
allow ALL:localhost
algoritmo:
Arriva una richiesta di accesso.
Processa host.deny
La richiesta ha un match?
si (ovviamente, con ALL:ALL): bloccalo, stop.
e... e... e... EHM!!!!!!
Uhm... mi sa che hai ragione.... =:-OOOOO
In ogni modo però convieni con me che è buona norma mettere ALL:ALL in
deny, e lasciar passare *solo* gli accessi che si vogliono consentire,
in host.allow.
Piuttosto che il contrario, cioè far passare tutto da host.allow e poi
bloccare gli accessi indesiderati da host.deny.
(BTW era poi questo il concetto che volevo esprimere...!)


 Scusa ma...:
LEGGI LA FOTTUTA MAN PAGE !


LEGGI LA FOTTUTA MAN PAGE !
Eccola qua... (dalla guida di Daniele Giacomini):
---8<---
Se il file è vuoto, o  manca, sono consentiti tutti gli accessi; se sono
  presenti delle direttive, viene verificata la corrispondenza dell'host
  a  queste direttive.  Alla  prima corrispondenza  trovata, la  ricerca
  termina,  ignorando  anche   il  file  /etc/hosts.deny.  È  importante
  ribadire che se un host  non corrisponde ad alcuna delle direttive del
  file  /etc/hosts.allow, questo  significa  solo che  questo accesso  è
  consentito, a meno che venga poi impedito da quanto contenuto nel file
  /etc/hosts.deny.
---8<---
Ma non  mi sembra che  si arrivi ad  altro se non  a quello cui  ero già
giunto:  ovvero, se io  voglio aver  la certezza  di abilitare  *solo* i
servizi che mi interessano, bloccando "di default" (per così dire) tutti
gli  altri, devo  mettere  ALL:ALL  in host.deny  e  poi abilitare  ogni
servizio in host.allow.  
In questo modo,  se il servizio è abilitato,  si trova la corrispondenza
in allow  e viene permesso;  viceversa, passa a scorrere  host.deny dove
comunque viene bloccato tutto.
-- 
Crononauta
==========              |  togli 'sse' dall'indirizzo  | 
ICQ UIN: 4005815        |  per rispondermi in  e-mail  | 


 servizio in host.allow.  
Mica tanto: se metto ALL : ALL in /etc/hosts.deny mi rifiuta il telnet
anche da una macchina cui il telnet era concesso in /etc/hosts.allow,
tolto ALL : ALL magicamente funziona.


 tolto ALL : ALL magicamente funziona.
Scusate: non vorrei capire male!
Ho messo ALL:ALL in hosts.deny e in.telnetd:192.168.0.124 in hosts.allow
Io dalla macchina 124 dovrei riuscire ad entrare in telnet oppure no?
Io ci riesco ... vorrei capire però come funziona esattamente la politica di
filtraggio con i TCP Wrappers (che però a questo punto penso di abbandonare
in favore di ipchains e/o iptables)...
AIUTATEMI a capire!

 Ho messo ALL:ALL in hosts.deny e in.telnetd:192.168.0.124 in hosts.allow
Ho appena fatto la prova: se si specifica l'IP address in hosts.allow
a me funziona ma se specifico solo l'hostname e c'e' ALL : ALL in
/etc/hosts.deny il telnet mi rifiuta la connessione.


 lan? Se piallo hosts.deny, invece, tutto ok.
Ok, ho risolto. Scemo io a non fare un tcpdchk... in pratica tcpd (almeno 
la versione che ho io) non vuole la versione "corta" della netmask, ma 
quella estesa.


tolto ALL : ALL magicamente funziona.
E' un comportamento  curioso e ai limiti dell'anomalo, e  se ci fai caso
non risponde affatto a quello previsto dal man che riporti sopra.
se tu hai in.telnetd:ALL in  allow, e ALL:ALL in deny, *deve* funzionare
il  telnet. Te  lo posso  garantire, con  quella configurazione  mi sono
collegato dall'ufficio col  mio utente!!!!!!!!!!!!!!! (poi chiusi telnet
temendo  aggressioni...  che  sono   poi  arrivate  ma  sul  nameserver,
ma questa è un'altra storia... =:-O ).
D'altronde, seguiamo esattamente la pagina di man:
'access will be granted when a pair matches an entry in hosts.allow.'
Se   arriva   una  connessione   remota   sul   telnet,  corrisponde   a
in.telnetd:ALL?  Sì certo, viene fatta passare. Fine.
Viceversa, se non c'è corrispondenza, si passa oltre:
'otherwise,  access will  be  denied when  a  pair matches  an entry  in
hosts.deny'
Allora, dopo aver attraversato hosts.allow (e non aver incontrato alcuna
corrispondenza),   viene   processato  hosts.deny   in   cerca  di   una
corrispondenza da bloccare.
Se   qui    c'è   ALL:ALL,   qualunque  cosa  viene   bloccata.   Questa
configurazione, di  fatto (che è  la mia) blocca qualunque  servizio che
non  è esplicitamente permesso  in hosts.allow.  Ed è  come da  guida di
Daniele Giacomini e non so quanti how-to.
Se tu *non*  metti ALL:ALL, invece, tutti i servizi  che non hanno avuto
una  corrispondenza *né* in  hosts.allow *né*  in hosts.deny  seguono la
regola:
'otherwise, access will be granted'
Per  quello  che  mi sembra  chiaro  da  tutto  questo, se  un  servizio
esplicitamente permesso in hosts.allow  *non* funziona se c'è ALL:ALL in
hosts.deny, vuol dire che non trova corrispondenza in hosts.allow.
Insomma,  per farla breve,  o il  file non  lavora (strano),  oppure hai
sbagliato la riga di permesso in hosts.allow, o qualcos'altro che non ti
so  che dire,  perché se  il servizio  ha corrispondenza  in host.allow,
host.deny non viene nemmeno processato, _per quel servizio_.
AFAIK, la tua resta un'anomalia, specie leggendo quella stessa pagina di
man che tu mi riporti!


/etc/hosts.deny il telnet mi rifiuta la connessione.
Ah... questo non te lo so dire, io ho sempre messo i numeri...
Do per scontato che il tuo /etc/hosts sia ok...
Sarebbe  da studiarci  su,  coi nomi  di  host sinceramente  non ho  mai
provato a vedere se funziona.


 flessibilita' maggiore.
Veramente e' gia' cosi', ma preferisco usare ANCHE tcpd per consentire 
l'accesso solo agli ip interni. Sai com'e... la paranoia...
-- 
* Jotaro Kujo *
 Can't you see the end
 Twentieth Century Man ? 

 Do per scontato che il tuo /etc/hosts sia ok...
Infatti lo e', ecco perche' non mi tornano in conti.


 man che tu mi riporti!
Prova con gli hostname e non solo per IP, prima di parlare di anomalie.


/etc/hosts.deny il telnet mi rifiuta la connessione.
funziona se si mette il punto finale all'hostname:
in.telnetd: nomehost.
cosi funziona anche se si specifica il dominio con il punto iniziale (tutti
gli host apparteneti al 
dominio.it
):
in.telned: .
dominio.it
     Paolo

 in.telned: .
dominio.it
Allora, ho appena provato..
/etc/hosts.deny:
ALL : ALL
/etc/hosts.allow:
smtp: localhost: setenv RELAYCLIENT:twist { { /var/qmail/bin/tcp-env /var/qmail/bin/qmail-smtpd 1>&3; } 2 >&1 | splogger qmail; } 3>&1
smtp: ALL : twist { { /var/qmail/bin/tcp-env /var/qmail/bin/qmail-smtpd 1>&3;} 2>&1|splogger qmail;} 3>&1
in.ftpd, in.telnetd : durin., cerberus., cmcsntpd., cmbdc_cs., nefertari., bernadette.
da bernadette (server NT) mi da' "Connection to host lost." mentre
da cerberus (il server Linux):
[pier@mordor Powerslave]$ telnet cerberus
Trying 192.168.4.56...
Connected to 
cerberus.gruppocm-cs.it
.
Escape character is '^]'.
Red Hat Linux release 6.2 (Zoot)
Kernel 2.2.14 on an i586
login: pier
Password: 
Last login: Wed Feb 14 11:09:06 from mordor
[pier@cerberus pier]$ 
[pier@cerberus pier]$ 
[pier@cerberus pier]$ 
[pier@cerberus pier]$ telnet mordor
Trying 192.168.4.212...
Connected to 
mordor.gruppocm-cs.it
.
Escape character is '^]'.
Connection closed by foreign host.
boh...


l'accesso solo agli ip interni. Sai com'e... la paranoia...
La paranoia aumenta le possibilita' di non rimanere scottati e va molto bene.
Ma in questo caso non ti cambia niente.


boh...
si, strano...
comunque per la cronaca da me funziona anche mettendo il FQDN
     Paolo

 mentre da qui si...
E visto che cosi' funziona e non ho necessita' di cambiare cio'
che funziona lo lascio cosi' com'e'.


in.ftpd, in.telnetd : durin., cerberus., cmcsntpd., cmbdc_cs., nefertari., bernadette.
Ho fatto  anch'io le prove. Risultato:  a me funziona *solo*  con gli ip
numerici, eventualmente con le  sottoreti (
192.168.0.0/16
), ma in nessun
modo (con o senza punti) gli hostname funzionano.
Chiaramente anche il mio /etc/hosts è a posto, perché se faccio:
telnet vraptor 23
mi compare il login via telnet, sia dalla LAN che dal localhost.
(vraptor è il mio localhost).
Però scusa, se *non* metti in  deny ALL:ALL, alla fine discrimini solo i
servizi che specifici in hosts.allow, mentre per tutti gli altri che non
citi, equivale a dare accesso libero.
Io metto gli ip numerici e in deny ho ALL:ALL, ma il login lo faccio.


 citi, equivale a dare accesso libero.
Se non metto nulla in deny vuol dire che permetto l'accesso a chi e'
specificato in allow, visto che un deny vuoto equivale ad un deny
inesistente.


inesistente.
un momento: se non si mette nulla in hosts.deny entrano tutti, non solo chi
e' specificato in hosts.allow, lo appena verificato.
     Paolo

Chiaramente anche il mio /etc/hosts è a posto, perché se faccio:
che vi devo dire, da me funziona.
Pero' una differenza rispetto a voi c'e': da me i nomi vengono risolti dal
DNS e non da /etc/hosts.
     Paolo

 e' specificato in hosts.allow, lo appena verificato.
Un'ulteriore prova che ho fatto e' questa:
ALL EXCEPT identd : ALL EXCEPT localhost
in.ftpd, in.telnetd: bernadette. (il server NT)
Beh, stessa cosa... sinceramente non ho tempo e voglia da perderci
dietro ora ma e' una cosa che prima o poi vorro' indagare perche'
di certo non e' normale che vada cosi'.


/etc/hosts.deny il telnet mi rifiuta la connessione.
allora, prova  a ordinare le  cose: tcpd si comporta  cosi' considerando
che  la ricerca  termina quando  si verfica  uan condizione,  risolte in
questo ordine:
i. accesso garantito in hosts.allow
ii. accesso negato in hosts.deny
iii. accesso garantito
Quindi  in sostanza,  viene verificato  se esistono  diritti di  accesso
tramite gli allow, se esiste motivo  per negare il servizio tramite deny
e quindi garantito.
Alcuni risultati: Se  i file sono vuoti garantisco tutto  a tutti (match
sul terzo caso) Se entrambi i file hanno ALL:ALL garantisco ancora tutto
a tutti (match sul primo caso e si ferma)
Il modo corretto quindi di usare i  wrappers e deny a tutti e allow solo
ai servizi/ip/reti che si interessa abilitare
e' possibile usare gli indirizzi ip  per definire client e reti (anzi e'
consigliatissimo) oppure nomi purche' FQDN (il match viene fatto tramite
DNS). Personalmente uso sempre gli ip.
Nel  caso del  "nego  tutto tranne  telnet"  si puo  agire  in due  modi
entrambi validi anche se preferisco il primo:
1) /etc/hosts.deny
   ALL: ALL, PARANOID
   /etc/hosts.allow
   ALL: 127.0.0.1
   in.telnetd: ALL
2) /etc/hosts.deny
   ALL: ALL, PARANOID EXCEPT in.telnetd: ALL
   /etc/hosts.allow
   ALL: 127.0.0.1
L'allow dell'interfaccia di loopback e'  obbligatoria se negate tutto in
deny, pena la  non corretta funzionalita' di  applicazioni residenti che
pero'  girano  sul  modello client/server.  Infine,  potete  controllare
la  validita' della  vostra  configurazione (inteso  come sintassi)  con
tcpdchk.
Il resto delle info per costruire le  regole e sul linguaggio di tcpd lo
potete vedere con man 5 hosts_access
Saluti
-- 
Goto, n.:
	A programming tool that exists to allow structured programmers
to complain about unstructured programmers.
		-- Ray Simard
Maurizio - Tannoiser
Founder Member of ERLUG (Emilia Romagna Linux User Group)
http://erlug.linux.it

 potete vedere con man 5 hosts_access
Riguardero' la man page per capire meglio come vanno indicati gli
hostname, THNX.


'bernadette' che 'bernadette.'
Questo e'  in assoluto uno  dei motivi se non  IL motivo per  cui wrappo
tutto con gli  IP oltre alla possibilta' di esprimere  una serie di cose
"comode" come
ALL: 192.168.0.
per  concedere/negare qualcosa  a una  tipica lan  locale con  indirizzi
privati (e  quindi nomi  non FQDN). Dovrebbe  dipendere dagli  ordini di
risoluzione  dei  nomi,  ma  come  ho detto  tcpd  utilizza  un  proprio
linguaggio. Una domandina: bernardette e' proprio FQDN (nel senso che e'
registrato?).  Credo che  a  titolo di  verifica lui  query  il DNS  per
evitare  spoof attack.  Potrebbe essere  il motivo  dei tuoi  connection
refused.
Per  quanto riguarda  i piu'  nomi su  una stessa  riga francamente  non
ricordo e  so' gia' che starai  leggendo la man page  ;-). Personalmente
per chiarezza  delle rules non lo  faccio mai, ma e'  solo una comodita'
personale, per leggere successivamente meglio i file.


 personale, per leggere successivamente meglio i file.
Probabilmente per comodita' (e levarmi il pensiero) faro' anche
io cosi'.
-- 


 DNS e non da /etc/hosts.
Chi usa /etc/hosts puo' provare a vedere cosa ha in /etc/nsswitch.conf? 
-- 
Saluti - Marco Coli

 Prova con gli hostname e non solo per IP, prima di parlare di anomalie.
Nella mia LAN uso anche gli hostnames e va (anche senza il punto
finale), ma ho il DNS locale come risolutore.


 Chi usa /etc/hosts puo' provare a vedere cosa ha in /etc/nsswitch.conf? 
Questo sul notebook a casa, sul PC in ufficio ve lo dico domani:
[root@durin /root]# sed '/^#/d;/^$/d' /etc/nsswitch.conf 
passwd:     files nisplus nis
shadow:     files nisplus nis
group:      files nisplus nis
hosts:      files nisplus nis dns
bootparams: nisplus [NOTFOUND=return] files
ethers:     files
netmasks:   files
networks:   files
protocols:  files
rpc:        files
services:   files
netgroup:   nisplus
publickey:  nisplus
automount:  files nisplus
aliases:    files nisplus


 finale), ma ho il DNS locale come risolutore.
Ah no, io no, purtroppo il DNS lo gestisce un Niu Tainozz.. per il
resto faccio tutto da /etc/hosts.


 hosts:      files nisplus nis dns
qui sembra a posto (la riga interessata e' quella di hosts appunto).
Come saprete qui si decide la "lookup policy" per la risoluzione dei
nomi da parte delle routine di libreria (come la gethostbyname()). In
base a quanto scritto li', prima si va a vedere in /etc/hosts (files) e
solo dopo, se non si trova la corrispondenza, si procede oltre, fino a
cadere sul dns.
Se anche in ufficio hai cosi', e comunque hosts.allow non va se ci metti
i FQHN, allora vuol dire che la routine di libreria che si occupa di
effettuare il mapping nome/IP in hosts.allow, non segue le regole
imposte da nsswitch, e usa solo il DNS. Baco?


 Come saprete qui si decide la "lookup policy" per la risoluzione dei
[..]
Si, anche sul computer dell'ufficio il file e' identico (vi risparmio
un altro copy+paste perche' sarebbe perfettamente inutile..) quindi a
questo punto non so perche' mettendo gli hostname senza e con il dot
finale oppure anche il FQDN non funziona mentre con gli IP si, boh !
