msgbartop
Blog di Dino Ciuffetti (Bernardino in realtà)
msgbarbottom

09 Mar 20 Disquisizioni su errori procedurali in ambito enterprise riguardo alla generazione e all’implementazione dei certificati SSL X509

Breve (anzi no) premessa senza entrare troppo nei dettagli di natura tecnica spinta. In sostanza i certificati X509 possono essere di varia natura e formato ma tutti governati dallo standard X.509 (https://en.wikipedia.org/wiki/X.509) che e’ uno standard internazionale. Secondo come vengono richiesti e poi emessi dalla CA competente (Certification Authority) hanno delle proprietà specifiche, alcune obbligatorie ed altre che cambiano in base alle applicazioni.

La crittografia asimmetrica basasta su certificati X.509 permette la mutua autenticazione (il client verifica il server e viceversa), cripta il canale di comunicazione impedendo il “man in the middle” ovvero rende impossibile per un attore che non conosce le chivi private client e server di poter “sniffare” il traffico mettendosi in mezzo, e conferma la veridicita’ e inalterabilita’ del messaggio in transito, oltre a verificare in modo inequivocabile chi l’ha inviato.

Per generare un certificato vi è sempre necessità di utilizzare una chiave privata (che va sempre tenuta segreta in quanto essa e’ in grado tra l’altro di decifrare i messaggi!). Operativamente e’ possibile generare una nuova chiave privata qualora quella precedente venga compromessa, oppure se si vuole cambiarla per motivi di sicurezza in generale, o ancora se viene richiesto dalla CA competente. Esse possono essere inaccessibili (ad esempio immagazzinate all’interno di una smartcard, un token di autenticazione, un wallet, etc) oppure accessibili. Nel caso fossero accessibili possono essere cifrate (protette da passphrase) oppure in chiaro. In base alla tecnologia su cui e’ implementata la PKI (Public Key Infrastructure) le chiavi possono essere salvate in un file (protetto contro letture non abilitate), un database, etc, ma solitamente non e’ altro che un contenitore come ad esempio un PKCS#12, un PKCS#8, un KeyStore Java (JKS), un Wallet Oracle, IBM, etc, etc.
E’ necessario, come appena detto, utilizzare una private key per generare un nuovo certificato, e questo viene fatto mediante la generazione di una richiesta di certificazione (CSR: Certification Signing Request, anche conosciuto come PKCS#10) che va inoltrata alla CA competente. Sebbene sia possibile generarsi un certificato da soli (self signed certificate) questa NON va considerata buona prassi ma bisognerebbe sempre utilizzare un Ente Certificatore preposto allo scopo. Il PKCS#10 contiene tutte le informazioni che servono alla CA per poter emettere un certificato X.509 valido e verificare in seguito che il richiedente sia quello corretto e il certificato “faccia scopa” con la chiave privata (per mezzo della firma digitale apposta dal richiedente per mezzo della sua chiave privata). Infatti, la chiave privata e il certificato che ne deriva hanno SEMPRE lo stesso “modulo”, cosa MAI vera se il certificato NON deriva da quella chiave privata ma da un’altra. E’ quindi possibile verificare che un determinato certificato derivi da una particolare chiave privata. Da un certificato non e’ possibile ottenere, ovviamente, una chiave privata, altrimenti tutto sarebbe inutile.

Una volta generato il CSR e il conseguente certificato la chiave privata NON va assolutamente buttata ma conservata in modo sicuro e configurata dove serve: senza di essa il certificato sarà completamente inutile e bisognerà rigenerarne un altro con una nuova chiave privata.

A seconda delle varie applicazioni e’ necessario, come sappiamo, implementare e scambiarsi uno o piu’ certificati SSL. Le chiavi private NON si scambiano mai!
Per quello che ci interessa in questa istanza, possiamo identificare le seguenti caratteristiche:

CERTIFICATO SERVER
 |caso 1|–> INSTALLATO SU UN SERVER (apache, tomcat, bea, etc): viene esposto su un server per implementare, ad esempio, il protocollo TLS con le relative ciphersuite. Il server invia il proprio certificato in fase di handshake per poter essere riconosciuto dal client che effettua la richiesta. Configurato come tale ha sempre bisogno della relativa chiave privata (come detto non una a caso ma esattamente quella che e’ stata utilizzata per la generazione e la firma del CSR) ed infatti per le tecnologie basate su java viene conservato nel cosiddetto KeyStore (ad esempio su tomcat e’ puntato dall’attributo keystoreFile nel connettore).
 |caso 2|–> INSTALLATO SU UN CLIENT: il certificato server viene utilizzato dal client per considerare TRUSTED (viene data fiducia) al server in fase di handshake. In questo caso non vi e’ alcun bisogno della chiave privata e infatti chi gestisce il server e ce lo invia la manterra’ privata. Nelle tecnologie java questi certificati vengono inseriti nel cosiddetto TrustStore (come ad esempio il cacerts della JVM).

CERTIFICATO CLIENT
 |caso 3|–> INSTALLATO SU UN CLIENT (ad esempio un browser, ma piu’ solitamente un’applicazione come Apache Axis, un client di una API, un client webservice o un reverse proxy come apache per la sua componente client – guardare ad es. direttiva SSLProxyMachineCertificateFile): viene esposto su un client per implementare la mutua autenticazione. In tal caso il client viene configurato per pubblicare il suo certificato al server in fase di handshake per poter essere riconosciuto dal server. Se configurato come tale ha sempre bisogno della relativa chiave privata (come detto non una a caso ma esattamente quella che e’ stata utilizzata per la generazione e la firma del CSR). Anche in questo caso, come per un certificato server installato su un server (caso 1), il certificato e la relativa chiave privata vanno in un KeyStore (in questo caso non del middleware ma dell’applicazione).
 |caso 4|–> INSTALLATO SU UN SERVER: il certificato client viene utilizzato dal server per considerare TRUSTED (viene data fiducia) al client in fase di handshake, come succede per un certificato server installato su un client (caso 2). Anche in questo caso la chiave privata non serve perche’ chi ce la invia (il client) la mantiene privata. Su tecnologie java, anche in questo caso, il certificato va installato nel TrustStore (in questo caso solitamente dell’applicazione o della JVM).

In tutte e 4 le casistiche indicate, i certificati non vanno installati da soli ma sempre completi della catena di certificazione (detto Chain of Trust), ovvero insieme al certificato della CA che lo ha emesso e nel caso di una CA Intermedia vanno installati tutti i certificati delle varie CA fino a quello della ROOT CA (la prima della catena). Se c’e’ un ordine questo deve procedere dal certificato utente fino a quello della ROOT CA che va installato per ultimo.

Da questo ne conseguono i seguenti punti di interesse di operation:
1) il trustStore NON ha mai chiavi private al suo interno ma solo certificati della controparte da autenticare (se sono server avro’ i certificati dei client, se sono client avro’ i certificati dei server).
2) l’applicazione puo’ usare piu’ trustStore e se e’ scritta in java vince il trustStore cacerts dentro “jre/lib/security/”
3) il keyStore avra’ il certificato con relativa chiave privata e non avra’ i certificati della controparte.
4) l’inserimento nel trustore e nel keystore prevede l’inserimento di tutta la catena di certificazione, ovvero i certificati delle varie CA
5) le operazioni per richiedere alla CA un certificato server o uno client sono le medesime, ma la CA scolpirà all’interno del certificato lo scopo per cui esso viene rilasciato (solo client, solo server o client/server). Diventa quindi importante richiedere alla CA la giusta tipologia di certificato perche’ il server o il client possono/devono verificare il corretto scopo del certificato.
6) sono previste le 4 diverse configurazioni del client e del server indicate sopra. Queste si differenziano nel caso in cui devono solo trustare le controparti (sia essa client o server, quindi senza chiave privata, ovvero i casi 2 e 4) oppure nel caso in cui si debba implementare il servizio vero e proprio (sia esso client o server, con chiave privata, ovvero i casi 1 e 3), con o senza mutua autenticazione
7) se non e’ prevista la mutua autenticazione il client non ha mai bisogno di un keyStore (certificato con chiave privata) ma solo di un trustStore per verificare il server. Nel caso di alcuni middleware o applicazioni non serve neanche quest’ultimo.
8) per un server il discorso e’ opposto, ovvero il server ha sempre e comunque bisogno di un keyStore ma se non c’e’ mutua autenticazione non ha bisogno di un trustStore per verificare il client.
9) le applicazioni o i middleware client e server possono essere configurati e/o implementati per verificare nel modo piu’ disparato e piu’ o meno strettamente i certificati della controparte. Posso ad esempio ignorare che un certificato della controparte sia scaduto o posso comunque fidarmi del certificato della controparte a prescindere che esso sia trustato nel mio truststore e posso ignorare completamente gli attributi del certificato e fidarmi comunque. Oppure invece posso andare a leggere e controllare scrupolosamente e puntualmente il certificato della controparte e verificare, ad esempio, una o piu’ cose tra cui: il seriale del certificato, il suo ente certificatore, il suo scopo, la scadenza, la scadenza del certificato della CA, il CN con cui viene pubblicato, se e’ stato revocato dalla CA (su richiesta del richiedente perche’ magari e’ stata compromessa la private key, oppure dalla ca stessa perche’ magari non si fidano piu’ dell’algoritmo di firma o delle procedure di rilascio, etc), se gli attributi di scopo sono rispettati (solo server, solo client, client/server, solo CA, solo firma digitale, etc), se il certificato e’ distribuito per una lista di nomi (SAN) o per un nome solo e essi fanno scopa con il servizio, etc, etc, etc.

Ne consegue quindi che le configurazioni possono essere molto personalizzate e flessibili e testare tutte le casistiche possibili non e’ fattibile. Forse la cosa migliore e’ lavorare a livello di documentazione, specialmente sulle procedure del singolo progetto.

In linea di massima possiamo riassumere le seguenti macro procedure di operation per le casistiche indicate sopra. Essendoci diverse tecnologie le modalita’ operative sono molto diverse nella forma ma uguali nella sostanza:

DEVO IMPLEMENTARE UN SERVER:
1) genero una chiave privata o uso quella precedente se la CA me lo consente (soddisfando i requisiti dettati da CA, esempio RSA 2048 bit)
2) genero un CSR a partire dalla chiave al punto 1 impostando nella richiesta tutti i parametri corretti (CN, scopo server, OU corretto, stato, paese, etc)
3) invio il CSR alla CA di competenza
4) ottengo il certificato solo server oppure client/server dalla CA
5) imposto il mio certificato sul keystore del server di cui sono responsabile insieme alla chiave privata al punto 1 e insieme ai certificati delle CA che lo hanno emesso
6) invio il mio certificato e quello della CA alle controparti SENZA inviare la chiave privata.
SE DEVO ATTIVARE MUTUA AUTENTICAZIONE (OVVERO FORZARE LA VERIFICA DEL CERTIFICATO CLIENT DELLA CONTROPARTE) FARO’ ANCHE QUESTE:
7) richiedo il certificato della controparte
8) inserisco nel mio truststore client o server il certificato della controparte e lo rendo TRUSTED insieme alle loro CA
9) forzo sul middleware le verifiche sui certificati appena messi nel truststore o implemento dei blocchi piu’ restrittivi, ad esempio controllando bene i certificati delle controparti affinche’ rispettino i requisiti di sicurezza richiesti dal progetto

DEVO IMPLEMENTARE UN CLIENT:
  di norma non serve fare nulla se non e’ richiesta mutua autenticazione. In alcune tecnologie, come ad esempio quelle basate su java potrei dover comunque effettuare i punti 1 e 2 indicati sotto:
SE DEVO ATTIVARE MUTUA AUTENTICAZIONE (OVVERO FORZARE LA VERIFICA DEL CERTIFICATO SERVER DELLA CONTROPARTE):
1) ottengo il certificato server dalla controparte
2) in base al middleware e alla tecnologia lo considero trusted sul mio truststore
3) genero una chiave privata o uso quella precedente se la CA me lo consente (soddisfando i requisiti dettati da CA, esempio RSA 2048 bit)
4) genero un CSR a partire dalla chiave al punto 1 impostando nella richiesta tutti i parametri corretti (CN, scopo client, OU corretto, stato, paese, etc)
5) invio il CSR alla CA di competenza
6) ottengo il certificato solo client oppure client/server dalla CA
7) imposto il mio certificato sul keystore del client di cui sono responsabile insieme alla chiave privata al punto 1 e insieme ai certificati delle CA che lo hanno emesso
8) invio il mio certificato e quello della CA alle controparti SENZA inviare la chiave privata
9) forzo sul middleware o sull’applicazione le verifiche sui certificati appena messi nel truststore o implemento dei blocchi piu’ restrittivi, ad esempio controllando bene i certificati delle controparti affinche’ rispettino i requisiti di sicurezza richiesti dal progetto

La maggior parte degli errori, per esperienza, avviene a livello procedurale perche’ spesso chi effettua l’attivita’ non ha la chiara visibilita’ o competenza su tutto il “giro del fumo”, oppure perche’ le informazioni si perdono (ad esempio in caso di passaggio di consegne). Per lo stesso motivo, in caso di disservizio, diventa lungo anche per noi di TS identificare il problema, non conoscendo bene tutte le applicazioni possibili.

Gli errori piu’ frequenti, comunque, risultano essere:

1) un mio certificato (server o client) scade creando disservizio alle controparti;
2) un mio certificato (server o client) viene (ri)generato con le modalita’ non corrette rispetto ai requisiti di progetto creando disservizio alle controparti
3) un certificato (server o client) di una controparte scade e mi crea un disservizio;
4) un certificato (server o client) di una controparte viene (ri)generato con le modalita’ non corrette rispetto ai requisiti di progetto e mi crea un disservizio
5) (ri)genero un certificato e non lo invio alle controparti, appena entra in campo potrei creare disservizio alle controparti
6) una controparte (ri)genera un certificato e non me lo invia, appena entra in campo potrei avere un disservizio
7) potrei per errore inviare alle controparti un certificato sbagliato, magari vecchio o di un altro progetto creando disservizio alle controparti
8) potrei ricevere per errore da una controparte un certificato sbagliato, magari vecchio o di un altro progetto ottenendo un disservizio
9) potrei inviare un certificato corrotto
10) potrei ricevere un certificato corrotto
11) essendoci vari formati (JKS, PEM, DER, P12, PFX, etc) potrei inviare un certificato in un formato che non si aspettano
12) potrei ricevere un certificato in un formato che non mi aspetto

Ricapitolando quindi, sia che ottengo, sia che sto inviando un certificato, esso deve sempre:
1- essere in corso di validita’ (non scaduto)
2- rispettare i requisiti di progetto (CN giusto, formato giusto, CA giusta, SAN, scopo, paese, attributi, etc)
3- essere installato e configurato correttamente sul mio middleware, sulla mia applicazione o su quelle di tutte le controparti

Il caso 1 e’ facilissimo da verificare e da prevedere, basta scaricarsi il certificato e verificare la data di scadenza;
Per il caso 2 bisogna verificare che il certificato faccia scopa con una serie di regole dettate dal singolo progetto o dalla singola tecnologia, volendo e’ possibile verificarlo rispetto ad uno che precedentemente andava bene e far saltare all’occhio le eventuali differenze perche’ potrebbero provocare un probabile disservizio;
Anche per il punto 3 la modalita’ di verifica cambia in base alla tecnologia o al progetto: se si tratta di un server si potrebbe invocare il servizio e prendersi il certificato esposto e verificarlo con le specifiche del progetto o con le proprieta’ di base che ci aspetteremmo da quel certificato. Se c’e’ mutua autenticazione il server potrebbe non risponderci fino a che non gli inviamo un certificato client valido che lui considera attendibile. Se invece e’ un client non si puo’ verificare da remoto ma solo in locale sulla macchina conoscendo il path ed avendo i giusti privilegi di accesso.

Allo stato attuale è possibile preparare uno shell script che permette di verificare visivamente un certificato X509, sia locale che remoto, e di mostrare tutte le sue proprieta’ e la data di emissione e scadenza.

Da qui a scriptare per risolvere i punti 2 e 3 la vedo molto complicata perche’ i requisiti e le tecnologie sono tutte diverse…

Ho completamente tralasciato tutto quello che riguarda i protocolli e le ciphersuite perche’ quello e’ un altro capitolo e la disquisizione e’ gia’ troppo lunga!

Buon Certificato X509 a tutti!

28 Dic 19 How to encrypt and decrypt a text file with vim

I always use VIM any single day of my life starting from 1994, and I did not realize that it’s now possible to encrypt and decrypt files with it without using gnupg! This is one of the reasons why I love vim so much: there are always things that you can learn from it!
So, I’ll now show you how to use vim to encrypt and decrypt your text files.

We can start creating a new encrypted text file with the command below:

# vim -x encryptedfile.txt
Enter encryption key:
Enter same key again:

Once you’ve entered an encryption key (WARNING: don’t forget it or you will lose your clear text data forever!!!) you can use vim as always, write your clear text data, save and quit.

# file encryptedfile.txt
encryptedfile.txt: Vim encrypted file data
# cat encryptedfile.txt
VimCrypt~03!�-
�
��[�v��>P��(�%

So, your file is now encrypted. To recover access to your clear text data, just open the file back with vim using the correct passphrase you used to create your file:

# vim encryptedfile.txt
Need encryption key for "encryptedfile.txt"
Enter encryption key:

You could also decide to change your passphrase or encrypt a clear text file, using the :set key=pwd vim command, like this:

:set key=mystrongpasswordyou'llneverfind
:wq
# file encryptedfile.txt 
encryptedfile.txt: Vim encrypted file data

If you want to decrypt the file and save it clear text, just use an empty key with the :set key= command, after you opened the encrypted file with the correct passphrase:

:set key=
:wq
# file encryptedfile.txt
encryptedfile.txt: ASCII text

So, this way you can create an encrypted file protected with a passphrase, get read/write access to the encrypted file, decrypt the file to clear text and change the passphrase.

Hope you all will enjoy this like me!!

10 Dic 19 How to view files and directory name representration as a tree on linux

There is a cool command on linux that can be used to view directories and files in a cool tree way, this is called tree.

Try this one:

tree -shugaDFC --du

You hopefully get something formatted like this:

.
├── [root     root       40 Dec 10 11:38]  .font-unix/
├── [root     root       80 Dec 10 11:39]  .ICE-unix/
│   ├── [Debian-gdm Debian-gdm    0 Dec 10 11:38]  2040=
│   └── [dino     dino        0 Dec 10 11:39]  2530=
├── [dino     dino        0 Dec 10 11:51]  opensc-debug.log
├── [root     root       40 Dec 10 11:38]  pulse-PKdhtXMmr18n/
├── [root     root        0 Dec 10 11:38]  SemFetchAndIncSem
├── [dino     dino       60 Dec 10 11:39]  ssh-Lu1SMknjwYCh/
│   └── [dino     dino        0 Dec 10 11:39]  agent.2530=
├── [root     root      140 Dec 10 11:38]  systemd-private-6ca1b00e83794d86a258dafff95a5ade-apache2.service-LGtMHO/
│   └── [root     root       80 Dec 10 11:38]  tmp/
│       ├── [root     root        0 Dec 10 11:38]  access_log
│       └── [root     root        0 Dec 10 11:38]  error_log
├── [root     root      100 Dec 10 11:39]  systemd-private-6ca1b00e83794d86a258dafff95a5ade-bolt.service-uuY7ay/
│   └── [root     root       40 Dec 10 11:39]  tmp/
├── [root     root      100 Dec 10 11:38]  systemd-private-6ca1b00e83794d86a258dafff95a5ade-colord.service-8gsnRd/
│   └── [root     root       40 Dec 10 11:38]  tmp/
├── [root     root      100 Dec 10 11:39]  systemd-private-6ca1b00e83794d86a258dafff95a5ade-fwupd.service-6puu9X/
│   └── [root     root       40 Dec 10 11:39]  tmp/
├── [root     root      100 Dec 10 11:38]  systemd-private-6ca1b00e83794d86a258dafff95a5ade-minissdpd.service-BJBYoN/
│   └── [root     root       40 Dec 10 11:38]  tmp/
├── [root     root      100 Dec 10 11:38]  systemd-private-6ca1b00e83794d86a258dafff95a5ade-ModemManager.service-T2ih67/
│   └── [root     root       40 Dec 10 11:38]  tmp/
├── [root     root      100 Dec 10 11:38]  systemd-private-6ca1b00e83794d86a258dafff95a5ade-ntp.service-DWl6NV/
│   └── [root     root       40 Dec 10 11:38]  tmp/
├── [root     root      100 Dec 10 11:38]  systemd-private-6ca1b00e83794d86a258dafff95a5ade-rtkit-daemon.service-B5JIPO/
│   └── [root     root       40 Dec 10 11:38]  tmp/
├── [root     root      100 Dec 10 11:38]  systemd-private-6ca1b00e83794d86a258dafff95a5ade-systemd-resolved.service-N3OP1K/
│   └── [root     root       40 Dec 10 11:38]  tmp/
├── [root     root      100 Dec 10 11:38]  systemd-private-6ca1b00e83794d86a258dafff95a5ade-upower.service-1MLpQa/
│   └── [root     root       40 Dec 10 11:38]  tmp/
├── [dino     dino       40 Dec 10 12:38]  Temp-78a83a1b-0d23-4bb2-b176-e7ae54b4b2d6/
├── [dino     dino       40 Dec 10 12:38]  Temp-897559cc-50ea-4ac1-b4da-780a5864e32c/
├── [dino     dino       40 Dec 10 11:52]  Temp-a7dd7308-8df0-42b3-9188-6ce51c3da1de/
├── [root     root       40 Dec 10 11:38]  .Test-unix/
├── [dino     dino       40 Dec 10 11:39]  tracker-extract-files.1000/
├── [root     root       80 Dec 10 11:39]  .X11-unix/
│   ├── [Debian-gdm Debian-gdm    0 Dec 10 11:38]  X0=
│   └── [dino     dino        0 Dec 10 11:39]  X1=
└── [root     root       40 Dec 10 11:38]  .XIM-unix/

 2.0K used in 31 directories, 9 files

If you get an error like command not found: tree then you have to install the tree package. For example, on debian/ubuntu:

apt install tree

You can experiment with tree alone or using different switches.

23 Ott 18 How to disable Diffie-Hellman ciphers on apache

If you are getting errors like “DH key too small” you can avoid using DH ciphersuites on apache.
You can obtain that using Perfect forward secrecy, or disabling all DH ciphersuites like this:

SSLCipherSuite ALL:!EXP:!NULL:!DH:!LOW

06 Lug 18 How to setup xtables GeoIP for iptables on OpenWRT

I’m not racist, but sometimes you may need to keep some people out of your network based on its geographical region… in reality I’m referring to its public source IP address.

Requests are coming from the big internet, so you can check if the source IP of the peers that are trying to connect to your powerful OpenWRT Linux router are coming from a particular region and you may want to stop all those requests accordingly.

If you are using iptables and ip6tables (if you are on linux this is the standard) you can setup GeoIP based packet filtering with iptables: it’s an iptables extension that make use of the glorious and free MaxMind GeoLite Legacy Downloadable Database (that is now dying…).

On OpenWRT this is supported automatically, but generally your router does not have all the disk space to host the entire GeoLite GeoIP database. So, you need to prepare all the records of the geographical regions that you want to block on your firewall.

Take a linux workstation or server (your notebook, a raspberry pi you own always on, one of your client’s server… better not IMHO…) and run those commands:

root@firegate2:~# mkdir /tmp/temp
root@firegate2:~# cd /tmp/temp
root@firegate2:/tmp/temp# /usr/share/xt_geoip/xt_geoip_dl
–2018-07-05 23:54:40– http://geolite.maxmind.com/download/geoip/database/GeoIPv6.csv.gz
Risoluzione di geolite.maxmind.com (geolite.maxmind.com)… 104.16.37.47, 104.16.38.47, 2400:cb00:2048:1::6810:262f, …
Connessione a geolite.maxmind.com (geolite.maxmind.com)|104.16.37.47|:80… connesso.
Richiesta HTTP inviata, in attesa di risposta… 200 OK
Lunghezza: 1715246 (1,6M) [application/octet-stream]
Salvataggio in: “GeoIPv6.csv.gz”

GeoIPv6.csv.gz 100%[================================================================>] 1,64M –.-KB/s in 0,1s

2018-07-05 23:54:40 (10,9 MB/s) – “GeoIPv6.csv.gz” salvato [1715246/1715246]

–2018-07-05 23:54:40– http://geolite.maxmind.com/download/geoip/database/GeoIPCountryCSV.zip
Riutilizzo della connessione esistente a geolite.maxmind.com:80.
Richiesta HTTP inviata, in attesa di risposta… 200 OK
Lunghezza: 2540312 (2,4M) [application/zip]
Salvataggio in: “GeoIPCountryCSV.zip”

GeoIPCountryCSV.zip 100%[================================================================>] 2,42M 11,3MB/s in 0,2s

2018-07-05 23:54:40 (11,3 MB/s) – “GeoIPCountryCSV.zip” salvato [2540312/2540312]

TERMINATO –2018-07-05 23:54:40–
Tempo totale: 0,4s
Scaricati: 2 file, 4,1M in 0,4s (11,1 MB/s)
Archive: GeoIPCountryCSV.zip
inflating: GeoIPCountryWhois.csv
root@firegate2:/tmp/temp#
root@firegate2:/tmp/temp# /usr/share/xt_geoip/xt_geoip_build -D . *.csv
209370 entries total
0 IPv6 ranges for A1 Anonymous Proxy
32 IPv4 ranges for A1 Anonymous Proxy
0 IPv6 ranges for A2 Satellite Provider
36 IPv4 ranges for A2 Satellite Provider
3 IPv6 ranges for AD Andorra
26 IPv4 ranges for AD Andorra
51 IPv6 ranges for AE United Arab Emirates
302 IPv4 ranges for AE United Arab Emirates
… and continues …
11 IPv6 ranges for ZM Zambia
64 IPv4 ranges for ZM Zambia
14 IPv6 ranges for ZW Zimbabwe
59 IPv4 ranges for ZW Zimbabwe
root@firegate2:/tmp/temp#

The script /usr/share/xt_geoip/xt_geoip_build it’s part of xtables-addons package that you may or may not find on your distribution. Search on google for that.

This will create LE and BE directories. Now you want to extract only the geo regions that you need (ex: CN,UA,TW,VN,VG,KP,VI,KR), like that:

root@firegate2:/tmp/temp# du -csh BE/CN.iv? BE/UA.iv? BE/TW.iv? BE/VN.iv? BE/VG.iv? BE/KP.iv? BE/VI.iv? BE/KR.iv? LE/CN.iv? LE/UA.iv? LE/TW.iv? LE/VN.iv? LE/VG.iv? LE/KP.iv? LE/VI.iv? LE/KR.iv?
36K BE/CN.iv4
48K BE/CN.iv6
24K BE/UA.iv4
16K BE/UA.iv6
8,0K BE/TW.iv4
4,0K BE/TW.iv6
4,0K BE/VN.iv4
4,0K BE/VN.iv6
4,0K BE/VG.iv4
4,0K BE/VG.iv6
4,0K BE/KP.iv4
0 BE/KP.iv6
4,0K BE/VI.iv4
4,0K BE/VI.iv6
8,0K BE/KR.iv4
4,0K BE/KR.iv6
36K LE/CN.iv4
48K LE/CN.iv6
24K LE/UA.iv4
16K LE/UA.iv6
8,0K LE/TW.iv4
4,0K LE/TW.iv6
4,0K LE/VN.iv4
4,0K LE/VN.iv6
4,0K LE/VG.iv4
4,0K LE/VG.iv6
4,0K LE/KP.iv4
0 LE/KP.iv6
4,0K LE/VI.iv4
4,0K LE/VI.iv6
8,0K LE/KR.iv4
4,0K LE/KR.iv6
352K totale

So, in this case we will need 352 Kb of router disk space. After we created the /usr/share/xt_geoip/BE/ and /usr/share/xt_geoip/LE/ directories on our router’s filesystem:

root@dam2ktplinkrouter:~# mkdir -p /usr/share/xt_geoip/BE /usr/share/xt_geoip/LE

We are going to copy those files on our OpenWRT router:

root@firegate2:/tmp/temp# scp LE/CN.iv? LE/UA.iv? LE/TW.iv? LE/VN.iv? LE/VG.iv? LE/KP.iv? LE/VI.iv? LE/KR.iv? root@192.168.10.1:/usr/share/xt_geoip/LE
root@192.168.10.1’s password:
CN.iv4 100% 35KB 109.8KB/s 00:00
CN.iv6 100% 47KB 76.0KB/s 00:00
UA.iv4 100% 23KB 108.4KB/s 00:00
UA.iv6 100% 15KB 87.9KB/s 00:00
TW.iv4 100% 4704 47.5KB/s 00:00
TW.iv6 100% 3104 77.8KB/s 00:00
VN.iv4 100% 3888 98.9KB/s 00:00
VN.iv6 100% 3584 87.9KB/s 00:00
VG.iv4 100% 536 40.1KB/s 00:00
VG.iv6 100% 224 20.0KB/s 00:00
KP.iv4 100% 40 3.9KB/s 00:00
KP.iv6 100% 0 0.0KB/s 00:00
VI.iv4 100% 392 30.6KB/s 00:00
VI.iv6 100% 160 14.4KB/s 00:00
KR.iv4 100% 8128 105.8KB/s 00:00
KR.iv6 100% 3616 87.0KB/s 00:00
root@firegate2:/tmp/temp# scp BE/CN.iv? BE/UA.iv? BE/TW.iv? BE/VN.iv? BE/VG.iv? BE/KP.iv? BE/VI.iv? BE/KR.iv? root@192.168.10.1:/usr/share/xt_geoip/BE/
root@192.168.10.1’s password:
CN.iv4 100% 35KB 114.4KB/s 00:00
CN.iv6 100% 47KB 66.0KB/s 00:00
UA.iv4 100% 23KB 115.2KB/s 00:00
UA.iv6 100% 15KB 74.9KB/s 00:00
TW.iv4 100% 4704 93.8KB/s 00:00
TW.iv6 100% 3104 75.7KB/s 00:00
VN.iv4 100% 3888 108.8KB/s 00:00
VN.iv6 100% 3584 76.2KB/s 00:00
VG.iv4 100% 536 40.3KB/s 00:00
VG.iv6 100% 224 20.0KB/s 00:00
KP.iv4 100% 40 4.1KB/s 00:00
KP.iv6 100% 0 0.0KB/s 00:00
VI.iv4 100% 392 33.1KB/s 00:00
VI.iv6 100% 160 15.4KB/s 00:00
KR.iv4 100% 8128 111.1KB/s 00:00
KR.iv6 100% 3616 71.8KB/s 00:00
root@firegate2:/tmp/temp#

OK, now we have our pieces of geo ip informations. We now need to install the iptables-mod-geoip from the LuCI web interface (or by hand if you like).
Now you can create your Firewall Traffic Rules. Go to Network -> Firewall -> Traffic Rules on the router’s LuCI web interface and add a custom traffic rule. In my case I created 2 that I called “CinamerdaMuoriUDPeTCP” and “CinamerdaMuoriICMP”, the first to block TCP and UDP and the second to block ICMP traffic.

After that you can setup your custom rule setting your protocol and address families, set “source zone” to WAN, “destination zone” to “Any zone (forward)”, action to DROP, and the “Extra arguments” field like this:

-m geoip –source-country CN,UA,TW,VN,VG,KP,VI,KR

You can check the image below.

OpenWRT Firewall geoip example

Now you can say hello to most chinaspammers and something like that, but don’t abuse, this is not ethic if you set up this on a server that offers some sort of public service.

21 Apr 17 How to create a sparse file from a block device

This is how to create a sparse file dump from a block device:
cp --sparse=always <(dd if=/dev/vg0/vmservice1 bs=8M iflag=direct | pv -pre --size=20G) /opt/backups/vmservice1.dat

14 Gen 17 Come creare un gateway IPv6 su Fastweb

Fastweb ha deciso per il momento di non fornire IPv6 nativo ai propri clienti, e inoltre da qualche giorno ha disabilitato il tunnel TSP (tsp-auth.ipv6.fastweb.it) il quale non risulta piu’ raggiungibile.

Visto che nel mio caso ho un router fastweb Argo 55+ su fibra 100, e il suddetto router non supporta IPv6, quando vado sulla MyFastPage e cerco di attivare il protocollo IPv6 il sistema mi dice che devo sostituire il router con un nuovo modello. Io NON voglio cambiare router perche’ lo considero estremamente stabile e performante.

Come posso quindi attivare IPv6 nella mia rete domestica senza dover cambiare router?

Fastweb porta IPv6 ai suoi utenti tramite 6rd (https://en.wikipedia.org/wiki/IPv6_rapid_deployment). Questo significa che e’ probabilmente possibile ottenere la subnet in tunnel anche su linux.

Ho preso uno dei miei raspberry pi con raspbian e ci ho installato il pacchetto radvd (sudo apt-get install radvd), poi nel mio /etc/network/interfaces ho messo questo:

iface eth0 inet6 static
address 2001:b07:27b:7b7b::1
netmask 64

auto ipv6fastweb
iface ipv6fastweb inet6 v4tunnel
netmask 64
endpoint 81.208.50.214
up ip -6 route add default dev ipv6fastweb
down ip -6 route del default dev ipv6fastweb

Invece di usare come indirizzo ip 2001:b07:27b:7b7b::1 devi calcolarti il tuo a partire dal tuo IP pubblico fisso che ti ha fornito fastweb. Puoi ottenere il tuo ip pubblico ad esempio da qui: http://whatismyipaddress.com/

Facciamo finta che tu abbia l’IP 2.123.123.123, devi convertirlo in esadecimale, ad esempio cosi:

printf “%x%02x:%x%02x::\n” `echo 2.123.123.123 |tr . ” “`

Quello che otterrai, ad esempio 27b:7b7b:: va accodato al prefisso di fastweb (2001:b07:) e come suffisso accodi il numero 1.

In questo caso, quindi, l’IP diventa:

2001:b07:27b:7b7b::1 che e’ stato costruito da [2001:b07]:[b07:27b:7b7b]::[1]. La prima e’ fissa, la seconda dipende dal tuo IP pubblico e infine 1. Questo andra’ messo nella riga “address” nel file /etc/network/interfaces che ti dicevo prima e va anche messo nella direttiva “prefix” del radvd.conf, ma in ques’ultimo caso senza l’1 finale.

Crea il file /etc/radvd.conf e mettici dentro questo:

interface eth0
{
AdvSendAdvert on;
MinRtrAdvInterval 3;
MaxRtrAdvInterval 10;

prefix 2001:b07:27b:7b7b::/64
{
AdvOnLink on;
AdvAutonomous on;
AdvRouterAddr on;
};

RDNSS 2001:4860:4860::8888
{
AdvRDNSSLifetime 20;
};
};

Riavvia il raspberry pi e se tutto va bene, sempre nel raspberry pi dovrai avere una scheda di rete virtuale chiamata ipv6fastweb senza IP usabili ma che serve per creare il tunnel con il border gateway di fastweb (81.208.50.214). Se non funziona, prova a cercare un altro border gateway, magari chiedendo al numero verde o cercando su internet. A me funziona con questo. Metti quello giusto alla direttiva “endpoint” del file “interfaces”.

Poi avrai l’IP pubblico IPv6 che ti sei calcolato (nel caso di esempio 2001:b07:27b:7b7b::1/64) sulla scheda eth0 e avrai il tuo radvd che invia i router advertisement ipv6 alla tua rete.

Ogni PC nella tua rete che supporta IPv6 otterrà un IP pubblico nella subnet che ti sei calcolato, e sara’ raggiungibile direttamente da internet tramite IPv6.

Bello no? Ovviamente se abilitate questo dovete disabilitare IPv6 sul router di fastweb perche’ sara il vostro raspberry pi a fare da router ipv6.

Commentate sotto, mi raccomando! Fatemi sapere.

A me funziona perfettamente e sono molto felice. Credo che Fastweb dovrebbe creare una guida ufficiale su questo per il bene degli utenti. Ci ho messo 2 ore a farlo funzionare, con una guida ci avrei messo 2 minuti.

 

 

10 Ago 16 Shared memory and huge pages

This script can be used to determine how many shared memory is used by “oracle” user’s processes, and how many huge page memory is used:

t=0; for i in `ipcs -m  | grep oracle | awk ‘{print $5}’`; do echo “Oracle consumed other $i bytes”; let t=t+$i; done

echo
echo “Consumed by oracle as shared memory segments: $t bytes”
let t=t/1024
let g=t/1024/1024;
echo “Memory conversions: ~ $t kbytes | ~ $g GB”

hugepagetot=`cat /proc/meminfo | grep HugePages_Total | awk -F’:’ ‘{print $2}’`
hugepagefree=`cat /proc/meminfo | grep HugePages_Free | awk -F’:’ ‘{print $2}’`
let usedhugepages=hugepagetot-hugepagefree
let totkbinhigepage=usedhugepages*2048

echo “Total hugepage usage in kb: $totkbinhigepage”

04 Ago 16 Change date format to tomcat log catalina.out

If you need to change your catalina.out date and time format, you can add this line to your tomcat/conf/logging.properties:

1catalina.java.util.logging.SimpleFormatter.format=[%1$td.%1$tm.%1$tY %1$tH:%1$tM:%1$tS,%1$tL] %4$s [%2$s] %5$s %6$s %n

 

06 Mag 16 How to convert URI to query string parameters with mod_rewrite

You may need to convert URI levels to query string parameters, for example if want to be RESTful compliant with PHP.

Try this one:

RewriteEngine on
RewriteRule ^/(\w+)/(\w+)$ /path_of_index.php?lev1=$1&lev2=$2 [QSA,L]

In this case the first URI level will be converted to a query string parameter called lev1, while the second will be converted to a query string parameter called lev2, each one with the respective values.

For example, the uri /user/list will be passed to index.php and will become index.php?lev1=user&lev2=list

An eventual query string will be passed, eventually overriding lev1 and lev2 parameters.