Linux Attitude

Niveau :      
Résumé : perl, libipq, IN PTR

Le problème

Les firewall ne proposent jamais de faire une règle qui couperait la connexion en fonction du domaine de l'appelant. C'est gênant car on aimerait bien pouvoir devenir indépendant de l'ip de notre partenaire.

Si on ouvre un accès à un ami, pourquoi devrait-il nous avertir lorsqu'il change d'ip alors qu'il a fait correctement son travail en mettant à jour son DNS.

En réalité il y a de bonnes raisons à cela, en effet le domaine ne se trouve pas dans le paquet il faut donc aller le chercher quelque part. Et cela implique :

• qu'on base une règle sur quelque chose qu'on ne maîtrise pas, voire pire, qu'un attaquant pourrait maîtriser : la base dns de la source
• qu'on devient dépendant du résolveur dns et donc de ses failles
• qu'il est possible que le firewall empêche le firewall d'aller chercher l'info sur le serveur dns
• qu'il faut attendre que le dns réponde et donc les performances d'un tel firewall risquent d'être catastrophiques

Les deux derniers problèmes sont purement techniques et ont donc une solution technique acceptable moyennant quelques compromis. Par contre les deux premiers problèmes concernent la sécurité et il faut donc garder en tête que si on met en place une telle règle, elle est là pour nettoyer les flux qui traversent notre firewall, mais qu'elle n'apporte que peu de sécurité par rapport à l'absence de règle.

La solution

Maintenant que nous savons qu'il ne faut pas le faire, voyons comment faire :-)

Tout d'abord il y a deux possibilités, se baser sur le forward DNS (IN A et IN AAAA) ou sur le reverse dns (IN PTR). Aujourd'hui je vous propose le pire des cas, le reverse DNS, puisque votre configuration est directement tributaire de la volonté de l'attaquant.

Commençons par un prototype, donc en perl, parce que je le veux bien.

Le point important ici est de faire la résolution dns en espace utilisateur. Pour cela il faut d'utiliser libipq, la bibliothèque permettant de communiquer entre l'espace utilisateur et netfilter la partie noyau du firewall linux.

Il nous faut donc :

• libipq : IPTables::IPv4::IPQueue
• parser les paquets ip : NetPacket::IP
• faire des requêtes dns : Net::DNS

Et voici le script tout simple, le reste de l'article est en commentaire dans le script.

Niveau :      
Résumé : ip link add link eth0 vlan1 type vlan id 1

Je suis de retour !

Désolé pour le lag ... mais je réponds aux commentaires.

Problème

Aujourd'hui, un problème qu'on m'a posé récemment. Comment faire lorsqu'on a un parc de box (routeur wifi, machine embarquée, ...) et qu'on veut pouvoir à tout moment se connecter physiquement sur son port ethernet et la configurer en utilisant ip (par ssh, snmp ...).

La première solution est d'avoir une configuration réseau immuable sur ces machines ET de répertorier d'une façon ou d'une autre un identifiant unique pour chacune de ces machines qu'on peut alors faire correspondre à une ip. C'est assez contraignant et ça impacte fortement la configuration réseau des machines. Ça risque de nous empêcher de réutiliser ce port pour communiquer dans un réseau existant le reste du temps.

La deuxième solution serait d'utiliser un protocole type zeroconf pour configurer automatiquement le réseau lorsqu'on se branche, l'inconvénient est de réussir à le désactiver lorsque la machine se retrouve dans son réseau de destination qui n'utilise pas nécessairement zeroconf tout en le gardant actif pour le configurateur.

Je vous propose donc une solution différente : l'ip unique. Toutes les machines à configurer ont la même IP. C'est bien beau me direz-vous, mais comment fait-on pour éviter les conflits sur le réseau de destination ? Et comment fait-on pour que ces machines communiquent ensemble ?

C'est tout simple, on met cette IP sur un vlan prédéfini. Ainsi vous n'avez plus aucune contrainte sur la configuration réseau de l'appareil. Ce peut être une box en bridge ou en routeur, une machine physique avec un routage complexe, ou une machine configurée en dhcp.

Solution pour linux

Pour ajouter une interface réseau virtuelle associée à un vlan :

# le vlan 1 sur l'interface eth0 sera dans l'interface virtuelle vlan1 
$ ip link add link eth0 vlan1 type vlan id 1 

# ou, pour ceux qui n'aiment pas le couteau suisse, ip, il y a l'outil d'origine
$ vconfig add eth0 1 # pas le choix, l'interface s'appellera nécessairement eth0.1

Et il suffit de lui configurer une ip choisie en dur et c'est fini, vous pouvez mettre n'importe quelle configuration pour eth0 ...

$ ip addr add 192.168.254.254/28 dev eth0.1

Pour faire ceci en statique, sur une debian like il faut modifier /etc/network/interfaces en nommant l'interface à configurer eth0.1 Pour les redhat like il faut créer le fichier /etc/sysconfig/network-script/ifcfg-eth0.1

Aujourd'hui une pub éhontée pour un livre. Je ne connais même pas l'auteur personnellement, mais la maison d'édition me l'a envoyé gratuitement, ça prouve qu'il est bien non ?

Il s'agit de Linux embarqué. Pour une fois, ne vous attendez pas à trouver des lignes de commande, des howto ou ce genre de détails. Il s'agit bien d'un livre technique, mais dons le but est de vous faire choisir (ou pas) linux comme plateforme pour l'embarqué.

Il vous pose les bonnes questions et vous aide à y répondre. Quel modèle de développement ? Temps réel ou non ? Investissez-vous sur le long terme ? Et ce n'est qu'après avoir étudié le sujet que vous saurez s'il est judicieux de choisir linux.

Mais une fois que vous avez choisi linux, pensez-vous vraiment que cela suffise à votre succès ? Gilles Blanc vous explique comment vous préparer, ce que vous devez savoir, comment organiser le projet. Tout ce qu'il faut à l'intention du chef de projet.

Ce livre permet aux gens de faire un choix avisé, de savoir quelles sont les raisons de ce choix et comment. C'est grâce ça que vous pourrez soutenir ce choix tout au long du projet. Il permettra de transformer un projet sur l'embarqué en succès. Et il est probable que parmi ces projets un certain nombre utiliseront linux. Et comme tout le monde devrait le savoir, un projet réussi est un bien meilleur ambassadeur du libre qu'un geek dans son coin.

En conclusion, même si je ne recommanderais pas ce livre à ma grand-mère, je pense qu'il a une énorme valeur pour la progression du logiciel libre. Je le recommande à tout chef de projet ou ambassadeur du logiciel libre qui voudrait lancer un produit avec du linux embarqué.

Niveau :      
Résumé : ntp.conf ; fudge

Pour vérifier le bon fonctionnement de votre démon ntp, vous êtes amené à taper la commande suivante qui liste les source de temps utilisées :

$ ntpdc -p

Cette commande met une étoile face à la source de référence utilisée pour la synchronisation. Le choix se fait entre autre en fonction du stratum de la source. Je rappelle que les serveurs NTP disposant d'une source de temps matérielle fiable (horloge atomique) ont pour stratum 1. Ceux qui se synchronisent sur eux, 2, et ainsi de suite.

Étant donné qu'il y a un grand nombre de serveurs publics de strate 2 et 3, vous devriez avoir accès à des serveurs de strate 4, ou au pire 5. Mais si le serveur a une strate plus élevée, il se peut que l'horloge choisie ne soit plus le serveur, mais l'horloge locale qui a une strate définie par défaut à 5 sur certaine distributions.

Et là c'est le drame, vous n'êtes plus synchronisés !

Pour résoudre ce problème, il y a plusieurs méthodes, se résumant toutes en la configuration des serveurs de temps :

# ntp.conf

# mettre l'option prefer sur le serveur voulu
serveur xxx.com prefer
# réduire la strate du serveur
fudge xxx.com stratum 4

# augmenter la strate de l'horloge locale
# 127.127 pour les horloges non réseau
# 1.0 pour l'horloge système
fudge 127.127.1.0 stratum 10

Niveau :      
Résumé : vlock; vlock -ns

Vous avez vu apparaître dans l'article sur tmux, un petit outil pour verrouiller le terminal, il s'appelle vlock.

Son unique fonctionnalité est le locker un terminal et de demander un mot de passe pour être débloqué.

Mine de rien ça lui fait quand même deux cas d'usage :

• bloquer l'accès physique à une machine
• bloquer l'accès virtuel à un shell

Virtuel

Avec la commande suivante :

$ vlock

Vous bloquez votre terminal en cours, et seul un mot de passe peut le débloquer. C'est utile essentiellement lorsque vous êtes connecté en ssh à distance sur une machine.

Physique

L'option -a permet de locker toutes les consoles locales (ctrl-alt-Fx, ou alt-Fx), en pratique il locke la console en cours et empêche d'en changer. Il faut donc déjà être sur une console locale.

Si vous êtes sur X, vous êtes aussi sur une console locale (remarquez le ctrl-F7 pour y aller). Mais le shell qui va lancer votre commande ne l'est pas, il est dans le terminal virtuel de xterm, rxvt, konsole et consorts. Pour locker toutes les consoles, il faut donc utiliser l'option -n qui ouvre une nouvelle console (avec openvt) avant de continuer avec l'option -a.

Enfin notez que l'utilisateur local a en général accès aux magic keys, et une de ces magic keys sert justement à tuer le processus en avant plan (alt-sysrq-k), par exemple pour garantir qu'il n'y a pas de keylogger. Si vous ne voulez pas vous faire tuer votre session par cette combinaison de touche vous pouvez utiliser l'option -s. C'est là qu'on voit que cette combinaison nommé SAK n'est pas si sécurisée que ça puisqu'elle peut être désactivée...

Donc je résume :

# en tant qu'utilisateur normal et seulement depuis une console texte
$ vlock -a
# en tant que root
$ vlock -sn

Quand le lancer

Et c'est là qu'est la difficulté, en toute logique le lancement doit se faire par le processus qui dispose du terminal à un instant donné, surtout dans le cas de blocage du terminal virtuel. La bonne solution est de le lancer après un certain temps d'inactivité, et seule l'application peut savoir quand le lancer. C'est donc à vous de trouver les settings spécifiques à l'application pour le faire.

Mon article précédent indique comment faire pour tmux, malheureusement je n'ai pas trouvé de solution pour bash qui ne propose que la variable TMOUT qui termine complètement le shell.

Niveau :      
Résumé : tmux

Comme disait un illustre au grand cœur, "Compromis, chose due !" (orthographe approximative). Voici donc mon fichier de configuration détaillé de tmux, à mettre dans ~/.tmux.conf ou /etc/tmux.conf au choix. Je n'ai pas changé beaucoup de raccourcis car je tiens à m'habituer autant que possible aux valeurs par défaut qui vont se retrouver sur mes nouveaux serveurs.

J'en profite pour ajouter un raccourci que j'ai oublié la dernière fois :

• ctrl-b D : pour détacher un tmux resté ouvert à distance

# Pour les nostalgiques de screen
# comme les raccourcis ne sont pas les mêmes, j'évite
#set -g prefix C-a
#unbind-key C-b
#bind-key a send-prefix

# même hack que sur screen lorsqu'on veut profiter du scroll du terminal (xterm ...)
set -g terminal-overrides 'xterm*:smcup@:rmcup@'

# c'est un minimum (defaut 2000)
set-option -g history-limit 100000

# lorsque j'ai encore un tmux ailleurs seule
# sa fenetre active réduit la taille de ma fenetre locale
setw -g aggressive-resize on

# locker la session après inactivité (en s)
set -g lock-after-time 3600
# pour que le lock marche sous linux (apt-get install vlock)
set -g lock-command vlock

# il faut choisir un derivé de screen, 256 couleurs c'est bien !
set -g default-terminal "screen-256color"

# pour ceux qui n'ont pas laché la souris
set -g mouse-select-pane on
setw -g mode-mouse on

# ca peut etre utile ...
set -g status-utf8 on
setw -g utf8 on

# Pour etre alerté sur un changement dans une autre fenêtre
setw -g monitor-activity on
#set -g visual-activity on
#set -g visual-bell on

# numéroter a partir de 1, pratique pour l'accès direct
set -g base-index 1

# repercuter le contenu de la fenetre dans la barre de titre
# reference des string : man tmux (status-left)
set -g set-titles on
set -g set-titles-string '#H #W #T' # host window command


#########
# theme #
#########
# exprimez votre créativité ici !
# pour les string : man tmux (status-left)

# barre un peu plus discrete
set -g status-bg default
set -g status-fg green
setw -g window-status-current-bg default
setw -g window-status-current-fg white
setw -g window-status-alert-attr default
setw -g window-status-alert-fg yellow

set -g pane-active-border-fg green
set -g pane-active-border-bg black
set -g pane-border-fg white
set -g pane-border-bg black

set -g message-fg black
set -g message-bg green

# exemples de barre d'état 
#set -g status-left '#[fg=red]#H#[fg=green]:#[fg=white]#S #[fg=green]][#[default]'
#set -g status-right '#[fg=green]][#[fg=white] #T #[fg=green]][ #[fg=blue]%Y-%m-%d #[fg=white]%H:%M#[default]'

#set -g status-left '#[fg=red]#H#[fg=green]:#[fg=white]#S #[fg=green]][#[default]'
#set -g status-right '#[fg=green]][ #[fg=blue]%Y-%m-%d #[fg=white]%H:%M#[default]'

#set -g status-left '#[fg=green](#S) #(whoami)@#H#[default]'
#set -g status-right '#[fg=yellow]#(cut -d " " -f 1-3 /proc/loadavg)#[default] #[fg=blue]%H:%M#[default]'

#set -g status-right "#[fg=yellow]#(uptime | cut -d ',' -f 2-)"

Comme pour le bashrc collaboratif, je vous propose de poster en commentaires vos personnalisations, je les ajouterai.

Niveau :      
Résumé : tmux

Aujourd'hui tout le monde connaît et utilise screen. Miracle de la technologie, il permet de survivre aux déconnexions, de lancer des commandes longues sans avoir peur, de faire passer tous ses shells dans une seule connexion et on le trouve souvent associé à l'indémodable irssi.

Comme vous le savez peut-être screen n'est plus maintenu. Ayant un code un difficile à lire et à maintenir, des développeurs ont choisi lui faire un concurrent plutôt que de le reprendre.

Ce concurrent se nomme tmux. Il dispose de la plupart des fonctionnalités de screen et d'autres en plus. Comme vous le verrez, votre problème sera essentiellement de vous adapter aux nouveaux raccourcis. Pour le reste c'est tout bon.

Tmux dispose de presque toutes les fonctionnalités de screen sauf la communication par port série (rapport choucroute, toussa).

Commençons par le lancement :

# lancer un nouveau multiplexeur
$ screen 
$ tmux
# s'attacher à un multiplexeur existant 
$ screen -d -r
$ tmux attach

Les raccourcis :

• Nouvelle fenêtre
  • screen : ctrl-a ctrl-c
  • tmux : ctrl-b c
• Se détacher :
  • screen : ctrl-a d
  • tmux : ctrl-b d
• Passer à la fenêtre suivante
  • screen : ctrl-a <espace>
  • tmux : ctrl-b n

Je dois dire que ça y est je suis passé entièrement à tmux, le mélange ctrl-a ctrl-b entre screen et tmux commençait à être difficile. A propos d'adaptation, j'ai eu une seule difficulté c'est de m'habituer au nouveau scrollback. Il n'est pas possible de le faire à la souris, comme dans screen avec l'astuce du termcapinfo. Remarquez, c'est plus propre car du coup il n'y a pas de mélange des bufffer de scrollback entre les différents terminaux. Donc la méthode propre dans tmux c'est ctrl-b suivi de pgUp et là vous êtes en mode copy (qui permet entre autre le scrollback), vous pouvez alors naviguer avec pgUp, pgDown ou les touches directionnelles. Et pour Revenir au mode normal, Esc tout simplement.

Dans un prochain article nous verrons comment changer la configuration de tmux, même si les valeurs par défaut sont plutôt bonnes.