Newsgroup: it.comp.sicurezza.varie
Titolo: AUTH

Sono in lotta con il ns. provider di connettivita' e posta aziendale a
Genova perche' ci rifiuta il traffico SMTP se non ci serviamo della ADSL
dell'ufficio; a me che controllino solo l'IP sta un po' sui marroni
Ho chiesto che implementino l'AUTH e mi hanno scaricato una valangata di
problemi, tra cui difficolta' d'implementazione specialmente in
riferimento agli altri server (?) e sicurezza nel controllo
dell'autenticazione stessa (ecco il rif. al ng ;))
Possibile che sia cosi' difficile ed insicuro? Pensavo fosse pratica
normale per qualunque provider :(
Accetto consigli
... e buona giornata

 normale per qualunque provider :(
E' insicuro quando le password passano in chiaro.
Fabio
[1] in realta' puoi usare solo l'AUTH supportata dal tuo client. Se usi
    autluc senza SSL/TLS, ad esempio, hai solo LOGIN, che fa passare in
    chiaro le password.

 normale per qualunque provider :(
Beh da quanto ci ho capito  io non hanno tutti i torti. AUTH viene usato
come "cortesia" nei confronti di server remoti relativi a servizi che non
prevedano autenticazione o informazioni sull'utente che ha iniziato la
connessione. Per esempio se uno si collega ad un server IRC (o smtp) puo'
essere che il server IRC remoto faccia una richiesta di call-back al
server del servizio auth locale (solitamente l'identd) per sapere, in
sostanza, chi e' che ha iniziato la connessione. Tutto cio' va bene se il
server remoto e' affidabile.  In generale pero' il server remoto puo'
essere chichessia e quindi usare il tuo servizio auth per avere liste di
usernames, dato che, nella sua implementazione piu' primitiva l'identd
 va a vedersi gli username in /etc/passwd.
Alternativamente auth puo' anche essere utilizzato per avere una lista dei
"possessori" di processi server remoti (l'opzione -I di nmap mi pare serva
a questo), o, detto in parole povere, dal punto di vista del posibile
intruso, per vedere se ci sono malconfigurazioni di server.  Insomma puo'
essere un buon strumento per raccogliere informazioni.
Oviamente esistono implementazioni di auth che risolvono il problema
rispndendo alle richieste di call back con  username falsi ma
probabilmente questo da' luogo a quelle complicazioni di cui ti parlavano.
Di piu' non so,
stammi bene,
b.

 servizi smtp alternativi.
a pagamento?
-- 
HappyCactus - Registered Linux User #209744
http://www.angelfire.com/jazz/happycactus/index.html
Made with 100% recycled electrons

 dell'autenticazione stessa (ecco il rif. al ng ;))
Il riferimento agli "altri server" probabilmente e' relativo a quelli 
"interni" alla loro rete, probabilmente si riferiscono alla difficolta' 
di sincronizzare gli account POP con quelli di autenticazione SMTP 
(immagino...)
La sicurezza sul controllo dell'auth. potrebbe essere un problema se si 
utilizza una autenticazione in chiaro; ma qui esistono diverse soluzioni. 
In sostanza credo che il provider non voglia implementarla per motivi 
tecnici ed economici, e avrebbe tutto il diritto di farsi pagare 
eventuali oneri.
La soluzione e' quella di utilizzare un servizio alternativo: ne esistono 
diversi a pagamento e gratuiti.
Una piccola nota a margine: l'utilizzo degli Open Relay "a sbafo", come 
consigliatoti da qualcuno di moooolto ben informato (ROFL) ti portera', 
al di la' delle considerazioni etiche (utilizzi risorse non tue, di cui 
non hai - in teoria - autorizzazione), un mucchio di problemi, tra cui il 
filtraggio da parte di molti provider (il mio, ad esempio). Quindi ti 
consiglio di evitarlo.


 
HappyCactus si è limitato a dare un utile consiglio tecnico (utilizzare 
open relay può non essere affidabile perchè molti server filtrano 
automaticamente tutti i messaggi che arrivano da un open relay).
Consigliare a qualcuno di non andare a impegolarsi in una soluzione che 
può comportare problemi sia tecnici che, in questo caso, magari 
addirittura legali, mi sembra un itervento utile e costruttivo 
soprattutto considerando che tu gli avevi appena consigliato di usare 
un open relay ("tanto ce ne sono in giro un sacco") senza avvisarlo 
delle possibili conseguenze.
-- 
Valter Minute
vmi...@inwind.it
 (the reply address of this message is invalid)

 La persona in questione non mi sembrava sprovveduta
ringrazio una bugia e' pur sempre piu' piacevole della fredda verita' ;)
Comunque, no Carlo quello che voglio e' una situazione ufficiale niente
open, ma neppure installazioni in casa che complicherebbero la vita a
tutti.
Per le responsabilita' la legge cosa dice? Se mi rubano la password e
spammano non sono comunque io il responsabile?
E sottolineo che non parlo di Tin con decine di migliaia di utenti
privati, ma siamo un swhouse che compra (e paga) un'adsl ed un servizio
di posta da un provider (poligono di 6 facce uguali & parte iniziale del
termine communication) che dovrebbe avere un occhio a queste
situazioni... possibile che dobbiamo mandare in giro email che arrivano
dai peggio freeaccount?
grazie mille per la reattivita', le alte fiamme rendono attenti piu'
attenti al ng???? ;)
Paolo

 tutti.
Hai un ip fisso? in tal caso potresti mettere in piedi un relay 
autenticato, magari su tunnel ssl. Tu da casa di autentichi sul tuo 
server di posta e di li' invii tutte le mail utilizzando il gateway del 
provider, quello che non fa relay.
Un po' come fa whip a rendere invisibile il suo IP <g>


 arrivano dai peggio freeaccount?
Una cosa e' il server da dove arriva la posta, un'altra sono i vari
campi dell'header che contengono gli indirizzi del mittente. Per te
e' piu' importante cio' che il destinatario vede nel campo Received
by, messo dell'MTA, o quello che vede in From o Reply to e che puoi
modificare a piacere? Forse la soluzione e' piu' semplice di quanto
possa sembrare.
Fabio

 by, messo dell'MTA, o quello che vede in From o Reply to e che puoi
c'e' del vero...
ma al momento sfrutto i commerciali del provider come momento distensivo
;)