Newsgroup: it.comp.os.linux.software
Titolo: postfix, open relay.

Di default postfix non agisce come open relay.
Il parametro interessato per questo tipo di comportamento e' il valore
di default di smtpd_recipient_restrictions, che sarebbe uguale a
permit_mynetworks, check_relay_domains.
E' corretto?

 E' corretto?
E` un po` semplificato.
Genericamente parlando, sono coinvolte le "occorrenze" di mynetworks e
di relay_domains, all'interno della tua configurazione.
Cmq, ho visto modi molto _creativi_ di creare degli openrelay. :)
-- 
                          Maurizio - Tannoiser - Lemmo
                 Founder Member of ERLUG 
http://erlug.linux.it
-------------------------------------------------------------------------------
These opinions are my own, though for a small fee they be yours too.

 
postconf mynetworks
mynetworks = 
127.0.0.0/8
, 
172.16.10.1/32
postconf relay_domains
relay_domains = $mydestination
postconf mydestination
mydestination = $myhostname, localhost.$mydomain, $mydomain, localhost
mynetworks permette l'uso dell'smtp come mail relay solo ai client delle reti 
indicate?
Significa che se io configuro tale server come smtp e lo volessi usare
da un ip internet, quindi non indicato in mynetworks, l'accesso mi
verrebbe negato?
Eppure ho provato ad inviare posta collegandomi in telnet alla porta
25 da internet e, ora non ricordo bene, ma credo di essere riuscito a
inviare posta.
il parametro relay_domains in associazione con mydestination indica
quali sono i domini per cui tale server fa il relay direttamente?
In caso contrario contatta l'smtp del dominio relativo al rcpt to per
poter inviare la mail?
Forse ho le idee un po confuse. 

 poter inviare la mail?
Se il "client" che sta effettuando la richiesta e` nella lista di coloro
per cui e` ammesso il relay si.
Il server smtp quando invia mail, fa le seguenti operazioni:
- valuta mail for 
indi...@example.com
. (in coda, injection, altro
meccanismo)
- produce l'equivalente di host -t mx 
example.com
. (usiamo 
debian.org
  perche` produce output).
mizio@gate:~$ host -t mx 
debian.org
debian.org
 mail is handled by 0 
master.debian.org
.
debian.org
 mail is handled by 5 
gluck.debian.org
.
debian.org
 mail is handled by 10 
murphy.debian.org
.
- contatta 
master.debian.org
 (il primo per priorita`), dicendo "ho posta
  per te".
Il server smtp quando riceve mail, fa le seguenti operazioni (di base):
- ascolta sulla 25
- accetta le chiamate con mail from: $any
- valuta rcpt to: <indirizzo>
- se <indirizzo> e` nel suo dominio (o dominio per cui e` configurato
  per fare relay), la mail viene accettata diversamente viene rifiutata.
Eccezioni: quello che tu definisci in mynetwork (almeno localhost, visto
che tu invii la mail a 
indi...@example.com
 al _tuo_ smtp).
Questo a grandi linee. Ovviamente, e` possibile sovvertire questo
ordine, o condizionarlo intenzionalmente o non-intenzionalmente.
Consideriamo ora smtpd_recipient_restrictions. La chiave di tutto e` che
a differenza delle altre restrictions, questa ha come ultimo argomento
reject (non espresso).
quindi il suo default:
gate:~# postconf -d | grep smtpd_recipient_r
smtpd_recipient_restrictions = permit_mynetworks,check_relay_domains
dice:
valuta tutte le mail con _un_ campo rcpt to (quindi tutte), tranne:
permetti tutto al contentuto di $mynetworks
controlla relay_domains (che comprende mydestination).
Quindi rifiuta tutte le altre.(il default implicito)
Quindi, un errore in $mynetworks, o un permit alla fine di questa
restrictions ti trasforma in un open-relay.
Nota come le altre restriction hanno default a permit (da
documentazione).
Spero di aver fatto un po` di chiarezza.
-- 
                          Maurizio - Tannoiser - Lemmo
                 Founder Member of ERLUG 
http://erlug.linux.it
-------------------------------------------------------------------------------
Education is what remains after has forgotten everything he learned in school.


Chiarissimo come sempre :-)
Qui ritorniamo alla richiesta che avevo fatto tempo fa di verificare che
le mail inviate dall'interno della lan provengano dal nostro dominio.
Questo proprio per evitare che l'smtp venga usato come open relay
dall'interno.
Infatti se a mynetworks e' concesso tutto un utente potrebbe collegarsi
all'smtp e inviare una mail verso chiunque inserendo nel MAIL FROM un
indirizzo con dominio fasullo.
Ancora meglio sarebbe se potessi verificare la reale esistenza
dell'account interno prima che la mail possa essere inviata per impedire
che dall'interno partano mail con mittenti fittizzi.
Il mio smtpd_recipient_restrictions e':
check_sender_access hash:/etc/postfix/sender_checks,
reject_invalid_hostname,
reject_non_fqdn_sender,
reject_non_fqdn_recipient,
reject_unknown_sender_domain,
reject_unknown_recipient_domain,
reject_unauth_pipelining,
permit_mynetworks,
check_sender_access hash:/etc/postfix/disallow_my_domain,
reject_non_fqdn_hostname,
reject_unauth_destination,
reject_maps_rbl,
permit
maps_rbl_domains =
 
cbl.abuseat.org
,
 
opm.blitzed.org
,
 
list.dsbl.org
,
 
dnsbl.njabl.org
,
 
sbl.spamhaus.org
,
 
blackholes.easynet.nl
,
 
dynablock.easynet.nl
,
 
dul.dnsl.sorbs.net
,
 
korea.services.net
,
 
relays.ordb.org
Posso avere un tuo parere?
Grazie mille.

 Posso avere un tuo parere?
in quella table, che suppongo sia quella che definisce il tuo dominio,
puoi specificare anche ogni singolo indirizzo accettabile anziche` il
solo dominio, come dice man 5 access. Ovvio che se
sono molti e` lunga.
Nota pero` che come tutte le table, possono essere sostituite con table
piu` comode in taluni casi (ad esempio ldap o mysql, se hai gia` gli
utenti in uno di questi db).
-- 
                          Maurizio - Tannoiser - Lemmo
                 Founder Member of ERLUG 
http://erlug.linux.it
-------------------------------------------------------------------------------
Security-wise, NT is a server with a "Kick me" sign taped to it.

 utenti in uno di questi db).
Ottimo.
Quel check_sender_access hash:/etc/postfix/disallow_my_domain, e' per
impedire che possano essere spedite delle mail con sender facenti parte
del mio dominio se non dalla rete aziendale.
Quindi per esempio da internet non possono essere spedite mail con
sender ....@
miazienda.it
 se no autorizzati ad usare il mio smtp come
relay.
Per quanto riguarda gli account, li ho tutti su tabelle ldap, potrei
quindi fare un check su queste tabelle per assicurarmi che i mittenti
siano tutti account validi.
Hai notato pero' che nei parametri di smtpd_recipient_restriction non
ho check_relay_domains e alla fine ho un permit?
Il check_relay_domains non e' una delle direttive che serve ad evitare l'uso
come open relay del server?
come relay
 

 come open relay del server?
Oh, yeah.
mi posti l'output di
postconf | grep smtpd_recipient_re
-- 
                          Maurizio - Tannoiser - Lemmo
                 Founder Member of ERLUG 
http://erlug.linux.it
-------------------------------------------------------------------------------
Ever wondered why your keyboard has so many keys? Use Emacs Gnus!

 postconf | grep smtpd_recipient_re
Volentieri:
postconf |grep smtpd_recipient_re
smtpd_recipient_restrictions =


         permit
Il valore di questo permit, e` molto legato a quello di sender_checks.
Personalmente, sono in disaccordo a modificare la policy di
recipient_restrictions: pur se arrivato a quel punto _dovresti_ aver
filtrato tutti quelli che volevi filtrare, non puoi esserne certo.
E` il motivo per cui prima si concede e poi si blocca e non viceversa.
(anche nelle regole dei firewall, o in squid, per dirne un paio).


 filtrato tutti quelli che volevi filtrare, non puoi esserne certo.
Quindi tu lasci in smtpd_recipient_restrictions i valori di default
permit_my_networks e check_relay_domains?
Io ho messo tutto in smtpd_recipient_restrictions seguendo cio' che
viene detto nel documento Postfix Anti-UCE Cheat-Sheet, dove dice:
...
Lastly: You'll observe that all of my anti-UCE checks are under
    # smtpd_recipient_restrictions, instead of having a separate
    # smtpd_client_restrictions, etc.  This is because, unless you have
    # set smtpd_delay_reject = no (default is "yes"), no rejecting takes
    # place until after RCPT TO anyway.  It's easier, cleaner and more
    # predictable when all of the anti-UCE stuff is under recipient
    # restrictions.
Tieni conto per inciso che io uso postfix 1.1, la woody ha ancora questa
vecchia versione :-(
Ciao. 


 vecchia versione :-(
Anche io. Se non hai bisogno della ver 2, non e` "vecchia".
-- 
                          Maurizio - Tannoiser - Lemmo
                 Founder Member of ERLUG 
http://erlug.linux.it
-------------------------------------------------------------------------------
Sex is not the answer. Sex is the question. "Yes" is the answer.

 mi pare che dica di mettere un permit in fondo.
In fondo al smptd_recipient_restrictions mette un permit.
Quindi, per una questione di ordine, tu metti tutte le regole che devono
essere controllate per il mail from in smtpd_sender_restrictions e quelle
che devono essere controllate per il rcpt to in
smtpd_recipient_restrictions lasciando pero' in quest'ultimo anche il
check_relay_domains.
Mi pare piu' logico anche se tutte vengono comunque controllate dopo il rcpt to
come indicato nel documento citato.

 il rcpt to come indicato nel documento citato.
Non dice questo, la documentazione. Dice che, a meno di impostare
smtpd_delay_reject = no, verranno _applicate_ in sede di rcpt to. Ma a
me va bene. Vengono applicate in quel punto per recuperare piu`
informazioni (a chi era indirizzata la posta, anche se listi il client),
quindi per scopi statistico/debuggosi.
-- 
                          Maurizio - Tannoiser - Lemmo
                 Founder Member of ERLUG 
http://erlug.linux.it
-------------------------------------------------------------------------------
A good system can't have a weak command language.

 Sono pazzi. Mi riprometto di controllare.
Hai potuto verificare?

Un piccolo dubbio.
Le regole agiscono su ogni singola sezione?
Mi spiego: se metto reject_maps_rbl in smtpd_recipient_restrictions mi
vengono rifiutate le mail in cui nel rcpt to l'host risulta nella lista
dei cattivi.
Ma se tale host e' nel mail from e nel rcpt to risulta un host valido la
mail viene accettata a meno che non metta reject_maps_rbl anche in
smtpd_sender_restrictions.
E' cosi'?
Per maggiore sicurezza, paranoica, quindi alcune regole sarebbe bene
duplicarle pe fare in modo, riferendomi all'esempio citato, che nessun
host contenuto nelle liste in reject_maps_rbl possa riuscire a mandare
mail.
Ciao e grazie come sempre per la disponibilita'.   

 E' cosi'?
Si. In postfix 2, e` cambiato. Ed e` piu` chiaro. Pero` inevitabilemte
ti obbliga a sapere le varie rbl che tipo di risultato danno (liste che
elencano ip, liste che elencano indirizzi...).
-- 
                          Maurizio - Tannoiser - Lemmo
                 Founder Member of ERLUG 
http://erlug.linux.it
-------------------------------------------------------------------------------
Life would be so much easier if we could just look at the source code.

 E` troppo facile fare un errore.
Il contenuto di quel file e':
# Postfix doesn't relay by default.  But it may *appear* to do so
# to some testers.  The first two statements below remove all
# doubt.
/^\@/		550 Invalid address format.
/[!%\@].*\@/	550 This server disallows weird address syntax.
/^postmaster\@/	OK
/^hostmaster\@/	OK
/^abuse\@/	OK
E' solo un ulteriore controllo per evitare relay indesidserati.
Tra le altre cose ho notato che se aggiungo check_relay_domains tra le
tante direttive che avevo indicato in smtpd_recipient_restrictions,
alcune di queste non vengono piu' prese in considerazione.
Ancora le cose non mi sono molto chiare.
Ciao.  

 Ancora le cose non mi sono molto chiare.
Considera che il documento mi pare dica espressamente che non si tratta
di una configurazione completa.
I quel file devi perforza aggiungere altro, se no, non passa nulla
(tranne postamaster, hostmaster, e abuse @qualasiasi cosa... che si
potrebbe discutere).
Se guardi all'inizio, nella configurazione "per punti" dice al punto 4:
"Out-right reject anything from outside that's not destined for my
network."
Questo deve avvenire perforza in quel file, stante la configurazione (e
il permit finale).
La mia opinione e`: prendilo come spunto. E` una configurazione
(inutilmente?) complicata, con un approccio deny-open che di norma, e`
contro l'approccio classico (open-deny).
Poi, ovviamente, puo` funzionare, stando molto attenti. Mi chiedo se ne
vale la pena. (e mi rispondo: no).
-- 
                          Maurizio - Tannoiser - Lemmo
                 Founder Member of ERLUG 
http://erlug.linux.it
-------------------------------------------------------------------------------
If your computer speaks English, it was probably made in Japan.

 il permit finale).
Si riferisce a quel reject_unauth_destination che evita di essere usato
come open relay.

 come open relay.
Vero. Non avevo visto questo reject. Valutare una configurazione cosi`
complessa senza testarla, non e` proprio banale.
Che ti devo dire, continua a non piacermi, non rientra nei requisiti di
KISS. E quando fai fatica ad immaginare la tua struttra, il piu` facile
che ti possa capitare, e` fare degli errori e non accorgersene.
Personalmente, non vedo benefici in questa struttura, rispetto ad una
piu` lineare, salvo essere meno leggibile (e infatti sto thread dura da
un pezzo), e meno semplice, senza nessun _apparente_ vantaggio.
Poi, "if work, don't fix it", ma non e` il modo in cui mi piace
lavorare.
-- 
                          Maurizio - Tannoiser - Lemmo
                 Founder Member of ERLUG 
http://erlug.linux.it
-------------------------------------------------------------------------------
Did you know that "Gullible" is not in the dictionary?