Skip to content →

Fabien Vincent Posts

Rsyslog : Dériver les messages syslog dans un fichier particulier

Depuis pas mal de temps, je me casse les dents sur la d√©rivation des logs envoy√©s au d√©mon rsyslog, utilis√©s pas d√©faut dans Ubuntu. En effet, j’ai install√© un tvheadend sur mon serveur / media center pour avoir √† la TV dans tous mes XBMC/Kodi, et le mode debug est un peu trop verbeux √† mon go√Ľt.

La configuration de base de rsyslog est fait par d√©faut dans “/etc/rsyslog.d/50-default.conf”. Pour qu’un fichier particulier soit trait√© en premier, comme dans Apache, il faut en cr√©er un nouveau.

Par exemple, j’ai cr√©er les fichiers suivants :

[19:54 user@home ~] > ll /etc/rsyslog.d/*
-rw-r--r-- 1 root root  483 Apr  9 21:40 /etc/rsyslog.d/10-tvheadend.conf
-rw-r--r-- 1 root root  465 Apr  9 21:40 /etc/rsyslog.d/11-dhcpd.conf
-rw-r--r-- 1 root root  469 Apr  9 21:50 /etc/rsyslog.d/12-postfix.conf
-rw-r--r-- 1 root root  311 Mar 17  2012 /etc/rsyslog.d/20-ufw.conf
-rw-r--r-- 1 root root 1.7K Apr  9 21:52 /etc/rsyslog.d/50-default.conf

Ces fichiers contiennent les dérivations suivantes :

[19:54 user@home ~] > cat /etc/rsyslog.d/10-tvheadend.conf
# Put tvheadend log in a specific log file
if $programname == 'tvheadend' then /var/log/tvheadend/tvheadend.log
& stop

[19:54 user@home ~] > cat /etc/rsyslog.d/11-dhcpd.conf
# Put isc-dhcpd-server log in a specific log file
if $programname == 'tvheadend' then /var/log/dhpcd.log
& stop

[19:54 user@home ~] > cat /etc/rsyslog.d/12-postfix.conf
# Put postfix log in a specific log file
if $programname == 'tvheadend' then /var/log/postfix.log
& stop

Il faut ensuite simplement reloader/restarter le service rsyslog pour prendre en compte ces changements, et vérifiez que vos fichiers sont bien crées (il peut subsister des problèmes de droits, surtout lorsque vous avez créer un dossier spécifique comme dans le cas de tvheadend).

A noter qu’il existe beaucoup d’options pour filtrer par programname, severity, ou de mani√®re plus puissante par regex. Dans le cas ou vous souhaiteriez faire ceci, RFTM !

Ensuite, il ne faut oublier de configurer la rotation des logs (dans mon cas, j’ajoute un restart du process, car je n’ai pas de ‘status‘ pour le d√©mon tvheadend dans mon init.d) :

[20:05 user@home ~] > cat /etc/logrotate.d/tvheadend
/var/log/tvheadend/*.log {
        daily
        missingok
        rotate 7
        compress
        delaycompress
        notifempty
        create 640 syslog adm
        sharedscripts
        postrotate
                /etc/init.d/tvheadend restart
        endscript
}

Puis forcer la rotation (-f) ou débuguer (-d)

[20:09 user@home ~] > sudo logrotate -d /etc/logrotate.conf
reading config file /etc/logrotate.conf
[...]
reading config file tvheadend
[...]

rotating pattern: /var/log/tvheadend/*.log  after 1 days (7 rotations)
empty log files are not rotated, old logs are removed
switching euid to 0 and egid to 104
considering log /var/log/tvheadend/tvheadend.log
  log does not need rotating
not running postrotate script, since no logs were rotated
switching euid to 0 and egid to 0

Vous trouvez alors la rotation des logs :

[20:11 user@home ~] > ll /var/log/tvheadend/
 
-rw-r----- 1 syslog adm  12K Apr 11 20:11 tvheadend.log
-rw-r----- 1 syslog adm  48K Apr 11 09:50 tvheadend.log.1

Bon amusement !

Comments closed

Passer de Cisco IOS à IOS-XR, une nouvelle façon de penser !

Pour industrialiser des nouveaux √©quipements ASR 99xx sous Cisco IOS-XR, j’ai √©crit un script pour convertir rapidement la configuration des interfaces L3 IPv4 / IPv6, l’IGP OSPF/OSPFv3 et ses costs, ainsi que le routage BGP depuis une configuration de Cisco 6K sous IOS. Ceci afin principalement d’√©viter les erreurs de ctrl+c / ctrl+v (ou l ‘effet PEBKAC) .

La majorit√© des changements est facile √† appr√©hender entre IOS et IOS-XR, m√™me si parfois les choix technologiques entrainent de changer sa mani√®re de corr√©ler la technique r√©seau et la configuration des √©quipements. Exemple : la MTU n’est plus consid√©r√©e au niveau 3 sur un IOS-XR, mais comme la MTU niveau 2, voir ASR9000/XR: Understanding MTU calculations ou
MTU Behavior on Cisco IOS XR and Cisco IOS Routers).

Mais le changement majeur de IOS-XR, c’est l’arriv√©e des route-policies. Pour ceux qui ont l’habitude des SUP720 /¬† SUP2T, lorsque l’on configure une session BGP, on configure 3 √©l√©ments communs en IN / OUT :

  • filter-list [AS_PATH] (in|out) : On configure ici la liste des AS / AS_PATH BGP autoris√©s ou interdits en in et out
  • prefix-list [PFX_LIST] (in|out) : On configure ici la liste des pr√©fixes annonc√©s ou interdits en in et out
  • route-map [ROUTEMAP] (in|out) : On configure ici la route-map in et out qui permettra de modifier les attributs BGP, les next-hop …. Tout un ensemble d‚Äô√©l√©ments n√©cessaires pour maitriser la r√©partition de trafic, les commits en fonction des transitaires, l’acceptation des default routes ou de la DFZ, etc ….

Sur Cisco IOS-XR, plus besoin de lire 1000 lignes √©parpill√©es dans la configuration pour comprendre la logique de tel ou tel neighbor BGP ! On peut avoir le tableau d’√©quivalences suivant:

Cisco IOS Cisco IOS-XR
Sets d’AS Paths ip as-path access-list as-path-set
Sets de préfixes ip prefix-list prefix-set
Configuration neighbor BGP filter-list
prefix-list
route-map
route-policy

 

Désormais, les annonces, les filtres et la modification des attributs BGP se réalisent dans un seul et même endroit : la route-policy.

Ces route-policies sont un peu d√©routantes au d√©but, car il fait penser √† tout. Plus possible de changer les annonces avec la modification rapide d’un prefix-list en out avec un clear ip bgp soft.

La logique de ces routes policies est beaucoup plus “programmatique” qu’avant :

  • Par d√©faut, on interdit tout (deny / drop implicite). Il n’y a donc plus de deny non plus dans les prefix-set ou les as-path-set, car il faut utiliser le mot cl√© “not” avant un test.
  • Les conditions sont faites par des conditions “if¬† then” > “elseif then” > “else” > “endif”, comme en bash. L’ordre des conditions remplace les num√©ros de s√©quences bien connues des route-maps.
  • L’ex√©cution d’une route-policy se fait √† l’aide d’un “ticket” qui peut changer de valeur en fonction des conditions :
    • mot cl√© “PASS” : L’ex√©cution continue et on autorise, tant que le reste de la RPL ne drop pas (le deny implicite ne s’applique pas)
    • mot cl√© “SET” : M√™me usage que “PASS”, mais on ajoute la modification des attributs BGP
    • mot cl√© “DONE” : L’ex√©cution s’arr√™te avec un “PASS”
    • mot cl√© “DROP”: L’ex√©cution s’arr√™te avec un deny explicite.

Exemple simple et stupide !

route-policy example
    # On autorise les AS_PATH dans allowed-ases
    # On évite la default route dans default-route
    if (as-path in allowed-ases and not destination in default-route) then
         pass
    # On set le local-pref à 20 si on tombe sur la default-route
    elseif (destination in default-route) then
         set local-preference 20
    # Sinon on laisse passer le reste avec un local-preference a 10
    else 
         set local-preference 10
    endif
# Ici, on a un drop implicite, d'o√Ļ le dernier set
end-policy

On peut aussi faire un appel à des routes-policies de manière imbriqué, en passant des variables :

route-policy set_localpref($pref)
  set local-pref $pref
end-policy

Dans la route-policy précédente, il nous suffit donc de faire

    else 
         apply set_localpref(10)
    endif

L’exemple ci-dessus n’est pas forc√©ment le plus intelligent, mais en √©largissant √† des exemples concrets, on prend conscience de la puissance des route-policies sous IOS-XR. Il est m√™me possible √† priori d’appeler une route-policy avec un argument dans la configuration d’un neighbor BGP.

Cette nouvelle manière de penser / écrire les optimisations et actions sur le routage est très percutante, même si le changement est difficile à appréhender et nécessite de la réflexion.

En effet, dans la r√©alisation de mon script de migration, j’ai pu convertir les as-path access-list, les prefix-list, et les route-maps, mais le nombre de combinaisons possibles pour les neighbors BGP m’a emp√™cher d’automatiser leur conversion de mani√®re simple. Le changement dans l’application des param√®tres de configuration du neighbor BGP n√©cessite une revue compl√®te et manuelle des param√®tres de configuration du neighbor BGP.

Pour en savoir plus, je vous engage √† lire ce tr√®s bon article sur le supportforums cisco, qui m’a permis de d√©marrer et automatiser la conversion des routes-maps¬†: ASR9000/XR: Understanding and using RPL (Route Policy Language)

De nombreux articles sont disponibles sur le net, et la pratique vaut forc√©ment mieux que l’exemple.

Bon courage √† ceux qui doivent migrer des milliers de lignes √† la main ūüėČ

Comments closed

Laverna, une application web de Notes

En cherchant une application pour auto-h√©berger mes notes et remplacer EverNote, j’ai √©t√© s√©duit par l’application Laverna.

Les fonctionnalit√©s qui m’ont attir√©es sont les suivantes :

  • G√©rer vos notes, m√™me lorsque vous √™tes d√©connect√©
  • Cryptage s√©curis√© c√īt√© client (AES)
  • Possibilit√© de synchroniser avec DropBox – ce que je ne ferais pas bien entendu ūüôā
  • Boutons de contr√īle WYSIWYG
  • Coloration syntaxique¬†
  • Raccourcis clavier

Pour une démonstration : https://laverna.cc/

Pour l’installation, il suffit de faire un git clone du repository dans un Virtual Host s√©curis√© : https://github.com/Laverna/laverna

Bref, une application web de plus auto-hébergée !

One Comment

Perfect Forward Secrecy pour Postfix/Dovecot

Apr√®s mon article sur PFS pour Apache, j’ai mis √©galement en place PFS sur mon serveur de messagerie Postfix/Dovecot, le client K9-Mail pour Android supportant d√©sormais des versions plus r√©centes de TLS, TLSv1.1 et v1.2.

Voici ici quelques éléments pour réaliser cette configuration et augmenter la sécurisation des flux chiffrés.

One Comment

Perfect Forward Secrecy pour Apache

Lors de l’utilisation d’un protocole comme SSL/TLS pour le chiffrement et la s√©curisation des donn√©es sur des r√©seaux non s√Ľrs, il est important de garantir la confidentialit√© totale des communications, m√™me en cas de capture du trafic chiffr√©.

TLS n’est en effet pas un protocole unique, mais une multitude de briques permettant la s√©curisation des √©changes, gr√Ęce √† :

  • L’authentification du serveur (et optionnellement du client). On utilise en g√©n√©ral un certificat x509v3 d√©livr√© par une autorit√© de certification.
  • La confidentialit√© des donn√©es, en utilisant les suites de chiffrement disponibles dans les CipherSpecs.
  • L’int√©grit√© des donn√©s, en utilisant des fonctions de hachage disponibles dans les CipherSpecs.

Un des probl√®mes de TLS est que pour que cela fonctionne, il faut bien un cl√© master sym√©trique d√©finie dans l’√©tape client key exchange. Heureusement, celle-ci est chiffr√©e par la cl√© publique du certificat serveur, emp√™chant sa lecture par un tiers autre que le serveur.

Un des probl√®mes est que si l’on r√©cup√®re la cl√© master et la cl√© priv√©e du serveur, m√™me √† post√©riori, il est techniquement possible (m√™me si cela n’est pas √† la port√© de quiconque !) de d√©chiffrer l’ensemble d’une capture du trafic par exemple. On perd ainsi la confidentialit√© des donn√©es transmises, ce qui n’est pas acceptable pour un protocole de s√©curisation de donn√©es. Quand on connait les impacts potentiels de la faille HeartBleed, on se rend compte que l’obtention de la cl√© priv√©e est possible (m√™me si encore une fois, cela reste une attaque tr√®s complexe et non garantie, cela reste possible et envisageable).

Afin d’√©viter cela, nous allons utiliser la propri√©t√©¬†Perfect Forward Secrecy, qui va faire appel √† des suites de chiffrement bas√©es sur les √©changes de cl√© DH (au lieu de RSA) qui ne sont pas faillibles (en th√©orie) √† ce principe, car les cl√©s √©chang√©es sont √©ph√©m√®res et sign√©es. Cette propri√©t√© permet d’√©viter le d√©chiffrement √† post√©riori d’une capture, m√™me en possession de la cl√© priv√©e du serveur. Attention, ceci est vrai si le groupe DH est suffisamment grand et valide, et uniquement sur des communications ant√©rieures √† l’obtention de la cl√© priv√©e.

Il est possible de renforcer ce m√©canisme de Perfect Forward Secrecy en utilisant la cryptographie bas√©e sur des courbes elliptiques (ECDHE pour l’√©change de cl√©s √©ph√©m√®res, et ECDSA pour l’authentification du serveur), r√©put√©e plus s√Ľre que la cryptographie par factorisation.

Par exemple, sur le logiciel Apache, on peut utiliser les CipherSuites suivantes pour renforcer la sécurité de nos échanges basés sur TLS :

# Activation du mod_ssl dans Apache
SSLEngine on

# On désactive SSLv2 et SSLv3 pour n'utiliser que TLS v1.x
SSLProtocol all -SSLv2 -SSLv3

# Au lieu de préférer les suites du client (mécanisme par défaut), on privilégie les suites proposées par le serveur
SSLHonorCipherOrder on

# On propose les suites avec ECDHE, ECDSA uniquement pour PFS
SSLCipherSuite "EECDH+ECDSA+AESGCM EECDH+aRSA+AESGCM EECDH+ECDSA+SHA384 EECDH+ECDSA+SHA256 EECDH+aRSA+SHA384 EECDH+aRSA+SHA256 EECDH+aRSA+RC4 EECDH EDH+aRSA RC4 !aNULL !eNULL !LOW !3DES !MD5 !EXP !PSK !SRP !DSS !RC4"
 
# On autorise les clients non compatibles SNI à accéder à ce vhost
SSLStrictSNIVHostCheck on

# Certificat, cl√© et ch√ģne de certification
SSLCertificateFile      /etc/ssl/certs/cert_beufa.net.cert
SSLCertificateKeyFile   /etc/ssl/private/cert_beufa.net.key
SSLCertificateChainFile /etc/ssl/certs/CAcert_chain.pem

Ces options sont bien s√Ľr √† activer avec pr√©caution en cas de forte charge sur vos serveurs Apache. En effet, la baisse de performances li√©es √† l’usage de la propri√©t√© Perfect Forward Secrecy entra√ģne des baisses de performances importantes, de l’ordre de 15% √† 20% en fonction de la longueur des cl√©s et CipherSpecs utilis√©s.

Comments closed
fr_FRFR