GnuPG: Crittografia di livello militare a portata di tutti

GnuPG (Gnu Privacy Guard) è la versione Open Source del software di crittazione PGP (Pretty Good Privacy) che Bruce Schneier, crittografo, in Applied Crittography ha definito come il modo per arrivare "probabilmente il più vicino alla crittografia di livello militare". Proprio per questo motivo Zimmermann, il suo creatore, fu accusato di "esportazione di armi senza apposita licenza"; non mi sento dunque di consigliare l'utilizzo di questo programma a tutti coloro che non posseggano il porto d'armi!

GPG è uno dei programmi sviluppati dalla Free Software Foundation ed è attualmente un programma stabile e maturo, compatibile con gli standard OpenPGP, e distribuito gratuitamente insieme a buona parte delle distribuzioni Linux, oltre che con FreeBSD, NetBSD ed OpenBSD; ne esistono inoltre delle versioni per Windows e Mac OS X grazie alla portabilità del suo codice (libero). Il livello di sicurezza raggiunto da GnuPg è tale da far ritenere a molti informatici che nemmeno molte aziende governative siano in grado di decrittare documenti protetti attraverso questo sistema; ciò non toglie, però, che esistano molti altri metodi per intercettare o recuperare i files originali "sprotetti", in modo da rendere vano l'utilizzo di questo software.



GnuPG utilizza un sistema a chiave pubblica; ciò significa che ogni utente, per comunicare in sicurezza attraverso l'utilizzo della crittografia, dispone di una chiave pubblica ed una chiave privata. La chiave pubblica è utilizzata da chiunque voglia comunicare in modo sicuro con l'utente, offrendo le specifiche per criptare i files che potranno essere poi decriptati dal possessore della chiave privata. Per utilizzare GPG dobbiamo dunque generare le nostre due chiavi: apriamo un terminale e digitiamo il comando gpg --gen-key; a questo punto il programma ci chiederà che tipo di chiave vogliamo generare; il mio consiglio è quello di fare la scelta di default (DSA e ElGamal) che genera due coppie di chiavi (DSA solo per firmare; ElGamal sia per firmare che criptare/decriptare). Adesso scegliamo la dimensione della chiave (in bit): anche qui possiamo utilizzare le opzioni di default (1024 bit) che offre già un ottimo livello di sicurezza (ovviamente più lunga è la chiave, maggiore è il livello di sicurezza). Scegliamo quindi il periodo di durata della chiave (è bene impostarne uno non troppo lungo: in questo modo, se la chiave diventasse improvvisamente non più valida, dopo poco tempo risulterebbe non più utilizzabile), inseriamo i nostri dati personali, al fine di poter associare la chiave ad una persona fisica, e infine, importantissima, la passphrase: questa ci servirà per decrittare e firmare i files, dunque è importante sceglierne una abbastanza sicura.

Creata la nostra chiave è importantissimo generare un certificato di revoca, che ci consente di invalidare la propria chiave qualora essa diventasse inutilizzata, compromessa, etc... Per farlo digitiamo in un terminale gpg --output revoca.asc --gen-revoke mia_chiave in cui mia_chiave rappresenta uno specificatore di chiave ossia l'ID associato alla coppia di chiavi generate o un qualsiasi altro campo del proprio User ID indicato durante la creazione delle chiavi. In questo caso il certificato di revoca viene memorizzato nel file revoca.asc: è importantissimo tenere questo file al sicuro in quanto chiunque, avendone accesso, potrebbe rendere inutilizzabile la propria chiave pubblica. Qualora si presentasse la necessità di revocare la chiave adesso potremmo dunque farlo pubblicando il nostro certificato di revoca.

Adesso non ci resta che la parte migliore! Utilizzando il comando gpg --list-keys possiamo visualizzare tutte le chiavi pubbliche presenti nel nostro portachiavi (ovvero le chiavi pubbliche memorizzate per un utilizzo futuro); per esportare una qualsiasi chiave presente nel nostro portachiavi pubblico basta utilizzare l'opzione export in questo modo: gpg --output chiave.gpg --export user_id dove user_id è un qualsiasi ID della chiave da esportare. Per rendere più "sicura" l'esportazione delle chiavi possiamo aggiungere l'opzione --armor al comando appena analizzato.

Per importare una chiave, invece, possiamo utilizzare l'opzione --import in questo modo: gpg --import gino.gpg; verifichiamo l'avvenuta importazione della chiave attraverso l'utilizzo di gpg --list-keys. Verificata la presenza di un ipotetico "Gino" nel nostro mazzo di chiavi, adesso abbiamo la possibilità di comunicare con lui attraverso la comunicazione crittata. Prima però controlliamo il fingerprint (le "impronte digitali") delle nostre chiavi, assicurandoci che ad ogni chiave corrisponda l'effettivo proprietario attraverso il comando gpg --fingerprint. A questo punto possiamo validare anche noi la chiave (se siamo realmente sicuri che a quella chiave corrisponda l'effettivo possessore) entrando nel menu di edit della chiave: attraverso gpg --edit-key user_id possiamo modificare in vari modi la chiave presa in esame. Attraverso il comando sign validiamo la chiave in editing, con check possiamo leggere le altre firme presenti nella chiave, con help visualizziamo una veloce schermata di aiuto, con q usciamo dal sottomenu.

Adesso, per cifrare un documento, ci basterà disporre della chiave di un utente nel nostro portachiavi pubblico, e poi dare via terminale il comando gpg --output filecifrato --armor --encrypt --recipient user_id dove user_id è ancora una volta l'ID del destinatario. In questo modo, soltanto il possessore della chiave privata relativa a quell'user_id potrà decriptare il "filecifrato". Per decriptare un file criptato attraverso l'uso della nostra chiave pubblica, invece, basta utilizzare gpg --output filedecifrato -d filecifrato ed immettendo quindi la propria passphrase.

Per cifrare i propri file firmandoli, invece, possiamo utilizzare gpg --output filefirmato --sign filedafirmare; se invece si presentasse la necessità di firmare un file lasciandolo "in chiaro" potremmo alternativamente usare gpg --clearsign filedafirmare o gpg --output firma.sig --detach -sign fileoriginale nel caso in cui volessimo salvare la firma in un file separato da quello originale. Per verificare la firma, in quest'ultimo caso, useremo gpg --verify firma.sig fileoriginario, mentre negli altri casi andrà benissimo gpg --verify filefirmato e, nel caso in cui il file sia anche cifrato, potremo decifrarlo attraverso il comando di decifrazione "standard" prima incontrato.

Per ulteriori informazioni circa l'utilizzo di GnuPG potete facilmente consultare:

• La guida ufficiale completa in formato HTML o scaricabile/visualizzabile in PDF;


• Le Man Pages, disponibili in inglese digitando man gpg in un terminale, o alternativamente seguendo questo link.

Mi sembra comunque di rilevante interesse segnalare che esistono dei frontend grafici per l'utilizzo "facilitato" di gpg: Seahorse per GNOME e Kgpg per KDE. Entrambi i programmi sono disponibili nei repository stabili della quasi totalità delle distribuzioni!

Fonti:

http://kikuchi.altervista.org/resources/gnupg/index.htm - shogoki.it; Sito ufficiale di Salvatore La Bua.

http://www.gnupg.org/gph/it/ - Guida ufficiale a gnupg.

http://it.wikipedia.org -It.wikipedia.

Impostare un editor di testo predefinito nella shell BASH

Introduzione

Chi di noi che usiamo il Sistema Operativo GNU/Linux non ha mai avuto a che fare con la shell BASH? Beh credo nessuno! La shell BASH è la fedele amica di tutti gli utenti GNU/Linux . Cosa è la shell BASH? Per chi non lo sapesse la shell è un interprete di comandi di tipo testuale; i comandi digitati dall'utente sono letti dalla shell, interpretati e inviati al kernel per essere eseguiti. Dalla shell possiamo avviare i nostri programmi e supporta inoltre una miriade di caratteristiche indispensabili per chi lavora su sistemi GNU/Linux, quindi è fondamentale settare correttamente il suo file di configurazione.



Configurazione

Il file di configurazione della shell bash si trova nella nostra directory personale di utente ossia in /home/tuoutente, ma essendo un file molto delicato per il corretto funzionamento del nostro sistema è stato nascosto, come sappiamo tutti, nei sistemi di tipo GNU/Linux ai file nascosti viene anteposto un punto "." , quindi il nostro file di configurazione della shell è il noto .bashrc .

Adesso impostiamo un editor di testo predefinito per la shell di BASH, cioè la shell di BASH userà sempre e solo l'editor da noi impostato per modifare i file vediamo come, intanto editiamo il file .bashrc così:

nano -w /home/tuoutente/.bashrc

una volta aperto il nostro .bashrc aggiungiamo in fondo al file la riga:

[bash]export EDITOR=nano[/bash]

poi diamo ctrl+x salviamo e chiudiamo. Ovviamente potete mettere l'editor di testo che preferite tra i tanti disponibili come vim, emacs etc.., io preferisco l'editor nano per la sua facilità d'uso direi molto intuitiva, pulita e semplice, senza nulla togliere ad editor molto potenti come vim ed emacs.

Adesso chiudiamo la nostra shell BASH ed alla riapertura della shell diamo il comando:

. /home/tuoutente/.bashrc

il tutto ovviamente per rendere effettive le nostre modifiche alla shell BASH.

Buon divertimento ^_^

Configurare SSH

Bentrovati! Oggi vi parlo di come configurare SSH!

Bene se avete una Debian tra le mani (tutti avete installato Debian vero?) potete tranquillamente installare SSH digitando da root aptitude update e aptitude install ssh che provvederà ad installare automaticamente il daemon SSH che fungerà da Server.

Adesso che è installato i troviamo i files di configurazione in /etc/ssh e quello che dobbiamo modificare per configurare in modo corretto il nostro Server SSH è /etc/ssh/sshd_config , quindi apriamolo col nostro editor di testo preferito e cominciamo a spulciarlo.



Port 22

Di default viene aperta la porta 22 per questioni di sicurezza e per evitare si essere trovata da un portscan occasionale è consigliato cambiarla possibilmente scegliendone una superiore alla 1024, in quanto fino alla 1024 sono riservate per servizi noti.

ListenAddress 0.0.0.0

Di default è 0.0.0.0 che indica l'ascolto in tutte le interfacce di rete configurate e tutti gli indirizzi IP associati, pertanto è utile cambiarlo con l'indirizzoIP specifico nel quale ci si aspettano connessioni

HostKey /etc/ssh/ssh_host_key

Specifica la posizione che contiene le chiavi private di un host e può essere lasciato il valore di default. Possono essere specificati più files ripetendo HostKey e cambiando il file di destinazione

Protocol 2

Indica il protocollo da utilizzare. Possono essere indicati 1 o 2 o entrambi separandoli con la virgola (1,2), tuttavia non è consigliato permettere connessioni con il protocollo 1

UsePrivilegeSeparation yes

yes è il valore di default, e indica che per ogni login viene creato un processo figlio con i privilegi dell'user che ha effettuato il login per evitare tecniche di "privilege escalation" basati sui privilegi dei processi

ServerKeyBits 1024

Dice quanti bit devono essere utilizzati perla creazione della chiave di criptazione della connessione. Si preferisce di solito utilizzare 1024 che è un buon compromesso tra velocità ed efficacia di crittazione.

LoginGraceTime 120

Rappresenta il tempo massimo in secondi che intercorre tra il momento in cui viene stabilita la connessione e quello in cui avviene un login con successo.

KeyRegenerationInterval 3600

Rappresenta il massimo tempo in secondi che il demone aspetta prima di rigenerare una nuova chiave per la connessione corrente e non deve essere eccessivamente elevato per evitare il cracking della chiave utilizzata nella sessione corrente

PermitRootLogin no

In genere di default è impostato su yes ma è altamente sconsigliato permettere ad un utente di effettuare il login remoto come root; è molto più sicuro far si che si effettui un login come normal user e da li guadagnare i permessi di root.

IgnoreRhosts yes

Dichiara di ignorare i files rhosts e shosts per l'autenticazione.

IgnoreUserKnownHosts yes

Dice al daemon di ignorare la lista degli hosts conosciuti presente in $HOME/.ssh/known_hosts durante la RhostsRSAAuthentication.

StrictModes yes

Questo serve per proteggere i files nelle home degli user che di solito vengono lasciati "world-writable".

X11Forwarding no

Ci permette di disabilitare o abilitare il forwarding su X11. Se non abbiamo una GUI installata nel server (di solito è così possiamo settarlo su no.

PrintMotd yes

Abilita la visualizzazione di /etc/motd a login avvenuto.

IgnoreUserKnownHost yes

Si ignora l'utilizzo si ~/.ssh/known_host e per il login ci si basa unicamente su user e password

SyslogFacility AUTH

LogLevel INFO

Ci indica il grado di prolissità dei log. I valori possibili sono QUIET, FATAL, ERROR, INFO, VERBOSE, DEBUG, DEBUG1, DEBUG2, DEBUG3. Utilizzare un flag di DEBUG viola la privacy degli utenti pertanto non è consigliato

RSAAuthentication yes

Indica se sono concessi i login con solo RSA

PasswordAuthentication yes

Indica se utilizzare come metodo di accesso le password o meno

PermitEmptyPasswords no

Non permette i login senza user o senza password

AllowUsers user1 user2

Permette il login via SSH solo agli user specificati. Da notare che gli user sono separati da spazi vuoti, quindi niente virgole o punto o altro

AllowGroups group1 group2

Permette il login via SSH solo ai gruppi specificati. Da notare che i gruppi sono separati da spazi vuoti, quindi niente virgole o punto o altro

Bene, fatta questa panoramica abbastanza ampia sul file id configurazione del demone SSH vi propongo la configurazione del mio server.

# What ports, IPs and protocols we listen for

Port 1001

# Use these options to restrict which interfaces/protocols sshd will bind to

#ListenAddress ::

ListenAddress 192.168.1.4

Protocol 2

# HostKeys for protocol version 2

HostKey /etc/ssh/ssh_host_rsa_key

HostKey /etc/ssh/ssh_host_dsa_key

#Privilege Separation is turned on for security

UsePrivilegeSeparation yes

# Lifetime and size of ephemeral version 1 server key

KeyRegenerationInterval 3600

ServerKeyBits 1024

# Logging

SyslogFacility AUTH

LogLevel INFO

# Authentication:

LoginGraceTime 120

PermitRootLogin no

StrictModes yes

RSAAuthentication yes

PubkeyAuthentication yes

#AuthorizedKeysFile %h/.ssh/authorized_keys

# Don't read the user's ~/.rhosts and ~/.shosts files

IgnoreRhosts yes

# For this to work you will also need host keys in /etc/ssh_known_hosts

RhostsRSAAuthentication no

# similar for protocol version 2

HostbasedAuthentication no

# Uncomment if you don't trust ~/.ssh/known_hosts for RhostsRSAAuthentication

IgnoreUserKnownHosts yes

# To enable empty passwords, change to yes (NOT RECOMMENDED)

PermitEmptyPasswords no

# Change to yes to enable challenge-response passwords (beware issues with

# some PAM modules and threads)

ChallengeResponseAuthentication no

# Change to no to disable tunnelled clear text passwords

PasswordAuthentication yes

# Kerberos options

#KerberosAuthentication no

#KerberosGetAFSToken no

#KerberosOrLocalPasswd yes

#KerberosTicketCleanup yes

# GSSAPI options

#GSSAPIAuthentication no

#GSSAPICleanupCredentials yes

X11Forwarding no

X11DisplayOffset 10

PrintMotd no

PrintLastLog yes

TCPKeepAlive yes

#UseLogin no

#MaxStartups 10:30:60

#Banner /etc/issue.net

# Allow client to pass locale environment variables

AcceptEnv LANG LC_*

Subsystem sftp /usr/lib/openssh/sftp-server

UsePAM yes

AllowUsers art3k

AllowGroups chrooted


Configurazione dei Virtual Hosts (alias) con Apache2 su Debian ETCH

Premessa

Questo tutorial non intende in nessun modo sostituire la reference ufficiale di Apache, per cui descrizioni dettagliate delle singole parti dei files di configurazione possono essere trovate nel sito ufficiale di Apache.

Introduzione

Nella guida precedente abbiamo parlato dell'installazione e la configurazione di un server LAMP con Debian, Apache2, MySQL e PHP, passiamo adesso alla configurazione dei singoli virtual hosts (ovvero degli hosts virtuali).

Il VirtualHosting consente la gestione di più domini basandosi sul loro nome ma non sul loro IP ed è una pratica ampiamente utilizzata in quanto è facile immaginare il gap di guadagno semplicemente immaginando il costo di una farm costituita da una serie di server che ospitano ciascuno un dominio diverso ed un solo server che ospita diversi domini diversi. L'unico appunto che può essere fatto a questa metodologia di gestione è che effettivamente se si ha un dominio molto attivo esso potrebbe monopolizzare le risorse di sistema lasciando solo la rimanenza delle risorse agli altri domini hostati difatti questo tipo di configurazione abitualmente è utilizzata per ospitare domini che non generano traffico eccessivo.

Se avete seguito la guida sull'installazione e la configurazione di un server LAMP con Debian non è necessario altro infatti l'intento di questo tutorial è dare le basi per la configurazione dei virtual hosts.

Per prima cosa prendiamo nota della DocumentRoot impostata nel file di configurazione di Apache2 digitando:

cat /etc/apache2/apache2.conf | grep DocumentRoot

di default la DocumentRoot è /var/www e utilizzerò questo riferimento nel resto del tutorial, tuttavia può essere facilmente modificata editando /etc/apache2/apache2.conf cercando la riga contenente DocumentRoot (per esempio con vim vi basterà digitare /DocumentRoot ) e modificando il percorso (ricordatevi che dovete creare la directory interessata prima di procedere al riavvio di apache tramite il comando /etc/init.d/apache2 reload ).

Cerchiamo di configurare l'ambiente per un dominio generico che con un po' di fantasia chiameremo miodominio.com . Adesso che conosciamo la nostra DocumentRoot possiamo creare una directory al suo interno:

mkdir /var/www/miodominio.com

che non renderemo pubblica ed una directory public che invece renderemo pubblica per cui:

mkdir /var/www/miodominio.com/public

creiamo anche una directory che useremo per l'utilizzo degli script CGI e vedremo in seguito come utilizzarla:

mkdir /var/www/miodominio.com/cgi-bin

e quindi procediamo con la creazione del file di configurazione per il dominio che vogliamo configurare, quindi creiamo e cominciamo a compilare il file suddetto col comando

vim /etc/apache2/sites-available/miodominio.com

inserendovi il seguente testo che analizzeremo riga per riga:

<VirtualHost *:80 >

ServerAdmin webmaster@miodominio.com

ServerName www.miodominio.com

DocumentRoot /var/www/miodominio.com/public

Alias /phpmyadmin "/usr/share/phpmyadmin"

<Directory "/var/www/miodominio.com/public">

Order Deny,Allow

Allow from all

Options -Indexes

</Directory>

<Directory "/var/www/miodominio.com/cgi-bin">

AllowOverride None

Options ExecCGI -MultiViews +SymLinksIfOwnerMatch -Indexes

Order allow,deny

Allow from all

</Directory>

ErrorLog /var/log/apache2/error_miodominio.net.log

LogLevel warn

CustomLog /var/log/apache2/access_miodominio.net.log combined

ServerSignature On

</VirtualHost>

procediamo all'analisi della configurazione riga per riga:

<VirtualHost *:80 >

è il tag che indica che devono essere processate le richieste indirizzate alla porta 80 (che comunque è quella di default) di tutti gli IP configurati nella macchina

ServerAdmin webmaster@miodominio.com

serve per indirizzare correttamente le richieste di supporto in caso di errori (pagine mancanti, richieste con accesso negato, ecc)

ServerName www.miodominio.com

viene utilizzato per configurare il nome di dominio da gestire e che lo distinguerà dagli altri

DocumentRoot /var/www/miodominio.com/public

ci dice in quale directory saranno indirizzate le richieste di connessione per il nome di dominio specificato nella riga precedente ed è anche la directory che quindi dovrebbe contenere l'index

Alias /phpmyadmin "/usr/share/phpmyadmin"

in questo modo impostiamo un alias di dominio ovvero digitando sul browser www.miodominio.com/phpmyadmin verremo indirizzati a quella directory che contiene il software phpmyadmin e quindi potremo amministrare il database

<Directory "/var/www/miodominio.com/public">

con questo tag cominciamo la configurazione dei permessi della directory public

Order Deny,Allow

definisce l'ordine di processamento dei permessi; nella fattispecie prima le negazioni di servizio (nel caso ci dovessero essere) e poi gli accessi

Allow from all

siccome nel nostro esempio non ci preoccupiamo di negare l'accesso in quanto vogliamo che il sito sia perfettamente accessibile dall'esterno consentiamo l'accesso a tutti

Options -Indexes

serve per restituire un messaggio di errore se nella directory nella quale si tenta l'accesso non è presente un file index , ciò serve per evitare di rendere pubblico materiale al quale non sono presenti collegamenti diretti

</Directory>

chiude il tag aperto poco prima

<Directory "/var/www/miodominio.com/cgi-bin">

con questo tag cominciamo a configurare la directory che conterrà gli script cgi

AllowOverride None

con questa opzione diciamo esplicitamente ad apache di non leggere il file .htaccess anche se presente perchè di fatto in questa directory non serve

Options ExecCGI -MultiViews +SymLinksIfOwnerMatch -Indexes

la descrizione di questa direttiva è un po' più lunga delle altre perchè ci sono un paio di opzioni di cui parlare (rimando al sito ufficiale per la documentazione dettagliata ed in inglese). Con ExecCGI consentiamo l'esecuzione di scripts CGI se è abilitato il modulo mod_cgi; con -MultiViews facciamo in modo che quando viene richiamata tramite browser la directory /var/www/miodominio.net/cgi-bin/qualcosa e questa directory non esistesse apache NON (vedi il - antecedente l'opzione) cerca un qualunque file in /var/www/miodominio.net/cgi-bin/ del tipo qualcosa.* ; con +SymLinksIfOwnerMatch facciamo in modo che Apache segua i links simbolici di sistema contenuti in questa directory solo se il proprietario del file o della directory di destinazione è lo stesso utente proprietario del link ; la -Indexes l'abbiamo vista prima

Order allow,deny

Allow from all

</Directory>

queste tre righe le abbiamo analizzate prima

ErrorLog /var/log/apache2/error_miodominio.net.log

questa riga serve per specificare il file in cui scrivere gli errori di apache che vengono riscontrati dagli utenti in fase di navigazione; è bene impostare un nome di questo file diverso per ogni dominio per facilitarne la lettura

LogLevel warn

con questa opzione dichiariamo il livello "verbosità" dei log e possiamo scegliere tra debug, info, notice, warn, error, crit, alert, emerg

CustomLog /var/log/apache2/access_miodominio.net.log combined

questa direttiva serve per tenere traccia delle richiesta al server apache

ServerSignature On

indica al server di includere la "firma" nel footer dei messaggi di errore, che include il nome del server ed il tipo di sistema operativo che si sta utilizzando

</VirtualHost>

questa indica la chiusura del tag VirtualHost

Per abilitare finalmente il nostro dominio sul server bastano due soli comandi

a2ensite miodominio.com

/etc/init.d/apache2 reload

col primo abilitiamo il nostro dominio creando un symlink a /etc/apache2/sites-available/miodominio.com in /etc/apache2/sites-enabled/miodominio.com e per disabilitarlo possiamo utilizzare i comandi

a2dissite miodominio.com

/etc/init.d/apache2 reload

ricordiamo sempre di ricaricare la cache di configurazione di apache ogni volta che viene modificato un file di configurazione.

Fatto ciò se i DNS sono aggiornati il nuovo sito sarà raggiungibile all'indirizzo www.miodominio.com.

WebServer LAMP (Linux, Apache 2, MySQL 5 e PHP 5) su Debian ETCH

Introduzione

Cosa è un "server LAMP"?

Nonostante molti di voi sperano che sia qualcosa di commestibile ahimè le vostra speranze stanno per crollare.. (per la cronaca.. non ha nemmeno a che fare con l'illuminazione della vostra scrivania).

Un server LAMP è quello che comunemente viene chiamato Webserver e consiste nell'installazione di software per la visualizzazione di pagine web e gestione dinamica di database; nello specifico LAMP sta per Linux, Apache, MySQL and PHP il che ci da un'idea su quali sono i software che servono per la realizzazione di server di questo tipo.

Linux bhè... è GNU/Linux... leggendo il resto del blog capirete da soli di che si tratta!

Apache è un daemon ovvero un programma che gira in background e serve per supportare connessioni di tipo HTTP ((HyperText Transfer Protocol)) che sarebbe il protocollo che generalmente si utilizza per la navigazione su internet e ci permette di vedere sul nostro Browser le pagine HTML ((HyperText Markup Language)) avete presente quella estensione che a volte si vede alla fine dell'URL?

PHP ha una definizione che viene detta ricorsiva perché nella stessa definizione viene ripetuto il termine PHP ed infatti sta per "PHP Hypertext Preprocessor" e consente ai webmaster di creare webapplications e pagine dinamiche in quanto è un vero e proprio linguaggio di programmazione (volendo anche ad aggetti) che viene interpretato dal motore Zend.

MySQL è il DataBase ovvero una specie di BancaDati più nello specifico è un software che ci permette di amministrare agevolmente dati disposti in tabelle tramite l'esecuzione di query.

Ingredienti

1.Debian 4.0 (ETCH)

2.Un editor di testo da linea di comando visto che probabilmente ci lavoreremo da remoto (consiglio vivamente VIM)

3.Un po' di pazienza

Installazione dell'ambiente

Passiamo al sodo.

Verifichiamo il contenuto di /etc/apt/sources.list e vediamo se sono presenti i seguenti mirror:



##ETCH (Stable)

deb http://ftp.it.debian.org/debian/ etch main contrib non-free

deb-src http://ftp.it.debian.org/debian/ etch main contrib non-free

##SECURITY UPDATES (Etch)

deb http://security.debian.org/ etch/updates main contrib non-free

deb-src http://security.debian.org/ etch/updates main contrib non-free

e diamo un bel

aptitude update

e poi

aptitude upgrade

Da root (ormai tutti sapete chi è root vero?) digitiamo:

apt-get install apache2 apache2-mpm-prefork php5-mysql mysql-server php5 libapache2-mod-php5 php5-cgi php5-gd php5-cli phpmyadmin

Durante la fase di installazione apt vi chiederà delle cose come:

Should MySQL start on boot? (Il server MySQL deve essere lanciato in fase di avvio?)

Io consiglio di selezionare SI in modo da avere il database sempre funzionante nonostante il server venga riavviato.

Facendo ciò la nostra cara Debian GNU/Linux box installerà Apache2, PHP5, MySQL5 e vari moduli per Apache e PHP per interfacciarsi tra di loro e col database.

Se pensate che sia finita qui (nonostante gran parte del lavoro sia gi?à stato fatto) vi sbagliate di grosso! Adesso comincia il bello!

Configurazione

Configurazione di Apache2

Aprite il file /etc/apache2/apache2.conf con VIM scrivendo sempre da root:

vim /etc/apache2/apache2.conf

e digitate "I" per passare alla modalità di inserimento del testo e scrivete nell'ultima riga:

ServerName localhost

per scrivere i cambiamenti ed uscire premete il tasto Esc e scrivete:

:wq

la lettera w indica a VIM di scrivere le modifiche ed il comando q gli dice di uscire dopo averlo fatto; mi raccomando i : prima di wq.

Adesso che avete capito penso/spero quali sono le funzioni base di VIM mi limiterò a dire "scrivete" e "salvate".

Le directory che vi serviranno per l'amministrazione sono:

/var/www che è impostata di default come webroot (vedremo in seguito come cambiarla)

/etc/apache2 che contiene i files di configurazione di apache2

/etc/apache2/sites-enabled e che contiene una serie di links simbolici ai files di configurazione degli hosts virtuali che si trovano in /etc/apache2/sites-available

Dei comandi utili per la gestione di apache sono:

/etc/init.d/apache2 start

/etc/init.d/apache2 stop

/etc/init.d/apache2 restart

che rispettivamente lancia, ferma, riavvia il demone apache2 .

E' utile anche abilitare alcuni moduli tra cui ssl e rewrite per cui scriviamo sul trminale da root:

a2enmod ssl rewrite

e poi riavviare il daemon digitando:

/etc/init.d/apache2 restart

Configurazione di MySQL

Adesso ci occupiamo di cambiare la password dell'utente root di MySQL scrivendo da root:

mysqladmin -u root password <lamiapassword>

ovviamente sostituendo <lamiapassword> con la vostra password preferita.

Spero che sia inutile dirvi di utilizzare caratteri maiuscoli e minuscoli, numeri e caratteri speciali come "@#][.," ecc..

Ritengo sia utile creare al volo un utente (diverso da root) da poter far accedere al database con privilegi limitati, ma lo vedremo tra un po'.

Dei comandi utili per la gestione del DataBase abbiamo:

/etc/init.d/mysql start

/etc/init.d/mysql stop

/etc/init.d/mysql restart

che rispettivamente, guarda un po', lancia, ferma e riavvia il daemon MySQL.

Varie

Da notare che durante l'installazione è stato installato anche phpmyadmin (l'ultima parola inserita nel comando che vi ho detto prima) che se volete potete anche omettere. PhpMyAdmin è uno script in php che serve per la gestione "grafica" del database MySQL senza aver bisogno dell'accesso via terminale alla macchina.

Test

Se avete eseguito correttamente i passi precedenti puntate il vostro browser preferito (spero si tratti di Iceweasel) su

http://<indirizzolocaledelserver>/phpmyadmin

dove <indirizzolocaledelserver> dovrebbe essere qualcosa del tipo: 192.168.1.2 e dovreste vedere lo script phpmyadmin in esecuzione che vi chiede username e password (Username: root e Password: quellacheavetesceltoprima).

Se per caso vi si dovesse aprire una finestra di download per un file probabilmente avete sbagliato qualcosa nei passi precedenti per cui consiglio di rivedere accuratamente la guida.

Una volta eseguito il login da root prendete dimestichezza con la grafica e tornate nella home di phpmyadmin quindi aggiungete un utente cliccando su "Privilegi" e poi su "Aggiungi nuovo utente" e seguite le indicazioni per completare la procedura.

Da ora in poi vi consiglio vivamente di utilizzare il nuovo utente per effettuare gli accessi al database.

Nella prossima guida parlerò della configurazione nel dettaglio dei files degli hosts in Apache2 (che per intenderci sono quelli contenuti in /etc/apache2/sites-available)

Installazione di shroudBNC con supporto SSL su un sistema Debian GNU/Linux

Introduzione

In questa guida vedremo come installare shroudBNC, l'ormai noto bouncer (abbrev. BNC).

I bouncer per la rete IRC, solitamente, vengono installati su server remoti, e la loro principale funzione è quella di mascherare l'indirizzo IP di chi si collega ad uno dei tantissimi server di IRC, sostituendo il proprio IP proprio come fa un proxy.

Perché tutto questo? Principalmente per proteggere la vostra privacy, ma soprattutto per prevenire i tanto temuti attacchi DoS (Denial-of-Service). Oltre a questo il bouncer su un server remoto vi permetterà di stare collegati sui vostri network IRC preferiti 24h su 24h.

Sperando di avervi fatto capire in poche parole cosa sia un bouncer, credo sia arrivato il momento del via!

Installazione

Vediamo intanto i pacchetti necessari per l'installazione di shroudBNC sulla nostra macchina Debian GNU/Linux. Per installarli lanciate da root:

apt-get install tcl8.4 tcl8.4-dev make gcc g++ openssl libssl-dev

Solitamente chi fornisce questi servizi su server remoti ha già installati questi pacchetti.

Fatte queste necessarie premesse, entriamo nel cuore operativo dell'installazione.

Dopo aver eseguito il login sul nostro server remoto, tramite SSH o altre shell remote, ed essere entrati nella nostra directory di utente con il semplice comando:

cd /home/tuadirectory

possiamo scaricare dal web il nostro shroudBNC eseguendo il comando:

wget http://mirror.shroudbnc.info/sbnc-1.2.tar.gz

Una volta terminato il download sarà necessario scompattare il nostro file così:

tar xvfz sbnc-1.2.tar.gz

Dopo aver scompattato, spostiamoci dentro la directory appena creata con:

cd sbnc-1.2/

e lanciamo il comando necessario per l'installazione di shroudBNC con il supporto per SSL

./configure --enable-ssl

seguito da:

make

e da:

make install

Fatto ciò spostiamoci nella cartella sbnc con il comando

cd ~/sbnc/

Primo avvio e configurazione

Terminata l'installazione, è arrivato il momento della configurazione del nostro shroudBNC

./sbnc

Ci verrà chiesto di inserire la porta sulla quale lavorerà il nostro BNC, ossia:

Which port should the bouncer listen on (valid ports are in the range 1025 - 65535):

dopodiché ci verrà chiesto di inserire l'identd

What should the first user's name be?

e la password associata all'identd

Please enter a password for the first user:

Please confirm your password by typing it again:

Ricordateli perché con questi dati accederete a shroudBNC, e sono gli stessi che imposterete sul vostro client IRC.

Configurazione delle chiavi SSL

Terminato l'inserimento, è giunto il momento di abilitare l'SSL per collegarci al nostro shroudBNC. Modifichiamo intanto il file sbnc.conf così:

nano -w sbnc.conf

sostituiamo la voce system.port con system.sslport

salviamo e chiudiamo con CTRL-X

Fatto ciò è necessario generare il nostro certificato SSL; per fare ciò utilizziamo tre semplici comandi:

openssl genrsa -des3 -out sbnc.key 2048

ci verrà richiesto di inserire una passphrase. Inseriamo una passphrase facile da ricordare, ma difficile da indovinare per eventuali malintenzionati

openssl rsa -in sbnc.key -out sbnc.key

Reinseriamo la passphrase precedente, e per terminare:

openssl req -new -x509 -days 3600 -key sbnc.key -out sbnc.crt

Qui ci verrà chiesto di inserire alcuni dati relativi al certificato SSL. Potete tranquillamente accettare con il tasto INVIO senza inserire nulla per tutte le successive richieste.

Secondo avvio e primi settaggi

Terminato il tutto, e sperando di non aver commesso errori nei passi precedenti, possiamo avviare il nostro shroudBNC impartendo il comando

./sbnc

Perfetto! Il nostro shroudBNC è attivo e funzionante! Adesso basta aprire il nostro client ed inserire i corretti parametri per la connessione al BNC.

Una volta collegati al BNC ci verrà chiesto di settare un server IRC al quale connetterci. In ogni caso, vi consiglio caldamente di creare un utente diverso da quello di amministrazione per accedere ai vari server IRC, e di lasciare l'user di amministrazione libero.

Per avere una panoramica esaustiva di tutti i comandi disponibili con shroudBNC, basta eseguire il comando /sbnc help dal vostro client IRC. Quindi creiamo velocemente il nostro nuovo user rispettando la sintassi:

/sbnc adduser <username> [password]

dove username sarà il nostro identd e non il nickname (attenzione!!), e la password ovviamente relativa all'user creato. Impostiamo questi parametri su una nuova scheda server del vostro client ed accediamo. Una volta aver effettuato il login digitiamo:

/sbnc set server host.deltuoserver.irc numeroporta

(es: /sbnc set server calvino.freenode.net 6667)

Aspettiamo i 120 secondi necessari affinchè shroudBNC si colleghi al server e joinate i vostri canali preferiti!

Buon divertimento!

Installazione dei plugin e script per il riavvio automatico di shroudBNC

Eccoci qui dopo aver visto come installare e fare le configurazioni iniziali del nostro shroudBNC, passiamo all'installazione di un plugin e di un utile script; procediamo con ordine, ed iniziamo con l'installazione del nostro plugin ossia nickserv.tcl, ma è corretto prima di partire con l'installazione capire perché usare questo plugin e cosa fa.

Sappiamo tutti cosa è un server IRC e qual è il suo scopo, ma non tutti sanno che su alcuni network di IRC vengono messi a disposizione degli utenti del network dei servizi utilissimi ad esempio ChanServ, che controlla le registrazioni nei canali e le informazioni di accesso, oppure MemoServ, che tiene traccia dei memos personali, dei canali oppure globali mandati dall'admin del server IRC al quale si è connessi e fra tutti questi servizi messi a disposizione di un server IRC c'è anche il nostro NickServ.



A cosa server NickServ?

Con NickServ è possibile registrare il proprio nickname associandolo ad una password, così da essere identificati ed evitare che qualcun altro si appropri del nostro nickname ed inoltre con NickServ è possibile ottenere delle informazioni anche sui nickname degli altri utenti registrati sul server. Bene, capito cosa è ed a cosa serve il NickServ passiamo all'installazione del nostro plugin.

Installazione del plugin

Per installare nickserv.tcl sul nostro shroudBNC è necessario effettuare il login al server e lanciare sul terminale:

wget --output-document=~/sbnc/scripts/nickserv.tcl http://khobbits.net/sbnc/sbnc/nickserv.tcl

Una volta scaricato il plugin nella directory scripts di shroudBNC è necessario attivarlo quindi modifichiamo il file sbnc.tcl, quindi diamo:

nano -w /home/tuoutente/sbnc/sbnc.tcl

ed aggiungiamo alla fine del file la riga:

source "scripts/nickserv.tcl"

poi ctrl+x chiudiamo e salviamo

Fatto questo torniamo al nostro client IRC connesso al BNC e diamo:

/sbnc tcl :rehash

per ricaricare tutti i plugin disponibili.

Configurazione

Bene adesso il plugin è disponibile e se si da un /sbnc help sempre dal client IRC si nota la presenza della voce nickserv, adesso non bisogna far altro che impostare il plugin per ogni singolo user del nostro shroudBNC e per far ciò basta dare i comandi:

/sbnc nickserv set reply ns

/sbnc nickserv set nick <tuonick>

/sbnc nickserv set password <tuapass>



dove ns (o anche nickserv) è il comando che si darebbe per identificarsi.

Perfetto il nostro plugin nickserv.tcl adesso è attivo e funzionante.

Installazione dello script per il riavvio automatico

Ora passiamo all'installazione del nostro semplice script che permette di far ripartire automaticamente il nostro shroudBNC anche dopo il crash del server che lo ospita, accediamo via SSH al nostro server e ci posizionamo nella cartella del nostro sbnc con:

cd sbnc/

Seguito da:

nano -w sbncchk.sh

e scriviamo dentro il nostro file queste semplici righe di codice:

#!/bin/sh
SBNCPATH=/home/username/sbnc
 
if test -r $SBNCPATH/sbnc.pid; then
    SBNCPID=$(cat $SBNCPATH/sbnc.pid)
    if $(kill -CHLD $SBNCPID >/dev/null 2>&1)
    then
 exit 0
    fi
fi
cd $SBNCPATH
./sbnc &>/dev/null

Facendo molta attenzione a sostituire alla riga:

SBNCPATH=/home/username/sbnc

al posto di username il nostro nome utente, ovviamente.

Fatto ciò diamo ctrl+x salviamo ed usciamo.

Poi cambiamo i permessi del file di script sbncchk.sh appena creato con:

chmod +x sbncchk.sh

Adesso editiamo il nostro crontab con il comando:

crontab -e

ed aggiungiamo al crontab le righe:

@reboot $HOME/sbnc/sbncchk.sh > /dev/null 2>&1

*/10 * * * * $HOME/sbnc/sbncchk.sh > /dev/null 2>&1

Salviamo ed usciamo. Bene abbiamo terminato anche con l'installazione dello script, così anche se il server nel quale risiede il nostro shroudBNC dovesse crashare, il nostro BNC è in grado di ritornare su da solo, dato che il nostro script non fa altro che controllare ogni 10 minuti se sbnc è avviato e se non lo è, lo riavvia.

Se volete cambiare l'intervallo di tempo per il controllo basta sostituire alla riga appena inserita in crontab ed esattamente questa riga:

*/10 * * * * $HOME/sbnc/sbncchk.sh > /dev/null 2>&1

al posto di 10 i minuti che desiderate voi. Ovviamente dopo aver effettuato la modifica di crontab salvate ed uscite.

Se vi può interessare sono disponibili all'indirizzo: http://khobbits.net/sbnc/ altri plugin interessanti per il nostro shroudBNC.

Buon divertimento ^_^