GuiGui's Show

« Over the years, PowerDNS users have frequently asked us about our preferred DNS load balancing solution, and we’ve never had a satisfying answer for that. Users of dedicated hardware often tell us that vendors spend most of their time and effort on balancing HTTP, and frequently deliver substandard or even buggy DNS functionality.

In terms of software, one big PowerDNS deployment is happy with OpenBSD relayd, and it indeed does look powerful. Other operators have deployed keepalived, which is very strong from a networking standpoint, but does not offer a lot of DNS specifics.

But all in all, we never found any load balancing solution for DNS that made people truly happy.

Simultaneously, there is now a lot of focus on providing the very best DNS performance, even in the face of the ongoing reflection attacks (one of which has been dubbed the “Chinese water torture attack“).

Putting these three things together (no really satisfying DNS aware load balancer, drive for the very best performance, ongoing attacks) led us to pollute the waters of the internet with yet another piece of software: dnsdist. »

Via https://twitter.com/powerdns/status/575745432267051008

Et https://code.facebook.com/posts/681382905244727/introducing-wedge-and-fboss-the-next-steps-toward-a-disaggregated-network/

« We plan to propose the designs for “Wedge” [NDLR : top-of-rack switch) and the central pieces of “FBOSS” [NDLR : Linux-based OS for that switch ] as contributions to OCP [NDLR : Open Compute Project] , so others can start consuming the designs and building on them. [...] We plan to propose the “6-pack” design as a contribution to the Open Compute Project, and we will continue working with the OCP community to develop open network technologies that are more flexible, more scalable, and more efficient. »

« J’ai donc lu “Sécurité et espionnage informatique – connaissance de la menace APT”.

Je ne vais pas vous faire le profil de l’oeuvre. Si votre chef vous a demandé une synthèse des solutions miracles pour demain … débrouillez vous :)

[...]

Non, si vous avez vraiment du temps à perdre, il vaut mieux vous attaquer directement aux hashes donnés page 105: ils ont été “anonymisés” ; ils doivent donc être importants.

[...]

Nous disposons donc du hash LM partiel et du hash NTLM partiel pour le même mot de passe. C’est entièrement suffisant pour retrouver le mot de passe d’origine, sauf collision hautement improbable.

Tout expert sécurité sait que le hash LM se compose de deux demi-hashes totalement indépendants. Ici la première moitié du hash LM est donnée en totalité, l’inversion du demi-hash s’effectue donc instantanément avec John ou n’importe quelle Rainbow Table.

3A6999A4D3EA7D44 –> PCKRD42

Malheureusement le mot de passe est mis en majuscules avant le calcul du hash LM ; il n’est donc pas possible de connaitre la casse réelle à ce stade.

Prenant en compte ce fait, il est désormais possible de compléter le mot de passe jusqu’à tomber sur un hash NTLM commençant par 35560bc48654e (la probabilité d’une collision est pour ainsi dire nulle).

Un simple script Python suffit, car la réponse ne tarde pas à venir:

Pckrd42!:3A6999A4D3EA7D44695109AB020E401C:35560BC48654EF33BD7162C7721BDE8C:::

Ce mot de passe est très intéressant, car il vérifie tous les critères appliqués habituellement en entreprise (mais beaucoup plus rarement chez les particuliers):
    * Longueur 8
    * Présence de majuscules/minuscules/chiffres/caractères spéciaux
    * Deux derniers chiffres ressemblant fortement à un incrément (il s’agit d’une construction universellement appliquée par les utilisateurs lorsqu’un changement régulier de mot de passe est imposé – 42 jours par défaut sous Windows). »

Rigolo d'avoir creusé les hashs d'un screenshot. :D À prendre uniquement pour ça et les rappels sur LM/NTLM, osef que ça soit VM de test, poste de travail de l'auteur, ...

Config' d'un ucd-snmpd avec quelques explications sur la syntaxe du fichier de configuration.

« ipset is used to set up, maintain and inspect so called IP sets in the Linux kernel. Depending on the type of the set, an IP set may store IP(v4/v6) addresses, (TCP/UDP) port numbers, IP and MAC address pairs, IP address and port number pairs, etc. See the set type definitions below.

Iptables matches and targets referring to sets create references, which protect the given sets in the kernel. A set cannot be destroyed while there is a single reference pointing to it. »

« ipset help :
Supported set types:
    list:set
    hash:net,iface
    hash:net,iface
    hash:net,port
    hash:net,port
    hash:net,port
    hash:net
    hash:net
    hash:net
    hash:ip,port,net
    hash:ip,port,net
    hash:ip,port,net
    hash:ip,port,ip
    hash:ip,port
    hash:ip
    bitmap:port
    bitmap:ip,mac
    bitmap:ip »


Sous Debian, c'est dans le package ipset. :D

Exemple d'usage basique : on ouvre le port SSH pour les admins
ipset create trustedAdminsIP hash:ip
ipset add trustedAdminsIP 192.0.2.1
ipset add trustedAdminsIP 192.0.2.2
ipset list trustedAdminsIP
iptables -A INPUT -i lo -j ACCEPT
iptables -A INPUT -m state ---state RELATED,ESTABLISHED -j ACCEPT
iptables -A INPUT -m set --match-set trustedAdminsIP src -p tcp -m tcp --dport 22 -j ACCEPT
ipset del trustedAdminsIP 192.0.2.2
ipset flush trustedAdminsIP
ipset destroy trustedAdminsIP -> échec car une règles iptables pointe encore sur ce set ;)

Le man du module « set » d'iptables n'est pas clair mais il peut matcher sur port source et port destination, pas juste sur IP source et IP destination : ipset create lala bitmap:port range 1024-2048 ; iptables -A OUTPUT -m set --set portsconnus dst -j DROP . Je n'y trouve pas beaucoup d'intérêt compte-tenu que --dport/sport et multiport permettent déjà de passer des plages de ports.

Mon avis sur les ip set :
    * Globalement bien foutu et syntaxe de l'userland similaire à iptables, y compris ipset save et ipset restore ;

    * Ces sets seront indéniablement plus rapides que x règles iptables plus le nombre d'IP augmentera compte-tenu des structures de donnée sutilisées (hashmap). Sans compter la lisibilité d'une seule règle iptables versus x :

    * Tout comme iptables, c'est chiant de load les set au boot, chaque adminsys va avoir sa façon de faire, ses scripts d'init homemade potentiellement foireux, ... Des scripts comme ipset-persistent (équivalent d'iptables-persistent) existent mais quid de leur maturité (il n'y a qu'à voir iptables-persistent sous Squeeze uhuhuhu) ? C'est là où on se dit "pf.conf > *"

    * Je pense que l'intérêt des sets apparaît quand on les utilise pour mitiger une attaque (D)DoS, c'est à dire quand on ne peut pas utiliser le suivi des connexions. Exemple concret (et scripts) : https://www.octopuce.fr/ipset-filtrages-des-attaques-sur-les-serveurs/ . Dans le cas contraire (autoriser une liste de machines, par exemple), je ne pense pas que x règles iptables pénalisent le système : seul le premier paquet d'une connexion devra parcourir l'ensemble des règles, les paquets suivants seront capturés par une règle "-m state --state RELATED,ESTABLISHED" positionnée en amont.

Une implémentation d'arbre radix/PATRICIA (https://en.wikipedia.org/wiki/Radix_tree) en python, orienté vers le stockage et la recherche de réseaux IPv4/IPv6. Permet de "représenter" la nature arborescente de l'adressage IP.

python-radix sous Debian. ;)

Je me mets ça sous le coude pour quand la version d'OpenDNSSEC (enfin la lib ldns sous-jacente) qui supporte le RRtype TLSA sera packagée dans Debian stable (Jessie).

« "L'agilité du protocole TLS souffre du gonflement de son héritage : après 20 années d'évolutions du standard, celui-ci comporte de nombreuses versions, extensions, et suites de chiffrement, dont certaines ne sont plus utilisées ou connues pour être non-sécurisées" écrivent les chercheurs dans le rapport consacrés aux attaques FREAK. Et cet héritage est justement une des causes de ce nouveau risque de sécurité identifié sur Internet.

En effet, la multiplication des versions du protocole, des modes d'authentification et des méthodes d'échange de clé permettant d'établir une connexion sécurisée entre un client et un serveur a engendré des "bugs" et "plusieurs vulnérabilités de sécurité critiques". Et ces failles sont demeurées cachées dans "ces libraires pendant des années".

[...]

Freak est particulièrement intéressante puisque cette vulnérabilité a pour origine les restrictions à l’export qui ont été mises en place sur la cryptographie dans les années 90. Ces familles d’algorithmes dédiés à l’export étaient plus faibles que les versions classiques aujourd’hui communément utilisées. L’attaque repose sur cela : à cause d’un bug, un attaquant peut exploiter cela et modifier les messages entre le client et le serveur pour forcer l’utilisation de ces familles de chiffrement, initialement destinées à l’export et qui ne garantissent pas une sécurité suffisante. Du côté client, celui-ci croit accepter une connexion sécurisée, mais celle-ci ne l’est pas, en tout cas pas aussi solide que ce qu’il croit.

Deux conditions sont nécessaires pour que l’attaque soit mise en place : il faut que l’attaquant parvienne à se placer dans un schéma d’attaque de type "Man in the middle", afin d’intercepter les messages échangés entre le client et le serveur, et côté serveur, il faut que celui-ci supporte les familles export d’algorithmes. Cette attaque reste assez délicate à mettre en œuvre puisqu’elle demande des moyens relativement importants : il parait difficile pour un individu visant une entreprise par exemple, d’envisager utiliser une attaque de ce type. C’est en revanche beaucoup plus envisageable pour un attaquant soutenu par un Etat.

[...]

D’après des tests réalisés par des experts de l’université du Michigan, un tiers des sites utilisant du chiffrement s’avèrent vulnérables à des attaques FREAK. C’est en particulier le cas de ceux utilisant OpenSSL (un correctif existe) et des clients TLS/SSL d’Apple. D’ailleurs le navigateur Safari de l’éditeur est vulnérable, tout comme celui intégré dans Android. Chrome, Firefox et Internet Explorer ne sont en revanche pas concernés. [ÉDIT du 06/03/2015 à 10h23 : sisi IE est aussi concerné : http://arstechnica.com/security/2015/03/stop-the-presses-https-crippling-freak-bug-affects-windows-after-all/ FIN DE L'ÉDIT.]

[...]

l’attaque Freak mais il faut bien comprendre que celle-ci appartient à une famille d’attaques, que nous avons regroupées sous le nom de State Machine Attacks. Toutes ont pour point commun la façon dont les implémentations de TLS gèrent les algorithmes de chiffrement. On a ainsi détaillé sur le site smacktls une autre attaque, qui vise cette fois l’implémentation de TLS au sein de Java, JSSE, et qui repose sur les mêmes principes.  [...] A l’origine, il y a eu un précurseur à cette attaque, nommé Early CCS. C’est cette attaque qui a montré que les messages envoyés au serveur TLS pouvaient être acceptés dans un ordre incorrect. Nous avons donc cherché comment savoir si les states machines étaient implémentées correctement. Pour tester cette hypothèse, Nous avons développé un outil afin de tester des séquences de messages volontairement incorrectes : si l’implémentation est correcte, alors un message d’erreur doit être renvoyé. Nous avons constaté beaucoup de cas ou aucune alerte n’était remontée et nous nous sommes donc interrogés sur l’interprétation à donner. C'est donc en étudiant le code source d’implémentations Open Source de TLS que nous avons découvert ces attaques. »

Bref, FREAK c'est mort côté client si pas Apple/Android ou en appliquant les patchs si c'est le cas et côté serveur en virant les suites cryptos destinées à l'export (regroupées dans le groupe EXP dans OpenSSL), ce qui devrait être fait depuis longtemps.

Via http://seenthis.net/messages/348012

« Le Gouvernement a fait publier au Journal Officiel le décret qui autorise ses services de police à demander à Google et d'autres moteurs de recherche ou annuaires le déréférencement de sites accusés de faire l'apologie du terrorisme. Les sites devront être supprimés des index dans les 48 heures, sans possibilités de recours.

Un mois après le décret autorisant le blocage administratif des sites sur ordre du ministère de l'intérieur, le Gouvernement a fait publier jeudi au Journal Officiel le décret "relatif au déréférencement des sites provoquant à des actes de terrorisme ou en faisant l'apologie et des sites diffusant des images et représentations de mineurs à caractère pornographique".

Le texte permet à l'Office central de lutte contre la criminalité liée aux technologies de l'information et de la communication (OCLCTIC) de notifier aux moteurs de recherche les sites accusés de relayer la propagande de terroristes, afin qu'ils soient déréférencés sur le champ, sans qu'un juge ne vérifier l'illégalité des sites en cause. Google et ses concurrents auront 48 heures pour prendre "toute mesure utile destinée à faire cesser le référencement de ces adresses", et devront le faire en respectant scrupuleusement "la confidentialité des données qui leur sont ainsi confiées". Pas question, donc, de publier les ordres de censure.

[...]

En revanche, alors que le blocage s'accompagne d'une redirection vers un site du ministère de l'intérieur qui fait explique le blocage et indique des voies de recours, rien n'est prévu pour s'opposer au déréférencement, à l'effet dévastateur.

[...]

Le déréférencement sur ordre policier des sites de propagande terroriste avait été introduit par un amendement surprise du Gouvernement présenté à la dernière minute, lors des débats sur la loi anti-terrorisme de 2014. Le ministre de l'intérieur Bernard Cazeneuve avait alors expliqué en séance que le dispositif proposé était identique à celui déjà prévu pour les sites d'argent en ligne, ce qui était mensonger. La loi sur les jeux d'argent en ligne prévoit que le déréférencement peut être ordonné par un magistrat, le président du TGI de Paris, et non directement par l'exécutif.

[...]

Le terrorisme n'est pas une notion simple à appréhender juridiquement, et n'a d'ailleurs jamais fait l'objet d'un consensus au niveau international. [...] Hélas, les événements récents consécutifs aux attentats de janvier 2015 à Paris ont rappelé que l'Etat avait une vision très large de l'apologie du terrorisme, au mépris de la liberté d'expression. »

« Ce nouveau RFC résume l'état actuel des bonnes pratiques en matière de sécurité BGP. Du classique, aucune révélation, juste la compilation de l'état de l'art. Ce RFC porte aussi bien sur la protection du routeur, que sur le filtrage de l'information (les routes) reçues et transmises. [...] Ce genre de compilation aurait plutôt due être faite dans le cadre du project BCOP mais celui-ci semble mort.

[...]

La section 2 de ce RFC rappelle qu'il n'a pas de caractère obligatoire : il expose des pratiques de sécurité générales, et il est toujours permis de faire des exceptions, en fonction des caractéristiques spécifiques du réseau qu'on gère.

Donc, au début (sections 4 et 5 du RFC), la protection de la discussion entre deux routeurs, deux pairs BGP qui communiquent (sécurité du canal). Ensuite (sections 6 à 11), la protection des informations de routage échangées, le contrôle de ce qui est distribué (sécurité des données).

Commençons par sécuriser le routeur (section 4). Il devrait idéalement être protégé par des ACL qui interdisent les connexions vers le port 179, celui de BGP, sauf depuis les pairs connus. Les protections de TCP ne suffisent pas forcément, la mise en œuvre de TCP dans les routeurs est parfois faite de telle façon qu'on peut planter le routeur juste en envoyant plein de demandes de connexion. Il faut donc les jeter avant même que TCP ne les voit.

[...]

Certains routeurs permettent également de mettre en place un limiteur de trafic, pour éviter du trafic excessif, même en provenance de pairs connus.

[...]

Ensuite (section 5 du RFC), la protection des sessions BGP avec les pairs légitimes (cf. RFC 6952). Si les deux routeurs ne prennent aucune précaution, un attaquant pourrait, par exemple, couper leur session BGP en envoyant de faux paquets TCP de type RST (cf. RFC 5961). Pire, il pourrait, avec des techniques comme l'usurpation ARP, injecter de faux paquets dans une session BGP existante. Pour se protéger contre les attaques TCP, il faut utiliser une authentification TCP, comme la traditionnelle (et bien dépassée) TCP-MD5 du RFC 2385. [...] En outre, MD5 étant désormais bien affaibli (RFC 6151), il faudrait désormais utiliser le mécanisme AO du RFC 5925. Le RFC note que, malgré le caractère antédiluvien de TCP-MD5, c'est toujours la solution la plus utilisée par les opérateurs.

[...]

Autre précaution, filtrer les paquets IP en entrée du réseau de l'opérateur pour interdire les paquets prétendant avoir une adresse IP source située dans le réseau de l'opérateur. Sans cette précaution, même les sessions iBGP pourraient être attaquées.

[...]

Dernière protection des sessions BGP, GTSM (RFC 5082) qui consiste à tester que le TTL des paquets entrants est à la valeur maximale (255), et que le paquet vient donc bien du réseau local (s'il était passé par, ne serait-ce qu'un seul routeur, le TTL aurait été décrémenté).

[...]

Sécuriser la session ne sert à rien si le pair légitime et authentifié nous envoie des informations fausses. La section 6 de notre RFC se consacre donc au filtrage des préfixes annoncés. D'abord, les préfixes non routables (ceux marqués Global: false dans le registre des adresses spéciales IPv4 ou son équivalent IPv6) devraient évidemment être rejetés. Mais il est également recommandé de ne pas accepter les préfixes non alloués (par le système d'allocation d'adresses IP IANA->RIR->LIR). Comme la liste de ces préfixes change tout le temps, les filtres doivent être mis à jour automatiquement, à partir de la liste à l'IANA.

[...]

Tester auprès de l'IANA ne permet que des filtres grossiers, éliminant les annonces de préfixes non alloués à un RIR, ce qui ne sert que pour IPv6, ne vérifie pas les préfixes plus spécifiques que ce que l'IANA alloue, et n'empêche pas un malveillant ou un maladroit d'annoncer les préfixes d'un autre AS. Il peut donc être intéressant de filtrer de manière plus précise, en regardant les IRR. [...] Des outils existent pour produire automatiquement des filtres sur le routeur à partir du RPSL (comme IRRToolSet). Malheureusement, aucun IRR n'est parfait (et certains sont vraiment imparfaits) : préfixes absents (surtout les plus spécifiques, en cas de dés-agrégation des annonces), information dépassée, etc. Les IRR des RIR sont proches des opérateurs et donc a priori ont une information fiable mais ce n'est que théorique (les préfixes IP « du marais », alloués avant l'existence des RIR, sont une source particulièrement importante de problèmes). En outre, l'IRR d'un RIR ne couvre que la région de ce RIR, et on peut donc avoir besoin d'en consulter plusieurs (on a un pair états-unien, on regarde la base de l'ARIN, mais ce pair a des clients sud-américains et on doit donc aussi regarder la base de LACNIC...), ce qui justifie les IRR privés, comme RADB, qui essaient de consolider l'information des RIR.

[...]

Dans le futur, il est possible qu'un système plus fiable soit adopté et déployé, le couple RPKI+ROA, alias SIDR pour Secure Inter-Domain Routing. SIDR repose sur une infrastructure de certification, la RPKI (RFC 6480), et sur des objets signés, les ROA (RFC 6482), annonçant quel AS peut annoncer tel préfixe.

[...]

D'autres filtrages sont possibles en entrée. Par exemple, les opérateurs filtrent les annonces trop spécifiques, afin notamment d'éviter la croissance indéfinie de leurs bases de données et tables de routage. Chacun choisit les valeurs quantitatives précises et il n'y a pas de consensus documenté sur ce point (on peut consulter les documents RIPE-399 et RIPE-532) mais on peut observer qu'un préfixe plus long que /24 en IPv4 et /48 en IPv6 a très peu de chances d'être accepté dans l'Internet.

Typiquement, on filtre aussi en entrée les annonces portant sur les préfixes internes. Normalement, ce n'est pas à nos voisins d'annoncer nos routes ! Autres préfixes souvent filtrés, les routes par défaut, 0.0.0.0/0 en IPv4 et ::0/0 en IPv6. Naturellement, les recommandations de filtrage dépendent du type d'appairage BGP : on ne filtre pas pareil selon qu'on parle à un pair, à un client ou à un transitaire (voir la section 6 du RFC pour tous les détails). Ainsi, pour reprendre le paragraphe précédent, sur la route par défaut, certains clients d'un opérateur demandent à recevoir une telle route et c'est tout à fait acceptable.

[...]

La section 7 est consacrée à une pratique très utilisée et très discutée, l'amortissement (damping). Lorsqu'une route vers un préfixe IP donné passe son temps à être annoncée et retirée, on finit par l'ignorer, pour éviter que le routeur ne passe son temps à recalculer ses bases de données. Pour réaliser cela, à chaque changement d'une route, on lui inflige une pénalité, et au bout d'un certain nombre de pénalités, on retire la route. Malheureusement, cette technique mène parfois à supprimer des routes et à couper un accès (voir RIPE-378). Avec de meilleurs paramètres numériques, comme recommandé par le RFC 7196 et RIPE-580, l'amortissement redevient utilisable et recommandable.

[...]

Autre technique de filtrage des erreurs, décrite en section 8, l'imposition d'un nombre maximum de préfixes annoncés par un pair BGP. S'il en annonce davantage, on coupe la session BGP. Un dépassement du nombre maximal est en effet en général le résultat d'une fuite, où, suite à une erreur de configuration, le routeur ré-annonce des routes reçues d'un autre. Parfois, c'est toute la DFZ qui est ainsi annoncée par accident aux pairs ! Notre RFC demande donc instamment qu'on limite le nombre de préfixes accepté pour une session BGP. Pour un pair sur un point d'échange, le seuil devrait être inférieur au nombre de routes de la DFZ (dans les 530 000 en IPv4 aujourd'hui, et 21 000 en IPv6), pour détecter les annonces accidentelles de toute la DFZ. On peut aussi avoir des seuils par pair, fondés sur le nombre de routes qu'ils sont censés annoncer. Pour un transitaire, par contre, le seuil doit être plus élevé que le nombre de routes dans la DFZ, puisqu'on s'attend à tout recevoir d'eux (mais une valeur maximale est quand même utile en cas de désagrégation intensive). Comme l'Internet change tout le temps, il faut réviser ces limites, et suivre les alertes [...]

Voyons d'abord le filtrage par chemin d'AS. Par exemple, un client d'un opérateur ne devrait pas annoncer des routes avec n'importe quels AS mais seulement avec un chemin comportant uniquement son propre AS (et, si le client a lui-même des clients, avec l'AS de ces clients secondaires). Si l'opérateur n'arrive pas à avoir une liste complète des AS qui peuvent se retrouver dans les chemins de ses clients, au moins peut-il limiter la longueur de ces chemins, pour éviter la ré-annonce accidentelle de routes. D'autre part, on n'accepte pas, dans le cas normal, de routes où un AS privé (64512 à 65534 et 4200000000 à 4294967294, voir RFC 6996) apparait dans le chemin. Conséquence logique, on n'annonce pas à ses voisins de routes avec des chemins d'AS qui incluent un AS privé, sauf arrangement spécifique. Et le chemin d'AS dans une annonce BGP doit toujours commencer par l'AS du voisin (sauf si on parle à un serveur de routes).

[...]

Quant au filtrage sur le routeur suivant (section 10 du RFC), il consiste à refuser une route si l'attribut BGP NEXT_HOP (RFC 4271, section 5.1.3) n'est pas l'adresse du voisin. Attention, ce test doit être débrayé si on parle à un serveur de routes, celui-ci ne souhaitant pas traiter les paquets IP. Idem (débrayage du test) si on fait du RTBH (RFC 6666). »