---
# System prepended metadata

title: TATT2 - Cours 2
tags: [' moemoea.fierin', TATT2]

---

---
title: TATT2 - Cours 2
tags: TATT2, moemoea.fierin
---


[TOC]
# <span style="color: red">Introduction</span>
## Correction Scapy





# <span style="color: red">TCP Hijacking</span>

Introduire un seg TCP dans un co TCP existante mais necessite le numero de seq. 
Cette attaque repose sur les numéros de séquence TCP qui doivent être synchronisés, sinon les paquets sont ignorés. Si on peut sniffer le numéro de séquence actuel, l’attaque est très rapide.

conseq involontaire: ACK storm par les machines


## <span style="color: green">TCP hijacking : TCP RST Injection</span>
TCP hijacking : TCP RST Injection
injection d'unpaquet RST pour couper la co
Parfois le numero de seq est recuperable facilement (vuln).


### Exercice
Ouvrir 3 terminals et un wireshark
**Terminal 1: Client**
```
nc 127.0.0.1 4242
```

**Terminal 2: Server**
```
nc -l -p 4242
```

**WireShark:**
En loopback (local)
on ecrit en client pour avoir des elements dans wireshark
on recupere un element sur wireshark et on check dans TCP le num de seq, port dest et port source.


**Terminal 3: Hping**
```
hping3 -R -p <dest_port> -s <source_port> -M <seq_numb> <ip>
```

![](https://i.imgur.com/2jaBh9m.png)
![](https://i.imgur.com/9k6SlsN.png)


# <span style="color: red">Attaque DNS</span>
Dns utiliser pour
- email 
- Web 
- TLS 
- Domaine Windows
(on ne parlera pas de DNSsec)


ca ecoute en UDP sur le port 53, TCP port 53 (dans quel cas? quel flux?)
des qu'on depasse la taille d'un paquet udp on passe sur TCP

**Plusieurs type de serv:**
- serveur une zone
- serv racine 
- serv de cache represive: interroger d'autre serv autoritaire

Petit site qui explique comment fonctionne un DNS
https://howdns.works/

**Champ dans l'entete dns?**
**Requete** A, AAAA, MX, PTR, CNAME, NS, SOA, TXT, SRV
Champ TXT: du texte un peu ce qu'on veut ca peut etre pour des extension de certains protocole comme name: quand on envoie un mail, lemail n'est pas authentifier. Il y'a des mechanismes pour determiner qui sont les personnesqui ont le droit de lire le mail. 

Calcul du domaine le plus proche est une requete DNS aussi.

Champ Additionnel
TTL 3600
mechanisme de round robin si on fait plusieurs fois la meme requete (la repartition de charge pas cher)


## <span style="color: green">Fast FLUX</span>
**Réseau de botnet**
Comment se faire son réseau de botnet? Avoir une vulnérabilité dans un lect multimedia (VLC) et on envoie un bon vieux fichier de sous titre et la on gagne facilement notre reseau de botnet. Autre possibilité: Wireshark.

**Déroulement de l'attaque**
Réseau de botnet va resoudre toto.ttd
l'obj. c'est de rep avec un champ TXT qui répond énormement de data (65536 octet par exemple) tout ça est mis en cache dans les serv DNS. La on est pres pour attaque le serveur d'epita.fr.

On fait juste une requête DNS, qui demande le champ TXT en faisant du DNS spoofing (ip source=epita.fr) et le DNS va envoyer la reponse vers les serveurs d'epita. Et là, ce qui se passe c'est qu'on envoie les 65535 octet à Epita par requête. On fait passer ça par les relais DNS. (Il faut trouver des relais, ça peut être nos relais mais dans ce cas l'attaque coûte trop cher).

Meme problème pour tous les protocoles en UDP.

**Détails sur toto.ttd**
Imaginons on a acheter un nom de domaine.
Dans la console OVH, on peut dire que que toto.fr est un enregistrement qui pointe vers 1.2.3.4 ou un enregistrement vrs un gros bloc de données.
le toto.ttd 

## <span style="color: green">Tunnel DNS</span>
flux DNS sortant filtrés
requete TXT: encodage des donnée a sortir dans le nom de machine => exfiltration de données
reponse arbitraire dans le champ TXT => communication bid
tunnel DNS : encapsulation du contenu TCP ou du paquet IP dans un flux DNS valide.
## <span style="color: green">Autres</span>
Autres:
Je deploie un code malveillant de temps en teps elle fait des req DNs vers un nom si jamais cette req est rempli je fais ...


## <span style="color: green">DNSSEC</span>
On fait du DNS avec TLS par ce que DNSSEC c'est trop compliqué. Mais ca ne fait pas la meme chose. DNSSEC c'est la signature et DNS sur TLS fait du chiffrement.

extension récente 
le contenue est chiffre mais pas le DNS. L'objectif c'est de chiffre la requete DNS. Pour DNSSEC  vous avez par defaut la signature

## <span style="color: green">DNS Root</span>
**Qu'est ce qui sepasse si on a des attaquants qui reussise a faire tomber les serv DNS ?**

## <span style="color: green">Autres protocos de resolution de nom</span>
NBNS
LLMNR
mDNS/Bonjour
NetBios (ne sert plus a rien a part aux attaquants ^^)

Programme responder

Certains programme permet de spoofer ces réponses. Si on utilise un resp, attendre que qqn demande le Wpad si y'a pas on lui repond pas donc windows s'impatiente et demande qqchose de plus vieux => Hop la y'a reponse et on peut lui demander ses configs etc...




# <span style="color: red">DHCP</span>
Sur un LAN sur un UDP port 67 (serveurs) et 68 (clients)
DHCPOFFER est envoyer => le client va repondre a cette appel d'offre, il chosiit une offre et on envoie cette reponse en broadcast pour que tous les serv DHCP soit au courant
Chaque serv DHCP fournit une adr ip pour un certains nb d'heure, apres cela il faure refaire une requete.

DHCP ne fait pas que donner votre addr ip ca donne masque sous reseau, votre route par defaut, votre servde nom. Si jamais on l'intercepte on peut fake l'adr de routeur et se faire passer pour lui, fake l'adr DNS. S'il y'a fuite il y'a notamment le nom de notre machine qui fuite.


## <span style="color: green">DHCP spoofing</span>

repondre a la place du serveur DHCP legitime:
deuxieme serveur plus rapide (rogue DHCP).
Ip spoofing realisable pour plus de furtivite: réponse avec l'adr du serv légitime.


si on est sur le meme reseau c'est plus rapide.

## <span style="color: green">DHCP RFC2131</span>
C'est dangereux DHCP .

# <span style="color: red">Attaque sur le routage</span>
## <span style="color: green">Attaques sur les routeurs</span>
Un routeur c'est un cible de choix pour attk par ce que c'estcentral et on voit tous le trafic (yes) pour un routeur c'est imp de securise toutes les interfaces (physique et logique). Bien desactive les differents services (interface d'administration, service DHCP/DNS/NTP, firewall dans les switchs). Derrière l'interface d'admin on a aussi plein d'autre service (Telnet, SSH, ..) qui sont active par defaut sur un routeur.

Pourquoi est-ce qu'on veut un minimum de services, quelles sont les diff attk sur ces protocoles:
SSH: pas d'authent sur certificat donc on peut forcer login:mdp
HTTPS: le gars qui a dev l'interface https et y'a une injection SQL qui peut etre faite.

L'objectif reduire au max la surface d'attaque d'un routeur.

On essaye d'eviter l'HTTPS si on peut faire passer le gars en SSH (attention certaines personnes ne savent que faire les bails sur HTTPS et n'ont aucune connaissance sur SSH)

SSH au moins  la premiere fois qy'on se connecte il y'aura enregistrement de la cle serveurs.

Possibilite de mettre des ACL : parfeu basique. 
On peut tres bien prendre un routeur et avoir notre routeur et parfeu en meme temps. Ce sera plus facilement administrable.

# <span style="color: red">Attaque sur le routage</span>
## <span style="color: green">Attaques sur les protocoles de routages</span>
RIP: y'a pas de sécurité par défaut
OSPF
BGP => full commercial (cf Free + YT super lent)


# <span style="color: red">Introduction Parefeu</span>
Interet: laisser que les service sutilies accessible et effectuer un controle d'acces.

ca permet de filtrer le traffic entre deux zones. Si on est sur le meme reseau on passe pas par le parfeu sauf le parefeu local.
Par defaut sur un linux il est la mais il laisse tout passer.
Si parefeu qui bloque tout par defaut le jour ou j'ai une vuln ou un truc qui devient public et bien c'est moins grave par ce qu'on ne peut pas y acceder.

Avant on n'avait pas le NAT qui protegeait mais on avait directement une addr ip public.

Type de parefeu: 2 gros types
- parefeu avec etat
- parefeu sans etat

On peut avoir du filtrage avec couche inferieur
Comme on l'a dit avant, Un routeur ca peut faire du parefeu avec des ACL, un parefeu par defaut ca fait routeur.

Marche de la securite: tres nombreuse offre de produit de parefeu (storm Shield) derriere c'est un linux/un openBSD dans lequel on a rajouter des bails (ca coute tres cher et c'est pas tres interessant)


## <span style="color: green">Limites</span>
**Ce qui n'est pas empeché:**
- attaque sur port autorise (Dos ou vuln applicatives): SI on laisse passer le traffic sur un flux, ca ne va pas regarder ce qu'il y'a dans ce flux. Le mieux cest de corriger l'appli pour la mettre a jour. On peut mettre un WAF par dessus si c'est pas notre appli
- attaques sur le trafi non filtre
- les attaques sur le parefeu, un parefeu non maj, il y'a potentiellement des vuln a exploités
- mauvaise config
- IP spoofing suaucun authentificatuon de l'utilisateur.
- appliance et realite caché: ils vendent le parefeu cher mais mettent des regles implicite qui sont l'interface admin est tjrs accessible (a notre inssue le parefeu fait ca meme si on fait drop all).

**Combien y'a de regles dans un parefeu d'entreprise classique:**
- plusieurs centaine voir des milliers de règles
- on peut tres rapidement avoir une mauvaise config de parefeu

Diff parefeu linux:
- cout de la maintenance et le support
- Homologation

## <span style="color: green">Bonnes pratiques des parefeu</span>
- Je bloque tout par defaut
- N'activer aucun services sur le parefeu
- Filtrer tout sle traficc entrant du reseau (aucun moyen de contournement du parefeu: WIFI, VPN, modem): Ca peut etre l'endroit ou on fait passer notre VPN dessus
- filtrer tout le trafic sortant
- proteger les sous reseaux internes avec un autre parefeu que celui utilise en peripherique (marque diff)
- realiser des audits de regles
- analyser les journaux 

## <span style="color: green">Problèmes potentiels</span>
- ports sources fixes => pas de NAT
- addr et ports dans le paquet: des protocoles dans lequel on a des adr ip et des port a l'interieur du paquet et en fonction du paquet on e co a d'autre port (?)
- port dynamique (FTP, SIP, RPC) inspection applicative necessaire pour oubrir les bons flux: comment on fait pour regler la securite FTP sur parefeu: FTPs SFTP (acceder a des donnees en passant par le protocole SSH).
- placement de parefeu et asymetrie des flux  (VoIP)
- Le parefeu doit etre capable de lire le contenue du message et savoir s'il doit l'autoriser ou pas. 
- ptout passe par le port 80 en sortie de nos jours. 
- Le filtrage en sortie cest couteux et la justification est faible dans le sens ou de tout facon l'attk utilisera le flux libre (ouvert).

## <span style="color: green">Regles netasq</span>
C'est graphique ca plait au commercial
Il y'a des regles implicites (regulierement source de probleme): il y'a une diff entre ce qu'il y'a d'afficher et ce qui est faisable.


# <span style="color: red">DMZ</span>
## <span style="color: green">Introduction</span>
DMZ = Zone demilitarisé
Est ce qu'une DMz cest une zone ou est penard?  Pas vraiment ca n'a rien a voir avec une DMZ militaire.

**Buts:**
- c'est comme un SAS: ca peut etre la separation de serveurs public web. Objectif: isole du reste en cas de compromisions.

Toujours des flux entrants. Eviter le max de flux sortants.

Autre buts: isoler des zones de sensibilisation diff. Une DMZ c'est simplement un sous-réseau pas forcement qqchose qui peut nous proteger.

On va voir differente topologies.(Besoin secu et cout)

## <span style="color: green">DMZ cas 1</span>
Internet -> routeur -> parefeu -> LAN
routeur -> DMZ

On protege le LAN mais pas la DMZ
![](https://i.imgur.com/OdVWIdt.png)

## <span style="color: green">DMZ cas 2</span>
Internet ->  parefeu -> SI interne
parefeu -> DMZ

un seul pare-feu: s'il tombe le parefeu de la DMZ et du SI interne tombe.
**Plusieurs regles de parefeu:**
- un set de regles d'internet vers la DMZ
- un set de regles de la DMZ vers le SI interne
- Si on se trompe on peut arriver a faire un lien internet entre l'exterieur et le SI interne.
![](https://i.imgur.com/7rpJMBk.png)

## <span style="color: green">DMZ cas 2 bis</span>
**Avantages:**
- On peut faire la revue des regles bcp plus simplement.
- On peut avoir deux parefeu differents evite les problemes en cas de vuln. Mais le probleme: les admin doivent maitrise les types de parefeu et c'est pas si evident d'etre competent sur une marque particulière.
![](https://i.imgur.com/nqWrjCg.png)

## <span style="color: green">DMZ cas 3</span>
Rupture protocolaire: on veut que tous les flux qui proviennent d'internet on les force a faire une analyse dans une autre couche OSI.

![](https://i.imgur.com/p25LG7A.png)


:::info
Remarque: (m'ai trompé, j'ai pris les images de 'plusieurs DMZ' au lieu des premiers cas)
les images ne correspondent pas tout a fait au texte (decalage)
:::



## <span style="color: green">Flux</span>
Au niveau des règles de filtrage de la **DMZ**, elles peuvent être très simples ou complexes selon l’architecture. En général on n’autorise **que le trafic vers les ports ouverts des serveurs de la DMZ et rien d’autre**. Laisser un port fermé non filtré peut permettre à un attaquant d’établir un canal de communication après une compromission (un bindshell écoutant sur le port autorisé) et améliore la précision d’une prise d’empreinte à distance (le programme nmap a besoin d’un port ouvert et d’un port fermé pour donner une réponse pertinente).



# <span style="color: red">Parefeu Libre</span>
## <span style="color: green">Iptables</span>
**Tables:**
- filter: filtrage des paquets:
    - input
    - output
    - forward
- nat: modification d'adr et de port
    - prerouting (modifier d'adr/port dest)
    - output
    - postrouting: modification d'adr/port src
- mangle: alteration des paquets

**Cibles:**
- accept
- drop/reject
- log/ulog

**Différence drop et reject:**
- drop paquet ignorer et on met aucune reponse
- reject je repond (par ex: non le serv est non joignable)
- plus agréable au niveau utilisateur d'avoir un reject mais alors quel interet de drop?

**Quel interet des DROP:**
- répondre ça donne des infos sur le système
- répondre consomme des resources sur le sys
- on donne de l'information dans tous les cas mais on en donne plus quand on répond

**Les règles**
- par defaut (-P)
- ajout (-A)
- insertion en tete (-I)
- suppression (-D)
- listage (-L)
- ...

**iptables**
Pour lister les regles iptables, il faut faire pour avoir les regles exactes: *iptables -vnL*. Car iptables en faisant simplement *-L* ne va pas expliciter.

"Related": dans le cas de FTP ou y'a deux ports, tous les protocols qui utilisent plusieurs ports.

Chacun de nos scripts iptables devraient commencer par ces lignes:
drop tout avant d'ecrire 


parefeu avec etat on autorise le flux a revenir
parefeu sans etat il faut deux regles differentes.



## <span style="color: green">Proxy</span>
Protection des postes de travail vis a vis des serveurs sur internet:
- relais Web
- relais SMTP
- relais DNS

Configuration explicite des clients et architecture reseau (filtrage) imposant le passage par un relais.

Si on a un poste client windows, il y'a un proxy système.
linux: variable d'environnement qui fait a peut pres la même chose.

Reverse proxy: protection des serveurs vis a vis des attaquant sur internet.
C'est de la lsite noir (donc pas ideal point de vue secu). 
- relai inverse Web appeles egalement WAD (Web application firewall)
- relais inverse SMTP entrant ayant les roles antispam et antivirus

## <span style="color: green">Journaliser</span>
On ne peut pas tout journaliser c'est illusoire donc il faut choisir.
Quelle est le type d'information que j'iamerais journaliser? durée de connection
solution: netflow => analyseur qui permettent de requeter tout ce qui a ete journaliser. L'un des gros probleme de netflow = UDP. Parfois il peut y avoir des trous enorme dans les logs.

Si vous avez un petit SI a sécurisé, netflow c'est une bonne idée. Ca permet de faire connaitre l'heure le jour, ...

**journalisation des flux autorisées**
journalisation des flux refuses: pare-feu
...

**Questions**
comment faire une archi pour une parselle web?

# <span style="color: red">Les différents moyens d'authentification</span>
type d'authentification:
- synchrone: login et mdp dans le meme paquet (SNMP)
- asynchrone (defi/rep)

Stockage du mdp sur le serveur!
- en clair: problème du stockage des mdp en clair => en cas de compromision du serveur, l'attk a acces directement aux mdp en clair (ca arrive en clair)
- haché (avec ou sans sel)

note: sel == precalculs generals


# <span style="color: red">Accès reseau</span>
## <span style="color: green">Connexion distante</span>
Authentification pour acces reseau (modem, site distant)
PAP en clair, historique
CHAP, defi , reponse historique
VPN TLS certificat
VPN IPseq

**les services courants: les classique**
FTP:
- USER toto
- PASS titi
POP3, APOP, 
- USER toto
- PASS titi
- USER toto
- APOP MD5(timstamp || password)
SNMP, communaute par defaut: protocole d'administration reseau
- public : acces en lecture
- private: acces en lecture et en ecriture
note: communaute == mot de passe

**service courant HTTP**
HTTP Basic: comment transite le mdp dans ce type de session (basic)=> en base64
=> base64(Login, mdp)
HTTP Digest: nouvelle methode qui a ete invente qui repose sur ??

est ce qu'auj utiliser http basic est recommandé ?  technique si on est en https tout est chiffre donc ça passe. 


**service courant mysql**
ce qu'on attak va chercher c'est les compte pas defaut. par defaut sur mysql on a "root:rien"
localisation des mdpo: mysql.user
forme des mdp:
- hachage maison jusque la version 5
- double SHA1 depuis 


note: pbkdf2 pour faire un double sha1 avec sel (mille fois plus lent)


**service Oracle**
Oracle cest complexe
les mdp sont stocket dans table DBA_users
# <span style="color: red">Messages electronique</span>
**risques lie a la msgerie**
problème potentiel ?
- reception ou envoi de virus
- relais manuel de mssg exterieur
- atteinte a la confidentialité des messages 
- perte de message
- absence de gestion de la non repudiation
- indisponibilite du serv de msg
- rebond sur le serv de messagerie pour une attk
- configuration en relai ouvert du serv


**protocol**
quand on envoie un mail notre client mail (thunderbird en local par ex)
MUA va se co au serveur de messagerie (MSA) et va dire voila le mail. Le MSA va passer de MTA a MTA  pour arriver jusqu'au mail destination agent

Si on veut mettre en place SMTPS par exemple sur le schema donnée ici. rien ne garantie qu'on aura du SMTPS dans les reseaux qui ne nous appartiennent pas c'est donc pas suffisant pour garantir le chiffrement de nos mails. On peut par exemple utiliser PGP pour garantir la securité.

**Fabrication de mail Spoofing SMTP**
HELO machin
MAIL FROM expediteur
RCPT TO: dst
DATA:
QUIT

```
dig srs.epita.fr 
```

![](https://i.imgur.com/CKDlZlU.png)


Enumeration des utilisateurs:
EXPN
VRFY
RCPT TO

**erreurs courantes**
- banniere trop explicite: le fait de cacher la bannière c'est bien/mieux/pas bien ? eh bah ca ralenti un attaquant mais ca ne va pas plus nous proteger
- accumulation de programmes: plus on installe plus il faut mettre a jours pour eviter de se faire niquer sur une vuln.
- relais ouvert: difficile de s'en proteger
- absence d'authen des emerteurs interne
- absence de chioffrement appicatif de nase acces aux mail sur le serveur (utilsier mime)