GuiguiAbloc

Pour être honnête avec vous, j’avais pensé intitulé ce billet « Ouvrez, ouvrez la cage aux oiseaux… ».

Mais après avoir osé « PKI, PKI, oh ! PKI, PKI, ah! » sur l’air de « Rosalie », je me se suis dit que vous alliez sûrement vous poser de sérieuses questions sur ma santé mentale et surtout sur mes goûts musicaux (bien que je n’ai rien de personnel contre Carlos et Pierre Perret)

Bref, donc le but de ce billet est de résoudre un problème fréquent.

Vous avez un beau serveur dédié Linux (ou un pote vous en prête un) et vous contrôler bien entendu dessus les accès réseau via Iptables.

D’ailleurs, vous utilisez peut-être même un superbe script déjà tout fait dans le genre de KHARON (comment cela je fais de la pub ???)

Vous disposez a votre domicile d’une adresse IP dynamique et bien entendu, pour fixer cela en dur dans Iptables, bah c’est la cata…

Vous jonglez donc avec Fail2ban et/ou des règles du style :

Iptables -I INPUT -p tcp --dport 22 -i eth0 -m state --state NEW -m recent --update --seconds 60
--hitcount 4 -j DROP

Voici donc une petite bidouille bien proprette pour insérer votre ip dynamique dans iptables (oublier les résolutions DNS en règles Iptables, cela ne marche pas…) et autoriser l’accès en SSH depuis votre ip dynamique.

Je suppose bien évidemment que vous utilisez déja un service comme DYNDNS ou une entrée de type DYNHOST chez OVH par exemple (ou autre hein, je suis pas sectaire).

Bref, un service permettant d’avoir un nom d’hôte pour votre ip dynamique et qui est mis à jour à intervalle régulier.

Tout d’abord, il faut créer une chaine que nous appelerons « mon_ip_maison » par exemple et l’insérer au début de la chaine INPUT d’iptables.

A rajouter donc dans votre script Iptables ou à la main comme ceci :

iptables -N mon_ip_maison
iptables -I INPUT 1 -j mon_ip_maison

Reste à écrire le joli script de mise à jour que j’appellerais ici : Wesh_Gros_C_est_moi.sh

(euh vous pouvez changer le nom hein…)

#!/bin/bash
#
# variables generales
dyndns=guiguiabloc.dyndns.com
ipfile=/root/ipfile
 
# Recuperation de l'ip
IP=`/usr/bin/dig +short $dyndns | /usr/bin/tail -n 1`
if [ "${#IP}" = "0" ]; then
    echo "Echec de la recuperation de l'ip"
    exit
fi
 
ANCIENNEIP=""
if [ -a $ipfile ]; then
    ANCIENNEIP=`cat $ipfile`
fi
 
# on enregistrer la nouvelle ip
echo $IP>$ipfile
 
echo "Mise a jour d'iptables"
if [ "${#ANCIENNEIP}" != "0" ]; then
    echo "Suppression de l'ancienne règle ($ANCIENNEIP)"
    /sbin/iptables -D mon_ip_maison -s $ANCIENNEIP/32 --dport 22 -j ACCEPT
fi
echo "Insertion de la nouvelle règle ($IP)"
/sbin/iptables -A mon_ip_maison -s $IP/32 --dport 22 -j ACCEPT

Ne reste qu’a le lancer toutes les 10 minutes via la crontab :

*/10 * * * * /root/Wesh_Gros_C_est_moi.sh   2>&1

Magique

Vous trouverez le script de Dave Horner ICI

Suite à ce billet sur la mise en oeuvre de VMware Server 2 sur un serveur dédié OVH, il semble que certain d’entre vous soit en difficulté pour affecter une ip failover à votre Machine Virtuelle et pour la faire communiquer avec le Nain Ternet.

Donc , petite mise au point et tuto pour le « comment qu’on fait » pour mettre une ip failover OVH sur ma VM.

• Pré-requis Hôte
  

Vous avez lu le billet sur l’installation VMWare et l’hôte est opérationnel.

J’appelerais l’hôte le serveur sur lequel est installé VMWare server.

L’interface Host-only utilisée sur l’hôte est VMNET1 :

hote# ifconfig
 
vmnet1    Lien encap:Ethernet  HWaddr 00:50:56:C0:00:01
          inet adr:10.154.98.1  Bcast:10.154.98.255  Masque:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:3675317 errors:0 dropped:0 overruns:0 frame:0
          TX packets:3013354 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 lg file transmission:1000
          RX bytes:0 (0.0 b)  TX bytes:0 (0.0 b)

L’ip affectée à VMNET1 est de classe privée (192.168/16, 172.16/12 ou 10/8) ici, 10.154.98.1/24 (la notation /24 correspond au nombre de bits du masque se sous-réseau donc ici 255.255.255.0).

Le forwarding IP est activée :

hote# cat /proc/sys/net/ipv4/ip_forward
1

Le proxy ARP est actif sur l’interface VMNET1 :

hote# cat /proc/sys/net/ipv4/conf/vmnet1/proxy_arp
1

Si les valeurs sont a 0, les activer :

hote# /bin/echo "1" > /proc/sys/net/ipv4/ip_forward
hote# /bin/echo "1" > /proc/sys/net/ipv4/conf/vmnet1/proxy_arp

L’ip FailOver utilisée dans cette exemple est 91.121.58.158.

On ajoute une route par défaut pour l’ipFailover :

hote# route add 91.121.58.158 dev vmnet1
hote# route -n
Table de routage IP du noyau
Destination     Passerelle      Genmask         Indic Metric Ref    Use Iface
91.121.58.158  0.0.0.0         255.255.255.255 UH    0      0        0 vmnet1

• Machine Virtuelle Linux (type Debian)

guest:~# cat /etc/network/interfaces
# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).
 
# The loopback network interface
auto lo
iface lo inet loopback
 
# The primary network interface
allow-hotplug eth0
iface eth0 inet static
address 91.121.58.158
netmask 255.255.255.255
dns-nameservers 213.186.33.99
 
post-up /sbin/route add default dev eth0

N’oubliez pas de renseigner vos serveurs de noms (opendns ici)

guest:~# cat /etc/resolv.conf
search localdomain
nameserver 208.67.222.222
nameserver 208.67.220.220

On reboot, Un ping sur une adresse externe doit fonctionner sans problème :

LinuxVM

Si vous préférez faire la config à la main :

guest# ifconfig eth0 91.121.58.158 netmask 255.255.255.255
guest# route add default dev eth0

• Machine Virtuelle WINDOWS

Etape 1

On spécifie l’ip failover, la passerelle qui l’adresse de VMNET1 de l’hôte et les DNS.

Concernant les masques, si vous laissez 255.255.255.255, vous aurez un message d’erreur :

Erreur masque

On va donc laisser 255.255.255.0 pour l’instant :

Masque par defaut

Lancer Regedit pour modifier la valeur du netmask (Démarrer/executer/Regedit).

Déplacer vous sur HkEY_LOCAL_MACHINE/SYSTEM et faites une recherche sur « subnet »

Modification dans le registre

Modifie la valeur 255.255.255.0 en 255.255.255.255

Modification Netmask

On reboot le pc, tout doit être ok désormais :

Test final

ATTENTION le netmask affichée est INCORRECT !! LA PREUVE :

Bug netmask ipconfig

En espèrant que cela vous aide

Ce billet est un petit exercice de style

Dans le cadre d’une architecture « standard », vous disposez d’un routeur qui vous donne accès au Nain Ternet, un firewall dédié et vos serveurs.

Les serveurs dédiés à offrir des services aux utilisateurs externes sont normallement en DMZ.

Ca c’est le cas idéal, mais il peut arriver (souvent même), que quelques applications soient hébergées sur des serveurs du LAN et là on joue avec de la NAT dans tout les sens.

Vous avez donc ouvert le port sur votre firewall puis fait une redirection sur la machine dans le LAN.

Ca marche mais bof quoi

Dans ce genre de concept (très fréquent), on laisse donc la transaction TCP (le fameux 3-way handshake) s’établir entre le client et le serveur dans le LAN.

Moyen hein ?

Après tout, vous obligez bien vos utilisateurs à passer par un proxy Squid pour aller sur le Web, pourquoi ne pas faire pareil avec vos connexions entrantes TCP ?…

Voila ce que nous allons mettre en place :

Schéma

Et qui a la plus de compétences pour gérer le 3-way handshake a la place des autres ? Qui a la plus grosse quand on parle de couche réseau ?

Réponse : OpenBSD forcement

Nous allons partir du principe que vous désirez offrir un accès SMTP sur la machine LAN-MAIL depuis le Nain Ternet.

L’adressage utilisée sera le suivant (et comme toujours un dessin valant mieux qu’un grand discours) :

Schéma

Coté Firewall, redirection toute simple, tout ce qui entre sur le port 25 SMTP depuis le Net sur l’interface externe est redirigé sur 10.154.1.1 port 25 (ou autre hein, c’est vous qui voyez).

La, c’est du truc habituel, rien de bien sorcier.

Coté OpenBSD, on va se monter un petit socket :

vi /etc/inetd.conf
 
127.0.0.1:5025 stream tcp nowait nobody /usr/bin/nc nc 192.168.0.50 25

On reload le process inetd

Puffy:~# ps aux | grep inetd
root     24243  0.0  0.3   524   780 ??  Is    26Sep08    0:18.06 inetd
root     30919  0.0  0.3   472   764 p0  S+    11:23AM    0:00.02 grep inetd
Puffy:~# kill -HUP 24243

Explication, on utilise netcat pour établir une connexion tcp vers LAN-MAIL sur le port 25 quand une requète TCP arrive sur son port 5025 en localhost.

Maintenant on s’attaque à la couche la plus poilue, Packet Filter :

(wan_if étant l’interface sis0 dans le schéma)

pf.conf
 
rdr pass on $wan_if inet proto tcp from any to $wan_if port 25 --> 127.0.0.1 port 5025
pass in quick inet proto tcp from any to 127.0.0.1 port 5025

Et c’est tout.

Bien évidemment vous avez déjà un beau PF configuré avec toutes les options qui vont bien, antispoof, scrub in all et tout, et tout…

J’ai volontairement simplifié l’architecture et les règles, alors ne me criez pas dessus

Et ca fait quoi donc maintenant ce joli truc ?

Cela fait que désormais, c’est l’OpenBSD qui va traiter la connexion entrante, l’accepter, ouvrir une nouvelle connexion vers LAN-MAIL et véhiculer les paquets vers lui.

Toute la phase d’échange TCP sera traitée par le BSD et c’est avec lui que le client discutera directement.

Bref, l’OpenBSD joue le rôle de Proxy TCP

Voila pour ce petit exercice que je vous laisse peaufiner et qui peut vous dépatouiller d’architectures un peu compliqués ou surtout, de connexions TCP moisies entre le Firewall et le Serveur final.

P.S. : Attention avec le protocole FTP, ce n’est aussi simple que cela y parait. Je vous conseille fortement d’utiliser le programme ftp-proxy d’openBSD (surtout si vous voulez redirigez vos requêtes FTP externes vers le FTP de votre Freebox HD par exemple )

Mouarf, OK, oubliez les 5 minutes mais en 1 heure je vous propose de monter une passerelle VPN vers les ressources de votre LAN, sans installer de client sur les postes, fort hein ?

Un dessin valant toujours mieux qu’un long discours :

En fait, je ne suis pas naturellement friand de ce genre de gadget, et je préfère passer du temps a monter mes VPNs et mes ACLs blindés dans tout les sens, mais cet article fait suite à une discussion au détour d’un couloir avec mon ami Horacio, un bloggeur KIFOVOIR, une personne attachante et très sympathique et qui le plus peut le moins, mon JAVA Man à moi (avec Fred bien sûr (non non Fred, je ne t’oublie pas ).
Bref, revenons à nos moutons : permettre à nos « amis », « client », « fournrisseurs » (etc, etc, cochez la mention inutile), d’accéder à des ressources de notre LAN sans pour autant leur faire passer la sempiternelle installation du client VPN Cisco, d’OpenVPN ou de Racoon (etc, etc…)

Impossible direz-vous ? Et bien si…

Horacio me sort donc il y a quelques jours « bah…. avec ssl-explorer. » (dixit et sans l’accent )

Scrongneugneu, « fichtre diantre » (en langage Fred), « tin bordel » (en langage Guiguiabloc), je look… et surprise, ce produit est bluffant.

Je cite :

« SSL-Explorer: Community Edition was an open source SSL VPN product developed by 3SP Ltd. The solution is licensed under the GNU General Public License (GPL) and is aimed primarily at smaller businesses to fulfill a requirement for remote access to internal network resources.

It is designed to be installed upon a standalone server and allows a user to connect remotely to internal corporate resources such as intranet websites, network file shares, ‘fat client’ applications and other data via a regular web browser. From the perspective of the end user the main advantage is that they have access to the applications that they would use everyday at work through a simple web browser without needing to install dedicated VPN client software. »

Google tranlate pour les anglophobes (/query pour Elwina :-p)

Pour résumé, un « portail » en java permettant d’accéder en VPN aux applis/ressources/services/web de notre LAN depuis l’extérieur sur un simple port 443 (https) ouvert depuis votre point de connexion.

Ca tue.

Donc ni une, ni deux, install :

go on : http://sourceforge.net/projects/sslexplorer

Pour les pré-requis, ANT (apt-get install ant sur Debian, yum install ant sur les redhat like ou ce que vous voulez install ant sur votre distrib easy ou compilation depuis les sources).

Un JDK focntionnel. (pas un JRE hein )

NB: lors de mes premiers tests, je suis parti sur un JDK 1.6 mais ca plante grave a la compil, donc je vous recommande chaudement de télécharger le JDK 1.5 chez Sun. (vous trouvez votre bonheur LA )

Une fois télécharger, un chmod +x sur le fichier téléchargé, on installe.

Un lien symbolique pour pas s’embêter : ln -s jdk1.5.0_12 java

On se modifie bien comme il faut notre .bashrc (.profile, ou tout autre fichier de conf de votre shell favori (Oui Poupinade, KSH, je sais … )

PATH= »/opt/java/bin:$PATH »
JAVA_HOME= »/opt/java »
export JAVA_HOME PATH

(enfin vous gérez suivant votre config hein )

On détarreGZ l’appli : tar xzvf sslexplorer-1.0.0_RC17-src.tar.gz ( du grec, detarrosgézèdes)

cd sslexplorer-1.0.0_RC17

# ant install

et ça compil…

Au bout d’un temps variable suivant que vous ayez un pentium 233mhz de récup ou un Octo-pro Quad coeur de votre boulot, l’url de l’installer s’affiche (http://lamachinedinstall:28xxx).

Un coup de navigateur pour terminer l’installation et voila, ne reste plus qu’a lancer le service.

Je ne détaille pas l’interface d’admin qui découle de souce.

#ant run

PS: je vous invite a liancer un « ant service-install » pour compiler et installer les scripts de démarrage. Peit bémol, un bug existe sous Debian, il faut passer un chmod +x sur /opt/sslexplorer-1.0.0_RC17/sslexplorer/install/platforms/linux/x86/wrapper

un /etc/init.d/sslexplorer start ou un ant run lancera le programme.

J’ai juste créer pour mon test un accés web (via Web-forward) sur un site web interne a mon LAN, en l’occurence, mon wiki.

Connexion sur https://serveurssl et on s’identifie en tant qu’admin. (suivant ce que vous avez renseigné à l’installation).

J’ai créer tout de suite un utilisateur lambda.

Puis on clique sur « Web-forward » :

On se déconnecte et on se reloggue sous l’utilisateur Lambda :

Le lien apparait, on clic dessus et un ssl-explorer-agent (en java) s’installe sur votre pc (le client doit avec un Jre quand même ).

Et une nouvelle fenêtre s’ouvre :

Magique

Vous pouvez « publier » ainsi des partages Windows, des accès FTP, des tunneling SSL sur tout les ports que vous souhaitez, bref, je vous laisse jeter un oeil à ce produit qui a d’immenses possibilités.

EDIT : 3SP, la société qui a développer SSL-Explorer offrait gracieusement 1 licence pour 2 user simultanées pour son edition Entreprise. Malheureusement, depuis plusieurs semaines, le lien direct depuis l’interface d’admin de SSL-Explorer ou l’accès direct à  http://3sp.com/en/free-sslx-license/ nous amène irrémédiablement à une page « Not Working »…

C’est bien dommage et surtout un manque de tac incompréhensible. Que le produit existe en OpenSource dans sa version Community, c’est très bien et remarquable, mais dire qu’on offre 1 licence pour 2 utilisateurs (ce qui convient à la majorité des geeks que nous sommes) et ne pas tenir ses engagements, je trouve cela plus que moyen…

Coup de gueule donc, ce soir, sur l’attitude un peu sournoise de 3SP qui, au moins, pourrait communiquer sur ce sujet…