Ferrero Rocher, Kinder Surprise, Kinder Bueno ! Je tiens à publiquement remercier le fabricant de Nutella pour les merveilleuses inventions qu’il a créées ; la vie m’apporte chaque jour un bonheur supplémentaire et je ne compte plus ma joie lorsque j’ouvre mon Kinder Surprise pour monter le truc en plastique, mais... mais malheureusement...
...récemment... mon chien est devenu aveugle depuis qu’il a mangé le jouet du Kinder ! Las !J’ai donc décidé d’écrire cette lettre ouverte à M. Ferrero Rocher pour qu’il remplace les jouets moisis des Kinder Surprise par des board WRAP ou Soekris – et pour le même prix modique bien entendu – l’intérêt est MULTIPLE !!!!
- pédagogique (oui, un enfant devant un WRAP avec un BSD est un enfant de moins dans les rues !) ;
- psychologique ;
- instructogique ;
- mégalogique ;
- funogique ;
- glandogique.
Les avantages pour M. Ferrero Rocher seraient énormes : il pourrait toucher un plus grand nombre de consommateurs, dans les catégories cibles que sont les ISP, les utilisateurs de salles blanches et de téléphones VoIP tout en conservant ses atouts décisifs dans les cours d’école. Tweaker une WRAP, c’est plus FUN qu’une partie de POG, enfin voilà tu vas gagner de l’argent, plein, M. Ferrero, alors écoute, écoute bien, toi aussi ami du Nutella et toi aussi le borgne qui mange des œufs au fond là -bas...
Pourquoi des œufs Kinder plus gros !
Ils sont trop petits pour des VRAIS jouets !!!!
D’abord j’avais rien, enfin rien, j’avais mon p’tit routeur "maggy-knor-rajoute-de-l-eau-c’est-prêt", ensuite j’ai eu envie de faire un projet à la noix, pour passer le temps de manière fun, cela a été l’occasion de refaire mon réseau interne, et je me suis dit alors pourquoi pas un article !
Grave question : pourquoi je me suis fait chier à faire un LAN interne blablabla blablabla ? Pas d’autre motivation que le fun, comprendre et gérer les flux, s’éclater à monter et bidouiller des trucs, améliorer la visibilité et potentiellement la sécurité du LAN.
Tout ce qui est nécessaire ne sera pas forcément décrit, _toutes_ les configurations ne seront pas forcément dumpées intégralement, enfin bref, je vais vous présenter une démarche, des concepts initiaux avant de passer à une mise en pratique !
SPUD !! LES SLIDES !!! PASSE À LA SUIVANTE
Le rapport avec BSD ?! Hmm, les routeurs sont des p’tits routeurs embedded faits maison, comme pour l’access point, pareil pour le VPN-SSL, etc., et tout tourne avec du BSD à la fraise avec du chocolat dedans. Sachant que je suis un fanatique religieux et que je porte une barbe orange, j’ai principalement utilisé NetBSD.
Le rapport avec Kinder Surprise ? M. Ferrero les routeurs sont petits et tiennent dans un œuf.
Pour les routeurs, les access points et le serveur VPN, j’ai utilisé du WRAP, la _gateway_ va (sous peu) être une Soekris, le reste est constitué de machines plus ou moins exotiques (Intel, MIPS, Sparc64, etc.).
Ca n’est pas gratuit, mais c’est un moyen de bâtir une infrastructure soi-même, avec _TOUS_ les éléments utiles et d’en faire une expérience amusante :)
Ca sent l’assouplissant, hmm, hmmm, vous sentez, là , le printemps, la lavande, les cigales, le propre et tout ça ?
Le fantasme, le rêve, le schéma de la conquête du moooOOOonde !
Dans l’architecture finale, la passerelle (GW) s’occupera du NAT et du filtrage interne -> externe et les WRAP ne feront que du routage ainsi que du filtrage interne -> interne.
Mis à part les quelques services décrits ci-dessous, ces routeurs se doivent de rester légers et simples.
Le matos
- 1 switch (genre un Xylan 24 ports capable de faire des vlans) ;
- 1 switch "Ã pacher" (genre un 8 ports Netgear) ;
- 2 WRAP (3 LAN, 1 avec carte Wifi atheros minipci et 1 avec carte crypto hifn(4)) ;
- 1 Soekris (5 LAN avec une hifn(4)) ;
- des câbles, plein ! ;
- du temps, aussi, oui :)
Les pré-requis
- un peu de connaissance de base sur les réseaux ;
- un peu de bidouille et d’espièglerie ;
- un peu de connaissance en code système ;
- des connaissances de base sur l’administration système BSD ;
- les articles du HS BSD Acte I (allez l’acheter ! OSPF, PF, IPSEC, etc.) ;
- du matos (comme décrit ci-dessus) ;
- de la farine, un œuf ;
- une poupée vaudou (huuh :)) ;
- une chèvre (en vie !) et un bouc (pour la chèvre et les p’tits poils).
Le plan d'adressage : pourquoi les jouets en plastique c'est dépassé ?
Ne me saoulez pas parce que c’est pas des /30 ou des réseaux plus petits ou plus segmentés ou je ne sais quel truc pour rendre les choses moins lisibles. Maman m’a dit [3] KISS principle, allez, que tout le monde aille lire [2] ARTU, avant de dormir, un bécot et dodo.
Alors voilà :
GW :
- Inet/PPPoE/PPPoA ;
- 10.9.33.1/24 g Interconnexion/Backbone (wow !).
WRAP #1 :
- 172.16.10.1/24 g wifi network ;
- 10.7.33.1/24 g internal network ;
- 10.4.33.1/24 g service network ;
- 10.9.33.2/24 g Interconnexion/Backbone (p’tain j’me sens plus là !).
WRAP #2 :
- 10.3.33.1/24 g DMZ network ;
- 10.8.33.1/24 g Lab network ;
- 10.16.1.1/24 g VPN network (découpé en /30 en fait mais on y reviendra après) ;
- 10.9.33.3/24 g Interconnexion/Backbone (haha, ça claque de dire ça chez soi).
Sur le switch convivial ça se matérialise comme ça (j’ai fait des ‘tits vlans, des domaines de broadcast séparés pour bien isoler chaque subnet) :
Labs Interco Services [ ] [ ] [ ] [ ] [ ] [ ] [ ] [ ] [ ] [ ] [ ] [ ] [ ] [ ] [ ] [ ] [ ] [ ] [ ] [ ] [ ] [ ] [ ] [ ] Labs Free DMZ [ ] == port du switch
L'installation : le nouveau jouet Kinder !
WRAP/Soekris :
N’ayant pas encore reçu mon Soekris, je ne peux encore rien confirmer, mais bon ça ne doit pas être très difficile. Je ne suis – et par conséquent vous n’êtes – pas le premier à faire des installs sur ces trucs-là , y a des milliers de docs sur comment, quoi, où, pourquoi, etc. Référez-y vous si un problème fait son apparition (à moins d’être poisseux, a priori, c’est peu probable :).
Alors plusieurs choix sont possibles selon évidemment le matériel que vous allez utiliser. Certains préfèrent le PXE. D’autres, comme moi, sont des grosses feignasses et préfèrent utiliser un lecteur de Compact flash externe USB.
Comme j’ai pris une archi toute simple, AMD Geode, de l’Intel compatible, niveau install, pas de prise de tête, je prends ma ‘tite carte Compact flash, je l’insère dans mon lecteur Compact flash USB, hop, je boote mon Laptop en USB and voilà !!!
L’install est identique à une install standard à l’exception du fait que vous n’avez pas un disque dur de 250 Go, mais une carte Compact flash de 512 Mo (à quelques Go près), donc essayez d’être économe.
Sur les deux WRAP, le partitionnement ressemble à ça :
device size mount point options /dev/wd0a 249M / no options /dev/wd0f 431M /var rw,noatime,nodev,nodevmtime,softdep /dev/wd0e 869M /usr rw,noatime,nodev,nodevmtime,softdep /dev/wd0g 124M /home rw,nodev,nodevmtime,noexec,nosuid,softdep /dev/wd0h 125M /tmp rw,nodev,nodevmtime,nosuid,softdep
Eh oui, il n’y a pas de partition swap, ces p’tites machines tournant sur des Compact flash avec un nombre d’écritures limité, il faut bien entendu éviter de faire des écritures régulières et intensives (genre syslog) sur le disque.
Les options sont là pour illustrer un moyen parmi tant d’autres de restreindre un p’tit peu plus l’usage du disque, mais nous savons que la sécu, c’est bien plus que quelques droits sur une partition, bref... (ça veut dire venez pas me relouter avec SAYNUL SAYPASAYSECURE).
Une fois votre petit joujou installé, vous avez un NetBSD standard qui tourne là -dessus. Nous allons commencer par l’access point qui gère également le réseau interne ainsi que le réseau des services internes.
Note pour ceux qui ont un lecteur CF
N’oubliez pas que le nom des devices pendant votre install et au moment du reboot ne sont PAS les mêmes. Votre WRAP ne rebootera pas si vous ne pensez pas à éditer votre /etc/fstab avant de redémarrer complètement.
N’oubliez pas de configurer l’adresse IP du WRAP sur au moins une interface réseau, le série c’est sympa cinq minutes. Pensez à avoir au moins un sshd qui démarre et une IP configurée et routée.
On rajoute donc ça :
root@airprout:~ # cat /etc/ifconfig.sip0 inet 10.9.33.2 netmask 255.255.255.0
Et ça aussi :
root@airprout:~ # cat /etc/mygate 10.9.33.1
Puis ça (rajoutez vos nameservers) :
root@airprout:~ # cat /etc/resolv.conf nameserver 10.9.33.1
Et finalement ça dans le /etc/rc.conf :
sshd=YES
Voici également le fichier de configuration du noyau pour les deux [1] WRAP. On va faire tourner un p’tit NetBSD 4.0_BETA2. Tu peux donc compiler tranquille sur ta box et balancer le binaire compilé direct sur le [1] WRAP après son premier reboot.
La config quenelle à récupérer ici :
- http://team.gcu-squad.org/~rival/WRAP.ap (pour l’access point de base) ;
- http://team.gcu-squad.org/~rival/WRAP.vpn (pour le server VPN avec hifn(4) ou ubsec(4)) ;
- http://team.gcu-squad.org/~rival/WRAP.local (blah !).
Attention, c’est une config assez générique/safe, elle ne contient PAS les quelques optimisations qui se doivent d’être faites pour un routeur/firewall (mbufs, nmbcluster, tailles des states tables, etc.).
Allez maintenant que tes WRAP redémarrent avec ce qu’il faut et un OS du bien et propre on va s’occuper de la conf de chacun d’entre eux.
WRAP #1 : access point et routeur interne #1
Liens : Services network, Internal network, Wifi network
On commence simple, la configuration des interfaces :
SIP 0 (uplink) :
root@airprout:~ # cat /etc/ifconfig.sip0 inet 10.9.33.2 netmask 255.255.255.0
SIP 1 (internal network) :
root@airprout:~ # cat /etc/ifconfig.sip1 inet 10.7.33.1 netmask 255.255.255.0
SIP 2 (service network) :
root@airprout:~ # cat /etc/ifconfig.sip2 inet 10.4.33.1 netmask 255.255.255.0
ATH0 (wifi network) :
root@airprout:~ # cat /etc/ifconfig.ath0 inet 172.16.10.1 netmask 255.255.255.0 ssid "prout-ssid" mode 11g mediaopt hostap hidessid -apbridge
Bien évidemment, c’est ce [1] WRAP qui va gentiment distribuer les adresses aux machines qui se connectent sur ton réseau poilu, DHCP est donc activé sur les interfaces gérant le réseau wifi et le réseau interne.
Alors pour te faciliter la tâche, je colle une conf DHCP simple et claire, pour le reste dhcpd.conf(5) :
root@airprout:~ # cat /etc/dhcpd.conf | grep -v ^# | grep -v ^$
option domain-name "mon.rezo.poilu";
option domain-name-servers 10.4.33.2 212.40.0.10, 212.40.5.50;
default-lease-time 600;
max-lease-time 7200;
authoritative;
ddns-update-style none;
log-facility local7;
subnet 172.16.10.0 netmask 255.255.255.0 {
range 172.16.10.3 172.16.10.254;
option domain-name "wifi.mon.rezo.poilu";
option broadcast-address 172.16.10.255;
option routers 172.16.10.1;
host kamehouse-wifi {
hardware ethernet 00:03:de:ad:de:ad;
fixed-address 172.16.10.2;
}
}
subnet 10.7.33.0 netmask 255.255.255.0 {
range 10.7.33.10 10.7.33.254;
option domain-name "int.mon.rezo.poilu";
option routers 10.7.33.1;
option broadcast-address 10.7.33.255;
host vomi {
hardware ethernet 00:01:02:03:04:05;
fixed-address 10.7.33.7;
}
host kamehouse-lan {
hardware ethernet 05:04:03:02:01:00;
fixed-address 10.7.33.2;
}
}
subnet 10.4.33.0 netmask 255.255.255.0 {
# beuh y a rien ici, tout est statique!!
}
Pour être sûr qu’il remplisse bien sa fonction de routeur, il faut évidemment le lui dire. Il y a bien entendu quelques tunings de base pour un fonctionnement correct de l’AP :
root@airprout:~ # cat /etc/sysctl.conf #!/sbin/sysctl -f # # $NetBSD: sysctl.conf,v 1.5 2003/11/03 15:12:06 briggs Exp $ # # sysctl(8) variables to set at boot time. # # Default core name template: #kern.defcorename=%n.core net.inet.ip.forwarding=1 # tricky little bastard made rsync fail net.inet.tcp.ecn.enable=1 net.inet.ip.random_id=1 net.inet.tcp.log_refused=1 net.inet.ip.ttl=129 net.inet.ip.maxflows=1024 net.inet.icmp.maskrepl=0 net.inet.icmp.rediraccept=0 hw.ath0.ledpin=1 hw.ath0.ledon=1 hw.ath0.ledidle=1 # Number of kernel threads to use for NFS client #vfs.nfs.iothreads=4 security.models.bsd44.curtain=1 vm.bufcache=3 vm.filemin=1 vm.filemax=2
ou
root@airprout:~ # sysctl -w net.inet.ip.forwarding=1
À ce stade, on a un truc à nous, propre (powered by NetBSD) et qui tourne.
On va s’occuper de la partie un peu spéciale (wouaaaa, ça brillllleeeee !!!) :
- la configuration de l’access point :
Comme on l’a vu avant, mon interface wifi a pour nom ‘ath0’. Voici la configuration associée dans le fichier /etc/ifconfig.ath0 :
inet 172.16.10.1 netmask 255.255.255.0 ssid "prout-ssid" mode 11g mediaopt hostap hidessid -apbridge
Décrivons les paramètres peu courants de cette ligne :
hostap: mode point d’accès ;hidessid: active le SSID cloaking (cela ne rend en _RIEN_ votre access point invisible, tant que vous générez du trafic :) ;-apbridge: désactive le dialogue entre les clients du point d’accès.
Plus d’infos là -dedans -> ifconfig(4) (oui, il faut toucher la page, laaaa ouiiii, comme çaaa ouiii... tu sens ?)
hostapd(8) :
Le daemon hostapd s’occupe de gérer l’authentification et l’accès au périphérique via les standards IEEE802.1X/WPA/WPA2/EAP, etc. En gros, il va donner accès au link-level de ton réseau wifi, donc à ton réseau.
Ce daemon est présent par défaut dans l’installation standard de NetBSD, rien à faire, *feign* powered, il faut juste le configurer et lui dire de démarrer au boot.
La configuration :
root@airprout:~ # cat /etc/hostapd.conf | grep -v ^# | grep -v ^$ interface=ath0 logger_syslog=-1 logger_syslog_level=3 logger_stdout=-1 logger_stdout_level=3 debug=0 dump_file=/tmp/hostapd.dump ctrl_interface=/var/run/hostapd ctrl_interface_group=wheel ssid=bikini-bottom macaddr_acl=0 auth_algs=1 wpa=2 wpa_passphrase=this is my elite passphrase :) wpa_key_mgmt=WPA-PSK wpa_pairwise=TKIP CCMP wpa_group_rekey=600 wpa_strict_rekey=1 wpa_gmk_rekey=86400
Voilà c’est fait, vous avez un access point qui fonctionne en WPA2-PSK avec comme passphrase d’accès ‘this is my elite passphrase :)’. Passer en WPA1 ? Rien de plus simple : wpa=1.
Le fichier hostapd.conf par défaut vous donne tous les détails pour vous authentifier via un serveur RADIUS, définir des ACL MAC, etc. Il est franchement convivial et très très simple à comprendre, ceci est bien évidemment un proof-of-concept (wouuuuaaaaaa le mot anglais bien classeeeee), en fait comme vous voyez, c’est super simple, c’est cucul la praline.
Message pour Kinder Surprise : offrir des [1] WRAP à monter dans ses œufs au lieu d’offrir des brouettes miniatures à monter soi-même.
Maintenant pour que tout reboote bien tranquillou, hopla, on rajoute ça dans le /etc/rc.conf :
hostapd=YES dhcpd=YES dhcpd_flags="ath0 sip1"
Et pour être sûr de l’heure, on va se synchroniser sur le ntp local à notre zone, hopla, encore un truc à rajouter :
ntpdate=YES ntpdate_hosts="ch.pool.ntp.org"
Après ce début de démonstration, il vous sera aisément compréhensible que les gamins et l’association mouflets du 21ème siècle que je représente vous demandent de bien vouloir considérer notre requête ; néanmoins, je vais continuer ma démonstration et vous exposer la suite de ce plan de restructuration qui pourrait faire décoller les ventes de Kinder Surprise EMEA... et p’têt worldwide.
WRAP #2 : VPN Server/Routeur interne #2
Liens : Lab network, DMZ network, VPN network
On recommence simple et souple, la configuration des interfaces :
SIP 0 (uplink) :
rival@earthprout:~ $ cat /etc/ifconfig.sip0 inet 10.9.33.3 netmask 255.255.255.0 up
SIP 1 (DMZ network) :
rival@earthprout:~ $ cat /etc/ifconfig.sip1 inet 10.3.33.1 netmask 255.255.255.0 up
SIP 2 (service network) :
rival@earthprout:~ $ cat /etc/ifconfig.sip2 inet 10.8.33.1 netmask 255.255.255.0 up
TUN0 (VPN network, elle n’existe pas encore !?!?!?!?!) :
rival@earthprout:~ $ #hmmm doucement on y arrive M. le Président, je sais que vous ne tenez plus, le concept est incroyable !!
On active le routage comme tout à l’heure :
root@airprout:~ # sysctl -w net.inet.ip.forwarding=1
NOTE
Ne pas oublier /etc/sysctl.conf pour que ça RESTE.
Le VPN -> OpenVPN :
La fonction de ce [1] WRAP c’est de router, c’est de filtrer, de NAT-er aussi temporairement, on verra pourquoi plus tard. Il fournit également un accès interne au réseau externe.
L’avantage est d’avoir un VPN multiplateforme, facile à mettre en œuvre (entendre : sans problèmes d’interopérabilité à la noix) et relativement "safe".
Pour cela, d’abord l’installer (et c’est là que vous sacrifiez la chèvre) :
root@earthprout:~ # pkg_add ftp://ftp.netbsd.org/......../openvpn-2.0.7.tgz
Nous allons attribuer une classe d’adresses associée aux utilisateurs VPN. J’ai associé des adresses IP statiques à chacun des utilisateurs ayant besoin d’accéder à certaines machines de mon LAN (je suis aussi un de ces utilisateurs :).
Bon, allons directement au fond des choses : voici la configuration, ça facilite toujours le boulot. Ce n’est pas un article sur OpenVPN, ni sur les VPN.
Le fichier de config WRAP.vpn contient le support tun(4)/tap(4) nécessaire au fonctionnement d’OpenVPN dans tout type de configuration.
server config : rival@earthprout:~ $ cat /usr/pkg/etc/openvpn/server.conf local 10.9.33.3 dev tun proto udp tls-server mode server keepalive 10 120 ca /usr/pkg/etc/openvpn/cacert.pem cert /usr/pkg/etc/openvpn/vpnserv.cert key /usr/pkg/etc/openvpn/vpnserv.key dh /usr/pkg/etc/openvpn/dh2048.pem push "route 10.3.33.0 255.255.255.0" push "route 10.8.33.0 255.255.255.0" client-config-dir ccd # do we need client to see each others client-to-client mssfix 1400 user nobody group nogroup comp-lzo persist-tun persist-key verb 1 management 127.0.0.1 1194 engine cryptodev server config ccd/user1 : rival@earthprout:/usr/pkg/etc/openvpn/ccd $ cat user1 ifconfig-push 10.16.1.14 10.16.1.13 client config user1 : rival@kamehouse:~ $ cat /usr/pkg/etc/openvpn/client.conf remote <ton ip publique> port 1194 client tls-remote vpn.mon.rezo.poilu # not fixed yet #ns-cert-type server tls-exit dev tun0 # if necessary #tls-auth keys/ta.key 1 ca cacert.pem cert kamehouse.cert key kamehouse.key comp-lzo verb 1
Après test, on devrait voir apparaître une interface tun0, etc., (enfin, bref OpenVPN quoi !) un truc comme ça :
rival@earthprout:~ $ ifconfig tun0 tun0: flags=8050<POINTOPOINT,RUNNING,MULTICAST> mtu 1500 inet 10.16.1.1 -> 10.16.1.2 netmask 0xffffffff inet6 fe80::20d:b9ff:fe06:be9c%tun0 -> prefixlen 64 scopeid 0x6
L’authentification se fait par certificat, signé par mon autorité de certification, pour gérer vos certificats, utilisez tinyCA ou proutCA ou chaispasquoiCA ou ce petit Makefile BSD fait maison, accompagné des fichiers de conf qui vont bien (openssl.cnf, etc., mais c’est pas non plus un article sur la PKI) :
#
# Little Makefile for handling signing certs requests + creating crl
# this Makefile also create initial CA files
#
# this makefile is inpirated from the idea of jmates
# it has been rewritten.
#
# for UW :
# rival@phear.org
#
# TODO: certificate revocation
#
# it Uses BSD Makefiles!$ #@!#@! $!@ !@ #
#
# Some Docs :
# 1. create a CA directory
# 2. create CA/conf
# 3. cp openssl.cnf CA/conf/
# 4. wget -O Makefile http://no.phear.org/codes/misc/Makefile.CA
# 5. config CAROOT, OSSL_CONF, OSSL_SERV_CONF variables in the Makefile
# 6. make init
# You're ready :)
# NB: if you want to generate server/clients csr install server.cnf in CA/conf and use 'make gencsr name=<name>'
#
# Common Use:
# Signing a CSR :
# 1. put new CSR in CA/csr directory (i.e. filename.csr)
# 2. make sign csr=filename.csr
# 3. get the cert in CA/cert/filename.cert if the operation is successfull
#
#
OPENSSL=/usr/bin/openssl
CAROOT=/home/rival/dev/soul/no.phear.org/CA
OSSL_CONF_DIR=$(CAROOT)/conf
OSSL_CRL_DIR=$(CAROOT)/crl
OSSL_CERTS_DIR=$(CAROOT)/certs
OSSL_NEWCERTS_DIR=$(CAROOT)/newcerts
OSSL_PRIV_DIR=$(CAROOT)/private
OSSL_CSR_DIR=$(CAROOT)/csr
OSSL_CONF=$(OSSL_CONF_DIR)/openssl.cnf
OSSL_SERV_CONF=$(OSSL_CONF_DIR)/server.cnf
all: help
list: listcsr listcrt listkey
listcrt:
@echo 'Listing CERTs:'
@cat ${CAROOT}/index.txt
listcsr:
@echo 'Listing pending CSRs:'
@/bin/ls -l ${OSSL_CSR_DIR}
listkey:
@echo 'Listing private KEY:'
@/bin/ls -l ${OSSL_PRIV_DIR}
sign:
@if [ ! -f $(OSSL_CSR_DIR)/${csr} ]; then echo "${csr} : no such file or directory" ; exit 1 ; fi
@$(OPENSSL) ca -config ${OSSL_CONF} -in ${OSSL_CSR_DIR}/${csr} -out ${OSSL_CERTS_DIR}/${csr:.csr=.cert}
@[ -s $(OSSL_CERTS_DIR)/${csr:.csr=.cert} ] && rm -P ${OSSL_CSR_DIR}/${csr}
# args name= server=yes
gencsr:
@echo 'Create the CSR for ${name}'
@$(OPENSSL) req -config ${OSSL_SERV_CONF} -newkey rsa:2048 -keyout ${OSSL_PRIV_DIR}/${name}.key -keyform PEM -out ${OSSL_CSR_DIR}/${name}.csr -outform PEM
@echo 'Create an unlocked CSR key version for ${name}'
@$(OPENSSL) rsa < ${OSSL_PRIV_DIR}/${name}.key > ${OSSL_PRIV_DIR}/${name}_unlocked.key
gencrl:
@$(OPENSSL) ca -config ${OSSL_CONF} -gencrl -out ${OSSL_CRL_DIR}/ca-crl.pem
revoke:
@$(MAKE) gencrl
init:
@test ! -f serial
@mkdir $(OSSL_CRL_DIR) $(OSSL_NEWCERTS_DIR) $(OSSL_PRIV_DIR) $(OSSL_CSR_DIR) $(OSSL_CERTS_DIR)
@chmod 700 $(OSSL_PRIV_DIR)
@echo '01' > $(CAROOT)/serial
@touch $(CAROOT)/index.txt
@$(OPENSSL) req -config $(OSSL_CONF) -days 1825 -x509 -newkey rsa:2048 -out $(CAROOT)/cacert.pem -outform PEM
caclean:
@echo cleaning CA files
@rm -rf $(CAROOT)/cacert.pem $(OSSL_CSR_DIR) $(CAROOT)/index.* $(CAROOT)/serial.* $(OSSL_NEWCERTS_DIR) $(OSSL_PRIV_DIR) $(OSSL_CERTS_DIR)
help:
@echo make help
@echo ' - this help'
@echo make init
@echo ' - init the CA authority'
@echo make list
@echo ' - list known key, signed certs (index.txt) & pending CSR'
@echo make gencsr name=\<name\>
@echo ' - generate a CSR (<name>.csr) & associated key (<name>.key)'
@echo ' location CSR: ${OSSL_CSR_DIR}/<name>.csr'
@echo ' location KEY: ${OSSL_PRIV_DIR}/<name>.key'
@echo make gencrl
@echo ' - generate the CRL (Certificate Revocation List)'
@echo ' location: ${OSSL_CRL_DIR}/ca-crl.pem'
@echo make sign csr=filename.csr
@echo ' - sign the filename.csr with CA authority'
@echo ' location: ${OSSL_CSR_DIR}/filename.csr'
@echo ' result: ${OSSL_CERTS_DIR}/filename.cert'
@echo ' csr is automagically deleted.'
@echo make revoke cert=filename.cert
@echo ' - revoke the filename.cert certificate and generate a new crl'
OpenOSPF (le routage entre tout le monde !)
Ahhhhhhhhh, c’est là que les choses deviennent marrantes :).
Alors si vous montez le [1] WRAP avec un OpenBSD pas de souci, [5] OpenOSPF compile sans problème, ça marche out of the box tout ça, tout ça. Si comme dans notre (allez encore de l’anglais) use case, on fait tourner tout sous NetBSD, alors là , y a pas encore de [5] OpenOSPF sous NetBSD. Alors, j’ai fait un petit portage de la version 3.9 d’OpenOSPF (la version 4.0 est en cours de portage aussi, mais j’ai trop de boulot, les structures ont changé entre OpenBSD et NetBSD et j’ai pas terminé pour cet article, oui, je suis fainéant !)
Le patch du portage se trouve ici :
http://no.phear.org/codes/misc/openospf/
C’est trivial et ça n’a pris que quelques heures. J’ai également fait un pkgsrc, qui se trouve au même endroit, mais il n’est pas tout à fait terminé (il marche quand même, hein, mais il copie pas le script de démarrage comme il faut :), bref... vous avez les billes de base *feign* *feign*.
Le but étant d’éviter les routes statiques partout et à maintenir soi-même. À problème simple, solution simple, du routage dynamique, youpi ! Sur chacun des routeurs, je configure OpenOSPF de la manière suivante, avec une area 0.
ospfd.conf(5) :
root@earthprout:/usr/pkg/etc/openvpn/ccd $ cat /usr/pkg/etc/ospfd.conf
hi="5"
redistribute connected
area 0.0.0.0 {
interface sip0 {
hello-interval $hi
auth-type crypt
auth-md-keyid 1
auth-md 1 "proutprout"
}
}
Je redistribue toutes les routes des interfaces connected à tous mes neighbours, sur le VPN je rajoute :
redistribute static
pour distribuer les routes statiques provenant des tunnels VPN qui se montent dynamiquement, and voilà !!!!
Un joli résultat :
root@earthprout:~ # ospfctl show neighbor ID Pri State DeadTime Address Iface Uptime 10.9.33.2 1 FULL/DR 00:00:36 10.9.33.2 sip0 01w2d22h
et ça de l’autre côté :
root@airprout:~ # ospfctl show neighbor ID Pri State DeadTime Address Iface Uptime 10.9.33.3 1 FULL/BCKUP 00:00:38 10.9.33.3 sip0 01w2d22h
On mate vite fait les routes sur l’un des deux :
root@airprout:~ # ospfctl show fib flags: * = valid, O = OSPF, C = Connected, S = Static Flags Destination Nexthop *S 0.0.0.0/0 10.9.33.1 *O 10.3.33.0/24 10.9.33.3 *C 10.4.33.0/24 link#4 *C 10.7.33.0/24 link#3 *O 10.8.33.0/24 10.9.33.3 *C 10.9.33.0/24 link#2 *O 10.16.1.0/24 10.9.33.3 *S 127.0.0.0/8 127.0.0.1 *C 127.0.0.1/8 link#0 * 127.0.0.1/32 127.0.0.1 *C 172.16.10.0/24 link#1 root@airprout:~ # ospfctl show rib Destination Nexthop Path Type Type Cost Uptime 10.9.33.3 10.9.33.3 Intra-Area Router 10 01w3d00h 10.9.33.0/24 10.9.33.2 Intra-Area Network 10 01w3d07h 10.3.33.0/24 10.9.33.3 Type 1 ext Network 110 01w3d00h 10.8.33.0/24 10.9.33.3 Type 1 ext Network 110 01w3d00h 10.16.1.0/24 10.9.33.3 Type 1 ext Network 110 01w2d22h
Ça marche !
Le troisième et dernier routeur, qui n'est pas encore là (eh oui, je l’ai commandé, mais il est pas encore là ), aura exactement la même configuration.
Alors c’est pas tout simplet tout ça ?!
Le NAT
Le tout dernier souci à régler avant de pouvoir avoir un truc complètement fonctionnel (dont tous les réseaux arrivent à joindre tous les réseaux) est de permettre à ces réseaux d’accéder (ou NON) à l’internet convivial Ferrero Rocher. Dans mon plan de conquête du monde, tout le trafic de l’interne passerait par un serveur SOCKS local, les autres réseaux utiliseraient également le même SOCKS et aucune translation ne serait effectuée, excepté pour le server SOCKS, je n’en suis pas encore là .
En plus, mon routeur ADSL est encore un vieux truc convivial qu’on administre via une page web (USRobotics de mes $#@$!#@), donc pas d’OSPF pour lui, ni rien, je ne contrôle pas mon NAT là -dessus, donc j’ai du NATer au niveau des WRAP en attendant de terminer tout ça.
Cet article se conclut donc par ces règles de NAT qui vous permettront d’avoir un réseau fonctionnel avec pleins de trucs kikoo lol qui claquent. Les règles parlant d’elles-mêmes, je n’en dirai pas plus.
Voici sur Airprout (wrap #1) :
root@airprout:~ # cat /etc/ipnat.conf # internal trusted lan map sip0 from 10.7.33.0/24 to !10.0.0.0/8 -> 10.9.33.2/32 proxy port ftp ftp/tcp map sip0 from 10.7.33.0/24 to !10.0.0.0/8 -> 10.9.33.2/32 portmap tcp/udp 20000:30000 mssclamp 1400 map sip0 from 10.7.33.0/24 to !10.0.0.0/8 -> 10.9.33.2/32 mssclamp 1440 # Wifi Network map sip0 172.16.10.0/24 -> 10.9.33.2/32 proxy port ftp ftp/tcp map sip0 172.16.10.0/24 -> 10.9.33.2/32 portmap tcp/udp 30001:40000 mssclamp 1400 map sip0 172.16.10.0/24 -> 10.9.33.2/32 mssclamp 1440
Et voici sur Earthprout (wrap #2) :
root@earthprout:~ # cat /etc/ipnat.conf # DMZ network inet access map sip0 from 10.3.33.0/24 to !10.0.0.0/8 -> 10.9.33.3/32 proxy port ftp ftp/tcp map sip0 from 10.3.33.0/24 to !10.0.0.0/8 -> 10.9.33.3/32 portmap tcp/udp 20000:30000 mssclamp 1400 map sip0 from 10.3.33.0/24 to !10.0.0.0/8 -> 10.9.33.3/32 # LABS network inet access map sip0 from 10.8.33.0/24 to !10.0.0.0/8 -> 10.9.33.3/32 proxy port ftp ftp/tcp map sip0 from 10.8.33.0/24 to !10.0.0.0/8 -> 10.9.33.3/32 portmap tcp/udp 30001:40000 mssclamp 1400 map sip0 from 10.8.33.0/24 to !10.0.0.0/8 -> 10.9.33.3/32 # MAP VPN _ME_ to everywhere, dangerous! map sip0 from 10.16.1.10/32 to !10.0.0.0/8 -> 10.9.33.3/32 portmap tcp/udp 42001:45000 mssclamp 1400 map sip0 from 10.16.1.10/32 to !10.0.0.0/8 -> 10.9.33.3/32
Oui, oui, je sais, c’est du hack tout laid, mais bon, j’ai pas fini, c’est en cours de finition. Les règles de filtrages sont à déterminer selon VOS besoins (faites une offrande au dieu des firewalls, il vous donnera probablement une réponse), de même que les autres services de base qui se situent dans le "service network" :
- DNS ;
- SOCKS ;
- syslog ;
- tor proxy ;
- Intranet + zabbix, etc.
Reste à faire :
- SNMP v3 ;
- router hardening ;
- OS hardening ;
- etc. ;
- acheter une nouvelle chèvre ;
- acheter des poules ;
- commander un AbdoFlex 3000 ;
- vendre des champignons.
Le test & l'instant Kodak
Du réseau interne :
rival@kamehouse:~ $ ifconfig wm0
wm0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
capabilities=7ff80<TSO4,IP4CSUM_Rx,IP4CSUM_Tx,TCP4CSUM_Rx,TCP4CSUM_Tx,UDP4CSUM_Rx,UDP4CSUM_Tx,TCP6CSUM_Rx,TCP6CSUM_Tx,UDP6CSUM_Rx,UDP6CSUM_Tx,TSO6>
enabled=0
media: Ethernet 100baseTX full-duplex
status: active
inet 10.7.33.2 netmask 0xffffff00 broadcast 10.7.33.255
inet6 fe80::215:c5ff:fe01:203%wm0 prefixlen 64 scopeid 0x1
J’atteins donc :
La DMZ :
rival@kamehouse:~ $ ping 10.3.33.2 PING 10.3.33.2 (10.3.33.2): 56 data bytes 64 bytes from 10.3.33.2: icmp_seq=0 ttl=253 time=1.435 ms
Le Lab :
rival@kamehouse:~ $ ping 10.8.33.3 PING 10.8.33.3 (10.8.33.3): 56 data bytes 64 bytes from 10.8.33.3: icmp_seq=0 ttl=253 time=3.178 ms
L’interco :
rival@kamehouse:~ $ ping 10.9.33.1 PING 10.9.33.1 (10.9.33.1): 56 data bytes 64 bytes from 10.9.33.1: icmp_seq=0 ttl=254 time=2.036 ms
et tout le reste.
Et l’image de l’installation faite maison :
Conclusion
M. Ferrero, cette démonstration faite, tout est désormais entre vos mains. Il me paraît clair que le consommateur est roi dans votre industrie, je vous invite donc à intégrer ces nouvelles données dans la fabrication de vos œufs pour l’année 2008. Je suis sûr que vos profits en ressentiront l’effet salvateur.
Je vous prie d’agréer, M. Ferrero, l’assurance de mes sentiments les plus cordiaux et distingués et vous remercie de l’attention portée à ce courrier.
Dans l’attente de vous lire en retour, je vous souhaite un bon week-end.
(NB : L’important c’est de tripper... et je trippe les Kinder surprises, je les tripperai d’autant plus si y a des trucs gratuits où on peut installer NetBSD dessus, merci de réaliser mes rêves !).

Références
[1] WRAP : http://pcengines.ch/wrap.htm
[2] The Art of UNIX programming : http://www.faqs.org/docs/artu/
[3] KISS principle : http://www.faqs.org/docs/artu/ch01s07.html
[4] NetBSD : http://netbsd.org
[5] OpenOSPF : http://www.openbgpd.org/
[6] BSD Acte I, "Répartition de charge et haute disponibilité sur les OS *BSD (Partie 1)", Linux Magazine,
hors-série n° 29.
[7] BSD Acte I, "Routage dynamique et haute disponibilité (Partie 2)", Linux Magazine, hors-série n° 29.
[8] ospfd.conf(5)
[9] openvpn(8)
[10] hostapd.conf(5)
Remerciements
- mes doigts ;
- la lessive (pour des habits qui sentent bon) ;
- mon écran (car il m’affiche des trucs) ;
- la tomate (prout !) ;
- le friand (contre prout !) ;
- GCU (maison !!!!) – I’m loving it
- les relecteurs (Benoyst, Courgette, Wilk, etc.)



