Menu Chiudi

Kattive/Danselfduty integrazione con SQUID/Dansguardian

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
WordPress Appliance - Powered by TurnKey Linux