Blogger pour rien dire!

Depuis environ 1 an l'idée de mover complètement vers le cloud pour mes besoin d'hébergement web, courriel, vpn, mumble, et bien plus. J'ai fait plusieur test, j'ai sauvegardé quelque snapshot pour mes besoin ponctuel en serveur. J'ai écrit quelques script pour syphonner mes config à partir d'un volume S3 au démarrage. Bref, il me reste a essayer le fameux cloud watch et tester le failover afin d'être redondant et ne pas être trop stressé si un désastre survient pendant que ma blonde accouche ;)

Un de mes gros problème était quessé je vais bien faire avec mes DNS comment est-ce que je vais en faire la gestion?

Depuis quelque jours je magazine les prix des "DNS as a Service" et ouf je suis pas mal découragé de voir les prix pour cela. Je suis consient que c'est une grosse responsabilité qu'on leur confie mais dans mon cas pour un lot d'environ 35-40 nom de domaines ça me couterais plus de 100$ par mois ... avec cela j'ai toujours d'ip/serveur sur lequel pointer ces nom! 100$ par mois c'est ce que je paie pour mon serveur dédié! voir si je vais payer le même pris pour que quelqu'un gère mes dns et ensuite payer le même prix si pas plus cher chez amazon en EC2, S3, EBS, CloudWatch, SimpleDB, disk IO, traffic web, loadbalancer, ElasticIP, etc.

J'en suis a me questionner et voir si je ne gèrerais pas mes DNS à même le cloud! 2 micro instances dans 2 datacenter éloignés, volume de traffic assez faible, pas énormément d'accès disque, pas besoin d'un énorme volume il reste a voir comment ça se gère quand une instance meurt. J'ai aussi regardé le "route 53" de amazon, mais pour le moment ça reste des idées à explorer.

Bref que de plaisir en perspectives!

Le site wiki.php.net semble avoir été attaqué dernièrement :(

php.net security notice

[19-Mar-2011]
The wiki.php.net box was compromised and the attackers were able to collect wiki account credentials. No other machines in the php.net infrastructure appear to have been affected. Our biggest concern is, of course, the integrity of our source code. We did an extensive code audit and looked at every commit since 5.3.5 to make sure that no stolen accounts were used to inject anything malicious. Nothing was found. The compromised machine has been wiped and we are forcing a password change for all svn accounts.

We are still investigating the details of the attack which combined a vulnerability in the Wiki software with a Linux root exploit.

Voici un article en anglais qui explique une faille de sécurité qui se trouve dans le browser de Android.

La faille en question se situe dans le navigateur web et permet d'accéder à des fichiers sur la carte SD.

A security officer has stumbled across a serious vulnerability in the built-in browser of Android smartphones that might allow hackers to lift data from SD cards in the Google handsets.

Heureusement, il y a un workaround qui consiste à installer un nouveau browser, opera ou firefox mais toujours est-il que la faille restera présente pour la plupart des gens et cela pour un temps indéterminé. Le correctif sera présent dans la version Gingerbread, mais cela ne fera pas en sorte que les fournisseurs de cellulaire, pour ne pas nommer Rogers, Bell et les autres, vont pousser une mise à jours pour corriger la situation. Rappelons-nous que lors de la faille du 911, qui était d'ordre critique voire même tragique, ils ont mis 8 mois avant de pousser une mise à jours...

Il y a quelques années, quand j'ai acheté mon premier portable, les réseau sans-fil était tout neuf. Personne ne les sécurisait, le wardrivin' était à la mode dans mon entourage. J'avais même volontairement laissé mon wifi ouvert afin d'espionner mes voisins qui décidaient d'utiliser ma connexion internet. En faisant cela, j'ai réalisé ce qui se passe quand on ne contrôle pas notre dhcp et/ou notre gateway vers internet. C'est à ce moment que j'ai décidé d'encapsuler mes communications dans un tunnel VPN. J'ai essayé plusieurs technologies: IPSEC, CIPE, pptp, des tunnel SSH bidon, mais rien n'était satisfaisant, souvent trop de manipulations à faire à chaque fois qu'on se connecte. J'ai longtemps utilisé CIPE ( Crypto IP Encapsulation ) un logiciel très simple à configurer comparativement à IPSEC mais il comporte encore quelques lacunes. Un jour, apparu, OpenVPN!!

Depuis plusieurs années, j'utilise OpenVPN dès que j'ai besoin d'une solution vpn. Simple, stable, sécuritaire, supportant plusieurs niveau d'authentification, du proxy http, bref rien à dire de plus pour me convaincre. Il y a même des outils hyper simple à utiliser pour faire la gestion des clef SSL.

La première étape est de se configurer un serveur OpenVPN.

Voici mon setup. J'utilise Centos 5.5, mais n'importe quelle version de linux/bsd ferait le travail tout aussi bien. Il se peut que les path des logiciel ne soient pas au même endroit, mais le concept reste le même.

Voici les grande lignes:

* Installer OpenVPN sur le serveur
* Générer les clefs SSL
* Éditer le fichier server.conf
* Paramétrer notre firewall
* Copier certaines clefs vers nos clients ( portable, téléphone cellulaire, etc. )
* Configurer notre client pour se connecter sur notre serveur.

yum install openvpn
cd /etc/openvpn/
cd easy-rsa

### configurer le fichier "vars" et répondre aux questions qui nous sont demandées.

. ./vars
sh clean-all
sh build-ca
sh build-key-server my-srv
sh build-key my-cli1
sh build-key my-cli2
sh build-key my-cli3
sh build-dh
openvpn --genkey --secret ta.key
cp keys/*.crt ../keys/
cp keys/*.key ../keys/

Quant à la configuration du firewall, je n'entrerai pas dans les détails. Brièvement, j'utilise du SNAT étant donné que j'ai une ip fixe ( chez iWeb ), mais si j'étais hébergé à la maison j'utiliserais fort probablement du Masquerade et un Dyndns.

Éditer /etc/sysctl.conf et s'assurer que les lignes suivantes sont présentes:

net.ipv4.ip_forward = 1
net.ipv4.conf.default.rp_filter = 1

# relire notre config et l'appliquer
sysctl -p

iptables -t nat -A POSTROUTING -s 10.18.137.0/255.255.255.0 -o eth0 -j SNAT --to-source 72.55.147.X
iptables -I RH-Firewall-1-INPUT -d 72.55.147.X -p udp -m udp --dport 1194 -j ACCEPT
service iptables save

Ensuite, on peut éditer /etc/sysconfig/iptables ou votre quelconque script de firewall.

Voici mon fichier de configuration

local 72.55.147.X
port 1194
proto udp
dev tun
ca keys/ca.crt
cert keys/serveur.crt
key keys/serveur.key  # This file should be kept secret
dh keys/dh2048.pem
server 10.18.137.0 255.255.255.0
ifconfig-pool-persist ipp.txt
push "redirect-gateway def1"
push "dhcp-option DNS 10.18.137.1"   # rediriger son dns sur une machine qu'on contôle!
keepalive 10 120
tls-auth keys/ta.key 0 # This file is secret
comp-lzo
persist-key
persist-tun
status openvpn-status.log
verb 3

Ensuite il faut copier nos clef "clients" vers nos ordinateurs portables. Dans mon cas, j'utilise TunnelBlick sur macosx et le client OpenVPN qui vient avec Android.

Pour utiliser OpenVPN sur son cellulaire il faut malheureusement l'avoir préalablement rooté son appareil. Je n'entrerai pas dans ces détails, mais sur ce site ils ont tout expliqué comment faire: http://www.cyanogenmod.com/ Lorsque CyanogenMod-6.0, de préférence, est installé, on va dans le Market, on installe OpenVPN-Installer et OpenVPN-Settings. Ensuite, il faut copier les clefs ca.crt, ta.key, my-cliX.crt. my-cliX.key dans un répertoire qui s'appelle openvpn à la racine de notre carte SD.

Voici le fichier de configuration que j'ai sur mon appareil: Notez qu'il a été créé par OpenVPN-Settings et qu'il est ensuite facilement éditable à partir de notre ordinateur.

client
dev tun
proto udp
remote 72.55.147.X 1194
resolv-retry infinite
nobind
persist-key
persist-tun
ca ca.crt
cert my-cliX.crt
key my-cliX.key
tls-auth ta.key 1
comp-lzo
verb 4

Ceci étant fonctionnel, j'ai tout de même quelques désagréments. Le vpn ne s'accroche pas automatiquement au démarrage du wifi. Si le téléphone tombe en veille ça cause parfois problème lors du réveil. Quand on est dans un environnement où il y a plusieurs bornes ( cégep, université, etc ), il se peut qu'en se déplaçant, et qu'on change de borne, le routing se brise, mais rien de terrible... Off/On du vpn et le tour est joué.

Attention à votre batterie! Elle se vide à vue d'oeil.

humm la vie sans internet n'a plus aucun sens, il y a eu une tempête et l'électricité a soudainement disparue. Heureusement j'ai une batterie sur mon ordinateur portable ainsi qu'un téléphone avec Android. En quelque secondes j'ai installé une application pour faire du tethering ... avec cela je partage le réseau wifi de mon charmant petit téléphone et ainsi utiliser la connexion 3G que mon fournisseur m'offre. Ah que c'est beau de pouvoir utiliser ces applications gratuite sur un téléphone dont j'ai le plein contrôle.

C'est à mon grand malheur que samedi passé je reçois un SMS de la part de Rogers me disant que je devrai nécessairement appliquer leur mise à jour obligatoire. Ayant rooté mon appareil, je me dit, ouf encore une magouille pour me rendre la tache encore plus compliquer pour rouler la version 1.6.

Je comprends très bien l'impact et la nécessité d'appliquer cette mise à jour qui corrige un bug relié aux appels acheminés au service 911 si on a le GPS d'activé. Pour forcer les gens à se mettre à jour ils ont décidé de désactiver le plan data a tout les détenteurs de HTC Dream ou Magic. Certain vont dire, mais ou est le lien avec le fucking GPS! L'application Google Maps utilise le GPS et va siphonner des données sur internet, donc ils ont jugé que si quelqu'un utilise le gps, il devra utiliser son plan data afin d'avoir une map qui contient des informations pertinentes. Donc en désactivant le data, les gens ne peuvent plus utiliser leur appareil comme un GPS dans la voiture ( ou dans mon cas à vélo ).

Personnellement j'ai un gros problème avec cette mise à jour car depuis septembre passé, la version 1.6 a corrigé ce bug... j'utilise et aime bien cette version comparativement à la version d'origine ( 1.5 ). Cette mise à jour va aussi Wiper tout les contact et applications sur le téléphone... style un FORMATTAGE! Je me retrouve face a une situation ambiguë, je dois contacter Rogers pour leur dire que j'ai pas appliqué la mise à jour et que j'ai aucune intention de l'appliquer, et que mon appareil n'est pas vulnérable à ce bug du 911 sans toute fois leur dire que j'ai rooté mon appareil. J'ai passé beaucoup de temps sur les forums de discutions à voir ce que les gens allaient faire.

Teteux comme je suis je les ai appelés à répétition pour qu'ils m'aident à mettre à jour mon appareil. Ils m'ont tous pris par la main afin que je me rende sur le site web avec la petite procédure. Une fois rendu sur la page, je leur dit que j'utilise Linux comme système d'exploitation et que j'ai pas accès a un ordinateur qui a windows peu importe la version, ni d'amis qui ont des mac. La c'est comique de les entendre patiner à se demander ce qu'ils vont faire. Finallement après avoir eu beaucoup de plaisir à engorger leur soutien technique, j'ai décidé de leur dire que j'ai repris mon vieux Nokia 6275i que j'avais chez bell mobilité... J'ai dit au gars du tech support que j'ai transféré ma sim dans mon ancien appareil que j'avais chez bell. Il a simplement fait son "network refresh" sans plus poser de questions.

Je suis content de la situation car j'ai mon accès a mon plan data, je ne suis pas vulnérable au cas ou je voudrait appeler le 911, et ce même si je suis entrain de jouer sur google maps avec mon gps.

Voici un lien intéressant sur le sujet

Vendredi passé, j'applique diverses mises à jours, et ce matin je rentre au bureau avec la mauvaise surprise que tous mes serveurs qui utilisent le combo postfix et selinux en mode enforcing me causent de petits problèmes. Heureusement, aucun d'entre eux sont des serveur de courriel, ils ne font qu'envoyer divers rapports de tache cron.

Bref, ce matin j'ai fouillé un peu sur le bugzilla de redhat de redhat et j'ai trouvé un petit workaround. Rien de trop compliqué..

echo "test" |mail -s "test" root
send-mail: warning: premature end-of-input on /usr/sbin/postdrop -r while reading input attribute name
send-mail: fatal: root(0): unable to execute /usr/sbin/postdrop -r: Success

yum install selinux-policy-devel

Créer un fichier mypostfix.te
vim /usr/share/selinux/devel/mypostfix.te

========CUT========
policy_module(mypostfix, 1.0)

gen_require(`
 type sendmail_t;
 type postfix_postdrop_t;
')

allow postfix_postdrop_t sendmail_t:unix_stream_socket { getattr read write ioctl };
==================

cd /usr/share/selinux/devel/; make -f Makefile
semodule -i mypostfix.pp

# On test que tout va bien.
echo "test" |mail -s "test" root

J'ai une vingtaine d'invitations disponibles si jamais quelqu'un voulait tester la nouvelle plateform de travail collaboratif de google. Je ne l'ai pas vraiment essayé depuis que j'ai reçu mon invitation, mais je serais ravis d'en faire l'essai avec mes fidèle lecteur de mon blogue que je délaisse un peu trop. Les invitations iront premier arrivé premier servis, donc j'attends avec impatience vos commentaires!

Ça fait déjà un bon nombre d'années que l'on peut enregistrer des nom de domaines ayant des caractères accentués. Je ne m'étais pas encore décidé d'en acheter un et de voir comment le tout fonctionnait avant cette semaine. Suite à mon expérimentation qui ressemble plus a beaucoup de lecture sur l'algorithme punycode qui est utilisé pour représenter les caractères bizarre ou accentués en ASCII. J'ai songé à cela un peu et en tant que tel, pour nous les francophones notre alphabet est tellement proche de l'anglais que ça ne nous cause pas de réel problèmes.

Prenons comme exemple un site populaire qui s'appelle météomédia qui utilise meteomedia.com comme nom de domaine. Tout est beau, le nom est très proche de la réalité et souvent à l'école les gens écrivent des caractères accentués avec un simple barbeau qui rend cela difficile à déterminer si l'auteur voulait écrire un é è ë ê. Bref pour la langue française c'est mineur comme avantages mais pour les gens en Asie ou leur alphabet ne ressemble pas du tout à nous ça deviens d'autant plus intéressant d'avoir des IDN. ( Internationalized domain names )

Le problème que l'on rencontre c'est que depuis qu'un tata a décidé d'enregistrer ωωω.ραyραl.com ou un autre genre de déviation du nom original afin de faire du phishing. Les navigateurs firefox et IE ont décidé de ne plus afficher le nom avec les caractères internationales mais plutôt d'afficher le résultat punycodé ce qui est un peu ordinaire à mon avis.

Ex: www.là-bas.com deviens www.xn--l-bas-rqa.com

Pour m'amuser j'ai aussi créé ωωω.là-bas.com

Je dois avouer que la configuration au niveau des dns n'est vraiment pas évidente à relire... C'est pas que c'est compliqué à faire mais visuellement c'est pas évident à voir qu'est-ce qui est quoi. Même chose dans la config de apache :)

$ORIGIN xn--l-bas-rqa.com.

@       IN A    72.55.168.14
www     IN A    72.55.168.14
xn--byaaa       IN A 72.55.168.14

    ServerName www.xn--l-bas-rqa.com
    ServerAlias xn--l-bas-rqa.com xn--byaaa.xn--l-bas-rqa.com
 

Bref tout la mécanique est en place pour que ça soit fonctionnel et utilisable mais les navigateurs nous mettent indirectement un bâton dans les roues sous prétexte que c'est pour protéger les gens contre les arnaques. Je vous laisse songer à tout ça et j'attends vos commentaires que je lis toujours avec grand plaisir.