Enregistrement DNS de type CAA

Introduction

Défini en 2013 par la RFC6844, le CAA est un type d’enregistrement DNS qui permet aux propriétaires de sites de préciser quelles autorités de certification (CA) sont autorisées à émettre des certificats contenant leurs noms de domaine.

Quel est l’intérêt

Par défaut, chaque autorité de certification publique est autorisée à émettre des certificats pour tout nom de domaine dans le DNS public, à condition qu’elle valide le contrôle de ce nom de domaine.

L’enregistrement CAA offre aux détenteurs de domaines un moyen de réduire ce risque d’une émission de certificat non souhaitée en intégrant une étape de confirmation/refus aux autorités de certification dans leurs processus d’émission de certificat.

L’intérêt d’un tel système prend tout son sens suite à l’essor des certificats générés « à la volée ». Ces types de certificat sont émis sans aucune vérification sur le titulaire du domaine. Il est aisé de demander un certificat pour n’importe quel domaine.

L’enregistrement CAA permet donc au propriétaire d’un nom de domaine de spécifier les autorités de certification qu’il autorise à émettre un certificat.

Notez que l’utilisation de DNSSEC pour authentifier les enregistrements CAA est fortement recommandée mais non requise (RFC 6844, section 4.1). Du point de vue sécurité, vous devez absolument utiliser le DNSSEC pour obtenir une requête/réponse authentique des CA à votre serveur DNS.

Enfin, cet enregistrement n’est pas encore obligatoire, mais je vous encourage à le mettre en oeuvre avant de personnes malveillantes n’utilisent cet oubli à leur avantage.

Principe de fonctionnement

Quand une autorité de certification reçoit une demande de certificat, elle vérifie le domaine afin de déterminer si un enregistrement de type CAA existe. Si un enregistrement existe et que la CA est bien autorisée, alors l’autorité de certification génère le certificat. Si l’enregistrement CAA spécifie une CA différente, alors la génération du certificat est refusée. A ce jour, si l’enregistrement CAA n’existe pas, alors la CA est autorisée à générer le certificat.

Structure d’un enregistrement CAA

Chaque enregistrement CAA est constitué d’un octet « flag » et d’une paire étiquette-valeur appelée une propriété.

Plusieurs propriétés peuvent être associées au même nom de domaine en publiant plusieurs enregistrements CAA à ce nom de domaine.

Un seul « flag » est défini: le « issuer critical » est représenté par le bit le plus significatif de l’octet. S’il est activé (c’est-à-dire que l’entier résultant est égal ou supérieur à 128) l’autorité de certification qui n’est pas à même de comprendre ou de mettre en œuvre l’étiquette de cet enregistrement doit refuser de délivrer un certificat pour le domaine.

Outre le « flag », trois mots clés sont définis:

  • issue : autorise une autorité (via son nom de domaine spécifié dans le champ « value ») à délivrer des certificats pour le domaine sur lequel l’enregistrement pointe
  • issuewild : est similaire à issue et vise les émissions de certificats wildcard
  • iodef : indique un moyen pour les autorités de signaler une demande de certificat ou un souci avec celle-ci

Pour interdire l’émission d’un certificat, il faut spécifier « ; » comme valeur pour le mot clé issue ou issuewild.

Exemple de mise en oeuvre

Qui prend en charge l’enregistrement CAA ?

Si vous voulez publier un enregistrement CAA, le logiciel (ou le fournisseur) de DNS de votre domaine doit prendre en charge le CAA.
Le site https://sslmate.com/caa/support vous indique quels logiciels et fournisseurs DNS prennent en charge la CAA. En France, les 2 principaux fournisseurs, Gandi et OVH, supportent le CAA.

Mise en oeuvre

Pour illustrer notre exemple, nous allons utiliser le domaine example.com et l’autorité de certification Let’s Encrypt.
Le nom de domaine d’identification de Let’s Encrypt pour la CAA est letsencrypt.org.

Si votre fournisseur est répertorié, vous pouvez utiliser le générateur d’enregistrements CAA de sslmate pour générer un ensemble d’enregistrements CAA répertoriant les CA que vous souhaitez autoriser.

Voici les captures :

Enfin, vous publiez votre politique CAA en ajoutez les enregistrements CAA suivants au DNS de votre domaine. Votre DNS doit être hébergé par un service qui prend en charge la CAA.

Plusieurs formats sont rencontrés :
– générique (utilisé par Google Cloud DNS, Route 53, DNSimple, et les autres services DNS hébergés) :

Name Type Value
example.com. CAA 0 issue ";"
0 issuewild "letsencrypt.org"
0 iodef "mailto:support@example.com"
  • standard (utilisé par BIND ≥9.9.6, PowerDNS ≥4.0.0, NSD ≥4.0.1, Knot DNS ≥2.2.0) :
Name Type Value
example.com. IN CAA 0 issue ";"
example.com. IN CAA 0 issuewild "letsencrypt.org"
example.com. IN CAA 0 iodef "mailto:support@example.com"
  • legacy RFC 3597 (utilisé par BIND <9.9.6, NSD <4.0.1, Windows Server 2016) :
Name Type Value
example.com. IN TYPE257 \# 8 000569737375653B
example.com. IN TYPE257 \# 26 0009697373756577696C646C657473656E63727970742E6F7267
example.com. IN TYPE257 \# 33 0005696F6465666D61696C746F3A737570706F7274406578616D706C652E636F6D

Résolution des problèmes

Comment vérifier

Commande DIG

Une requête de test avec dig montre les enregistrements :

$ dig @1.1.1.1 celea.org caa +dnssec +multi +noauthority +noadditional

; <<>> DiG 9.16.1-Ubuntu <<>> @1.1.1.1 celea.org caa +dnssec +multi +noauthority +noadditional
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 45743
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 1232
;; QUESTION SECTION:
;celea.org. IN CAA

;; ANSWER SECTION:
celea.org. 1800 IN CAA 0 iodef "mailto:mathias@celea.org"
celea.org. 1800 IN CAA 0 issuewild "letsencrypt.org"
celea.org. 1800 IN CAA 128 issue "letsencrypt.org"
celea.org. 1800 IN RRSIG CAA 13 2 1800 (
20210520000000 20210429000000 7209 celea.org.
9CmiaEqazRE272NDI8SgfY4iaWFI+Du13j0bTDWAzsCn
H6Y4dI7VT2UfG/vWNuLdUPSpXGkhwee0MOSMoQJcFA== )

;; Query time: 96 msec
;; SERVER: 1.1.1.1#53(1.1.1.1)
;; WHEN: ven. mai 07 17:43:20 CEST 2021
;; MSG SIZE rcvd: 258

Services en ligne

Vous pouvez aussi utiliser un service en ligne https://caatest.co.uk/ :

Erreur CAA liée au fournisseur DNS

Avant l’émission d’un certificat, l’autorité de certification vérifie les enregistrements CAA. Parfois des erreurs sont renvoyées même pour des domaines n’ayant pas défini d’enregistrements CAA. Lorsqu’une erreur est obtenue, la CA ne peut pas savoir si elle est autorisée à émettre un certificat pour le domaine concerné. En effet, des enregistrements CAA pourrait être présents interdisant l’émission, mais qui ne sont pas visibles à cause de l’erreur.

Certains fournisseurs DNS qui ne sont pas familiers avec la CAA répondent initialement aux rapports de problèmes par « Nous ne prenons pas en charge les enregistrements CAA ». Votre fournisseur DNS n’a pas besoin de prendre spécifiquement en charge les enregistrements CAA. Il doit seulement répondre par une réponse NOERROR pour les types de requêtes inconnus (y compris le CAA). Renvoyer d’autres opcodes, y compris NOTIMP, pour les types de requête inconnus est une violation de la RFC1035, et doit être corrigé.

SERVFAIL

L’erreur les plus courantes rencontrée est SERVFAIL. Le plus souvent, cela indique un échec de la validation DNSSEC.
Si vous obtenez une erreur SERVFAIL, votre première étape devrait être d’utiliser un débogueur DNSSEC comme dnsviz.net. Si cela ne fonctionne pas, il est possible que vos serveurs de noms génèrent des signatures incorrectes uniquement lorsque la réponse est vide. Et les réponses CAA sont le plus souvent vides.

Si vous n’avez pas activé DNSSEC et que vous obtenez un SERVFAIL, la deuxième raison la plus probable est que votre serveur de noms faisant autorité a renvoyé NOTIMP, ce qui est une violation de la RFC1035. Il devrait plutôt renvoyer NOERROR avec une réponse vide. Si tel est le cas, contactez de votre fournisseur DNS.

Enfin, les SERVFAILs peuvent être causés par des pannes au niveau de vos serveurs de noms faisant autorité. Vérifiez les enregistrements NS de vos serveurs de noms et assurez-vous que chaque serveur est disponible.

Timeout

Parfois, les requêtes CAA n’aboutissent pas. Même après plusieurs tentative, le serveur de noms faisant autorité ne répond pas. Le plus souvent, cela se produit lorsque votre serveur de noms est protégé par un pare-feu mal configuré qui rejette les requêtes DNS avec des QTYPES inconnus. Contactez alors votre fournisseur DNS.

Les champs QTYPE apparaissent dans la partie question d’une requête. Les QTYPES sont un sur-ensemble de TYPEs, donc tous les TYPEs sont des QTYPEs valides

Surveillez votre domaine

Même si vous publiez un enregistrement CAA, une autorité de certification non conforme peut ignorer vos enregistrements CAA. Utilisez Cert Spotter pour surveiller les journaux de Certificate Transparency afin d’être averti si cela se produit.

OpNSense : configurer WireGuard VPN en vidéo

Une vidéo très bien faite expliquant l’installation et la configuration pas à pas du VPN Wireguard sur le firewall OPNSense.

2019-11-19: Critical FreePBX Security Vulnerability

Une vulnérabilité de sécurité critique découverte dans FreePBX permet l’exécution de code à distance sans authentification.

Les serveurs FreePBX en version 14 ou 15 sont automatiquement mises à jour. Par contre, les serveurs fonctionnant en version 12 ou 13 doivent-être mises à jour manuellement. Assurez-vous que votre serveur FreePBX est mis à jour avec les dernières versions  !

La vulnérabilité est corrigée dans:

  • (Version 12 inconnue pour le moment)
  • 13.0.197.14
  • 14.0.13.12
  • 15.0.16.27

Je me permets de vous rappeler qu’il est essentiel de tenir à jour ses serveurs et d’autant plus dans la VoIP qui est une cible particulièrement intéressante pour les assaillants !

Plus de détails sur la vulnérabilité sont disponibles sur le wiki de FreePBX.

Comment sécuriser Django, framework python

Comment sécuriser une application web avec le framework python Django ?

Tout le monde est maintenant conscient de l’importance de délivrer ou utiliser un service web fortement sécurisé. Il est indispensable de protéger les données stockées dans les bases de données, valeurs inestimables, et assurer la confidentialité des échanges.

L’utilisation d’un framework comme Django permet de partir sur des bonnes bases. Mais nous allons voir qu’il est nécessaire de paramétrer finalement celui-ci.

Comment sécuriser Django ?

Je vais me servir d’un exemple concret, l’application PyFreeBilling dont je suis le créateur. PyFreeBilling est une application complète de VoIP (fonctionnalités de class 4 pour les connaisseurs) permettant à un opérateur télécom ou à une entreprise de services de connecter des clients et des fournisseurs, de router les appels, d’appliquer un tarif selon le type d’appel ainsi que l’ensemble des tâches nécessaires à cette activité.

L’exemple est intéressant du point de vue de la criticité de l’application. Une solution de communications de VoIP doit-être fortement sécurisée. Les risques de fraudes, de divulgation d’informations ou de perte de services sont importants. Un serveur à peine déployée subit ses premières attaques au bout de quelques minutes ceci étant aidé par des frameworks permettant d’automatiser les attaques.

L’interface de gestion de PyFreeBilling est développée avec le framework Django.

Pourquoi sécuriser Django ?

La sécurisation de l’interface d’administration est essentielle. Elle permet de gérer a création et la suppression de comptes SIP, la modification de mots de passe, l’augmentation des limites comme le nombre d’appels simultanés ou le volume d’appels journaliers. Un système d’anti-fraude peut ainsi être facilement détourné, un compte utilisateur pirate créé et des routes créées. Un assaillant peut aussi récupérer les données des accès opérateurs ou la base clients.

Les risques

Je vais maintenant présenter les types d’attaque les plus courantes et puis montrer comment avec Django mettre en oeuvre des solutions afin de limiter le risque.
L’OWASP est une communauté spécialisée dans la sécurité des applications web. Ils proposent notamment des outils afin de tester la sécurité des applications web. Un projet va particulièrement nous intéresser : OWASP Application Security Verification Standard (ASVS) . Je vous engage notamment à lire les cheatsheets mises à disposition.
Voici le top ten des risques définis par l’OWASP (les liens conduisent à la page détaillant chaque item) :

Mise en oeuvre des contre-mesures

Maintenant que nous avons identifié les risques et nous avons une base documentaire solide sur laquelle nous appuyer, nous allons voir les contre-mesures pour sécuriser Django.

Les injections

Tout d’abord, nous allons voir les injections SQL. Django fournit un ORM qui permet de se protéger de ce risque en échappant les variables avant de soumettre la requête à la base de données. A la condition, de ne pas utiliser la fonction RawSQL permettant d’utiliser du code SQL natif. Dans ce cas, c’est au développeur de valider les variables utilisées dans la requête !
Attention : l’ORM ne dispense pas de valider les variables, c’est une bonne pratique !

L’authentification

Nous allons retrouver plusieurs sous parties.
Tout d’abord, nous allons voir comment se protéger des attaques par brute force.
Pour se protéger des attaques que subissent constamment les pages de login, les attaques par brute force, j’utilise le package django-axes . Il permet de bloquer une adresse IP après un nombre prédéfini de tentatives infructueuses. La configuration par défaut est très satisfaisante, mais je vous invite à lire la documentation de django-axes afin de tuner votre configuration selon vos souhaits, notamment si vous avez besoin de whitelister quelques adresses IP.
Toutes les tentatives sont accessibles via l’interface d’administration incluant les adresses IP, les navigateurs, les noms d’utilisateurs utilisés …
En complément, un honeypot est intégré afin de détecter les robots malveillants testant la page /admin, page identique à la vraie page de connexion ! Toute tentative est ainsi bloquée en amont. Pour cela, j’utilise le package django-admin-honeypot.
Le second point, concerne la robustesse des mots de passe. Très souvent les utilisateurs utilisent des mots de passe trop simples. Afin, de renforcer la complexité des mots de passe, Django intègre des validateurs de mots de passe, dont voici un exemple de configuration :
AUTH_PASSWORD_VALIDATORS = [
{
'NAME': 'django.contrib.auth.password_validation.UserAttributeSimilarityValidator',
},
{
'NAME': 'django.contrib.auth.password_validation.MinimumLengthValidator',
'OPTIONS': {
'min_length': 9,
}
},
{
'NAME': 'django.contrib.auth.password_validation.CommonPasswordValidator',
},
{
'NAME': 'django.contrib.auth.password_validation.NumericPasswordValidator',
},
]
Nous allons tout d’abord vérifier que le mot de passe n’est pas trop similaire avec un attribut de l’utilisateur, puis que la longueur minimum est de 9 (je suggère d’augmenter cette valeur), ensuite nous allons vérifier s’il ne fait pas partie d’une liste de mots de passe couramment utilisés et que le mot de passe n’est pas entièrement composé de chiffres. Par ailleurs, il est aussi possible d’intégrer son propre validateur en plus de ceux prédéfinis par Django.
Le stockage du mot de passe en base de données doit aussi être particulièrement surveillé.
Django ne stocke heureusement pas les mots de passe en clair dans la base de données, mais un hash de celui-ci. Nous avons la flexibilité d’utiliser les méthodes de hachage de notre choix, mais dans une liste réputée sécurisée. Par défaut, c’est l’algorithme PBKDF2 avec un hash SHA265.
PyFreeBilling utilise l’algorithme Argon2 étant réputé plus sécurisé.
Il est possible et souhaitable d’activer une double authentification (two-factor authentication). Dans PyFreeBilling, cette fonctionnalité est optionnelle, car selon le type de déploiement, la mise en oeuvre sera plus ou moins complexe. Mais je recommande très fortement la prise en considération de cette fonctionnalité qui va renforcer sensiblement l’application. Pour cela, l’application django que je recommande est django-two-factor-auth qui intègre de nombreux services. Je ne vais pas détailler ici la mise en oeuvre, un article entier serait nécessaire. Je vous encourage à lire la documentation qui est bien faite.

Exposition de données sensibles

Il est essentiel de s’assurer qu’aucune donnée sensible ne puisse être interceptée.
Tout d’abord la mise en oeuvre du protocole HTTPS afin de garder confidentielles les données échangées est indispensable.
Par défaut, Django autorise les échanges via le protocole HTTP, mais pour des raisons évidentes, l’accès à l’interface d’administration de PyFreeBilling est forcée en HTTPS.
Pour cela nous allons forcer le navigateur l’utilisation du protocole HTTPS en activant l’entête HTTP Strict Transport Security ou HSTS.
Django définit cet en-tête pour vous sur toutes les réponses HTTPS si vous définissez le réglage SECURE_HSTS_SECONDS à une valeur entière différente de zéro.
Voici les paramètres correctement configurés :
  • SECURE_HSTS_SECONDS = 15768000 # 6 mois
  • SECURE_HSTS_INCLUDE_SUBDOMAINS = True
  • SECURE_HSTS_PRELOAD = True
Définissez aussi le paramètre SECURE_SSL_REDIRECT sur True, ainsi toutes les demandes non SSL seront redirigées de manière permanente vers SSL.
Ensuite, nous allons intégrer des entêtes HTTP afin d’activer des paramètres de sécurité embarqués dans les navigateurs modernes (et oui, il faudrait bloquer les vieux navigateurs troués comme de vieux torchons).
Anti-click jacking :
Le principe est d’interdire l’affichage d’une page de notre interface d’administration dans une frame. Django possède nativement les protections, mais qu’il faut activer correctement via les variables suivantes :
Tout d’abord il faut activer le middleware « django.middleware.clickjacking.XFrameOptionsMiddleware » afin d’ajouter l’entête X-FRAME-OPTIONS à toutes les réponses.
Par défaut, la valeur de l’entête X-Frame-Options est à SAMEORIGIN, mais il est possible de forcer à DENY ce qui est fait pour l’administration de PyFreeBilling. Ainsi, on interdit au navigateur d’intégrer nos pages dans une iFrame.
Entête CSP :
Les entêtes Content Security Policy ou CSP permet de contrôler la manière dont les ressources sont inclues dans la page.
Afin de gérer ces entêtes, le package django-csp est utilisé (https://github.com/mozilla/django-csp). Il permet de paramétrer très finement nos ressources.
Tout d’abord nos devons activer le middleware « csp.middleware.CSPMiddleware » et ensuite définir les valeurs souhaitées pour les paramètres.
Le choix fait pour PyFreeBilling est de n’utiliser aucune ressources externes pour des raisons de sécurité, mais aussi afin de pouvoir fonctionner sans accès internet (c’est le cas de certains clients). Le paramétrage des entêtes CSP est ainsi simplifié. Pour comprendre en détail les différentes valeurs, je vous engage à lire les spécifications CSP puis la documentation de django-csp.
Protection XSS :
Définissez le paramètre SECURE_BROWSER_XSS_FILTER sur True afin d’activer les protections de filtrage XSS du navigateur.
Entête X-Content-Type-Options :
Enfin, il est avisé d’empêcher le navigateur de déterminer le type de fichier en ajoutant un entête X-Content-Type-Options. Pour cela Django dispose d’une variable (à False par défaut) qu’il faut passer à True : SECURE_CONTENT_TYPE_NOSNIFF (https://docs.djangoproject.com/en/2.1/ref/settings/#secure-content-type-nosniff)

XML entités externes

Je ne vais pas traiter de cette partie, n’utilisant pas ce type de fonctions dans PyFreeBilling. Si vous souhaitez l’utiliser, vous devez soit écrire le code ou utiliser une librairie. Je vous invite à lire la documentation associée et utiliser les éléments de filtrage proposés nativement par Django.
Vous pouvez apporter des éléments en commentaire du présent article pour les futurs lecteurs (je compléterais à l’occasion cette partie)

Broken accès control

Django propose de base une gestion des utilisateurs et des groupes d’utilisateurs. Des décorateurs permettent de définir l’accès à une ressource donnée avec des droits différents : lecture, modification, création … .
Il est aussi possible de définir plus finement l’accès. Un package très utilisé est django-braces.
D’autres plugins permettent de gérer plus finement par objet ou par certains attributs. Dans tous les cas, c’est de la responsabilité du développeur d’utiliser correctement ces outils et de tester les accès suivant les différents typologies d’utilisateurs.

Mauvaises configuration de sécurité

C’est l’objet de l’article de pointer sur les points d’attention lors du paramétrage d’un projet Django. Il existe des outils afin de valider que rien n’a été oublié.
Je vous en propose 2 :
FreesScan de Qualys qui va permettre de tester en profondeur votre site avec un rapport  précis. Il va tester les certificats et la configuration du serveur web. Voici la note obtenue par un déploiement de PyFreeBilling de base sous docker :
Tous les éléments ne sont pas testés, mais ça permet de valider rapidement notre déploiement.
Et l’Observatory, outil de Mozilla permettant de vérifier de nombreux points de sécurité : il valide la sécurité des en-têtes OWASP, les meilleures pratiques TLS et effectue des tests tiers à partir de SSL Labs, High-Tech Bridge, des en-têtes de sécurité, du préchargement HSTS, etc. Il est particulièrement complet et aussi très instructif.

Cross-Site Scripting (XSS)

C’est une des failles visant le navigateur des utilisateurs. Nous allons voir comment des paramètres Django vont pouvoir nous prémunir contre elles, sachant que les outils automatisées savent les détecter et les exploiter !
Nous avons déjà vu dans la section « exposition de données sensibles » en ajoutant des entêtes HTTP en ajoutant des paramètres nous protégeant de failles XSS. Nous allons voir comment nous protéger du vol de sessions.
Il s’agit de bloquer l’accès à un code javascript exécuté dans le navigateur par un assaillant au cookie de session . Pour cela, nous allons forcer l’envoi de l’entête httpOnly transmise avec le cookie.

Les sessions sont gérées par le middleware : ‘django.contrib.sessions.middleware.SessionMiddleware’, et l’activation de l’entête est faite par la variable SESSION_COOKIE_HTTPONLY (https://docs.djangoproject.com/en/2.1/ref/settings/#std:setting-SESSION_COOKIE_HTTPONLY).
Explication de la team django : ‘It’s recommended to leave the SESSION_COOKIE_HTTPONLY setting on True to prevent access to the stored data from JavaScript.’
Afin de renforcer la sécurité des cookies, nous allons modifier 2 paramètres :
Enfin, nous allons forcer l’échange de cookies uniquement via une connexion HTTPS : la configuration par défaut est à False. Pour forcer l’échange via HTTPS, il faut mettre SESSION_COOKIE_SECURE à True.
La doc de référence de Django pour les sessions : https://docs.djangoproject.com/en/2.1/topics/http/sessions/

Insecure Deserialization

Je vais faire la même remarque que pour le traitement de document XML.

Utiliser des composants incluant des vulnérabilités connues

Django étant un framework python, vous avez plusieurs outils vous permettant d’être notifié quand une dépendance est mise à jour. Mais surtout, certains outils peuvent envoyer une notification quand une dépendance utilisée contient une faille de sécurité. J’utilise PyUp pour cela. Ils annoncent surveiller 173 000 dépendances python !

Si votre projet utilise aussi du code qui n’est pas écrit en python, ce qui est souvent le cas comme du javascript, d’autres outils existent. Pour ce javascript, npmjs ou Retire.js pourront vous être très utiles. Retire.js propose même des extensions pour Chrome et Firefox !

OWASP dispose aussi d’un outil pouvant être intégré dans votre Jenkins préféré appelé OWASP Dependency Check. Il supporte actuellement les langages Java, .NET, Ruby, Node.js, Python et partiellement C++.

Insufficient Logging&Monitoring

Il est en effet essentiel de logger les erreurs mais surtout de les traiter. Django propose des outils de génération de logs poussés. Une section dédiée à la génération de logs liés à la sécurité : https://docs.djangoproject.com/en/2.1/topics/logging/#django-security.

Pour un gros projet, un outil comme Sentry qui s’intègre parfaitement avec Django est un très intéressant.

Et pour surveiller votre application Django, les packages de monitoring sont listés dans https://djangopackages.org/grids/g/monitoring/

Conclusion

Nous avons vu au cours de cette article que la sécurisation d’une application web est une tâche complexe nécessitant de bien connaître les risques. Un framework puissant comme Django, à condition de bien le maîtriser, nous facilite la tâche.

Et pour finir, je vais vous partager un dernier truc afin d’améliorer la sécurité de notre projet Django : restreindre l’accès à toutes ou certaines URL à une ou plusieurs adresses IP.

Pour cela, le package django-iprestrict est l’outil adéquate. Afin de bloquer/autoriser l’accès à partir de région ou pays, geoip2 sera utilisé. Tout d’abord, il faut activer le middleware « iprestrict.middleware.IPRestrictMiddleware ». Le paramétrage se fait ensuite dans l’interface d’administration.

Et surtout pour sortir sécuriser Django correctement, sinon tous vos efforts auront été vains, assurez-vous d’utiliser un SECRET_KEY long, aléatoire et unique !

Si vous avez des remarques ou des packages intéressants à partager afin d’améliorer la sécurité d’un projet Django, les commentaires sont à votre disposition.

 

OpnSense : sortie de la version 1.9.1

L’équipe d’OpnSense vient d’annoncer la nouvelle version de leur parefeu libre basé sur HardenedBSD.

Parmi les éléments les plus importants, la migration vers l’OS de base HardenedBSD en version 11.2. Pour ceux ne connaissant pas HardenedBSD et son intérêt pour un outil comme un firewall, voici un lien de comparif HardenedBSD avec FreeBSD, OpenBSD et NetBSD (cela vous permettra d’avoir un élément de comparaison en plus avec PFSense).

Voici les modifications les plus importantes depuis la version 18.7:

  • support du PIE firewall shaper
  • prise en charge de la journalisation des règles NAT par le pare-feu
  • 2FA via la combinaison LDAP-TOTP
  • WPAD / PAC et prise en charge du proxy parent dans le proxy Web
  • Exportation de certificat P12 avec mots de passe personnalisés
  • Dpinger est maintenant le moniteur de passerelle par défaut
  • support étendu IPv6 DUID
  • prise en charge de Dnsmasq DNSSEC
  • version du pilote Realtek NIC 1.95
  • HardenedBSD 11.2
  • LibreSSL 2.7
  • Unbound 1.8
  • Suricata 4.1
  • vérification de l’état du firmware étendue pour couvrir tous les fichiers du système d’exploitation, miroir HTTPS par défaut
  • les mises à jour tiennent compte du cache du navigateur en ce qui concerne les actifs CSS et JavaScript
  • nouveaux plugins :
    • pour l’exportation de sauvegarde via API
    • Bind
    • widget Matériel
    • Nginx
    • Ntopng
    • VnStat
    • Dnscrypt-proxy

Pour télécharger et tester la nouvelle version, c’est par là : https://opnsense.c0urier.net/releases/19.1/

Avant d’effectuer une mise à jour d’un équipement existant, je vous invite à lire les notes de migrations !

Plus d’infos sur la nouvelle version d’OpnSense 1.9.1 ici.

Les nouveautés sont intéressantes, notamment la prise en charge de DNSSEC essentiel dans la protection de nos réseau et la migration vers Hardened BSD en version 11.2. Quelles sont les fonctionnalités que vous attendez d’OpnSense encore manquante ?

RTPBleed et Asterisk : les appels d’Asterisk sous écoute

Asterisk souffre d’un problème assez grave permettant à un attaquant d’écouter simplement vos conversations. Une attaque de l’homme du milieu (man-in-the-middle), sans être vraiment au milieu d’ailleurs, permet de redirriger les flux RTP assez facilement.

Asterisk souffre d’un problème assez grave permettant à un attaquant d’écouter simplement vos conversations. Une attaque de l’homme du milieu (man-in-the-middle), sans être vraiment au milieu d’ailleurs, permet de rediriger les flux RTP assez facilement.

L’annonce a été faite il y a quelques jours (31/08/2017). Il s’agit en fait d’un vieux bug datant de 2011 qui a été réintroduit au premier trimestre 2013. Le premier report annonçant la régression date de mai dernier ainsi que le patch (fournit pour test). L’annonce officielle a été faite le 31 août dernier.

Quelles sont les versions vulnérables ?

Toutes les versions d’Asterisk entre la 11.4.0 à la 14.6.1 sont malheureusement touchées.

Dans quel cas le serveur Asterisk est vulnérable ?

Quand le serveur Asterisk fonctionne avec des postes derrière un routeur NAT, il est nécessaire de mettre en oeuvre des actions afin de router correctement les paquets voix. Le protocole SIP s’appuie sur le protocole RTP afin de transporter la voix et le protocole SDP afin que les user-agents (UA) puissent négocier entre eux des éléments comme les codecs, adresses et ports. Ces éléments sont échangés en clair sur le réseau.
Pour permettre ces négociations, le serveur Asterisk est configuré (fichier sip.conf) avec les options nat=yes et strictrtp=yes. De plus, ces options sont configurées ainsi par défaut !

Comment exploiter la faille ?

Un attaquant doit envoyer des paquets RTP au serveur Asterisk sur un port alloué pour recevoir un flux RTP. Si le serveur est vulnérable, alors le serveur Asterisk répond à l’assaillant en relayant les paquets RTP du destinataire véritable. Il est ensuite aisé avec des outils comme Wireshark de décoder le flux audio.

Quelles sont les actions de mitigation envisageable ?

  • La première recommandation est de ne pas transporter les flux SIP et RTP sur internet en clair, mais d’utiliser un tunnel VPN. Si cela n’est pas possible pour diverses raisons bonnes ou mauvaises, voici d’autres solutions :
  • application du patch fournit par Asterisk (https://raw.githubusercontent.com/kapejod/rtpnatscan/master/patches/asterisk/too-short-rtcp-bugfix.diff) qui actuellement limite la fenêtre temps de l’attaque aux toutes premières millisecondes.
  • éviter l’option nat=yes si possible
  • chiffrer les flux RTP avec SRTP (je vous invite aussi à chiffrer les flux SIP et à utiliser le protocole de transport TCP uniquement pour ce dernier afin de fiabiliser les échanges au lieu de l’UDP)
  • ajouter une option de configuration à vos peers SIP afin de prioriser les paquets RTP venant de l’adresse IP apprises au travers de l’échange initial effectué via le protocole SIP.

Par ailleurs, si vos postes IP et vos fournisseurs de trunk SIP utilisent des adresses IP fixes et connues, la mise en oeuvre d’une règle sur votre firewall bloquant l’accès aux ports UDP 10000 à 20000 (ports RTP utilisés par défaut par un serveur Aterisk) uniquement à partir de ces adresses apporte une protection suffisante.

Comment vérifier si mon serveur Asterisk est vulnérable ?

L’outil rtpnatscan permet de tester votre serveur Asterisk.

Références :

pfSense 2.3.2 est disponible

La version 2.3.2 de PFSense, distribution open source de sécurité, avec 60 bugs corrigés, vient d’être libérée. Vous pouvez en savoir plus sur la publication de mise à jour de la version 2.3.2 sur le blog de pfSense. Pensez à mettre à jour vos appliances.

Comment sécuriser Firefox avec quelques paramètres dans about:config ?

Il est essentiel de paramétrer finalement son navigateur afin de s’assurer un surf plus sécurisé. Je vais vous présenter les différentes options essentielles à modifier. Je n’aborderai pas l’usage de modules complémentaires (peut-être le sujet d’un prochain article).

Pour entrer dans la configuration avancée de Firefox, il suffit d’entrer dans la barre d’adresse about:config et de taper sur la touche d’entrée. Lisez bien l’alerte, puis validez (si vous êtes OK).

Firefox about:config

Puis vérifiez, les paramètres de security.tls.version afin que les valeurs soient celles-ci (min à 1 et max à 3):

security tls version firefox
security tls version firefox

 

Ensuite, modifiez :

  • geo.enabled à False afin de supprimer la géolocalisation
  • network.http.sendRefererHeader à 1 afin de ne communiquer que la dernière page visitée – Cela semble poser des problèmes (cf commentaires). Explication des valeurs de la variable network.http.sendRefererHeader :
    • 0 – never send the referring URL.
    • 1 – send only when links are clicked.
    • 2 – send for links and images (default).
  • browser.safebrowsing.malware.enabled à False et supprimez les données de browser.safebrowsing.provider.google.lists afin d’éviter que Google vous profile. (Je vous recommande de lire ce lien https://feeding.cloud.geek.nz/posts/how-safe-browsing-works-in-firefox/ expliquant le fonctionnement de cette option. Merci à Barmic pour la contribution)
  • offline-apps.allow_by_default à False et offline-apps.quota.warn à 0 afin que les données offline ne soient utilisées à votre insu

N’oubliez pas de modifier les préférences par défaut afin d’éviter d’être pisté et d’accepter les cookies tiers inutiles.

Vous pouvez tester votre navigateur en utilisant ces sites : https://panopticlick.eff.org et http://ghacks.net/ip/ (teste l’IP, le referer et le navigateur)

Je mettrai à jour cette page afin de tenir compte des évolutions de Firefox. N’hésitez pas à contribuer pour la sécurité de tous.

Historique de modifications de la page :

  • 22/08/2016 : changement de la valeur network.http.sendRefererHeader à 1 au lieu de 0, car cela bloque les réponses aux forums et empêche l’identification sur certains sites !
  • 24/08/2016 : ajoût du lien d’explication du fonctionnement de l’option browser.safebrowsing.malware.enabled – Contribution de Barmic
  • 01/09/2016 : suppression de la modification de network.http.sendRefererHeader (la valeur par défaut est à 2)
  • 02/09/2016 : ajoût du site ghacks pour tester son navigateur

Quelles traces laissent mon navigateur sur internet ?

Nous savons tous que nos visites sur les différents sites web sur les internets laissent de nombreuses traces, mais savons nous réellement lesquelles ?

Voici 2 petits sites afin de vous aider à voir une partie de celles-ci (et oui, nos navigateurs sont très bavards) :

http://www.anonymat.org/vostraces/index.php

et bien sûr la CNIL

Il ne vous reste plus qu’à paramétrer au mieux votre navigateur … et vos ordinateurs, smartphones et tablettes ! bon courage.

Règles iptables afin de bloquer les scanners SIP

Les serveurs SIP (Asterisk, FreeSwitch … mais aussi les serveurs propriétaires) sont constamment scannés par des automates ou des humains avec pour seule idée, découvrir une faille à exploiter. En effet, les enjeux financiers sont importants.
Je partage avec vous ce jour, un script iptables pour bloquer les scanners SIP (à adapter notamment les ports si vous utilisez des différents de 5060).

iptables -N SIPDOS

iptables -A INPUT -i eth0 -p udp -m udp –dport 5060 -m string –string “sundayddr” –algo bm –to 65535 -m comment –comment “deny sundayddr” -j SIPDOS
iptables -A INPUT -i eth0 -p udp -m udp –dport 5060 -m string –string “sipsak” –algo bm –to 65535 -m comment –comment “deny sipsak” -j SIPDOS
iptables -A INPUT -i eth0 -p udp -m udp –dport 5060 -m string –string “sipvicious” –algo bm –to 65535 -m comment –comment “deny sipvicious” -j SIPDOS
iptables -A INPUT -i eth0 -p udp -m udp –dport 5060 -m string –string “friendly-scanner” –algo bm –to 65535 -m comment –comment “deny friendly-scanner” -j SIPDOS
iptables -A INPUT -i eth0 -p udp -m udp –dport 5060 -m string –string “iWar” –algo bm –to 65535 -m comment –comment “deny iWar” -j SIPDOS
iptables -A INPUT -i eth0 -p udp -m udp –dport 5060 -m string –string “sip-scan” –algo bm –to 65535 -m comment –comment “deny sip-scan” -j SIPDOS
iptables -A INPUT -i eth0 -p udp -m udp –dport 5060 -m string –string “User-Agent: sipcli” –algo bm –to 65535 -m comment –comment “deny sipcli” -j SIPDOS
iptables -A INPUT -i eth0 -p udp -m udp –dport 5060 -m string –string “User-Agent: Nmap NSE” –algo bm –to 65535 -m comment –comment “deny Nmap NSE” -j SIPDOS
iptables -A INPUT -i eth0 -p udp -m udp –dport 5060 -m string –string “User-Agent: VaxSIPUserAgent” –algo bm –to 65535 -m comment –comment “deny VaxSIPUserAgent” -j SIPDOS
iptables -A INPUT -i eth0 -p udp -m udp –dport 5060 -m string –string “From: sipp <sip:” –algo bm –to 65535 -m comment –comment “deny sipp” -j SIPDOS

iptables -A INPUT -i eth0 -p tcp -m tcp –dport 5060 -m string –string “sundayddr” –algo bm –to 65535 -m comment –comment “deny sundayddr” -j SIPDOS
iptables -A INPUT -i eth0 -p tcp -m tcp –dport 5060 -m string –string “sipsak” –algo bm –to 65535 -m comment –comment “deny sipsak” -j SIPDOS
iptables -A INPUT -i eth0 -p tcp -m tcp –dport 5060 -m string –string “sipvicious” –algo bm –to 65535 -m comment –comment “deny sipvicious” -j SIPDOS
iptables -A INPUT -i eth0 -p tcp -m tcp –dport 5060 -m string –string “friendly-scanner” –algo bm –to 65535 -m comment –comment “deny friendly-scanner” -j SIPDOS
iptables -A INPUT -i eth0 -p tcp -m tcp –dport 5060 -m string –string “iWar” –algo bm –to 65535 -m comment –comment “deny iWar” -j SIPDOS
iptables -A INPUT -i eth0 -p tcp -m tcp –dport 5060 -m string –string “sip-scan” –algo bm –to 65535 -m comment –comment “deny sip-scan” -j SIPDOS
iptables -A INPUT -i eth0 -p tcp -m tcp –dport 5060 -m string –string “User-Agent: sipcli” –algo bm –to 65535 -m comment –comment “deny sipcli” -j SIPDOS
iptables -A INPUT -i eth0 -p tcp -m tcp –dport 5060 -m string –string “User-Agent: Nmap NSE” –algo bm –to 65535 -m comment –comment “deny Nmap NSE” -j SIPDOS
iptables -A INPUT -i eth0 -p tcp -m tcp –dport 5060 -m string –string “User-Agent: VaxSIPUserAgent” –algo bm –to 65535 -m comment –comment “deny VaxSIPUserAgent” -j SIPDOS
iptables -A INPUT -i eth0 -p tcp -m tcp –dport 5060 -m string –string “From: sipp <sip:” –algo bm –to 65535 -m comment –comment “deny sipp” -j SIPDOS

iptables -A SIPDOS -j LOG –log-prefix “firewall-sipdos: ” –log-level 6
iptables -A SIPDOS -j DROP

Si vous avez des idées pour l’améliorer, toutes les suggestions sont les bienvenues, l’idée étant de faciliter la sécurisation des serveurs SIP au plus grand nombre.

Mises à jour :

  • 4 août 2016 : ajoût de règles + correction typo suite au commentaire de Ztur