Show the number of users currently connected to the VPN:
./sacli VPNSummary
Show the status of internal Access Server services:
./sacli status
Stop internal Access Server services:
./sacli stop
Start/restart internal Access Server services:
./sacli start
The ‘start’ command is smart in the sense that if the Access Server is already running, and you modified the configuration via the Config DB, only those services whose parameters are changed will be restarted. Note that if you modify any parameters in the Access Server bootstrap configuration file (/usr/local/openvpn_as/etc/as.conf), you will need to do a full unix restart in order for those settings to take effect.
Also note that the start/stop commands above don’t actually start or stop the Access Server daemon itself, only internal services within the daemon. To start/stop the access server daemon itself, use the traditional unix syntax:
Splits OpenVPN (.ovpn) files into separate files for private key, user+ca certificates and tls-auth key, for use with network-manager in debian/ubuntu.
# Install globally
$ npm install -g openvpn-config-splitter
# Run it, specifying your unsplit OpenVPN configuration file
$ ovpnsplit path/to/some/config.ovpn
# Config is now split into separate files, new configuration
# linking to the split files has been generated
$ ls path/to/some
ca.crt client.key client.ovpn client.split.ovpn ta.key user.crt
var fs = require('fs'),
configPath = '/some/path/to',
splitter = require('openvpn-config-splitter');
var paths = {
'caCert': configPath + '/openvpn-ca.crt',
'userCert': configPath + '/openvpn-user.crt',
'privateKey': configPath + '/openvpn-private.key',
'tlsAuth': configPath + '/openvpn-tls.key'
};
fs.readFile(configPath + '/config.ovpn', function(err, originalConfig) {
if (err) {
console.error('Could not read file (' + err.path + ')');
process.exit(1);
}
splitter.split(originalConfig, paths, function(err, parts, missing) {
if (err) {
console.error(err);
process.exit(1);
}
/**
* `parts` now contain the matched parts of the config + new config
* (caCert, userCert, privateKey, tlsAuth, config)
*
* `missing` is an array containing the parts that were NOT found -
* use this if you want to warn the user or fall back if you require
* a specific part to be present
*/
// Want to write the split files?
splitter.writeToFiles(parts, paths, function(err) {
if (err) {
console.log(err);
process.exit(1);
}
console.log('Hooray, we split the files and wrote them to disk!');
});
});
});
In a post on Wednesday, researchers Alex Halderman and Nadia Heninger presented compelling research suggesting that the NSA has developed the capability to decrypt a large number of HTTPS, SSH, and VPN connections using an attack on common implementations of the Diffie-Hellman key exchange algorithm with 1024-bit primes. Earlier in the year, they were part of a research group that published a study of the Logjam attack, which leveraged overlooked and outdated code to enforce « export-grade » (downgraded, 512-bit) parameters for Diffie-Hellman. By performing a cost analysis of the algorithm with stronger 1024-bit parameters and comparing that with what we know of the NSA « black budget » (and reading between the lines of several leaked documents about NSA interception capabilities) they concluded that it’s likely NSA has been breaking 1024-bit Diffie-Hellman for some time now.
The good news is, in the time since this research was originally published, the major browser vendors (IE, Chrome, and Firefox) have removed support for 512-bit Diffie-Hellman, addressing the biggest vulnerability. However, 1024-bit Diffie-Hellman remains supported for the forseeable future despite its vulnerability to NSA surveillance. In this post, we present some practical tips to protect yourself from the surveillance machine, whether you’re using a web browser, an SSH client, or VPN software.
Disclaimer: This is not a complete guide, and not all software is covered.
Web Browser
To make sure you’re using the strongest crypto, you have to look at the encryption algorithms (or cipher suites) that your browser supports. There’s an excellent tool, How’s My SSL?, that will test your browser’s cipher suite support. The relevant area of the page is the bottom, Given Cipher Suites. You want to make sure that you don’t see the text « _DHE_ » in the list of ciphersuites – although the Elliptic Curve variant of Diffie-Hellman, represented by suites with « _ECDHE_ » is okay. It is important to note that there is a trade-off here: removing your clients support for « _DHE_ » ciphers will eliminate the risk of this attack, but it may also remove Forward Secrecy support altogether for some sites. Here’s how to remove those « _DHE_ » cipher suites if you still have them:
Firefox
(tested with 40.0.3)
Open a new tab, enter « about:config » into the location bar and hit the « Enter » key. If you get a warning page, click « I’ll be careful, I promise! » This will bring you to the Firefox configuration settings. In the search bar up top, type « .dhe_ » and hit the « Enter » key. This should result in two settings being displayed: « security.ssl3.dhe_rsa_aes_128_sha » and « security.ssl3.dhe_rsa_aes_256_sha ». Double-click both of them to change the value from « true » to « false ».
Now, if you refresh the How’s My SSL page, the « _DHE_ » ciphersuites should be gone!
Grâce à un tunnel, il est possible de passer directement d’un point à un autre, sans devoir subir les affres de la circulation à la surface. Les tunnels informatiques s’en rapprochent fortement, en proposant un moyen de relier « directement » deux réseaux privés distants, à travers un inter-réseau aussi complexe que l’internet.
Il existe une grande quantité de moyens pour réaliser des tunnels informatiques. PPP peut être considéré comme un tunnel dans des configurations comme PPPoE ou PPPoA. L2TP (Layer 2 Tunneling Protocol), est utilisé sur les réseaux des opérateurs, par exemple dans les connexions ADSL non dégroupées.
PPTP (Point to Point Tunneling Protocol), utilisé par Microsoft, ou encore les tunnels sur IPSec sont d’autres solutions. L’objectif de ce chapitre est de monter le fonctionnement d’un tunnel sur IP à travers une implémentation standardisée : le tunnel GRE, puis à travers une solution plus sécurisée : OpenVPN.
Merci à _SebF, créateur du site frameip.com, pour son aimable collaboration.
Le principe
Imaginons que nous ayons à intervenir sur deux réseaux privés différents, géographiquement éloignés, les réseaux A et B. Si nous voulons interconnecter ces deux réseaux, nous avons à priori deux possibilités :
L’une chère, qui consiste à utiliser une liaison spécialisée, proposée par tout bon opérateur de télécoms. Les technologies utilisées par ces opérateurs afin de créer notre réseau privé sont principalement du type ATM1), MPLS2) et, plus anciennement, Frame Relay. Les avantages apportés sont la garantie d’un SLA3) et d’une étanchéité renforcée,
l’autre, moins chère, qui consiste à interconnecter ces deux réseaux via de l’internet public.
Oui, mais la seconde solution, à priori moins chère, sera plus limitative.
Soit, comme c’est le plus souvent le cas, nous ne disposerons que d’une seule adresse IP publique pour accéder à chaque réseau et dans ce cas, nous ne pourrons pas faire facilement communiquer n’importe quelle machine du réseau A avec n’importe quelle machine du réseau B, puisque ces LANs seront montés avec des adresses IP privées. (Voyez le Partage de connexion, mis en œuvre dans de telles configurations),
Soit nous disposons de suffisamment d’adresses IP publiques pour monter nos réseaux avec ces adresses, mais alors, toutes nos machines seront directement exposées sur le Net. Cher et difficile (il n’est pas simple, et encore moins gratuit d’obtenir des plages, même petites, d’adresses IPv4 publiques, encore qu’avec IPv6, ce sera tout à fait réalisable) et pour le moins dangereux.
Comment faire alors ?
Créer une ligne spécialisée virtuelle, qui passera par l’internet, mais qui fonctionnera presque comme une liaison spécialisée. Bien sûr, pour ce faire, un tunnel est nécessaire afin de créer l’interconnexion, de garantir l’étanchéité. L’avantage est de ne pas être dépendant d’un opérateur et ainsi, de pouvoir choisir la sortie Internet de chaque site indépendamment les unes des autres. Rien en effet n’interdit de construire plusieurs tunnels, éventuellement sur des connexions internet différentes. Nous disposons de plusieurs technologies telles que PPtP, IPSec et celles qui nous intéressent dans cette documentation : Le tunnel GRE et OpenVPN.
Au niveau IP, un tunnel se présente comme ceci :
Et nous aurons l’impression d’avoir à peu près cela :
Bien que la première couche IP circule normalement sur l’internet, en suivant les routes définies par les opérateurs, celle-ci transporte une seconde couche IP et sur cette couche, tout va se passer comme si les deux routeurs communiquaient directement, par l’intermédiaire d’un réseau IP ne comportant que deux nœuds : les deux routeurs.
Grâce à ce tunnel, tout nœud du réseau A pourra communiquer avec tout nœud du réseau B, les deux réseaux étant construits avec des adresses IP privées.
Super non ?
Oui, mais souvenez-vous que IPv4 est un protocole qui n’est pas sécurisé, que nous allons l’utiliser et qui plus est, sur un réseau plutôt mal famé. L’opération n’est donc pas sans risques.
