Présentation PowerPoint - SéQCure · Scénario –Réponse à un incident de sécurité :...

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)