Massive Attack : an overview on advanced DDoS mitigation
Cet article extrait de [ http://www.minithins.net/warehouse/DDoS.txt ] offre un aper?u – un instantan? m?me – des m?thodes les plus
avanc?es, en cours de d?ploiement, d’exp?rimentation ou de d?veloppement,
permettant de lutter contre les Distributed Denial of Service et m?me, parfois,
d’identifier leurs auteurs. Ces techniques agissant soit directement sur le
chemin, soit sur le management de queues, elles s’appliquent de facto ?
l’infrastructure r?seau et en particulier aux routeurs, constituant le coeur du
net, son squelette. Ce document se focalise sur le mat?riel Cisco mais abordera
?ventuellement d’autres syst?mes, libres (*BSD, Linux, Zebra) ou propri?taires
(Juniper). Il est admis que vous connaissez au moins basiquement ces syst?mes
et que vous poss?dez une bonne compr?hension du mod?le TCP/IP et des
disciplines d’?vitement de congestion des impl?mentations TCP (New)Reno. La
s?curisation compl?te d’infrastructure Cisco (pas uniquement contre les DoS)
est par ailleurs r?sum?e dans une pr?sentation en [FIS02].
> DocBook translation (then make a big chunky html)
"Semper ego auditor tantum ? Nunquamne reponam ?"
Thomas de Quincey, De l'Assassinat consid?r? comme un des Beaux-Arts
1. Rappels
Tout d'abord, quelques rapides rappels sur ce que sont les DoS et leurs
diff?rents types, qui ne cessent d'augmenter et de s'?toffer de jour en jour
[CHAR]. Un Denial of Service ou DoS est une attaque destin?e ? limiter ou
emp?cher le bon fonctionnement, la disponibilit? d'une machine. Les DoS
agissent la plupart du temps par Ressource Starvation, c'est-?-dire qu'ils
consomment un maximum de ressources (CPU, RAM...) de la machine attaqu?e afin
de la rendre inop?rante. Avec assez de ressources du c?t? attaquant, n'importe
quelle machine est susceptible d'?tre victime d'un DoS par 'ressource
starvation'. Mais il existe plusieurs m?thodes permettant de faire beaucoup de
d?g?ts avec peu de ressources.
En premier lieu desquelles, et sans doute par ordre de c?l?brit?, on trouve les
smurfs. Les smurfs agissent ? partir du protocole ICMP et des adresses IP
broadcast. L'attaquant envoie un paquet ICMP echo request ? une ou m?me
plusieurs adresses broadcast (de pr?f?rence appartenant ? des r?seaux de
classes B voire A) en usurpant l'adresse de l'h?te cible, ainsi les echo reply
de la totalit? des h?tes se trouvant derri?re l'adresse broadcast (jusqu'?
65535 machines pour une classe B) r?pondront ? la machine cible tous en m?me
temps entra?nant la situation de DoS. Le r?seau de l'adresse broadcast agit ici
comme r?flecteur pour le DoS.
Une autre m?thode tr?s r?pandue est le SYN flood. Elle exploite TCP en cr?ant
un nombre important de connexions semi-ouvertes dans un intervalles de temps
restreint. Chaque segment TCP avec le flag SYN d?clenche chez l'h?te cible la
cr?ation d'un espace m?moire commun?ment appel?e TCP Control Block (TCB)
contenant les informations relatives ? la connexion. Une fois le SYN re?u,
l'h?te renvoie un SYN/ACK puis attendant de recevoir un ACK afin de compl?ter
le processus d'initialisation. Cependant, les segments du SYN flood auront ?t?
spoof? de sorte que l'h?te cible ne re?oive jamais de ACK en r?ponse et reste
en ?tat SYN-RECEIVED. La succession rapide de cr?ation de TCB remplissant les
queues de connexions en ?tat incomplet finit par consommer assez de m?moire
pour ralentir ou stopper l'h?te cible.
Une variation r?cente de cette attaque, appel?e Naptha [NAP00], a ?t? d?voil?.
Le principe reste le m?me, ? savoir la consommation des ressources m?moire par
la cr?ation rapide d'un grand nombre de TCB. Mais afin de contourner les
nombreuses parades qui ont ?t? mise en place contre les SYN floods, le naptha
tente d'initialiser compl?tement une connexion puis de laisser l'h?te cible en
?tat ESTABLISHED apr?s avoir envoy? un unique ACK apr?s le SYN/ACK, ou en ?tat
CLOSE-WAIT apr?s lui avoir un ACK suivi d'un FIN initialisant le four-way
handshake de d?connexion. Pour ?viter de consommer un TCB de son c?t?,
l'attaquant doit ici r?aliser une connexion en TCP blind spoofing. Ce dernier
d?tail rend l'attaque bien plus complexe puisqu'elle n?cessite la pr?diction
de Sequence Number TCP g?n?r?s par des Pseudo Random Number Generator (PRNG).
Cependant de r?cents travaux [ZAL01] sur l'utilisation des attracteurs ?tranges
pour l'identification de patterns de g?n?ration pourrait faciliter la mise en
application des napthas.
Mais une condition de DoS peut aussi appara?tre avec un faible nombre de
paquets par exemple ? cause d'une erreur dans une application. Ce cas de figure
s'est par exemple pr?sent? d?but 2002 dans BlackICE Defender, outil de s?curit?
r?seau propri?taire. En interceptant un paquet ICMP similaire ? un Ping of
Death - c'est-?-dire l?gitime mais fragment? et forg? de mani?re ? ?tre hors
limite une fois r?assembl? par le destinataire, causant crash ou ralentissement
- crashait ? son tour, entra?nant parfois son h?te ? sa suite. La faille, qui
s'est finalement av?r?e ?tre un buffer overflow, ?tait ici due ? un bug de
gestion du trafic en sortie du driver propri?taire utilis? par BlackICE pour
l'interception des paquets sous Windows 2000 et Windows XP. De m?me il y a
quelques ann?es existait le small footprint DoS, contre TCPdump et ses d?riv?s,
consistant en un unique paquet avec les champs IP Version et IP Total Length
mis ? 0. Ces cas sont doublement dangereux puisqu'ils repr?sentent des DoS
applicatifs n?cessitant une signature mais attaquent en plus les applications
utilisant ces signatures. Ces types de vuln?rabilit?s peuvent ?tre sp?cifiques
? un syst?me, un logiciel, ou m?me une configuration particuli?re de plusieurs
d'entre eux. Plus simple mais tout aussi destructeur, une attaque, semblable
aux SYN flood que nous avons vus, peut ?tre cibl? contre une machine ou un
service critique dont la d?gradation des performances entra?nera un effet de
bord assimilable ? un DoS. C'est par exemple ce qu'? soulign? un r?cent draft
IETF sur la s?curit? du protocole BGPv4 [MUR03].
Toutes ces m?thodes peuvent ais?ment ?tre combin?es. Une dizaine d'ann?e de
cela, les ISP ont remarqu? le d?veloppement inqui?tant du ph?nom?ne de 'route
flap'. Ce terme d?signe le retrait et l'annonce successive et r?p?t?e de routes
sur une courte ?chelle de temps. Chaque flap pousse le routeur ? mettre ? jour
sa table de routage, causant une surcharge non n?glib?able. D'autre part, les
d?lais de convergence des routes au niveau global donnent aux flaps un impact
important sur la stabilit? du routage. En r?ponse, les organisations li?es au
routage ont rapidement d?ploy?e une proposition de Curtis Villamizar, r?sum?e
ensuite dans la RFC 2439 [2439], nomm?e route flap damping. Cette technique
consiste ? surveiller les retraits et r?annonces, en ajoutant une p?nalit? ?
une route ? chaque retraiit. Lorsqu'on d?passe une certaine valeur de p?nalit?,
c'est-?-dire qu'on observer un nombre de flap ?lev? sur une courte p?riode, la
route n'est plus utilis?e ni annonc?e pour une dur?e pr?d?termin?e partant du
dernier flap ; chaque flap red?clenchant le timer en augmentant le compteur de
p?nalit?. En effet, ce compteur diminue en fonction du temps, tant qu'on
observe plus aucun nouveau flap. Lorsqu'il repasse au-dessus d'un seuil de
r?utilisation, la route retrouve sa place dans les tables de routage. Le
probl?me vient alors du fait qu'un attaquant peut tr?s bien forcer une route ?
"flapper" pour subir des p?nalit?s et donc dispara?tre d'Internet. Une vaste
attaque coordonn?e peut m?me compl?tement couper un r?seau des autres. Il
suffit de lancer un flood sur le routeur, en particulier sur le port 179/tcp
habituellement utilis? pour les sessions BGP. Le manque de ressources
provoquera ?ventuellement des timeouts voire un reboot du routeur. Cette
interruption des sessions, si r?p?t?e, sera rapidement assimil?e ? du flapping,
et donc p?nalis?e. Le RIPE a publi? un document tr?s complet sur la bonne
utilisation du damping [RIPE01] encourageant notamment l'utilisation des
messages BGP du type REFRESH et des ?quivalents ? la 'soft-configuration' de
Cisco. Ces deux techniques permettent en effet de modifier une politique BGP
sans n?cessiter une r?initialisation de la session, assimil?e ?ventuellement ?
du flapping. De m?me, le "proggressive damping" incite ? p?naliser plus
fortement les prefixes courts puisque les prefixes longs sont plus stables et
leur suppression causerait, selon toute vraisemblance, plus de d?sagr?ments
pour les utilisateurs. Cela revient concr?tement ? encourager fortement
l'agr?gation des routes. Enfin, les serveurs racines DNS sont prot?g?s et
list?s comme 'Golden Networks'. Malgr? tout, ce type d'attaques combin?es,
entra?nant un DoS en cascade, demeure r?alisable pour qui dispose de
connaissances et d'une organisation rigoureuse.
La derni?re classe de DoS que nous aborderons n'est pas r?ellement une m?thode
en soit mais plut?t un raffinement. Il s'agit de faire partir l'attaque non
plus d'un unique h?te attaquant, mais d'une multitude de serveurs esclaves
contr?l?s par un client ma?tre, potentiellement via plusieurs proxies. C'est
ainsi que fonctionnent les outils Trinoo, Tribal Flood Network 2000 (TFN2k) et
Stacheldaht dont vous pourrez trouver des analyses individuelles d?taill?es sur
le site de Dave Dittrich [DITT]. Stacheldaht s'est rendu c?l?bre d?but 2001
lors des impressionnantes mais triviales attaques contre Yahoo!, CNN, eBay et
bien d'autres. Ces outils agissent habituellement par une g?n?ration simple
d'un grand nombre d'ICMP echo reply ou d'UDP echo sans grande finesse. Mais
n'importe laquelle des attaques d?j? d?crites peut ?tre appliqu?e ? cette
architecture distribu?e, ? laquelle on a attribu? la d?nomination DDoS pour
Distributed Denial of Service. Ils n?cessitent de plus le contr?le d'un nombre
important de machines ce qui pousse leurs utilisateurs ? l'intrusion massive,
quasiment industrielle, allant jusqu'? exploiter des worms, comme ce fut le cas
de Code Red II en 2001 dont chaque instance ciblait le site de la Maison
Blanche.
Outre les DoS massifs ou non, protocolaires ou applicatifs, il faut ?galement
remarquer une autre source involontaire mais n?anmoins d?vastatrice : les
worms. Depuis 1988 et l'Internet Worm de Robert Morris, ces applications
automatiques se propageant sur les r?seaux au gr? des vuln?rabilit?s ont
?norm?ment ?volu?s [PAX+02]. Ainsi les nouvelles concernant l'apparition de
nouveaux worms se sont multipli?s ces derni?res ann?es, et des noms comme Code
Red et Nimda entre juillet et septembre 2001, ou Sapphire d?but 2003, sont
d?sormais c?l?bres. L'analyse de ce dernier [WEA+03], a permis d'?tablir une
classification entre Sapphire, restraint par la bande passante, et Code Red et
Nimda de l'autre c?t?, limit?s par la latence. En effet, Sapphire, exploitant
une faille SQL Microsoft, ne n?cessitait qu'un unique paquet UDP de 404 octets,
permettant une propagation rapide et aveugle. Le vers a ainsi pu contamin? 90%
des h?tes vuln?rables en 10 minutes, utilisant dans ce laps de temps
?norm?ment de bande passante :
"[Sapphire] caused considerable harm simply by overloading networks and
taking database servers out of operation. Many individual sites lost
connectivity as their access bandwidth was saturated by local copies of
the worm and there were several reports of Internet backbone disruption"
[WEA+03]
A l'oppos?, Code Red et Nimda utilisaient des transmissions TCP et se
trouvaient limit?s par la dur?e de synchronisation, impos?e par le protocole
via le three-way handshake, et les proc?dures d'acquittement. La vitesse de
propagation ?taient donc fonction des d?lais dans les r?seaux. La quantit? de
mise en tampon - Code Red faisant 4ko et Nimda 60ko - a n?cessairement d?grad?
ces d?lais et la fiabilit? des transmissions. Malgr? cela, une meilleure
utilisation du multithreading aurait pu rendre ces vers tout aussi
d?vastateurs, du point de vue des DoS, que Sapphire, comme l'ont montr? Paxson
& al. en [WEA+03]. Plus particuli?rement, Code Red I, attaquant les serveurs
Microsoft IIS, se propageait par l'interm?diaire de 99 threads concurrents avec
en plus un bug qui poussait un thread particulier ? scanner la m?me s?quence
d'adresses IP, cr?ant potentiellement des situations de DoS vers ces adresses.
Nimda quant ? lui utilisait jusqu'? 5 vecteurs de propagation, du web au mail
en passant par les partitions partag?s, multipliant d'autant l'apparition de
conditions de DoS pendant son expansion.
Comme vous le voyez, le risque est omnipr?sent et n?cessite donc une large
protection. Notez cependant que les technologies pr?sent?es dans cet article ne
concernent en aucun cas les attaques applicatives, du fait de leur sp?cifit?.
Les seules protections r?sideraient alors en un processus complexe d'audit
permettant de d?gager des signatures uniques. Celles-ci pourraient ensuite ?tre
?ventuellement utilis?es par un IDS pour d?tecter ces attaques, et parfois m?me
les arr?ter. Bien que le principe de contre-mesures soit encore bien peu
d?velopp? dans le domaine de la s?curit?, vous pouvez d?j? trouver quelques
exemples d'application dans les IDS Prelude et les d?veloppements de Snort tels
Guardian, Hogwash ou encore FlexResp (ou m?me, dans une certaine mesure, Cisco
Firewall IDS et NBAR, ?tudi?s dans cet article). Cette cat?gorie d'outils
int?gr?s ?tant d?sormais nomm?s Intrusion Prevention System. Nous nous
int?resserons ici principalement aux technologies capables de d?tecter,
pr?venir ou identifier un DDoS. Elles doivent alors pouvoir s'appliquer ? un
r?seau entier ? travers le mat?riel en formant l'architecture. C'est ? cause de
cette optique g?n?raliste que les technologies ?tudi?es suivront le plus
souvent un mod?le anomaly-based et se baseront sur les statistiques.
Les deux orientations que nous avons suivies pour notre ?tude sont
l'identification et le contr?le des DDoS en fonction de leur chemin
(path-oriented) ou en fonction de l'utilisation des ressources
(exhaustion-oriented). La premi?re partie accueille ?galement les descriptions
de plusieurs sch?mas d'identification de la source. Ce n'est pas seulement un
?l?ment utile lors de la phase de forensic mais ?galement, devant le manque
criant de mesures automatiques dans la lutte contre les DDoS, une source
d'information essentielle ? obtenir le plus rapidement afin d'appliquer des
mesures r?actives au plus pr?s de la source. La seconde approche s'est quant ?
elle vu r?cemment confirm?e dans un article ?voquant la limitation des DoS par
une surveillance stricte du Quality of Service (QoS) [RED+02].
2. Path-oriented
Les DoS ont toujours une source, qu'elle soit directe ou indirecte. Une
solution ?vidente pour arr?ter un DoS est tout simplement de bloquer les
paquets vecteurs de condition de DoS. Cependant, lorsqu'on s'int?resse plus
particuli?rement aux DDoS, non applicatifs le plus souvent, les sources se
multiplient et se falsifient plus ais?ment. Il d?vient alors des plus ardus
d'en identifier la source afin de constituer un agr?gat capable de servir au
pistage, dit traceback, ou au simple blocage.
D'autre part, le protocole BGP, utilis? pour l'annonce de routes entre
routeurs, offre certaines possibilit?s de configuration dangereuse, telles
l'annonce de routes vers des adresses priv?es ou non allou?es ainsi que, plus
g?n?ralement, l'annonce de prefixes n'appartenant pas au r?seau annonceur. Ces
erreurs, intentionelles ou non, peuvent alors renforcer un DDoS en suscitant
d'importantes quantit?s de messages ICMP host unreachable, ?ventuellement en
supprimant toute possibilit? de communication avec les prefixes ill?galement
annonc?s.
Dans cette premi?re partie, nous allons donc nous int?resser en particulier aux
proc?d?s touchant ? la caract?risation et au cheminement du paquet dans le
r?seau. Plus concr?tement, cela indique une ?tude pouss?e des m?canismes li?s
au filtrage, blocage ou comptabilit? du trafic.
2.1. ACL
ACL, pour Access Control List, est le terme d?signant les r?gles de filtrage
sur les syst?mes Cisco. Plus g?n?ralement, nous aborderons les techniques
logicielles permettant, ? un routeur ou un firewall, de filtrer le trafic selon
agr?gat. Les principales DDoS ne poss?dant pas de signature particuli?re ou
bien facilement modifiable, la d?tection par pattern matching comme dans les
IDS s'av?re inop?rante. Le filtrage dynamique brut contre un attaquant s'av?re
?galement peu utile puisque la bande passante en amont s'av?re toujours
utilis?e. Ce point force d'ailleurs les responsables d'une infrastructure
r?seau ? placer les protections le plus proche possible de l'attaquant, donc
g?n?ralement au niveau des border routers. Mais la principale opposition au
filtrage dynamique est tout simplement l'utilisation syst?matique du spoofing
dans ces techniques. Pour limiter cela, quelques r?gles simples peuvent ?tre
appliqu?es.
D'abord pour ?viter que notre r?seau ne serve de r?flecteur pour un smurf, nous
avons la possibilit? chez Cisco d'interdire les r?ponses ? un broadcast issue
d'une adresse unicast. Notez que cette configuration est celle par d?faut
depuis IOS 12.0.
router(config)#interface e0
router(config-if)#no ip directed-broadcast
Nous allons ensuite filtrer plusieurs blocs d'adresses que nous savons
attribu?es ? des r?seaux priv?s non routables sur Internet, ou bien
r?serv?es ? des usages exp?rimentaux. Cette politique de filtrage ingress est
r?sum?e parfaitement dans la RFC 2267 [1812][2267]. Plusieurs de ces adresses
sont indiqu?es dans la RFC 1918 accompagn?es de leur politique de routage comme
ci-dessous
"Because private addresses have no global meaning, routing information
about private networks shall not be propagated on inter-enterprise
links, and packets with private source or destination addresses
should not be forwarded across such links. Routers in networks not
using private address space, especially those of Internet service
providers, are expected to be configured to reject (filter out)
routing information about private networks. If such a router receives
such information the rejection shall not be treated as a routing
protocol error."
Les blocs que nous filtreront selon la RFC 1918 sont :
- 0.0.0.0/8 repr?sentant une machine sans adresse ce qui ne doit pas exister
- 127.0.0.0/8 repr?sentant l'interface de loopback
- 169.254.0.0/16 utilis? comme adresse d'autoconfiguration en cas d'?chec
avec DHCP
- 192.0.2.0/24 r?serv? pour documentation et test
- 192.168.0.0/16 ; 172.16.0.0/12 et 10.0.0.0/8 pour les adresses priv?es
- 224.0.0.0/3 repr?sentant des r?seaux multicast de classe D notamment utilis?
par OSPF et certains broadcast videos, et exp?rimentaux de classe E
Pour plus d'informations sur l'assignation d'espaces d'adresses et m?me de
num?ros d'Autonomous System (priv?s de 64512 ? 65535), r?f?rez vous aux RFC
1166 et 1466 et aux registres de l'IANA sur l'adressage IPv4 listant plusieurs
classes C : http://www.iana.org/assignments/ipv4-address-space. Enfin, fin
2002, l'IANA a souhait? r?sum? en un seul document ces contenus disp?rs?s au
sein de la RFC 3330 [3330].
Sur les routeurs Cisco, nous allons configurer des access-list. Cette op?ration
s'effectue en mode 'configure terminal' :
router#configure
Configuring from terminal, memory, or network [terminal]?
Enter configuration commands, one per line. End with CNTL/Z.
router(config)#
La commande access-list se d?compose de la mani?re suivante :
Number a la double fonction de num?roter l'access list, et donc par extension,
l'access group, tout en sp?cifiant le type d'ACL souhait?. De 1 ? 99 ce sont
des ACL standards tout comme de 1300 ? 1999 si cela ne suffit pas ; de m?me, de
100 ? 199 et de 2000 ? 2699, nous avons affaire ? des Extended ACL. La liste
n'est pas exhaustive, et vous en apprendrez bien plus en tapant :
router#access list ?
Nous utiliserons les EACL contr?lant la source, la destination, le protocole et
le port. Les diff?rents mots-cl?s qu'elles nous permettent d'utiliser sont les
suivants :
- 'permit' et 'deny' permettent de laisser passer ou de bloquer un paquet
tandis que 'remark' permet de placer un commentaire
- 'protocol' matche les paquets d'un protocole donn?e (eigrp, gre, icmp, igmp,
igrp, ip, ipinip, nos, ospf, tcp, ou udp)
- 'source' correspond ? l'adresse IP ? bloquer, et 'source mask' ? son masque
de sous-r?seau en notation invers?e. En mettant ce champ ? any, votre r?gle
sera valable quelque soit l'adresse.
- le champ suivant est constitu? d'un op?rateur 'lt' pour inf?rieur ?, 'gt'
pour sup?rieur ?, 'eq' pour ?gal ou 'neq' pour diff?rent, suivi du num?ro de
port source. L'utilisation de comparateurs permettra de filtrer selon une
gamme de ports.
- 'destination', 'destination mask' et 'destination port', sont ?quivalent aux
champs pr?c?dents pour la destination
- 'options' peut prendre pour valeur 'tos' (max-reliability, max-throughput,
min-delay, min-monetary-cost, normal) ou 'precedence' (critical, flash,
flash-override, immediate, internet, network, priority, routine) avec le
protocole IP pour filtrer selon le ToS ou l'IP Precedence, respectivement.
Mais vous pouvez ?galement sp?cifier l'?tat 'established' pour TCP v?rifiant
ainsi la pr?sence du flag ACK, ou bien, pour ICMP, la paire type/code ou
simplement le nom du message.
- Les derniers mots-cl?s co?ncident avec les instructions de journalisation,
soit 'log' pour une journalisation classique des informations du paquet,
suivi ?ventuellement de 'log-input' pour ajouter ? ces informations les
adresses MAC et l'interface de r?ception. Notez qu'un paquet unique n'est
enregistr? qu'une seule fois toute les 5 minutes, les donn?es journalis?es
se voyant alors compl?t?es par un compter du nombre d'occurence.
------------------------------------ SNiP -------------------------------------
no access-list 101
! filtrage selon les RFCs 1918, 1166, 1466 et 3330
access-list 101 deny ip 0.0.0.0 0.0.0.255 any log log-input
access-list 101 deny ip 10.0.0.0 0.0.0.255 any log log-input
access-list 101 deny ip 14.0.0.0/8 0.0.0.255 any log log-input
access-list 101 deny ip 24.0.0.0/8 0.0.0.255 any log log-input
access-list 101 deny ip 127.0.0.0 0.0.0.255 any log log-input
access-list 101 deny ip 169.254.0.0 0.0.255.255 any log log-input
access-list 101 deny ip 172.16.0.0 0.0.240.255 any log log-input
access-list 101 deny ip 192.0.2.0 0.255.255.255 any log log-input
access-list 101 deny ip 192.18.0.0/15 0.0.254.255
access-list 101 deny ip 192.88.99.0/24 0.255.255.255
access-list 101 deny ip 192.168.0.0 0.0.255.255 any log log-input
access-list 101 deny ip 224.0.0.0 0.0.0.108 any log log-input
access-list 101 deny ip 240.0.0.0/4 0.0.0.240
! Bonus Track : Sun Microsystems cluster interconnects
access-list 101 deny ip 204.152.64.0 0.255.255.255 any log log-input
! adresses internes arrivant depuis l'ext?rieur
access-list 101 deny ip any log log-input
------------------------------------ SNiP -------------------------------------
Il ne reste plus qu'? appliquer cette configuration ? votre routeur, sur
l'interface de sortie, bien entendu :
router(config)#interface e0
router(config-if)#ip access-group 101 in
router(config-if)#^Z
router#write
Building configuration...
[OK]
router#
Cette configuration est ? appliquer sur l'interface externe en entr?e. Mais
elle peut - et m?me doit ! - s'appliquer tout aussi bien en output sur l'une
des interfaces pour ?viter de laisser fuir des adresses non-autoris?es.
Si vous ?tes charg?s de l'administration d'un r?seau important, et remaquez que
vos access-lists s'allongent de mani?re inqui?tante pour les performances de
vos routeurs, sachez qu'il existe une solution. En effet, depuis IOS 12.0(6)S,
les ACL ont la possibilit? d'?tre compil?es, devenant ainsi des Turbo ACL. Le
ruleset est remplac? par une structure de donn?es, dites lookup tables, proche
des tables de routage. Le parcours du ruleset est alors remplac? par des
comparaisons avec entre les en-t?tes de paquets et ces lookup tables. Le tout
en conservant la r?gle du "first match win" (arr?t ? la premi?re ?quivalence
entre un paquet et une r?gle) propres aux ACL Cisco.
Il suffit, pour effectuer la compilation, d'entr?e la ligne suivante :
router(config)#access-list compiled
La documentation Cisco [TACL] affirme que pour des rulesets de plus de 3
entr?es, gr?ce aux lookup tables, la charge CPU et la dur?e de recherche de
concordance sont d?sormais fixes, quelqu'e?t ?t? la taille du ruleset d'origine
maintenant compil?. La compensation est une consommation sup?rieure ? la
normale de m?moire, de l'ordre de un Mo par access-group. Il devient alors
capital de correctement grouper ses r?gles. D'autre part, si votre ruleset
comporte des ACL de type reflexive, dynamique ou born?es dans le temps,
celles-ci se verront exclues de la compilation. Ce genre de configuration peut
cr?er des situations peu confortables ou ACL exotiques en liste et ACL
classiques compil?es fonctionnent parall?lement. Les Turbo ACL demeurent
toutefois int?ressantes pour obtenir un filtrage restrictif qui ne p?nalise les
op?rations de routage ? son profit.
La commande 'show access-list compiled' propose des informations tr?s compl?tes
en particulier pour d?terminer les r?gles exotiques qui n'ont pas pu ?tre
compil?es. Celle-ci seront alors affich?es par la commande accompagn?es de la
mention "Unsuitable" dans la colonne "State" :
router#show access-list compiled
Vous trouverez plus de d?tails sur les ACL en [RIP]. Sachez ?galement, dans un
souci d'interop?rabilit?, que la configuration et la syntaxe des ACL sont tr?s
similaires pour GNU Zebra [ZEB], le sous-syst?me de routage libre le plus
complet ? ce jour.
Pour aller encore un peu plus loin avec les technologies Cisco, sachez que vous
disposez d'un des rares dispositifs int?gr?s liant IDS et firewall, au sein du
Firewall IDS [FIDS], pr?sent depuis IOS 12.0(5)T. Comme tout bon IDS, il
inspecte chaque paquets ou sessions traversant le routeur, ? la recherche
d'analogies avec l'une de ses 59 signatures. Il est alors capable, en outre de
la classique journalisation, de prendre des actions en r?ponses ? une alerte
afin de contrecarrer une attaque en cours, et ce de mani?re compl?tement
automatis?e. Pour les amateurs de Cisco jusqu'au bout des ongles, il sera m?me
possible de l'int?gr? comme senseur du Secure IDS (c'est-?-dire NetRanger) et
d'obtenir un syst?me de journalisation des alertes centralis?.
Les signatures utilis?es sont basiquement hierarchis?e, entre 'atomic' pour
celles concernant un unique paquet et 'compound' lorsqu'on surveille une suite
d'actions ou d'?tats (hierarchie interne au syst?me), ou entre 'info' pour les
actions de reconnaissances (g?n?ralement atomiques) et 'attack' pour les
attaques compl?tes (plut?t compound). Les r?ponses, quant ? elles, sont 'alarm'
pour alerter via syslog, 'drop' pour rejeter le paquet et 'reset', reserv? au
transmission TCP, qui permet de terminer une connexion en envoyant un segment
RST ? chaque extr?mit?. Vous pouvez tout d'abord configurer le comportement par
d?faut pour les deux types de signatures attack et info, c'est-?-dire une ou
plusieurs des 3 actions pr?sent?es :
router(config)#ip audit info action alarm
router(config)#ip audit attack action alarm drop reset
Comme notre sujet se concentre sur les DDoS, il est assez inutile de consommer
des ressources au niveau des routeurs pour tenter de d?tecter toutes les
attaques. Firewall IDS est en effet un gros consommateur de ressources, comme
tout IDS ou firewall, ? cause de la recherche de correspondances ou de la
notification. D'autre part, il appara?t ?vident que 59 signatures sont bien peu
de choses face aux nouvelles attaques d?couvertes chaque jour. M?me si la
volont? de Cisco ?tait de constituer un syst?me ? jour, ce qui n?cessiterait
des mises ? jour r?guli?res, la m?thodologie de mise ? jour d'IOS deviendrait
vite ?puisante. Un IDS d?di? sera plus ? m?me de se consacrer ? la d?tection
d'attaques, disposant d'un ruleset certainement plus ? jour. Heureusement,
Firewall IDS offre la possibilit? de d?sactiver des signatures.
router(config)#ip audit signature {disable | list }
Signature-id est un num?ro d'identification d'une signature. Vous pourrez
trouver la liste compl?te dans la documentation Cisco [FIDS] ou dans la
NetRanger Network Security Database. Dans notre cas, elles seront toutes
d?sactiv?es (disable) ? l'exception des signatures 3050 (SYN flood), 2154 (Ping
of Death) et 3106 (spam). La seconde option, list, permet d'attacher une
signature ? un num?ro d'ACL. Mais cette op?ration sera de toutes mani?res
r?alis?e par la commande suivante :
'ip audit name' permet d'attacher un type entier de signatures ? une ACL, tout
en d?finissant les actions ? prendre. Ces derni?res prendront le dessus sur la
configuration par d?faut. Vous trouverez ci-dessous un exemple d'application avec
et sans couplage ? une ACL.
------------------------------------ SNiP -------------------------------------
! application sans ACL
ip audit signature 1000 disable
ip audit name reco info action alarm
! seules les Standard ACL sont accept?es
ip audit name forged list 99 alarm drop reset
access-list 99 deny 198.162.0.0 0.0.255.255
------------------------------------ SNiP -------------------------------------
Remarquez que lier une r?gle d'audit et une ACL n'est absolument pas
obligatoire. Cette m?thode permet seulement, avec 'ip audit signature', de
personnaliser totalement le set de signatures utilis?es selon l'h?te ou le
r?seau, pour prot?ger ce qu'on appelle communemment des trusted hosts.
Il ne reste plus alors qu'? attacher vos r?gles d'audit ? une interface, comme
pour une ACL :
Typiquement, on attachera les r?gles dans le sens rentrant (in) pour une
interface externe et dans le sens sortant (out) pour une interface interne.
Notez que la r?gle 3106 se rapportant ? la d?tection du spam n?cessite une
petite configuration suppl?mentaire. Elle se base en effet sur le nombre
d'adresses mails contenues par le champ SMTP RCPT TO, c'est-?-dire le champ
indiquant les destinataires. La valeur par d?faut est 250, mais vous avez tous
loisirs de l'ajuster de la mani?re suivante :
router(config)#ip audit smtp spam 50
Enfin, pour la notification par la journalisation, vous avez ?galement une
marge de configuration permettant de d?finir son format (syslog par d?faut).
Ceci vous permettra par exemple d'adopter un format lisible en cas de
notification distante vers NetRanger. Ci-dessous, la commande en question :
Enfin, vous disposez des habituelles commandes d'afficage du sous-syst?me,
toutefois un peu plus compl?tes qu'? l'habitude pour le Firewall IDS. Outre
l'afficache de la configuration globale, vous pouvez consulter la
configuration par interface, ainsi que des statistiques d'utilisation :
router#show ip audit configuration
router#show ip audit interface
router#show ip audit statistics
Ces derni?res peuvent ?tre remises ? z?ro de la mani?re suivante :
router#clear ip audit statistics
Tandis que la configuration globale d'audit peut ?tre supprim?e avec la
commande qui suit :
router#clear ip audit configuration
Bien s?r vous pouvez vouloir appliquer une protection minimale contre les
paquets forg?s, tirant parti d'adresses non routables, sans avoir un large
r?seau disposant de routeurs. Pour cela il vous suffit d'appliquer la m?me
configuration ? vos firewalls. Ci-dessous un exemple de configuration pour
IPFilter [IPF] (et sans doute Packet Filter d'OpenBSD). Ce firewall existe sur
de nombreux syst?mes et le ruleset est ais?ment traduisible.
------------------------------------ SNiP -------------------------------------
# bloque et log les paquets avec les adresses sources suivante en entr?e sur
# l'interface fxp0, assumant que celle-ci est l'interface externe
extinf=fxp0
us=/
block in log quick on $extinf from 0.0.0.0/8 to any
block in log quick on $extinf from 10.0.0.0/8 to any
block in log quick on $extinf from 14.0.0.0/8 to any
block in log quick on $extinf from 24.0.0.0/8 to any
block in log quick on $extinf from 127.0.0.0/8 to any
block in log quick on $extinf from 169.254.0.0/16 to any
block in log quick on $extinf from 172.16.0.0/12 to any
block in log quick on $extinf from 192.0.2.0/24 to any
block in log quick on $extinf from 192.18.0.0/15 to any
block in log quick on $extinf from 192.88.99.0/24 to any
block in log quick on $extinf from 192.168.0.0/16 to any
block in log quick on $extinf from 204.152.64.0/24 to any
block in log quick on $extinf from 224.0.0.0/3 to any
block in log quick on $extinf from 240.0.0.0/4 to any
block in log quick on $extinf from $us to any
------------------------------------ SNiP -------------------------------------
Afin de vous faciliter la vie, voici les m?mes r?gles traduites pour iptables,
le firewall du projet Netfilter, disponible depuis Linux 2.4.x.
iptables -A INPUT -i $EXTINF -s 0.0.0.0/8 -j DROP
iptables -A INPUT -i $EXTINF -s 10.0.0.0/8 -j DROP
iptables -A INPUT -i $EXTINF -s 14.0.0.0/8 -j DROP
iptables -A INPUT -i $EXTINF -s 24.0.0.0/8 -j DROP
iptables -A INPUT -i $EXTINF -s 127.0.0.0/8 -j DROP
iptables -A INPUT -i $EXTINF -s 169.254.0.0/16 -j DROP
iptables -A INPUT -i $EXTINF -s 172.16.0.0/12 -j DROP
iptables -A INPUT -i $EXTINF -s 192.0.2.0/24 -j DROP
iptables -A INPUT -i $EXTINF -s 192.18.0.0/15 -j DROP
iptables -A INPUT -i $EXTINF -s 192.88.99.0/24 -j DROP
iptables -A INPUT -i $EXTINF -s 192.168.0.0/16 -j DROP
iptables -A INPUT -i $EXTINF -s 204.152.64.0/24 -j DROP
iptables -A INPUT -i $EXTINF -s 224.0.0.0/3 -j DROP
iptables -A INPUT -i $EXTINF -s 240.0.0.0/4 -j DROP
iptables -A INPUT -i $EXTINF -s $US -j DROP
iptables -A INPUT -i ?EXTINF -j LOG -log-prefix "incoming pkts on extif:"
------------------------------------ SNiP -------------------------------------
Pour les programmes de DDoS, il ne sert ? rien d'essayer de filtrer les ports
de leur daemons et proxies puisqu'ils utiliseront en g?n?ral pour communiquer
des covert channels, tels que la c?l?bre paire ICMP echo request/reply. Pour
utiliser un syst?me similaire au Cisco Firewall IDS, vous pouvez utiliser Snort
coupl? ? Guardian [GRD]. Ce dernier scan les logs Snort et, en cas d'alertes,
ex?cute un shell script ins?rant une r?gle dynamique dans le firewall. Ce
m?canisme fonctionne avec iptables, ipchains et ipfwadm sur Linux et ipfw sur
FreeBSD. Cependant cette alternative est peu ?l?gante et multiplie les
possibilit?s d'erreurs ou d'abus, nous faisant pr?f?rer des syst?mes int?gr?s
comme Cisco IOS ou bien, en open source, Prelude IDS [PREL].
L'int?r?t principal, dans le fait d'aborder le filtrage, est de donner un
aper?u des capacit?s disponibles sur tous les syst?mes r?cents. Vous disposez
ainsi d'un moyen simple de vous prot?ger unilat?ralement d'attaques par
spoofing des plus basiques, ainsi que d'erreurs ou d'exploitation dans des
configurations BGP laxistes. Toutes ces erreurs peuvent mener ? des DDoS.
2.2. RPF
Le Reverse Path Forwarding est une technologie Cisco qui peut s'av?rer tr?s
utile dans la lutte contre le spoofing. Lorsqu'un paquet arrive sur une
interface, RPF v?rifie que l'interface ayant re?u ce paquet co?ncide avec le
plus court chemin du routeur ? la source. C'est seulement ? cette condition que
le routeur pourra faire suivre le paquet. Dans le cas contraire, cela signifie
que le paquet est ill?gitime (d?lib?r?ment construit lors d'une attaque, ou
bien issue d'une erreur de routage) et il est donc rejet?. Le Unicast RPF [RPF]
activ? sur des routeurs externes (type eBGP) offre une mani?re simple et
?l?gante d'?viter l'arriv?e de paquets forg?s sur l'interface externe avec,
en source, une adresse correspondant ? l'un des r?seaux directement connect?s
au routeur. En effet, selon les crit?res de RPF, le routeur les verra comme
arrivant par une mauvaise interface, c'est-?-dire n'empruntant pas le chemin le
plus court. Et ainsi quelque soit les adresses, priv?es ou publiques, globales
ou de sous-r?seau, se trouvant derri?re ledit routeur.
Cette v?rification s'effectue gr?ce ? une autre technologie Cisco, le Cisco
Express Forwarding ou CEF [CEF], bas?e sur une image de la table de routage
appel?e Forward Information Base (FIB) maintenant une liste de next-hop par
prefixe IP, ainsi qu'une Adjacency Table listant le next-hop au layer 2 pour
chaque entr?e dans la FIB. Un raffinement du CEF consiste ? faire par d?faut
du load balancing par destination : chaque paire d'adresses conserve le m?me
chemin mais diff?rentes paires peuvent avoir diff?rents chemins de valeur
m?trique ?quivalente.
Le Unicast RPF s'active par interface, apr?s l'activation de CEF, le tout en
utilisant la s?quence des commandes ci-dessous.
------------------------------------ SNiP -------------------------------------
ip cef
! per-destination est le comportement par d?faut
ip load-sharing per-destination
interface e0
ip verify unicast reverse-path
------------------------------------ SNiP -------------------------------------
Notez que vous pouvez ajouter ? la fin de la commande 'ip verify unicast
reverse-path' le num?ro d'une ACL qui d?terminera le traitement du paquet en
cas d'echec au test RPF. Ce tour de passe-passe vous permet gr?ce ? une r?gle
deny de loguer les paquets rejet?s, fonctionnalit? non offerte par RPF.
Devant l'int?r?t suscit? par cette fonctionnalit?, il n'a pas fallu attendre
longtemps pour en retrouver des ?quivalents dans le logiciel libre.
L'importance d'une telle commande est de simplifier le travail de
l'administrateur en rempla?ant ais?ment les configurations complexes
n?cessaires auparavant pour atteindre le m?me but. En effet, sur tout firewall
g?rant correctement les op?rateurs logiques, il sera possible d'?crire une
r?gle emp?chant tous paquets marqu?s d'une certaine adresse de passer par autre
chose que l'interface ? laquelle cette adresse est normalement attach?e. Par
exemple, en suivant une syntaxe type IPF (ou PF), la configuration serait telle
que ci-dessous (avec extif l'interface externe et subnet le r?seau priv?) :
block drop in on !$extif inet from $subnet to any
Depuis Linux 2.4, vous pouvez activer une telle fonctionnalit? par interface
via les variables disponibles dans /proc/sys/net/ipv4/conf/. M?me si il est
exprim? diff?remment, le raisonnement reste le m?me. Pour Linux, si l'interface
par laquelle le paquet analys? est suppos? quitter son r?seau ne correspond pas
? celle par laquelle il rentre, alors il est consid?r? comme invalide et
rejet?. Concr?tement, cela revient ? v?rifier dans la table de routage si ce
paquet entre bien par l'interface directement connect?e ? son r?seau d'origine.
Pour l'activer dans une interface donn?e, ex?cutez la ligne suivante :
# echo "1" > /proc/sys/net/ipv4/conf//rp_filter
O? 'interface' est ? remplacer par le nom de l'interface. Pour ?tendre cette
configuration ? l'ensemble de vos interfaces, remplacez 'interface' par
'default" ou 'all'. Enfin, pour la rendre persistante, il vous faudra ajouter
cette commande sous forme de script ? /etc/rc.d/init.d/.
Pour d?tecter quels paquets sont effectivement rejet?s, afin de corriger
?ventuellement une configuration ind?sirable, ajoutez ?galement cette entr?e :
# echo "1" >/proc/sys/net/ipv4/conf//log_martians
Pour ?tendre cette configuration, suivez les m?mes instructions que pour
rp_filter. Plus de d?tails dans le Linux Advanced Routing & Traffic Control
(LARTC) Howto [LARTC].
Pour ce qui est de FreeBSD, la r?-impl?mentation d'IPFW, sous le nom IPFW2,
a vu l'ajout - dans FreeBSD 4.8 avec l'option IPFW2, ou dans -CURRENT avec
l'option IPFW classique - du mot-cl? 'verrevpath' [VRP], r?f?rence directe ? la
commande correspondante chez Cisco. Le fonctionnement est strictement similaire
? Linux. Pour chaque paquet correspondant aux r?gles affubl?es de verrevpath,
ipfw v?rifie, au sein de la table de routage, si l'interface par laquelle un
paquet entre, coincide avec celle li?e ? la route vers le r?seau d'origine du
paquet. Par pr?caution, tous les paquets sortant ou bien ceux qui ne poss?dent
pas d'interface de sortie correspondante ? leur adresse source (c'est-?-dire
venant d'un r?seau non directement connect?e) passent le test.
Un r?gle ipfw appliquant cette s?curit? ? tous les paquets entrant dans un
r?seau ressemblera ? celle qui suit, avec extif repr?sentant l'interface
d'entr?e :
ipfw add 100 allow log all from any to any via ${extif} verrevpath
Le dernier ? suivre ce mouvement fut OpenBSD, avec PF [PF]. Depuis la release
3.3, celui-ci dispose du mot-cl? 'antispoof' sur lequel vous trouverez des
informations compl?tes dans pf.conf(5)[MANPF]. La commande type IPF que nous
avons vu plus haut, peut d?sormais ?tre remplac?e, dans pf.conf, gr?ce ?
antispoof, de la fa?on suivante :
antispoof for $extif inet
Outre la v?rification qu'aucun paquet ayant pour source une adresse du r?seau
auquel est attach?e une certaine interface (ici extif) ne sorte pas une autre,
une seconde protection, sp?cifique ? OpenBSD, est ajout?e en rejetant
compl?tement tout paquet ayant pour source l'adresse de l'interface prot?g?e.
Elle remplace donc aussi la r?gle suivante, o? 192.168.0.1 correspondait ?
l'interface prot?g?e :
block drop in inet from 192.168.0.1 to any
Notez que les applications qui communiquent avec les interfaces locales via
l'interface loopback peuvent se trouver perturb?es, comme pr?cis? dans la man
page pf.conf(5). Pensez alors ? ajouter une r?gle autorisant explicitement les
transmissions depuis l'interface de loopback.
L'autre probl?me majeur que vous pouvez rencontrer avec RPF sera le rejet de
paquets l?gitimes ? cause des routes asym?triques auxquelles peuvent conduirent
les protocoles de routage dynamique. Pour cette raison, il sera pr?f?rable de
n'appliquer RPF que pour des adresses d'un r?seau directement connect? (donc
sur des interfaces priv?es) et d'enregistrer les paquets rejet?s afin de
pouvoir d?teter un tel probl?me.
2.3. Route filtering
Poursuivant notre lutte acharn?e contre le spoofing, il appara?t rapidement
judicieux et n?cessaire d'?viter simplement la possibilit? de router un paquet
apparemment forg?. En effet, les auteurs de spam et de DDoS disposent de
plusieurs techniques permettant l'usurpation ou le d?tournement temporaire
d'adresses afin de lancer leurs attaques. Un routeur malin peut ainsi servir
? introduire dans la table BGP Internet globale des annonces de routes de
courte dur?e vers des adresses priv?es. Dans la m?me veine, la d?sagr?gation
consiste ? annoncer des routes plus sp?cifiques, c'est-?-dire d'une longueur
de prefixe (en notation CIDR) plus grande, la rendant ainsi prioritaire dans le
processus de prise de d?cision BGP pour l'installation d'une route.
Afin de contr?ler au plus pr?s les annonces re?ues et distribu?es, Cisco (et,
par extension, Zebra) dispose de plusieurs m?canismes ? m?me d'effectuer un
filtrage des routes propag?es, via BGP, au niveau de vos routeurs externes,
dits routeurs eBGP. Chaque r?seau se voit attribu? dans sa globalit? un num?ro
d'AS (Autonomous System). La distinction entre routeur externe (eBGP) et
interne (iBGP) se base alors sur les num?ros d'AS utilis?s pendant une session.
Si'ils diff?rent entre deux routeurs voisins, nous nous trouvons en pr?sence
d'une liaison eBGP, c'est-?-dire entre deux r?seaux, soutendant des modes de
propagation de routes diff?rents. Les m?thodes d?crites ci-apr?s permettent de
ne pas tenir compte de certaines annonces de routes en les filtrant simplement
d?s l'entr?e de votre r?seau. Ainsi, il n'y aura jamais aucune route, dans nos
tables de routage, vers ces adresses.
Les deux m?thodes en question ont pour noms 'distribute-list' et 'prefix-list'.
Bien que relativement redondantes, nous ?voquerons les deux pour plusieurs
raisons. Tout d'abord, elles sont mutuellement exclusive, ce qui signifie que
vous ne pouvez en aucun cas les appliquer simultan?ment sur un m?me routeur. Il
est m?me recommander de rester coh?rent de d'utiliser la m?me technique ?
l'?chelle de votre r?seau. La diff?rence majeure entre ces deux commandes
demeure la cat?gorisation des informations. Dans un cas, 'distribute-list', il
est fait appel aux ACL pour filtrer les adresses annonc?es, tandis que
'prefix-list' utilise un m?canisme qui lui est propre. Les deux sch?mas se
configurent de mani?re similaire en mode BGP config.
Les distribute-list, pr?sentes depuis IOS 10.0, comme toutes les innombrables
options de la commande 'neighbor', pourront s'appliquer individuellement ?
chaque routeur voisin selon leur adresse IP, ou bien ? tous les routeurs
voisins d?finis au sein d'un peer group. Voyez la documentation Cisco [CBGP]
pour de plus amples informations sur cette configuration tr?s pratique.
Une distribute-list est en r?alit? une simple invocation d'une Standard ACL
contre laquelle les messages BGP seront test?s. Pour appliquer une telle liste
aux messages en provenance d'un routeur voisin, utilisez la commande suivante :
Comme vous le voyez, la commande est assez simple. Outre la d?finition du
voisin ou du groupe de voisins auquel les ACL s'appliqueront, vous pouvez
ensuite sp?cifier le num?ro de ces fameuses ACL ou bien, ? d?faut, pr?ciser
le nom d'une prefix-list. La configuration finale, en reprenant les ACL vues
pr?c?demment, devrait ressembler ? l'exemple suivant.
------------------------------------ SNiP -------------------------------------
! filtrage de route annonc?es par le voisin d'adresse x.x.x.x
neighbor x.x.x.x distribute-list 101 in
------------------------------------ SNiP -------------------------------------
La description des distribute-list a pu vous intringuer par la mise sur un pied
d'?galit? des ACL et des prefix-list. En effet, ces derni?res, apparues
seulement sur IOS 12.0, constituent un r?el remplacement des ACL. Le but est de
fournir une am?lioration des performances pour ce qui est du chargement de la
liste et des v?rifications de validit? des routes. D'apr?s Cisco, l'objectif
est atteint, en particulier lorsque l'utilisateur manipule des listes
importantes.
Le remplacement pur et simple des ACL a ?galement conduit ? quelques
modifications dans le fonctionnement du filtrage. Ainsi d?sormais, une
politique restrictive est appliqu?e par d?faut, ce qui signifie que, d?s lors
qu'une prefix-list est activ?e, tout ce qui n'est pas expressement autoris? se
voit implicitement rejet?, comme l'explique la documentation Cisco attenante.
Un autre changement est intervenu dans l'ordonnancement des r?gles elles-m?mes.
En lieu et place des num?ros d'ACL, les r?gles des prefix-list sont d?sign?es
de mani?re unique par un num?ro de s?quence. Ces num?ros s'incr?mentent, par
d?faut, de 5 ? chaque nouvelle r?gle. L'id?e sous-jacente est de pouvoir
ajouter des r?gles interm?diaires apr?s coup, simplifiant la mise ? jour de la
liste. Cependant, d?sactiver cette g?n?ration automatique peut s'effectuer tr?s
simplement :
router(config-router)#no ip prefix-list sequence number
Il devient alors obligatoire de pr?ciser le num?ro de s?quence de chacun de vos
r?gles. Cette option restait possible dans la configuration par d?faut,
conservant l'incr?ment automatique de 5 entre une r?gle au num?ro de s?quence
sp?cifi? et une laiss?e au soin de la g?n?ration automatique. Cette op?ration
est r?alis? ? travers l'option 'seq' de la commande 'ip prefix-list' qui suit :
Cette commande permet d'une mani?re g?n?rale de cr?er une liste (dont le nom
remplace 'name') et d'ajouter des r?gles en sp?cifiant une adresse IP suivant
de la longueur de son masque de sous-r?seau, juste apr?s avoir pr?cis? l'action
'deny' pour rejeter la route ou 'permit' pour l'autoriser. Les options ge
(greater-or-equal, >=) et le (lesser-or-equal, =<) sont des comparateurs
permettant de d?finir des seuils pour le masque de sous-r?seau. Un masque
inf?rieur ? 8 d?note par exemple une route tr?s g?n?rale, et peut ?tre
consid?r? comme suspect.
Appliquer une prefix-list ? un routeur voisin peut s'effectuer, comme nous
l'avons vu, par une distribute-list ou bien par une option s?par?e de neighbor
d?di?e aux prefix list, bien qu'identique ? distribute-list :
La configuration finale, suivant les RFCs RFC 1918, 1166 et 1466, sera telle
que celle ci-dessous.
------------------------------------ SNiP -------------------------------------
! prefix-list 'rfc', avec seq automatique
ip prefix-list rfc deny 192.168.0.0/16
ip prefix-list rfc deny 172.16.0.0/12
ip prefix-list rfc deny 10.0.0.0/8
ip prefix-list rfc deny 127.0.0.0/8
ip prefix-list rfc deny 224.0.0.0/3
ip prefix-list rfc deny 169.254.0.0/16
ip prefix-list rfc deny 0.0.0.0/24
ip prefix-list rfc deny 192.0.2.0/24
ip prefix-list rfc deny 204.152.64.0/24
ip prefix-list rfc permit any
! application au neighbor x.x.x.x de la liste 'rfc'
neighbor x.x.x.x prefix-list rfc in
------------------------------------ SNiP -------------------------------------
Dans les deux cas, distribute-list et prefix-list, in indiquera de filtrer les
routes en provenance du voisin, tandis que out appliquera la liste sp?cifi?e
aux annonces que votre routeur ?met vers son voisin. Les deux configurations
simultan?es sont souhaitables. Plus de pr?cisions, en particulier sur les
commandes 'show' attenantes, sont disponibles en [CBGP].
Le routage BGP exige une certaine rigueur dans les configurations pour ?viter
d'annoncer n'importe quoi n'importe comment. Comme nous avons d?j? pu
l'?voquer, filtrer strictement les routes sortant ou entrant dans notre r?seau
permet de se pr?venir de nombreuses situations assimilables ? un DoS. Une
configuration rejettant par d?faut et autorisant explicitement (restrictive
stance) permettrait quant ? elle d'?viter une bonne partie des attaques tirant
parti de configurations laxistes de la part des titulaires d'AS. En plus du
filtrage des adresses "sp?ciales" que nous venons de voir, v?rifiez toujours
que vous n'annoncez effectivement que les pr?fixes sur lesquels vous avez une
autorit?. Et n'oubliez jamais que la s?curit? tient une place primordiale dans
l'am?lioration de la qualit? et de la continuit? du service.
2.4. {Black,Sink}hole
Au sein de l'infrastructure r?seau, nous avons ?galement la possibilit? de
d?finir un 'blackhole' [GRE02]. Un tel dispositif permet de faire totalement
dispara?tre le trafic ? destination d'une machine. Ainsi, lorsqu'un DoS est
d?tect?, il suffit de blackholer la cible de l'attaque pour la prot?ger au
niveau de l'infrastructure. Sous Cisco, cela correspondra ? la d?finition d'une
route statique sur nos routeurs, liant l'adresse de la cible et la
pseudo-interface null0. Concr?tement, l'invocation de null0, sur les routeurs
disposant de la technologie CEF, implique une gestion particuli?re au sein de
l'Adjacency Table, entra?nant ? son tour le rejet pur et simple des paquets
transitant par la pseudo-interface. Il est alors int?ressant de noter que les
processeurs utilis?s dans les routeurs Cisco sont optimis?s afin d'?tre plus
efficace dans des conditions de rejets que dans celles de forwarding.
Il existe cependant quelques inconv?nients intrins?ques aux blackholes.
D'abord, la d?tection du DoS reste bien ?videmment ? la charge de
l'administrateur r?seau via un dispositif parall?le. Cela implique que le
blackhole n?cessite l'intervention manuelle du m?me administrateur pour ?tre
mis en place, r?duisant, par ce d?lai, l'efficacit? de la mesure. L'autre
d?savantage majeur est qu'aucune distinction ne peut ?tre faite entre les
paquets effectivement ? l'origine du DoS et le trafic l?gitime. Outre que cette
m?thode se voit plut?t ? des cas extr?mes et manifestes, dans lesquels une
interruption temporaire du service est pr?f?rable, le blackhole se verra
surtout utilis? ponctuellement afin d'identifier le point d'entr?e de l'attaque
dans le r?seau ? partir des messages ICMP unreachable, puis de placer sur ce
point d'entr?e des ACLs ou des politiques de limitation de d?bit (voir sections
2.1 et 3.3 respectivement).
La technique que nous d?crivons n?cessiterait cependant la configuration de
chacun de nos routeurs, travail ? combien fastidieux. Le bon sens nous indique
donc d'utiliser BGP pour redistribuer les informations concernant le blackhole.
L'id?e est de pr?param?trer sur tous les routeurs une route vers null0
attribu?e ? un bloc d'adresses inutilis? (tr?s important puisque tous les
routeurs rejetteront de fait les paquets de et vers ces adresses) tel qu'un
bloc d'adresses RFC 1918. Attention dans ce cas aux interfaces sur lesquelles
vous appliquez vos filtres distribute-list, afin de ne pas emp?cher la
redistribution de vos routes blackhole. La ligne suivante permet de lier le
bloc choisi ? une route vers null0 :
router(config)#ip route 255.255.255.0 null0
Il est ensuite n?cessaire de d?finir un routeur de moindre importance, dit
'blackhole server', depuis lequel nous d?finirons le blackhole et le
propagerons par BGP ? toute l'infrastructure. Cette ?tape sera r?alis? gr?ce ?
une politique route-map. Celle-ci appliquera aux routes statiques locales
affubl?es d'un certain tag un nouveau next-hop correspondant au bloc
d'adresses inutilis?. Comme ce dernier est partout rout? vers null0, tous les
paquets appartenant ? ces routes statiques locales seront supprim?s. La
route-map policy est de forme similaire ? celle ci-dessous.
------------------------------------ SNiP -------------------------------------
! on the blackhole server (configuration phase) in 'configure bgp' mode
redistribute static route-map blackhole
route-map blackhole permit 10
match tag 1337
set ip next-hop
set local-preference 500
set community no-export
set origin igp
------------------------------------ SNiP -------------------------------------
Bien que la commande route-map soit sans doute l'une des plus famili?re aux
administrateurs Cisco, analysons cette s?quence plus en d?tail. Le nom de la
politique est 'blackhole' et son num?ro de s?quence (cf. ACL et filter-list)
10. Cette politique s'applique ? toutes les routes statiques poss?dant le tag
'1337'. Pour cette route, une s?rie de 'set options' est alors prise. Le
next-hop est remplac? par le bloc inutilis? s?lectionn? pr?c?demment, la
pr?f?rence locale est mise ? 500 pour que la route vers le nouveau next-hop
soit choisie ? coup s?r comme best-path selon le processus de d?cision de BGP
pour les routes de provenance interne (iBGP), le champ community est mis ?
no-export pour ne pas annoncer cette nouvelle route en dehors de notre AS
(risque de blackhole complet de la part des peers), et enfin le 'BGP origin
code' est 'igp' indiquant que la source est un routeur interne.
L'application d'une politique route-map sur les routes re?ues peut se faire
soit sur la base d'une interface, soit pour un voisin (neighbor) d?sign?. Dans
le premier cas, il faudra simplement entre en mode configuration interface :
Dans le second cas de figure, il sera pr?f?rable de cr?er un groupe r?unissant
l'ensemble des routeurs internes et d'appliquer ? toutes les routes re?ues
depuis ce groupe notre politique. Cette proc?dure s'effectue en mode
configuration bgp.
Dans cette s?quence, nous cr?ons un peer-group que nous nommons (en rempla?ant
pg-name) et dont les routeurs appartiennent ? l'AS local puisqu'il regroupe
les routeurs internes (remplacer AS par le num?ro d'AS local), nous lui
appliquons la route-map blackhole sur les routes entrantes, et enfin nous y
ajoutons autant de routeurs que n?cessaires (en iBGP enti?rement connect?,
sans r?flecteurs de routes, cela correspond ? la totalit? des routeurs iBGP).
Lorsqu'un DoS occure, il suffira alors de placer, sur le blackhole server, une
route statique marqu?e du tag correspondant ? la route-map policy, comme dans
l'exemple qui suit, en rempla?ant par la cible du DoS :
router(config)#ip route 255.255.255.255 null0 tag 1337
Mais le m?canisme de blackhole permet ?galement de remonter la source de
l'attaque spoof?e, ceci en journalisant les paquets ICMP * unreachable et
l'interface qui les g?n?re. Cela vous indiquera ainsi par d?duction le point
d'entr?e du trafic spoof? dans votre domaine. Appliquer cette m?thode ? de
larges ?chelles permettrait de remonter plus facilement la source d'un trafic
spoof? en passant d'AS en AS. La journalisation s'effectue tr?s simplement par
les ACL :
router#access-list 101 permit icmp any any unreachables log log-input
Notez cependant que la redirection vers null0 risque de g?n?rer une forte
quantit? de messages ICMP unreachable. Afin de ne pas surcharger le routeur, il
sera alors n?cessaire de limiter le d?bit de ces messages - comme indiqu? en
section 3.3. de cet article - ou bien carr?ment de les supprimer totalement
avec 'no ip unreachables'.
Comme nous l'avons d?j? rapidement abord?, la m?thode originale de blackholing
provoque un rejet complet du trafic ? destination de la cible de l'attaque,
incluant le trafic potentiellement l?gitime. BGP offre pourtant des attributs
permettant d'identifier des chemins (path) distincts et donc de leur appliquer
des r?gles diff?rentes. Face ? ce constat, une m?thodologie am?lior?e de mise
en oeuvre d'un blackhole est apparu en tant que draft IETF [TURK02].
Pour d?crire ce raffinement du blackhole, nous prendrons un num?ro d'AS
d'exemple, 1337. L'id?e est que chaque routeur dispose d'une politique
route-map se d?clenchant selon une valeur de l'attribut BGP community
diff?rente pour chaque routeur. Pour simplifier la lecture de nos
configurations et aussi nous conformer ? la RFC 1997 sp?cifiant le format de
l'attribut community (AS:NN, o? AS est le num?ro d'AS et NN un nombre
quelconque, chacun sur deux octets), entrez la commande suivante en mode de
configuration globale :
router(config)#ip bgp-community new-format
Comme pour un blackhole normal, il faut s'assurer que les routeurs en bordure
du r?seau poss?de bien une route statique orientant le bloc inutilis?, servant
de nouveau next-hop en cas d'attaque, vers la pseudo-interface null0 :
router(config)#ip route 255.255.255.0 null0
Il est ensuite demand? de cr?er une AS-Path ACL permettant d'identifier les
annonces BGP provenant bien de notre AS (1337). Ceci servira ensuite ? emp?cher
un r?seau externe d'utiliser nos valeurs de community pour blackholer n'importe
quel r?seau en envoyant des annonces qui d?clencheraient notre blackhole
am?lior?. Il faut cr?er d'abord une ACL classique qui matchera tout le trafic,
puis l'appliquer ? une AS-Path ACL qui cherchera une correspondance (regexp)
entre l'attribut AS et notre num?ro d'AS.
------------------------------------ SNiP -------------------------------------
access-list 1 permit ip any
! appliquez-la ? toutes les interfaces
interface e0
ip access-group 1 out
! voyez la documentation Cisco concernant les regexp
ip as-path access-list 1 permit ^1337 .*
------------------------------------ SNiP -------------------------------------
L'utilisation de la valeur de l'attribut community parmis les match criteria de
nos politiques route-map n?cessite la cr?ation pr?alable de community ACL.
Chaque devant chercher sa propre community ainsi que celle englobant la
totalit? des borders routeurs, il existera deux r?gles dans la liste ; la
premi?re ?tant sp?cifique ? chaque routeur.
------------------------------------ SNiP -------------------------------------
! la premi?re ligne change pour chaque routeur
ip community-list 1 permit 1337:01
ip community-list 1 permit 1337:411
------------------------------------ SNiP -------------------------------------
Il ne reste plus qu'? installer sur chacun de nos border routers une politique
route-map permettant de d?clencher un blackhole ? l'appel de sa valeur de
community. C'est ici que l'on se rend particuli?rement compte de l'int?r?t de
cette m?thode sur la classique. Au lieu de voir tous les routeurs relayer la
mesure de blackhole, seul le peer eBGP d?sir? le fait, laissant les autres
routes suppos?es l?gitimes intactes. Une mesure de blackhole g?n?ral est
cependant pr?vue par l'auteur de cette technique am?lior?e puisqu'il pr?conise
d'installer ?galement une politique route-map se d?clenchant ? la r?ception de
la valeur de community correspondant ? l'ensemble des routeurs eBGP (1337:411).
Cette ?tape a ?t? simplifi? en utilisant un num?ro de community-list englobant
les deux valeurs community.
------------------------------------ SNiP -------------------------------------
redistribute bgp route-map enhanced_blackhole
route-map enhanced_blackhole permit 20
match community 1
match as-path 1
set ip next-hop
set local-preference 500
set community no-advertise
set origin igp
------------------------------------ SNiP -------------------------------------
En cas d'attaque, il ne reste plus qu'? annoncer, par l'interm?diaire de BGP,
les routes vers la cible affubl?es de la valeur de community du peer eBGP
identifi? comme point d'entr?e de l'attaque. Vous remarquerez cependant ici une
lacune importante du draft. Celui-ci semble assumer que l'administrateur est
capable d'identifier le routeur eBGP par lequel transite l'attaque. Non
seulement ce postulat n'est pas ?vident dans la vie r?elle mais, de plus, dans
le cas d'une attaque distribu?e (DDoS), les points d'entr?e peuvent ?tre assez
nombreux. Il faudrait alors plut?t voir dans ce raffinement du blackhole un
remplacement du filtering classique apportant, en outre, une capacit?
d'activation distante.
La modification de la valeur de community n?cessite de passer par BGP, donc par
une politique route-map, ? l'instar des route-maps utilis?es pour la route
statique null0 sur un serveur blackhole. Suivez la s?quence de commandes
suivante, en rempla?ant 'ebgp_community' par la valeur de community du peer eBGP
point d'entr?e pr?sum? de l'attaque.
------------------------------------ SNiP -------------------------------------
redistribute static route-map trigger_blackhole
route-map trigger_blackhole permit 30
match tag 318
set community no-export :
set local-preference 500
set origin igp
------------------------------------ SNiP -------------------------------------
Comme ? votre habitude, lorsqu'un DoS est d?tect?, il suffira d'ajouter
localement une route statique vers null0 pour d?clencher le processus de
blackhole :
router(config)#ip route 255.255.255.255 null0 tag 318
De fa?on relativement r?cente, on a vu appara?tre un raffinement suppl?mentaire
au blackhole. Le principe en est succintement d?crit dans le draft abordant la
m?thode de blackhole am?lior?e [TURK02] vue auparavant. Cette nouvelle
technique, nomm?e sinkhole par analogie aux blackholes dont elle reprend une
partie de la configuration, consiste, non plus ? r?-annoncer une route donn?e
afin que tout le trafic vers sa destination soit supprim?, mais ? la place ?
orienter ce trafic vers une installation d?di?e ? des fins d'analyse. Si nous
sommes effectivement face ? une attaque de type DDoS, il peut ?tre n?cessaire
pour l'op?rateur d'analyser le trafic d'attaque et d'en extraire le plus
possible d'information avant, ?ventuellement, de le faire suivre ? sa
destination l?gitime, pour n'?veiller aucun soup?ons. Dans une conf?rence
[GRE+03] donn?e au NANOG (North American Network Operators Group), Barry Greene
comparait quant ? lui les sinkholes aux honeypots. En effet, si
Cet article a été publié
le Mardi 6 janvier 2004 à 15 h 10 min et est classé dans Securité.
Vous pouvez en suivre les commentaires par le biais du flux
RSS 2.0.
Vous pouvez laisser un commentaire, ou faire un trackback depuis votre propre site.