Mastering Bash, it’s out!
Well, it’s my first book in English so it is somewhat special to me!
Easy routing workaround for Linux Fortinet SSL client
So you have your Fortinet Linux SSL VPN client, you setup your credential, fire up the connection, it connects, then you do not have access to any of your machines on your private vpn.
Nasty.
You can see sent and received byte numbers flipping on the forticlient window, but you go nowhere.
Errrr!!! Routing problems.
Go either in your 64bit or 32bit client directory and edit
sysconfig.linux.sh
Look for the following line:
addr=`ip addr show $ifn | grep "inet" | tr '/' ' ' | awk '{ print $2 }'`
and change it to:
addr=`ip addr show $ifn | grep -m 1 "inet" | tr '/' ' ' | awk '{ print $2 }'`
That’s it. It’s a simple matching problem.
As you can see in :
forticlientsslvpn.log
It fails to grep the IP address for the ppp0 interface and so, it fails to create a new route towards your private network.
Easy and nasty.
Heartbleed OpenSSL bug fix on Debian Wheezy
Following the Debian Security Advisory DSA-2896-1 openssl — security update, a good practice would be to check wether your server is affected by the OpenSSL Heartbleed security bug or not.
If you find your server affected by the bug, here are some few steps to fix the problem on Debian Wheezy (but with slight changes you can use with other distros too).
As root:
aptitude update aptitude upgrade libssl1.0.0 aptitude upgrade openssl
As you reboot you Apache or SSH servers, you will notice that the bug is fixed, but the problem is still here, you private keys may be compromised, so it’s time to generate new secrets.
Apache
Let’s generate a new private key. First, let’s move to the ssl private keys directory:
cd /etc/ssl/private
Let’s issue:
openssl genrsa -des3 -out server.key 1024 openssl req -new -key server.key -out server.csr
So now we have a new private key and a csr (certificate signing request).
Time to strip the password from the private key:
cp server.key server.key.org openssl rsa -in server.key.org -out server.key
And now, we self sign the certificate:
openssl x509 -req -days 365 -in server.csr -signkey server.key -out server.crt
Have a look at your new certificate:
openssl x509 -in server.crt -text | less
Now let’s make everything readable just by root user, remember that we stripped the password from private key:
chmod o-r server*
Finally let’s copy the new public certificate to the right directory:
cp server.crt ../certs/
Do not forget to modify, if needed, the entry for certificate files in Apache conf :
SSLCertificateFile /etc/ssl/certs/server.crt SSLCertificateKeyFile /etc/ssl/private/server.key
Now, restart Apache:
service apache2 restart
SSHD
For OpenSSH it’s way easier. First, we remove the old host keys:
rm /etc/ssh/ssh_host_*
Now we reconfigure openssh-server package to generate new keys:
dpkg-reconfigure openssh-server
Finally, if dpkg-reconfigure did not, we restart SSH
service ssh restart
ERROR Could not initialize NSS on Debian x86_64
Few days ago I felt the need to setup Icedove so I could read my company email messages on my Debian 6.0 x86_64 notebook. Well, since we use Exchange I had to rely on Davmail to exchange emails with Exchange (sorry, I could not resist the joke). Well, as I checked the emails from my work account, Davmail sported the error “Could not initialize NSS”.
Since I am a lazy guy, I checked Google for an answer, you can find it here. I had to make just a little change cause I use a x64 OS:
uname -m
x86_64
Edit the file
/usr/lib/jvm/java-6-openjdk/jre/lib/security/nss.cfg
And in this snippet
name = NSS
nssLibraryDirectory = /usr/lib
nssDbMode = noDb
attributes = compatibility
you have to change the nssLibraryDirectory value to
name = NSS
nssLibraryDirectory = /usr/lib/x86_64-linux-gnu
nssDbMode = noDb
attributes = compatibility
If you have any problems with the nss.cfg file (backup it before you edit it), you can always find a fresh copy in:
dpkg -S /etc/java-6-openjdk/security/nss.cfg
openjdk-6-jre-headless: /etc/java-6-openjdk/security/nss.cfg
OpenDNS e dhclient
Alcuni giorni or sono, Andrea scriveva di quanto sono buoni e belli i server di OpenDNS, invitando a passarvi le proprie macchine. Gli indirizzi dei server DNS di OpenDNS sono:
- 208.67.222.222
- 208.67.220.220
Se avete un ip statico, nessun problema, basta indicare il tutto nel file resolv.conf:
nameserver 208.67.222.222
nameserver 208.67.220.220
Se utilizzate dhclient, invece, il discorso si complica dato che il file che contiene la lista dei dns da utilizzare per la risoluzione dei nomi da parte del sistema, ovvero resolv.conf, viene rigenerato a ogni acquisizione di un nuovo lease (semplificando, ogni volta che ottenere un indirizzo dinamico), utilizzando le informazioni inviate dal server dhcp.
Questo comportamento è governato dal file dhclient.conf, tramite il quale è possibile intervenire sul meccanismo di acquisizione dei dns, imponendo una scelta predeterminata. Si osservi il seguente blocco di istruzioni contenuto in dhclient.conf:
request subnet-mask, broadcast-address, time-offset, routers,
domain-name, domain-name-servers, host-name,
netbios-name-servers, netbios-scope;
E’ fra le opzioni del file di configurazione di dhclient che si nasconde la chiave per risolvere il problema. Basterà eliminare l’istruzione che forza la richiesta dell’elenco dei server DNS, rimuovendo domain.name-servers, preponendo nel contempo alle informazioni fornite dal server dhcpd la nostra lista di server DNS:
prepend domain-name-servers 208.67.222.222, 208.67.220.220;
request subnet-mask, broadcast-address, time-offset, routers,
domain-name, host-name,
netbios-name-servers, netbios-scope;
In pratica, l’istruzione domain-name-servers è stata spostata al di fuori del blocco di richieste effettuate al server dhcp ed è stata istanziata con dei valori predefiniti dall’utente.
Qual’è l’effetto finale?
Semplicemente, il file resolv.conf verrà rigenerato a ogni riacquisizione di lease, utilizzando gli indirizzi dei server OpenDNS indicati dalla direttiva prepend domain-name-server in dhclient.conf.