GuiguiAbloc

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…

 

 

 

Pour les serveurs qui possèdent 2 cartes ethernet avec des adresses IP dans des VLAN différents et sans configuration supplémentaire, les trames IP qui arrivent sur l’interface eth1 ont les réponses qui partent sur eth0, qui est l’interface qui dispose de la gateway par défaut.

Ceci peut poser des problèmes de routage et de contrôle des accès.

Pour remédier à cela, je vous propose une solution qui à l’air de fonctionner et fait passer les trames aller/retour sur la même interface:

1) ajouter dans le fichier /etc/iproute2/rt_tables les lignes “<numéro table> <nom table>”

2) Si un serveur du vlan eth1 se connecte à l’adresse eth0 du serveur, pour que les paquets retour de la connexion utilisent l’interface eth0 comme les paquets aller et non eth1:

ip route add default via <gateway vlan eth0> dev eth0 table <nom table 1>
ip rule add from <vlan eth0> to <vlan eth1> table <nom table 1> priority <niveau 1>

3) Pour une connexion entre 2 serveurs du vlan eth1, pour que les paquets passent par l’interface eth1 sans contacter la gateway d’eth1 qui sera définie dans la règle suivante et éviter ainsi le filtrage de la gateway:

ip route add dev eth1 table <nom table 2>
ip rule add from <vlan eth1> to <vlan eth1> table <nom table 2> priority <niveau 2>

4) Si un serveur hors du vlan eth1 se connecte à l’adresse eth1 du serveur, pour que les paquets retour passent par eth1 et non la default gateway de eth0.

ATTENTION: cette règle doit obligatoirement avoir un niveau de priorité supérieur à la règle précédente:

ip route add default via <gateway vlan eth1> dev eth1 table <nom table 3>
ip rule add from <vlan eth1> table <nom table 3> priority <niveau 2> + 1

5) faire un flush des routes:

ip route flush cache

6) pour que les définitions soient ajoutées/supprimées lors des activations/désactivations des interfaces, il faut créer les scripts shell /sbin/ifup-local et /sbin/ifdown-local.

Le premier script contiendra les règles vues précédemment et le second les même règles en modifiant “add” par “del”.

Ces scripts sont automatiquement appelés par les scripts de manipulation des interfaces réseaux et sont lancés avec comme paramètre le nom de l’interface.

Dans les scripts c’est le test de ce paramètre (exemple eth1) qui permettra de créer/supprimer les règles de routage.

Les commandes pour vérifier la configuration:

1. pour voir les règles: ip rule show

2. pour voir le routage: ip route show table vlan124

Exemple d’un serveur avec le vlan 51 sur eth0 et le vlan 124 sur eth1:

1) fichier rt_tables:

51 	vlan51
124	vlan124
125	vlan124out

2) Pour que les paquets qui sortent de 10.144.51 vers 10.144.124 utilisent eth0 et non eth1 (cas des paquets retour d’une connexion d’un serveur 10.144.124 vers l’interface 10.144.51)

ip route add default via 10.144.51.254 dev eth0 table vlan51
ip rule add from 10.144.51.0/24 to 10.144.124.0/22 table vlan51 priority 51

3) Pour que les paquets de 10.144.124 vers 10.144.124 passent par l’interface eth1 sans contacter la gateway

ip route add dev eth1 table vlan124
ip rule add from 10.144.124.0/22 to 10.144.124.0/22 table vlan124 priority 124

4) Pour que les paquets qui sortent de 10.144.124 passent par eth1 et la gateway (cas d’une connexion d’un poste hors vlan 124 vers le vlan 124) avec nécessairement une priorité supérieure à la règle précédente

ip route add default via 10.144.127.254 dev eth1 table vlan124out
ip rule add from 10.144.124.0/22 table vlan124out priority 125

Avec l’ajout de nouveaux serveurs, pc, équipements dans votre réseau, la centralisation des logs sur une seule machine devient une évidence.

Passer 1 heure a se connecter en ssh, minicom ou autre sur chaque bestiole pour vérifier les logs devient vite fastidieux et la mise en place d’un « Syslog Host » (terme que j’emploierai pour désigner le serveur de récupération des logs) coule de source.

Heureusement, ce genre de déploiement est assez simple car déjà inclus nativement sur nos Linux / *BSD préféré.

Le choix du serveur de logs n’est pas non plus à prendre a la légère. Outre le volume de données a stocker/traiter, la criticité d’une telle machine ne doit pas être oubliée.

1. Vous vous exposez à une « attaque » de type Syslog Bombing
2. Certains logs peuvent être sensible et ne pas être donné en pature a n’importe quel lecteur

Prévoyez donc une partition dédiée (type /var/log) suffisamment dimensionnée et réservée aux logs.

Côté sécurité réseau, les flux Syslog utilisent le protocole UDP sur le port 514, a vous donc de positionner vos ACL et/ou règles Firewall en conséquences et bien entendu à ne pas l’exposer au réseau Internet.

L’idéal étant bien évidemment de positionner le SyslogHost dans un VLAN dédié ou vous n’autoriserez que l’UDP port 514 et le SSH depuis le poste de management.

(Petite parenthèse d’humour paranoïaque :
La sécurité ultime étant justement d’utiliser la particularité du protocole UDP qui travaille en mode non-connecté pour couper physiquement le fil TX du câble réseau côté carte du SyslogHost

Bon OK, là c’est vraiment Parano

fin de la parenthèse qui sert à rien)

Activation du démon Syslogd

Sur votre Pingouin, il suffit de rajouter l’option « -r » a Syslog.

Debian Like : /etc/default/syslogd

RedHat Like : /etc/sysconfig/syslog

Relancer syslog.

Sur le Poisson qui pique, ajouter le flag -u dans votre /etc/rc.conf :

syslogd_flags= »-u »

Killer le process Syslogd et relancer le en mode -u : syslogd -u

Un netstat -an | grep 514 vous confirmera l’écoute :

udp 0 0 *.514 *.*

Sur les clients, il suffit maintenant de modifier le fichier /etc/syslog.conf pour lui demander de tout envoyer au Syslog Host :

Ex: *.* @192.168.0.1

Bien sur vous pouvez peaufiner ce que vous voulez envoyer comme logs. (lire cet article par exemple).

N’oubliez surtout pas de configurer la rotation automatique des logs !!!

Avec logrotate.d sur Linux et Newsyslog sur OpenBSD (MAN est votre ami)…

Remontée les logs Cisco

Les Ciscos savent envoyer leurs logs ves un Syslog host.

Sur un routeur :

logging 192.168.0.1

Sur un Pix :

logging host inside 192.168.0.1

Par défaut, les Ciscos envoient leurs logs avec le niveau local.7

Il peut être intéressant de peaufiner le traitement des logs et de séparer les logs « syslog » des machines, des logs équipements.

Pour un Pix par exemple, nous pouvons utiliser le tableau suivant :

Facility	Logging Facility Command Value	local 0	16
local 1	17
local 2	18
local 3	19
local 4	20
local 5	21
local 6	22
local 7	23

 

1. Préparons le SyslogHost a recevoir les logs : local3.debug /var/log/cisco.log (dans le syslog.conf)
2. Sur le Pix ou le routeur Cisco :

logging trap informational
logging facility 19

Car facility 19 = local 3

NB : Il s’agit simplement d’une traduction du binaire :-p

• 16 = 00010000 = local0
• 17 = 00010001 = local1
• 18 = 00010010 = local2
• 19 = 00010011 = local3
• 20 = 00010100 = local4
• 21 = 00010101 = local5
• 22 = 00010110 = local6
• 23 = 00010111 = local7

On utilise les 4 derniers bits, exemple 22 = 00010110, les 4 derniers =0110 = en décimal 6, c’est du local 6.

Le flag Trap est le niveau de log voulu :

alerts Immediate action needed (severity=1)
critical Critical conditions (severity=2)
debugging Debugging messages (severity=7)
emergencies System is unusable (severity=0)
errors Error conditions (severity=3)
informational Informational messages (severity=6)
notifications Normal but significant conditions (severity=5)
warnings Warning conditions (severity=4)

Les commandes suivantes ne sont pas négligeables à rajouter :

service timestamps log datetime localtime (Cisco routeur)

logging timestamp (Cisco PIX)

Si cela vous amuse vous pouvez également coloriser vos logs qui s’afficheront (voir l’article ICI ).

Traitement des logs

Se coltiner des flux continus de logs qui défilent n’est pas des plus agréables et une information Critique peut vous échapper si vous ne lisez pas vos logs ou ne les traiter pas automatiquement.

Il existe des multitudes de script vous permettant de parser vos logs et d’en extraire les informations essentielles, je vous laisse avec Google pour faire le plein de bonne solution.

Personnellement, comme je l’avais expliqué dans un billet précédent, j’utilise Prelude comme centralisateur d’informations et en installant un module Prelude-LML (LML : Log Monitoring Lackey) sur le SyslogHost, je remonte tout cela sur le Prelude Manager et une bonne moulinette maison me permet d’être alerté en temps réel en cas d’incident.

J’espère que vous prendrez conscience de l’utilité et de l’importance de la centralisation des logs qui n’a été que rapidement approchée dans ce billet mais que vous pourrez étendre beaucoup plus loin (remontée des logs applicatives par exemple (qui a dit Log4j ??? ) etc..

Bon courage

Intégration d’un Firewall Vert

Je vous avez déjà parler des VLANs dans un billet précédent et pour la suite de cet article, je vais m’y attarder un peu plus.

Pour gérer et contrôler mes VLANs, je me sert bien évidemment de cette fonction sur le switch Cisco CATALYST.

La création se fait en deux lignes de commandes :

catalyst#vlan database

catalyst(vlan)#vlan 66 name mon-vlan
VLAN 66 added:
Name: mon-vlan

Apply et voila, le vlan est créé

Il ne reste plus qu’à l’affecter à un port physique :

catalyst#conf t
Enter configuration commands, one per line. End with CNTL/Z.
catalyst(config)#int f
catalyst(config)#int fastEthernet 0/1
catalyst(config-if)#switchport access vlan 66

Et c’est tout, le serveur/poste relié sur le port 1 du switch Catalyst sera dans le vlan 66.

C’est bien beau tout cela, mais ca ne fait pas grand chose, a part isoler vos réseaux LANs.

Nous allons donc rajouter un équipement supplémentaire qui fera office de routeur (et donc de passerelle pour chaque VLAN), mais également de Firewall Vert.

C’est à dire qu’il gèrera les accès entre les VLANs (un poste dans le vlan 2 voulant voir le site web du serveur dans le vlan 30) et également, fera office de firewall sortant (toutes les machines de mon LAN vers le méchant NainTernet).

L’équipement que j’ai choisi est le Cisco 2611 XM.

Toujours pour Elwina je l’ai acheté 180,00 euros + 17,00 euros de Frais de Port sur eBay.

N.B. : Si vous décidez d’achetez un routeur Cisco de la série 2600 (2610,2611, etc.), soyez attentif :

Tout vendeur sérieux affichera un « show version » du routeur qui vous donnera les informations nécessaires. Voila à quoi cela ressemble et les points qu’il faut surveiller (en gras) :

routeur#show version
Cisco IOS Software, C2600 Software (C2600-ADVENTERPRISEK9-M), Version 12.4(18), RELEASE SOFTWARE (fc1)

la version de l’IOS présent, je vous en reparlerais
Technical Support: http://www.cisco.com/techsupport
Copyright (c) 1986-2007 by Cisco Systems, Inc.
Compiled Fri 30-Nov-07 15:38 by prod_rel_team

ROM: System Bootstrap, Version 12.2(7r) [cmong 7r], RELEASE SOFTWARE (fc1)

routeur uptime is 6 weeks, 20 hours, 32 minutes
System returned to ROM by power-on
System restarted at 18:12:55 GMT+1 Mon Feb 25 2008
System image file is « flash:c2600-adventerprisek9-mz.124-18.bin »
L’emplacement et la version de l’IOS
This product contains cryptographic features and is subject to United
States and local country laws governing import, export, transfer and
use. Delivery of Cisco cryptographic products does not imply
third-party authority to import, export, distribute or use encryption.
Importers, exporters, distributors and users are responsible for
compliance with U.S. and local country laws. By using this product you
agree to comply with applicable laws and regulations. If you are unable
to comply with U.S. and local laws, return this product immediately.

A summary of U.S. laws governing Cisco cryptographic products may be found at:

http://www.cisco.com/wwl/export/crypto/tool/stqrg.html

If you require further assistance please contact us by sending email to
export@cisco.com.

Cisco 2611XM (MPC860P) processor (revision 1.0) with 127308K/3764K bytes of memory.

La quantité de RAM installée, si vous voulez utilisez les fonctions de cryptage, 128 Mo comme ici, est un minimum.
Processor board ID xxxxxxxxx
M860 processor: part number 5, mask 2
2 FastEthernet interfaces Le nombre et le type d’interface Réseau (fastEthernet = 100 Mbps, Ethernet = 10 Mbps)
1 Serial interface
32K bytes of NVRAM.
32768K bytes of processor board System flash (Read/Write)

La taille de la mémoire Flash, TRES IMPORTANT, pour un IOS décent, il vous faut au moins 16Mo (avec 8Mo vous aurez les fonctions de base IP), comptez 32 Mo comme ici pour un IOS avec fonctionnalités Firewall

Pour résumé, vérifier que votre interface (ou vos interfaces) réseau est en 100 mbps minimum, que la quantité de mémoire FLASH et RAM est suffisante pour pouvoir évoluer.

La mémoire pour routeur Cisco est assez chère donc prévoyez d’avance. De plus, une grande partie des routeurs 2600 vendus sur eBay n’ont que les fonctions basiques et ne dispose que de 8Mo de mémoire FLASH.

J’oubliez une autre chose TRES importante :

Un équipement CISCO comme le 2600 (ou même le Catalyst d’ailleurs) est très bruyant (grosse ventilation).

Je vous aurais prévenu

A suivre…