Newsgroup: it.comp.os.linux.sys
Titolo: sicurezza rete ed ettercap

Spero di non essere OT, nel qual caso vi prego di indirizzarmi al NG
appropriato :-)
Mi è venuta una paranoia.
Nella rete aziendale abbiamo un server Debian con Samba.
Ogni utente legge la posta direttamente dal ISP con Thunderbird e le
password in chiaro (POP3).
E' possibile che una persona collegata fisicamente alla LAN aziendale
riesca tramite una macchina linux ed il programma ettercap a sniffare le
password di posta e del server Samba, e magari anche di accesso al
server in SSH o FTP ?
Che sistemi dovrebbe adottare l'azienda per evitare questo rischio ?
O magari non si può fare nulla perchè ettercap è troppo potente (ma in
questo caso nessuna rete può essere definita sicura.
TIA

 Che sistemi dovrebbe adottare l'azienda per evitare questo rischio ?
Bisogna sviluppare una politica di sicurezza, è una questione un pò 
complessa da spiegare e multidisciplinare - oltre che OT.
Un modo molto banale e incompleto di risolvere il tuo problema potrebbe 
essere quello di usare solo protocolli sicuri e togliere tutti i servizi 
vulnerabili a questo tipo di attacchi.

 
Certamente, per ovviare al problema dovresti utilizzare pop3-ssl e sftp
quando possibile.
Per quanto riguarda l'accesso ssh le password non passano in chiaro nella
LAN quindi dovresti stare relativamente sicuro.
 Giovanni
-- 
/*
 * SnB - Qualità Informatica - 
http://www.snb.it
 */

 ssh è impossibile
Mica vero.
-- 
Words are very unnecessary
They can only do harm

 questo caso nessuna rete può essere definita sicura.
Prima di tutto obbligare gli utenti ad usare IMAP anziche` POP3.
I server SSH ed anche samba di solito usano password criptare.  Ma hai 
ragione, nessuna rete puo` essere sicura se qualcuno si da` veramente 
da fare per bucarla, ma non e` cosa alla portata del normale utente.
Ciao
Giovanni
-- 
   A computer is like an air conditioner,
   it stops working when you open Windows.
   Registered Linux user #337974  < 
http://giovanni.homelinux.net/
 >

 Mica vero.
Immagino che tu voglia estremizzare il discorso, in questo caso hai 
ragione (cioè se domani compro un computer quantico da 007 o uso 
bluegene di nascosto è probabile che riesca a forzare ssh).

 Che sistemi dovrebbe adottare l'azienda per evitare questo rischio ?
Utilizzare il più possibile la versione sicura (SSL o TLS) dei vari
protocolli.
Istruire adeguatamente i propri utenti (ettercap consente attacchi
man-in-the-middle con i quali può inserirsi anche in sessioni protette da
SSL/TLS, fornendo certificati "falsi").
Utilizzare alcune feature di sicurezza degli switch (su Cisco, ad esempio,
port security, dhcp snooping, dynamic arp inspection e ip source guard)
Però non siamo esattamente IT...


 bluegene di nascosto è probabile che riesca a forzare ssh).
Non intendo questo.
Faccio arp spoofing, faccio credere al tuo client che il server supporta
solo ssh1 e poi faccio man-in-the-middle cambiando la key rsa che il server
ti invia.
Un utente esperto si allarma, certo, uno meno scaltro, magari...


 Un utente esperto si allarma, certo, uno meno scaltro, magari...
Uno meno scaltro avrà a disposizione un client ssh pre-configurato da me 
in modo da poter stabilire solo connessioni con ssh2 senza possibilità 
di cambiare nulla (tantomeno le chiavi in uso).

 di cambiare nulla (tantomeno le chiavi in uso).
Il che è cosa buona e giusta, in effetti, ma ritengo sempre meglio
ricorrere a soluzioni user-proof.


 qui, a meno di grosse cagate nella configurazione, è impossibile
Ok, se non puoi downgradare il ivello dell'autenticazione non vedi
direttamente la password, ma se questa e' stata scelta male non ci
vuole molto a recuperarla dal challenge response ntlm (o dall'hash
preauth kerberos).
Fabio

 Prima di tutto obbligare gli utenti ad usare IMAP anziche` POP3.
????????????????????????????????
-- 
A: Because we read from top to bottom, left to right.
Q: Why should i start my reply below the quoted text?

 
Hai mai sentito parlare dei protocolli IMAP e POP?
Mentre con POP la password e` in chiaro con IMAP hai varie 
possibilita` di criptarla anche se nell'esempio che segue e` previsto 
solo AUTH=CRAM-MD5
6.3.4 querying 
mail.home.net.it
 (protocol IMAP) at Tue Mar 13 18:06:27 
2007: poll started
IMAP< * OK [CAPABILITY IMAP4REV1 LITERAL+ SASL-IR LOGIN-REFERRALS 
STARTTLS AUTH=CRAM-MD5
IMAP> A0001 CAPABILITY
IMAP< * CAPABILITY IMAP4REV1 LITERAL+ IDLE NAMESPACE MAILBOX-REFERRALS 
BINARY UNSELECT SC
IMAP< A0001 OK CAPABILITY completed
IMAP> A0002 STARTTLS
IMAP< A0002 NO STARTTLS failed: Server certificate not installed
IMAP> A0003 CAPABILITY
IMAP< * CAPABILITY IMAP4REV1 LITERAL+ IDLE NAMESPACE MAILBOX-REFERRALS 
BINARY UNSELECT SC
IMAP< A0003 OK CAPABILITY completed
IMAP> A0004 AUTHENTICATE CRAM-MD5
IMAP< + PDI1NjM1LjExNzM4MDU1ODdAbWlsZW5hLmhvbWUubmV0Lml0Pg==
IMAP> Z3Vlc3QgNzdlN2VmMjU3MDIyOTEyYjE4NTkyZmEyODNjMDgxMWI=
IMAP< A0004 OK [CAPABILITY IMAP4REV1 LITERAL+ IDLE NAMESPACE 
MAILBOX-REFERRALS BINARY UNS
IMAP> A0005 SELECT "INBOX"
IMAP< * 1 EXISTS
IMAP< * 0 RECENT
IMAP< * OK [UIDVALIDITY 1138439497] UID validity status
IMAP< * OK [UIDNEXT 6] Predicted next UID
IMAP< * FLAGS (\Answered \Flagged \Deleted \Draft \Seen)
IMAP< * OK [PERMANENTFLAGS (\* \Answered \Flagged \Deleted \Draft 
\Seen)] Permanent flags
IMAP< A0005 OK [READ-WRITE] SELECT completed
IMAP> A0006 SEARCH UNSEEN NOT DELETED
IMAP< * SEARCH
IMAP< A0006 OK SEARCH completed
1 message (1 seen) for guest at 
mail.home.net.it
.
skipping message 
gu...@milena.home.net.it:1
 not flushed
IMAP> A0007 LOGOUT
IMAP< * BYE 
milena.home.net.it
 IMAP4rev1 server terminating connection
IMAP< A0007 OK LOGOUT completed


 di criptarla anche se nell'esempio che segue e` previsto solo AUTH=CRAM-MD5
Ehm...
Il meccanismo che dici è definito anche per POP3 da 15 anni, con le
stesse modalità di IMAP...
Vedi RFC1734.
- --
Skull & Bones (ER6n Silver)
Neo:  I know Sendmail!
Morpheus:  Show me.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (Darwin)
iD8DBQFF95308THo01J+SBERAtfBAKCIpbPtVnOvUNIJ34V4t7ZD2O2LpQCePCjn
Mw7ZcldjVmgWYzBemItZ69I=
=WOW/
-----END PGP SIGNATURE-----

 solo AUTH=CRAM-MD5
Perchè, con pop3 no?


 
Saro` io sfigato, ma non ho ancora trovato un provider che lo supporti.


 Perchè, con pop3 no?
Effettivamente non con i più vecchi: il protocollo "originale" prevedeva
solamente plain-text, e se vai a vedere RFC1939 le uniche autenticazioni
disponibili sono plain-text e APOP, ma si fa menzione dei meccanismi
aggiuntivi disponibili se il server POP implementa anche RFC1734.
Quindi, strettamente parlando, l'obiezione ha un suo fondamento "formale".
C'è da dire che AFAIK qualsiasi server POP3 "serio" tuttora mantenuto
supporta RFC1734...
Piuttosto c'è da fare un altro appunto, che però vale uguale sia per POP
che per IMAP: i meccanismi CRAM -AFAIK- richiedono che il server
mantenga il database delle password *in chiaro*.
Il che, oltre a porre un evidente problema in caso di accesso non
autorizzato al DB di autenticazione, ne limita pesantemente il campo di
applicabilità...
- --
Skull & Bones (ER6n Silver)
Neo:  I know Sendmail!
Morpheus:  Show me.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (Darwin)
iD8DBQFF98VA8THo01J+SBERAtcDAJ4mX88OXQzWiUEGiNJ7NGYq4s/AbQCeLOf6
shRhQWUkxLc1zk4q8Gelj5w=
=obfI
-----END PGP SIGNATURE-----

 Saro` io sfigato, ma non ho ancora trovato un provider che lo supporti.
Sì, ma ci sono delle ragioni.
Vedi sotto la risposta a Whip, e nota come le stesse ragioni che
limitano l'utilizzo di CRAM su POP valgono tali e quali anche per IMAP...
- --
Skull & Bones (ER6n Silver)
Neo:  I know Sendmail!
Morpheus:  Show me.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (Darwin)
iD8DBQFF98W78THo01J+SBERAiPfAJ97QwMkmPqs3yR2fv88szN+21v9UACgkjnU
dyJYRBp4XBtbxhyU2NlVb8o=
=+H7B
-----END PGP SIGNATURE-----

 supporta RFC1734...
Appunto, nowadays...
BTW, io sono un fan di STARTTLS ovunque. :-)


 BTW, io sono un fan di STARTTLS ovunque. :-)
Con l'aria che tira sugli algoritmi di hashing, poi... :-\
- --
Skull & Bones (ER6n Silver)
Neo:  I know Sendmail!
Morpheus:  Show me.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (Darwin)
iD8DBQFF998B8THo01J+SBERAkMRAKDBGOGpGd+b1yZvhWubuticknyE+QCgnYkO
f0/oYruq78XUABrO5zAcAAI=
=9c/0
-----END PGP SIGNATURE-----

 Saro` io sfigato, ma non ho ancora trovato un provider che lo supporti.
- Poste.IT ... IMAPS + CRAM-MD5 ("Autenticazione Cifrata" di Thunderbird)
- Email.IT  CRAM-MD5   a *VOLTE* ...
    non ho ben capito perché ma *A*VOLTE* le CAPABILITY  con AUTH=....
    non viene inviato :| (quindi TB rompe i maroni sulla sua mancanza)
     :(
comincio a chiedermi se sappiano configurare (decentemente) i 
server/servizi ....