Networking

Aumentare dimensione HD di Freepbx su VM

by • Networking • 0 Comments

Aumentare la dimensione del disco (HD) di Freepbx su VM è una necessità sempre più frequente. Quando, per esempio, è stata sottostimata la capacità del disco fisso virtuale rispetto alle esigenze del sistema o del cliente. le VM (macchina virtuale) sono ormai molto diffuse, anche per la facilità di backup e di ripristino in caso di crash. In questo breve guida, vedremo come aumentare la dimensione di un HD di Freepbx su una VM realizzata in ambiente windows con virtualbox.

Innanzi tutto sarà necessario aumentare la dimensione del disco virtuale, accediamo alla finestra per la modifica della dimensione, digitando la sequenza Ctrl+D:

Aumentare dimensione HD di Freepbx su VM

aumentando la dimensione e confermando con applica e poi chiudi.

A questo punto dobbiamo assegnare lo spazio libero, appena aggiunto, al volume logico utilizzato da freepbx.

Come prima attività verifichiamo le partizioni presenti:

#fdisk -l
Disk /dev/sda: 269.6 GB, 269591642112 bytes, 526546176 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk label type: dos
Disk identifier: 0x0007c563

Device Boot Start End Blocks Id System
/dev/sda1 * 2048 4098047 2048000 83 Linux                <—— Partizione 1
/dev/sda2 4098048 48861183 22381568 8e Linux LVM <—— Partizione 2

Disk /dev/mapper/SangomaVG-root: 20.8 GB, 20770193408 bytes, 40566784 sectors
Units = sectors of 1 * 512 = 512 bytes

Quindi verifichiamo le partizioni utilizzate e lo spazio libero creato:

#parted /dev/sda print free
Model: ATA VBOX HARDDISK (scsi)
Disk /dev/sda: 270GB
Sector size (logical/physical): 512B/512B
Partition Table: msdos
Disk Flags:

Number Start End Size Type File system Flags
32.3kB 1049kB 1016kB Free Space
1 1049kB 2098MB 2097MB primary ext4 boot
2 2098MB 25.0GB 22.9GB primary lvm
25.0GB 270GB 245GB Free Space <——– Spazio libero creato

Creiamo la nuova partizione utilizzando lo spazio appena creato:
#fdisk /dev/sda
Welcome to fdisk (util-linux 2.23.2).

Changes will remain in memory only, until you decide to write them.
Be careful before using the write command.

Command (m for help): n
Partition type:
p primary (2 primary, 0 extended, 2 free)
e extended
Select (default p): p
Partition number (3,4, default 3): 3
First sector (48861184-526546175, default 48861184):
Using default value 48861184
Last sector, +sectors or +size{K,M,G} (48861184-526546175, default 526546175):
Using default value 526546175
Partition 3 of type Linux and of size 227.8 GiB is set

Command (m for help): t
Partition number (1-3, default 3): 3
Hex code (type L to list all codes): 8e
Changed type of partition ‘Linux’ to ‘Linux LVM’

Command (m for help): w
The partition table has been altered!

eseguiamo la riscansione delle partizioni:
# partprobe -s
/dev/sda: msdos partitions 1 2 3

verifichiamo le partizioni presenti:
# fdisk -l

Disk /dev/sda: 269.6 GB, 269591642112 bytes, 526546176 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk label type: dos
Disk identifier: 0x0007c563

Device Boot Start End Blocks Id System
/dev/sda1 * 2048 4098047 2048000 83 Linux
/dev/sda2 4098048 48861183 22381568 8e Linux LVM
/dev/sda3 48861184 526546175 238842496 8e Linux LVM   <—— Partizione 3 creata

Disk /dev/mapper/SangomaVG-root: 20.8 GB, 20770193408 bytes, 40566784 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes


Disk /dev/mapper/SangomaVG-swaplv1: 2147 MB, 2147483648 bytes, 4194304 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes

Quindi inizializziamo il PhisicalVolume per il suo successivo utilizzo nel nostro LVM:

#pvcreate /dev/sda3
Physical volume “/dev/sda3” successfully created.
# vgdisplay
— Volume group —
VG Name SangomaVG
System ID
Format lvm2
Metadata Areas 1
Metadata Sequence No 4
VG Access read/write
VG Status resizable
MAX LV 0
Cur LV 2
Open LV 2
Max PV 0
Cur PV 1
Act PV 1
VG Size 21.34 GiB
PE Size 4.00 MiB
Total PE 5464
Alloc PE / Size 5464 / 21.34 GiB
Free PE / Size 0 / 0
VG UUID Pcc0pu-mUbd-rOg0-V4iI-5jdO-sVUp-tk6Icd

Inseriamo il volume nel nostro volume logico SangomaVG:

# vgextend SangomaVG /dev/sda3
Volume group “SangomaVG” successfully extended

Infine estendiamo il filesystem esistente all’intero spazio disponibile sul volume:

# lvresize -r -l+100%FREE /dev/mapper/SangomaVG-root
Size of logical volume SangomaVG/root unchanged from <247.12 GiB (63262 extents).
Logical volume SangomaVG/root successfully resized.

A questo punto il nostro volume è stato allargato, lo possiamo verificare facilmente con il comando df -lh.

Attivare un Server SysLog su Linux

by • Networking • Tags: • 0 Comments

syslog server

Attivare un server syslog su linux è una operazione necessaria quando si intende analizzare o monitorare i comportamenti dei dispositivi presenti nella nostra infrastruttura.  Attivare un server syslog su linux dedicato a questo scopo ha il vantaggio di poter ricevere i dati su un dispositivo dedicato esclusivamente a questo scopo, quindi poter analizzare i dati di servizi in funzione su altri server anche in fase di avvio. Di seguito vediamo quali sono i comandi per attivare un server syslog su linux ed in particolare su una macchina Centos 6.X:

# yum -y install rsyslog
per installare il servizio

a questo punto andiamo a modificare alcuni valori contenuti nel file /etc/rsyslog.conf  che contiene i parametri di configurazione del servizio:

# vi /etc/rsyslog.conf
andiamo a modificare le seguenti righe:

# Provides UDP syslog reception
#$ModLoad imudp
#$UDPServerRun 514

# Provides TCP syslog reception
#$ModLoad imtcp
#$InputTCPServerRun 514

togliendo il simbolo di commento:

# Provides UDP syslog reception
$ModLoad imudp
$UDPServerRun 514

# Provides TCP syslog reception
$ModLoad imtcp
$InputTCPServerRun 514

ed infine riavviamo il servizio:

#service rsyslog restart

A questo punto verifichiamo che il servizio sia attivo ed in ascolto:

#netstat -antup | grep 514
il risultato dovrebbe essere simile a :
tcp  0 0   0.0.0.0:514 0.0.0.0:* LISTEN 8081/rsyslogd
tcp  0 0   :::514          :::*         LISTEN 8081/rsyslogd
udp 0 0  0.0.0.0:514  0.0.0.0:* 8081/rsyslogd
udp 0 0   :::514         :::*

Se il risultato ottenuto è simile a quello sopra illustrato, il server è funzionante ed in ascolto sulla porta 514. Eventualmente si può anche specificare una particolare directory dove andare a memorizzare i file log come descritto nelle prossime righe.

Per impostare una specifica directory dove memorizzare i file di log, bisogna modifica il file /etc/rsyslog.conf aggiungendo le seguenti righe prima del blocco GLOBAL DIRECTIVES:

$template RemoteLogs,”/var/log/%HOSTNAME%/%PROGRAMNAME%.log” *
*.* ?RemoteLogs
& ~

Nell’esempio i file di log vengono memorizzati nella directory /var/log/ all’interno della quale vi è una directory con il nome dell’host remoto e dell’applicazione che ha generato i log.

 

OpenVPN Rinnovo e Verifica Certificato

by • Networking • Tags: • 0 Comments

OpenVPN Rinnovo e Verifica Certificato

L’articolo OpenVPN Rinnovo e Verifica Certificato ha lo scopo di presentare una soluzione per la gestione dei certificati utilizzati da  OpenVPN© per l’attivazione di connessioni VPN. OpenVPN© è uno dei più diffusi software per la creazione di tunnel VPN per connessioni remote sicure. Smartworking o telelavoro sono ormai diventate modalità di lavoro ampiamente diffuse e OpenVPN© è uno strumento che permette di implementarle e supportarle in maniera sicura e veloce.

Generalmente OpenVPN© ha come impostazioni di default la porta di ascolto 1194/UDP e la scadenza dei certificati (client, server e CA) impostata a 3650 giorni, cioè 10 anni. OpenVPN Rinnovo e Verifica Certificato descrive le principali operazioni da effettuare.

Per verificare la scadenza di un certificato, per esempio della CA possiamo usare il comando:

  • #openssl x509 -in ca.crt -text -noout | grep After

oppure per verificare la scadenza di un certificato, per esempio del server possiamo usare il comando:

  • #openssl x509 -in server.crt -text -noout | grep After

il risultato sarà del tipo:

  • Not After : Sep 13 13:48:00 2029 GMT

che indica la data di termine validità del cerificato in questione.

Scopo di questo breve articolo è quello di illustrare come rinnovare o creare certificati con durata diversa dallo standard.  Per modificare la durata dei certificati è possibile agire in due modi:

  • Attraverso il file di configurazione vars presente in /etc/openvpn. Questo file valorizza i vari parametri utilizzati dagli script di generazione dei certificati. In particolare i parametri coinvolti sono:
    • export CA_EXPIRE=3650
    • export KEY_EXPIRE=3650
      entrambi i valori possono essere modificati secondo l’esigenza.
      Dopo aver modificato i valori contenuti nel file vars, per generare un certificato si utilizzano i seguenti comandi:
    • #. vars o #source vars
      #./buid-key-server <NOME>
      in caso di rinnovo è necessario specificare un <NOME> diverso da quello per evitare  l’errore di update database.
  • DIrettamente in fase di rinnovo con il comando:
    • openssl x509 -in ca.crt -days 36500 -out ca.crt.new -signkey ca.key
      specificando esplicitamente il numero di giorni ad es. 10 anni

 

Tunnel SSH

by • Networking • Tags: • 0 Comments

La necessità di utilizzare un tunnel SSH per connettersi ad apparati remoti è spesso dettata dall’avere dei collegamenti sicuri verso servizi che potrebbero presentare dei problemi di sicurezza.

Se per esempio abbiamo un apparato dotato di interfaccia web al quale vogliamo connetterci in sicurezza possiamo farlo creando un tunnell ssh attraverso il quale far passare il traffico.

In questa breve guida useremo un client ssh per ambiente windows di nome putty.exe ed il browser mozilla firefox.

Prima di tutto configuriamo il client ssh per la creazione del tunnel, dopo aver lanciato il client inserire l’indirizzo IP al quale vogliamo collegarci, modificando, se necessario la porta:

putty.exe

Selezioniamo dal menu in basso a sinistra la voce SSH e quindi la voce Tunnels ed inseriamo i seguenti valori:

Source port 17222 (inserire una porta qualsiasi) – Selezionare Dynamic – Premere Add

putty

Quindi premere il tasto Open ed inserire le credenziali di accesso, dopo aver ottenuto l’accesso lasciare la finestra aperta e configurare il browser per il collegamento attraverso il tunnel.

Apriamo Firefox e selezionare Strumenti –> Opzioni –> Avanzate.

Nel menù avanzate selezionare Rete à Impostazioni, configurare i valori come segue:

  • Selezionare “Configurazione manuale dei proxy”
  • Alla voce Host SOCKS inserire 127.0.0.1 e porta 17222 (stessa porta inserita in putty.exe)

firefox avanzate

Quindi selezionare OK.

Ora tutto il traffico web verrà instradato verso il tunnel.

WILDCARD MASK

by • Networking • Tags: , , • 0 Comments

La gestione del traffico IPv4 basato sul filtraggio di indirizzi IP non può prescindere dal concetto di WILDCARD MASK, una sequenza di 32 bit che indica quali bit dell’indirizzo IP devono essere considerati per applicare le regole di filtro.

La wildcard mask si presenta in maniera simile alla subnet mask ma con regole del tutto diverse. Mentre la subnet mask identifica la network e la parte host dell’indirizzo, la wildcard mask utilizza i bit 0 e 1 per identificare i singoli indirizzi IP o ad un gruppo di essi in un modo molto più flessibile rispetto alla rigidità della subnet mask.

Le regole che la wildcard segue sono le seguenti:

  • Bit a 0 – il corrispondente bit dell’indirizzo IP viene controllato
  • Bit a 1 – il corrispondente bit dell’indirizzo IP viene ignorato

Vediamo un esempio:

Indirizzo IP        192.168.001.000              11000000.10101000.00000001.00000000

Wildcard mask   000.000.000.255              00000000.00000000.00000000.11111111

Applicando la maschera 0.0.0.255 all’IP 192.168.1.0 si ottiene una selezione di tutti gli IP che hanno i primi tre byte posti a 192.168.1, l’ultimo byte viene ignorato.

A prima vista sembrerebbe il complementare della subnet mask, infatti il risultato dell’esempio precedente è la network 192.168.1.0 255.255.255.0. In realtà la wildcard mask permette di superare il concetto di network identificando l’indirizzo IP o i gruppi di indirizzi IP in base ai singoli bit degli stessi.

Supponiamo, per esempio, di voler selezionare tutti gli indirizzi dispari della network 192.168.1.0/24. Con la subnet mask  tale compito sarebbe impossibile, mentre con la wildcard mask:

  • Fisso i primi tre byte della 0 così da verificare il matching di essi con 192.168.1
  • Considerato che tutti gli indirizzi dispari finiscono con l’ultimo bit dell’ultimo byte a 1 dovrò considerare l’ultimo byte della maschera in modo che garantisca il matching dell’ultimo bit quindi 11111110. Avrò quindi la wildcard mask pari a 0.0.0.254 che applicata all’indirizzo 192.168.1.1 selezionerà tutti gli indirizzi dispari della rete 192.168.1.0, applicata all’indirizzo 192.168.1.2 selezionerà tutti gli indirizzi pari della medesima rete.

192.168.001.001 –> 00000001                                                                          192.168.001.002 –> 00000010

000.000.000.254 –> 11111110           controlla solo l’ultimo bit dell’Ip            000.000.000.254 –> 11111110

Facciamo un altro esempio per meglio chiarire il concetto:

supponiamo di voler selezionare gli ip della rete 192.168.1.0/24 il cui ultimo byte va da 4 a 7 cioè da 192.168.1.4 a 192.168.1.7

.4 –> 00000100

.7 –> 00000111

Si nota facilmente che gli ultimi due bit identificano, variando, il range di ip che ci interessa, quindi la wildcard mask da utilizzare dovrà ignorare il controllo sugli ultimi due bit lasciando fissi gli altri, pertanto la wildcard mask da utilizzare sarà 0.0.0 con ultimo byte pari a 00000011 cioe’ .3

In conclusione 192.168.1.4 0.0.0.3 seleziona gli indirizzi IP nel range 192.168.1.4 – 192.168.1.7.

 

IPV6 o IP New Generation

by • Networking • Tags: , , , , , , , • 0 Comments

IPv6 nasce con lo scopo di superare i diversi limiti insiti al protocollo IPv4. L’utilizzo di indirizzi di tipo IPv4 introduce alcune problematiche che, anche se oramai assuefatti dall’uso quotidiano, hanno notevoli ripercussioni in termini di prestazioni e sicurezza.

L’Esaurimento degli indirizzi IPv4 è forse il problema più grosso che il mondo del networking sta ormai da tempo affrontando. Nonostante i circa 4,3 miliardi di indirizzi IPv4 disponibili, solo 3,7 miliardi sono quelli usabili numero decisamente insufficiente per gestire il sempre crescente fabbisogno di connettività. L’introduzione della NAT, tecnologia comunemente utilizzata nel mondo IPv4 a causa della carenza di indirizzi e necessaria per condividere lo stesso IP pubblico tra diversi host, spesso introduce problematiche in applicazioni che richiedono una connettività end-to-end.

Nel 1990 IETF per superare le limitazioni derivanti dall’utilizzo del protocollo IPv4 definisce una nuova versione del protocollo IP, la versione 6 o new generation.

L’apparente complessità della rappresentazione dell’indirizzamento IPv6 viene velocemente superata dalle moltiplici semplificazioni ed ottimizzazioni introdotte e che apportano notevoli migliorie a livello funzionale. Vediamo, di seguito, alcune delle principali novità introdotte:

  • Aumento del numero di indirizzi l’indirizzo IP passa da 32 bit a 128 bit quindi si passa da circa 4,7 miliardi di indirizzi a 3,4 x 1038 indirizzi, un numero enorme, basti pensare che se con l’IPv4 possiamo avere 0,000007 indirizzi per ogni m2 di superficie terrestre, con l’IPv6 ne abbiamo 655.571 miliardi di miliardi.
  • Miglioramento Gestione Pacchetti l’header è stato notevolmente semplificato riducendo il numero di campi. E’ stato Inoltre introdotto un supporto per applicazioni Real-Time.
  • NAT non necessario Grazie alla grande quantità di indirizzi IP disponibili non è più necessaria l’implementazione della NAT.
  • Sicurezza IPv6 supporta nativamente autenticazione e privacy.
  • Header A differenza dell’header IPv4 che è composto da 20 byte (che diventavano 60 byte in caso di utilizzo degli option fields) e 12 campi fondamentali, l’Header IPv6 è composto da 40 byte (in gran parte dovuti all’aumento delle dimensioni dell’indirizzo sorgente e destinatario) ed 8 campi dei quali 3 derivanti dal vecchio Header IPv4.

header IPv6

In giallo sono riportati i campi ereditati da IPv4 ma rinominati.

Version       (4 bit) indica la versione del protocollo che per IPv6 è 0110.

Traffic Class (8 bit) Equivalente al DS (Differentiated Service) dell’IPv4 è composto da DSCP (6 bit) + ECN (2 bit).

Flow Label (20 bit) Indica il flusso di pacchetti. Creato per applicazioni critiche (Real time) può essere usato per indicare ai routers di mantenere i medesimi percorsi per i pacchetti con uguale valore di campo in modo da evitare il riordino dei pacchetti a destinazione.

Payload Length (16 bit) Come per IPv4 rappresenta la lunghezza dell’intero pacchetto.

Next Header (8 bit) Identifica generalmente il tipo di protocollo di livello transport che è utilizzato dal payload. Il campo è utilizzato in alternativa per indicare il tipo di extension header che segue. Per esempio il valore 59 indica nessun next header, il valore 58 indica next header di tipo ICMPv6, il valore 50 indica Encapsulation Security Payload (ESP), ecc.

Hop Limit (8 bit) Equivalente al campo TTL dell’IPv4. Il valore di questo campo viene decrementato ogni volta che il pacchetto attraversa un hop. Quando arriva al valore zero il pacchetto viene scartato.

Source Address (128 bit) Indirizzo Sorgente

Destination Address (128 bit) Indirizzo Destinazione