Un ringraziamento particolare a chi mi ha aiutato a raccogliere tutte le informazioni necessarie a realizzare questa “breve” guida ! (Roberto Resoli e Mitja Tavcar del Comune di Trento).
Danselfduty è un programma che interagisce con Squid e Dansguardian per permettere agli utenti di autorizzare l’accesso a specifici siti, bloccati a causa di politiche interne restrittive, al gruppo al quale l’utente stesso appartiene.
Un ringraziamento particolare a chi mi ha aiutato a raccogliere tutte le informazioni necessarie a realizzare questa “breve” guida ! (Roberto Resoli e Mitja Tavcar del Comune di Trento).
Danselfduty è un programma che interagisce con Squid e Dansguardian per permettere agli utenti di autorizzare l’accesso a specifici siti, bloccati a causa di politiche interne restrittive, al gruppo al quale l’utente stesso appartiene.
I servizi che entrano in gioco sono i seguenti:
– squid, come servizio proxy, utilizzato SOLO come cache (l’autenticazione degli utenti è delegata a Kattive)
– ldap, per la gestione dell’autenticazione centralizzata di utenti e password (Samba4/AD)
– dansguardian, come sistema di content-filtering
– kattive/danselfduty, per consentire agli utenti di poter sbloccare autonomamente eventuali siti bloccati da dansguardian
I server utilizzati sono i seguenti (ovviamente la configurazione può variare da caso a caso, tutti i servizi potrebbero essere installati su di un unico server):
KATTIVE
– è il gateway verso Internet
– tre schede di rete (es. INTERNET/eth0, RETE INTERNA/eth1 192.168.10.0/24, DMZ/eth2 192.168.20.0/24)
– i software installati sono dnsmasq, shorewall, kattive
SRVPROXY
– è il nostro proxy di rete
– una scheda di rete
– per ragioni di sicurezza, il posto migliore dove andarlo a posizionare è una dmz
– i software installati sono squid3 e dansguardian
SRVAD
– è il nostro server di autenticazione
– può essere un AD, OpenLDAP…. provato anche con Samba4 e il giochino funziona
Navigazione “senza” Proxy – Transparent Mode
La navigazione può essere gestita in Transparent Mode (senza impostare un proxy nelle impostazioni dei browser)
tenendo presente quanto segue:
- il protocollo https NON funziona in Transparent Mode - tutti i pacchetti https vanno autorizzati o a livello di shorewall o tramite Kattive - le autorizzazioni a livello di shorewall o tramite Kattive possono essere fatte per SINGOLO host (non è possibile autorizzare un intero dominio) - è necessario essere autenticati a Kattive prima di accedere a qualsiasi sito in HTTPS
Navigazione “tramite” Proxy
La navigazione può essere gestita configurando un proxy nelle impostazioni dei browser
tenendo presente quanto segue:
- è indispensabile informare il browser che l'indirizzo http://kattive.dominio.locale NON venga proxato - squid viene configurato per lasciare passare i protocolli HTTP, HTTPS, FTP senza richiedere autenticazione (l'autenticazione viene gestita da Kattive) - dansguardian, opportunamente configurato, blocca tutti i sitti HTTPS ad eccezione di quanto riportato nel file "greysitelist" - è possibile autorizzare un intero domonio aggiungendolo al file "greysitelist" - NON è necessario essere autenticati a Kattive prima di accedere a qualsiasi sito in HTTPS, tutte le richieste inviate al proxy vengo reindirizzate a Kattive per la successiva autenticazione
La soluzione che preferisco è questa:
– configurare il proxy sui client per fare in modo che venga utilizzato Dansguardian/Squid
– come impostazione predefinita per tutte le richieste http viene fatto il redirect verso Kattive
– eventuali richieste https vengono fatte passare attraverso il proxy che accetta le connessioni HTTPS ma delega la gestione delle permission direttamente a Dansguardian
– le richieste https possono essere autorizzate, da ogni singolo utente, tramite l’apposita interfaccia web di kattive
– Kattive si occupa di gestire l’autenticazione (o tramite richiesta utente/password o sfruttando l’autenticazione integrata tramite Samba/AD)
– ad autenticazione avvenuta viene innestata una nuova regola per autorizzare le richieste http/https/ftp verso il Proxy
Di seguito trovate uno schema di esempio per capire il funzionamento di Danselfduty.
Richieste in uscita per utenti non ancora autenticati
browser --> GW/KATTIVE --> Redirect verso Kattive (Apache) per l'autenticazione
Richieste in uscita per utenti autenticati
browser --> GW/KATTIVE (dnat verso srvproxy) --> dansguardian (porta 8080) --> squid (porta 3128) --> internet
relativo flusso di ritorno se il sito ha superato il valore massimo del parametro ‘naughtynesslimit’ (navigazione bloccata)
internet --> squid --> dansguardian --> danselfduty --> browser
relativo flusso di ritorno se il sito NON ha superato il valore massimo del parametro ‘naughtynesslimit’ (navigazione NON bloccata)
internet --> squid --> dansguardian --> browser
Questo è un esempio di cosa accade in pratica:
– l’utente pippo apre il proprio browser
– alla prima richiesta (es. http://www.sitodavisitare.it) Kattive richiede utente e password (o sfrutta l’autenticazione integrata tramite Samba/AD)
– dansguardian, in base al gruppo di appartenenza, applica i relativi filtri (dopo aver scaricato la pagina da analizzare tramite squid)
Dansguardian NON ha bloccato i contenuti richiesti
– restituisce la relativa pagina al browser
Dansguardian HA BLOCCATO i contenuti richiesti
– dansguardian redirige la richiesta a danselfduty che viene eseguito dal server apache presente sul server kattive
– l’utente pippo, a questo punto, può scegliere tra: abbandonare la navigazione, visualizzare un’anteprima della pagina richiesta, abilitare la navigazione per tutti gli utenti appartenenti al proprio gruppo di navigazione.
COME IMPLEMENTARE LA SOLUZIONE PROPOSTA
server AD (il nostro server LDAP)
– creare un utente in AD che ci consenta di interrogare il database LDAP (es. kattive in Users)
– creare i relativi gruppi per poter assegnare i vari utenti ai relativi filtri dansguardian (es. K_segreteria, K_ragioneria …)
– per una questione di ordine è possibile creare un’apposita organization unit in cui posizionare tutti i gruppi/permessi di navigazione (es. OU-GruppiKattive)
– assegnare ad ogni utente il relativo gruppo di appartenenza
server SRVPROXY
– installare squid
es. di configurazione del file /etc/squid3/squid3.conf # porta in ascolto client (proxy verso 8080) --> dansguardian (8080) --> squid (3128) http_port 3128 transparent # imposto la tipologia e la dimensione della cache assegnata a squid 30G # su 32 cartelle di primo livello e 512 cartelle di secondo livello cache_dir ufs /var/spool/squid3 30720 32 512 # acl varie acl manager proto cache_object acl localhost src 127.0.0.1/32 # elenco reti abilitate acl reti src 192.168.1.0/24 # Rete locale acl reti src 192.168.2.0/24 # Rete Wifi acl reti src 192.168.3.0/24 # Rete remota # definizione delle acl relative alle porte acl SSL_ports port 443 # elenco porte ssl acl Safe_ports port 80 # http acl Safe_ports port 21 # ftp acl CONNECT method CONNECT # gestione abilitazioni http_access deny manager !localhost http_access allow CONNECT SSL_ports http_access deny !Safe_ports http_access deny CONNECT http_access allow reti http_access deny all # parametri vari follow_x_forwarded_for allow localhost acl_uses_indirect_client on log_uses_indirect_client on hierarchy_stoplist cgi-bin ? coredump_dir /var/spool/squid3 # Add any of your own refresh_pattern entries above these. refresh_pattern ^ftp: 1440 20% 10080 refresh_pattern ^gopher: 1440 0% 1440 refresh_pattern -i (/cgi-bin/|\?) 0 0% 0 refresh_pattern . 0 20% 4320
– installare dansguardian
– verificare che nel file /etc/dansguardian/dansguardian.conf siano presenti le seguenti righe
# faccio in modo che dansguardian fornisca l'IP del client a squid tramite l'header della richiesta http forwardedfor = on # necessario al corretto funzionamento dell'autenticazione tramite ip usexforwardedfor = on # 2 = report fully reportinglevel = 2 # indirizzo del server kattive su cui è presente danselfduty accessdeniedaddress = 'https://kattive/danselfduty.cgi' # numero di filtri da gestire filtergroups = 2 # abilito l'autenticazione tramite ip authplugin = '/etc/dansguardian/authplugins/ip.conf'
– per ogni gruppo/filtro da gestire creare uno specifico file dansguardianfX.conf e configurarlo secondo le proprie esigenze
– per ogni gruppo/filtro creare una cartella fX in /etc/dansguardian dove posizionare eventuali file di configurazione per il gruppo specifico (es. bannedsitelist, bannedmimetypelist)
server KATTIVE (il nostro gateway)
– verificare che in /etc/hosts sia stato associato il nome host a tutte le interfacce presenti sul server stesso
es. 192.168.10.251 kattive.dominio.locale kattive 192.168.20.251 kattive.dominio.locale kattive
– installare e configurare shorewall
– configurare shorewall per gestire il redirect delle richieste HTTP verso kattive per tutti gli utenti non autenticati
es. REDIRECT int:RETE_INTERNA/24!EVENTUALE_IP_DA_ESCLUDERE/32 PORTA_APACHE_KATTIVE tcp www - !IP_SERVER_KATTIVE
– installare kattive come riportato nella documentazione ufficiale
– eseguire i seguenti comandi per montare la cartella di configurazione di dansguardian sul server KATTIVE
# apt-get install sshfs # ssh-keygen # ssh-copy-id -i /root/.ssh/id_rsa.pub root@srvsquid # mkdir /etc/dansguardian # sshfs -o allow_other root@srvproxy:/etc/dansguardian /etc/dansguardian/
– in /etc/rc.local inserire la seguente riga per fare in modo di ripristinare il collegamento al riavvio del server:
sshfs -o allow_other root@srvproxy:/etc/dansguardian /etc/dansguardian/
– in /opt/kattive/etc/general.conf cambiare il comando
dansguardian -g
in
ssh srvsquid dansguardian -g
e
dansguardian_filters_file => “/etc/dansguardian/filters.txt”,
in
dansguardian_filters_file => “/opt/kattive/cache/filters.txt”,
– creiamo il file filters.txt nel posto giusto nel modo seguente
# cp -p /opt/kattive/etc/dansguardian/filters.txt /opt/kattive/cache
– modifichiamo il file /opt/kattive/cache/filters.txt in base ai gruppi AD/LDAP utilizzati
es. #gruppo:filtrodg:filefiltrodg:fileskype:authorize[0,1]:preview[0,1]:sottogruppi(separati da ,) k_utenti:filter1:dansguardianf1:/etc/squid/skype.txt:1:1: k_ced:filter2:dansguardianf2:/etc/squid/skype.txt:1:1:
– popoliamo l’elenco degli utenti per consentire a Dansguardian di associare i relativi filtri
# /opt/kattive/bin/dansguardianfromLDAP.pl -domain=DOMINIO.LOCALE
– scheduliamo (a piacere) l’esecuzione di dansguardianfromLDAP.pl
# cat /etc/cron.d/dansguardianfromLDAP */5 * * * * root /opt/kattive/bin/dansguardianfromLDAP.pl -domain=DOMINIO || true
– abilitiamo l’uso di dansguardian in Kattive modificando il file /opt/kattive/etc/logs.conf
# uso di dansguardian use_dansguardian => 1,
– copiamo la cartella /opt/kattive/doc/examples/dansguardian-squid3-schroot/etc/dansguardian/languages/kattive in dansguardian necessaria al funzionamento di Danselfduty
# cp -pr /opt/kattive/doc/examples/dansguardian-squid3-schroot/etc/dansguardian/languages/kattive /etc/dansguardian/languages
– modifichiamo la lingua contenuta nel file dansguardian.conf
language = 'kattive'
– per ogni gruppo di utenti creiamo uno specifico file in /etc/dansguardian
# cp /etc/dansguardian/dansguardianf1.conf /etc/dansguardian/dansguardianf2.conf # cp /etc/dansguardian/dansguardianf1.conf /etc/dansguardian/dansguardianf3.conf
– deleghiamo la gestione della navigazione tramite HTTPS a Dansguardian (squid viene configurato per NON bloccare la navigazione tramite https…. ci pensa Dansguardian), modifichiamo il contenuto di /etc/dansguardian/lists/bannedsitelist
#Blanket SSL/CONNECT Block. To block all SSL #and CONNECT tunnels except to addresses in the #exceptionsitelist and greysitelist files, remove #the # from the next line to leave only a '**s': **s
In che modo vengono AUTORIZZATI i siti ?
La gestione dell’autorizzazione dei siti tramite DanselfDuty varia in base alla tipologia di protocollo utilizzato.
# ------------------------------------------------------------------------------------------------- # # Domini accessibili abilitati dagli utenti tramite danselfduty - SOLO _HTTP_ # # il file /opt/kattive/etc/general.conf e' stato configurato in questo modo # # #variabile del file .conf di dansguardian che definisce il file delle eccezioni http # STRINGDANSGUARDIANEXCEPTIONFILE => "exceptonsitelist", # # # NB. per tutti i siti che matchano _NON_ vengono applicati altri controlli # (es. controllo sulla tipologia di file scaricato) # # ------------------------------------------------------------------------------------------------- - viene popolato il file exceptionsitelist ed eseguito un "dansguardian -r"
# ------------------------------------------------------------------------------------------------- # # Domini accessibili abilitati dagli utenti tramite danselfduty - SOLO _HTTPS_ # # il file /opt/kattive/etc/general.conf e' stato configurato in questo modo # # # variabile del file .conf di dansguardian che definisce il file delle eccezioni https # STRINGDANSGUARDIANEXCEPTIONHTTPSFILE => "greysitelist", # # # NB. per tutti i siti che matchano vengono applicati TUTTI gli altri controlli # (es. controllo sulla tipologia di file scaricato) # # ------------------------------------------------------------------------------------------------- - viene popolato il file greysitelist ed eseguito un "dansguardian -r" - viene aggiunta una regola 443 per il gruppo Kattive (se nel browser è stato impostato il proxy la regola viene ignorata) - viene innestata una regola al volo di IPTables per l'utente corrente (se nel browser è stato impostato il proxy la regola viene ignorata)
postazione client:
– è indispensabile informare il browser che l’indirizzo http://kattive NON dove essere “proxato”
GESTIRE IL PREVIEW DEI SITI BLOCCATI
Danselfduty è in grado, sfruttando una specifica funzionalità di dansguardian, di consentire all’utente finale
di visualizzare eventuali contenuti bloccati per un tempo ristretto (es. 30 secondi).
Da notare come la preview NON sia una sorta di demo (i contenuti visualizzati vengono scaricati da Internet !).
Quando un utente utilizza tale funzionalità, di fatto, accede (se pur per pochi secondi) ai contenuti che dansguardian ha tentato di bloccare.
Per abilitare la funzionalità di preview in danselfduty procedere nel modo seguente:
– modificare il contenuto del file /opt/kattive/etc/general.conf
# contenuto della variabile del file .conf di dansguardian che definisce la passphrase per la preview
DANSGUARDIANPREVIEWPASSPHRASE => “fe057463fa8e4626388f56dc9fbd5498”,
# timeout di durata della preview in secondi
DANSGUARDIANPREVIEWTIMEOUT => “30”,
– modificare il contenuto per ogni file /etc/dansguardian/dansguardianX.conf per il quale si vuole consentire la preview (compreso dansguardianf1.conf)
# -1 = enable but you require a separate program/CGI to generate a valid link
bypass = -1
# passphrase per l’abilitazione della preview
bypasskey = ‘fe057463fa8e4626388f56dc9fbd5498’
– modificare il contenuto del file /opt/kattive/cache/filters.txt verificando che il parametro preview sia impostato a “1”
es. cat /opt/kattive/cache/filters.txt internet:filter1:dansguardianf1:/etc/squid/skype.txt:1:0 k_segreteria:filter2:dansguardianf2:/etc/squid/skype.txt:1:0 k_commerciali:filter3:dansguardianf3:/etc/squid/skype.txt:1:1 k_ced:filter4:dansguardianf4:/etc/squid/skype.txt:1:1
DanselfDuty utilizzo dei file alwaysparsedsites e blockedsites
blockedsites - contiene l'elenco degli indirizzi web che NON possono essere SBLOCCATI dall'utente tramite DanselfDuty, indipendentemente dal gruppo kattive di appartenenza (il file NON può contenere commenti).
alwaysparsedsites - contiene l'elenco degli indirizzi web che NON possono essere AUTORIZZATI dall'utente mediante l'interfaccia "Gestione Autorizzazioni/Blocchi dei siti" (il file NON può contenere commenti, tipicamente contiene un elenco di siti di motori di ricerca)
Note su Gestione Skype La soluzione proposta di seguito può ovviamente variare in base alle varie politiche aziendali.
L’idea di base è quella di bloccare l’utilizzo di skype a tutti gli utenti e di consentirne l’utilizzo solo tramite l’autenticazione tramite kattive.
Il file /etc/dansguardian/skype.txt:
contiene l’indirizzo del client da cui l’utente si è loggato tramite KATTIVE.
viene generato al volo da kattive quando un utente si logga
deve essere leggibile anche da squid
Vanno aggiunte le seguenti righe al file di configurazione di squid
# definisco le acl acl skype src "/etc/dansguardian/skype.txt" acl CONNECT method CONNECT # applico i relativi permessi alle acl http_access allow CONNECT skype http_access deny CONNECT
In sostanza, per tutti gli IP (utenti/pc) contenuti nel file skype.txt potranno usare la CONNECT anche in http.
Configurazione Kattive lato interfaccia Web:
– creare la “CA” e il “Certificato WEB SSL”
– configurare il dominio
es.
Generali Nome Dominio: DOMINIO.LOCALE Metodo di Autenticazione: Active Directory su LDAP Opzioni per Autenticazioni Esterne Prefisso Ricerca Gruppo: k_ Autopopolamento in KATTIVE: Si Opzioni per Autenticazioni su LDAP Versione LDAP: 3 Primary Domain Controller: IP_DEL_SERVER_LDAP Secondary Domain Controller: DN path di autenticazione Utente Privilegiato: cn=Users,dc=dominio,dc=locale Utente Privilegiato: cn=kattive Password Utente: ************* DN path di Ricerca Utente: dc=dominio,dc=locale DN path di Ricerca Gruppo: ou=OU-Kattive,dc=dominio,dc=locale Abilita connessione tramite SSL: No
– configurare le reti
es.
Generali Tipo: Rete Interna Etichetta: int Interfaccia: eth0 Nome o Indirizzo IP: kattive.dominio.locale Rete: RETE_LOCALE Netmask: 255.255.255.0 Avanzate Rete locale di instradamento: Dominio di autenticazione: DOMINIO.LOCALE Limitazione giornaliera navigazione: No Rete Interattiva: No Routing permesso: Si
– in “Configurazioni/Gestione Campi/Ambiente Gruppi di Regole/Campi presenti in Lista” aggiungere “Destinazioni interne – routing (ip sorgente)”
– creare i corrispondenti gruppi “k_” tramite l’interfaccia web di kattive
– aggiungere la regola “[(transparent proxy) ANY->80->127.0.0.1->8080->tcp]” nella sezione “Destinazioni autorizzate (ip mascherato)”
questo ovviamente nel caso il proxy sia installato sulla stessa macchina kattive
Gestione autencicazione tramite Kerberos – Autenticazione Apache2 con Kerberos(mod_auth_kerb) su Active Director
La procedura che segue serve ad impostare l’autenticazione kerberos su server apache, in
combinazione con l’implementazione Kerberos di Active Directory. Il vantaggio di questo
sistema è l’invio automatico dei ticket dai browser del client con l’utente active directory.
Questo permette di utilizzare il Single Sign On con l’autenticazione windows AD per tutti i
programmi che utlizzano apache (principalmente, i browsers).
– Installare e configurare ntp
# apt-get install ntp
– Verificare che in /etc/ntp.conf il server da cui prendere l’ora punti al server interno (solitamente il primary domain controller):
... # pool: server iburst dynamic #server 0.debian.pool.ntp.org iburst dynamic ...
– riavviare il servizio e provare se funziona la sincronia con
# ntpq -p
– installare i pacchetti necessari all’autenticazione tramite Kerberos
# apt-get install libapache2-mod-auth-kerb krb5-config krb5-clients krb5-user samba-client
– configurare il file /etc/krb5.conf
[libdefaults]
default_realm = DOMINIO.LOCALE
clockskew = 300
kdc_timesync = 1
ccache_type = 4
forwardable = true
proxiable = true
fcc-mit-ticketflags = true
default_keytab_name = FILE:/etc/krb5.keytab
[realms]
DOMINIO.LOCALE = {
kdc = ad.dominio.locale
master_kdc = ad.dominio.locale
admin_server = ad.dominio.locale
default_domain = dominio.locale
}
[domain_realm]
.dominio.locale = DOMINIO.LOCALE
dominio.locale = DOMINIO.LOCALE
– confirurare eventuali regole di firewalling dal server Kattive verso AD
ACCEPT fw int:IP_SERVER_AD udp 88 ACCEPT fw int:IP_SERVER_AD tcp 88 ACCEPT fw int:IP_SERVER_AD udp 750
– le seguenti regole invece sono necessarie SOLO per effettuare il join della macchina Kattive in AD… non dovrebbero più essere necessarie dopo aver effettuato il join !
ACCEPT fw int:IP_SERVER_AD udp 135,445 ACCEPT fw int:IP_SERVER_AD udp 137:139 ACCEPT fw int:IP_SERVER_AD udp 1024 ACCEPT fw int:IP_SERVER_AD tcp 135,139,445 ACCEPT int:IP_SERVER_AD fw udp 135,445 ACCEPT int:IP_SERVER_AD fw udp 137:139 ACCEPT int:IP_SERVER_AD fw udp 1024 ACCEPT int:IP_SERVER_AD fw tcp 135,139,445
– autenticarsi come utente Administrator
# kinit Administrator
– visualizzare l’elenco dei ticket kerberos
# klist -l
– cancellare il ticket kerberos
# kdestroy
– configurare samba nel modo seguente
netbios name = kattive realm = DOMINIO.LOCALE server string = %h server security = ADS syslog = 0 log file = /var/log/samba/log.%m max log size = 1000 dns proxy = No usershare allow guests = Yes panic action = /usr/share/samba/panic-action %d idmap config * : backend = tdb
– effettuo il join della macchina Kattive al dominio AD
#net ads join -U Administrator
– sSe vi fossero problemi nell’inserimento del dominio, provare a ripulire la cache col seguente comando
# net cache flush
– si può verificare lo stato del join con
# net ads testjoin join is OK
– dopo aver effettuato il join di Kattive in AD è necessario scaricare la chiave da AD nel file keytab da fare utilizzare ad Apache
Il keytab è un contenitori di chiavi per il principal in questione (il ns. server), contiente le chiavi segrete che il principal utilizza per scambiare le informazini con il server kerberos e il ticket granting server.
E’ fondamentale che il file keytab sia adeguatamente protetto in scrittura e anche in lettura.
Nel nostro caso a parte root esso deve essere solo leggibile da www-data: utente con cui gira apache2 su debian.
# net ads keytab add HTTP -U administrator
– ora in /etc/krb5.keytab sono presenti i principal https per kattive, per verificarli è possibile utilizzare il tool ktutil:
# ktutil ktutil: rkt /etc/krb5.keytab ktutil: l slot KVNO Principal ---- ---- --------------------------------------------------------------------- 1 0 HTTP/kattive.dominio.locale@DOMINIO.LOCALE 2 0 HTTP/kattive.dominio.locale@DOMINIO.LOCALE 3 0 HTTP/kattive.dominio.locale@DOMINIO.LOCALE 4 0 HTTP/kattive@DOMINIO.LOCALE 5 0 HTTP/kattive@DOMINIO.LOCALE 6 0 HTTP/kattive@DOMINIO.LOCALE
– modifico i permessi per il file /etc/krb5.keytab
# chown root:www-data /etc/krb5.keytab # chmod 640 /etc/krb5.keytab
– abilito l’autencicazione kerberos per Apache
# a2enmod auth_kerb
– aggiungo le seguenti righe al file /etc/apache2/sites-enabled/default-ssl
<Files apache_auth.cgi>
AuthType Kerberos
#KrbAuthRealms DOMINIO.LOCALE
KrbMethodNegotiate On
KrbMethodK5Passwd On
KrbServiceName HTTP/kattive.dominio.locale
#Krb5KeyTab /etc/krb5.keytab
require valid-user
KrbLocalUserMapping Off
</Files>
Spiegazione direttive
KrbAuthRealms - necessaria se non specificato nel file di configurazione predefinito in /etc/krb5.conf KrbMethodK5Passwd On - se è on in caso di fallita negoziazione o se non venisse passato il ticket viene richiesta utente/password kerberos Krb5KeyTab /etc/krb5.keytab - specifaca il percorso del keytab serve se diverso dal default di sistema - generalmente /etc/krb5.keytab KrbLocalUserMapping On - toglie il @REALM dal nome utente che viene passato all'applicativo es da UTENTE@DOMINIO.LOCALE diventa UTENTE
– creo un link simbolico al file kattivecli.cgi
# ln -s -T /opt/kattive/cgi-bin/kattivecli.cgi /opt/kattive/cgi-bin/apache_auth.cgi
– per distribuire il certificato https/ssl tramite le Group Policy di Windows:
Copiare il file /opt/kattive/cache/ssl/kattive.pem in un percorso raggiungibile dal server M$ 1) On a domain controller in the forest of the account partner organization, click Start, point to Administrative Tools, and then click Domain Security Policy. 2) In the console tree, double-click Public Key Policies, right-click Trusted Root Certification Authorities, and then click Import. 3) On the Welcome to the Certificate Import Wizard page, click Next. 4) On the File to Import page, type the path to the appropriate certificate files (es. certificato.pem), and then click Next. 5) On the Certificate Store page, click Place all certificates in the following store, and then click Next. 6) On the Completing the Certificate Import Wizard page, verify that the information you provided is accurate, and then click Finish. 7) Repeat steps 2 through 6 to add additional certificates for each of the ADFS servers.
Lato client posso gestire l’autenticazione integrata tramite l’esecuzione di uno script kattive.vbs eseguito con il netlogon di M$ o tramite group policy:
Set IE = CreateObject("InternetExplorer.Application")
IE.visible = 0
IE.navigate "https://kattive.dominio.locale/apache_auth.cgi?state=kattivecli"
do while IE.Busy
loop
IE.quit
Set IE = Nothing
O in alternativa posso includere del codice html/javascript direttamente alla Intranet:
il codice che richiama l'immagine è il seguente: <a href="javascript:togglestatus()"><img id="kstatus" src="https://kattive.dominio.locale/apache_auth.cgi?state=statusimage" /></a> NB. https://kattive.dominio.locale/apache_auth.cgi?state=statusimage NON innesca nessun tipo di autenticazione. dove: togglestatus() è una semplice funzione che rimpiazza l'attributo "src", e richiama la funzione che logga - slogga l'utente. makeid() genera una sequenza pseudocasuale di cinque caratteri per evitare il caching del browser. //genera una sequenza pseudocasuale di 5 caratteri function makeid() { var text = ""; var possible = "ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789"; for( var i=0; i < 5; i++ ) text += possible.charAt(Math.floor(Math.random() * possible.length)); return text; } function togglestatus() { var statusImage = document.getElementById('kstatus'); //makeid serve ad evitare il caching del browser (che avviene nonostante gli headers impostati sopra) newUrl='https://kattive.dominio.locale/apache_auth.cgi?state=togglestatus&id=' + makeid(); //window.alert("About to toggling kattive status, getting:\n\n" + newUrl); statusImage.setAttribute("src", newUrl); }
Alcune note relative all’integrazione tra Autenticazione Kattive e Iptables/NetFilter/Shorewall
Kattive è in grado di gestire le regole di iptables, innestate al momento della login, in due “modalita'” distinte:
– solo regole kattive
– regole kattive e successivamente regole iptables
La scelta della modalità con cui operare è determinata dal parametro type_fw presente nel file /opt/kattive/etc/general.conf
# tipo di firewall usato type_fw => “iptables-restore”, # type_fw => “iptables-shorewall”,
dove:
“iptables-restore” –> vengono applicate le regole di Kattive e in coda viene innestato un drop
“iptables-shorewall” –> vengono applicate le regole di Kattive e in coda NON viene innestato un drop
Integrazione con shorewall
cat /etc/shorewall/init
#salvataggio utenti attivi /opt/kattive/bin/kattiveshorewall end 2>/dev/null 1>&2 || true
cat /etc/shorewall/started
#inserisce le rule statiche nel manual degli utenti /etc/shorewall/import_static_rules.pl 2>/dev/null 1>&2 || true #reinserimento utenti attivi prima del restart /opt/kattive/bin/kattiveshorewall start 2>/dev/null 1>&2 || true # Duplicare questa riga e scommentarla completando con l'indirizzo ip o la rete # che si vuole aperto/a senza la login/redirect su KATTIVE #/opt/kattive/bin/openip start 2>/dev/null 1>&2 || true
copiare il file import_static_rules.pl (il quale si occupa di innestare le regole per tutti gli utenti) nella cartella /etc/shorewall
# cp -p /opt/kattive/doc/examples/shorewall/import_static_rules.pl /etc/shorewall/import_static_rules.pl
configurare il file /etc/shorewall/includes/REGOLEPERTUTTI nel modo seguente:
######################################################################################## # In questo file devono essere inserite tutte le regole che si vuole che siano attive # sia prima che dopo la login di KATTIVE, se non si vuole inserirle nell'utente o gruppo # in interfaccia di KATTIVE. ######################################################################################## # # QUESTO FILE NON ACCETTA LE MACRO LE DESTINAZIONI VANNO INSERITE ESPLICITE # # Esempio: # # normalmente per ssh su di un sito si userebbe # SSH/ACCEPT lan:192.168.10.0/24 inet:, # # In questo file che popola anche le rule di KATTIVE porta e protocollo devono essere espliciti # ACCEPT lan:192.168.10.0/24 inet:, tcp 22 # # ATTENZIONE: nella scrittura della regola non é possibile mettere solo la zona (senza l'indicazione degli ip), # ad esclusione della zona firewall. Il valore della zona del firewall viene letto dal file zones di shorewall # basandosi sulla tipologia "firewall" # # Esempio: # # accetto la porta ssh verso tutti gli ips # ACCEPT lan:192.168.10.0/24 inet:0/0 tcp 22 # # accetto la porta ssh verso il firtewall # ACCEPT lan:192.168.10.0/24 fw tcp 22 # # ATTENZIONE: il riferimento alle zone viene instaurato solo se la zona esiste nel file interfaces di shorewall. # In caso di sottozona che esiste solo nel file hosts di shorewall, nella scrittura della regola utilizzare # l'indicazione della zona padre (che deve comunque essere presente nel file interfaces di shorewall). # # Esempio: # # DNAT lan:192.168.10.0/24 dmz:: tcp - # # ATTENZIONE: se manca viene impostata al suo posto all'interno della regola. # COMMENT Regole Automatiche COMMENT