Catégorie : How to / Guide

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.

SIP – PFSense : Comment résoudre une perte d’enregistrement

Les postes sont localisés sur un site et passe par internet pour accéder au serveur de téléphonie VoIP SIP qui est situé derrière un PFSense.

Vous constatez un défaut d’enregistrement de vos téléphones SIP pendant plusieurs minutes, ceux-ci affichant un message « No service » ou « prov. server failed ».

Vous devez surement faire face à un timeout d’état de la table NAT du firewall PFSense. En effet, ce timeout doit-être inférieur à la fréquence de ré-enregistrement des postes SIP !

Les délais d’expiration UDP par défaut dans PFSense sont trop faibles pour certains services VoIP. Si les téléphones fonctionnent principalement, mais se déconnectent de manière aléatoire, il faut modifier les options d’optimisation du pare-feu sur les mettant sur « Conservateur » sous Système> Avancé, onglet Pare-feu / NAT.

Un système de keep-alive (ou autrement un ping SIP avec un message OPTION) ou une réinscription sur le poste téléphonique pendant une durée plus faible, environ 20 à 30 secondes, peut également aider, et est souvent une meilleure solution.

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.

 

Yunohost : comment ajouter la liste des paquets de la communauté aux applications ?

/unohost permet d’installer simplement une solution d’auto-hébergement ciblant à la fois les particuliers mais aussi les petites entreprises afin de reprendre le contrôle de ses données : agenda, calendrier, fichiers, webmail …

Une liste d’applications installables facilement via l’interface web d’administration de Yunohost est disponible. Ces applications sont validées par le équipe de Ynuhost. Mais, de nombreuses applications fort intéressantes sont mises à disposition par la communauté. Il faut les installer en intégrant l’url du repos git de celle-ci. Pas très compliqué !  Mais, afin d’éviter d’aller rechercher sur le wiki de Yunohost les applications disponibles, il peut-être intéressant de les retrouver dans cette même page. Pour activer les applications Yunohost gérées par la communauté, il faut taper en ligne de commande :

sudo yunohost app fetchlist -n community -u https://yunohost.org/community.json

Vous avez maintenant accès à la liste des applications de Yunohost et celles fournies par la communauté. Cette astuce permet aussi de bénéficier des mises à jour des applications communautaires.

Notes de mise à jour de l’article :

  • 16/09/2016 : précision sur la mise à dispo des MAJ (merci à LJF pour sa contribution)

Dolibarr : email de relance des factures impayées

Comment créer un email de relance pour les facture en retard de paiement sous Dolibarr, logiciel de gestion libre pour les TPE, PME et associations.

Dolibarr est un logiciel de gestion open source réputé pour les TPE/PME et associations permettant la gestion de la facturation. Il est aisé grâce à une fonction intégrée facilement appelable via un bouton, d’envoyer une facture à un contact par email. Dans une ancienne version, un bouton équivalent permettait de relancer les factures en retard de paiement par email,  facture par facture. Ce bouton a maintenant disparu !

Nous allons voir comment, sans toucher au code (sauf pour l’ajout d’éléments complémentaires), intégrer simplement une fonction de relance de facture en retard de paiement par email.

Pour cela, nous allons utiliser les modèles d’email, utilisables pour les factures clients mais aussi pour les commandes, propales … Ainsi, il nous suffira de choisir le bon modèle dans la liste déroulante juste au dessus du mail, afin de sélectionner le texte adéquat.

Premièrement, des messages d’envoi d’emails sont prédéfinis. Ils sont disponibles dans le dossier des langues de dolibarr /htdocs/langs/fr_fr/other.lang . Nous retrouvons notre modèle d’envoi de facture par email mais aussi, avec surprise, le modèle de relance de facture par email.

Nous allons donc créer un nouveau modèle. Pour cela, il faut aller dans Accueil -> configuration -> dictionnaires -> modèles des courriels , puis renseigner les différents éléments : libellé (champs définissant le modèle dans liste déroulante, par exemple Relance_facture), type de modèle (« pour l’envoi de facture client » dans notre cas), privé (0, sinon juste vous pourrez utiliser ce modèle), la position dans la liste déroulante (1, c’est votre premier modèle), le sujet (par ex : Relance de la facture REF ), et enfin le content (par ex : Bonjour,\n\nNous voudrions vous avertir que le facture REF ne semble pas avoir été payée. Nous vous avons joins la dite facture comme rappel.\n\nCordialement\n\n__SIGNATURE__ ).

J’ai utilisé 2 variables REF qui sera remplacé par le numéro de facture, et SIGNATURE qui sera remplacé par … votre signature (bien penser à compléter votre signature dans votre profil d’utilisateur.

Voici la liste des variables disponibles pour les factures (elles sont définies dans le fichier htdocs/compta/facture.php ) :

$formmail->substit['__REF__'] = $object->ref;
$formmail->substit['__SIGNATURE__'] = $user->signature;
$formmail->substit['__REFCLIENT__'] = $object->ref_client;
$formmail->substit['__THIRDPARTY_NAME__'] = $object->thirdparty->name;
$formmail->substit['__PROJECT_REF__'] = (is_object($object->projet)?$object->projet->ref:'');
$formmail->substit['__PROJECT_NAME__'] = (is_object($object->projet)?$object->projet->title:'');
$formmail->substit['__PERSONALIZED__'] = '';
$formmail->substit['__CONTACTCIVNAME__'] = '';

Voici l’exemple d’un modèle d’email plus complet :

__CONTACTCIVNAME__,\n\n
Veuillez trouver ci-joint votre facture __REF__ d'un montant de __FACTOTALTTC__ € TTC.\n\n
Nous vous rappelons que cette facture doit être réglée avant le __FACDATELIMREG__ .\n\n
Vous en souhaitant bonne réception, nous vous prions de croire,__CONTACTCIVNAME__, en l'assurance de nos salutations distinguées.\n\n
__SIGNATURE__

Il faut noter que les 2 dernières variables, PERSONALIZED et CONTACTCIVNAME, qui sont pourtant utilisées dans les modèles de base, retournent une chaîne vide ! à vous de les compléter (je vous laisse un peu de taf).

J’utilise aussi des variables complémentaires qu’il nous faut créer. Pour cela,  il suffit d’ajouter en ligne 3942 dans le fichier htdocs/compta/facture.php (version 3.9.3), les variables personnalisées complémentaires :

$formmail->substit['__FACDATE__'] = date('d/m/Y',$object->date);
$formmail->substit['__FACTOTATTC__'] = number_format($object->total_ttc,2,',','');
$formmail->substit['__FACDATELIMREG__'] = date('d/m/Y',$object->date_lim_reglement);

A noter, qu’à chaque mise à jour, vos modifications seront écrasées et seront donc à refaire !

Il est aussi possible d’utiliser des extensions permettant de réaliser cette opération, mais aussi d’intégrer à Dolibarr un process complet de recouvrement. Je vous conseille Relance factures impayées v2, le plus complet, ou Rappel impayé facture, devis, adhérent (3.9.x) , deux outils intéressants, à des prix différents mais n’offrant pas les mêmes fonctionnalités.

Source : wiki dolibarr

Installation ou mise à jour de Dolibarr directement en SSH

Dolibarr est un formidable logiciel de gestion pour les TPE / PME. Je vous conseille fortement de le découvrir soit via la démo en ligne soit en l’installant sur votre serveur. Un livre sur Dolibarr est disponible afin de vous guider dans l’utilisation du logiciel (l’image est la couverture de ce livre).

La documentation d’installation de Dolibarr indique l’usage de Source forge pour l’installation via les sources. Comme beaucoup, je préfère gérer en ssh mes serveurs, et l’usage de Source Forge n’est pas top. Mais une solution simple est d’utiliser le repo de github et d’aller dans l’onglet « release », vous aurez ainsi les dernières versions en tar.gz !

Installation FreeSwitch sur Ubuntu automatisée

Installation automatisée de FreeSwitch à partir des sources sur Ubuntu/Debian

L’installation de FreeSwitch à partir des sources n’est pas une tâche bien compliquée. Il suffit de suivre le guide expliquant le processus sur le site de FreeSwitch. Mais cette tâche est longue et si vous installez de manière régulière de serveurs FreeSwitch, cela devient vite répétitif et source d’erreur.

Je vais vous présenter une manière simple et automatique pour installer FreeSwitch sur votre serveur tout neuf Ubuntu 14.04 64 bits LTS. (Cela marche aussi pour Debian 7).

Voici le process d’installation FreeSwitch :

sudo apt-get install -y python-apt python-pycurl libtiff5-dev
sudo git clone https://github.com/mwolff44/freeswitch-mw.git
sudo echo localhost > inventory
sudo ansible-playbook -i inventory freeswitch-mw/test.yml --connection=local

Prenez un grand café, prenez votre temps pendant que vous voyez FreeSwitch se compiler et s’installer.

Vous pouvez personnaliser les modules à installer, pour cela il faut utiliser la variable « freeswitch_modules_template » pour pointer sur votre propre fichier. Je vous laisse découvrir les autres options sur le Readme de github pour le script freeswitch-mw.

 
Django : comment changer le mot de passe d’un utilisateur en ligne de commande
 
 
Comment changer le mot de passe d’un utilisateur dans un framework Django en ligne de commande ?
 
En fait c’est assez simple. Il faut ouvrir un shell python, importer le modèle User, récupérer l’objet correspondant à votre utilisateur, modifier l’attribut « password » et sauver l’objet.
 
Ne pas oublier d’activer l’environnement virtuel si nécessaire.
 
Voici le code correspondant à la description (n’oubliez pas de changer l’attribut « username » afin qu’il corresponde à votre utilisateur et le « password » bien sûr)
# Lancement du shell
python manage.py shell

# Le prompt change !!! >>>

# Chargement du modèle User
from django.contrib.auth.models import User

# Récupération de l'objet correspondant à notre utilisateur root
u = User.objects.get(username='root')

# Changement du mot de passe
u.set_password('mon_mot_de_passe_res_complique')

# Sauvegarde
u.save()

# On quitte le shell
exit()
Manipuler les objets Django en CLI via le shell n’est pas bien compliqué, mais terriblement utile et puissant.
  
FritzBox : fonctionnalités avancées de VoIP / SIP
Modification avancée des paramètres VoiP des routeurs FritzBox : codec, VAD, détection des silences …
 
 
Certaines FritzBox fournissent un service de standard téléphonique (IPBX). Vous pouvez raccorder une ligne analogique, numérique ou SIP à votre équipement ainsi que des postes SIP, analogique, numérique ou DECT. Les services fournis permet de répondre aux attentes des TPE sans aucun problème.
 
Il peut parfois être utile d’accéder aux paramètres avancées non accessibles via l’interface web. Nous allons voir comment. Tout d’abord, vous devez vous connecter via telnet à votre FritzBox. Si vous ne savez pas comment faire, je vous invite à lire ce post : comment activer le service telnet de ma FritzBox.
La configuration se fait dans un seul fichier, /var/flash/voip.cfg
Pour éditer ce fichier, il faut utiliser nvi :
 
nvi /var/flash/voip.cfg
Bien entendu, il ne faut modifier les éléments de ce fichier que si vous savez ce que vous faites. Une mauvaise manipulation pourrait rendre inopérant les services de téléphonie de votre FritzBox.
Nous allons voir comment modifier les codecs et l’ordre de ceux-ci. Pour cela, il faut localiser les 2 lignes suivantes :
use_audiocodecs = no;
audiocodecs = "PCMA", "PCMU", "G726-32", "G726-40", "G726-24";
C’est la configuration par défaut. La première variable (use_audiocodecs) avec une valeur à « yes » permet de dire à la FritzBox d’utiliser les codecs listés dans audiocodecs dans l’ordre de préférence indiqué. Par défaut, la FritzBox utilise le codec selon l’ordre annoncé par l’opérateur. Nous pouvons forcer les priorités ainsi :
use_audiocodecs = yes;
audiocodecs = "G729", "PCMA", "PCMU", "G726-32", "G726-40", "G726-24";
Après avoir réalisé ces modifications, il faut arrêter, puis redémarrer le daemon VoIP :
 
voipd -s
voipd
Maintenant, il est possible d’utiliser le codec G11 en priorité afin d’avoir une meilleure qualité audio.
Nous allons voir comment activer la détection de silence et la fonction VAD (voice activity detection). Vous pourriez avoir besoin de ces fonctions si votre ligne dispose d’un débit limité.
A la fin du fichier voip.cfg , vous avez la variable rtpstream :
 
rtpstream {
    voice_activity_detection {
        vad_enabled = vadenabled_no;
        vad_threshold = 10000;
        }
        plc {
            in_the_stack = yes;
        }
        jitter {
            auto_on = yes;
            in_ms = 50;
            in_packets = 0;
        }
        rtcp_enabled = yes;
        silence_detection = no;
}
Que vous allez modifier comme suit :
rtpstream {
    voice_activity_detection {
        vad_enabled = vadenabled_yes;
        vad_threshold = 10000;
        }
        plc {
            in_the_stack = yes;
        }
        jitter {
            auto_on = yes;
            in_ms = 50;
            in_packets = 0;
        }
        rtcp_enabled = yes;
        silence_detection = yes;
}
La valeur du threshold étant à adapter selon votre environnement (faites des tests).
Je vous laisse découvrir les différents paramètres.
 
FritzBox telnet: comment accéder à la ligne de commande
Solution pour activer le serveur telnet pour les routeurs AVM FritzBox
 
Même si l’interface web développée par les équipes d’AVM permet de réaliser les tâches d’administration et de parentérale, il est parfois utile d’avoir recours à la ligne de commande. D’abord, parce que c’est bien ! Surtout, pour ajouter des fonctionnalités complémentaires ou accéder à des paramètres cachés de l’interface web.
 
Pour cela il faut activer l’accès au serveur telnet. Pour cela, vous devez disposer d’un téléphone connecté à votre FritzBox, et composer le code suivant : #96*7* . Vous aurez un message sur votre téléphone « telnet on »
Après avoir réalisé vos modifications, vous pouvez désactiver le telnet avec le code #96*8*.
 
Vous allez pouvoir découvrir de nouvelles possibilités à votre routeur FriztBox : ajouter un serveur OpenVPN, manager plus finement le Firewall, installer un serveur Asterisk …