ago
27

Problemi risolti? Lighttpd sembra dire di si!

 

Popularity: 1% [?]



Puoi visualizzare il post originale qui.

ago
20

Redirect da HTTP su HTTPS e viceversa con Apache2

 

Popularity: 1% [?]



Puoi visualizzare il post originale qui.

ago
20

Server LAMP sulla nostra Ubuntu

 

Popularity: 1% [?]



Puoi visualizzare il post originale qui.

ago
20

Interfaccia grafica per XAMPP piattaforma di sviluppo web/database.

 

Popularity: 1% [?]



Puoi visualizzare il post originale qui.

ago
20

Go Away Scriptkiddie!!

 

Popularity: 1% [?]



Puoi visualizzare il post originale qui.

lug
28

Google inizia ad aprire Wave

 

Google ha iniziato a svelare il codice che fa parte del progetto Google Wave.

Il primo tassello è Operational Transform (OT), il meccanismo che consente a Wave di essere altamente distribuito, ed il protocollo client server. Si tratta di un “hello world” che vuole invogliare a sperimentare con questo protocollo.

Si tratta di 40 mila linee di codice rilasciate sotto licenza Apache 2.0, mentre la documentazione è stata resa disponibile sotto licenza Creative Commons.

Via | GoogleWaveDev

Popularity: 1% [?]



Puoi visualizzare il post originale qui.

lug
17

Apache + openssl = creazione di certificati per connessioni cifrate (pt.1)

 

Di recente ho dovuto configurare un web server in modo da permettere una connessione cifrata per una zona “sicura” del sito.

La prima domanda è stata: ma come lo creo un certificato? Chi me lo firma?

42-20504685

Praticamente potremmo scegliere di farcelo firmare da alcune CA (Certification Autority) vere, pagando le stesse perché certifichino che il mio sito è sicuro.

Ma io devo soltanto fare delle prove… e allora come faccio?

La risposta è openssl.

Piccola spiegazione di quello che faremo:

  • Creazione certificato e chiave CA
  • Creazione certificato e chiave Server
  • Creazione certificato e chiave Client

Per quanto riguarda il Server, lo configureremo in modo che la pagina iniziale, nonostante (https://frontend/index.html) sia consultabile da tutti, mentre la sezione https://frontend/secure sia visibile soltanto con un certificato.

Praticamente ho assunto il ruolo di CA, di server e infine anche di client (per testarlo).

Il primo passo sarà creare una chiave privata ed un certificato standard X.509 per la CA.

LATO CA

Quindi digitiamo da root:

[root@localhost ~]# openssl genrsa -des3 -out CA.key 2048

Praticamente stiamo richiedendo la generazione di una chiave privata RSA utilizzando l’algoritmo Triple DES, salvata con il nome CA.key. Di default la lunghezza è 512 bit, ma noi l’abbiamo richiesta da 2048 bit.

Durante la creazione della chiave ci verrà richiesta una “pass-phrase”. Dobbiamo assolutamente ricordarcela perché verrà richiesta ogni volta che useremo la chiave privata della CA.

Generating RSA private key, 2048 bit long modulus
..................................................................
........................+++
...............+++
e is 65537 (0x10001)
Enter pass phrase for CA.key:
Verifying - Enter pass phrase for CA.key:

Dalla chiave possiamo ora creare il certificato:

[root@localhost ~]# openssl req -new -key CA.key -x509 -days 3650 -out CA.crt

Il nostro certificato, firmato con la chiave CA.key avrà il nome CA.crt.

  • new : vuoldire nuova richiesta
  • key : specifichiamo con quale chiave firmare il certificato
  • x509 : è il formato del certificato
  • days : il tempo in giorni di validità del certificato (3650 giorni = 10 anni)
  • out : il file che conterrà il certificato

A questo punto, durante la creazione del certificato, dovremo inserire dei dati che di default sono quelli dentro le parentesi quadre:

Enter pass phrase for CA.key:
You are about to be asked to enter information that will be
incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name
or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter  . , the field will be left blank.
-----
Country Name (2 letter code) [GB]:IT
State or Province Name (full name) [Berkshire]: Italy
Locality Name (eg, city) [Newbury]: Perugia
Organization Name (eg, company) [My Company Ltd]: Company New
Organizational Unit Name (eg, section) []: CA NEW
Common Name (eg, your name or your server s hostname) []: CA NEW
Email Address []: nostra@mail.bo

NB: Abbiamo appena creato la chiave della CA e il rispettivo certificato.

LATO SERVER

Traformiamcii da SERVER e generiamo la chiave privata per il server con il nome server.key:

[root@localhost ~] openssl genrsa -des3 -out server.key 1024

Ora possiamo creare dalla chiave la RICHIESTA DI CERTIFICATO che sarà in un secondo momento elaborata dalla CA per la creazione del certificato, firmato con la chiave privata della CA.

[root@localhost ~]# openssl req -new -key server.key -out server.csr -config /usr/share/ssl/openssl.cnf

NB: con l’opzione -config dobbiamo specificare il percorso del file openssl.cnf. Nel mio caso (Scientific Linux) era contenuto in /usr/share/ssl/openssl.cnf

Enter pass phrase for server.key:
You are about to be asked to enter information that will be incorporated into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter  . , the field will be left blank.
-----
Country Name (2 letter code) [GB]: IT
State or Province Name (full name) [Berkshire]: Italy
Locality Name (eg, city) [Newbury]: Perugia
Organization Name (eg, company) [My Company Ltd]: Pava
Organizational Unit Name (eg, section) []: Web Server        
Common Name (eg, your name or your server s hostname) []:frontend/secure
Email Address []:info@miosito.it 

Please enter the following  extra  attributes to be sent with your certificate request
A challenge password []:
An optional company name []:

IMPORTANTE:  Su “Common Name” dobbiamo specificare perfettamente quale zona sarà cifrata. Se cambiamo nome al sito i semplicemente alla parte che vogliamo sia sicura, dobbiamo generare un altro certificato e specificare il nuovo hostname.
Mentre gli ultimi due campi solitamente sono lasciati vuoti.

Ora possiamo diventare di nuovo la grande CA ed elaborare la richiesta del server, firmandola con la chiave privata della CA, ottenendo così il certificato:

[root@localhost ~]# openssl x509 -req -in server.csr -out server.crt -sha1 -CA CA.crt -CAkey CA.key -CAcreateserial -days 2190
Signature ok
subject=/C=IT/ST=Italy/L=Miacittà/O=Perugia  Azienda/OU=Servizi
Web/CN=frontend/secure/emailAddress=info@miosito.it
Getting CA Private Key
Enter pass phrase for CA.key:

NB: la pass-phrase scelta per il server, dovrà essere inserita ogni volta che il servizio “httpd”  viene riavviato.
Esiste un modo per settarlo una volta in modo che venga memorizzato, ma non verrà trattato qui, ora.

LATO CLIENT

Lavoriamo ora per creare il certificato del client così da testare il server.
Creiamo prima di tutto la chiave per il cliente

[root@localhost ~]# openssl genrsa -out client.key 1024

Proseguiamo con la richiesta di certificato:

[root@localhost ~]# openssl  req -new -key client.key -out client.csr -config /usr/share/ssl/openssl.cnf

Ora trasformandoci da CA possiamo esportare il certificato del cliente in formato pem:

[root@localhost ~]# openssl x509 -CA CA.crt -CAkey CA.key -csr -in client.csr -out client.pem -days 100

Ed infine convertirlo in formato .p12 per permettere l’importazione nel browser dell’utente:

[root@localhost ~]# openssl pkcs12 -export -clcerts -in client.pem -inkey client.key -out client.p12

A questo punto il client dovrà installare il proprio certificato sul browser semplicemente importando il file “client.p12” sul browser andando sulla sezione “certificati personali” e facendo un “import”.
Il client è ora pronto a visualizzare l’intero sito, comprendente la zona “sicura”.

——————————————————————————-

Nella seconda parte, configureremo il nostro Web Server, con tanto di iptables.

Bye bye

Popularity: 1% [?]



Puoi visualizzare il post originale qui.

lug
17

Apache + openssl = creazione di certificati per connessioni cifrate (pt.2)

 

Come promesso, oggi configuriamo per bene apache, con un occhio per il firewall.

ssl_cover_logo

Iniziamo col dire che bisogna installare Apache e controllare che il modulo sia caricato.

Questo modulo è sicuramente presente, ma potrebbe essere commentato.

Lo cerchiamo nel file httpd.conf (nella mia macchina risiede in /etc/httpd/conf/httpd.conf)

#LoadModule ssl_module modules/mod_ssl.so

Se lo è, lo decommentiamo.

LoadModule ssl_module modules/mod_ssl.so

Se non fosse presente, (nel caso si usi una versione di apache < 1.3) ci basta scaricarlo e installarlo da qui.

A questo punto possiamo preoccuparci di due cose fondamentali:

  1. Trovare il file ssl.conf (per me risiede in /etc/httpd/conf.d/ssl.conf)
  2. Decidere dove dire al server su quale porta stare in ascolto

Infatti una volta trovati i file httpd.conf e ssl.conf, dobbiamo inserire soltanto su uno dei due file le porte su cui stare in ascolto.

Avendo deciso di usare soltano una connessione cifrata, quindi l’utilizzo del protocollo https, diremo al web server di rimanere in ascolto sultanto sulla porta 443 (invece della porta 80 – http).

Io ho deciso di scriverlo su httpd.conf.

#Listen 80
Listen 443

A questo punto dobbiamo soltanto decidere l’indirizzo del nostro server e creare un VirtualHost sul file ssl.conf.

Facciamo un po’ di chiarezza su questo file.

Tutto ciò che è definito all’esterno di <VirtualHost> vale per tutte le pagine, mentre ciò che è definito all’interno vale soltanto per le pagine che appartengono a quell’indirizzo.

Prima di continuare, facciamo un passo in dietro. Nella prima parte abbiamo creato i cetificati per il server e per il client che vuole entrare nel sito tramite certificato.

Per quanto riguarda il server, consiglio di mettere chiave e certificato in una cartella apposita, per esempio /etc/httpd/ssl, così da saperlo ritrovare ed utilizzare facilmente. In questa sede faremo riferimento a questa configurazione.

Scegliamo l’indirizzo per il server. Io ho usato 192.168.0.2 (originale eh???) ed editiamo il file ssl.conf in questo modo:

NameVirtualHost 192.168.0.2:443
<VirtualHost 192.168.0.2:443>
  #DI DEFAULT SU LINUX C'è QUESTA ROOT
  DocumentRoot "/var/www/html"
  SSLEngine on
  SSLOptions +StrictRequire
  <Directory />
    SSLRequireSSL
  </Directory>
  SSLProtocol -all +TLSv1 +SSLv3
  SSLCipherSuite HIGH:MEDIUM:!aNULL:+SHA1:+MD5:+HIGH:+MEDIUM
  #QUESTO è IL CERTIFICATO DEL SERVER
  SSLCertificateFile /etc/httpd/ssl/server.crt
  #QUESTA è LA CHIAVE DEL SERVER
  SSLCertificateKeyFile /etc/httpd/ssl/server.key
  #NOI VOGLIAMO CHE L'INDEX NON RICHIEDA IL CERTIFICATO
  SSLVerifyClient none
  #CERTIFICATO DELLA CA
  SSLCACertificateFile /etc/httpd/ssl/CA.crt
  #MA NELLA ZONA "https://192.168.0.2/secure"
  #VOGLIAMO CHE VENGA RICHIESTO IL CERTIFICATO
  <Location /secure>
    SSLVerifyClient require
    SSLVerifyDepth 1
  </Location>
  SSLProxyEngine off
  <IfModule mime.c>
    AddType application/x-x509-ca-cert      .crt
    AddType application/x-pkcs7-crl         .crl
  </IfModule>
  #SERVE PER IE
  SetEnvIf User-Agent ".*MSIE.*"
  nokeepalive ssl-unclean-shutdown
  downgrade-1.0 force-response-1.0
</VirtualHost>

Ora non ci resta che riavviare httpd

[root@frontend~] /etc/init.d/httpd restart

Se funziona ci chiederà la pass-phrase del server.

Ultimo accorgimento:

siccome siamo degli esperti in sicurezza dobbiamo anche settare il firewall da permettere in entrata soltanto comunicazioni sulla porta 443.

Quindi:

[root@frontend~] iptables -t filter -I INPUT -p tcp --dport 443 -j ACCEPT

A questo punto è davvero tutto.

Se avete domande… fate pure. Ciao!

PS: un grazie va anche ad akane. Il server lo abbiamo configurato insieme.

Popularity: 1% [?]



Puoi visualizzare il post originale qui.

mag
12

ModSecurity 2 per Debian Lenny

 

Per una serie di vicissitudini legate alla licenza di distribuzione, il modulo ModSecurity 2 non è stato incluso nei repository ufficiali di Debian Lenny.
Mod-Security è il componente di Apache dedicato alla sicurezza più conosciuto, tuttavia con grande dispiacere non è possibile trovarlo in forma pacchetizzata ufficiale.  Nonostante tutto, non bisogna scaricare i sorgenti per poter adoperare ModSecurity 2 su Lenny.

Fortunatamente il problema con la licenza è stato risolto, dunque con qualche compromesso è possibile ottenere libapache-mod-security2.

Scaricare i due pacchetti da http://etc.inittab.org/~agi/debian/ controllando di aver scelto l’architettura giusta tra 386, amd64, powerpc:

wget http://etc.inittab.org/~agi/debian/libapache-mod-security2/libapache-mod-security_2.5.9-1_i386.deb
wget http://etc.inittab.org/~agi/debian/libapache-mod-security2/mod-security-common_2.5.9-1_all.deb

Poi occorre installare contemporaneamente i due pacchetti di ModSecurity:

# dpkg -i mod-security-common_2.5.9-1_all.deb libapache-mod-security_2.5.9-1_i386.deb

E’ meglio creare una cartella all’interno della directory del web server:

mkdir /etc/apache2/modsecurity2
chmod 600 /etc/apache2/modsecurity2

Scaricare dal sito ufficiale di modsecurity l’insieme di regole base modsecurity-core-rules (le più aggiornate si possono trovare all’indirizzo http://www.modsecurity.org/download/)

wget http://www.modsecurity.org/download/modsecurity-core-rules_2.5-1.6.1.tar.gz

Estrarre i file contenuti nell’archivio col comando e spostare tutti i file di configurazione nella cartella appena creata di modsecurity:

tar zxvf modsecurity-core-rules_2.5-1.6.1.tar.gz
mv *.conf /etc/apache2/modsecurity2/

Creare un link simbolico:

ln -s /var/log/apache2 /etc/apache2/logs

Ora è possibile riavviare apache col comando (necessario è il riavvio perché le modifiche siano abilitate):

/etc/init.d/apache2 restart

Popularity: 1% [?]



Puoi visualizzare il post originale qui.

apr
13

La carta d identità del comune di Grosseto

 

Nel 2003 il Ministero dell’Interno ha deciso di introdurre la nuova Carta d’Identità Elettronica.

I comuni dovevano avviare e gestire il nuovo sistema locale che si basava su un software sviluppato da Società Appaltatrice per conto dello stesso ministero. Il comune di Grosseto a metà del 2008 si è reso conto delle implicazioni legate alla dipendenza del software proprietario fornito.

Il sistema avrebbe dovuto essere a costo zero per i comuni, ma la società aveva aggirato questo vincolo escludendo il plugin per internet explorer dalla fornitura. Plugin necessario per l’uso del software da parte dei cittadini su cui veniva caricato un costo agguintivo.

Come se non bastasse Società Appaltatrice aveva persino deciso di non utilizzare i protocolli SSL/TLS per la protezione delle connessioni, ma uno incompatibile con le realtà esistenti.

Per questi ed altri motivi il dipartimento IT del comune ha lanciato lo sviluppo del progetto OpenPortalGuard, una piattaforma open source per garantire al cittadino il pieno controllo ed accesso ai servizi della nuova carta.

Il progetto ha riscosso successo ed stato preso in considerazione da altre amministrazione per gestire l’autenticazione single-sing-on basata su certificati e smartcard X.509, senza imporre sui cittadini alcun vincolo sul browser o sistema operativo utilizzato.

Via | FabioMarzocca

Popularity: 1% [?]



Puoi visualizzare il post originale qui.

apr
09

CouchDb, il database non relazionale

 

CouchDB, o più precisamente Apache CouchDB, è un database server fault-tolerant e schema-free document-oriented che utilizza per il dialogo RESTful HTTP/JSON API.

Tra le caratteristiche principali citiamo repliche incrementali con gestione e risoluzione automatica dei conflitti, indicizzazione dei dati senza bisogno di uno schema fisso ed infine l’uso di JavaScript come linguaggio di interrogazione.

CouchDb è scritto in Erlang e vi si può accedere da qualsiasi ambiente sia in grado di effettuare chiamate HTTP. Ci sono molte librerie per semplificare la programmazione per i più diffusi linguaggi.

Al suo interno è disponibile un’interfaccia di gestione utilizzabile via http, che prende il nome di Futon. Per un maggior approfondimento vi rimando all’introduzione generale e tecnica.

Via | Couchdb

Popularity: 1% [?]



Puoi visualizzare il post originale qui.

mar
31

Installare bugzilla su debian

 

Popularity: 1% [?]



Puoi visualizzare il post originale qui.

mar
30

Doh! “Premature end of script headers: index.php”

 

Popularity: 1% [?]



Puoi visualizzare il post originale qui.

mar
26

Installare IlohaMail su Debian Etch

 

Oggi sto sperimentando un po di webmail da installare su server Debian.
Ho scoperto che i repository di Etch contengono IlohaMail, e quindi sufficiente eseguire il seguente comando:

apt-get install ilohamail

selezionare, quando richiesto, il server http da voi utilizzato (solitamente apache2) e dirigersi con il vostro browser di fiducia all URL seguente:

http://INDIRIZZO_IP_SERVER/IlohaMail

Se volete cambiare il default (IlohaMail) lo potete fare nel file /etc/apache2/conf.d/ilohamail

Popularity: 1% [?]



Puoi visualizzare il post originale qui.

top