Archive

Articles taggués ‘securite’

Rsnapshot

14/03/2019 Comments off

Introduction

Vous le savez maintenant, les sauvegardes sont indispensables… Sauvegardes. Nécessaires, mais facile à oublier, sauf si elles sont effectuées automatiquement.

Voici un tutorial qui décrit la procédure pour mettre en place une solution de sauvegarde automatique simple basée sur rsnapshot.

Rsnapshot est un script écrit en perl.

Il utilise Rsync (et ssh si vous le souhaitez) pour effectuer des sauvegardes à intervalle régulier.

Il est capable de réaliser des sauvegardes d’un systèmes de fichier ou bien de bases de données par l’intermédiaire de scripts.

Un des principaux avantages de rsnapshot est son extrême simplicité.

rsnapshot utilise les « hard link unix » pour :

  • Éviter de dupliquer inutilement les fichiers.
  • Faciliter la restauration.

rsnapshot crée l’illusion de plusieurs sauvegardes complètes, alors qu’il n’y a sur le système de fichier que la première et les différences éventuelles apparues entre cette dernière et les suivantes. Il s’agit d’une méthode de sauvegarde différentielle.

Dans ce tuto nous allons vous expliquer comment mettre en place la sauvegarde différentielle sécurisée d’un répertoire d’une machine distante.

Prérequis: Configuration de SSH et des clefs

Vous devez pouvoir vous connecter aux machines auxquelles vous allez vous connecter sans mot de passe:

Tout d’abord, il faut configurer ssh et importer la clef du serveur distant.

Je vais procéder comme dans ce tuto

Testez:

root@nas:~# ssh -p 10122 vanille
Linux vanille.zehome.org 2.6.32-5-amd64 #1 SMP Tue Jun 14 09:42:28 UTC 2011 x86_64

The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.

Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
Last login: Thu Aug 11 08:07:48 2011 from nas.zehome.org
root@vanille:~#

Installation de rsnapshot

root@nas:~# apt-get install rsnapshot

Qui vous installera par la même occasion Rsync

Sauvegarde du fichier de configuration:

root@nas:~# cp /etc/rsnapshot.conf /etc/rsnapshot.conf.sos

Lire la suite…

IP leak affecting VPN providers with port forwarding

02/03/2019 Comments off

Vulnerability “Port Fail” reveals real IP address

We have discovered a vulnerability in a number of providers that allows an attacker to expose the real IP address of a victim. “Port Fail” affects VPN providers that offer port forwarding and have no protection against this specific attack. Perfect Privacy users are protected from this attack.

This IP leak affects all users: The victim does not need to use port forwarding, only the attacker has to set it up.

We have tested this with nine prominent VPN providers that offer port forwarding. Five of those were vulnerable to the attack and have been notified in advance so they could fix this issue before publication. However, other VPN providers may be vulnerable to this attack as we could not possibly test all existing VPN providers.

Details about the leak

The attacker needs to meet the following requirements:

  • Has an active account at the same VPN provider as the victim
  • Knows victim’s VPN exit IP address (can be obtained by various means, e.g. IRC or torrent client or by making the victim visit a website under the attackers control)
  • The attacker sets up port forwarding. It makes no difference whether the victim has port forwarding activated or not.

The IP leak can then be triggered as follows:

  1. Victim is connected to VPN server 1.2.3.4
  2. Victim’s routing table will look something like this:
    0.0.0.0/0 -> 10.0.0.1 (internal vpn gateway ip)
    1.2.3.4/32 -> 192.168.0.1 (old default gateway)
  3. Attacker connects to same server 1.2.3.4 (knows victim’s exit through IRC or other means)
  4. Attacker activates Port Forwarding on server 1.2.3.4, example port 12345
  5. Attacker gets the victim to visit 1.2.3.4:12345 (for example via embedding <img src=”http://1.2.3.4:12345/x.jpg”> on a website)
  6. This connection will reveal the victim’s real IP to the attacker because of the “1.2.3.4/32 -> 192.168.0.1” vpn route.

The crucial issue here is that a VPN user connecting to his own VPN server will use his default route with his real IP address, as this is required for the VPN connection to work. If another user (the attacker) has port forwarding activated for his account on the same server, he can find out the real IP addresses of any user on the same VPN server by tricking him into visiting a link that redirects the traffic to a port under his control.

Also note that due to the nature of this attack all VPN protocols (IPSec, OpenVPN, PPTP, etc.) and all operating systems are affected.

Mitigation

Affected VPN providers should implement one of the following:

  • Have multiple IP addresses, allow incoming connections to ip1, exit connections through ip2-ipx, have portforwardings on ip2-ipx
  • On Client connect set server side firewall rule to block access from Client real ip to portforwardings that are not his own.

 

Source: Perfect Privacy

Categories: Réseau Tags: , ,

Le tunnel GRE

16/02/2019 Comments off

Les tunnels

tunnel greGrâ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 :

vpn-1

Et nous aurons l’impression d’avoir à peu près cela :

vpn-2

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.

Lire la suite…

Categories: Réseau, Tutoriel Tags: , , ,

Différents accès aux différentes organisations avec un pare-feu

15/02/2019 Comments off

Zone démilitarisée, la DMZ.

Une zone démilitarisée est un sous-réseau (DMZ) isolé par deux pare-feux (firewall). Ce sous-réseau contient des machines se situant entre un réseau interne (LAN – postes clients) et un réseau externe (typiquement, Internet).

La DMZ permet à ces machines d’accéder à Internet et/ou de publier des services sur Internet sous le contrôle du pare-feu externe. En cas de compromission d’une machine de la DMZ, l’accès vers le réseau local est encore controlé par le pare-feu interne.

La figure ci-contre représente un cas particulier de DMZ; pour des raisons d’économie, les deux pare-feu sont fusionnés. C’est la ‘colapsed dmz‘, moins sure, car dès que le pare-feu est compromis, plus rien n’est contrôlé.

Schéma DMZ avec 1 seul pare-feu

Schéma DMZ avec 1 seul pare-feu

Schéma DMZ avec 2 pare-feux

Schéma DMZ avec 2 pare-feux

une installation complète contient :

  • Un réseau privé, dont on considère (souvent à tort) qu’il ne sera pas utilisé pour attaquer notre système informatique. Dans cette zone, il n’y a que des clients du réseau et des serveurs qui sont inaccessibles depuis l’Internet. Normalement, aucune connexion, au sens TCP du terme, aucun échange, au sens UDP du terme, ne peuvent être initiés depuis le Net vers cette zone.
  • Une « DMZ » (Zone DéMilitarisée), qui contient des serveurs accessibles depuis le Net et depuis le réseau privé. Comme ils sont accessibles depuis le Net, ils risquent des attaques. Ceci induit deux conséquences :
    • Il faut étroitement contrôler ce que l’on peut faire dessus depuis le Net, pour éviter qu’ils se fassent « casser » trop facilement,
    • Il faut s’assurer qu’ils ne peuvent pas accéder aux serveurs de la zone privée, de manière à ce que si un pirate arrivait à en prendre possession, il ne puisse directement accéder au reste du réseau.

Le dispositif qui va permettre d’établir ces règles de passages s’appelle un pare-feu. Techniquement, ce pourra être un logiciel de contrôle installé sur un routeur.

1.1 Les trois passages.

1.1.1 Entre le réseau privé et le Net.

Toujours typiquement, ce sont les clients du réseau (les utilisateurs) à qui l’on va donner des possibilités d’accéder au Net comme par exemple le surf ou la messagerie. Toutes les requêtes partent du réseau privé vers le Net. Seules les réponses à ces requêtes doivent entrer dans cette zone. Les accès peuvent être complètement bridés (les clients du réseau privé n’ont aucun droit d’accès vers le Net, ça nuit à leur productivité.

Seul le patron y a droit). Ou alors, les utilisateurs ne pourront consulter qu’un nombre de sites limités, dans le cadre de leurs activités professionnelles exclusivement. Très généralement, cette zone est construite sur une classe d’adresses privées et nécessite donc une translation d’adresse pour accéder au Net. C’est le routeur qui se chargera de cette translation.

1.1.2 Entre la DMZ et le Net.

Ici, nous avons des serveurs qui doivent être accessibles depuis le Net. Un serveur Web, un serveur de messagerie, un FTP… Il faudra donc permettre de laisser passer des connexions initiées depuis l’extérieur. Bien entendu, ça présente des dangers, il faudra surveiller étroitement et ne laisser passer que le strict nécessaire.

Si l’on dispose d’adresses IP publiques, le routeur fera un simple routage. Si l’on n’en dispose pas, il devra faire du « port forwarding » pour permettre, avec la seule IP publique dont on dispose, d’accéder aux autres serveurs de la DMZ. Cette technique fonctionne bien sur un petit nombre de serveurs, mais devient très vite un casse-tête si, par exemple, plusieurs serveurs HTTP sont présents dans la DMZ.

1.1.3 Entre le réseau privé et la DMZ.

Les accès devraient être à peu près du même type qu’entre la zone privée et le Net, avec un peu plus de souplesse. En effet, il faudra

  • Mettre à jour les serveurs web,
  • Envoyer et recevoir les messages, puisque le SMTP est dedans
  • Mettre à jour le contenu du FTP (droits en écriture).

En revanche, depuis la DMZ, il ne devrait y avoir aucune raison pour qu’une connexion soit initiée vers la zone privée.
Lire la suite…

Installing a high availability web server cluster on Ubuntu 12.04 LTS using HAProxy, HeartBeat and Nginx

14/02/2019 Comments off

How to set-up a high-availability cluster

Here are a few notes about how to set-up a high-availability web server farm using Ubuntu 12.04 LTS using a whole load of awesome software (HAProxy, HeartBeat, Watchdog and Nginx)

The setup

In my setup I have five virtual machines, these are named and used for the following:-

haproxy1 – Our first proxy (master)/load-balancer (running HAProxy, HeartBeat and Watchdog) [IP address: 172.25.87.190]
haproxy2 – Our second proxy (failover)/load-balancer (running HAProxy, HeartBeat and Watchdog) [IP address: 172.25.87.191]
web1 – Our first web server node (running nginx) [IP address: 172.25.87.192]
web2 – Our second web server node (running nginx) [IP address: 172.25.87.193]
web3 – Our third web server node (running nginx) [IP address: 172.25.87.194]

The servers are connected in the following way:-

thesetup

In my next post I will also explain how to configure the web servers to point to a backend shared storage cluster (using NFS) and a MySQL cluster server to have a truly highly available web hosting platform.

Lire la suite…