Ci sono due strade percorribili, una è la Debian Way l’altra è quella maccheronica. Descriverò quella alla Debian Way e lascio ai commenti l’opportunità di descrivere quella maccheronica!:)

Con il comando update-alternatives –config editor vien fuori:

Ci sono 5 alternative che forniscono `editor'.
Selezione Alternativa
-----------------------------------------------
1 /bin/ed
+ 2 /bin/nano
3 /usr/bin/vim.tiny
4 /usr/bin/vim.basic
* 5 /usr/bin/vim.nox
Premi invio per mantenere il default[*], o inserisci il numero da selezionare:

Facile no? Ovviamente bisogna aver installato l’editor che si vuole impostare come default altrimenti la lista mostrata sarà molto misera.

Adesso chiedo a voi: qual’è il modo maccheronico per cambiare editor?

Ci viene in aiuto ULOG, un tool che lavora in userspace e permette   quindi,   tramite un   programma   in   continuo   ascolto,   di   gestire   tali   informazioni nella maniera più disparata.

Procediamo con l’installazione dei pacchetti necessari:

apt-get install ulogd ulogd-mysql

Adesso va creato il database con gli opportuni privilegi. Tralascio questa fase perché è banale, specie con phpMyAdmin.
Le struttura della tabella è scritta nel file /usr/share/doc/ulogd-mysql/mysql.table, quindi lo carichiamo nel database appena creato con:

mysql -u <utente> -p <nome_db> < /usr/share/doc/ulogd-mysql/mysql.table

Procediamo con la configurazione di ULOG editando il file /etc/ulogd.conf.

Nella sezione plugins va decommentato:

plugin="/usr/lib/ulogd/ulogd_MYSQL.so"

visto che i dati andranno sul un db MySQL.

Impostiamo l’account per l’accesso al database:

[MYSQL]
table="ulog"
pass="<password>"
user="<user>"
db="<database>"
host="localhost"

Bene, riavviamo ULOG:

/etc/init.d/ulogd restart

Proviamo il tutto impostando una regola di iptables con il target ULOG:

iptables -t nat -I POSTROUTING -s 192.168.1.0/24 -o eth0 -j ULOG

In breve: tutto quello che proviene dalla classe lan 192.168.1.0/24 ed esce dall’interfaccia eth0 (verso Internet) e quindi viene nattato, lo registriamo su MySQL. Ovviamente possiamo impostare qualsiasi regola di firewall con target ULOG per testarne il funzionamento.

MySQL ha qualche record in più? Bene, abbiamo finito.

Vediamo come.

Supponiamo di avere due nodi:

1. Il server, che condivide porzioni di filesystem
2. Il client, che monta ed utilizza il filesystem condiviso dal server

I pacchetti da installare sul server sono:

apt-get install nfs-kernel-server nfs-common portmap

Sul client invece basta:

apt-get install nfs-common portmap

Adesso va configurato il server per l’esportazione delle directory e quindi va editato il file /etc/exports/ ed al suo interno dobbiamo mettere qualcosa del tipo:

/mnt/nfs-share        192.168.1.100 (rw,sync)

Dove:

• /mnt/nfs-share/ è la directory che vogliamo condividere con il cliente
• 192.168.1.100 è l’IP del client autorizzato a connettersi al server
• (rw,sync) sono  dei parametri necessari per consentire la lettura e la scrittura e l’aggiornameno sincrono della directory

Una volta cambiato il file /etc/exports/ lanciamo il comando:

exportfs -a

Creiamo la directory da condividere (forse era meglio farlo prima!):

mkdir /mnt/nfs-share
chown nobody:nogroup /mnt/nfs-share


Il server è OK. Passiamo al client.
Creiamo il punto di mount sul client:

mkdir  /mnt/nfs

E montiamo la directory remota:

mount 192.168.1.7:/mnt/nfs-share /mnt/nfs

Ovviamente 192.168.1.7 è l’IP del server, cambiatelo in base alle vostre esigenze.
Finito! Adesso possiamo scrivere su /mnt/nfs del client che coincide con la directory condivisa dal server.
Chicca finale: montiamo la partizione NFS all’avvio del sistema con fstab aggiungendo questa riga:

192.168.1.7:/mnt/nfs-share /mnt/nfs nfs rw,sync,hard,intr 0 0

Buon NFS a tutti!:)

Lo uso da tantissimo tempo ma, quando tutta Internet tremava per il bug dei server DNS, sapere che PowerDNS era completamente immune a tale vulnerabilità, ha rafforzato la mia stima verso questo software.

I principali punti di forza di PowerDNS sono:

• Backend per svariati database quali ad esempio MySQL e PostgreSQL
• Facilità di configurazione
• Sicurezza
• Versatilità

Prima di procedere con l’installazione è doveroso illustrare le parti che compongono questo software:

1. pdns-server: il server DNS vero e proprio
2. pdns-backend-*: il backend dove sono memorizzati i dati ad esempio pdns-backend-mysql utilizzerà MySQL per memorizzare i record DNS
3. pdns-recursor: un server necessario se si devono risolvere altri domini Internet oltre a quelli gestiti dal server

Installiamo!

Come sempre facile e veloce:

apt-get install pdns-server pdns-backend-mysql

Si può notare non ho installato il pacchetto pdns-recursor visto che voglio configurare un server DNS che risponda solo alle query per i domini da lui gestiti.

Creiamo un database ed utente su MySQL chiamato pdns a cui diamo tutti i privilegi:

CREATE USER 'pdns'@'localhost' IDENTIFIED BY '<password_utente>';
GRANT USAGE ON * . * TO 'pdns'@'localhost' IDENTIFIED BY '<password_utente>' WITH MAX_QUERIES_PER_HOUR 0 MAX_CONNECTIONS_PER_HOUR 0 MAX_UPDATES_PER_HOUR 0 MAX_USER_CONNECTIONS 0 ;
CREATE DATABASE IF NOT EXISTS `pdns` ;
GRANT ALL PRIVILEGES ON `pdns` . * TO 'pdns'@'localhost';

Inizializziamo le tabelle necessarie attraverso il file SQL incluso nel pacchetto Debian:

mysql -u pdns -p pdns < /usr/share/doc/pdns-backend-mysql/mysql.sql

Il database è pronto, inseriamo dei record di prova:

INSERT INTO `domains` (`id`, `name`, `master`, `last_check`, `type`, `notified_serial`, `account`) VALUES
(1, 'ideafactorytest.tld', NULL, NULL, 'NATIVE', NULL, NULL);
INSERT INTO `records` (`id`, `domain_id`, `name`, `type`, `content`, `ttl`, `prio`, `change_date`) VALUES
(1, 1, 'ideafactorytest.tld', 'SOA', 'ns1.ideafactorytest.tld hostmaster.ideafactorytest.tld 0 7200 3600 604800 3600', 3600, 0, 1235466538),
(2, 1, 'ideafactorytest.tld', 'NS', 'ns1.ideafactorytest.tld', 86400, 0, 1235466538),
(3, 1, 'www.ideafactorytest.tld', 'A', '192.168.1.254', 86400, 0, 1235466538),
(4, 1, 'ns1.ideafactorytest.tld', 'A', '192.168.1.254', 86400, 0, 1235466538);

Ovviamente i dati sono di test e vanno personalizzati secondo le proprie esigenze.

Consiglio di utilizzare tool di MySQL per popolare il database come ad esempio phpMyAdmin, in alternativa c’è Poweradmin che è un software scritto in PHP specifico per PowerDNS ma non mi ha convinto per niente.

Torniamo alla configurazione del server DNS.

Editiamo il file /etc/default/pdns e verifichiamo che ci sia:

START=yes

Adesso è il turno di /etc/powerdns/pdns.conf, vi consiglio di editare:

local-address=<ip_server_dns>

Altrimenti PowerDNS si mette in ascolto su tutti gli IP del server.

Ci sono altre opzioni, come l’abilitazione del webserver che consente di vedere le statistiche d’utilizzo.

Il file di configurazione è di semplice interazione quindi consiglio di dare un occhio a tutti i parametri e rimando alla documentazione ufficiale per configurazioni più elaborate.

Infine configuriamo /etc/powerdns/pdns.d/pdns.local:

launch=gmysql
gmysql-host=localhost
gmysql-user=pdns
gmysql-password=<password_scelta>
gmysql-dbname=pdns

Fine. Proviamo:

/etc/init.d/pdns monitor

Se l’output è qualcosa di simile a questo:

Apr 15 17:05:16 This is module gmysqlbackend.so reporting
Apr 15 17:05:16 This is a standalone pdns
Apr 15 17:05:16 UDP server bound to 192.168.1.254:53
Apr 15 17:05:16 TCP server bound to 192.168.1.254:53
Apr 15 17:05:16 PowerDNS 2.9.20 (C) 2001-2006 PowerDNS.COM BV (Aug  9 2008, 23:00:23, gcc 4.1.2 20061115 (prerelease) (Debian 4.1.1-21)) starting up
Apr 15 17:05:16 PowerDNS comes with ABSOLUTELY NO WARRANTY. This is free software, and you are welcome to redistribute it according to the terms of the GPL version 2.
Apr 15 17:05:16 Set effective group id to 106
Apr 15 17:05:16 Set effective user id to 106
Apr 15 17:05:16 DNS Proxy launched, local port 23998, remote 127.0.0.1:53
Apr 15 17:05:16 Creating backend connection for TCP
% Apr 15 17:05:16 gmysql Connection succesful
Apr 15 17:05:16 About to create 3 backend threads for UDP
Apr 15 17:05:16 gmysql Connection succesful

Significa che PowerDNS si connette a MySQL e la configurazione è andata a buon fine.

Facciamo una query di prova:

host www.ideafactorytest.tld <ip_server_powerdns>

L’output dovrebbe essere:

Using domain server:
Name: <ip_server_powerdns>
Address: <ip_server_powerdns>#53
Aliases:
www.ideafactorytest.tld has address 192.168.1.254

Perfetto!

Come viene gestito il concetto di master/slave in PowerDNS?

Usando come backend un database MySQL, è facile mettere su un altro server sul quale configurare PowerDNS e la replica del database principale oppure, si può fare in modo che entrambi i server DNS usino lo stesso server MySQL ma questa soluzione è poco high available.

Consiglio di leggere la documentazione ufficiale al fine di ottenere il massimo da questo potente server DNS o scrivere eventuali quesiti nei commenti sperando che io riesca a rispondere!:)

Un rootkit, (in ambiente Unix per “root” access si intende accesso di livello amministrativo, quindi letteralmente si potrebbe intendere equipaggiamento da amministratore) è un programma software creato per avere il controllo completo sul sistema senza bisogno di autorizzazione da parte di utente o amministratore. Recentemente alcuni virus informatici si sono avvantaggiati della possibilità di agire come rootkit (processo, file, chiave di registro, porta di rete) all’interno del sistema operativo.

Per capire se sul nostro server ci sono rootkit è necessario:

• controllare i log di sistema alla ricerca di cose anomale
• monitorare attentamente i processi server quali Apache, SSH etc
• controllare le directory su cui tutti possono scrivere come ad esempio /tmp
• vedere il file history alla ricerca di comandi non nostri
• attraverso tool come ntop vedere se ci sono in esecuzione processi non autorizzati
• con netstat o nmap verificare che non ci siano porte aperte non consentite dalla nostra configurazione
• controllare lo spazio su disco utilizzato

Tutto questi controlli portano via tempo e di certo non è un lavoro facile da fare.

In ambiente Linux esistono due tool particolarmente efficienti che fanno al caso nostro: ChkRootkit e rkhunter.

Installiamo il software su Debian:

apt-get install chkrootkit rkhunter

rkhunter

Una volta installato va aggiornato:

rkhunter --update

Adesso possiamo eseguire uno scan sul nostro sistema:

rkhunter -c

L’output è molto esplicito e di facile comprensione.

Utili queste opzioni:

• --createlogfile <file> : l’output viene scritto sul file specificato
• –skip-keypress : non è necessario dare conferme tramite l’esecuzione

ChkRootkit

E’ meno duttile di rkhunter visto che rileva solo una lista ben precisa di rootkit.

Per l’esecuzione è sufficiente:

chkrootkit

Consiglio vivamente di inserire tali contralli nel crond (Debian automatizza tale operazione con rkhunter) ma soprattutto di tenersi aggiornati con i bug di sicurezza attraverso le apposite mailing-list della distribuzione usata o via web con i siti specializzati.

Su Debian l’installazione è banale:

apt-get install vnstat

Adesso dobbiamo inizializzare il database di vnStat con le interfacce in nostro possesso:

vnstat -u -i <interfaccia>

Il più delle volte le nostre interfacce ethernet sono eth0, eth1 etc etc.

Adesso è il momento del caffè visto che i dati devono confluire in vnStat per visualizzare le prime statistiche. Trascorso un pò (bel pò) di tempo torniamo su Linux e vediamo che dati fornisce il tool appenna installato.

Lanciando il comando

vnstat

Vedremo il traffico degli ultimi due giorni.
Per avere maggiori dettagli è possibile usare i seguenti parametri:

• -h : visualizza il traffico delle ultime 24 ore
• -d : visualizza il traffico giornaliero dell’ultimo mese
• -m : visualliza il traffico degli ultimi mesi
• -t : i 10 giorni con più traffico
• -w : il traffico delle ultime settimane
• -tr : il traffico medio degli ultimi 5 secondi (con -tr X monitoriamo gli ultimi X secondi)

Se abbiamo più interfacce sotto osservazione possiamo usare il parametro -i <interfaccia> per specificare quale visualizzare.

Prima di procedere all’installazione del software necessario, vediamo le modalità operative del channel bonding:

• mode=0 (balance-rr): avviene il round-robin tra le due interfacce. I pacchetti vengono trasmessi attraverso la scheda di rete scarica e se una delle due va ko viene usata solo la scheda di rete funzionanete. Questa  modalità fornisce sia il load balance e sia il fault tolerance e non prevede switch di rete con particolari funzionalità.
• mode=1 (active-backup): una sola schede di rete viene usata se questa si rompe il MAC address viene associato all’altra funzionante (di backup) e quindi il flusso di rete viene garantito. Questa modalità fornisce un sistema di fault tolerance e non è necessario uno switch che abbia funzionalità avanzate.
• mode=2 (balance-xor): il traffico di rete viene inoltrato sulla scheda in base a questa regola di XOR: ((source MAC) XOR (dest MAC)).  Questa modalità garantisce load balance e  fault tolerance e non necessità di particolati switch.
• mode=3 (broadcast): vengono usate entrambe le interfacce per trasmettere e ricevere. Il fault tolerance è garantito senza switch preposti.
• mode=4 (802.3ad): è una modalità si supporto allo standard IEEE 802.3ad Dynamic link aggregation, per questa modalità è necessario uno switch che supporti lo standard 802.3ad.
• mode=5 (balance-tlb): Adaptive Transmit Load Balancing. Il traffico in entrata è ricevuto solo sullo slave attivo, il traffico in uscita viene distribuito a seconda del carico su ogni slave. Non necessità di particolai switch.
• mode=5 (balance-alb): Adaptive Load Balancing. Fornisce bilanciamento del carico sia in ricezione che in trasmissione. Non necessità di switch particolari ma richiede la capacità di cambiare l’indirizzo MAC del dispisitivo di rete senza che questo interrompa il traffico.

Procediamo con l’installazione di ciò che occore sul nostro sistema Debian Lenny:

apt-get install ifenslave-2.6

Adesso configuraziomo il networking tramite il file /etc/network/interfaces, supponendo che eth0 ed eth1 siano le schede ethernet presenti sulla nostra debian box:

iface bond0 inet static
address <indirizzo_ip>
netmask <subnetmask>
network <indirizzo_di_rete>
gateway <ip_del_gateway>
bond_mode <modalita_di_bonding_preferita>
bond_miimon 100
bond_downdelay 200
bond_updelay 200
slaves eth0 eth1

Io vi consiglio o la modalità balance-rr o la active-backup.

E’ importante commentare o cancellare i riferimenti alla schede di rete reali.

Fatto questo riavviamo il sistema di networking con:
/etc/init.d/networking restart

Maggiori informazioni e dettagli li potete trovare qui:

http://www.linuxhorizon.ro/bonding.html

La soluzione si chiama:  CurlFtpFS.

Installiamolo:

apt-get install curlftpfs

E’ importante caricare il modulo di fuse:

modprobe fuse

Montiamo la partizione remota FTP:

curlftpfs -o allow_other ftp://<user>:<pass>@<host_ftp> <directory_di_mount>

Per per montare la partizione all’avvio impostiamo fstab aggiungendo questa riga:

curlftpfs#<user>:<pass>@<host_ftp> <directory_di_mount> fuse rw,uid=500,user,noauto 0 0

Fine!:)

Ecco le caratteristiche principali di CurlFtpFS:

• support for SSLv3 and TLSv1
• connecting through tunneling HTTP proxies
• automatic reconnection if the server times out
• conversion of absolute symlinks to point back into the FTP filesystem

OpenVPN is a free and open source virtual private network (VPN) program for creating point-to-point or server-to-multiclient encrypted tunnels between host computers. It is capable of establishing direct links between computers across network address translators (NATs) and firewalls. It was written by James Yonan and is published under the GNU General Public License (GPL).

Bene, procediamo.

Supponiamo di avere due host e di creare una VPN tra loro, installiamo su entrambi openvpn:

apt-get install openvpn

Adesso usiamo la Debian Way e quindi utilizziamo gli script per la creazione dei certificati e delle chiavi.

Facciamo un link simbolico:

ln -s /usr/share/doc/openvpn/examples/easy-rsa/ /etc/openvpn/easy-rsa

Editiamo il file /etc/openvpn/easy-rsa/vars con i parametri che fanno al caso nostro:

export KEY_COUNTRY=
export KEY_PROVINCE=
export KEY_CITY=
export KEY_ORG=”"
export KEY_EMAIL=”"

Il file contiene tutto variabili d’ambiente e quindi con questo comando:

source /etc/openvpn/easy-rsa/vars

Esportiamo le variabili.

Adesso generiamo la chiave della CA visto che saremo noi stessi a fare da certification authority:

/etc/openvpn/easy-rsa/build-ca

Le chiavi andranno a finire sotto:

/etc/openvpn/easy-rsa/keys

Adesso creiamo la chiave per il server:

/etc/openvpn/easy-rsa/build-key-server server

Seguendo le facili istruzioni a video verrà creata la chiave.

Abilitiamo lo scambio di chiavi Diffie-Hellman

Lo Scambio di chiavi Diffie-Hellman (Diffie-Hellman key exchange) è un protocollo crittografico che consente a due entità di stabilire una chiave condivisa e segreta utilizzando un canale di comunicazione insicuro (pubblico) senza la necessità che le due parti si siano scambiate informazioni o si siano incontrate in precedenza. La chiave ottenuta mediante questo protocollo può essere successivamente impiegata per criptare le comunicazioni successive tramite uno schema di crittografia simmetrica.

eseguendo questo comando:

/etc/openvpn/easy-rsa/build-dh

Adesso manca solo il certificato TLS, che va creato così:

openvpn –genkey –secret /etc/openvpn/easy-rsa/keys/ta.key

Abbiamo tutto il necessario per il server, va solo configurato attraverso il file /etc/openvpn/server.conf:

local
port 1194
proto udp
dev tun
ca /etc/openvpn/easy-rsa/keys/ca.crt
cert /etc/openvpn/easy-rsa/keys/server.crt
key /etc/openvpn/easy-rsa/keys/server.key
dh /etc/openvpn/easy-rsa/keys/dh1024.pem
tls-auth /etc/openvpn/easy-rsa/keys/ta.key 0
cipher BF-CBC
server 10.0.0.0 255.255.255.0
ifconfig-pool-persist ip_client.txt
comp-lzo
persist-key
persist-tun
keepalive 10 360
verb 4
mute 20
log-append /var/log/openvpn/openvpn.log
status /var/log/openvpn/openvpn-status.log

Da notare la direttiva ifconfig-pool-persist ip_client.txt che memorizza gli IP assegnati ai client per dare lo stesso IP in futuro.
Va creata le directory sotto /var/log sua sul server che sul client:

mkdir /var/log/openvpn

Ora è possibile lanciare OpenVPN:

/etc/init.d/openvpn start

Se l’output è questo:

Starting virtual private network daemon: server(OK).

Potete vedere tramite ifconfig la nuova interfaccia tun0.

Siamo a metà dell’opera, manca il client.
Per comodità generiamo le chiavi del client sul server…so che non andrebbe fatto ma visto che non c’è una vera CA penso sia la cosa più veloce!

Creiamo la chiave:

/etc/openvpn/easy-rsa/build-key

Seguendo le istruzioni avremo la chiave per il client e sicomme Debian è la migliore distribuzione al mondo, è anche verificata tramite CA (la nostra!).

Spostiamo i file (IN MODO SICURO) sul client, ma quali file?

• ca.crt
• ta.key
• <client>.crt
• <client>.key

Sul client metteremo questi file sotto /etc/openvpn, occhio ai permessi:

-rw-r–r–    ca.crt
-rw-r–r–    <client>.crt
-rw-r–r–    <client>.key
-rw——-    ta.key

Creiamo il file di configurazione del client (/etc/openvpn/client.conf):

client
dev tun
proto udp
remote 85.25.71.39 1194
resolv-retry infinite
ca ca.crt
cert <client>.crt
key <client>.key
tls-auth ta.key 1
cipher BF-CBC
comp-lzo
ping 10
verb 3
mute 10
log-append /var/log/openvpn/openvpn.log
status /var/log/openvpn/openvpn-status.log

E’ il momento di far partire il client:

/etc/init.d/openvpn start

Se l’output è questo:

Starting virtual private network daemon: client(OK).

Abbiamo finito!:)

Proviamo la VPN con un ping dal client verso il server (10.0.0.1) per vedere se è tutto ok.

Per fortificare ancor più questo sistema si può usare SSH con l’autenticazione a chiave pubblica. Esistono decine di siti che descrivono bene questo sistema e spiagano come creare la coppia di chiavi quindi io do per assodato la creazione delle chiavi.

Per prima cosa va copiata la nostra chiave pubblica nel server remoto:

scp -p id_rsa.pub <utente_remoto>@<hot_remoto>:

Il file nel mio caso si chiama id_rsa.pub perché ho generato una chiave RSA ma anche una di altro tipo va più che bene!

Adesso creiamo le directory opportune nella home del nostro utente sul server remoto:

mkdir ~/.ssh
chmod 700 ~/.ssh
cat id_rsa.pub >> ~/.ssh/authorized_keys
chmod 600 ~/.ssh/authorized_keys
mv id_rsa.pub ~/.ssh

Adesso sul server remoto va configurato il demone SSH attraverso il file /etc/ssh/sshd_config.

Settiamo queste direttive:

PermitRootLogin no
PasswordAuthentication no
UsePAM no

e riavviamo SSH:

/etc/init.d/ssh restart

Da adesso al nostro server ci si accede senza password…ma con la chiave!:)