Synchronisation rsync via un un tunnel ssh

J’ai découvert il y a peut de temps une fonctionnalité bien utile pour lancer une synchronisation RSYNC via un tunnel SSH sous Linux.

L’intérêt est de pouvoir bypasser un proxy ou bien un firewall sous réserve d’avoir accès à SSH à un serveur n’étant pas soumis au même restriction.

Pré-requis:

  • Avoir accès en ssh à un serveur non filtré
  • Avoir netcat d’installé sur ce serveur

Pour cela, rien de plus simple. Un petit export dans son shell de la variable RSYNC_CONNECT_PROG avec les paramètres ci-dessous.

$ export RSYNC_CONNECT_PROG='ssh login@monserveur nc %H 873'

Dès qu’une synchronisation rsync est réalisée, un ssh est fait sur le serveur monserveur puis votre mot de passe vous sera alors demandé (vous pouvez très bien utiliser des clés ssh). Pour finir, un netcat est lancé sur le port 873 sur l’hôte (%H) défini dans la commande rsync.

Lien Permanent pour cet article : https://www.batard.eu/2014/07/synchronisation-rsync-via-un-un-tunnel-ssh/

Créer son cloud personnel

En voulant surfer sur la vague de l’auto hébergement, en évitant soigneusement les Dropbox, Google Drive & co, j’ai découvert les projets libres Owncloud et Cozycloud (en beta).

Owncloud

Le principe est simple. Ces deux logiciels sont des plateformes de services en ligne, sortes de frontaux web qui utilisent des connecteurs du type systèmes de fichiers, serveur FTP et d’autres pour la partie stockage.

Cozycloud

Vous pouvez partager fichiers, calendriers, flux RSS, musiques ou photos d’un simple clic de souris. Les utilisateurs peuvent également générer des liens temporaires (ou non) pour partager des fichiers avec des personnes ne possédant pas de compte.

En parlant des utilisateurs, il pourrait être intéressant de proposer de créer un compte via la page de login car pour le moment, c’est à l’administrateur de le faire. Sinon, des connecteurs WordPress et LDAP existent parmi d’autres.

Les deux interfaces sont assez user-friendly et proposent même une galerie photo assez sympathique. Elles sont intuitives et jolies. C’est assez rare pour des produits venant du libre (seek!)

Certains se sont amusés à porter ces deux solutions sur des NAS type Synology ou Qnap mais rien n’empêche d’avoir son serveur en frontal et de connecter un partage/lecteur NFS, SAMBA, ISCSI via un NAS.

Des clients existent pour les téléphones (iOS et Android) et pour PC (Windows, Linux, OSX) mais je n’ai pas eu l’occasion de tester car redondant avec mon NAS actuel.

Pour finir avec Owncloud et Cozycloud, il est toujours possible de développer ses propres connecteurs ou bien de développer des modules additionnels tels que des clients IRC, webmail, etc.

[important]Il est possible de tester Owncloud et Cozycloud directement sur leur site respectif.[/important]

[important]MAJ du 12/07/2013:

Je viens de voir que le nouvel OS de la Freebox permet de partager des données via des liens temporaires. Reste à savoir si Free permettra le changement de disque dur. Cela m’étonnerait beaucoup qu’il ait développé un OS aux fonctionnalités riches uniquement pour la Freebox Révolution. Peut être le proposeront-ils un jour en option des NAS.

Synology a publié sa beta de DSM 4.3. Ils proposeront également de partager des données via des liens. A tester donc prochainement.
[/important]

Liens:

https://www.cozycloud.cc/
http://owncloud.org/
http://fr.wikipedia.org/wiki/OwnCloud

Lien Permanent pour cet article : https://www.batard.eu/2013/07/choisir-son-cloud-personnel/

Debugger une connexion SSL avec Openssl

Les certificats et leur gestion restent toujours un peu obscur pour un grand nombre de personnes. Bien qu’il soit assez facile de configurer apache et mod_ssl avec un certificat auto-signé, il peut en être tout autre avec des certificats signés par une autorité de certification reconnue type thawte, Verisign,…. Ajoutez à cela la gestion des certificats clients, on peut rapidement en perdre la tête.

je vais vous présenter différentes façons de débugger une connexion SSL depuis un poste client avec Openssl. Vous saurez ainsi rapidement si votre web server est bien configuré, c’est à dire si les certificats, et donc la chaine de certification, présentés à votre navigateur sont ceux attendus, et si des certificats clients sont exigés.

Pré-requis

Le cas de figure présenté ici consiste en :

– une Autorité de Certification (AC) auto-signée
– un certificat serveur signé par l’AC
– un certificat client signé par l’AC
– un apache + mod_ssl configuré pour exigé un certificat client signé par l’AC

Si ce n’est pas déjà fait, téléchargez OpenSSL sur votre poste !!

Vérification de la connexion SSL

Ici, nous vérifions, dans un premier temps, que la connexion SSL fonctionne, en gros, que nous avons configuré correctement notre web server.

$ openssl s_client -connect neosec.batard.eu:443
CONNECTED(00000003)
depth=1 /C=FR/ST=Ile-de-France/L=Villejuif/O=Batard/CN=batard.eu/emailAddress=webmaster@batard.eu
verify error:num=19:self signed certificate in certificate chain
verify return:0
835:error:14094410:SSL routines:SSL3_READ_BYTES:sslv3 alert handshake failure:/SourceCache/OpenSSL098/OpenSSL098-35/src/ssl/s3_pkt.c:1061:SSL alert number 40
835:error:140790E5:SSL routines:SSL23_WRITE:ssl handshake failure:/SourceCache/OpenSSL098/OpenSSL098-35/src/ssl/s23_lib.c:188:

openssl s_client -connect host:port lance une com SSL vers le serveur (host) sur le port 443, port par défaut de SSL. Changez le si nécessaire.

Nous pouvons constater assez facilement que nous avons réussi à monter une com SSL grâce à CONNECTED(00000003). Cependant, la négociation SSL n’est pas arrivée à son terme d’après le message d’erreur sslv3 alert handshake failure.
Nous allons tenter de trouver pourquoi.

Visualiser le handshake SSL

L’option que je vais vous présenter permet de visualiser le handshake SSL dans son ensemble en hexadécimal.
Ci-dessous, le schéma d’un handshake SSL réussi:

SSL Handshake

Schéma d’une négociation SSL

Pour plus d’informations sur le détail de chaque phase, un petit tour sur Wikipedia s’impose.

$ openssl s_client -connect neosec.batard.eu:443 -msg
CONNECTED(00000003)

>>> SSL 2.0 [length 007d], CLIENT-HELLO
01 03 01 00 54 00 00 00 20 00 00 39 00 00 38 00
...
...
aa ea 7b 8b fe a2 c7 57 a3 da 77 3e 52

<<< TLS 1.0 Handshake [length 004a], ServerHello
02 00 00 46 03 01 4d 7b 5c aa 1f cd d9 b3 35 31
c2 41 7a e3 b1 0d 59 24 7f 95 4a 99 57 f5 b5 07
ba 94 44 ce 40 3a 20 3c 12 10 64 58 43 99 c3 4b
03 59 d5 b6 3c ba 7c 8d a3 78 9a 9e 87 fb 6b d8
ad 5b b0 87 f5 22 2d 00 39 00

<<< TLS 1.0 Handshake [length 09c2], Certificate
0b 00 09 be 00 09 bb 00 04 f4 30 82 04 f0 30 82
...
...
91 2f 73 5d 25 8d 4c 0c bb 23 63 7c a1 92 a3 1f
a3 6a

depth=1 /C=FR/ST=Ile-de-France/L=Villejuif/O=Batard/CN=batard.eu/emailAddress=webmaster@batard.eu
verify error:num=19:self signed certificate in certificate chain
verify return:0

<<< TLS 1.0 Handshake [length 020d], ServerKeyExchange
0c 00 02 09 00 80 d6 7d e4 40 cb bb dc 19 36 d6
...
...
a5 89 36 49 8e 50 e3 f3 11 79 8b 3d c0 14 72 6f
c9 64 e3 6c d7 2c 84 bc 2f cd 90 2b 94

<<< TLS 1.0 Handshake [length 0093], CertificateRequest
0d 00 00 8f 05 03 04 01 02 40 00 87 00 85 30 81
...
...
77 65 62 6d 61 73 74 65 72 40 62 61 74 61 72 64
2e 65 75

<<< TLS 1.0 Handshake [length 0004], ServerHelloDone 0e 00 00 00 >>> TLS 1.0 Handshake [length 0007], Certificate
0b 00 00 03 00 00 00

>>> TLS 1.0 Handshake [length 0086], ClientKeyExchange
10 00 00 82 00 80 3c 4c f3 f0 d8 ed 65 e7 23 d5
..
..
92 fb 15 b5 e9 28 e8 ee de 84 d8 6d c7 c2 b0 8e
fd e5 e1 b2 b3 70
>>> TLS 1.0 ChangeCipherSpec [length 0001]
01

>>> TLS 1.0 Handshake [length 0010], Finished
14 00 00 0c 63 40 d7 34 d5 5b 8c 02 2b da d6 e6

<<< TLS 1.0 Alert [length 0002], fatal handshake_failure
02 28

698:error:14094410:SSL routines:SSL3_READ_BYTES:sslv3 alert handshake failure:/SourceCache/OpenSSL098/OpenSSL098-35/src/ssl/s3_pkt.c:1061:SSL alert number 40
698:error:140790E5:SSL routines:SSL23_WRITE:ssl handshake failure:/SourceCache/OpenSSL098/OpenSSL098-35/src/ssl/s23_lib.c:188:

Nous pouvons voir qu’ici, le serveur a bien présenté son certificat et qu’il a été accepté par le client. Or, l’opération se termine par un fatal handshake_failure.

Identifier les certificats requis par un serveur lors d’une authentification cliente

prexit, ma commande préférée. OpenSSL n’affiche pas toutes les informations lorsqu’une session SSL échoue. Cette option permet de palier à ce problème. Voici comment.

$ openssl s_client -connect batard.eu:443 -prexit
CONNECTED(00000003)

depth=1 /C=FR/ST=Ile-de-France/L=Villejuif/O=Batard/CN=batard.eu/emailAddress=webmaster@batard.eu
verify error:num=19:self signed certificate in certificate chain
verify return:0
823:error:14094410:SSL routines:SSL3_READ_BYTES:sslv3 alert handshake failure:/SourceCache/OpenSSL098/OpenSSL098-35/src/ssl/s3_pkt.c:1061:SSL alert number 40
823:error:140790E5:SSL routines:SSL23_WRITE:ssl handshake failure:/SourceCache/OpenSSL098/OpenSSL098-35/src/ssl/s23_lib.c:188:
---
Certificate chain
0 s:/C=FR/ST=Ile-de-France/O=Batard/CN=www.batard.eu/emailAddress=webmaster@batard.eu
i:/C=FR/ST=Ile-de-France/L=Villejuif/O=Batard/CN=batard.eu/emailAddress=webmaster@batard.eu
1 s:/C=FR/ST=Ile-de-France/L=Villejuif/O=Batard/CN=batard.eu/emailAddress=webmaster@batard.eu
i:/C=FR/ST=Ile-de-France/L=Villejuif/O=Batard/CN=batard.eu/emailAddress=webmaster@batard.eu
---
Server certificate
-----BEGIN CERTIFICATE-----
MIIE8DCCA9igAwIBAgIBATANBgkqhkiG9w0BAQUFADCBgjELMAkGA1UEBhMCRlIx
...
...
A3r15TfDatqGp8tnTeyJ8FoB6KA=
-----END CERTIFICATE-----
subject=/C=FR/ST=Ile-de-France/O=Batard/CN=www.batard.eu/emailAddress=webmaster@batard.eu
issuer=/C=FR/ST=Ile-de-France/L=Villejuif/O=Batard/CN=batard.eu/emailAddress=webmaster@batard.eu
---
Acceptable client certificate CA names
/C=FR/ST=Ile-de-France/L=Villejuif/O=Batard/CN=batard.eu/emailAddress=webmaster@batard.eu
---
SSL handshake has read 3275 bytes and written 210 bytes
---

Une information importante nous intéresse particulièrement ici. Acceptable client certificate CA names nous indique clairement les certificats clients trustés par le serveur. Il suffit alors de vérifier le certificat client présenté au serveur et le tour est joué.

Résoudre les problèmes de « unable to verify the first certificate »

Lors d’une connexion avec openssl s_client, vous rencontrerez sûrement le message suivant :

 Verify return code: 21 (unable to verify the first certificate) 

Cela signifie qu’openssl n’a pas réussi à valider la chaîne de certification, c’est à dire le certificat serveur + l’autorité de certification.

Pour vérifier la chaîne de certification, ajoutez la directive -CAfile à openssl pour lui préciser quelle est l’autorité de certification du certificat serveur. Utile dans le cas où openssl n’a pas dans son référentiel le certificat racine du certificat serveur. Cette directive ne sert que pour des tests.

Exemple:

openssl s_client -connect monsite.com:443 -CAfile mofichierCA.pem

Assurez vous également que le serveur renvoie bien la chaîne de certification complète dans le cas d’un AC de type distribuée avec différentes AC intermédiaires comme Verisign.Verisign propose différents types de certificats qui sont générés par des AC intermédiaires également différentes. Par conséquent, l’utilisateur final, humain ou machine, n’a aucune connaissance de l’AC ayant généré le certificat serveur. C’est pour cette raison que c’est au serveur de l’envoyée en même temps que son propre certificat. Vous pouvez le vérifier via la log suivante

depth=n 

où n est la profondeur dans la hiérarchie de certificat. certificat serveur -> certificat intermédiaire -> certificat racine.
La directive apache permettant d’envoyer la chaîne de certification est

 SSLCertificateChainFile 

Lien Permanent pour cet article : https://www.batard.eu/2011/03/debugger-une-connexion-ssl-avec-openssl/

Maîtriser les certificats avec OpenSSL

Cet article a pour but de vous présenter les différentes possibilités offertes par l’outil Open Source qu’est openSSL. Cet outil puissant et incontournable doit être maîtrisé pour gérer correctement ses certificats.

Gestion d’une Autorité de Certification (CA ou AC en français)

 Générer une clé RSA 2048 bits et protection de cette clé par chiffrement AES 256

# openssl genrsa -aes256 -out private/CA.key 2048

genrsa : Directive pour générer des clés privées
aes256 : Chiffre la clé privée en AES 256
out : Enregistre la clé privée RSA 2048 bits chiffrée en AES 256 dans le fichier passé en paramètre
2048 : Nombre de bits de la clé privée

Créer une Autorité de Certification racine (‘CA ROOT’) autosignée

# openssl req -new -x509 -sha256 -days 3650 -key private/CA.key -out certs/CA.pem

req : Directive de gestion des requêtes de certificats
new : Génère une nouvelle demande de certificat
x509 : Génère un certificat autosigné
days : Détermine la période de validité du certificat si l’option x509 est spécifiée (30j par défaut)
key : Utilise la clé contenue dans le fichier passé en paramètre
out : Enregistre dans le fichier passé en paramètre le résultat

Révoquer un certificat

# openssl ca -revoke CERTIFICATE.pem

ca : Directive de gestion des certificats
revoke : Révoque le certificat passé en paramètre

Créer d’une liste de révocation (CRL) d’un période de validité de 30 jours

# openssl ca -gencrl -out CRL.pem -crldays 30

ca : Directive de gestion des certificats
gencrl : Génère une liste de révocation de certificats (CRL)
out : Enregistre la CRL dans un fichier
crldays : Spécifie la période de validité de la CRL

Visualiser une CRL

# openssl crl -in CRL.pem -text

crl : Directive de gestion des CRL
in : Spécifie la CRL à lire
text : Affiche la CRL au format texte

Gestion des certificats

Générer un certificat autosigné

# openssl req -x509 -days 365 -newkey rsa:2048 -keyout PRIVATE_KEY.key -out CERTIFICATE.crt

req : Directive de gestion des requêtes de certificats
x509 : Génère un certificat autosigné
days : Détermine la période de validité du certificat si l’option x509 est spécifiée (30j par défaut)
newkey : Crée une requête de certificat et une clé privée. Prend la forme rsa:nbits, où nbits détermine le nombre de bits de la clé privée
keyout : Enregistre la clé privée dans le fichier passé en paramètre
out : Enregistre le certificat généré dans le fichier passé en paramètre

Générer une clé RSA 2048 bits et protection de cette clé par chiffrement AES 256

# openssl genrsa -aes256 -out private/SERVER.key 2048

genrsa : Directive pour générer des clés privées
aes256 : Chiffre la clé privée en AES 256
out : Enregistre la clé privée RSA 2048 bits chiffrée en AES 256 dans le fichier passé en paramètre
2048 : Nombre de bits de la clé privée

Créer une demande de certificat serveur (CSR : Certificate Signing Request)

# openssl req -sha256 -new -key private/SERVEUR.key -out certs/SERVER.req

req : Directive de gestion des requêtes de certificats
sha256 : Algorithme de signature du CSR. Peut être md5, sha1 …
new : Génère une nouvelle demande de certificat
key : Utilise la clé privée contenue dans le fichier passé en paramètre
out : Enregistre le CSR dans le fichier passé en paramètre

Signer le certificat par la CA

# openssl ca -days 365 -in certs/SERVER.req -out certs/SERVER.pem

ca : Directive de gestion des certificats
days : Détermine la période de validité du certificat
in : Fichier en entrée contenant un CSR
out : Enregistre le certificat dans le fichier passé en paramètre

Remarque:
Il est possible de rajouter la directive -config pour préciser le fichier de configuration de la CA à utiliser. Par défaut, le fichier de configuration config.cnf d’openSSL est utilisé.

Visualiser un certificat

# openssl x509 -in certs/SERVER.pem -noout -text

x509 : Directive de gestion des certificats
in : Fichier en entrée contenant un certificat
noout : Empêche l’affichage de la version encodée en base 64 du fichier en entrée
text : Affiche le certificat en entrée sous sa forme textuelle

Supprimer la passphrase d’une clé privée

# openssl rsa -in ENC_KEY.key -out NO_CRYPT_KEY.key

rsa : Directive de gestion des clés RSA
in : Fichier en entrée contenant une clé privée
out : Enregistre la clé sans protection dans le fichier passé en paramètre

Vérification d’un certificat

Tester une clé

# openssl rsa -noout -modulus -in SERVER.key | openssl md5

rsa : Directive de gestion des clés RSA
noout : Empêche l’affichage de la version encodée en base 64 du fichier en entrée
modulus : Affiche le modulus de la clé privée
in : Fichier en entrée contenant une clé privée

Remarque:
En greppant avec openssl md5, on réduit l’affichage du modulus en n’affichant que sa signature MD5

Tester un CSR

# openssl req -noout -modulus -in SERVER.csr | openssl md5

req : Directive de gestion des requêtes de certificats
noout : Empêche l’affichage de la version encodée en base 64 du fichier en entrée
modulus : Affiche le modulus de la clé publique contenue dans la requête de certificat
in : Fichier en entrée contenant une requête de certificat

Remarque:
En greppant avec openssl md5, on réduit l’affichage du modulus en n’affichant que sa signature MD5

Tester un certificat

# openssl x509 -noout -modulus -in SERVER.crt | openssl md5

x509 : Directive de gestion des certificats
noout : Empêche l’affichage de la version encodée en base 64 du fichier en entrée
modulus : Affiche le modulus de la clé publique contenue dans le certificat
in : Fichier en entrée contenant un certificat

Remarque:
En greppant avec openssl md5, on réduit l’affichage du modulus en n’affichant que sa signature MD5

Conversion d’un certificat

La conversion d’un certificat dans un format différent de celui d’origine peut s’avérer utile en fonction de l’utilisation. Afin de rendre compatible un certificat, openSSL propose différentes commandes pour convertir du format binaire DER (.crt, .cer, .der) au format texte PEM et vice versa. Le format PEM n’est qu’un encodage base 64 du certificat binaire.

Convertir un fichier binaire DER (.crt .cer .der) en PEM

# openssl x509 -inform der -in SERVER.crt -out SERVER.pem

x509 : Directive de gestion des certificats
inform : Spécifie le format d’entrée attendu [der/pem]
in : Fichier en entrée contenant un certificat binaire
out : Enregistre le certificat binaire DER converti en PEM dans le fichier passé en paramètre

Convertir un fichier PEM en DER

# openssl x509 -outform der -in SERVER.pem -out SERVER.der

x509 : Directive de gestion des certificats
outform : Spécifie le format de sortie attendu [der/pem]
in : Fichier en entrée contenant un certificat der/pem
out : Enregistre le certificat converti dans le fichier passé en paramètre
Un fichier PKCS12 est un conteneur, contenant (si, si je vous jure) une clé privée et une clé publique (le certificat) protégés par un mot de passe.

Convertir un fichier PKCS#12 (.pfx, .p12) contenant une clé privée et un certificat en PEM

# openssl pkcs12 -in KEYSTORE.pfx -out KEYSTORE.pem

pkcs12 : Directive de gestion des conteneurs PKCS12
in : Fichier PKSC12 en entrée
out : Enregistre dans un fichier PEM le contenu du PKCS12

Convertir un fichier PEM et une clé privée en PKCS#12 (.pfx, .p12)

# openssl pkcs12 -export -out KEYSTORE.pfx -inkey PRIVATE_KEY.key -in SERVER.crt -certfile CACERT.crt

pkcs12 : Directive de gestion des conteneurs PKCS12
export : Spécifie qu’un fichier pkcs12 sera créé et non parsé
out : Fichier de sortie du PKCS12 à créer
inkey : Fichier contenant une clé privée
in : Fichier en entrée contenant des certificats et des clés privées au format PEM à ajouter dans le PKCS12
certfile : Fichier contenant d’autres certificats

Remarque:
La directive export change le comportement des directives in ou out

Lien Permanent pour cet article : https://www.batard.eu/2010/11/maitriser-les-certificats-avec-openssl/

Sécurisation de switchs CISCO

Pour ce premier article, j’ai décidé de passer en revue les options à configurer ou à désactiver pour sécuriser des commutateurs (désolé je n’y arrive pas à le dire) switchs CISCO.

N’hésitez pas à laisser des commentaires pour me faire par de vos remarques, tips ou correction.

Pour rentrer dans le vif du sujet, je vous conseille pour l’installation et le configuration d’un switch, de le réinitialiser en configuration usine pour éviter tout reliquat d’une conf précédente:

cisco# write erase
Erasing the nvram filesystem will remove all files! Continue? [confirm]y[OK]
Erase of nvram: complete
cisco# reload

Pensez aussi à effacer les VLANs:

cisco# delete flash:/vlan.dat
Delete flash:vlan.dat? [confirm]y
cisco# reload
Proceed with reload? [confirm]y
4w5d: %SYS-5-RELOAD: Reload requested

Au redémarrage, l’assistant d’installation propose de configurer certains paramètres. Perso, je préfère m’en passer pour maîtriser chaque ligne de configuration mais à vous de voir.

Would you like to terminate autoinstall? [yes]: N

Paramètres de base

Changer le nom et le domaine de l’équipement

En prévision de l’activation de SSH, certaines options comme le hostname ou le domain name doivent être définis. Elles sont notamment utilisées lors génération de la paire de clé RSA.

cisco(config)# hostname
cisco(config)# ip domain name

Ajout d’une bannière

Une bannière, ou Message Of The Day (MOTD), est un message d’avertissement affiché lors d’une connexion à un équipement. Il avertit l’utilisateur se connectant des risques encourus en cas de tentative de connexion illégitime.

La commande ci-dessous permet l’ajout d’une bannière. Le ‘^C’ représente ici la combinaison de touche CTRL + C. Il détermine le caractère de fin du message. :

cisco(config)# banner motd ^C
____________________________________________________________________________________

                   L'acces est limite aux personnes autorisees

  Article 323-1 du code penal :

  Le fait d'acceder ou de se maintenir, frauduleusement, dans tout ou partie d'un
 systeme de traitement automatise de donnees est puni de deux ans  d'emprisonnement
 et de 30000 Euro d'amende (150 000 Euro pour les personnes morales)
___________________________________________________________________________________^C

Gestion des comptes

Je vous recommande plus que vivement d’utiliser des mots de passe complexes, c’est-à-dire qui doivent contenir au minimum 3 des conditions suivantes :

  • Une longueur minimum de 8 caractères
  • Contenir des caractères alphabétiques minuscules
  • Contenir des caractères alphabétiques majuscules
  • Contenir des caractères numériques
  • Contenir des caractères spéciaux

Activer un enable secret

Un enable secret de type 5 utilise l’algorithme MD5 (salted) avec du sel. Seules les rainbows tables peuvent théoriquement casser ajourd’hui ce type de protection bien que le sel augmente considérablement la sécurité du chiffrement MD5.

cisco(config)# no enable password
cisco(config)# enable secret MOT_DE_PASSE_COMPLEXE

Aucun enable password ne doit être paramétré sur un équipement du fait que le mot de passe apparaitra en clair dans le fichier de conf. Cette commande est dépréciée par CISCO. C’est pour cette raison qu’un enable secret est plus que conseillé.

Ajout d’un compte local

En cas d’authentification centralisée, il est toujours bon d’avoir un compte de backup pour pouvoir s’authentifier:

cisco(config)# username secret 5 MOT_DE_PASSE_COMPLEXE

Gérer l’authentification RADIUS

Les switchs CISCO supportent l’authentification avec le protocole RADIUS. L’utilisateur peut être ainsi authentifié grâce des systèmes de gestion centralisée de mots de passe supportant ce protocole.

  • Pour commencer, il est nécessaire de créer un model AAA (Authentication, Authorization and Accounting).
cisco(config)# aaa new-model
  • Ensuite, un groupe de serveurs RADIUS doit être défini
cisco(config)# radius-server host IP_SERVER1 auth-port 1645 acct-port 1646 key 7 PRE_SHARED_KEY
cisco(config)# radius-server host IP_SERVER2 auth-port 1645 acct-port 1646 key 7 PRE-SHARED_KEY
cisco(config)# radius-server directed-request

On Définit un groupe de serveurs RADIUS

cisco(config)# aaa group server radius RadiusGroup
cisco(config)# server IP_SERVER1 auth-port 1645 acct-port 1646
cisco(config)# server IP_SERVER2 auth-port 1645 acct-port 1646
  • Viennent ensuite les parties authentication et authorization. Authentication vérifie que les utilisateurs se connectant sont bien autorisés à se logger sur les switchs tandis que authorization contrôle les actions que les utilisateurs peuvent ou ne peuvent pas faire.

Pour cet exemple, les switchs sont configurés pour authentifier les utilisateurs à partir des serveurs RADIUS. S’il ne sont pas joignables, la base de données locale d’authentification sera utilisée.

Le mode User Exec n’est pas autorisé pour les utilisateurs RADIUS. Ils seront directement connectés avec les privilèges enable.

cisco(config)# aaa authentication login LOGIN group RadiusGroup local
cisco(config)# aaa authorization exec default group RadiusGroup none
cisco(config)# aaa authorization network default group RadiusGroup
  • L’ID de session utilisé pour l’authentication, l’authorization et l’accounting doit être le même au sein d’une même tentative de connexion.
cisco(config)# aaa session-id common

Pour terminer le paramétrage de l’authentification forte, les line vty doivent être configurés pour utiliser le nouveau mode d’authentification définit aux étapes précédentes. Sans cette étape, seule l’authentification locale sera prise en compte.

cisco(config)# line vty 0 4
cisco(config)# login authentication LOGIN

Sécurisation des accès CLI

Générer des clés RSA

Une paire de clés RSA est utilisée pour les connexions SSH.

Pour plus de sécurité, une clé de 2048 bits semble suffisante pour le moment.

cisco(config)# crypto key generate rsa
The name for the keys will be:
Choose the size of the key modulus in the range of 360 to 2048 for your
  General Purpose Keys. Choosing a key modulus greater than 2048 may take
  a few minutes.

How many bits in the modulus [2048]:
% Generating 2048 bit RSA keys ....[OK]

Activer SSH

Seul SSH v2 doit être activé pour l’administration à distance.

cisco(config)# ip ssh version 2

Limiter le nombre de sessions et le temps de connexion

Le protocole Telnet, protocole non chiffré, ne doit pas être utilisé. Seules les sessions SSH doivent être autorisées pour l’administration des switchs.

Nous autorisons ici 5 sessions line vty simultanées. Un auto-logout de session est paramétré à 10 minutes.

cisco(config)#line vty 0 4
cisco(config)# transport input ssh
cisco(config)# exec-timeout 10 0

L’accès via le port console doit également avoir une déconnexion automatique en cas d’inactivité, ici paramétrée à 5 minutes.

cisco(config)# line con 0
cisco(config)# exec-timeout 5 0

Renforcement de la sécurité

Désactiver les services inutiles

  • VLAN Trunking Protocol

VTP permet de gérer de manière centralisée les VLANS d’un réseau. Cette option doit être paramétrée en mode transparent si le VTP n’est pas utilisé dans votre LAN. En mode transparent, un switch reçoit les mises à jour de VLANS et les transmet à ses voisins sans les prendre en compte.

cisco(config)# vtp mode transparent
  • Service de source-routing

Le service de source-routing permet à l’émetteur d’un paquet IP de spécifier le chemin que doit prendre le paquet pour accéder à sa destination, indépendamment des tables de routage des routeurs traversés. Le destinataire devra utiliser le chemin inverse pour le retour. Son utilisation pourrait donc altérer la politique de routage définie par l’administrateur du réseau. Il est donc prudent de rejeter les paquets qui comportent cette option.

cisco(config)# no ip source-route
  • Résolution DNS

Si la résolution DNS n’est pas configurée sur le switch, il est recommandé de désactiver les requêtes DNS pour éviter tout « broadcasting » sur les interfaces du switch, ainsi qu’une mauvaise utilisation du service .

cisco(config)# no ip domain-lookup
  • Service IP unreachable

Il est recommandé de désactiver les réponses ICMP unreachable émises par le switch, provoquant un trafic non négligeable et permettant l’identification de l’équipement.

cisco(config)# no ip unreachable
  • Service Cisco Discovery Protocol (CDP)

Le service CDP (Cisco Discovery Protocol) est utilisé pour certaines fonctionnalités d’administration réseau. Il permet, entre autre, de déterminer la topologie d’un réseau. Mais il est dangereux de l’utiliser dans la mesure où il permet à tout système d’un segment directement joint d’apprendre qu’il s’agit d’un matériel Cisco, de déterminer le numéro du modèle et la version de l’OS utilisé. Ces informations peuvent être utiliser pour trouver les vulnérabilités du switch, et pour préparer une attaque contre le switch.

cisco(config># no cdp run
  • Service http

Le service http est utilisé pour administrer le routeur en http. Ce protocole est non sécurisé notamment pour la transmission des mots de passe en clair sur le réseau, il est donc recommandé de le désactiver.

cisco (config)# no ip http server
  • Service bootp

Le protocole BootP (Bootstrap Protocol) permet aux administrateurs réseaux de gérer la configuration d’hôtes distants depuis un serveur central de configuration. En général, BootP est utilisé par les administrateurs pour assigner des adresses IP aux stations de travail. Ce protocole fonctionnant en mode non connecté présente de nombreuses failles de sécurité.

cisco(config)# no ip bootp server
  • Service finger

Le service finger est utilisé pour découvrir quels utilisateurs sont enregistrés dans un dispositif du réseau. Il est donc recommandé de le désactiver.

cisco(config)# no service finger
  • Services small-servers

Les services « small-server » (echo, daytime…) doivent être désactivés s’ils ne sont pas utilisés.

cisco(config)# no service tcp-small-servers
cisco(config)# no service udp-small-servers

Remarque :

Les service small-servers tcp et udp sont désactivés à partir des versions d’IOS 12.1.

  • Service Packet Assembler/Dissassembler (PAD)

Ce service est utilisé dans des réseaux X.25. Il n’est pas utile de garder un tel service activé.

cisco(config)# no service pad
  • Service de log en console

Ce service activé par défaut affichera les logs sur la console. Il peut devenir gênant pendant la phase de configuration.

cisco(config)# no logging console

Activer les services de sécurité

  • Service password encryption

Le service password-encryption devra être activé. Il chiffre certains mots de passe avec un algorithme dit de type 7 à savoir l’algorithme de Vigenère, considéré comme (très) faible. Il n’a d’utilité que pour protéger visuellement certaines informations de la configuration des regards indiscrets. Il n’est pas possible de changer d’algorithme à l’heure actuelle, il s’agit d’une limitation de CISCO.

cisco(config)# service password-encryption
  • Service tcp-keepalives-in

L’activation de ce service peut réduire les effets d’une attaque DoS. Les sessions orphelines seront terminées pour ne pas consommer de ressources système.

cisco(config)# service tcp-keepalive-in
  • Service scheduler

Une fois ce service activé, les processus plantés ou bloqués seront tués.

cisco(config)# scheduler max-task-time 5000
  • Restriction des accès

TODO

  • Désactivation des interfaces non utilisées

Les interfaces qui ne sont pas utilisées doivent être configurées en shutdown.

cisco(config)# interface FastEthernet0/X
cisco(config-if)# shutdown

 

cisco(config)# interface range FastEthernet0/X-XX
cisco(config-if)# shutdown

Lien Permanent pour cet article : https://www.batard.eu/2010/11/securisation-de-switchs-cisco/

Bonjour tout le monde !

Hello world !!!

J’ai voulu faire comme tout le monde en me mettant moi aussi à bloguer.

Vous trouverez sur ce site blog des articles traitants principalement de la sécurité informatique réseau et système mais aussi d’autres articles qui me tiennent à cœur.

N’hésitez à laisser des commentaires !

Lien Permanent pour cet article : https://www.batard.eu/2010/10/bonjour-tout-le-monde-2/