Embed Size (px)
Citation preview
https://nvlpubs.nist.gov/nistpubs/specialpublications/nist.sp.800-161.pdf
CEH (5 phases présentées en 4!!!)
Netcraft : affiche version du serveur web, applications, etc.
Shodan : ports ouverts …..
Scénario – Réponse à un incident de sécurité :
Réception d’un courriel d’hameçonnage
Contient des données : IP, mail server, lien URL, le fichier joint malveillant, etc.
Comment OSINT sera déclenché ?
Collecte d’information sur le web (adresses IP, DNS, noms de domaine, mail
serveur, IOC)
Collecte d’informations si IP malveillante, blacklist, reliées à d’autres attaques?
Avec outils spécialisés : surveiller enregistrements nouveaux domaines par les
propriétaires des noms de domaine malveillants, etc.
http://www.isaca.org/cyber/cyber-security-articles/Pages/looking-back-to-look-
forward-osint-based-adversary-analysis.aspx?utm_referrer=
Pour cette section, on présente certaines configurations qui permettent
directement de contrer les activités de reconnaissance…
Attention !! Le but n’est pas de faire de l’endurcissement (Hardening) ici !! C’est
simplement quelques petits changements aux configurations par défaut qui,
on le pense sont très payant car ils permettent de venir compliquer la vie des
hackers et leur utilisation d’outils de plus en plus automatisés, mais qui
nécessite
d’obtenir une information précise pour être efficace.
Nous ne verrons pas toutes les recommandations mais certaines!
Autres commandes :
wget -q -S IP
telnet IP 80
User-agent: The specific web crawler to which you’re giving crawl instructions
(usually a search engine). Voir : http://www.robotstxt.org/db.html
Disallow: The command used to tell a user-agent not to crawl particular URL.
Only one "Disallow:" line is allowed for each URL.
Allow (Only applicable for Googlebot): The command to tell Googlebot it can
access a page or subfolder even though its parent page or subfolder may be
disallowed.
https://moz.com/learn/seo/robotstxt
http://www.robotstxt.org/robotstxt.html
La sécurité offensive!!!!!
footprinting (recon+énumération de bannière) = rechercher/trouver de
l'information
scanning (balayages) = inspecter les murs, les portes et les fenêtres pour
trouver des failles pour pouvoir entrer plus tard
(exploitation = illégal au Canada 342.3 Code Criminel canadien)
https://laws-lois.justice.gc.ca/fra/lois/C-46/page-75.html?txthl=342#s-342
https://www.youtube.com/watch?v=DkOx_jO8R7s
https://nmap.org/nsedoc/index.html
/etc/proxychains.conf
Ajouter des IP Proxy web + port
Lancement du scan :
proxychains nmap -sS <IP address>
nmap -v --spoof-mac fausseMAC IP
nmap -v -sT -PN --spoof-mac 0 IP
nmap -v -S IPorigine Ipdestination
nmap -v -n -Ddecoy.IP1,decoyIP2…
nmap –v -D RND:5 IP = risque de SYN flooding la cible
nmap -v -f IP
nmap -v -sS -f --mtu 32 -T5 IP_victime
nmap -sS -T4 -A -f IP
nmap -mtu 8 IP (8 bytes le paquet)
nmap -v --scan_delay 11s IP
Un WAF n’offre pas en soit une protection complète pour sécuriser un serveur
web mais il a tout à fait sa place dans une stratégie de défense en
profondeur.
ModSecurity, par sa flexibilité, sa communauté et son intégration, est un WAF
Open Source très intéressant !
Phase 1 = Entête de la requête
• Le serveur Web vient de lire l’entête de la requête.
• Il n’a pas encore lu le contenu (body) de la requête.
• Il ne connaît pas encore les arguments contenus dans la requête.
• Toute règle s’exécutant en phase 1 intervient avant que le serveur soit en
mesure de faire quelque chose.
Exemples de règles en phase 1:
• décider si le corps de la requête doit être traité plus en détail.
• définir comment le corps doit être traité (en XML ?)
Phase 2 : corps de la requête
• Nous disposons désormais des arguments de la requête.
• Les règles de filtrage ou de rejets liées à des applications doivent intervenir à
ce niveau .
Phase 3 : entête de la réponse
• Cette phase intervient juste avant que les entêtes des réponses parviennent
au client.
• Les règles de filtrage permettent de définir ce qu’il doit advenir de la « future »
réponse.
• On décide si l’on veut analyser le contenu/corps de la réponse ou la bloquer.
• A ce niveau, nous ne savons pas encore ce que le serveur va retourner…
Phase 4 : corps de la réponse
A ce niveau, ModSecurity analyse les informations renvoyées à destination du
client.
• Le contenu HTML est analysé pour détecter :
• des fuites d’informations.
• des messages d’erreurs.
• des traces d’authentifications ayant échouées.
• etc.
Phase 5 : journalisation
• Les règles déclarées à ce niveau interviennent seulement sur la manière dont
la journalisation doit s’opérer.
• Cette phase peut être utilisée pour analyser les messages d’erreur enregistrés
par Le serveur Web.
• Elle permet également d’inspecter des entêtes de réponse qui n’étaient pas
accessibles en phases 3 et 4.
• Il est trop tard pour interdire ou bloquer des connexions
Open Web Application Security Project (OWASP)
