Openvpn

by in Infrastruttura, Sicurezza, System Administration

Nei server di laboratorio, abbiamo installato vari tool aziendali di planning e gestione del personale, ovviamente raggiungibili soltanto dalla sede stessa. Avendo la necessità di esporre questi tool su internet, per usufruirne da qualsiasi sede, ed anche per eventuali condivisioni con il cliente finale. Per raggiungere questo obiettivo, abbiamo optato per un prodotto Opensource, OpenVPN.

Questo prodotto, permette ad un client opportunamente configurato, di accedere alla rete aziendale da qualsiasi parte del mondo.

Per la nostra VPN, abbiamo utilizzato un server con Centos 6.5 64 bit. Installiamo Openvpn:

yum install openvpn easy-rsa

Il pacchetto di OpenVPN fornisce una serie di script già pronti, per la gestione dei certificati di accesso. Copiamo tali script nella cartella di OpenVPN:

cp -r /usr/share/easy-rsa/2.0/ /etc/openvpn/rsaopenvpntech_logo_rounded_antialiased

Spostiamoci sotto la cartella apeena copiata:

cd /etc/openvpn/rsa

Apriamo il file “vars” e editiamo i campi, questo velocizzerà la creazione dei certificato, è comodo per chi ha la necessità di creare molti certificati. Un esempio del file vars:

export KEY_SIZE=1024
export KEY_COUNTRY="IT"
export KEY_PROVINCE="IT"
export KEY_CITY="Roma"
export KEY_ORG="Converger"
export KEY_EMAIL="info@converger.it

Creiamo la nostra CA (certificate authority)

# source vars 
# NOTE: If you run ./clean-all, I will be doing a rm -rf on /etc/openvpn/rsa/keys
# ./clean-all

Ora possiamo generare la nostra Certificate Authority: è necessario richiamare anche lo script “clean-all” per iniziare con un ambiente pulito. A questo punto siamo pronti per generare la nostra CA (certificate authority):

# ./build-ca
Generating a 1024 bit RSA private key..................................................
++++++...++++++
writing new private key to '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) [IT]:
State or Province Name (full name) [IT]:
Locality Name (eg, city) [Roma]:
Organization Name (eg, company) [Converger]:
Organizational Unit Name (eg, section) []:
Common Name (eg, your name or your server's hostname) [Converger CA]:
Email Address [info@converger.it]:

I valori di default vengono letti dal file vars sopra customizzato. Ora possiamo creare il certificato per il server VPN:

# ./build-key-server ConvergerVPN

ConvergerVPN è il nome della macchina su cui sto installando il server VPN, per coerenza la coppia chiave/certificato avrà il nome dell’host su cui viene usato.

Per evitare che ad ogni riavvio di OpenVPN sia richiesta una password premere invio senza inserire nulla alla richiesta di password:

Generating a 1024 bit RSA private key..................
++++++.++++++
writing new private key to ConvergerVPN .key'-----You are about to be asked to enter information that will be incorporatedinto 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) [IT]:
State or Province Name (full name) [IT]:
Locality Name (eg, city) [Roma]:
Organization Name (eg, company) [Converger]:
Organizational Unit Name (eg, section) []:
Common Name (eg, your name or your server's hostname) [ConvergerVPN ]:
Email Address [info@converger.it]:
Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:password
An optional company name []:
Using configuration from /etc/openvpn/rsa/openssl.cnf
Check that the request matches the signature
Signature ok
The Subject's Distinguished Name is as follows
countryName           :PRINTABLE:'IT'
stateOrProvinceName   :PRINTABLE:'IT'
localityName          :PRINTABLE:'Roma'
organizationName      :PRINTABLE:'Converger'
commonName            :PRINTABLE:' ConvergerVPN  '
emailAddress          :IA5STRING:'info@converger.it'
Certificate is to be certified until Nov 25 13:50:00 2020 GMT (3650 days)
Sign the certificate? [y/n]:y
1 out of 1 certificate requests certified, commit? [y/n]y
Write out database with 1 new entries
Data Base Updated

Procediamo alla creazione del file Diffie-Hellman, necessario per l’avvio delle connessioni cifrate.OpenVPN

# ./build-dh
Generating DH parameters, 1024 bit long safe prime, generator 2
This is going to take a long time
........+............

Realizziamo l’ultima chiave necessaria per l’instaurazione di una connessione sicura:

# openvpn --genkey --secret keys/ta.key

Generazione dei certificati per i client

La procedura per generare i certificati dei client è identica a quella del server, nell’esempio li creiamo nominali per una semplice identificazione, in caso di grandi numeri è possible usare la matricola aziendale.

# cd /etc/openvpn/rsa
# source vars 
# NOTE: If you run ./clean-all, I will be doing a rm -rf on /etc/openvpn/easy-rsa/keys  (ignorare il meassaggio)
# ./build-key rmassimi
Generating a 1024 bit RSA private key
..........................................++++++
................................................++++++
writing new private key to 'rmassimi.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) [IT]:
State or Province Name (full name) [RM]:
Locality Name (eg, city) [Roma]:
Organization Name (eg, company) [Converger]:
Organizational Unit Name (eg, section) []:
Common Name (eg, your name or your server's hostname) [rmassimi]:
Name []:Roberto Massimi
Email Address [info@converger.it]:rmassimi@converger.it
Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:
An optional company name []:
Using configuration from /etc/openvpn/easy-rsa/openssl.cnf
Check that the request matches the signature
Signature ok
The Subject's Distinguished Name is as follows
countryName           :PRINTABLE:'IT'
stateOrProvinceName   :PRINTABLE:'RM'
localityName          :PRINTABLE:'Roma'
organizationName      :PRINTABLE:'Converger'
commonName            :PRINTABLE:'rmassimi'
name                  :PRINTABLE:'Roberto Massimi'
emailAddress          :IA5STRING:'rmassimi@converger.it'
Certificate is to be certified until Nov 26 14:29:37 2024 GMT (3650 days)
Sign the certificate? [y/n]:y
1 out of 1 certificate requests certified, commit? [y/n]y
Write out database with 1 new entries
Data Base Updated

 Configurazione del server

Ora andiamo a configurare il demone OpenVPN, anche in questo caso il pacchetto dovrebbe portare con se degli esempi.

# cp /usr/share/doc/openvpn-2.3.2/sample/sample-config-files/server.conf /etc/openvpn/

Di seguito un file di configurazione:

 # SERVER CONF
port 443
proto tcp
dev tun
ca rsa/keys/ca.crt
cert rsa/keys/rcc001ws.crt
key rsa/keys/rcc001ws.key  # This file should be kept secret
dh rsa/keys/dh2048.pem
server 10.1.1.0  255.255.255.0
ifconfig-pool-persist ipp.txt
client-config-dir ccd
route 10.1.1.0 255.255.255.0
keepalive 10 120
cipher AES-256-CBC
comp-lzo
persist-key
persist-tun
status /var/log/openvpn-status.log 5
status-version 2
log-append /var/log/openvpn-status.log
verb 3
keepalive 10 60
push route "10.31.57.0 255.255.255.0"
crl-verify /etc/openvpn/crl.pem

In questo modo, dopo connesso in vpn, tutto funzionerà come prima, ma il nostro PC avrà una nuova interfaccia di rete con IP 10.1.1.x e tutti gli IP della classe 10.31.57.x verranno dirottati sulla VPN.In questa configurazione, rilasciamo IP ai client del tipo 10.1.1.x ed aggiungiamo la rotta 10.31.57.x .

Configurazione di IPTABLES

Come ultimo step sul server, dobbiamo abilitare il fowarding e il MASQUERADE tramite IPTABLES:

sysctl -w net.ipv4.ip_forward=1
iptables -t nat -A POSTROUTING -s 10.1.1.0/24 -o eth0 -j MASQUERADE

Se abbiamo IPTABLES configurato andiamo ad aggiungere anche le policy di ACCEPT:

iptables -A INPUT -i tun0 -j ACCEPT
iptables -A FORWARD -i tun0 -j ACCEPT

Avviare il demone di OpenVPN e configurare i certificati dei client.

Configurazione dei client

Per prima cosa dobbiamo copiarci i certificati:

  • La coppia certificato/chiave per il client (i due file .key e .crt)
  • Il certificato della CA del server (il file ca.crt)
  • La chiave di autenticazione TLS (il file ta.key)

File client.opvn:

client 
dev tun
proto tcp
remote IP_SERVER_VPN 443
resolv-retry infinitenobind
persist-key
persist-tun
# THE CSR FILE:
ca ca.crt
cert rmassimi.crt
key rmassimi.key
ns-cert-type server
cipher AES-256-CBC
comp-lzo
verb 3
route-method exe
route-delay 2

Lanciando questa configurazione con openVPN del client, noterete una nuova scheda di rete 10.1.1.x . Se ora provate ad aprire un qualsiasi tool o sistema sulla rete 10.31.57.x, questo risulterà disponibile!
Autore: Roberto Massimi

Bulk Email

by in System Administration

Bulk Mail con Mandrillapp, soluzione facile e gratuita

invio_massivo_email_intro2Molti sistemisti spesso si ritrovano davanti l’esigenza di dover inviare email automatiche a lunghe liste di destinatari. Registrare un account email dedicato e sviluppare uno script che invii le email è facile come cercare una moto usata su internet, basta avere un po’ di pazienza e trovare la soluzione più adatta alle nostre esigenze.

Ma cosa succede nel momento in cui la lista degli indirizzi diventa sull’ordine delle centina di indirizzi o addirittura migliaia?

Le regole antispam dei firewall di tutti i domini, sono molto “rigidi” quando vedono che un singolo account di posta elettronica, invia migliaia di email consecutive e finire nelle blacklist degli spammer è solo una questione di tempo.

A questo punto bisognerebbe vagliare tutte le proposte on-line di servizi di “Bulk-Send” o “messaggi massivi”. Questi provider sono provvisti di server smtp che vengono “riconosciuti” da tutti i domini come account bulk sender, quindi autorizzati ad inviare flussi di messaggi, senza essere bloccati o “rimbalzati” dai provider di posta elettronica.

La giungla delle offerte è veramente vasta, dal costo unitario per singola mail ad offerte stile supermercato all’ingrosso, più ne invii, meno ne paghi. Quindi a questo punto il sistemista, dopo aver valutato tutte le offerte, dovrebbe proporre la migliore all’eventuale cliente/commerciale per poter procedere all’acquisto del servizio ed iniziare la configurazione. Poi si torna con i piedi sulla terra, dove la richiesta dei PM è sempre “dammi la Luna, ma mi raccomando, GRATIS”.

Ed ecco arrivare in nostro aiuto Mandrillapp (www.mandrillapp.com), dove con una semplice registrazione assolutamente gratuita, si ha la possibilità di inviare fino a 12.000 messaggi al mese in modo totalmente gratuito, con una frequenza di massimo 250 messaggi l’ora.

Quest’ultima caratteristica potrebbe sembrare una limitazione, già il sistemista starà pensando a come suddividere le sue mail in trunk da 250invio_massivo_email_intro messaggi, invece no. Possiamo tranquillamente inviare tutte le nostre mail, sarà Mandrillapp a suddivere i messaggi. Una volta raggiunte le prime 250 email, le altre verranno depositate in una coda. Appena termina la prima ora di attesa, partono le 250 seguenti e così via, potendo inviare fino a 6000 email in 24h.

Già tutto questo basterebbe per convincere molti, ma i veri punti forza di questo provider sono:

– Facilità d’uso

– Grafici e statistiche personali

Infatti per utilizzare Mandrillapp, basterà usare l’smtp fornito in fase di registrazione ed il proprio utente ed ogni mail verrà inviata in modalità “on behalf of” del mittente a vostra scelta.

Una volta terminato l’invio, potremo interrogare tutte le statistiche fornite, che includono dati come:

– numero di email inviate

– numero di email consegnate

– numero di email “bounced” con motivazione

– numero di email aperte

Quindi se avete esigenza di inviare mail di segnalazione, monitoring o semplicemente la vostra app invia messaggi, questa soluzione potrebbe fare anche al caso vostro.
Autore : Marco Capacci

HP Non Stop Kernel

by in System Administration

HP Non Stop Kernel (aka HP NSK)

nskCosa è
Hp NonStop è un sistema disegnato e costruito per sopravvivere a fault hardware/software, situazione che per la maggior parte delle altre tipologie di sistemi, sarebbe fatale.
Queste sue caratteristiche lo portano alla realizzazione di sistemi full 24/7.

Fault-tollerance hardware
Un node server NSK implementa ridondanza HW interna. Ogni componente (unità di calcolo, unità di rete, unità di storage, etc…) è sempre costituita da ALMENO 2 unità.

Alcuni esempi di unità che costituiscono un sistema NSK:

UNITA’

 TIPOLOGIA NUMERO

CPU

 HP BLxxx 2 – 16

RAM

HP BLxxx

2+

NIC

HP DLxxx

2+
STORAGE HP DLxxx e/o (HP EVA o HP MSA)

2+


Fault-tollerance software
Il concetto stesso di sistema operativo è molto singolare;.

Qualsiasi cosa in Hp NonStop è implementato attraverso il concetto di sottosistema: dischi, connettività di rete, shell, database, il kernel stesso. Ogni CPU lavora indipendentemente dalle altre in un ambiente non condiviso ma coordinato dal sottosistema Kernel.

La scalabilità di sistema è realizzata con il parallelismo dei processi e non dei thread. E’ possibile eseguire il medesimo processo su ogni CPU del NSK. Il sistema stesso si occupa della distribuzione del carico di lavoro. L’alta affidabilità software è garantita configurando l’esecuzione in modalità transazionale di un processo (Process pair).

Dove
Telecomunicazioni, ATM bancari, servizi telefonici di emergenza, Point of Sale (POS), etc. sono alcuni esempi di sistemi in cui il completamento di transazioni è linfa vitale. Un sistema HpNon Stop garantisce tempi di inattività, in minuti, vicino allo zero annuo.

Autori: Alessandro Pioli, Manuel Quattrociocchi

VMWARE e HP C7000: velocità, facilità d’uso e sicurezza dei dati

by in System Administration

VMWARE vSphere ESX 5.0+ Enclosure HP C7000+SAN: velocità, facilità d’uso e sicurezza dei dati il tutto senza rinunciare alla scalabilità dell’infrastruttura e garantendo la continuità dei servizi anche nelle situazioni più critiche.

LE BASI

VMWARE

Il sistema di virtualizzazione che andremo ad usare è quello fornito da VMware per la sua alta affidabilità (HA). Infatti vSphere ESX, garantisce la disponibilità delle macchine virtuali all’interno di un ambiente, sapendo l’estrema importanza che questo ha per gli amministratori di sistema.
VMware HA allevia questi problemi fornendo una protezione dai guasti su i tre layer principali:

  • Infrastruttura: A questo livello, VMware HA controlla lo stato della macchina virtuale e tenterà di riavviarla, quando un guasto (come la perdita di un host fisico)si verifica. Questa protezione è indipendente dal sistema operativo utilizzato nella macchina virtuale.
    • Sistema Operativo: Attraverso l’uso dei VMware Tools installati all’interno del sistema operativo, VMware HA può monitorare il sistema operativo e il suo corretto funzionamento. Questo protegge contro possibili fallimenti (come un sistema operativo che non risponde).
    • Applicativo: Con qualche personalizzazione o con un tool di terze parti, un amministratore può anche monitorare il corretto funzionamento dell’applicazione in esecuzione all’interno del sistema operativo. In caso di guasto VMware HA può essere attivato per riavviare la macchina virtuale che ospita l’applicazione.

Enclosure HP C7000

L’enclosure hp c7000 è un contenitore di Blade, tra le sue caratteristiche ci sono la velocità (i sui virtual connect permettono un collegamento in fibra ridondato), la possibilità di espansione (può contenere fino a 16 half blade, 8 full blade), il sistema di gestione centralizzato (tramite l’onboard administrator si può controllare lo stato di tutti i blade), l’efficienza termica e la ridondanza del collegamento elettrico.
I blade utilizzati possono essere sia half  sia full, ed è possibile anche una configurazione mista che ci permette di utilizzare l’enclosure per più utilizzi.

SAN

Non è previsto l’utilizzo di una specifica SAN, le caratteristiche richieste sono:

  • Alte prestazioni;
  • Alta disponibilità;
  • Scalabilità;
  • Facilità di gestione.

LA CONFIGURAZIONE

La configurazione richiede del tempo ma i benefici sono tangibili, partendo dalla base di una SAN, quindi tutti i profitti  legati alla stessa (alta affidabilità,  ridondanza alle rotture, e velocità di accesso ai dati).
Lo zoning della San viene presentato ai Blade montati sul’enclosure c7000 grazie ai Virtual connect (moduli presenti sul c7000 che collegano l’enclosure al mondo),  il blade così è in grado di fare il boot sulla SAN bypassando i dischi locali. L’installazione del Sistema Operativo ESX prosegue in modo standard, al termine avremmo un sistema performante che sfrutta la velocità dei dischi sulla SAN.
Installato l’ESX ed effettuata la configurazione base abbiamo la possibilità di iniziare ad installare le Virtual Machines, come datastore possiamo utilizzare la stessa SAN, massimizzando e ottimizzando l’utilizzo di quest’ultima. Le macchine virtuali installate potranno essere attestate su un singolo blade ed in caso di necessità o di eventuali fault essere migrate su un altro blade mantenendo attiva l’operatività del sistema.
Il sistema permette così di migrare le macchine virtuali e mettere momentaneamente un server fuori FARM per eventuali riparazioni, o di sostituire l’intera lama senza dover reinstallare il sistema operativo minimizzando così i rischi di disservizi che tanto temono le aziende.

PRO
Il sistema prevede un’ottima scalabilità (è possibile aggiungere altri blade e collegare altre SAN)
Velocità e sicurezza
Possibilità di installare anche altri sistemi operativi su lame diverse sullo stesso c7000

CONTRO
Costo medio-alto

 

Autori: Giovanni Melis, Ermete De Luca e Gianluca Cavallari.

Backup a caldo per soluzioni di DR di sistemi Linux

by in System Administration

Nel corso del progetto DSC Vodafone, il nostro gruppo di lavoro si è trovato a dover cercare una soluzione a basso impatto economico per effettuare a caldo backup DR di sistemi Linux.
Dopo varie ricerche la soluzione adottata è stata quella di MondoRescue (http://www.mondorescue.org/), sw opensource che consente appunto, previa installazione sul sistema oggetto di backup, la creazione di file ISO “bootabili” per il ripristino completo del sistema in caso di disastro, anche su sistemi HW differenti (molto utile quindi anche per istallazione “in batteria”).

L’installazione del software nell’ambiente testato (RHEL6.5) prevede il download dei seguenti pacchetti:

  • genisoimage-1.1.9-12.el6.x86_64
  • afio-2.5-1.rhel6.x86_64
  • mindi-2.1.7-1.rhel6.x86_64
  • buffer-1.19-4.rhel6.x86_64
  • mindi-busybox-1.18.5-3.rhel6.x86_64
  • mondo-3.0.4-1.rhel6.x86_64

Ovviamente le release dei packages ed a volte il nome degli stessi, può cambiare in base alla distro o del periodo di installazione.

Il comando utilizzato nel nostro caso è stato il seguente:
# mondoarchive -i -d /workarea/mondo -E “/workarea|/opt/adc/adc/cdr|/tmp|/var/tmp” -s 8500m -T /workarea/mondo/tmp -S /workarea/mondo/tmp -OV -p `uname -n`_`date +%Y-%m-%d`

Si rimanda al man per i dettagli delle opzioni possibili ed approfondimento in base alla proprie esigenze; un accorgimento utile è quello di badare allo spazio disponibile nel FS di destinazione ISO e quello temporaneo.

I test di recovery del sistema sono stati eseguiti montando la ISO precedentemente creata dal “Virtual Drives” della Java modorescueIRC di ILO.

Una volta avviata la ISO è possibile scegliere se eseguire il recovery in modalità automatica (nuke) o interattiva (interactive).
Questa ultima possibilità da modo di decidere cosa ripristinare e cosa no.

Inoltre è possibile eseguire una comparazione tra il backup a nostra disposizione e il sistema che ci accingiamo a sovrascrivere (compare).

Al termine della procedura avremo il nostro sistema ripristinato al momento del backup.

Essendo la procedura di backup eseguibile a caldo, è possibile ovviamente schedulare in crontab la creazione della iso, per mantenere il backup aggiornato e consistente.

Autore: Filiberto Mannelli

Fault Tolerant Distributed File System

by in System Administration

xfs

(Fault Tolerant Distributed File System)

 

A differenza dei Network File System comuni, XtreemFS è un file system distibuito, fault-tolerant, open source che funziona su più server e grazie allo striping è possibile accedere ai dati con la larghezza di banda aggregata di più server di archiviazione.

Grazie ad esso è possibile costruirsi un proprio storage utilizzandoxfs2 hardware di uso comune, con la possibilità di gestire lo spazio in base alle proprie disponibilità,  con la sicurezza di tollerare guasti hardware a costi decisamente contenuti (opensource) rispetto a soluzioni all-in-one (SAN e NAS) che generalmente dipendono dal fornitore hardware.

XtreemFS utilizza il concetto di file system basato su oggetti: I Metadata (nome file, owner e struttura directory) vengono memorizzati su un server (MRC), il contenuto dei file viene diviso in chunks di dimensione fissa che chiameremo “oggetti”, gli oggetti vengono memorizzati su un server di archiviazione (OSD). Questa separazione tra metadata e contenuto dei file permette di scalare la capacità di memorizzazione e la larghezza di banda, se vogliamo aggiungere o rimuovere altri server di memoria (OSD).

Il servizio directory server (DIR) è il registro centrale che i servizi di XtreemFS utilizzano per trovare gli altri nodi. E’ anche usato dai client per trovare l’MRC che gestirà il volume montato dagli utenti.

MRC e DIR memorizzano tutti i dati (metadata) su un database integrato e ottimizzato per lo storage dei metadata, BABUDB, mentre OSD memorizza i suoi dati in forma di file e directory su file system locale OSD. Tutti gli oggetti si trovano nella directory specificata nel file di configurazione.

Come si evince dall’immagine accanto, i tre server condivideranno un XtreemFS, il quale sarà sommato a quelli  condivisi dagli altri sistemi, per un totale (in questo caso) di 150Gb. Il client accederà a 150Gb di risorse.

La scalabilità di XtreemFS permette velocemente l’aggiunta o la rimozione di altri “storage server”e grazie allo striping dei file su più server di archiviazione,  le operazioni di READ/WRITE vengono eseguite in parallelo sugli storage server, sfruttando tutta la banda, simile a RAID 0.

Il prodotto si può scaricare gratuitamente al seguente URL: http://www.xtreemfs.org/download.php?t=source

L’installazione del pacchetto client è necessaria per accedere a Xtreemfs da un sistema remoto .

Autori: Domenico Princi, Luca Di Dedda, Octavian Petrascu