Business continuity assicurata e ripartenza immediata in caso di disastro

Datto Utilities – Configurazione manuale, via CLI, dei parametri di rete

FS20200804

Ultimo aggiornamento: 04 August 2020

Utilizzo attivo della CLI in Live OS presente in Datto Utilities

N/A

Prerequisiti

  1. Presenza di una subnet e conoscenza dei parametri di rete associati a Gateway e Server DNS

    N.B.
    Per l’esempio sottostante (punto 5 di successiva sezione) si prenderà in considerazione la seguente configurazione di rete:
    Subnet: 192.168.0.0/24
    Gateway 192.168.0.1
    dns-nameservers 192.168.0.1 8.8.8.8


  2. Datto Device già presente e configurato con i corretti parametri di rete.

  3. Datto Utilities già scaricate da portale: https://downloads.datto.com

    N.B.
    Risulta possibile masterizzare la ISO delle Datto Utilities su un DVD oppure montare le Datto Utilities su chiave USB attraverso l’uso di appositi tools (es: Rufus –> https://rufus.ie )

  4. Avere a disposizione una macchina di destinazione dotata di possibilità di Boot via USB o via unità ottica.

Procedura

  1. Avviare il boot delle Datto Utilities. Una qualsiasi delle voci presenti in elenco andrà bene.

    N.B.
    Qualora occorresse si potrà premere su tasto funzione “F1” per selezionare il proprio tipo di layout di tastiera preferito (la predefinita à la US ma risulta possibile selezionare la IT).

  2. Una volta caricata l’interfaccia grafica premere su “Ctrl + Alt + F5” per passare alla CLI.

  3. Eseguire la login usando i seguenti dati:

    User ID: root
    Password: datto


  4. Inserire il seguente comando per accedere al file di configurazione:

    sudo nano /etc/network/interfaces

  5. Editare il file inserendo i dati necessari.

    Esempio:
    auto eth0
    iface eth0 inet static
    address 192.168.0.16
    netmask 255.255.255.0
    gateway 192.168.0.1
    dns-nameservers 192.168.0.1 8.8.8.8

  6. Premere “Ctrl + x” per chiudere. Confermare con tasto “Y” per salvare.

  7. Inserire i seguenti due comandi per eseguire un flush dell’IP precedentemente associato alla scheda di rete e riavviare la sezione networking:

    sudo ip addr flush eth0
    sudo systemctl restart networking.service

  8. Inserire il seguente comando per verificare che la modifica sia stata effettivamente eseguita:

    ip add

  9. Premere su “Ctrl + Alt + F7” per tornare all’interfaccia grafica “web-gui”.

  10. Proseguire nell’opera di manutenzione standard (BMR o Rapid Rollback) via canonica “web-gui” (anche da browser di differente PC presente in medesima subnet).

La soluzione completa per affrontare le complessità del mondo IT

Gestire profili duplicati in Kaseya Cloud Backup

FB20200731

Ultimo aggiornamento: 31 July 2020

Gestire profili lockati sul portale Acronis

In determinati casi (ad esempio se si interrompe la comunicazione verso il cloud Acronis durante un’operazione di cancellazione iniziata da VSA), possiamo trovare sul portale Acronis macchine con profili duplicati o disallineati rispetto a VSA.

Questi profili appaiono di norma con un lucchetto che sta a significare che il profilo è lockato e immodificabile perché impostato via API o da un account con diritti più elevati di quello in uso.

E’ possibile però gestire i profili in modo completo con un workaround: è sufficiente loggarsi direttamente a cloud.acronis.com con le credenziali usate per connettere VSA al cloud Acronis.

Una volta loggati:

– selezionare il cliente dalla lista;
– cliccare su Manage Services;

– nel tab Device, identificare la macchina che ha i profili duplicati e cliccare sull’ingranaggio in alto a dx: https://www.screencast.com/t/0PKCkDxkuNGq
– cliccare su Protect.

Saranno visibili tutti i profili assegnati e si potrà gestirli completamente o cancellarli.

La soluzione facile e flessibile per gestire le reti da remoto

Come reimpostare l’autenticazione a due fattori (2FA) di un utente Datto?

LB20200730

Ultimo aggiornamento: 30 July 2020

Cosa fare se l'autenticazione a due fattori (2FA) di un utente non funziona più?

Possono verificarsi i seguenti casi:

1. Esiste un altro utente con il ruolo Security Admin.

2. Non esiste un altro utente con il ruolo Security Admin.

Esiste un altro utente con il ruolo Security Admin

Per reimpostare la 2FA per un collega, procedere in questo modo:

1. Accedere al portale di Datto con un utente che ha il ruolo di Security Admin.

2. Entrati nel portale di Datto, fare clic sulla scheda Admin e poi selezionare Manage Employees dal menu a discesa.

3. Nella tabella Manage Employees, fai clic sull’icona a forma di matita nella colonna all’estrema destra per aprire la finestra di dialogo Edit Employee.

4. Fare clic sul link Email TOTP, nella parte inferiore della finestra di dialogo per inviare al dipendente un codice di accesso singolo che può utilizzare per accedere. Dopo aver effettuato l’accesso con il codice, il sistema richiederà al dipendente di reimpostare le proprie credenziali di accesso. Il sistema chiederà inoltre loro di riconfigurare la propria 2FA prima dell’accesso.

Si visualizza un messaggio di conferma se il messaggio viene inviato correttamente.

Non esiste un altro utente con il ruolo Security Admin

Se l’utente a cui non funziona più la 2FA era l’unico utente con il ruolo di Security Admin, occorre procedere in questo modo:

1. Recuperare i seguenti dati:

a. username dell’account da “resettare”;

b. nome dell’azienda registrata nel portale Datto;

c. numero di cellulare dell’account da “resettare”.

2. Aprire una richiesta (in inglese) al supporto di Datto fornendo i dati del punto precedente. I riferimenti del supporto Datto per l’Europa sono:

email: support@datto.com

tel. +44.(0).118.402.9609

Ripristino istantaneo dei dati colpiti da ransomware o attacco 0-day, senza firme, senza backup e senza aggiornamento

Cosa succede quando avviene un Commit

AC2020072902

Ultimo aggiornamento: 29 July 2020

NeuShield: Dettagli sul funzionamento del Commit automatico e manuale

La tecnologia Mirror Shielding di NeuShield fa in modo che le modifiche avvenute all’interno di una cartella protetta (creazione file, modifica file, cancellazione file) vengano scritte temporaneamente su un overlay virtuale. Questo livello, evitando che i dati vengano scritti direttamente su disco, permette di ripristinare (Revert) ad una situazione precedente dati che per errore o per dolo sono stati modificati, come nel caso del ransomware.

La scrittura da overlay a disco avviene tramite Commit. Questo può essere automatico o manuale, e le due modalità si differenziano per alcuni aspetti.

COMMIT AUTOMATICO

E’ configurabile da console NeuShield, tab Data Setinel Settings > File Protection and Data Engram Settings > Overlay Commit Interval. Qui posso specificare ogni quante ore verrà effettuata la scrittura su disco dall’agente, scegliendo tra un minimo di 4 ore e un massimo di 96. La scelta è del tutto soggettiva. Un numero di ore più basso, in caso di Revert, permetterà di tornare ad una situazione più recente e di conseguenza implicherà una perdita di lavoro svolto minore, ma ci dà una quantità di tempo più breve per effettuare il Revert in caso di necessità. Al contrario un numero di ore più alto costituisce una perdita di lavoro svolto più elevata, ma ci dà più margine per effettuare il Revert.

Il Commit automatico scrive su disco tutte le modifche avvenute dal commit precedente (file creati, modificati e cancellati)

COMMIT MANUALE

E’ possibile eseguirlo in qualunque momento da PC, è sufficiente cliccare col tasto destro del mouse su una cartella protetta, tab NeuShiel > Commit changes.

L’operazione va a scrivere su disco i file modificati e creati presenti su overlay, ma non i file cancellati. Per scelta del vendor la cancellazione di un file viene applicata da overlay a disco solo tramite Commit automatico.

PRECISAZIONI SULL’ORARIO DI COMMIT IN FASE DI REVERT DI UNA CARTELLA

Nonostante si abbiano queste due modalità, l’orario di ultimo Commit con cui viene taggata una cartella è sempre quello avvenuto in modo automatico. Se infatti provate a effettuare Revert per una cartella protetta (click col tasto destro del mouse, tab NeuShiel > Revert changes) apparirà un messaggio del genere:

Anche se sulla stessa cartella avete dato un Commit manuale pochi minuti prima, il popup vi informerà che “x file sono stati modificati dall’ultimo Commit automatico”.

Questa è una scelta del vendor che ha ritenuto complessa e fuorviante una gestione delle date di Commit disomogenea. Un caso classico è quello del Revert su una cartella padre contenente a sua volta diverse cartelle per le quali sono stati fatti Commit manuali in diversi momenti.

Nell dettaglio disponibile sulla finestra (more details) è comunque indicata per ciascun file l’ora esatta della modifica.

Backup di Office 365 e delle applicazioni cloud

Quante licenze sto pagando?

AC2020072901

Ultimo aggiornamento: 29 July 2020

Controllare le licenze attive su Datto SaaS Protection

Da portale Datto SaaS, tab Seat Management > Users, è possibile tramite il tasto Download scaricare un report csv col dettaglio delle licenze utilizzate.

Il rapporto elenca tutti gli indirizzi e-mail licenziati e riconosciuti da Datto SaaS. Oltre a questo indicherà anche quali licenze vengono addebitate come SharePoint Seat. E’ indicata inoltre, per ciascuna riga, lo stato attuale. Nell’esempio riportato in immagine vengono fatturate 10 mailbox + 1 SharePoint Seat.

LICENSED_SEAT_STATUS: questo campo potrà essere valorizzato come Active o Archived:

  • Active: Datto SaaS eseguirà backup per quell’utente.
  • Archived: l’utente occupa una licenza in Datto SaaS, ma non vengono eseguiti più nuovi backup. Gli utenti Archived occupano licenza in quanto Datto mantiene i dati precedentemente sottoposti a backup fino al momento in cui sono stati disattivati. Un esempio può essere una mailbox eliminata da O365 ma che necessita conservazione dei dati fino a quel momento presenti.

LICENSED_SEAT_NAME: gli indirizzi email degli utenti con licenza.

LICENSE_OCCUPIED_BY_SHAREPOINT: questo campo indica se SharePoint Seat sta occupando la licenza oppure no.

QUALI ENTITA’ OCCUPANO UNA LICENZA (BILLABLE SEAT)?

In linea generale Datto SaaS occupa licenza per le stesse entità che occupano licenza in O365/G Suite. In pratica tutti gli user account che su portale Datto SaaS si presentano in uno di questi stati:

  • Active
  • Paused
  • Archived

Per ulteriori informazioni su questi stati, visitare il seguente articolo Datto

QUALI ENTITA’ NON OCCUPANO UNA LICENZA (NON-BILLABLE SEAT)?

  • Unprotected User
  • Shared and Resource Mailboxes
  • SharePoint Sites
  • Team Sites
  • Share Drive

—————————————————————————————————————————————————

Una visualizzazione rapida degli elementi protetti da backup è disponibile da Partner Portal > SaaS Protection Status. Qui solo la riga User indica entità che occupano licenza.

Visualizza gli articoli originali qui e qui.

Business continuity assicurata e ripartenza immediata in caso di disastro

Se fallisce il pairing delle VM guest in modalità agent-less

AC20200728

Ultimo aggiornamento: 28 July 2020

Correggere possibili problemi di pair tra Datto device e host VMware

Potrebbe capitare, configurando i backup Datto in modalità agent-less, che il pairing dell’host VMware vada a buon fine, mentre il pairing delle VM guest dia un errore del genere:

L’errore è dovuto a una impostazione di default presente su un file di configurazione del device Datto riguardante la risoluzione dei nomi dominio (DNS). L’errore in fase di pairing è dato da un fallimento nella risoluzione stessa la quale viene interrotta prematuramente e si verifica spesso quando il dominio termina in .local

Non è possibile mettere mano al sistema operativo del device, in questi casi quindi si consiglia di segnalare al supporto Datto tramite ticket specificando l’errore ricevuto. La loro risoluzione sarà poi breve.

La soluzione completa per affrontare le complessità del mondo IT

Ricreare i pacchetti del Kaseya Software Management

FB20200728

Ultimo aggiornamento: 28 July 2020

Le scansione per il patching generano errore

9.5

NOTA: eseguire questa procedura solo se istruiti in tal senso dal supporto Achab.

La procedura di seguito riportata è utile a ripristinare la corretta corrispondenza di file necessari alla gestione degli aggiornamenti del Kaseya Software Management.

L’operazione scarica molti file verso il server Kaseya (più di 40000), quindi il consiglio è iniziare l’operazione e verificare il giorno dopo che la scansione delle patch termini correttamente.

1. Sul server Kaseya, eseguire una shell dei comandi, posizionarsi sulla cartella \Kaseya\EndpointDownloads ed eseguire i seguenti comandi:

del package-SM.zip del Windows_x86.zip
del *.ospx
del *.pls
del *.plp

2. Collegarsi quindi a SQL Server ed eseguire le seguenti query sul db Ksubscribers (i blocchi possono essere copiati così come sono in quanto le righe di testo puro sono commentate per SQL Server):

-- per rimuovere i riferimenti ai file cancellati sopra:
DELETE FROM sm.OspxFile;
DELETE FROM sm.StoredFileData;
DELETE FROM sm.PatchZipFiles;
DELETE FROM sm.SoftwareDeploymentProfileTitles;
DELETE FROM sm.ProductVersion;
DELETE FROM sm.Product;
DELETE FROM sm.Vendor;
DELETE FROM sm.UnappliedPatch;
-- per cancellare i pacchetti:
DELETE FROM endpoint.DownloadableFile WHERE name LIKE '%.pls' OR name LIKE '%.plp' OR name LIKE '%.ospx' OR name LIKE '%package-sm%';
DELETE FROM Endpoint.DownloadableFile WHERE id IN (SELECT downloadable_file_id FROM Endpoint.Package WHERE name LIKE '%sm%');
DELETE FROM Endpoint.Package WHERE name LIKE '%sm%';
-- per ricreare i pacchetti:
EXEC sm.spCreatePackage;
-- per resettare i contatori
UPDATE [SM].[Defaults] SET Value = 0 WHERE PartitionId = 0 AND RelatedObjectId = 16;
-- per eseguire l'importazione dei titoli software
EXEC hermes.AddRunNowRunOnceEvent
@EventDescription='SM Run Once',
@EventEndpointName='SM.Kaseya.SM.Common.ImportTitlesFromServiceEndpoint';

La seguente query può poi essere eseguita per verificare che il processo sia partito. Si può anche controllare che il numero di file presenti nella cartella \Kaseya\EndpointDownloads cresca in modo continuo.

-- per verificare che il processo sia partito correttamente:
select top 200 * from Logging.Syslog
where LogName = 'SMLogs.Main'
and DateCreated > dateAdd(hh, -4, getDate())
order by DateCreated desc

Il modo più semplice e veloce per distribuire applicazioni Windows su qualsiasi device, senza agenti, senza setup, senza VPN

Cameyo NoVPN

FS20200728

Ultimo aggiornamento: 28 July 2020

NoVPN - Servizio di Remote Web browsing ottimizzato per il lavoro remoto

N/A

NoVPN – Servizio di Remote Web browsing ottimizzato per il lavoro remoto

Panoramica del servizio

La soluzione NoVPN di Cameyo nasce per distribuire a tutti i dipendenti, senza necessità di dover accedere via connessioni VPN, delle Web App normalmente disponibili solamente via intranet aziendale.

Differenze tra VPN e Cameyo NoVPN

Configurazione di Cameyo NoVPN

  • Se non è ancora stato creato un server Cameyo occorrerà attivarne uno attraverso l’utilizzo del seguente wizard:
    online.cameyo.com/servers/add
  • Si raccomanda di lasciare attive le configurazioni di default per il server, in special modo le opzioni relative a “Temporary user profiles”.
  • Il server ospiterà il Web browser che verrà utilizzato dai tele-lavoratori. Per questo motivo il Cameyo server dovrà avere pieno accesso alla intranet aziendale che conterrà le Web App.
  • Una volta che il server Cameyo risulterà attivo e configurato occorrerà utilizzare il seguente hyperlink:
    online.cameyo.com/novpn-setup.
    Tale azione creerà automaticamente in elenco l’applicazione “NoVPN”.

N.B.
Qualora NoVPN risultasse già presente in elenco “Apps”, il processo di creazione verrà semplicemente rediretto verso la pagina di utilizzo del servizio NoVPN.

Al termine del processo l’applicativo NoVPN risulterà configurato e utilizzabile come una qualsiasi altra applicazione Cameyo:

N.B.
Una volta che i test del caso saranno terminati, prima di portare il tutto in PROD, assicurarsi si aver configurato l’accesso al server Cameyo in modalità HTTPS, integrando un apposito certificato utile ad assicurare comunicazioni sicure e criptate.

Utilizzo

Gli utenti potranno avviare sessioni NoVPN attraverso l’icona preposta presente in proprio elenco “Apps” oppure attraverso il link: online.cameyo.com/novpn.
In entrambi i casi si troveranno di fronte una pagina iniziale simile a quella rappresentata in immagine sottostante:

Inserire l’URL interessato, come ad esempio quello che punta ad una specifica Web App e premere il tasto invio.
NoVPN eseguirà browsing all’interno della intranet aziendale e presenterà ai richiedenti ciò che normalmente la Web App presenta solo localmente o via connessione VPN.

Barra di navigazione

La barra di navigazione sottostante permette agli utenti di eseguire tutte le opere di browsing tra vari siti:

  • Pulsanti “Indietro” (<) e “Avanti” (>) : Spostamenti tra pagine.
  • Pulsante “Home”: Apertura della pagina iniziale.
  • Pulsante “Switch”: Spegne o accende la visione “fullscreen” del browser web (inclusi i vari tab e la canonica barra indirizzi).

Personalizzare la pagina iniziale

La pagina iniziale, sviluppata in formato HTML e pienamente personalizzabile, risulta essere presente all’interno del seguente percorso del server Cameyo:
“C:\RemoteAppPilot\NoVpnPage”

Ulteriori informazioni

NoVPN, di default, è configurata per l’uso di Chrome.
Risulta in ogni caso possibile modificare il Browser predefinito eseguendo editing dei contenuti della command-line associata all’applicativo (NoVPN in lista “Apps”).

N.B.
Per Cameyo la dicitura “novpn” in command-line (caratteri minuscoli) sta ad indicare: “Avvio di Chrome”.

Al termine di ogni sessione NoVPN il profilo dell’utente viene completamente rimosso.
Tutti i dati associati al Browser Web, quali cookies e history, vengono comunque preservati a parte.
Gli stessi verranno ripristinati automaticamente se il medesimo utente Cameyo riavvierà una sessione via NoVPN.

Dove si trovano i dati:

  • Con Session Sync attivo i dati si trovano in propria sezione Cloud Cameyo.
  • Senza Session Sync si trovano localmente sul server Cameyo in percorso: “C:\UserData”.

Il modo più semplice e veloce per distribuire applicazioni Windows su qualsiasi device, senza agenti, senza setup, senza VPN

Porte e indirizzi di rete utilizzati da Cameyo

AC207252020

Ultimo aggiornamento: 27 July 2020

Le configurazioni networking di Cameyo

SaaS

PORTE INBOUND

  • In una configurazione tipica, i server Cameyo richiedono che le porte http / https (in genere 80/443) siano aperta dall’esterno e/o all’interno della rete, a seconda degli utenti che ne faranno uso (interni alla LAN o esterni, appunto). Se non desideri esporlo su Internet ma solo agli utenti interni, devi rendere le porte http/https accessibili solo in LAN.
  • Se il traffico https in entrata è bloccato da Internet, si consiglia (ma non è obbligatorio) di consentire comunque l’accesso da:
    • – online.cameyo.com (in): controller back-end e iniziatore di sessione di Cameyo.
    • – healthmon.cameyo.com (in): bot di controllo qualità di Cameyo.
  • Se prevedi di utilizzare i Native Player di Cameyo (Windows e/o lettori Android), dovrai aprire anche la porta RDP (3389). E’ solo questo il caso in cui tale porta si rende necessaria. Da considerare che sarà comunque protetta tramite RDP Port Shield di Cameyo.
  • Dopo aver aperto le opportune porte per il server di Cameyo, testare l’accesso inserendo l’indirizzo del server su un browser da una macchina remota utilizzando http: //[indirizzo host], dove l’indirizzo host può essere il suo indirizzo IP/nome host/FQDN. Dovresti vedere una pagina HTML con il logo Cameyo.

INDIRIZZI OUTBOUND

  • Se la tua azienda blocca l’accesso Internet in uscita, si consiglia di consentire l’accesso https a:
    • – Preferibilmente: *.cameyo.com (outbound)
    • – In alternativa, se ciò non è possibile: api.cameyo.com, files.cameyo.com, devfiles.cameyo.com (outbound)
  • Test: avvia un browser sul server Cameyo stesso e prova ad accedere a https://online.cameyo.com e https://files.cameyo.com.
  • Funzionalità di Google Cloud: se prevedi di utilizzare la console Google Cloud di Cameyo (SessionSync) o Google Drive, è necessario aprire anche i seguenti indirizzi https: accounts.google.com, cloud.google.com, www.googleapis.com , storage.googleapis.com.

IN CASO DI PROXY

Se il server Cameyo deve passare attraverso un proxy per connettersi a Internet, assicurati che per l’account system locale su server Cameyo ci sia l’accesso proxy configurato. Puoi farlo in uno dei seguenti modi:

  • Consentire l’accesso diretto in uscita agli indirizzi https sopra indicati da questo server.
  • Configurare le impostazioni del proxy come spiegato qui

Visualizza l’articolo originale.

Il modo più semplice e veloce per distribuire applicazioni Windows su qualsiasi device, senza agenti, senza setup, senza VPN

Protezione dagli attacchi come RDP brute-force

AC207242020

Ultimo aggiornamento: 27 July 2020

Cameyo protegge le proprie istanze dalle minacce correlate a RDP utilizzando una funzionalità di sicurezza unica e senza manutenzione

SaaS

Potresti non saperlo, ma non appena abiliti la funzionalità Remote su una macchina Windows, in effetti stai aprendo le sue porte RDP al mondo esterno, in particolare le porte 3389, 3387, 3392. Quindi, se il tuo server è direttamente collegato a Internet, sei vulnerabile agli attacchi brute-force e vulnerability. Secondo uno studio condotto da Cameyo, un dispositivo Windows collegato direttamente a Internet è soggetto a centinaia di migliaia di tentativi di accesso tramite password casuali ogni settimana, eseguiti da bot automatici, script, virus e macchine zombie. Senza dimenticare gli exploit RDP, e vulnerabilità come BlueKeep.

La feature RDP Port Shield di Cameyo è una funzionalità firewall unica e dinamica che affronta questa minaccia chiudendo le porte RDP a livello Windows Firewall e aprendole in modo specifico agli utenti autenticati se/quando necessario. Il suo funzionamento su server si basa sulla creazione e gestione in tempo reale di una regola di white-list RDP sul firewall del sistema operativo.

ATTIVAZIONE

La funzionalità RDP Port Shield può essere configurata dalla pagina del server Cameyo. E’ abilitata di default:

È possibile aggiungere un elenco di indirizzi IP separati da virgola che devono sempre essere autorizzati. Nella maggior parte dei casi ciò non è necessario, poiché anche l’accesso amministrativo è consentito dinamicamente quando necessario, come spiegato di seguito. La modifica di questa impostazione richiede un riavvio del servizio. Questo può essere fatto usando il pulsante “Restart Service”.

SOTTO IL COFANO

Il meccanismo RDP Port Shield può essere descritto e suddiviso in 3 fasi:

  1. All’avvio del servizio, Cameyo disabilita tutte le regole esistenti in Windows Firewall che consentono l’accesso tramite porte RDP. Aggiunge quindi le proprie regole white-list denominate “Cameyo Port Shield (TCP / UDP-In)”. Se nella configurazione di Cameyo sono stati specificati “Admin IPs” in white-list (vedi sopra), verranno aggiunti alle regole su firewall questi ip considerati pre-autorizzati; in caso contrario l’ip assegnato alla regola aggiunta da Cameyo consisterà nel solo indirizzo “255.255.255.254”, l’accesso RDP alla macchina è in questo modo bloccato (più avanti un esempio pratico).
  2. Quando le sessioni Cameyo approvate vengono avviate tramite il portale Cameyo (ovvero online.cameyo.com/apps/xxxxx/play), si verifica uno dei due scenari seguenti:
    • – Quando vengono avviate sessioni HTML5 regolari, non vengono apportate modifiche. Le porte RDP rimangono chiuse. Le sessioni HTML5 di Cameyo non richiedono l’interazione delle porte RDP da utente a server.
    • – Quando vengono avviate sessioni RDP dirette, il portale di Cameyo (tramite il quale gli utenti si autenticano per avviare sessioni) informa il server interessato che occorre aprire l’accesso RDP all’indirizzo IP dell’utente richiedente. Le sessioni Direct RDP includono: l’accesso Admin (ovvero tramite il pulsante “Generate .RDP file” del portale Cameyo), sessioni avviate utilizzando Native Player di Cameyo o sessioni avviate tramite dispositivi Android mobili.
  3. Gli indirizzi IP in white-list vengono rimossi e ripuliti al riavvio del servizio Cameyo, che avviene in automatico dopo poche ore.

ESEMPIO

Nell’esempio seguente, Port Shield di Cameyo ha disabilitato le regole di autorizzazione RDP pre-esistenti e ha aggiunto la propria regola con indirizzo 255.255.255.254.

A seguito di una richiesta di sessione RDP diretta autenticata dal portale, Port Shield ha aggiunto l’autorizzazione per le connessioni RDP provenienti dall’indirizzo 37.189.xxx.xxx:

Questa autorizzazione di accesso verrà cancellata al successivo riavvio del servizio Cameyo entro poche ore, riportandolo solo agli indirizzi IP in white-list:

Visualizza l’articolo originale.