locked
Tentativo di accesso o falso allarme? RRS feed

  • Domanda

  • Ho un cliente il cui server (SBS2003) registra centinaia di accessi con un utente esistente ma con password sbagliata.
    Il cliente ha da poco configurato un tablet ed uno smartphone per l'accesso alla posta, e uno di questi dispositivi non si connette pertanto la lunga lista di tentativi falliti potrebbe essere dovuta a questo, ma vorrei esserne certo.

    Questo è uno degli eventi che viene registrato:

    529,AUDIT FAILURE,Security,Wed Mar 06 22:27:16 2013,NT AUTHORITY\SYSTEM,Accesso non riuscito:     Motivo:  Nome utente sconosciuto o password non valida     Nome utente: [UTENTE]     Dominio:  [dominio.local]     Tipo di accesso: 8     Processo di accesso: Advapi       Pacchetto di autenticazione: Negotiate     Nome workstation: [NOMESERVER]     Nome utente chiamante: [NOMESERVER$]     Dominio chiamante: [DOMINIO}     ID accesso chiamante: (0x0,0x3E7)     ID processo chiamante: 1668     Servizi transitati: -     Indirizzo di rete origine: 123.123.123.123     Porta origine: 60096

    Ci sono alcuni fattori che mi fanno pensare che il problema sia dovuto effettivamente ai loro apparati mobili:
    Tutti gli IP del dominio di origine che appaiono (non è sempre lo stesso) sono di Telecom che, effettivamente, è il gestore che usano per gli apparati mobili;
    A quanto vedo il tipo di accesso (8) indica un tentativo di accesso dalla rete (più precisamente "Testo non crittografato in rete") e non, per esempio di tipo 10 che indica un tentativo dall'esterno tramite terminal o desktop remoto;
    I tentativi sono troppo poco frequenti (uno ogni 5 minuti) per essere dei tentativi di brute force sulla password.

    Voi che dite?

    giovedì 7 marzo 2013 00:04

Risposte

  • Ciao. Si, il logon type 8 indica un tentativo di accesso con credenziali in chiaro.

    Spesso questo evento viene registrato nei tentativi di login tramite IIS e basic authentication (aggiungo che può essere molto pericoloso se la sessione non è protetta con SSL), quindi potrebbe trattarsi di un problema dei dispositivi solo se viene utilizzato questo metodo di autenticazione per Exchange. In qualsiasi caso a mio parere è il caso di eseguire qualche verifica in più, ma se il nome utente corrisponde a quello di un particolare utente (e non si tratta di admin, administrator, ecc...) può essere valida la tesi di una password errata memorizzata in un dispositivo. Se hai IIS/Exchange pubblicato all'esterno la cosa andrebbe verificata ancora più attentamente in quanto il rischio di un attacco (magari intercettando password trasmesse in chiaro) è molto più elevato. A questo proposito andrebbe riverificato anche se la sicurezza offerta dai metodi di autenticazione scelti è adeguata al contesto.




    venerdì 8 marzo 2013 23:51
    Moderatore

Tutte le risposte

  • Ciao. Si, il logon type 8 indica un tentativo di accesso con credenziali in chiaro.

    Spesso questo evento viene registrato nei tentativi di login tramite IIS e basic authentication (aggiungo che può essere molto pericoloso se la sessione non è protetta con SSL), quindi potrebbe trattarsi di un problema dei dispositivi solo se viene utilizzato questo metodo di autenticazione per Exchange. In qualsiasi caso a mio parere è il caso di eseguire qualche verifica in più, ma se il nome utente corrisponde a quello di un particolare utente (e non si tratta di admin, administrator, ecc...) può essere valida la tesi di una password errata memorizzata in un dispositivo. Se hai IIS/Exchange pubblicato all'esterno la cosa andrebbe verificata ancora più attentamente in quanto il rischio di un attacco (magari intercettando password trasmesse in chiaro) è molto più elevato. A questo proposito andrebbe riverificato anche se la sicurezza offerta dai metodi di autenticazione scelti è adeguata al contesto.




    venerdì 8 marzo 2013 23:51
    Moderatore
  • Sono sicuro che il dispositivo del cliente (uno smartphone con Android 4.0) usi SSL per la connessione ad Exchange ma non mi pare si possa specificare anche il tipo di autenticazione (come si fa, per esempio, per la connessione RPC over HTTP di outlook).
    sabato 9 marzo 2013 20:13
  • L'indirizzo di rete riportato nell'evento è esterno alla tua rete? L'accesso da parte di questi dispositivi avviene attraverso internet?

    domenica 10 marzo 2013 13:42
    Moderatore
  • Il 10/03/2013, Fabrizio Giammarini ha detto :

    L'indirizzo di rete riportato nell'evento è esterno alla tua rete? L'accesso da parte di questi dispositivi avviene attraverso internet?

    Si, l'IP di origine è esterno (come dicevo, sempre reti Telecom). Gli apparati si collegano direttamente da internet (non viene stabilita una VPN prima, se è questo che intendi) richiamando l'IP pubblico direttamente dall'applicazione di posta.

    domenica 10 marzo 2013 23:58
  • lunedì 11 marzo 2013 09:18
    Moderatore
  • Fabrizio Giammarini ha detto questo lunedì :

    Però l'indirizzo 123.123.123.123 credo sia sospetto.....
    http://blog.threatstop.com/2011/04/12/latest-adobe-zeroday-call-home-blocked-by-threatstop/

    Per forza... l'ho inventato. :-)
    Gli IP originali sono tutti nei seguenti range: 217.x.y.z (rete TIM) e 80.x.y.z (rete ADSL Telecom)

    lunedì 11 marzo 2013 10:02
  • Per forza... l'ho inventato. :-)
    Gli IP originali sono tutti nei seguenti range: 217.x.y.z (rete TIM) e 80.x.y.z (rete ADSL Telecom)

    Ah, ok....la prossima volta però usa direttamente x.x.x.x almeno è più evidente che hai "oscurato" l'IP.... :-)

    Comunque l'ipotesi di un errore di autenticazione da parte di questi dispositivi mi sembra valida, esegui un controllo incrociato tra il dispositivo, il nome utente rilevato e l'indirizzo IP in modo da poter escludere problemi di sicurezza.


    lunedì 11 marzo 2013 12:53
    Moderatore
  • Fabrizio Giammarini ha pensato forte :

    Ah, ok....la prossima volta però usa direttamente x.x.x.x almeno è più evidente........

    Chiudo il thread.
    Era effettivamente l'apparato mobile del cliente a generare quelle registrazioni.
    Una volta sistemati i parametri, è tornato tutto a posto

    venerdì 15 marzo 2013 15:05