OpenDS: Replication Server

Non poteva mancare in OpenDS la Replication Server. Questa permette, una volta configurata sui vari server OpenDS, di "replicare" i dati.

Inizialmente la replica veniva configurata modificando il file di configurazione config.ldif, nelle recenti build invece avviene lanciando un comando da shell:
dsreplication.

Il comando prende in input tutti i server sui quali si vuole configurare la replica, ecco un esempio (preso dal sito di OpenDS):

$ dsreplication enable \
--host1 host1 --port1 1389 --bindDN1 "cn=Directory Manager" \
--bindPassword1 password --replicationPort1 8989 \
--host2 host2 --port2 2389 --bindDN2 "cn=Directory Manager" \
--bindPassword2 password --replicationPort2 8990\
--adminUID admin --adminPassword password --baseDN "dc=example,dc=com"

La Fiera della Sicurezza Informatica

A Milano anche quest'anno dal 5 al 7 Febbraio 2008 si svolge Infosecurity, Storage Expo Italia e Trackability.

Questo e' il sito dell'evento:

http://www.infosecurity.it

Iscrivetevi in tanti... ma lasciatemi un posto! :)

OWASP Top Ten: Security Vulnerabilities

OWASP ha stilato la lista delle maggiori vulnerabilita' di sicurezza eccole:

1 - Cross Site Scripting;
2 - Injection flaws;
3 - Malicious file Execution;
4 - Insecure Direct Object Reference;
5 - Cross Site Request Forgery (CSRF);
6 - Leakage and Improper Error Handling;
7 - Broken Authentication and Sessions;
8 - Insecure Cryptographic Storage;
9 - Insercure Communications;
10 - Failure to Rescrict URL Access.

Le ESAPI, di cui accennato brevemente in un altro post (e di cui rimando comunque una lettura sul sito di OWASP) in merito a queste vulnerabilita' offrono le seguenti "soluzioni":

1 - Validator, Encoder;
2 - Encoder;
3 - HTTPUtilities (Upload);
4 - AccessReferenceMap;
5 - User (csrftoken);
6 - EnterpriseSecurityException, HTTPUtils;
7 - Authenticator, User, HTTPUtils;
8 - Encryptor;
9 - HTTPUtilities (secure cookie, channel);
10 - AccessController

ESAPI: OWASP Enterprise Security API

Uno dei problemi piu' difficili per un sviluppatore e' realizzare applicazioni "sicure".

Difficile sia perche', per quanto ci si sforzi, e' quasi impossibile scrivere un'applicazione "inespugnabile", sia perche' spesso non si sa dove guardare e cosa fare per proteggersi.
Il piu' delle volte si utilizzano framework, piattaforme per introdurre "sicurezza" nei nostri applicativi.

Le ESAPI sono delle API per la sicurezza e, come scritto sul sito di OWASP, si prefiggono il compito di fornire un' insieme di librerie facili da utilizzare, chiare per lo sviluppo di applicazioni sicure.

Rimando alla documentazione che si puo' trovare sul sito di OWASP e invito tutti a provarle.

http://www.owasp.org/index.php/ESAPI

OpenSSO build 2

In questi giorni e' uscita la versione 2 di OpenSSO che, oltre alla parte di Identity Management, include anche FAM: Federated Access Manager.
Cosa c'e' di nuovo nella build 2 di OpenSSO:

- SAMLv2 federation adapter SPI
- C SDK
- supporto per ID-FF
- Session failover
- SAMLv2 ECP
- ECP, SAMLv2, IDP proxy etc.
- OpenDS (come data store di configurazione)

Nota FAM e' il nome commerciale Sun di OpenSSO, tuttavia le build di OpenSSO (opensource) e di Fam (Sun branded) sono identiche. :)

Per chi vuole incominciare questo e' il sito dal quale cominciare:
https://opensso.dev.java.net/public/use/index.html

Tomcat Access Log

In Tomcat e' possibile configurare un log aggiuntivo, simile all'access Log di un qualsiasi Web Server. In Tomcat si chiama Access Log Valve per configurarlo bisogna modificare il file server.xml che si trova nella directory conf della nostra installazione di Tomcat.
Per abilitare il log nella sua configurazione di base e' sufficiente togliere il commento alla definizione di ValveAccessLog, per esempio:


<valve classname="org.apache.catalina.valves.AccessLogValve" directory="logs" prefix="localhost_access_log." suffix=".txt" pattern="common" resolvehosts="false"/>

Esistono due pattern definiti di default: common e combined. Tuttavia e' possibile costruirsi un pattern personalizzato, per recuperare solo le informazioni desiderate, in questo modo, per esempio:

<valve classname="org.apache.catalina.valves.AccessLogValve" directory="logs" prefix="localhost_access_log." suffix=".txt" pattern="%h %l %u %t %r %s %b %{nome_cookie}c" resolvehosts="true"/>

Per ulteriori informazioni vi consiglio questo
link.

Password Policy per gli agents

In seguito alla creazione di un agent nella console di amministrazione di OpenSSO, sotto il tab subjects, questo viene creato in OpenDS all'interno di ou=agents.
Per queste tipologie di utenze e' meglio impostare la Password Policy di Root, aggiungendo il seguente attributo:
ds-pwp-password-policy-dn = cn=Root Password Policy,cn=Password Policies,cn=config

OpenDS: Character Set Password Validator

Il Character Set Password Validator permette di definire quali set di caratteri la password dovra' contenere, per esempio: almeno un numero, un carattere minuscolo, un carattere maiuscolo ed un carattere speciale.

Per aggiungere questo Validator al nostro Password Policy bisogna prima di tutto inserire in cn=Default Password Policy il seguente attributo:
ds-cfg-password-validator-dn con questo valore cn=Character Set,cn=Password Validators,cn=config.

Poi c'e' da configurare il Password Validator secondo le proprie esigenze. Bisogna quindi andare a modificare questa configurazione cn=Character Set,cn=Password Validators,cn=config.

Nella configurazione di base OpenDS definisce un set di caratteri che devono essere contenuti nella password.
Per ogni insieme di caratteri deve essere inserito il seguente attributo, in questo modo, per esempio:
ds-cfg-character-set: 1:0123456789
ds-cfg-character-set: 1:abcdefghijklmnopqrstuvwxyz
ds-cfg-character-set: 1:ABCDEFGHIJKLMNOPQRSTUVWXYZ
ds-cfg-character-set: 1:~!@#$%^&*()-_=+[]{};:,.<>/?

Impostando questo parametro ds-cfg-allow-unclassified-characters a false si inibisce l'utilizzo, nella password, di un carattere che non e' nel precendente set di valori.

Ovviamente perche' questo validatore funzioni, come per tutti gli altri, occorre che l' attributo ds-cfg-password-validator-enabled sia true.

Configurazione Password Validators

I Password Validators sono delle regole di validazione della password. Attraverso l'utilizzo di queste validazioni e' possibile per esempio impostare che la password sia lunga almeno 8 caratteri e non piu' lunga di 20 caratteri.
In OpenDS sono disponibili, per ora, i seguenti Password Validators:

- Attribute Value;
- Character Set;
- Dictionary;
- Length-Based Password Validator;
- Repeated Characters;
- Similarity-Based Password Validator;
- Unique Characters

Per la definizione e per la descrizione dettagliata rimando al senguente link:

https://www.opends.org/wiki//page/ThePasswordValidatorConfiguration

Ecco qualche esempio di configurazione all'interno del cn=Default Password Policy.
Per inserire un Password Validator bisogna andare nella Password Policies che si vuole utilizzare, nel nostro caso, Default Password Policy e si configura il seguente attributo per ogni Validator che si vuole applicare alla password.
Per esempio:

ds-cfg-password-validator-dn: cn=Attribute Value,cn=Password Validators,cn=config
ds-cfg-password-validator-dn: cn=Character Set,cn=Password Validators,cn=config
ds-cfg-password-validator-dn: cn=Dictionary,cn=Password Validators,cn=config
ds-cfg-password-validator-dn: cn=Length-Based Password Validator,cn=Password Validators,cn=config
ds-cfg-password-validator-dn: cn=Repeated Characters,cn=Password Validators,cn=config

Una considerazione che, per alcuni sara' banale, si possono avere piu' attributi uguali, nel nostro caso ds-cfg-password-validator-dn, l'importante e' che cambi il valore. :)

Cosi' abbiamo detto che, per tutti gli utenti che hanno le Default Policy sulle password, sono applicate tutte le regole di validazione che abbiamo inserito.

Il prossimo passo consiste nel configurare il Password Validator specifico secondo le regole che ci servono. Per fare questo bisogna andare in cn=Password Validators, selezionare il Validator che vogliamo utilizzare e configurarlo. Per prima cosa bisognera' verificare che il validatore si abilitato, l'attributo ds-cfg-password-validator-enabled dovra' essere true.
Per esempio nella configurazione di cn=Attribute Value,cn=Password Validators,cn=config possiamo inserire tutti gli attributi che vogliano che non siano utilizzabili nella nostra password, questo ci permette di non inserire la password uguale al nome (givenName).
Dovra' essere inserito l'attributo ds-cfg-match-attribute con il seguente valore givenName.

OpenDS: Configurazione Password Policy

OpenDS mette a disposione un set di regole per la struttura della password. I riferimenti a tutte le funzionalita' disponibili, ad oggi, sono qui:

1) https://opends.org/wiki//page/PasswordPolicyConfiguration

2) https://www.opends.org/wiki/page/PasswordPolicyArchitecture

Qui di seguito alcuni esempi di configurazione di Password Validator. In OpenDS ci sono due Password Policies preimpostati (si trovano in cn=config):

- Default Password Policy, cn=Default Password Policy,cn=Password Policies,cn=config
- Root Password Policy, cn=Root Password Policy,cn=Password Policies,cn=config


Di default tutti gli utenti, anche l'amministratore, hanno preimpostato come Password Policy il Default Password Policy.
Per impostare un Password Policy ad hoc bisogna aggiungere questo attributo all'utente: ds-pwp-password-policy-dn. Questa operazione puo' essere fatta sul singolo utente.

Ricapitolando:
attributo= ds-pwp-password-policy-dn
valore: Custom Password Policy, cn=Root Password Policy,cn=Password Policies,cn=config

Per aggiungere le validazioni della password a tutti gli utenti, senza differenze e' sufficiente modificare la configurazione di Default Password Policy.
E' importante impostare il ds-pwp-password-policy-dn = cn=Root Password Policy,cn=Password Policies,cn=config per gli utenti amministratori e per i cn=dsame users, se si vuole continuare ad utilizzare gli utenti con cui si e' configurato OpenSSO.

OWASP

Nell'ambito della sicurezza informatica ed i temi ad esso correlati, il progetto OWASP (Open Web Application Security Project) si propone di trovare e combattere le cause di software insicuro.

Sito:
http://www.owasp.org/index.php/Main_Page


Di rilievo la top ten delle maggiori vulnerabilita' delle applicazioni web, vedi link sotto:

https://www.owasp.org/index.php/Top_10_2007

OpenSSO e OpenDS

OpenSSO come sistema di identity management con OpenDS, un repository LDAP scritto in Java.
Riferimenti utili:

OpenSSO, Open Access Open Federation
https://opensso.dev.java.net/

OpenDS
https://opends.dev.java.net/