Newsgroup: it.comp.os.linux.sys
Titolo: Firewall su mail server

Ciao a tutti, ho configurato un server di posta (Sendmail) ed ho un problema
che non riesco a risolvere, sarà sicuramente qualche cazzillo di
configurazione, non è che qualcuno ha già affrontato la cosa? Mi spiego:
la macchina è protetta da ipchains in cui ho aperto l'accesso ai servizi
SMTP, POP3, IMAP da parte dei client (tcp e udp), la macchina può accedere
ai DNS esterni (tcp e udp), ho una sbrodolata di icmp aperti.
Con un client mi collego al server, la connessione è immediata ma passano 30
secondi esatti prima che si passi al controllo password.
Il fatto che si tratti di 30 secondi tondi tondi mi fa sorgere un  sospetto:
POP3 (o Sendmail) deve aspettare forse un timeout per una qualche
interrogazione verso l'esterno (dns, lookup o altro) e ipchains blocca
questa interrogazione (infatti se stoppo ipchains tutto il processo è
istantaneo).
Il problema è che non riesco a capire cosa aprire per eliminare questa
attesa.
Se qualcuno mi può essere utile, ringrazio anticipatamente, altrimenti
saluti a tutti.
Oliviero

 wrote in message
9uitoj$8bvsg$1...@ID-56021.news.dfncis.de...


 attesa.
Tentativo: prova ad aprire la porta sunrpc/udp. Se così funziona potrebbe
essere un problema di configurazione di nsswitch.conf: devi levare i
riferimenti a nis/nis+.
Anche ident, come ti hanno già detto, è un buon candidato.
Non c'è niente di significativo nei log di iptables?
Fabio

>>> (infatti se stoppo ipchains tutto il processo è
istantaneo<<<<<<<<<<<<<
Ho rimarcato la parte che credo debba essere l'oggetto
delle tue attenzioni, qualcuno ti ha gia dato delle
risposte,
Fabio e Paolo che credo conoscano molto meglio di me
il server di posta, però il fatto che se stoppi le regole di
ipchains mantenedo il forward attivo funziona tutto a dovere
mi puzza, io ricontrollerei eliminando una regola alla volta
per vedere quale è che scazza.
ciao.
--
------------------------------------------------------------
---------
Alessio Sommariva  
smmgpp...@tin.it
Piu' passano gli anni piu' m' accorgo che
l'arte dello imparare e lo vizio
del sapere son spirito giovine.
Alessio

 per vedere quale è che scazza.
E ti puzza bene. Quello che intendevamo io e Paolo era proprio relativo a
questo: sunrpc e ident sono servizi legati a specifiche porte. Servizi che, in
alcune situazioni, vengono usati durante la fase di autenticazione della
connessione e che rimangono in sospeso fino al timeout proprio a causa del
filtraggio di ipchains/iptables. Se questa autenticazione o servizio non è
indispensabile l'operazione può poi proseguire.
Quindi i primi tentativi sono diretti proprio ad aprire queste porte (111/udp,
111/tcp e 113/tcp).
Fabio

 attesa.
Cosa di riporta il comando 
# ipchains -L -v

 ciao.
Innanzitutto scusate se non ho piů risposto al thread ma in questi giorni
sono un'anima errante e non ho un portatile al mio fianco.
Il fatto č che ho adottato una politica chiusa (tutto proibito tranne quello
che dico io). Andando per esclusione, aprendo le porte una per una  a turno
(sperando che sia solo una) penso che morirei di vecchiaia (se non ho
alternativa perň...).
La mia domanda č nata dall fatto che non capivo perchč il download della
posta avesse bisogno di ulteriori porte oltre alle POP3 o IMAP ufficiali.
Appena rimetto le mani sul server proverň ad aprire le porte suggeritemi da
Fabio.
Grazie,
Oliviero

 Fabio.
Mi sono reso conto che nella descrizione dei possibili tentativi fatta nei
post precedenti forse mancava un po' di dettaglio e c'erano delle involontarie
imprecisioni.
Il traffico ident e sunrpc è buona norma bloccarlo in ingresso e in uscita, se
non serve: si può fare con REJECT o con DENY. Nel primo caso la richiesta
viene rigettata immediatamente e le operazioni proseguono mentre nel secondo
caso occorre attendere il timeout (penso che sia il tuo caso).
Come già accennato, l'apertura della porta (o l'uso di reject) possono essere
usati momentaneamente per cercare quel è la porta incriminata ma poi sarebbe
meglio riportare tutto alla policy DENY che avevi deciso inizialmente e
modificare la configurazione della macchina (es. nsswitch.conf per il problema
di NIS nel caso la porta sia la 111/udp).
Sappici dire.
Fabio

 Il fatto che si tratti di 30 secondi tondi tondi mi fa sorgere un
sospetto:
conosco solo iptables e non ipchains, cmq ti basta impostare un reject
invece di un deny sulla tua 113.
ciao
--
    /"\    ASCII RIBBON CAMPAIGN
    \ /      AGAINST HTML MAIL
     X      Ste  -- TVLUG - 
www.neko.it/tvlug
    / \     Linux User Registered #208536 at 
http://counter.li.org/

 di NIS nel caso la porta sia la 111/udp).
Sono riuscito a ricreare una situazione simile a quella originale su una
macchina di prova, effettivamente l'utilizzo del REJECT, o in alternativa
l'apertura della 111 e della 113, ha risolto i tempi di attesa. Per il
momento questo mi basta, spero però di capire prima o poi che tipo di
transazione venga bloccata dal firewall con queste porte chiuse.
Ciao e grazie,
Oliviero.