LogMeIn Security Whitepaper

Assiomi dell’accesso remoto

Tutto è un bersaglio di attacco

Sempre più computer sono online 24 ore su 24, 7 giorni su 7. Gran parte di tali computer appartengono a utenti domestici e presentano falle nella protezione quali vulnerabilità non corrette e la mancanza di password adeguate.

La debolezza maggiore, tuttavia, è l'utente stesso. L'estrema rapidità di diffusione dei virus che si propagano per e-mail è indice della mancanza di consapevolezza dei problemi legati alla sicurezza e della natura ingenua della maggior parte degli utenti di Internet. I virus diffusi per e-mail sono gli allegati alle e-mail meglio noti come Trojan, o cavalli di Troia. Si diffondono tanto rapidamente per l'estrema leggerezza con cui gli utenti dimenticano di osservare le regole principali della gestione dei contenuti non affidabili. Se gli utenti stessi sono responsabili dell'infezione dei propri computer da parte dei trojan, difficilmente saranno in grado di proteggere efficacemente i loro sistemi dagli attacchi diretti.

Persino amministratori di rete esperti possono scordare di installare una o due patch che, nelle situazioni peggiori, consentono all'aggressore di eseguire un codice arbitrario sui sistemi infettati.

Gli attacchi informatici non sono una novità, ma di recente si sono verificati significativi cambiamenti relativi a chi sia in grado di sferrarli. Quella che un tempo era un'attività illecita ristretta a pochi soggetti altamente qualificati, competenti e ben connessi si è oggi trasformata in qualcosa che è praticamente alla portata di chiunque, soprattutto grazie ai kit automatizzati pronti per l'uso che consentono di sfruttare senza sforzo migliaia di vulnerabilità note.

Accesso remoto e sicurezza

È facile constatare che molti computer connessi a Internet sono estremamente vulnerabili, anche senza l'installazione di un prodotto per l'accesso remoto. I prodotti per l'accesso remoto vengono percepiti come fattori ad alto rischio, ma principalmente per motivi psicologici. Quando un utente vede per la prima volta una soluzione di accesso remoto in azione, la prima reazione è di solito negativa per questioni legate alla protezione. È perfettamente normale, ed è anzi auspicabile che sia così. Il vero problema è che gli utenti non si rendono conto delle minacce derivanti da altre applicazioni abilitate per la rete, come i client e-mail, i server Web o il sistema operativo stesso.

Tutti i sistemi operativi moderni includono per impostazione predefinita qualche tipo di soluzione di accesso remoto. In Windows, ad esempio, è integrato Remote Desktop di Microsoft, che funge da semplice interfaccia di amministrazione remota. Persino OpenBSD, la variante Unix considerata generalmente il sistema operativo più sicuro disponibile, include SSH, un'applicazione semplice e sicura che consente l'accesso dalla riga di comando su una connessione di rete al computer remoto.

In sostanza, una soluzione di accesso remoto ben selezionata e configurato riduce il numero di eventi di sicurezza a livello minimo. If a network manager can keep a network secure using a reliable remote access software package, such as LogMeIn Pro and LogMeIn Central, productivity can be increased and costs may be reduced without any adverse effects on network security.

Architettura software

Before explaining the exact security mechanisms employed by LogMeIn Pro and LogMeIn Central, it is necessary to give a quick introduction to the solution architecture.

In ogni sessione di accesso remoto intervengono tre componenti principali. I ruoli del client e l'host dovrebbero essere semplici, ovvero il terzo componente è il gateway.

Architettura di sistema

The host maintains a constant TLS-secured connection with one of the LogMeIn Pro and LogMeIn Central gateway servers in one of our physically secure datacenters. Questo collegamento viene avviato da parte dall'host e i firewall lo riconoscono come connessione in uscita, come traffico di navigazione Web protetto. The client establishes a connection to LogMeIn Pro or LogMeIn Central and authenticates itself. In base all'identità del client, questo viene autorizzato a scambiare dati con uno o più host (che appartengono all'account dell'utente). Il gateway inoltra quindi il successivo traffico crittografato tra il client e l'host. È bene notare che il anche il client deve effettuare l'autenticazione all'host; il gateway media il traffico tra le due entità, ma non richiede che l'host consideri implicitamente attendibile il client. Una volta che l'host ha verificato l'identità del client e l'ha autorizzato ad accedere al computer, ha inizio l'effettiva sessione di accesso remoto.

Il vantaggio di utilizzare il gateway è che una o entrambe queste entità, client e host, possono essere protette da firewall. Il gateway garantisce che gli utenti non devono configurare i firewall.

Meccanismi di sicurezza

Quando gli utenti pensano alla protezione dei dati su Internet, di solito fanno riferimento alla crittografia dei dati stessi, al punto che la protezione viene misurata in base alla lunghezza della chiave di crittografia utilizzata. Crittografia e decrittografia tuttavia, pur essendo molto importanti, sono attività abbastanza banali rispetto alle altre difficoltà a cui devono far fronte i progettisti dei sistemi protetti. As you will see, data encryption is just one of the main goals set forth by the designers of LogMeIn Pro and LogMeIn Central.

Autenticazione del Gateway al Client

First and foremost, when a user connects to a LogMeIn Pro or LogMeIn Central installation via a gateway – the “server” – they need to be 100% positive that the computer they are about to exchange data with is really the one to which they intended to connect.

Supponiamo che un aggressore si spacci per il server con l'utente e si spacci per l'utente con il server. In questo caso, l'aggressore può frapporsi tra le due parti durante la lettura o la modifica dei dati in transito. Questa situazione è conosciuta come attacco MITM, o dell'uomo in mezzo (Man In The Middle), e la difesa da questo tipo di attacco è particolarmente difficile.

I nostri prodotti utilizzano TLS 1.2 e 1.3 autenticazione basata sul certificato per verificare le identità del server e quindi proteggere dagli attacchi MITM. Quando viene avviata una connessione, viene verificato il certificato del server. Se il certificato risulta emesso da un’autorità di certificazione non affidabile, viene visualizzato un avviso. Se il nome host nell'URL non corrisponde con il nome host incluso nel certificato, viene visualizzato un altro messaggio di avviso.

Se il server supera queste verifiche, il client dell'utente genera un "Pre-Master Secret" o PMS, lo crittografa con la chiave pubblica del server contenuta nel certificato e lo invia al server. Grazie alla crittografia a chiave pubblica, solo il server che detiene la chiave privata corrispondente può decifrare il PMS. Il PMS viene poi utilizzato per consentire all'utente e al server di ottenere il Master Secret, che a sua volta verrà a sua volta utilizzato per ottenere i vettori di inizializzazione e le chiavi di sessione per la durata della sessione protetta.

In breve, queste precauzioni garantiscono che l'utente stabilisca la connessione con il server e non con un'entità terza. In caso di tentativo di attacco MITM, o viene generato uno degli avvisi di protezione, oppure il PMS non viene riconosciuto dal MITM, rendendo in tal modo l'attacco impossibile.

One2Many – Autenticazione e crittografia

La funzionalità One2Many consente agli utenti avanzati di eseguire script e di applicazioni di distribuzione, che consentono ai nostri utenti di eseguire funzioni di massa in tutte le organizzazioni. With this tool, users can execute, manage, and monitor administrative tasks on multiple Windows and Mac computers directly from LogMeIn Central.

Per garantire una sicurezza e una sicurezza ad alto livello, è obbligatorio l'utilizzo di 2FA per One2Many. One2Many memorizza le credenziali in due modi diversi quando esegui un'attività in tempo reale, memorizza le credenziali nel browser. Quando l'esecuzione dell'operazione è in corso, le credenziali vengono memorizzate nel database del prodotto.

Le credenziali utilizzate in One2Many vengono crittografate per prima cosa con la chiave pubblica dell'host, che viene ulteriormente crittografata dal sito web. La prima è necessaria, pertanto solo l'host con la sua chiave privata può decrittografare, e la secondo ne garantisce l'opzione per la rimozione dei dati. With this method, credentials can be wiped from the website (LogMeIn Central) even if the host is offline. L'aspetto principale di questo è che solo l'host può decrittografare le credenziali.

Autenticazione degli utenti al Gateway

Gli utenti devono essere autenticati sia da gateway che da host. An email address and password verification is performed whenever a user logs on to the LogMeIn website. Users are also advised to enable one or more of LogMeIn’s extra security features to strengthen this authentication step.

Note: LogMeIn Central subscribers can enforce a strong password policy. Visit support.goto.com for details.

Autenticazione tra gli utenti e il gateway

9.2.1 Codici di sicurezza Stampa

Una funzione di protezione aggiuntiva è rappresentata dai codici di protezione stampati. Quando l'utente attiva questa funzione, gli viene richiesto di stampare un elenco di password di 9 caratteri casuali generate dal gateway. Ogni volta che un utente accede al proprio account al www.LogMeIn.com, agli utenti viene chiesto di inserire uno dei codici di sicurezza nell’elenco per poter accedere al loro account. Ogni codice può essere utilizzato una sola volta. Prima che l'utente abbia utilizzato tutti i codici di sicurezza stampati, gli viene richiesto di stamparne un altro foglio. Dopo questa operazione, i codici di sicurezza stampati in precedenza non saranno più validi.

Ecco come attivare i codici di sicurezza stampati:

Login to your LogMeIn account.
Fai clic Impostazioni > Sicurezza.
Seleziona il Codice di sicurezza Stampa opzione.
Generare e stampare un elenco di codici di protezione.
Fai clic su Salva.

9.2.2 Codici di sicurezza inviati tramite e-mail

Another way to secure your LogMeIn account is to use the Emailed Security Code feature. Ad ogni accesso al proprio account in LogMeIn.com, si riceverà un'e-mail contenente un codice di protezione, che dovrà essere immesso nel apposito campo per poter accedere all'account. Ogni codice può essere utilizzato una sola volta.

When this feature is turned on and the user authenticates successfully with their email address and password to the LogMeIn gateway, a pass code is generated and sent to the email address. Alla ricezione del messaggio con il passcode, l'utente deve immettere il codice nel modulo fornito dal gateway. Il passcode scade in seguito all’uso o entro alcuni minuti dalla sua generazione, a seconda dell’evento che si verifica per primo.

Ecco come abilitare i codici di sicurezza tramite e-mail:

Login to your LogMeIn account.
Fai clic Impostazioni > Sicurezza.
Nella scheda Protezione aggiuntiva, selezionare l'opzione Codice di protezione inviato per e-mail.
Immettere l'indirizzo e-mail nell'apposito campo.
Fai clic su Salva.

9.2.3 Audit dell'Account

Keep track of activity in your LogMeIn account. Selezionare gli eventi dei quali si desidera ricevere una notifica automatica per e-mail, come ad esempio i tentativi di accesso non riusciti o le modifiche delle password. Le notifiche verranno inviate agli indirizzi e-mail specificati (per più destinatari, separa gli indirizzi e-mail con un punto e virgola). Alcuni eventi dell'account sono attivati per impostazione predefinita e non possono essere disattivati.

Ecco come attivare la funzionalità di audit dell'account (notifiche e-mail):

Login to your LogMeIn account.
Fai clic Impostazioni > Impostazioni dell'account.
In Notifiche e-mail, fai clic su modifica e seleziona gli eventi per i quali desideri ricevere notifica tramite e-mail automatica.
Tip: Puoi anche modificare l'elenco dei destinatari.
Fai clic su Salva.

LogMeIn Central subscribers (account holders) can audit additional items at Settings > Security > Audit Settings:

Modifiche delle impostazioni di protezione
Eventi relativi agli utenti (utenti invitati, inviti accettati o eliminati, eventi di accesso)
Eventi relativi ai computer (aggiunte, eliminazioni, generazione/invalidazione di collegamenti, generazione di pacchetti di installazione)

9.2.4 Verifica in due passaggi (autenticazione a due fattori, 2FA)

La verifica in due passaggi aggiunge una protezione aggiuntiva al tuo account. Come un ATM che protegge il tuo denaro richiedendo una tessera magnetica e il PIN. Senza la verifica in due passaggi, chiunque conosca la tua password può accedere ai tuoi dati. Una volta impostata la verifica in due passaggi, il tuo passaggio sarà modificato: dopo aver inserito l'ID LogMeIn e la password, ti sarà richiesto di verificare la tua identità.

LogMeIn Central subscribers can enforce a login policy that forces all users in their account to use two-step verification. For step-by-step instructions, visit support.goto.com.

Autenticazione della Gateway all'Host

Il gateway deve dimostrare la propria identità all'host prima di ottenere i codici di accesso. The host, when making a connection to the gateway, checks the certificate transported during the TLS handshake to make sure it is connecting to one of the LogMeIn gateway servers. Questo processo è molto simile a quello “Autenticazione del Gateway al Client”.

Autenticazione dell'host al gateway

Quando accetta una connessione in entrata, il gateway verifica l'identità dell'host utilizzando una lunga stringa di identificazione univoca, che è un segreto condiviso tra le due entità ed è generata dal gateway quando viene installato l'host. L'identificatore univoco viene comunicato su un canale protetto da TLS solo dopo che l'host ha verificato l'identità del gateway. La Figura 3 illustra come l'host e il gateway si autenticano a vicenda prima che il client possa accedere all'host. Per garantire maggiore sicurezza, l'host può modificare il segreto condiviso con una richiesta dall 'gateway tramite la connessione sicura.

Autenticazione dell'host e del gateway

Crittografia dati

I standard TLS definiscono una vasta gamma di suite di crittografia, in genere basate su crittografia basate su AES per motivi di compatibilità. AES può invece utilizzare chiavi a 128 o 256 bit. Il client e il server accettano il ruolo più forte possibile. Il client invia al server un elenco di crittografie che è pronto a usare, e il server sceglie quello che si riferisce.

La standard TLS non definirà il modo in cui il server deve scegliere il frazionatore finale. Nel caso, il server seleziona semplicemente la chiave condivisa più forte che il cliente ha offerto.

Questo metodo permette sia al client che al server di rifiutare l'uso di specifici algoritmi di protezione dei dati senza la necessità di aggiornare entrambi i componenti, nel caso in cui un algoritmo sia ritenuto non sicuro.

Rilevamento delle intrusioni

LogMeIn Pro and LogMeIn Central provide two layers to detect intrusion attempts: TLS and LogMeIn Intrusion Filters.

TLS

For the first layer of intrusion detection, LogMeIn utilizes TLS 1.2 and 1.3 certificate based authentication to ensure that the data has not changed in transit. Questo avviene mediante le seguenti tecniche:

Numerazione della sequenza dei record: Tramite la numerazione della sequenza dei record, i record TLS vengono numerati dal mittente e il loro ordine viene verificato dal ricevente. Di conseguenza, un aggressore non può rimuovere o inserire dei record arbitrari nel flusso dei dati.
Codici di autenticazione dei messaggi: Ad ogni record TLS vengono allegati dei codici di autenticazione dei messaggi (MAC, Message Authentication Codes). Tali codici derivano dalla chiave della sessione (nota solo alle due parti comunicanti) e dai dati contenuti nel record. Se la verifica dei MAC non riesce, allora significa che i dati sono stati modificati durante il transito.

LogMeIn Intrusion Filters

The second layer is provided by LogMeIn itself, and is comprised of three intrusion filters.

Filtro indirizzi IP

When LogMeIn receives a connection request from a client, it first checks its list of trusted and untrusted IP addresses and possibly denies the connection. An administrator can set up a list of IP addresses within LogMeIn that are either allowed or denied to establish a connection to the selected host (for example, designate the internal network and another administrator’s home IP address as allowed). IP Address filters can be set under Security > IP Filtering. You can also set filter profiles for the network adapters available on the Server under Preferences > Network.

Rifiuto del filtro del servizio

Il filtro degli attacchi Denial of Service respinge la connessione se l'indirizzo IP da cui sta partendo la richiesta ha effettuato un numero eccessivo di richieste senza autenticazione nel periodo di osservazione. Questo impedisce che qualcuno possa sovraccaricare il computer host richiedendo ad esempio automaticamente e molto rapidamente la pagina di accesso in continuazione. Puoi personalizzare il comportamento del filtro DoS in Sicurezza > Blocco indirizzi IP.

Filtro di autenticazione

Se l'utente effettua un numero eccessivo di tentativi di accesso non riusciti, il filtro di autenticazione respinge la connessione. Il filtro di autenticazione serve per evitare che un potenziale intruso riesca a indovinare il nome e la password dell'account.

Here's how to set filters on a LogMeIn host:

Accedi alle preferenze host dall'host o dal client:
- Se sei all'organizzatore, apri il Pannello di controllo di LogMeIn e segui questo percorso: Opzioni > Preferenze > Sicurezza
- Se sei al client, connettiti all'host Menu principale e segui questo percorso: Preferenze > Sicurezza
Nell'applicazione desktop, alla voce Controllo delle intrusioni, clicca su Modifica profili per iniziare a creare un profilo di filtro.
On the LogMeIn Central website, select Host Preferences, then click IP Address lockout category. For details, see the LogMeIn Pro or the LogMeIn Central support site.

Autenticazione e autorizzazione degli utenti all'Host

Dopo aver superato i precedenti livelli, l'utente deve dimostrare la propria identità all'host. Questo avviene attraverso una fase di autenticazione obbligatoria a livello di sistema operativo.

L'utente deve autenticarsi all'host utilizzando il nome utente e la password standard di Windows o Mac. L'host solitamente inoltre questa richiesta al relativo controller di dominio. Questa fase non solo consente l'autenticazione dell'identità dell'utente, ma garantisce anche che gli amministratori di rete possano controllare chi può accedere a un dato host.

Password personale

Personal Password is another optional security measure that can be set up on the LogMeIn host. L'utente può assegnare all'host una Password personale che, come la password a livello di sistema operativo, non viene memorizzata né verificata dal gateway. Una differenza tra la password a livello di sistema operativo e la Password personale è che l'host non chiede mai la Password Personale completa, per cui l'utente non la immette mai per intero in una singola sessione di autenticazione. L'host solitamente richiede all'utente tre cifre casuali di questa Password personale dopo l'autenticazione a livello di sistema operativo. Se l'utente immette le cifre corrette (ad esempio la prima, la quarta e la settima), gli viene consentito l'accesso.

Ecco come configurare una Password personale:

Accedi alle preferenze host dall'host o dal client:
- - Se sei all'organizzatore, apri il Pannello di controllo di LogMeIn e segui questo percorso: Opzioni > Preferenze > Sicurezza
  - Se sei al client, connettiti all'host Menu principale e segui questo percorso: Preferenze > Sicurezza
- Sotto Password personale, immettere una password personale, quindi immetterla nuovamente per confermarla.
- Fai clic Applica.

GoTo and RSA SecurID

To add an extra layer of security over the simple username/password authentication, you can configure LogMeIn to require RSA SecurID authentication. RemotelyAnywhere, the product that pioneered the technology in use by LogMeIn, was officially certified by RSA Security as SecureID Ready in 2003. A quel punto, GoTo has continuare a mantenere il livello di sicurezza elevato in modo coerente con la tecnologia RSA.

Per informazioni sul prodotto RSA SecurID, visita la Sito web di RSA. For information on setting up this feature on a LogMeIn host, visit https://support.logmeininc.com/pro.

Autenticazione tra gli utenti e l'host

Autenticazione e autorizzazione degli utenti all’interno dell’Host

Once LogMeIn has verified the user’s identity using the above methods, it checks its own internal user database to see which internal modules the user is allowed to access.

System administrators can configure LogMeIn so that users with certain roles have access only to a subset of tools offered by LogMeIn; for example, the Helpdesk department can be configured to only view a computer’s screen and performance data, but not actually take over the mouse and the keyboard or make any changes to the system configuration. All'ufficio vendite ad esempio potrebbe venire dato pieno accesso al controllo remoto dei rispettivi computer, rendendo però non disponibili funzioni quali il monitoraggio delle prestazioni e l'amministrazione remota.

Using the operating system access token obtained when the user was authenticated, LogMeIn impersonates the user towards the operating system while performing actions on their behalf. This ensures that LogMeIn adheres to the operating system's security model, and users have access to the same files and network resources as if they were sitting in front of their computer. Resources unavailable to users in Windows or OS X also remain unavailable via LogMeIn.

See “Controlling Who Can Access Your Host Computers” in the LogMeIn Pro or LogMeIn Central support site.

Audit e registrazione

LogMeIn provides extensive logging capabilities. A very detailed log of the events that occur within the software is kept in the LogMeIn data log directory. Nel registro eventi delle applicazioni di Windows vengono inseriti anche gli eventi più importanti, quali ad esempio le operazioni di accesso e disconnessione. Il registro dettagliato può essere inviato anche a un server Sysllog personalizzato della scelta del cliente.

See “How to View Host Event Log Files” in the LogMeIn Pro support site for details. For SYSLOG, see “Deployable Host Preferences for Logs and Session Recording” in the LogMeIn Central support site.

Inoltro dei dati

Il gateway fornisce una crittografia end-to-end inoltrando i dati crittografati tra l'host e il client. Se hai dimestichezza con il funzionamento di TLS, questo può sembrare impossibile; del resto, seguendo la logica, dal momento in cui il client è sicuro di comunicare con il gateway, solo il gateway può decrittografare i dati inviati dal client. This is a valid point, but LogMeIn made a few important changes to how TLS sessions are handled between the host and the gateway.

La prima parte della negoziazione TLS avviene tra il gateway e il client. Il gateway inoltra quindi lo scambio all'host, che rinegozia la sessione TLS e concorda con il client una nuova chiave di sessione, fornendo di conseguenza una reale crittografia end-to-end.

Quando il traffico viene inoltrato attraverso il gateway, il client stabilisce una sessione TLS con il gateway usando il certificato del gateway. Il gateway trasferisce all’host lo stato di tale sessione TLS (incluso il Pre-Master Secret). Dopo aver concordato una nuova chiave di sessione, l’host usa questo stato della sessione per gestire il resto della sessione TLS direttamente con il client. Il certificato del gateway protegge la sessione, lasciando che il client comunichi direttamente con l’host, senza la necessità che il gateway decrittografi e ricrittografi il traffico.

Un attacco di tipo "man in the middle" viene reso impossibile per il fatto che sia l’host che il client verificano il certificato del gateway, e che il client utilizza la propria chiave pubblica RSA per autenticare le informazioni crittografate utilizzate per generare il Pre-Master Secret TLS.

UDP NAT Traversal

È importante spiegare in che modo venga utilizzato UDP NAT Traversal, soprattutto dal momento che UDP viene generalmente considerato non sicuro. Questo non è completamente un errore: se UDP viene utilizzato come mezzo di comunicazione, allora la sicurezza può essere un problema molto importante, poiché i dati degli UDP sono semplici da forgiare e l'indirizzo IP del mittente può essere disattivato.

Per contrastare questa situazione, con le connessioni UDP NAT Traversal, LogMeIn.com non utilizza l'UDP come mezzo di comunicazione. Come stabilito dal modello di rete ISO/OSI, l'UDP è relegato al livello di rete con un livello di trasporto di tipo TCP costruito al di sopra di esso, completo di controllo di flusso, scalabilità dinamica della banda larga e numerazione della sequenza dei pacchetti.

LogMeIn.com uses UDP instead of TCP packets (thereby effectively re-implementing a TCP-like transport layer) because most firewalls and NAT devices allow seamless two-way communication over a UDP transport as long as it is initiated from within the security perimeter, but they require significant reconfiguration for TCP and IP packets. Dopo che un flusso affidabile di tipo TCP viene costruito a partire da pacchetti UDP non affidabili, il flusso viene ulteriormente protetto da un livello TLS che fornisce crittografia totale, protezione dell'integrità e possibilità di verifica della connessione.

Per impostare una connessione UDP NAT Traversal, il client e l'host inviano diversi pacchetti UDP crittografati al gateway. Questi pacchetti sono crittografati utilizzando una chiave segreta condivisa dal gateway e dal rispettivo peer, e vengono comunicati su una connessione TLS preesistente, per cui è impossibile falsificarli.

Il gateway utilizza questi pacchetti per determinare gli indirizzi IP esterni (Internet) delle due entità e prova anche a prevedere quale porta del firewall verrà utilizzata per la comunicazione al momento dell'invio di un nuovo pacchetto UDP. Trasmette quanto scoperto ai peer che tenteranno poi di impostare una connessione diretta. Se il gateway determina la posta usata, la connessione riesce. I peer si verificano a vicenda usando un'altra chiave segreta condivisa ottenuta dal gateway. Viene stabilita una sessione TLS e i peer comunicano direttamente.

Se è impossibile impostare una connessione diretta, i peer si riconnettono al gateway su TCP e richiedono che venga utilizzata una sessione inoltrata e crittografata end-to-end. L'intero processo dura solo pochi secondi e non è percepibile dall'utente. Le uniche differenze percepibili, durante l'uso di una connessione diretta, sono il miglioramento delle prestazioni e il basso livello di latenza. Per maggiori informazioni vedi US Rescue no. 7.558.862.

Aggiornamenti software e sicurezza del gateway

The LogMeIn host, based on user preferences, can semi-automatically or automatically update itself on the user’s computer. Il software host verifica periodicamente sul sito Web LogMeIn.com la disponibilità di nuove versioni del software. Se viene trovata una nuova versione, questa viene scaricata automaticamente e viene visualizzato un messaggio che richiede all'utente di consentire l'aggiornamento. Il processo di download utilizza al massimo il 50% della larghezza di banda disponibile, limitando quindi al minimo le interferenze con altre applicazioni di rete.

Questi aggiornamenti software sono firmati digitalmente da LogMeIn.com con una chiave privata che non si trova in nessuno dei nostri sistemi connessi a Internet. Therefore, even if the LogMeIn datacenters were compromised by attackers who then gain complete control over our servers, they would not be able to upload a rogue update and run arbitrary code on our users’ computers. The most such a highly unlikely attack could accomplish is access to the LogMeIn logon screen on the customer’s computer, which, even though it effectively bypasses the gateway security mechanisms, would still require that they enter valid operating system credentials to gain access to the computer. I metodi drastici di forzatura delle password non sono fattibili, poiché il filtro di autenticazione, per impostazione predefinita, l'indirizzo IP dell'utente dopo poche volte che viene immessa una password sbagliata.

For cases when a user has the same password for both LogMeIn and their computer, note that we do not store actual LogMeIn passwords in our database. Utilizziamo invece una funzione di derivazione di una chiave crittografica a senso unico e un valore di salt diverso per ogni account, per assicurare che non sia possibile attaccare la password con il metodo forza bruta, anche se in possesso del valore derivato.

Conclusione

Una soluzione di accesso remoto ben progettata può aumentare notevolmente la produttività e assicurare un rapido ritorno sull'investimento. When deployed with care and LogMeIn's optional security features are utilized, the benefits greatly outweigh the risks.

Pubblico

Terminologia

Fondamenti di design