Catégorie : Administration réseau     Tags : , ,      

    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.

     

    /img-articles/lmhs/30/cc-art-netusecase/fig-1.jpg

    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 !).

    /img-articles/lmhs/30/cc-art-netusecase/fig-2.jpg

    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.)
    Posté par (La rédaction) | Signature : Eric Auge, (GCU) | Article paru dans Creative Commons License

    Laissez une réponse

    Vous devez avoir ouvert une session pour écrire un commentaire.


    • Il y a actuellement

    • 633 articles/billets en ligne.