Archive for the ‘Network’ Category

Network connection with HTC Hero and Debian

Saturday, July 17th, 2010

I have an HTC Hero, an Android phone, for one year. But I never tried to share his network connection with my Debian laptop. To prepare my trip to Debconf10, I try it today and… I’m surprised because it’s so easy!

1. Plug your phone on USB
2. Active “Share your phone network” on phone (in french: “Partage du réseau mobile”)
3. You see now an usb0 ethernet device:

usb0      Link encap:Ethernet  HWaddr a2:17:af:4f:fa:da
BROADCAST MULTICAST  MTU:1500  Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 lg file transmission:1000
RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

4. Configure usb0 to have the network configuration 192.168.100.100/24 with your favorite tool (ifconfig for example).
5. Now you can ping your phone with 192.168.100.254. Use it as gateway and enjoy: your laptop is now connected with Wi-Fi, GPRS or 3G+!

Note: I use HTC Hero with Android 1.5 (build number: 2.73.61.5) and the french mobile phone provider Orange.

Mon compte-rendu du FRnOG 16

Saturday, July 3rd, 2010


Vendredi 25 juin 2010, je me suis rendu au FRnOG 16, la rencontre des BOFH qui se déroule 2 fois par an à Paris. Le principe est de réunir tous les opérateurs de l’Internet français (Orange, SFR, Bouygues, Nerim, Iliad, Jaguar Network, TATA, Level 3, etc.) mais aussi des acteurs incontournables (AFNIC, RIPE NCC, Renater, etc.), des hébergeurs (OVH, Ikoula, GANDI, Euro Web, etc.), des sociétés de services (principalement la célébrissime société Evolix ;-), mais aussi Linagora, Witbe, etc.) et même des gros sites web (CyberCartes, Pixmania, etc.). Voici donc mon résumé du déroulement de l’après-midi :

  • Présentation commerciale d’Equinix (un des sponsors de la manifestation) qui possède notamment un gros datacenter à Saint-Denis où se trouvent pas mal d’hébergeurs et d’opérateurs français
  • Présentation de France-IX, une nouvelle entité dont le but est de monter un gros point d’échange français dans la lignée du FreeIX d’Iliad, du PANAP de Bouygues Telecom ou du Sfinx de Renater. Pour les non-initiés, un point d’échange sert notamment à favoriser le peering (échange de trafic souvent gratuit) entre les opérateurs. On y apprend notamment que France-IX a trouvé un accord avec le PANAP, et que Marseille va devenir une plaque-tournante du monde d’Internet grâce à l’arrivée des câbles sous-marins. Marseille, centre du monde, quoi de plus normal \o/
  • Nouvelles du Sfinx, le point d’échange de Renater. On a notamment des informations sur les évolutions prévues en terme d’équipements mais aussi sur les points de présence (notamment dans les DOM/TOM). Et ça parle encore de projets sur Marseille \o/
  • Talk d’Alix Guillard du RIPE NCC qui commence très fort : “je suis Alix et je ne suis pas un point d’échange”. Il présente les dernières discussions sur les mailing-lists, et surtout les outils du RIPE Labs : labs.ripe.net
  • Présentation technique de l’infrastructure mondiale de Level 3, un très gros opérateur. L’exposé est très technique et intéressant et traite notamment des flux trèèèèèès haut débit (jusqu’à plusieurs Tb/s), des câbles sous-marins, etc.
  • Exposé de Stéphane Bortzmeyer de l’AFNIC sur DNSSEC. Pédagogique, clair, l’exposé est génial ! Stéphane, avec un superbe T-Shirt isc.org Bind 1997, est un bon orateur. Il nous ré-explique pourquoi DNSSEC (sécurité, faille Kaminski). Extrait : “D’ici à 2012 plusieurs fins du monde sont prévues”. Puis il expose le planning de déploiement sur les serveurs racines et désormais les TLD. De nombreuses anecdotes amusantes, comme les déboires du .GOV suite à une relance de Barak Obama et l’invalidité pendant plusieurs semaines du .NOAA.GOV ou encore du .FBI.GOV. Pour le .FR c’est prévu pour septembre 2010 (l’AFNIC a commencé avec le .PM… le TLD de St-Pierre et Miquelon :-). Enfin, une question sur qui vérifiera les signatures DNSSEC : l’utilisateur final ou le FAI ? Stéphane répond que ça sera sûrement les deux : le geek vérifiera et le FAI vérifiera pour Mme Michu.
  • Pause publicitaire de la société BeFree
  • Présentation de la société Blade Network, un constructeur de switchs peu connu car il équipe des gros constructeurs (IBM, HP…) en marque blanche. Il nous parle notamment de ses switchs 10G.
  • Pause café
  • One-man-show de Jean-Michel Planche de Witbe. Au milieu des blagues, le sujet était le monitoring. JMP insiste notamment sur la nécessité de faire des mesures fiables et pertinentes sur les points significatifs (NDLR: certes…) et il parle de QoE (Qualité d’Expérience) en plus de la QoS (Qualité de Service). Pas mal d’évidences : “rien ne passe comme prévu”, “il faut automatiser ce qui peut l’être”, mais on reste un peu sur sa faim car on a l’impression qu’il manque une conclusion à son talk. En effet, il a parlé d’outils plus sérieux que les “Nagioseries”, mais sans dire de quoi il s’agissait (vous croyez qu’il peut s’agir d’outils propriétaires développés par sa société ? :-). Certes, je suis d’accord sur pas mal de choses, notamment que le monitoring ne consiste pas à faire des requêtes automatisées toutes les 3 minutes, et qu’il faut que les opérateurs arrêtent de proposer du pseudo-monitoring et confient les missions d’infogérance à des prestataires indépendants (comme Evolix par exemple ;-). Par contre, JMP généralise trop son exposé : tout le monde n’a pas des FAI comme clients qui doivent surveiller la qualité du débit/VoIP/IPTV de millions de Mme Michu ; et Nagios reste un très bon outil même si il en a touché les limites.
  • Exposé très pointu sur les cartes réseau 40G et 100G. Je dois avouer avoir un peu décroché… Zzzz…
  • Présentation des défis opérationnels d’IPv6 par Souissi (AFNIC) et Stevant (ENST). Parler d’IPv6 en présence de nombreux opérateurs… le terrain était miné. L’idée n’était pas de ré-expliquer l’intérêt d’IPv6 et la pénurie prochaine des IPv4, mais d’aborder des détails concrets comme l’obtention de préfixes IPv6 ou des expérimentations de futures connexions Internet sans IPv4 avec des tunnels, etc.

Voilà pour les conférences commerciales et techniques. À la fin, il y avait un tirage au sort pour gagner un iPad et des ballons de la Coupe du Monde. J’avais annoncé que si je gagnais l’iPad, je l’échangerai contre un ballon de foot (faut pas déconner non plus). Bon, je n’ai pas gagné l’iPad, mais j’ai justement gagné un Jabulani. Suite à cela, il y avait le beer event, dans un petit bar pris d’assaut. Mais j’ai à peine eu le temps de parler emailing avec EmailVision, Nagios avec Yann, et descendre une bière, que j’ai du filer vers mon TGV pour me ramener au centre du monde.

SFR Huawei 3G+ USB key with Debian

Wednesday, July 29th, 2009

After Orange GPRS with Nokia 6630 and SFR GPRS with Nokia E65, I use now mainly Huawei 3G+ USB key with SFR (french mobile phone provider).

lsusb info about this Huawei 3G+ USB key:

Bus 003 Device 003: ID 12d1:1003 Huawei Technologies Co., Ltd. E220 HSDPA Modem / E270 HSDPA/HSUPA Modem

And dmesg info:

[208765.818448] option 3-1:1.0: GSM modem (1-port) converter detected
[208765.818448] usb 3-1: GSM modem (1-port) converter now attached to ttyUSB3
[208765.830451] usb-storage: probe of 3-1:1.1 failed with error -5
[208765.830451] option 3-1:1.1: GSM modem (1-port) converter detected
[208765.830451] usb 3-1: GSM modem (1-port) converter now attached to ttyUSB4
[208765.830502] scsi12 : SCSI emulation for USB Mass Storage devices
[208765.834458] usb 3-1: New USB device found, idVendor=12d1, idProduct=1003
[208765.834458] usb 3-1: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[208765.834458] usb 3-1: Product: HUAWEI Mobile
[208765.834458] usb 3-1: Manufacturer: HUAWEI Technologies
[208765.834458] usb-storage: device found at 3
[208765.834458] usb-storage: waiting for device to settle before scanning
[208770.863868] usb-storage: device scan complete
[208770.866850] scsi 12:0:0:0: CD-ROM            HUAWEI   Mass Storage     2.31 PQ: 0 ANSI: 2
[208770.887881] sr0: scsi-1 drive
[208770.887881] sr 12:0:0:0: Attached scsi CD-ROM sr0
[208770.887881] sr 12:0:0:0: Attached scsi generic sg1 type 5

For connecting, I tried an infamous GUI distributed by Vodafone in Debian package. Too buggy, too complex. The best solution is using a PPP chatscript.

Then, plug USB key, sleep 20 and unlock it:

echo 'at+cpin="1234"' > /dev/ttyUSB3

Note: 1234 is PIN code (or not) and /dev/ttyUSB3 is modem device.

Create these 2 files:

/etc/ppp/peers/gprs:

noauth
debug
nodetach
connect "/usr/sbin/chat -v -f /etc/ppp/peers/huawei-e220.chat"
/dev/ttyUSB3
230400
crtscts
defaultroute
noipdefault
user ignored
remotename whatever
ipparam whatever
usepeerdns

/etc/ppp/peers/huawei-e220.chat:

# Chat file for Huawei E220 HSDPA USB modem
ABORT BUSY ABORT 'NO CARRIER' ABORT 'NO ANSWER' ABORT DELAYED
'' AT
OK ATZ
OK 'ATQ0 V1 E1 S0=0 &C1 &D2 +FCLASS=0'
OK 'AT+CGDCONT=1,"IP","websfr"'
OK ATDT*99***1#
CONNECT ""

Finally you can:

pppd call gprs

Driver bnx2 du noyau Lenny et carte Broadcom NetXtreme II

Friday, May 8th, 2009

Le driver bnx2 du noyau Linux 2.6.26 de Debian Lenny (et du 2.6.24 d’half-and-etch) nécessite un firmware pour fonctionner avec les cartes réseau Broadcom NetXtreme II (présentes par exemple sur les serveurs DELL PowerEdge 1950/2950), au contraire du noyau Linux 2.6.18 de Debian Etch. Lors de la mise-à-jour vers l’un de ces noyaux, il faut donc installer le paquet firmware-bnx2 (section non-free) et s’assurer de mettre à jour les images initramfs (update-initramfs -u -k all).

Ferme ton Bind !

Sunday, February 1st, 2009

Il est important de fermer complètement son Bind, à savoir mettre dans son named.conf :

allow-query { localhost;};
allow-recursion { localhost; };
allow-transfer { none; };

Cela provoque un statut REFUSED pour toutes les requêtes non autorisées. Si refuser les transferts (requêtes AXFR dévoilant toute votre zone) est sage et refuser les requêtes récursives est logique (vous ne voulez pas être serveur DNS pour le monde entier), il faut également refuser toutes les requêtes par défaut afin d’éviter de potentiels dénis de service.

Vous noterez que les directives ci-dessus autorisent les requêtes classiques de la part de localhost dans la mesure où il est fréquent que votre machine se serve de son propre Bind. Si ce n’est pas le cas, mettre toutes les directives à none.

Un moyen simple de vérifier qu’un serveur DNS refuse bien toutes les requêtes :

dig google.fr @<serveur DNS>

Vous ne devez pas obtenir la(les) réponse(s), ni même obtenir la liste des ROOT SERVERS. Vous devez obtenir status: REFUSED (ou alors un timeout…).

J’ai souvent eu du mal à expliquer pourquoi il fallait fermer complètement son Bind, car la menace des attaques DOS restait un peu vague. Ce n’est désormais plus le cas depuis quelques semaines où chaque administrateur d’un Bind assiste (dans ses logs ;-) aux multiples requêtes “. NS IN” générées par des robots/virus :

client 76.9.16.171#39068: query (cache) './NS/IN' denied
client 69.64.87.156#42646: query (cache) './NS/IN' denied

On déplore même des victimes de ces attaques DDOS de grande ampleur, notamment NetworkSolutions qui l’explique sur son blog. Pour contrer cela, on peut refuser les paquets en amont : voici un fameux paquet (format PCAP). On voit donc que l’on peut interdire les paquets comportant une requête DNS récursive (flags = 0×0100). Sur une machine Linux, on peut le faire avec iptables et le module u32 (attention, il semble y avoir des bugs avec certaines versions) :

iptables -A INPUT -p udp --dport domain -m u32 --u32 "0>>22&0x3C@10=0x01000001" -j DROP

SI vous ne voulez pas interdire toutes les requêtes récursives, j’ai trouvé sur Internet une règle plus précise qui matche sur le “. NS IN” (voir commentaires de ce post) :

iptables -A INPUT -j DROP -p udp --dport domain -m u32 --u32 \
"0>>22&0x3C@12>>16=1&&0>>22&0x3C@20>>24=0&&0>>22&0x3C@21=0x00020001"

Enfin, sur l’excellent blog de Stéphane Bortzmeyer, vous trouverez plus de détails et des outils pour mesurer le nombre d’attaques sur votre serveur.

Set up IPv6 in Xen domU with nat-mode

Sunday, January 11th, 2009

I have a Xen dom0 with nat-mode and IPv6 enabled. Set up IPv6 in Xen domU is like a classical IPv6 network: add IPv6 addresses on vif interfaces on dom0 and IPv6 addresses on domU (manually or with radvd on dom0). The only tip is how adding IPv6 addresses on vif interfaces which are dynamically created by Xen. Here is my dirty hack to do it on /etc/xen/scripts/vif-nat file:

        [ "$dhcp" != 'no' ] && dhcp_up
        +# Add IPv6 addresses
        +[ "$vif_ip" = '192.168.0.1' ] && ifconfig "$vif" add 2001:6f8:143d:1::101:1234/64
        +[ "$vif_ip" = '192.168.0.2' ] && ifconfig "$vif" add 2001:6f8:143d:2::101:1234/64
        ;;
    offline)

Where $vif_ip is the IP address from domU configuration : vif=['ip=192.168.0.1].

I think the best solution is adding ipv6 option to domU configuration. I will consider to open a wishlist bug for that.

Conférence sur la sécurité et l’Open Source

Saturday, November 8th, 2008

À l’occasion du salon Synergie NTIC à Marseille, je suis intervenu environ 20 minutes dans une conférence à propos de la sécurité et l’Open Source. En résumé, j’ai parlé de la façon dont on doit se préoccuper de la sécurité quand on travaille avec des distributions ou logiciels Open Source. Notamment, j’ai parlé :

  • Du célèbre principe de Full Disclosure et de ses limites pratiques (période d’embargo),
  • Des moyens de faire une veille sécurité à propos de logiciels Open Source (listes de diffusion à suivre, etc.),
  • De la façon dont les distributions et logiciels Open Source s’organisent face aux problème de sécurité, en prenant l’exemple de Debian,
  • Du choix entre l’installation par paquets ou ports et l’installation via des sources vanilla,
  • D’exemples concrets de problèmes de sécurité récents : la faille concernant vmsplice dans le noyau Linux et du générateur de nombre aléatoire prévisible dans le paquet Debian openssl.

Vous pouvez télécharger les slides utilisés pour cette présentation (soyez indulgent, je les ai fait rapidement).

No /dev/net/tun in xen Linux domU

Wednesday, August 20th, 2008

No persistent /dev/net/tun in xen Linux domU… Hacky workaround is adding

mkdir /dev/net && mknod /dev/net/tun c 10 200

while booting (for example in rc.local or in your init.d script which need it).

For example tun device is useful for SSH VPN. Without it, you will have errors like:

channel 0: open failed: administratively prohibited: open failed

SFR GPRS with Debian

Wednesday, August 6th, 2008

I use Nokia E65 phone and SFR (french mobile phone provider). Note there is at least two possibilities for access: wapsfr (for WAP browsing and AFAIK illimited) and websfr (less restricted but with high-cost level). I will only speak about wapsfr here. For connecting, it’s the same method like Orange SFR with Debian excepted you set wapfr instead of orange.fr in /etc/ppp/peers/gprs-wvdial.conf file. Then you are now connected but access seems restricted to 80 and 443 ports via proxy (NetApp/6.0.7 NetCache appliance announced by HTTP headers). For HTTP browsing, you must change your User-Agent to Vodafone/1.0/HTC_Mercury/1.23.163.5/Mozilla/4.0 for HTTP browsing. Of course, no problem for HTTPS browsing. And for SSH (for example SSH tunnel to have a full Internet access), you can use corkscrew and a SSH server reachable on tcp/443 to bypass the proxy. Just “apt-get” it and launch:

ssh -o "ProxyCommand /usr/bin/corkscrew %h %p %h %p" -p 443 login@your_ssh_server

Petit patch indispensable pour PFW

Thursday, April 24th, 2008

PFW est un frontend web pour PF (OpenBSD Packet Filter). Voici un petit patch indispensable pour permettre d’éditer correctement les règles de NAT (version 0.7.8). D’autres patches suivront peut-être car de nouveaux bugs nous ont déjà été reportés.