No more maintained.
Now just a test in a lab.
PAM (Pluggable Authentication Module)
Gestione degli accessi con PAM (Pluggable Authentication Module). Logica e configurazione.
PAM - Politica di definizione delle password
Tipo Infobox: DESCRIPTION - Skill:
Come e' risaputo, fornire esclusivamente indicazioni ai propri utenti riguardanti come debbano definire le proprie password, credo sia pressoche' inutile, poiche' avendone la possibilita' essi continueranno ad usare password semplici quali nomi di persona, date di nascita, squadra del cuore e cosi' via. L'unica soluzione valida e' fare in modo che siano obbligati a scegliersi delle password decenti.
Una simile soluzione puo' essere imolementata utilizzando Pluggable Authentication Modules, ed il modulo pam_cracklib.
Tale modulo non e' presente al termine dell'installazione base del sistema, e quindi sara' necessario installarlo tramite il comando apt-get install libpam-cracklib. Tra le dipendenze viene installato anche un dizionario, che potra' essere utilizzato per impedire la scelta di password uguali alle parole che lo compongono. Per qualche oscuro motivo, pero', anziche' un dizionario inglese od italiano sulla mia debian sarge e' ne e' stato installato uno in catalano.
E' quindi necessario rimuoverlo con un comando apt-get remove wcatalan, ed al suo posto ho installare i dizionari desiderati. Nel mio caso ho optato quelli italiano, inglese ed americano: apt-get install witalian wamerican wenglish.
Perche' il modulo am_cracklib possa farvi riferimento deve essere editato il file /etc/cracklib.conf, modificando la riga cracklib_dictpath_src:
cracklib_dictpath_search=”/usr/share/dict/italian
/usr/share/dict/american-english /usr/share/dict/british-english
/usr/share/dict/extra.words”
L'opzione modificata consente di specificare dei files contenenti delle liste di parole, che potranno essere aggiunti al database della libreria cracklib con il comando update-cracklib -a -r /etc/cracklib/cracklib.conf.
La scelta dell'utilizzo di dizionari di diverse lingue ritenga sia giustificata dalla necessita' di impedire che gli utenti possano utilizzare parole dei dizionari inglese ed americano come password. Volendo essere veramente paranoici si potrebbero aggiungere anche altri dizionari quali quello francese, tedesco ecc.
Un ulteriore precauzione presa, puo' essere la creazione del file /usr/share/dict/extra.words, anch'esso richiamato in cracklib.conf, al cui interno andranno definite tutte quelle parole non appartenenti al vocabolario, ma che potrebbero essere facilmente utilizzate come password, come ad esempio nomi di squadre di calcio, personaggi dei fumetti ecc.
Il modulo pam_cracklib si basa sulla libreria crackLib, per controllare le password e capire se rispettano determinati criteri di sicurezza.
Nel mio caso la politica prescelta per la definizione delle password e' stata la seguente:
- lunghezza di almeno 8 caratteri;
- hash md5 della password in /etc/shadow;
- presenza di almeno una lettera maiuscola;
- presenza di almeno un numero;
- almeno tre caratteri diversi rispetto alla precedente password
- verifica che la parola non appartenga ai vocabolari definiti;
- verifica che la parola inserita non sia una delle password utilizzate precedentemente
Per ottenere questo comportamento e' stato modificato nel modo seguente il file /etc/pam.d/passwd:
password required pam_cracklib.so dcredit=-1 ucredit=-1 minlen=8 difok=3
password required pam_unix.so obscure md5 use_authtok remember=20
Entrambe le regole riguardano il tipo di modulo password, ovvero quello preposto all'aggiornamento dei token di autenticazione relativi all'utente. Poiche' si vuole che entrambe le regole vengano onorate il flag di controllo e' posto a required, in modo che la richiesta del servizio (nel caso il programma passwd) fallisca in caso l'azione di almeno uno dei moduli non abbia l'esito richiesto.
Nella prima regola viene richiamato il modulo pam_cracklib con i parametri dcredit ed ucredit pari a -1 e minlen uguale a 8. Tale regola richiede che la lunghezza della password sia di almeno 8 caratteri e contenente almeno un numero ed una lettera maiuscola.
I valori negativi dei parametri dcredit ed ucredit definiscono appunto i primi due requisiti, disabilitando pero' il sistema di attribuzione dei crediti alla password. In caso contrario, abilitando il sistema di crediti per ogni numero e ogni lettera maiuscola verra' calcolato un credito pari rispettivamente al valore di dcredit ed ucredit. In tale caso la password verrebbe accettata se la sua lunghezza fosse pari almeno alla differenza tra minlen e la somma di questi crediti.
La seconda regola invece utilizza il modulo pam_unix. Il parametro obscure dovrebbe servire per eseguire una ulteriore serie di controlli, non specificati pero' nella documentazione; md5 indica di memorizzare le password usando un hash md5 anziche' la funzione crypt, ed infine use_authtok obbliga pam_unix ad impostare automaticamente come nuova password quella gia' accettata dal precedente modulo nello stack (nel caso pam_cracklib). Non utilizzando quest'ultima opzione, all'utente verrebbe chiesto di cambiare la password due volte, la prima tramite il modulo pam_cracklib e la seconda tramite il modulo pam_unix.
Inoltre, non viene impostata l'opzione nullok, che avrebbe consentito il cambio di password anche nel caso la password attuale fosse stata vuota. In caso dovesse presentarsi tale necessita', root e' comunque in grado di effettuare il cambio, poiche' queste regole non debbono essere onorate nel suo caso.
Per verificare il funzionamento della politica adottata si puo' provare ad impostare alcune password prive di numeri o lettere maiuscole, troppo corte, troppo ripetitive (come ad esempio asdasdasd) o appartenenti al vocabolario. Il sistema dovrebbe impedire la modifica, riportando rispettivamente i seguenti avvisi: BAD PASSWORD: is too simple, BAD PASSWORD: is too short, BAD PASSWORD: it does not contain enough different characters, e BAD PASSWORD: it is based on a dictionary word.
Un'altra caratteristica utile nella politica di definizione delle password potrebbe essere anche quella di impedire il riutilizzo di password usate in precedenza, poiche', in caso contrario buona parte degli utenti, per pigrizia, userebbero sempre le solite due o tre password cambiandole ciclicamente.
Tramite il modulo pam_unix e' possibile memorizzare le ultime password degli utenti nel file /etc/security/opasswd, in modo che al cambio di password si possa controllare che la parola scelta non sia compresa in questo elenco. Il numero di password memorizzate puo' essere impostato con il parametro remember di tale modulo.
In caso non esista il file opasswd e' necessario crearlo con un touch /etc/security/opasswd, pena il non funzionamento del parametro remember.
Anche con questo accorgimento, pero', la pigrizia dell'utente potrebbe ancora avere ancora vita troppo facile, ad esempio cambiando solo una lettera od un numero dalla password precedente. Per impedire un comportamento simile si potrebbe puo' richiedere che che la nuova password contenga un numero minimo di caratteri diversi rispetto alla precedente. Tale caratteristica e' gestibile tramite il parametro difok del modulo pam_cracklib.
Nell'esempio riportato viene impedito il riutilizzo di una delleultime 20 password, e si richiede il cambio di almento tre caratteri nelle nuove parole chiave. I valori specificati per difok e remember in /etc/pam.d/passwd sono quindi stati rispettivamente 3 e 20.
PAM - Limitare l'utilizzo del comando su
Tipo Infobox: DESCRIPTION - Skill:
su consente a chi lo invoca di diventare un altro utente, cambiando i propri ID e GID. Per default questo comando e' impostato con il bit SUID attivo e permesso di esecuzione per tutti gli utenti. In questo modo chiunque, conoscendo le rispettive password, e' in grado di “impersonare” un altro utente, persino root.
Un primo metodo molto brutale per limitarne l'utilizzo,potrebbe essere quello di togliere il bit SUID a /bin/su, in modo che nessuno, ad eccezione di root, possa usare tale comando. E' una soluzione possibile, ma impedirebbe ad esempio di vietare i login diretti all'utente root, perche' poi non sarebbe piu' possibile cambiare ID tramite su. D'altro canto e' innegabile il fatto che i permessi di default associati al comando siano troppo generosi.
Una buona alternativa a questi estremi potrebbe essere quella di consentire l'utilizzo del comando su esclusivamente ad un insieme ristretto di utenti selezionati.
Un possibile scenario potrebbe essere quello in cui esistano due gruppi sys_operators e administrators. Agli utenti appartenenti al primo gruppo deve essere concesso l'utilizzo del comando su, ma senza la possibilita' di diventare root, a differenza degli appartenenti ad administrators.
Una scelta del genere puo' risultare sensata nel caso ci sia la necessita' di avere piu' amministratori di sistema per la macchina in questione.
Per impedire l'utilizzo a chiunque del comando su, sono stati rimossi i permessi di lettura ed esecuzione a tutti gli utenti con chmod 750 /bin/su, ed impostato il bit SUID con chmod u+s /bin/su, ed infine cambiato il gruppo associato al file con chgrp sys_operators /bin/su.
In questo modo, i semplici utenti non avranno i privilegi per eseguire questo comando, mentre i membri di sys_operators potranno utilizzare su, potendo pero' impersonare anche root.
Per fare in modo che solo gli utenti del gruppo administrators possano utilizzare su per diventare root, si puo' ricorrere al modulo pam_wheel. Esso consente infatti di specificare uno specifico gruppo (per default il gruppo wheel) ai cui membri sia consentito di assumere ID 0.
A tale scopo e' stato modificato il file /etc/pam.d/su aggiungendo la linea :
auth required pam_wheel.so group=administrators
In questo modo se un utente del solo gruppo sys_operators dovesse cercare di eseguire su per diventare root il sistema risponderebbe con il messaggio su: permission denied, anche nel caso la password inserita per l'utente root fosse risultata corretta. Provando invece ad impersonare un altro utente il comando funzionera' correttamente.
Invocando invece su con un utente che appartenga al gruppo administrators, la procedura dovrebbe essere eseguita con con successo, consentendo accedere come utente root.
NOTA: per via dei permessi impostati a /bin/su, e' fondamentale che gli utenti del gruppo administrators, vengano aggiunti anche a sys_operators, poiche' in caso contrario non avrebbero il permesso di esecuzione per tale comando.
PAM - Cifratura della home directory tramite truecrypt
Tipo Infobox: DESCRIPTION - Skill:
Quella che segue e' la procedura da seguire per cifrare tramite truecrypt la home directory di un utente su un sistema operativo Linux, in modo che essa venga montata automaticamente al login dello stesso. A titolo esemplificativo verra' illustrata la procedura per l’utente andrea la cui home directory si trovi in /home/andrea.
Si presuppone che l’ultima versione di truecrypt sia gia' installata e configurata sul sistema.
Per prima cosa e' necessario creare un volume cifrato per l’utente con il comando truecrypt -t –c e seguire la procedura guidata inserendo le informazioni che verranno richieste come la tipologia di volume, percorso, algoritmi di cifratura ecc.
Durante la procedura, alla richiesta del tipo di Filesystem selezionare l'opzione None. Si raccomanda inoltre di impostare la stessa password utilizzata per il login dell’utente.
In caso contrario al login dello stesso, verra' stampato a video un messaggio in cui viene richiesto l’inserimento della password del volume cifrato. Il messaggio in questione pero' potrebbe essere mostrato ciclicamente e con una velocita' tale da non consentire all’utente il tempo necessario per inserire la propria password.
A titolo esemplificativo si ipotizza che il volume cifrato corrisponda al file /home/andrea.tc, ma nulla vieta di creare il volume cifrato su una partizione disponibile.
Ovviamente, per potere creare il file sotto la directory /home il comando precedente deve essere lanciato come utente root. Successivamente si dovra' modificare gruppo ed owner del file corrispondnete al volume cifrato: chown andrea:andrea /home/andrea.tc
Sempre come utente root montare il volume creato e verificare il device ad esso associato::
truecrypt -t –-filesystem=none /home/andrea.tc
truecrypt -t –l
Ipotizzando che il device mostrato nell’output del comando truecrypt -t –l sia /dev/loop1, creare un nuovo filesystem, ad esempio di tipo ext3, sul device in questione, e smontare il volume cifrato al fine di salvare le modifiche apportate:
mkfs.ext3 /dev/loop1
truecrypt -t –d
Una volta creato e preparato il volume installare il pacchetto libpam-mount: apt-get install libpam-mount
Editare il file /etc/pam.d/login ed aggiungere dopo le due direttive
@include common-account
@include common-session
la linea
@include common-pammount
Editare il file /etc/security/pam_mount.conf.xml, aggiungendo la seguente linea nella sezione relativa ai volumi:
<volume fstype=”truecrypt” user=”andrea” path=”/home/andrea.tc” mountpoint=”/home/andrea” />
A questo punto, loggandosi con l’utente andrea, se la password impostata per il volume cifrato sia uguale a quella utilizzata per accedere al sistema il volume verra' montato automaticamente nella directory /home/andrea. La directory in questione pero', potrebbe avere root rispettivamente come owner e gruppo della stessa e dei file in essa contentuti.
Sara' quindi necessario loggarsi per una volta come utente root in un’altra shell, modificare l’owner della home directory dell’utente e smontare il volume cifrato in modo da salvare le modifiche apportate:
chown –R andrea:andrea /home/andrea
truecrypt -t -d
In questo modo al successivo login dell’utente andrea, la propria home directory verra' montata assegnandole il proprietario corretto.
D'ora in poi loggandosi come andrea verra' montato il volume cifrato al posto della home dell'utente, senza richiedere alcuna password in caso essa sia uguale a quella dell'utente.
Al logout dello stesso, verra' automaticamente eseguito l’umount del volume in questione.
Ovviamente, nel caso l’utente dovesse cambiare la propria password, sara' necessario modificare anche la password associata al volume cifrato con il comando truecrypt -t -C /home/andrea.tc, pena l’impossibilita' di effettuare il login e montare la propria home directory, a causa dei problemi precedentemente esposti.
PAM - Impedire il login diretto agli account di sistema
Tipo Infobox: DESCRIPTION - Skill:
Ai fini di una migliore sicurezza del sistema, potrebbe essere utile impedire il login diretto per l'utente root, eventuali account di sistema che non siano stati disattivati ed account condivisi (ovvero la cui password sia conosciuta a piu' persone). In questo modo sara' prima necessario effettuare il login con un altro utente e poi assumere le credenziali desiderate tramite su.
Per ottenere questo comportamento si puo' ricorrere al modulo pam_access, che consente di definire delle regole in /etc/security/access.conf.
E' sufficiente aggiungere in /etc/pam.d/login la seguente linea:
account required pam_access.so
Impostanto il flag di controllo a required, se il tentativo d'accesso non dovesse rispettare le regole definite in /etc/security/access.conf la richiesta fallira', dopo avere elaborato la parte restante dello stack di autenticazione.
Ipotizzando che ad esclusione di root e degli account di sistema, tutti gli utenti appartengono ad uno tra i gruppi users, administrators e sys_operators si puo' scegliere di negare l'accesso su qualunque tty a chiunque non appartenga a tale gruppi, inserendo la seguente riga in /etc/security/access.conf:
-: ALL EXCEPT administrators sys_operators users:ALL
Il file /etc/security/access.conf, una volta effettuata l'autenticazione verra' letto dal modulo pam_access, che neghera' l'accesso diretto per tutti gli utenti che non appartengano ai gruppi elencati. Ad esempio, tentando di eseguire un login come utente root, il sistema rispondera' con il messaggio Permission denied.
Una soluzione del genere sarebbe pero' scomoda nel caso ogni utente appartenga al gruppo omonimo, poiche' per ognuno di essi andrebbe aggiunta la relativa voce in access.conf.
Per imporre che ogni nuovo utente aggiunto al sistema appartenga al gruppo user si puo' modificare il file /etc/adduser.conf impostando l'opzione USERGROUPS a no. In questo modo ogni nuovo utente apparterra' algruppo con il gid specificato dall'opzione USERS_GID. Il valore di defualt di USERS_GID e' 100 e corrisponde appunto al gruppo users.
Infine, si sottolinea come questa configurazione funzionera' correttamente solo nel caso in cui non esistano utenti di nome administrators, sys_operators o users, perche' in tal caso l'accesso verrebbe consentito a tali utenti, e non agli appartenenti ai gruppi ominimi.
PAM - Locking degli account
Tipo Infobox: DESCRIPTION - Skill:
L'idea e' quella di bloccare l'account di un utente dopo alcuni tentativi consecutivi di login errati. Una scelta del genere potrebbe prestare il fianco ad attacchi DoS, o scherzi idioti quali il cercare di loggarsi con lo username di qualche collega ed una password errata per bloccarne l'account. Essa ha pero' l'indubbio vantaggio di rendere impossibile tentativi esaustivi per indovinare la password di un'utente, avendo solamente un numero limitato di chances.
Il problema degli attacchi DoS, e' invece legato agli account di sistema utilizzati per i servizi, dai quali e' pero' possibile mettersi al riparo, disabilitando il login diretto per tali account.
Nel mio caso ho scelto di bloccare esclusivamente gli account utente, per la precisione dopo 5 errori consecutivi, inserendo le due righe seguenti in /etc/pam.d/login:
auth required pam_tally.so onerr=fail unlock_time=20 deny=5 per_user
account required pam_tally.so reset
La prima riga, relativa all'autenticazione, consente di contare il numero dei tentativi di login o di su falliti per ogni utente, andando a leggerli dal file /var/log/faillog. L'opzione onerr=fail indica al modulo come comportarsi in caso di errore, come ad esempio l'impossibilita' di accedere al file faillog, mentre unlock_time=20 indica al sistema di bloccare l'account dell'utente per 20 minuti in caso di un numero di tentativi di login errati superiore al valore di deny.
La seconda riga gestisce altri aspetti dell'account, resettando il contatore dei login falliti in caso l'utente sia stato autenticato con successo.
Anziche' bloccare definitivamente l'account, richiedendo quindi l'intervento dell'amministratore di sistema in caso qualche utente avesse inavvertitamente sbagliato troppe volte ad inserire la propria password (ad esempio per non essersi accordo del caps lock attivo), e' stata scelta una soluzione piu' dolce, facendo in modo che esso resti inaccessibile per 20 minuti. Penso chi voglia fare delle prove esaustive per scoprire una password, questo deterrente possa essere sufficiente.
Inoltre, temendo che qualcuno possa cercare di bloccare alcuni account di sistema, nella prima riga e' stato utilizzato il parametro per_user. Tale parametro indica al modulo pam_tally di ignorare il valore di deny per gli account per i quali il massimo numero di errori al login sia stato settato manualmente, ad esempio con il comando faillog -u nomeutente -m numero_errori. Impostando a -1 il numero di errori si puo' disattivare il limite al numero di login falliti, mentre il valore 0 indica di usare come riferimento il parametro deny del modulo pam_tally.
In caso di necessita' e' inoltre possibile verificare il numero di fallimenti associati a ciascun utente con il comando pam_tally nomeutente, ed eventualmente riportarli a zero con pam_tally --user nomeutente --reset.
Per default il modulo pam_tally non incrementa il contatore dei login falliti nel caso dell'utente root, perche' in caso contrario sarebbe troppo semplice causare un problemi al sistema bloccando tale account. Volendo e' possibile modificare questo comportamento tramite l'opzione even_deny_root, ma nell'esempio riportato ho preferito lasciare l'impostazione di default, considerando maggiori i rischi in cui si potrebbe incorrere rispetto ai benefici derivanti dall'opzione menzionata.
PAM - Introduzione
Tipo Infobox: DESCRIPTION - Skill:
PAM, acronimo per Pluggable Authentication Modules, e' un insieme di librerie che consentono di definire il modo in cui le applicazioni devono autenticare gli utenti. Essa consente di apportare modifiche al sistema di autenticazione senza le necessita' di modificare le applicazioni in questione.
La libreria e' gestita localmente tramite il file di configurazione /etc/pam.conf, od una serie di files per i diversi programmi, presenti nella directory /etc/pam.d . I diversi shared objects da utilizzare sono invece posti sotto /lib/security .
Personalmente, anziche' avere un unico file di configurazione, preferisco mantenere tutto separato, e quindi gli esempi presentati saranno sempre riferiti alla situazione con diversi files di configurazione in /etc/pam.d .
In questo caso ogni file dovra' avere il nome corrispondente al servizio: ad esempio il file di configurazione per ssh sara' /etc/pam.d/ssh, quello per su /etc/pam.d/su e cosi' via. Nel caso per un programma non esista il rispettivo file in pam.d esso utilizzera' la configurazione di default, definita da /etc/pam.d/other.
All'interno di ognuno di questi files viene definito lo stack di autenticazione ovvero la sequenza dei moduli da utilizzare, con le condizioni che debbono essere soddisfatte per autenticare l'utente.
Le linee in cui vengono richiamati i diversi moduli devono avere la seguente struttura :
tipo flag modulo argomenti
Tipo indica il tipo di modulo, tra i quattro disponibili:
- auth: si occupa degli aspetti relativi all'autenticazione dell'utente;
- account: aspetti dell'account non direttamente legati all'autenticazione, ad esempio consentire l'accesso in base all'ora, le risorse disponibili ecc;
- session: relativo alle operazione da eseguire prima e dopo che all'utente venga fornito il servizio, ad esempio mostrare il motd dopo il login;
- password: necessario per l'aggiornamento dei token di autenticazione associati all'utente;
Flag indica come PAM deve comportarsi a seconda dell'esito favorevole o meno del modulo indicato. I valori ammissibili sono:
- required: in caso di fallimento per il modulo con questo control flag, all'utente non viene concesso l'accesso all'applicazione, dopo avere comunque elaborato la rimanente parte dello stack;
- requisite: in caso di fallimento il controllo viene direttamente ritornato all'applicazione, senza elaborare la restante parte dello stack;
- sufficient: in caso di successo del modulo con tale flag, verra' consentito l'accesso all'utente se nessun precedente modulo con flag required ha avuto esito sfavorevole;
- optional: come il nome lascia intendere questo flag di controllo indica moduli «opzionali», ovvero il cui esito non abbia conseguenze nel consentire o negare l'accesso all'applicazione;
Modulo consente di specificare lo shared object da utilizzare od il suo percorso completo. Se il primo carattere specificato per questo campo e' uno /, PAM cerchera' in /lib/security il modulo col nome indicato.
Argomenti e' costituito da una lista di token che debbono essere passati come parametri al modulo quando viene invocato. In caso vengano specificati parametri errati essi verranno ignorati dal modulo, che pero' registrera' un avvertimento tramite syslog. Inoltre, in caso un argomento debba comprendere degli spazi esso deve essere chiuso tra parentesi quadre.
A titolo esemplificativo, si consideri la configurazione di /etc/pam.d/other. Probabilmente sarebbe una buona idea cercare di rendere il piu' restrittivo possibile il comportamento definito da esso, poiche' dovrebbe intervenire in quelle situazioni per cui non e' gia' previsto un apposito file. Alla luce di cio' other potrebbe essere definito nella maniera seguente:
auth required pam_deny.so
auth required pam_warn.so
account required pam_deny.so
account required pam_warn.so
password required pam_deny.so
password required pam_warn.so
session required pam_deny.so
session required pam_warn.so
Tutti gli elementi dello stack hanno flag di controllo required, quindi l'esito dell'azione di ogni modulo dovra' avere esito positivo, oppure la richiesta del servizio fallira'. dopo l'elaborazione della parte residua dello stack.
Per tutti i quattro contesti auth, account, password e session vengono richiamati i moduli pam_deny e pam_warn. Il primo di essi non fa altro che negare l'accesso alla risorsa. Esso, pero', non riporta alcuna informazione nei log di sistema, a differenza di pam_warn, che registra via syslog l'utente, l'host di provenienza, il servizio richiesto ecc.
Per le applicazioni che la utilizzeranno, quindi, questa configurazione, quindi, non avra' l'effetto di non consentire alcun tipo di accesso, oltre a loggare i tentativi effettuati.
PAM - Limitare l'accesso in base all'orario
Tipo Infobox: DESCRIPTION - Skill:
Volendo, tramite l'utilizzo di PAM, e' anche possibile specificare delle limitazioni all'accesso degli utenti in base a delle fasce orarie. A titolo di esempio, si ipotizzi di volere consentire l'accesso ssh all'utente andrea solamente dalle nove di sera alle sette del mattino.
Per abilitare questo controllo, e' necessario ricorrere al modulo pam_time, aggiungendolo nel modo seguente all'interno del file /etc/pam.d/ssh:
account required pam_time.so
Una volta effettuata l'autenticazione, il modulo pam_time andra' a leggere il file /etc/security/time.conf, e secondo il suo contenuto consentira' o meno l'accesso al servizio:
ssh;*;andrea;Al2100-0700
Il significato della linea da inserire in time.conf e' quello di consentire l'accesso al servizio ssh all'utente andrea su qualsiasi terminale virtuale (*), qualsiasi giorno della settimana(Al) dalle 21:00 am alle 7:00 (2100-0700).
Per testare il funzionamento della regola, si puo' provare a connettersi al servizio al di fuori dall'orario previsto: se la configurazione e' stata eseguita correttamente il sistema dovrebbe rispondere con un Permission denied.