Benjamin Collet

Configuration minimale d'une borne Cisco Aironet 1200 Series

Tue, 24 Jan 2012 16:35:00 +0100

J’ai récemment mis la main sur quelques bornes Cisco Aironet 1220B-E-K9, j’ai donc décidé d’en faire profiter quelques amis.

Les réseaux locaux personnels étant la plupart du temps différents des réseaux d’entreprise (tout le monde ne fait pas du 802.1X avec plusieurs VLAN à la maison), j’ai décidé de faire un petit tutoriel pour mettre en place une configuration minimale pour rendre lesdites bornes fonctionnelles chez tout un chacun.

Les postulats de départ avant de commencer :

votre borne est raccordée dans un réseau avec un serveur DHCP et vous êtes capables de récupérer l’IP assignée à votre borne ;
vous n’avez pas de câble série Cisco ;
vous avez une version d’IOS récente sur votre borne (pour les bornes que j’ai donné c’est le cas : c1200-k9w7-mx.123-8.JED1) ;
vous avez un minimum de notions en réseau (vous savez ce qu’est une IP, un réseau, un masque de sous-réseau, une passerelle par défaut, une clef WPA, un SSID, etc.) ;
la borne est dans une configuration d’usine.

Tout d’abord, on va se connecter à la borne en telnet (ouais c’est vieux, c’est moche et c’est pas sûr, mais c’est la configuration initiale, il y a pas le choix), on va activer les commandes privilégiées et on va passer en mode configuration. L’identifiant et le mot de passe par défaut est Cisco.

telnet 192.168.42.154
   
Trying 192.168.42.154...
Connected to 192.168.42.154.
Escape character is '^]'.
   
   
User Access Verification
   
Username: Cisco
Password: Cisco
ap>enable
Password: Cisco
ap#conf t
Enter configuration commands, one per line.  End with CNTL/Z.

On va maintenant la nommer et lui dire dans quel domaine elle est (faites le, c’est obligatoire pour la suite).

ap(config)#hostname sushi-ap
sushi-ap(config)#ip domain name fa0.org

On active les nouvelles commandes et fonctions de contrôle d’accès, puis on fait passer les nouvelles connexions directement en mode d’exécution (privilégié). Ensuite on créé un nouvel utilisateur (ici bcollet avec le mot de passe givemesushi), on supprime l’utilisateur par défaut (Cisco) et on enlève le mot de passe pour passer en mode d’exécution (qui n’est plus nécessaire maintenant).

sushi-ap(config)#aaa new-model
sushi-ap(config)#aaa authorization exec default local
sushi-ap(config)#username bcollet privilege 15 password givemesushi
sushi-ap(config)#no username Cisco
sushi-ap(config)#no enable secret

On va maintenant générer une clef RSA, nécessaire pour se connecter en SSH et en HTTPS (si vous laissez l’interface web activée).

sushi-ap(config)#crypto key generate rsa
The name for the keys will be: sushi-ap.fa0.org
Choose the size of the key modulus in the range of 360 to 2048 for your
  General Purpose Keys. Choosing a key modulus greater than 512 may take
  a few minutes.
   
How many bits in the modulus [512]: 1024
% Generating 1024 bit RSA keys ...[OK]

On va maintenant n’autoriser les connexions console que en SSH et non plus en telnet.

sushi-ap(config)#line vty 0 15
sushi-ap(config-line)#transport input ssh
sushi-ap(config-line)#exit

On va rentrer maintenant dans le vif du sujet, à savoir fournir un accès sans-fil. Nous configurons ici un SSID sushi avec la clef ilovesushi.

sushi-ap(config)#dot11 ssid sushi
sushi-ap(config-ssid)#authentication key-management wpa
sushi-ap(config-ssid)#wpa-psk ascii ilovesushi
sushi-ap(config-ssid)#exit

Nous allons maintenant configurer l’interface radio 0 pour lui dire d’annoncer le SSID sushi avec CCMP comme chiffrement. Si vous avez encore des antiques Windows XP, rajoutez le mot clef tkip après aes-ccm (mais c’est mal^©).

sushi-ap(config)#interface dot11Radio 0
sushi-ap(config-if)#encryption mode ciphers aes-ccm
sushi-ap(config-if)#ssid sushi
sushi-ap(config-if)#no shutdown
sushi-ap(config-if)#exit

Les interfaces BVI sont des ponts entre plusieurs interfaces. Ici par défaut un pont est configuré entre l’interface radio et l’interface Ethernet. À savoir que l’IP du point d’accès doit être configurée sur le pont et non sur l’interface Ethernet, ce que nous allons faire maintenant, au lieu d’avoir un adressage via DHCP. Attention, votre connexion va être interrompue, vous devrez vous reconnecter (en SSH cette fois ci).

sushi-ap(config)#interface BVI 1
sushi-ap(config-if)#ip address 192.168.42.154 255.255.255.224
sushi-ap(config-if)#exit

On finalise la configuration réseau de la borne en lui donnant l’adresse de la passerelle par défaut et du serveur de nom.

sushi-ap(config)#ip default-gateway 192.168.42.129
sushi-ap(config)#ip name-server 8.8.8.8

Enfin, on désactive l’interface web. La première ligne sert à désactiver l’interface HTTP, la seconde l’interface HTTPS. Si vous souhaitez conserver un accès à l’interface web, gardez de préférence celui en HTTPS.

sushi-ap(config)#no ip http server
sushi-ap(config)#no ip http secure-server

Et voilà, c’est terminé, il ne nous reste plus qu’à sortir du mode de configuration et d’enregistrer les changements.

sushi-ap(config)#end
sushi-ap#write
Building configuration...
[OK]

Suspend and hibernate on a Thinkpad X40

Mon, 17 Aug 2009 04:10:00 +0200

Making suspend and hibernate working on Debian Lenny on a Thinkpad X40 with a minimal installation is pretty easy, but can become a real pain in the ~~ass~~ neck if you miss a step.

First of all, you must install the following packages:

hal
dbus
consolekit
acpid
uswsusp
gnome-power-manager

Then, add youself to the powerdev group:

adduser <login> powerdev

Make sure thinkpad_acpi kernel module is loaded.

If you want to be able tu use the Thinkpad (or Access IBM) blue button, you must edit /etc/acpi/thinkpad-thinkpad.sh and replace acpi_fakekey $KEY_PROG1 by acpi_fakekey $KEY_MACRO (for an unknown reason, it seems that Xorg is not able to retrieve $KEY_PROG1 (#148) keycode from /dev/input/eventx). The keycode associated is now 239, you can bind it using xmodmap or xbindkeys.

Don’t forget to put gnome-power-daemon on your session startup script (~/.config/openbox/autorun.sh in Openbox).

You should now be able to use either special shortcuts such as Fn-F4/Fn-F12 and gnome-power-manager buttons in the tray icon.

Changements sur oxynux.org

Fri, 24 Jul 2009 01:29:00 +0200

J’ai effectué pas mal de changements sur oxynux.org et ses sous-domaines, tout d’abord avec un changement de serveur, en effet je suis passé d’un serveur @home à un dédié chez OVH, m’apportant ainsi une plus grande souplesse quant à ma mobilité, en effet je n’ai plus à me soucier de la connexion internet de l’endroit où je peux être amené à déménager pour y mettre mon serveur. De plus passer d’une connexion à 7Mbps/1Mbps à une connexion en 100Mbps symétrique n’est pas désagréable.

Autre grande modification, plus récente celle là, concerne la page principale d’Oxynux.org, qui s’est vue remplacée par un dokuwiki regroupant mon blog, ainsi que les pages précédemment hébergées sur un wiki séparé. J’ai normalement fait le nécessaire pour ne pas « casser » les url des billets ou des flux rss/atom, évidemment en cas de problème, n’hésitez pas à m’en faire part.

Je vais maintenant profiter de ce renouveau pour détailler les différentes configurations de mon serveur dans les pages accessibles sous la rubrique System administration.

Freebox v5, boitier HD et commutateur administrable

Wed, 06 May 2009 00:00:00 +0200

Nous avons enfin reçu à la Petite Sœur la remplaçante de notre antique Freebox v4 ; une Freebox v5 et son boitier HD. Ayant déjà un réseau filaire administré passant non loin de la TV il était donc logique d’y faire passer aussi le lien pour le boitier TV.

Il faut cependant être au courant de certaines choses ; le boitier TV et la Freebox communiquent entre-eux en faisant du marquage de vlan (802.1Q), sur le VLAN 100 pour être exact. Au démarrage le boitier HD demande un bail DHCP à la Freebox, puis initie une connexion VPN avec la Freebox.

La finalité sera donc d’avoir un lien pour la TV et Internet entre la Freebox et le commutateur administrable, un lien entre le commutateur et le pare-feu (ou votre routeur) et un lien entre le commutateur et le boitier HD.

Nous allons donc utiliser le VLAN 100 pour la TV (contrainte par les boitiers) et le VLAN 101 pour le lien entre la Freebox et le pare-feu (à adapter à votre configuration).

L’exemple de configuration qui suit est prévu pour un commutateur Cisco, mais est facilement adaptable pour n’importe quel commutateur administrable.

Configuration du port pour la Freebox

moyra(config-if)#no switchport access vlan
moyra(config-if)#switchport mode trunk
moyra(config-if)#switchport trunk encapsulation dot1q
moyra(config-if)#switchport trunk native vlan 101
moyra(config-if)#switchport trunk allowed vlan 100

Configuration du port pour le pare-feu

moyra(config-if)#switchport access vlan 101

Configuration du port pour le boitier HD

moyra(config-if)#no switchport access vlan
moyra(config-if)#switchport mode trunk
moyra(config-if)#switchport trunk encapsulation dot1q
moyra(config-if)#switchport trunk allowed vlan 100

Internship

Thu, 02 Apr 2009 00:00:00 +0200

My two-year course at Technology University Institute of Belfort - Montbéliard is ending with a ten-week internship, which I am going to start next Monday.

I have chosen to do this internship at UTBM’s IT Department (more precisely in the Network, system and Unix branch).

UTBM currently provides wireless access to students based on the following technologies:

The objective of my internship is to improve and extend the existing system to meet expectations of a wider public. The ‘new’ version will have to provide access to:

Academic guests through eduroam
Non-academic guests through a captive portal, which involves development of an accounts management interface
UTBM members (students, teachers, researchers, technical and administrative staff), with separation of different communities

My work will be divided in two parts; network and system (80%) and development (20%).

Several technologies are involved: 802.1X authentication protocol, Freeradius authentication server, MySQL DBMS, Cisco IOS (UTBM is using Cisco Aironet 1100 accesspoints, and Catalyst switches), GNU/Linux, 802.1Q (vlan tagging), LDAP, etc.

Grsec & grub-probe (update-grub failing)

Sun, 07 Dec 2008 08:48:00 +0100

If you have a grsec-patched kernel and PaX is enabled, update-grub is failing, witch is a little bit annoying:

8:45 root@sloane ~# update-grub
Searching for GRUB installation directory ... found: /boot/grub
zsh: exit 137   update-grub

After a little more in-depth look, the problem comes from grub-probe not having the right PaX flags.

Default flags:

8:47 root@sloane ~# chpax -v /usr/sbin/grub-probe.
 
----[ chpax 0.7 : Current flags for /usr/sbin/grub-probe (PeMRxS) ]----.
 
 * Paging based PAGE_EXEC       : enabled (overridden).
 * Trampolines                  : not emulated.
 * mprotect()                   : restricted.
 * mmap() base                  : randomized.
 * ET_EXEC base                 : not randomized.
 * Segmentation based PAGE_EXEC : enabled

We need paging and segmentation based PAGE_EXEC to be disabled: chpax -ps /usr/sbin/grub-probe.

It should now work:

8:51 root@sloane ~# grub-probe --device-map=/boot/grub/device.map -t device /
/dev/md0

Grsec & snmpd

Sun, 07 Dec 2008 08:04:00 +0100

With a grsec-patched kernel, only members of the specific group #112 are allowed to access /proc, but having the snmp user in grsec group is not enough, because snmpd doesn’t set groups the user belongs to properly. You can use the -g flag, but it will only change the owner group, and still won’t set groups to snmpd.

For instance, without setting the -g flag:

Gid:    0       0       0       0   
Groups: 0

With -g 112:

Uid:    118    118    118    118 
Gid:    112    112    112    112 
Groups: 112

I wrote this quick&dirty little patch, to enable correct group attribution:

--- snmpd-orig/agent/snmpd.c        2007-07-19 23:01:43.000000000 +0200
+++ snmpd-patch/agent/snmpd.c       2008-11-17 15:02:04.000000000 +0100
@@ -960,7 +960,7 @@
         DEBUGMSGTL(("snmpd/main", "Changing gid to %d.\n", gid));
         if (setgid(gid) == -1
#ifdef HAVE_SETGROUPS
-            || setgroups(1, (gid_t *)&gid) == -1
+            || initgroups(getpwuid(uid)->pw_name, gid) == -1
#endif
             ) {
             snmp_log_perror("setgid failed");
@@ -970,6 +970,14 @@
             }
         }
     }
+    else if(initgroups(getpwuid(uid)->pw_name, getpwuid(uid)->pw_gid) == -1)
+    {
+      snmp_log_perror("initgroups failed");
+      if (!netsnmp_ds_get_boolean(NETSNMP_DS_APPLICATION_ID,
+    NETSNMP_DS_AGENT_NO_ROOT_ACCESS)) {
+          exit(1);
+      }
+    }
#endif
#ifdef HAVE_SETUID
     if ((uid = netsnmp_ds_get_int(NETSNMP_DS_APPLICATION_ID,

Now I do have:

Uid:    118    118    118    118
Gid:    112    112    112    112
Groups: 112 65534

Une photo de la soirée retrouvailles où l’équipe info...

Sat, 08 Mar 2008 18:50:00 +0100

Une photo de la soirée retrouvailles où l’équipe info (Sarah et moi) avons définitivement perdu toute crédibilité… surtout moi en fait.