Archive for Sicurezza

DNS leak: problemi di sicurezza

Un altro problema di sicurezza  e privacy da non sottovalutare nelle connessioni, anche in quelle realizzate tramite VPN, è il DNS leak.

Dns leak

Ovvero la richiesta che dal personal computer viene inoltrata al server DNS del nostro ISP (per convertire il nome del dominio in un indirizzo IP), è inviata al di fuori del tunnel  VPN, pertanto non protetta e rintracciabile (a tale proposito rimando all’articolo su DNSCrypt).

Sul sito http://dnsleak.com è possibile eseguire un DNS leak test per verificare il proprio DNS (un sito alternativo è https://www.dnsleaktest.com).

Utilizzando la connessione VPN di TunnelBear  il risultato è il seguente:

DNS no leak

Disattivando la connessione:

DNS leak

How to use ssh – config

Abbreviating hostnames

If you often have to SSH into a machine with a long host and/or network name, it can get irritating to type it every time. For example, consider the following command:

$ ssh web0911.colo.sta.solutionnetworkgroup.com

If you interact with the web0911 machine a lot, you could include a stanza like this in your ~/.ssh/config:

Host web0911
    HostName web0911.colo.sta.solutionnetworkgroup.com

This would allow you to just type the following for the same result:

$ ssh web0911

Of course, if you have root access on the system, you could also do this by adding the hostname to your/etc/hosts file, or by adding the domain to your /etc/resolv.conf to search it, but I prefer the above solution as it’s cleaner and doesn’t apply system-wide.

Fixing alternative ports

If any of the hosts with which you interact have SSH processes listening on alternative ports, it can be a pain to both remember the port number and to type it in every time:

$ ssh webserver.example.com -p 5331

You can affix this port permanently into your .ssh/config file instead:

Host webserver.example.com
    Port 5331

This will allow you to leave out the port definition when you call ssh on that host:

$ ssh webserver.example.com

Custom identity files

If you have a private/public key setup working between your client machine and the server, but for whatever reason you need to use a different key from your normal one, you’ll be using the -i flag to specify the key pair that should be used for the connection:

$ ssh -i ~/.ssh/id_dsa.mail srv1.mail.example.com
$ ssh -i ~/.ssh/id_dsa.mail srv2.mail.example.com

You can specify a fixed identity file in .ssh/config just for these hosts instead, using an asterisk to match everything in that domain:

Host *.mail.example.com
    IdentityFile ~/.ssh/id_dsa.mail

I need to do this for Mikrotik’s RouterOS connections, as my own private key structure is 2048-bit RSA which RouterOS doesn’t support, so I keep a DSA key as well just for that purpose.

Logging in as a different user

By default, if you omit a username, SSH assumes the username on the remote machine is the same as the local one, so for servers on which I’m called tom, I can just type:

[email protected]:$ ssh server.network

However, on some machines I might be known as a different username, and hence need to remember to connect with one of the following:

[email protected]:$ ssh -l tomryder server.anothernetwork
[email protected]:$ ssh [email protected]

If I always connect as the same user, it makes sense to put that into my .ssh/config instead, so I can leave it out of the command entirely:

Host server.anothernetwork
    User tomryder

SSH proxies

If you have an SSH server that’s only accessible to you via an SSH session on an intermediate machine, which is a very common situation when dealing with remote networks using private RFC1918 addresses through network address translation, you can automate that in .ssh/config too. Say you can’t reach the host nathost directly, but you can reach some other SSH server on the same private subnet that is publically accessible, publichost.example.com:

Host nathost
    ProxyCommand ssh -q -W %h:%p public.example.com

This will allow you to just type:

$ ssh nathost

More information

The above are the .ssh/config settings most useful to me, but there are plenty more available; check man ssh_config for a complete list.

Fonte: blog.sanctum.geek.nz

Sentinel superpro dongle emulator

If you are running a 64-bit version of Windows 7 go to this article.

Emulatore di chiavi Sentinel super pro

Currently, many companies use the expensive Hardward Sentinel Key for software protection.

If you need to install the program, regularly purchased, on other PC or if you want to avoid carrying around the precious keys, you can use an emulator program which allow you to use the software without the use of  the Sentinel Key.
The program that I used for the emulation is Sentinel Emulator 2007, that with some small changes, it can run on Windows Vista.
The zipped package, that you can download from here: “Sentinel Emulator“, contains the following programs:

– Sentinel versione 7.3.0
– SSDCleanup
– Emulator

Of course, to allow the emulator to work, you need to have an original Sentinel Key.


1) Launch the application Sentinel73.exe to install the drivers.

2) Insert the key and wait for the device recognition.

3) Star EDGE (the program has the function to copy the data stored in the key and exporting them to a file with DNG extension).

4) Insert the destination folder.

5) Insert the file name (by Browse).

6) Press the “Dump & Solve” and wait a few minutes.

7) Wait that the dump file is created.

8) Remove the key.



To allow the program to work under Vista, go to the properties panel to enable the compatibility mode for Windows XP.

Emulator  2010 is compatible with Vista, but it doesn’t accept the “dump file ” created with previous versions.

Emulatore di chiavi Sentinel super pro

Run Emulator and check if the driver has been correctly installed:


Press “Start Service” and load “Dump  file” with DNG extension.


If everything goes well, you will get a screen like this: