Tutti gli articoli di Roberto Massa

MeetUp TTG a Torino il 15 febbraio 2018

Facebooktwittergoogle_plusredditlinkedin

Io ed Ermanno Goletto giovedì saremo ospiti del meetup del 15 febbraio organizzato da Torino Technologies Group in cui analizzeranno in modo dettagliato i componenti di Active Directory e il loro impatto sul sistema in caso di malfunzionamento. Inoltre verranno approfondite le Best Practices e gli strumenti a disposizione nelle varie versioni di Windows Server per eseguire il troubleshooting e il disaster recovery di Active Directory.

LastLogon, LastLogonTimeStamp, LastLogonDate. Utilizzo degli attributi per la rilevazione di oggetti “Stale” in AD PS CMD-LET Search-ADAccount

Facebooktwittergoogle_plusredditlinkedin

Ognuno degli attributi presenti è utile per la rilevazione di quelli che sono gli oggetti scaduti o Stale all’interno di un’infrastruttura AD.

Sono utili quindi per determinare se un utente o un computer hanno effettuato un logon al dominio e nel caso basarsi su questo valore temporale per eventualmente eliminare i vari oggetti utente o computer non più utilizzati e che possono essere fonte di brecce nella sicurezza di un’infrastruttura AD.

Gli oggetti utente e computer hanno diversi attributi che riportano informazioni relative ad eventi di logon/logoff

LastLogon

Prima della versione 2003 di Windows Server era disponibile l’attributo LastLogon per determinare il reale evento di logon di un utente o macchina.

Il valore era aggiornato solo nel Domain Controller che effettivamente validava la richiesta di accesso.

L’attributo, che è ancora presente nelle versioni successive, non è replicato, quindi per effettuare una verifica basandosi su questo è necessario effettuare una query su ogni DC del dominio e considerando il più recente come valido.

Con le successive versioni di Sistema Operativo il significato ed il meccanismo di replica di questo attributo non è stato modificato.

In buona sostanza il valore contenuto in LastLogon si può considerare come assoluto soltanto se si dispone di un dominio con un solo Domain Controller.

1 attributo LastLogon su ambiente con più di un DC ed autenticazione non avvenuta sul DC interessato dalla query

LastLognTimeStamp

Nelle versioni di Windows Server dalla 2003 in poi è disponibile un nuovo attributo che è replicato tra tutti i DC, questo riporta in modo univoco il valore temporale espresso in FILETime, ossia il numero di intervalli di 100 nanosecondi che intercorrono tra il “momento” attuale ed il 1° gennaio 1601 riferito ad UTC.

2 attributo LastLogonTimeStamp sul medesimo DC e per lo stesso evento di Logon

Troveremo quindi un valore numerico all’interno di una variabile di tipo INT64, tale valore dovrà poi essere elaborato per poter essere letto nel formato data/ora classico.

È possibile con il comando w32tm /ntte eseguire una rapida conversione del valore contenuto nell’attributo

Fatte le considerazioni precedenti, in relazione alla differenza tra i due attributi, è possibile verificare tramite l’utility Repadmin, l’effettiva replica su tutti i DC degli attributi visti prima.

repadmin /showattr * “CN=Utente Test,OU=Test,DC=dominio,DC=loc /attrs:lastLogontimeStamp”

3 replica dell’attributo lastLogonTimeStamp

Questo attributo è replicato sui vari DC e popolato con lo stesso valore

mentre il valore dell’attributo LastLogon rilevato sempre con Repadmin riporterà esclusivamente il DC che ha effettuato l’autenticazione dell’oggetto.

Questo attributo può riportare informazioni non attuali, infatti è replicato secondo il valore impostato in un ulteriore attributo

ms-DS-Logon-Time-Sync-Interval attributo espresso in giorni da 1 a
100.000

This attribute controls the granularity, in days, with which the last logon time for a user or computer, recorded in the lastLogonTimestamp attribute, is replicated to all DCs in a domain.

Di default questo non è impostato e per valore predefinito è considerato pari a 14 giorni, l’aggiornamento del dato avviene in caso di logon e se questo valore è precedente alla data/ora attuale diminuita del valore in msDS-LogonTimeSyncInterval,

La sincronizzazione iniziale dopo l’elevazione del livello funzionale del dominio è calcolata come 14 giorni diminuita di un valore percentuale casuale di 5 giorni

4 stato dell’attributo LastLogon su tutti i DC

(è da notare che l’utente scelto per questa dimostrazione è stato creato ex novo ed ha eseguito un solo accesso)

Tramite ADUC è possibile visualizzare il valore convertito di questo attributo

Per attivare la visualizzazione degli attributi è necessario attivare la funzionalità di visualizzazione avanzata all’interno di ADUC

 

 

 

 

 

 

ADUC riporta la conversione del valore numerico in formato data/ora mentre la visualizzazione diretta del contenuto evidenzia il valore numerico

LastLogonDate

Un ulteriore attributo messo a disposizione per rilevare le attività di accesso di un oggetto macchina oppure utente è LastLogonDate, che è un valore calcolato localmente in relazione alla replica dell’attributo LastLogonTimeStamp.

Viene cioè convertito in data/ora il valore numerico dell’attributo LastLogonTimeStamp localmente ad ogni server e salvato nell’attributo LastLogonDate, risulta quindi utile in quanto permette di calcolare direttamente le differenze data senza la conversione necessaria con LastLogonTimeStamp.

Ad esempio risulta più semplice rilevare con un calcolo dinamico rispetto alla data odierna gli utenti che non eseguono accesso da più di n giorni

get-aduser -filter -properties Name,LastLogonDate |
Where-Object {$_.LastLogonDate -ge (get-date).adddays(-400)}

Search-ADAccount Powershell Cmd-Let

Finora abbiamo visto come una serie di attributi ed i valori in essi contenuti ci possono aiutare per la rilevazione in AD di alcune anomalie, come ad esempio oggetti non utilizzati.

In questo contesto powershell ci ha permesso di interrogare gli attributi interessati e di rilevarne il valore per poi determinare le nostre azioni.

In modo più strutturato, in PS è disponibile un cmd-let che è in grado di rilevare agevolmente quelli che sono gli Stale-Object.

Il command-let Search-ADAccount è utile per rilevare le informazioni di scadenza, blocco etc. relative ad un oggetto che effettua attività di logon al dominio Utenti, Computer o Service Account

Esempi:

Rilevazione di oggetti computer non attivi da più di 90 giorni

Search-ADAccount -ComputersOnly -AccountInactive | ? { $_.LastLogonDate -lt (get-date).AddDays(-90) } | Select-Object Name,LastLogonDate,DistinguishedName

Rilevazione di oggetti utente non attivi per più di 90 giorni

Search-ADAccount -AccountInactive -UsersOnly | ? { $_.LastLogonDate -lt (get-date).AddDays(-90) } | Select-Object Name,SAMAccountName,LastLogonDate,Enabled,LockedOut,PasswordExpired

Riferimenti

Microsoft Virtual Academy considerazioni sugli oggetti scaduti

Attributo LasLogonTimeStamp

Attributo LastLogon

Articolo Technet

Installazione di GLPI 9.2.0 in ambiente Linux

Facebooktwittergoogle_plusredditlinkedin

Sul sito ICTPower.it abbiamo pubblicato una serie di articoli relativi al Software di gestione ed inventory GLPI, che alla prova dei fatti si è rivelato molto potente principalmente grazie alla sua modularità che ne estende le funzioni tramite molteplici Plug-In.

Riprendendo articoli, già pubblicati, in cui si analizza il percorso passo-passo per la configurazione in ambiente Windows, e dato che GLPI è rilasciato anche per ambienti Linux, proponiamo qui la sua installazione e configurazione di base su questo sistema operativo.

Dato che questa guida prescinde dall’analisi più ad alto livello delle potenzialità del software e delle sue origini, consigliamo, prima di addentrarsi nell’installazione vera e propria, di dedicare un po’ di tempo alla lettura di questo articolo.

Installazione di GLPI in ambiente Windows

relativo all’installazione su Windows Server 2016 ma con una approfondita overview sul progetto e sulla sua documentazione

Premessa

Come è noto la galassia delle distribuzioni Linux è molto estesa, e pur se presenti in rete installazioni di GLPI già preconfezionate per Debian ed altre distribuzioni, in questo articolo è considerata l’installazione in ambiente CentOS, che per sua origine è molto vicina alle distribuzioni Redhat, Fedora ed Oracle Linux Enterprise.

La versione di CentOS che è stata utilizzata è la 7.4 nella sua opzione “minimal” che consente l’installazione di un sistema operativo molto leggero e quindi anche con limitata superficie di attacco.

GLPI è sviluppato in php e utilizza MariaDB (MySQL) per l’archiviazione delle proprie informazioni, mentre come web server è utilizzato l’onnipresente Apache.

Preparazione del sistema operativo

Terminata l’installazione di CentOS 7 nella configurazione Minimal, è utile prima di procedere, effettuare un aggiornamento del sistema tramite YUM, eseguendo il comando

yum update

Alla data di pubblicazione del presente articolo la versione ultima del sistema operativo è la 7.4.1708

il consiglio, per chi dovesse utilizzare questa guida tra qualche è di verificare le eventuali incompatibilità con le Build più recenti del Sistema Operativo.

Terminato l’aggiornamento base del sistema operativo è utile installare PHP (che verrà aggiornato successivamente) e l’utility WGET utile per il recupero di alcuni file di installazione da GitHub (il repository da cui è disponibile GLPI)

yum -y install wget

yum -y install php

Aggiornamento di PHP

A questo punto è necessario aggiornare PHP utilizzando i repository EPEL (Extra Packages for Enterprise Linux) e REMI

wget -q http://rpms.remirepo.net/enterprise/remi-release-7.rpm

wget -q https://dl.fedoraproject.org/pub/epel/epel-release-latest-7.noarch.rpm

rpm -Uvh epel-release-latest-7.noarch.rpm

rpm -Uvh remi-release-7.rpm

scaricati ed installati i riferimenti ai repository si dovrà abilitare il ramo del repository REMI relativo alla versione 7.1 di PHP

yum-config-manager --enable remi-php71

e successivamente eseguire l’update di PHP

yum update php

a questo punto è possibile verificare la versione di PHP installata

php -v

Terminata questa prima fase di configurazione ed aggiornamento è necessario installare una serie di pacchetti PHP e database necessari al funzionamento di GLPI

yum -y install http

yum -y install php-mysql

yum -y install php-pdo

yum -y install php-gd

yum -y install php-imap

yum -y install php-mbstring

yum -y install php-ldap

yum -y install php-xml

yum -y install php-opcache

yum -y install php-pecl-apcu

yum -y install php-xmlrpc

yum -y install mariadb-server

yum -y install net-tools vim

Configurazione del Firewall di sistema operativo

Configurazione delle componenti di sicurezza Firewall per consentire l’accesso a GLPI

firewall-cmd --permanent --add-service=http

firewall-cmd --reload

in questo esempio è utilizzato il protocollo http, nel caso in cui si intenda attivare il protocollo Https sarà necessario adattare il comando di configurazione per le regole del firewall e configurare Apache per l’uso di certificati.

nel caso si utilizzi un dominio pubblico tramite Letsencrypt è possibile ottenere certificati validi gratuitamente. In alternativa per ambiti lan con domini privati è possibile gestire il rilascio di gertificati tramite l’installazione di CA private.

Impostazione di avvio dei servizi

Impostazione delle opzioni di avvio per Apache e MariaDB al fine di avviare a boot-time i servizi base per GLPI

systemctl enable httpd

systemctl start httpd

systemctl enable mariadb

systemctl start mariadb

Configurazione dell’ambiente MariaDB e creazione del Database per GLPI

Completata questa fase, che definisce i pacchetti base e di supporto per GLPI, è necessario proseguire con la configurazione di ambiente e successivamente creando il DB e la credenziale di accesso che GLPI utilizzerà per il suo funzionamento.

mysql_secure_installatio

questo comando esegue una configurazione dell’ambiente di sicurezza del Database a partire dall’impostazione della password dell’utente root (di database).

Per la nostra installazione, definita la password, è sufficiente confermare tutte le scelte di default fino al temine.

Il passo successivo permette la creazione del Database per GLPI

mysql -u root -p

create database glpi;

CREATE USER 'GlpiUser'@'localhost' IDENTIFIED BY '
1!UserGlpi';

GRANT ALL PRIVILEGES ON glpi. * TO 'GlpiUser'@'localhost' IDENTIFIED BY '
1!UserGlpi';

FLUSH PRIVILEGES;

Installazione di GLPI

I passaggi per l’installazione vera e propria di GLPI sono pochi e molto semplici, è sufficiente scaricare il pacchetto GLPI da repository GitHub e, una volta scompattato, copiarlo nella cartella di Apache.

wget https://github.com/glpi-project/glpi/releases/download/9.2.1/glpi-9.2.1.tgz

tar -xvf glpi-9.2.1.tgz

cp -R glpi /var/www/html

è fortemente consigliato prima di procedere al download di GLPI verificare in GitHub la versione disponibile. Di norma è consigliato il download dell’ultima versione stabile

terminata la copia del pacchetto GLPI è necessario definire le impostazioni di accesso ai file copiati in modo da impostare correttamente la sicurezza dell’installazione.

chmod -R 755 /var/www/html/glpi

chown -R apache:apache /var/www/html/glpi

Prima di procedere con l’avvio della configurazione bisogna modificare il file httpd.conf, relativo alla configurazione di Apache, ed impostare la direttiva AllowOverride per la cartella Docroot a Limit

vi /etc/httpd/conf/httpd.conf

un’ultima configurazione è necessaria per la corretta impostazione in Selinux (che di default è attivo) al fine di permettere a GLPI di operare correttamente

chcon -R -t httpd_sys_rw_content_t /var/www/html/glpi/

setsebool -P httpd_can_network_connect 1
setsebool -P httpd_can_network_connect_db 1

setsebool -P httpd_can_sendmail 1

al termine dei vari passaggi descritti è utile eseguire un riavvio del servizio Apache prima di procedere alla seconda fase della configurazione tramite il browser Web

systemctl restart httpd.service

Completamento della configurazione

a questo punto accedendo tramite un browser all’indirizzo http://<Fqdn>/glpi
è possibile in pochi ulteriori passi portare a termine la configurazione.

Selezionare la lingua di utilizzo dell’applicativo

Accettare i termini della licenza d’uso

Selezionare “install” in quanto si tratta di una nuova installazione

viene eseguito un controllo sulla validazione dei componenti installati


L’installazione procede con la richiesta delle credenziali di accesso al DB creato in precedenza


Selezionare il db GLPI


La configurazione dell’ambiente DB termina con messaggio di conferma


Viene riproposto un riepilogo delle credenziali di accesso default


È possibile accedere direttamente al software


Da cui sarà necessario procedere ad alcune successive impostazioni

Considerazioni

L’installazione è terminata ed il prodotto è utilizzabile la documentazione ufficiale e descrittiva delle varie funzionalità ed impostazioni è reperibile qui:

http://glpi-project.org/

sul sito IctPower sono disponibili i seguenti articoli relativi alla configurazione e gestione di GLPI in ambiente Windows Server


configurazione di GLPI

backup di GLPI


Utilizzo e configurazione di Let’s Encrypt in ambiente Linux/Apache

Facebooktwittergoogle_plusredditlinkedin

In questo articolo abbiamo proposto l’utilizzo della Certification Authority Let’s Encrypt ed
una configurazione basata sull’implementazione del rilascio automatico di certificati per Internet Information Services.

Analogamente al Web server Microsoft possiamo utilizzare questa CA anche per ambienti Open, quindi Linux, OpenBsd, Nginx ed altri e quindi anche per il rilascio automatico di certificati nel Web server Apache

Nell’analisi della soluzione proposta è bene tenere in considerazione che l’estrema varietà di distribuzioni Linux, comporta anche differenze di implementazione della soluzione proposta, in questo caso i passi descritti sono riferiti ad una distribuzione Centos 6.9 e quindi applicabili all’ambiente RedHat, così come Oracle Linux Enterprise.

Il client ACME (Automated Certificate Management Environment), così come per l’ambiente Windows è disponibile anche in Linux un Client ed è scaricabile tramite Git

Per procedere alla sua installazione è necessario procedere come segue:

  • Installare HTTPD
  • Installare MOD_SSL
  • Installare i riferimenti al repository EPEL (Extra Packages for Enterprise Linux) da cui installeremo Git
  • replicare in locale il repository GIT per Let’s Encrypt in /usr/local

terminata la parte di semplice installazione è necessario procedere con i pochi passi necessari ad attivare e configurare il client in modo da permettere il primo rilascio ed il successivo rinnovo dei vari certificati.

È da tenere presente che:

As a domain may resolve to multiple IPv4 and IPv6 addresses, the server will connect to at least one of the hosts found in the DNS A and AAAA records, at its discretion. Because many web servers allocate a default HTTPS virtual host to a particular low-privilege tenant user in a subtle and non-intuitive manner, the challenge must be completed over HTTP, not HTTPS.

Il DNS relativo all’ host/dominio per cui si richiede il certificato dovrà avere un record di tipo “A” e non sarà validato in caso di “CNAME”.

Al Punto 1 viene installato il Web Server Apache tramite il comando yum install HTTPD e verranno anche installate le eventuali dipendenze.

Mod_ssl previsto al punto2 è il modulo di gestione del protocollo SSL/TLS in Apache installabile con yum install mod_ssl

Punto 3, il repository EPEL contiene molte estensioni per i sistemi basati su sistemi Linux RedHat Centos e similari anche qui con il comando yum install epel-release otterremo la possibilità, sempre tramite yum di installare numerosi altri pacchetti in questo caso epel ci consente di installare GIT.

AL punto 4 Tramite il comando git clone https://github.com/letsencrypt/letsencrypt posizionandosi in /usr/local potremo replicare in locale la componente ACME con cui richiedere successivamente a Let’s Encrypt i certificati.

Figura 1 Replica da GIT di Let’s Encrypt

Configurazioni preliminari

Prima di procedere con la vera e propria richiesta alla CA dovremo però fare in modo che il WEB server risponda effettivamente anche per l’host per cui attiveremo HTTPS, questa impostazione, è all’interno del file di configurazione di Apache in httpd.conf, editandolo, dovremo definire un Virtual Host per il nostro sito attivo in http.

Figura 2 Impostazione VirtualHost Httpd

Richiesta del certificato HOST

Definita questa impostazione potremo procedere alla richiesta vera e propria del certificato utilizzando l’ambiente CertBot scaricato prima da GIT, posizionandoci quindi in /usr/local/letsencrypt dovremo eseguire il comando:

./letsencrypt-auto --apache -d linux1.robimassa.it

Dove specificheremo il tipo di Web Server utilizzato, ed l’FQDN dell’host che andremo a configurare

Per un elenco completo delle opzioni del client Let’s Encrypt potremo usare l’opzione –help

A questo punto verrà effettuata la richiesta verso la CA, sarà verificato se la configurazione DNS ed host sono corrette, ed in piena autonomia il client provvederà anche a modificare per noi la configurazione del file httpd.conf.

Durante la procedura di installazione sarà possibile scegliere se definire un redirect dalla porta 80 alla 443 o mantenere il precedente protocollo http ed insieme https.

Figura 3 Output comando di richiesta Certificato

Terminata la procedura di configurazione il file httpd.conf sarà modificato secondo le impostazioni volute

Figura 4 Modifica httpd.conf

La nuova impostazione di HTTPS con il certificato richiesto è definita in un file di configurazione che verrà incluso nella configurazione principale

Figura 5

Si noti che il certificato, la relativa chiave privata, la csr e più in generale tutto l’ambiente necessario alla gestione è creato all’interno di /etc/letsencrypt.

Rinnovo automatico del Certificato

Terminata la prima configurazione/richiesta il certificato rilasciato è valido per 3 mesi

Figura 6

il rinnovo può avvenire in modo automatico tramite un’attività impostata (anche quotidianamente) in cron, il comando da impostare è usr/local/letsencrypt-auto renew


ogni operazione che è compiuta dal client è “loggata” in /var/log/letsencrypt/letsencrypt.log

Conclusioni

Let’s Encrypt è una CA Free che può essere utilizzata liberamente da chiunque, il limite finora è nella possibilità di richiedere certificati di tipo Wildcard, ossia per un intero dominio ad esempio *. robimassa.it

Qualche mese fa è stato annunciato anche il rilascio per questo tipo di certificati a partire da gennaio 2018

Figura 7

Riferimenti:

https://letsencrypt.org/

https://certbot.eff.org/

Gestione della Modalità Enterprise di Internet Explorer Versione 11

Facebooktwittergoogle_plusredditlinkedin

Come abbiamo avuto modo di vedere nel Video Tech Heroes di Nicola Ferrini e Paola Presutto, Microsoft ha abbandonato il supporto delle versioni “legacy” di IE mantenendolo esclusivamente per la versione 11.

Nella estrema varietà di siti che ci si trova ad utilizzare, soprattutto in ambito aziendale, non è raro incontrare applicazioni web che richiedono la compatibilità con versioni precedenti di Internet Explorer.

Già dalla versione 10 del browser era attivabile la gestione della “Visualizzazione Compatibilità

Figura 1

Questa impostazione tuttavia non consentiva (e non consente nemmeno in IE 11) un’impostazione puntuale su un singolo host, infatti definendo www.ictpower.it come host da visualizzare in modalità compatibile, l’elenco viene popolato con l’intero dominio ictpower.it.

Se ci si trova ad operare in ambienti intranet esiste una sola impostazione disponibile ed anche qui non è possibile gestire il singolo host in visualizzazione compatibilità

Alcune soluzioni che abbiamo avuto modo di analizzare hanno visto implementare un dominio differente nel quale riferire i singoli host per cui è richiesta la modalità compatibile. Questa soluzione è difficilmente gestibile e richiede comunque un certo impatto sulla struttura DNS interna.

La configurazione di Internet Explorer 11 prevede una modalità operativa denominata Enterprise Mode, per mezzo della quale è possibile ovviare alla limitazione vista in precedenza, potendo così definire un preciso host in visualizzazione compatibile.

In modo ancor più granulare è possibile definire se un determinato sito deve essere utilizzato in modalità IE7 oppure IE8.

L’attivazione della Modalità Enterprise può avvenire tramite Group Policy o chiavi di registro, e la definizione dei siti e della relativa modalità di navigazione è impostata all’interno di un file XML.

La compilazione di questo file è possibile tramite un apposito tool di gestione, di cui vedremo le peculiarità più avanti.

Attivazione di Enterprise Mode tramite Group Policy

Per mezzo di una GPO è possibile centralmente gestire la modalità operativa del Browser, la Policy oltre che attivare questa impostazione istruisce il “client” su dove reperire il file XML di impostazione. Il percorso in questo caso deve essere un URL navigabile ed accessibile dal client e deve essere dichiarato nella forma

http://<FQDN>/<Nome_File>.xml

In generale, IE11, quando lavora in “Enterprise Mode”, dopo 65 secondi circa dall’avvio, ricerca il file secondo le impostazioni previste nella GPO, una volta individuato e scaricato in locale, questo non viene più controllato fino al prossimo riavvio del browser.

Il file XML, riporta all’interno un numero di versione, all’avvio, IE verifica che il file salvato localmente sia allineato con la versione presente nel repository centrale, nel caso in cui il file locale sia meno recente procede allo scaricamento della versione aggiornata.

La Group Policy può essere definita nelle impostazioni Utente o Computer in:

Modelli Amministrativi\Componenti di Windows\Internet Explorer\Usa Elenco Siti Web di Internet Explorer modalità Enterprise

Chiaramente la definizione della policy nel ramo Computer farà ereditare l’impostazione a tutti gli utenti

Figura 2

Nella configurazione riportata sopra è indicato L’URL completo del file XML definito per le impostazioni del Browser

Attivazione di Enterprise Mode tramite Registro di Sistema

Come accennato in precedenza Internet Explorer può essere attivato per la modalità Enterprise anche tramite chiavi di registro, questa impostazione consente una maggior flessibilità di gestione permettendo di definire tre modalità di reperimento del file XML, che sono:

  • Percorso HTTP(S): “SiteList”=”http://intranet.ictpower.it/SiteList.xml”
  • Rete locale: “SiteList”=”\\UNC_PATH\share\ SiteList.xml”
  • File locale: “SiteList”=file:///c:\\Users\\<user>\\documenti\\ SiteList.xml

Analogamente alla configurazione tramite Group Policy è possibile impostare il browser “per Machine” o “per User”, sarà sufficiente modificare la chiave nel ramo HKLM (HKEY_LOCAL_MACHINE) piuttosto che HKCU (HKEY_CURRENT_USER) per il resto il percorso sarà invariato.

A questo punto navigando un sito per cui è previsto l’uso in modalità Enterprise il browser presenterà anche una visualizzazione particolare, che sta ad indicare l’attivazione di questa modalità.

Figura 3

Le configurazioni viste ora definiscono in modo centralizzato quali siti devono essere navigati in modalità Enterprise, e gli utenti non hanno modo di agire ulteriormente. È possibile attivare una chiave di registro che di fatto “sblocca” l’accesso a questa modalità e quindi gli utilizzatori possono attivarla in autonomia sui vari siti utilizzati.

Modelli Amministrativi\Componenti di Windows\Internet Explorer\Consenti agli utenti di attivare e utilizzare a modalità Enterprise dal menu strumenti

Figura 4

 

Quando si attiva questa impostazione, è possibile specificare un URL che punta ad un server WEB che ha la funzione di archiviare i messaggi che vengono inviati quando un utente attiva o disattiva la modalità Enterprise dal menu strumenti.

Figura 5

Per dettagli ulteriori sulla configurazione del Server Web e per la consultazione del file di log è possibile consultare questo link.

 

 

 

Creazione del file XML per la gestione della Modalità Enterprise di Internet Explorer 11

Le configurazioni che abbiamo analizzato, si avvalgono, come già detto di un file formato XML che riporta le impostazioni relative ai vari siti, la creazione e gestione di questo file è facilitata da un apposito tool “Enterprise Mode Site List Manager“.

Ad oggi sono disponibili due versioni dello strumento a seconda della versione del sistema operativo e dello schema di XML a questo associato.

Al fine di scegliere correttamente la versione adatta si consiglia di seguire questo link, per brevità si riporta qui sotto la tabella riassuntiva delle versioni e relative compatibilità.

Figura 6

Dalla pagina di download dello strumento e relativamente alla versione V.2 viene riportato il seguente avviso

This tool lets IT Professionals create and update the Enterprise Mode Site List in the version 2.0 (v.2) XML schema. The Enterprise Mode schema has been updated to v.2 to be easier to read and to provide a better foundation for future capabilities. The v.2 schema is supported on Windows 7, Windows 8.1, and Windows 10. The v.1 XML schema will also continue to be supported on Windows 7, Windows 8.1, and Windows 10.

Il tool permette, tramite il tasto ADD, di inserire, uno per ogni riga, I vari URL che dovranno essere navigati in modalità compatibile, in alto è riportata la versione della configurazione utilizzato dal sistema per la comparazione tra il file locale e quello disponibile centralmente.

Caratteristica particolarmente utile è la possibilità di definire soltanto determinati Path di un sito, inserendo il percorso all’interno del campo URL, in questo modo è possibile gestire in modo estremamente preciso le singole aree che richiedono emulazioni differenti rispetto all’intero sito web.

Figura 7 ( definizione di siti visualizzati in modalità compatibile IE7)

Figura 8 (visualizzazione della sola area /articoli/ in modalità compatibile IE7)

Riferimenti:

https://docs.microsoft.com/it-it/internet-explorer/ie11-deploy-guide/turn-on-enterprise-mode-and-use-a-site-list

https://docs.microsoft.com/en-us/internet-explorer/ie11-deploy-guide/check-for-new-enterprise-mode-site-list-xml-file

https://technet.microsoft.com/library/dn640701.aspx

https://technet.microsoft.com/it-it/library/dn781326.aspx

Configurazione di un servizio SFTP tramite il demone SSH in Ambiente Linux

Facebooktwittergoogle_plusredditlinkedin

Può essere necessario attivare un servizio di scambio file in modo che utenti, anche esterni, abbiano la possibilità, di effettuare trasferimenti di archivi magari anche per mezzo di procedure schedulate.

Tramite il demone SSH è possibile configurare un servizio di scambio file analogamente al vecchio ed ormai in disuso FTP.

L’utilizzo di SSH in questo caso garantisce maggior riservatezza e sicurezza nella connessione in quanto la comunicazione avviene su in canale cifrato tramite la porta 22 tipica di questo servizio.

Questa peculiarità rende anche le configurazioni relative all’ambiente di protezione più semplici, ovviando alle fastidiose configurazioni necessarie per consentire il traffico in porta 20 e 21 tipiche dell’FTP, oppure all’attivazione della modalità passiva lato client.

 

 

 

 

 

 

 

Come visto in questo Post tramite SSH è possibile configurare un sistema che realizzi un tunnel in modo da Bypassare eventuali sistemi di sicurezza ed accedere in modo trasparente ad un sistema che è “dietro” ad un Firewall e non accessibile altrimenti.

Nel caso dell’implementazione del servizio SFTP tramite il demone SSH è bene tenere presente questa peculiarità ed adottare alcuni accorgimenti di sicurezza che impediscono, sulla base dell’appartenenza ad un gruppo, l’utilizzo della funzione di Tunnel.

Sempre in un’ottica di robustezza di accesso al servizio, è bene considerare la possibilità che le cartelle definite accessibili per lo scambio di file, siano confinate in un ambiente CHROOT e che gli utenti, con i permessi di accesso allo scambio file, possano esclusivamente accedere a questa funzione, ma non possano in alcun modo avere accesso tramite SSH alla shell del sistema operativo anche se con permessi limitati.

Le configurazioni qui sotto proposte, tengono conto di queste premesse e definiscono un ambiente il più “sicuro” possibile.

Le configurazioni sono effettuate nel file conf del servizio SSHD e più precisamente nel file sshd_config

(in questo esempio è presa come riferimento la Distro Linux Centos 7.x) posizionato in /etc/ssh e per mezzo dei comandi groupadd e useradd verranno creati il gruppo e gli utenti che dovranno accedere alle cartelle in “share”.

Il gruppo creato per concedere il permesso di accesso è FtpScambioFile e verrà creata in / ( root) una cartella /ScambioFiles dove verrà definita in configurazione la root dell’ambiente Chroot per SFTP al di sotto della quale saranno create una o più cartelle per l’archiviazione vera e propria

Per prima cosa è necessario creare il gruppo con il comando groupadd e successivamente la cartella dell’archivio SFTP (che può essere in un punto qualunque del Filesystem per comodità in questo esempio la creeremo in /) e le sottocartelle accessibili in lettura/scrittura

Sudo groupadd FtpScambioFile

sudo mkdir /ScambioFiles/

sudo chown root:root /ScambioFiles/

sudo chmod 755 /ScambioFiles/

la cartella ScambioFiles deve avere come proprietario l’utente root, ed i permessi come nell’esempio sopra, nel caso questo passo non venisse completato, l’accesso risulterebbe impossibile e all’interno di /var/log/secure verrebbe evidenziato un errore

A questo punto è possibile procedere con la creazione di una ulteriore sottocartella utilizzata per il trasferimento dei file e dei relativi permessi

sudo mkdir /ScambioFiles/Scambio

sudo chown root:FtpScambioFile /ScambioFiles/Scambio/

sudo chmod 775 /ScambioFiles/Scambio/

Terminata la prima parte della configurazione, ossia quella relativa alla creazione della struttura delle cartelle e dei relativi permessi, si può proseguire con la configurazione del file sshd_config come nell’immagine qui sotto.

Al termine del file nella sezione # override default of no subsystems commentare la riga presente come indicato al punto 1

Successivamente inserire le seguenti righe di configurazione

Subsystem sftp internal-sftp

Match Group FtpScambioFile

ForceCommand internal-sftp

ChrootDirectory /ScambioFiles/

PermitTunnel no

AllowAgentForwarding no

AllowTcpForwarding no

X11Forwarding no

La dichiarazione al punto 2 imposta il servizio per operare anche come un SFTP server.

Al punto 3 sono indicati il nome del gruppo, il percorso della root del CHROOT e la modalità operativa del servizio SFTP (per dettagli ulteriori consultare la pagina help disponibile sul sistema man sshd_config di cui il testo sotto è un estratto)

# man sshd_config |grep internal

Specifying a command of “internal-sftp” will force the use of an in-process sftp server that requires no support files when used with ChrootDirectory. Alternately the name “internal-sftp” implements an in-process “sftp” server. This may simplify configurations using ChrootDirectory to force a different filesystem root on clients.

A questo punto è sufficiente riavviare il servizio ssh con il comando

systemctl restart sshd.service

e procedere alla creazione dei singoli utenti che accederanno al servizio

sudo adduser -g FtpScambioFile <nome_utente>

sudo passwd <nome_utente>

tramite un client SFTP come ad esempio Filezilla è possibile accedere all’ambiente appena creato, anche nella pagina di Download di Putty è disponibile un eseguibile che da linea di comando può essere di aiuto per script vari.

Considerazioni:

E’ ancora prassi comune l’utilizzo di protocolli poco sicuri per il trasferimento di file come ad esempio FTP.

La soluzione proposta, che parte da un’esigenza ben specifica, ha permesso di salvaguardare da un lato la necessità di avere a disposizione determinate informazioni, e dall’altro di salvaguardare la sicurezza delle stesse permettendone la trasmissione all’interno di un canale cifrato.