Aujourd’hui je ne parlerais pas de… #1

1 juillet 2009 2 commentaires

Première fois que je me lance dans l’easy writing, ce principe d’écriture que beaucoup de blogueurs plus ou moins influant (ce concept me fait doucement rire) se permettent de mettre en scène pour x ou y raisons.

Pour cette toute première édition je l’aborderais sous un ton d’aigri profond, ca pourrait presque faire office de billet d’humeur tiens.

Aujourd’hui, 1 juillet 2009 je ne parlerais pas de:

Je ne comprend pas ce qui fait le buzz avec les versions de FF; La rengaine est toujours la même: Plus beau, plus fort, plus secure donc plus plus mieux, va pas chercher à comprendre on optimise le JS mais le renard se traine de plus en plus de mois en mois.

Bon ok, cette monture embarque HTML5, et alors il fallait bien y arriver et d’autres l’ont fait avant, à croire que 90% des utilisateurs de FF sont des marketeux.

La liberté cette notion qui ne tient qu’à un fil ou plutôt qu’à quelques dollars.

Moi qui parlait de TPB comme un symbole de la liberté et du mouvement anonyme qui enfle sur internet il y a si peu de temps, voila que je tombe dénue devant ce fait des plus déplorables.

Le pire dans tout ca ? La rumeur de délit d’initié qui tourne autours de la boite qui a rachetée TPB, quand un symbole quel qu’il soit tombe dans le burlesque et les magouilles financières on ne se rappellera que peu de temps de lui… enfin tout dépendra de son devenir, qui vivra verra comme j’aime à le dire.

Orange dans ces tentatives désespérées de recréer le même business que les lignes de cuivre (tu loues, j’impose) va tout faire pour ne pas voir les solutions concurrentes et moins avantageuses pour son business model dépassé arriver dans les goulottes de vos immeubles.

Ce feuilleton aussi palpitant que marrant oppose l’ARCEP à Orange… l’autorité à la puissance de l’argent. Pour l’instant Orange bluff, que va répondre l’ARCEP ou le gouvernement ?… A suivre dans un prochain feuilleton.

Un autre symbole qui est mort ces derniers jours, de la à pleurer et sortir faire son faux moonwalk dans la rue et crier « Michael on t’aime même s’il est possible que tu ais été le plus connu de tout les pédophiles de l’histoire, on te regrette» , ca en devient navrant.

Comme quoi il suffit de chanter une chanson à la voisine pour lui violer sa fille, va comprendre.

Quand je pense que mon feedreader est pollué de toute ces conneries du journal le monde (lien précèdent) au blog de presse citron (pour l’article sur MJ le moins pourri que j’ai pu lire) tout le monde exploite la faille émotionnelle engendrée par la mort de ce chanteur, c’est cool ca fait de l’audimat et ca aide kleenex à vendre des mouchoirs, mais c’est pour « rendre hommage»  donc c’est bien et personne ne râle.

Bref, seul point positif, les médias traditionnels ont l’air enfin de comprendre la puissance des médias sociaux.

Voila voila, c’est tout pour aujourd’hui.

5 questions avant de migrer des clients vers de l’Unix

1 juillet 2009 7 commentaires

On commence petit à petit voir apparaitre du coté parc client des Unix like (en particulier Linux), actuellement ca se cantonne aux développeurs mais je suis sur que dans les mois qui viendront nous devrions voir d’autres services migrer.

The IT Crowd - Open Rights Group poster!
Creative Commons License photo credit: barnoid

Mais avant même d’envisager d’établir un dossier pre-migration il faudrait se poser au moins 5 questions essentielles.

1. Les différents services ont ils des besoins spécifiques ?:
Avant même de s’attarder sur le passage à l’autre OS il faudrait inspecter les logiciels installés et utilisés sur le parc à migrer.
Par exemple il est pour le moment inconcevable de migrer un parc de graphistes vers du Linux pour une simple et bonne raison: Adobe n’édite pas ces logiciels de création sous linux (le premier qui ose me dire que Gimp arrive à la cheville d’une creative suite, il se prend une claque).
Autre exemple plus compliqué, la migration des machines utilisées par la horde de secrétaire à votre charge, nous savons que leur passe temps favoris c’est solitaire la suite office, nous pouvons la remplacé par une alternative open source reconnue: Open Office, le problème ce coup ci n’est pas le logiciel à proprement dit mais plutôt le cout de formation engendré par cette migration d’outil, il faut donc prendre en compte ce facteur même si les logiciels utilisés sembles tous avoir une alternative.

2. Le staff du SI ou mon prestataire informatique sont ils formés pour ?:
C’est une bonne idée de vouloir migrer son parc sur du Linux pour X ou Y raisons (généralement le cout d’acquisition quasi nul est un argument de poids pour la direction) mais faut il encore savoir si l’entreprise est dans la capacité de supporter cette migration et maintenir le parc une fois celle ci effectuée.
En effet le support et la maintenance des machines Linux est totalement différente (ou presque) de celle d’une machine Windows.
De plus les process de support Windows sont surement déjà écrits et entrés dans les conscience de tout le staff, encore une fois il y aura donc un cout de formation et un besoin de changer certaines habitudes après la migration.
Dans le cas ou votre SI est externalisé vous pouvez toujours demander à votre prestataire s’il peut prendre en charge la maintenance de ces machines, si la réponse est négative d’autres prestataires existent et je ne doute pas que vous arriverais à trouver chaussure à votre pied.

3. La direction va elle trouver son intérêt ?
Puisque tout SI est soumis à la validation de la direction (malheureusement vous n’êtes pas le guru dans tout ce que vous faites) il vous faudra convaincre.
C’est donc des intérêts que vous devrez trouver pour convaincre les décideurs, généralement appuyer sur ce qui fait mal (l’argent) est une bonne idée, mais pensez à aborder les avantages apportés à la productivité de vos employés, vous devrez en quelque sorte vendre votre initiative comme un technico commercial le ferait.

4. L’infrastructure peut elle supporter le changement ?
La le problème est un peu plus technique, vous ne rentrerez pas des machines sous Unix like dans un domaine AD facilement, il faudra passer par du LDAP et quelques astuces presques dignes du bricolage, c’est le prix à payer pour l’hétérogénéité des réseaux, avant même de parler de la migration des clients vérifiez que votre infrastructure service pourra accueillir les nouveaux types de clients.

5. Les utilisateurs sont ils prêts au changement ?
Enfin, vous pourrez faire tout comme il faut et voir la vie en rose, si les utilisateurs refusent expressément la migration pour x et y raisons, les foudres de la direction reviendront vers vous, un utilisateur ayant un espace de travail qu’il trouve austère et non adapté est un employé qui produira moins et qui perdra en rentabilité et efficacité.

C’est donc 5 questions primordiales à se poser avant toute migration, on constate au final qu’on pourrait résumer nos points à appréhender en 3 facteurs:

  • Social
  • Technique
  • Économique

Une fois que ces 3 points sont bien traités et que vous avez clairement envisagé toutes les possibilités vous pourrait passer à la création d’un cahier des charges et à l’élaboration de votre process.
Sachez que chaque point du dossier comptera, du choix de la distribution (Je vous conseille d’ailleurs de l’ubuntu du red hat ou encore du Suse, chacune de ces distributions est reconnue et pleinement supportée moyennant finances par leur entreprises respectives) aux modifications à effectuer coté back end.

La tache n’est pas facile mais le jeu en vaut la chandelle, pour l’économie mais aussi pour la flexibilité et la liberté qu’une telle solution apporte.

A bon entendeur,

Note rapide « FeedBurner» 

30 juin 2009 Aucun commentaire

J’ai enfin décidé à voir ce que donne FeedBurner (c’est surtout pour savoir combien j’ai de readers et voir un peu comment ils se comportent).

Normalement la migration s’est faite en toute transparence (simple rewrite), n’hésitez pas à me signaler un problème avec le feed.

Mise en place d’une solution de filtrage dédiée web (Part 2, PSAD)

30 juin 2009 Aucun commentaire

Chose promise, chose due: Voici la seconde partie concernant le filtrage dédié web.

Ce coup ci parlons de PSAD.
PSAD est un analyseur de logs iptables qui permet de repérer des comportements suspect grâce à un système de signatures (on pourrait presque le qualifier d’IDS).

Nous utiliserons PSAD pour lutter un tant soit peu contre les attaques DDoS.

On ne lutte pas contre un DDoS au niveau du système, on épanche juste au maximum les projections de sang pendant et après l’attaque.

Ce que PSAD fait:
En l’occurrence PSAD servira à maintenir notre service up, à établir une liste d’IPs bannies et à éviter le crash de la machine.

Ce que PSAD ne fait pas:
Il ne permettra par contre pas de maintenir un accès au service, si c’est ce que vous souhaitez il faudra vous orienter vers du load balacing (nginx/pound/…), en outre il est impossible de faire du café avec PSAD.

Note: Ce mini howto s’applique en particulier aux systèmes tournant sous Debian.

PSAD se trouve dans les dépôts Debian, son installation en est donc grandement facilitée:

1
apt-get install psad

L’installation a beau être facilitée, sa configuration n’en est pas moins à modifier.
Dans /etc/psad/psad.conf modifiez toutes les lignes suivantes, j’ai commenté je n’ai donc rien à ajouter:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
[...]
EMAIL_ADDRESSES             admin@ltd.com, root@localhost, xxx@xyz.fr;
 
HOSTNAME                    Nom_de_la_machine;
 
DANGER_LEVEL1               50;    # niveaux d'alerte
DANGER_LEVEL2               100;
DANGER_LEVEL3               250;
DANGER_LEVEL4               500;
DANGER_LEVEL5               600;
 
PORT_RANGE_SCAN_THRESHOLD   0; # On attend pas d'être scanné avant d'alerter
 
ENABLE_PERSISTENCE          N; # On introduit la notion de timeout
 
SCAN_TIMEOUT                3600;  # On remet à 0 les stats d'une IP au bout d'1H
 
MIN_DANGER_LEVEL            3; # On rentre en phase d'attaque au niv. 3
 
EMAIL_ALERT_DANGER_LEVEL    3; # Au ni. 3 on averti
 
ALERT_ALL                   N; # On précise qu'on ne veut être avertis qu'en cas de danger
 
IMPORT_OLD_SCANS            Y; # On importe les scans effectués precedemments
 
ENABLE_AUTO_IDS             Y; # Gestion automatique des rules iptables
 
AUTO_IDS_DANGER_LEVEL       5; # Au niveau 5 on ban
 
AUTO_BLOCK_TIMEOUT          36000; # 10H de ban
 
IPTABLES_BLOCK_METHOD       Y; # PSAD créer des règles iptables pour DROP

Rendes vous ensuite dans /etc/syslog.conf et ajoutez y ceci:

1
kern.info       |/var/lib/psad/psadfifo

Redémarrez ensuite psad:

1
/etc/init.d/psad restart

Ce qui devrait vous donner ceci:

1
2
3
4
5
6
# /etc/init.d/psad restart
Stopping Port Scan Attack Detector: Shutting down the psadwatchd monitoring daemon: psadwatchd.
Shutting down the psad daemon: psad.
Shutting down the kmsgs daemon: kmsgs.
psad.
Starting Port Scan Attack Detector and associated daemons: psad.

Pour avoir des statistiques concernant PSAD:

1
psad -S

Voila, il ne vous reste plus qu’à effectuer quelques test en fonction des niveaux de danger que vous avez mis et regarder si votre iptables se comporte comme il faut.

Pour rappel cet article va de paire avec celui ci.

A bon entendeur,

Mise en place d’une solution de filtrage dédiée web (Part 1, FW)

30 juin 2009 3 commentaires

J’ai cette nuit (0h > 1h) été victime d’une attaque DDoS sur le dédié hébergeant le blog, montrant à quel point mon script de firewall devenait ancien et peu fiable, j’ai décidé de l’épauler avec PSAD et de le hacher pour le simplifier et le rendre dédié à une seule utilisation: l’hébergement de sites ouaib sur un seul et même serveur, sans fioritures.

J’ai pour cela utilisé une base d’un script iptables de chez les gros lutins poilus de GCU (qui ont d’ailleurs sévis dans le GLMF de Juillet/Aout que je ne peux que vous conseiller de lire) et utilisé le magnifique PSAD pour le repérage et le traitement des attaques.

Coté script iptables, c’est beaucoup argumenté, je m’étendrais pas, veillez juste à appliquer un chmod +x pour le rendre exécutable et à l’intégrer à l’init qui va bien pour le lancer à chaque démarrage:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
#!/bin/bash
 
### Preparatifs ###
 
# On fixe les modules à charger et les diverses variables
IPTABLES=`which iptables`
 
RED="\033[31m"
GREEN="\033[32m"
YELLOW="\033[33m"
NORMAL="\033[m"
BOLD="\033[1m"
 
 
# On créer les alias d'interface
IFSE="ethO"
IFSI="lo"
 
# On flush en masse
echo -en "${BOLD}${YELLOW}Flush des règles:${NORMAL}"
${IPTABLES} -t filter -F INPUT
${IPTABLES} -t filter -F OUTPUT
${IPTABLES} -t filter -F FORWARD
${IPTABLES} -t nat    -F PREROUTING
${IPTABLES} -t nat    -F OUTPUT
${IPTABLES} -t nat    -F POSTROUTING
${IPTABLES} -t mangle -F PREROUTING
${IPTABLES} -t mangle -F OUTPUT
echo -e "\t\t\t\t${GREEN}OK${NORMAL}"
 
# On met tout à zero
echo -en "${BOLD}${YELLOW}Remise à zero des tables:${NORMAL}"
${IPTABLES} -t filter -Z
${IPTABLES} -t nat    -Z
${IPTABLES} -t mangle -Z
echo -e "\t\t\t${GREEN}OK${NORMAL}"
 
# On set les règles par défaut
echo -en "${BOLD}${YELLOW}Definition des regles par défaut :${NORMAL}"
${IPTABLES} -t filter -P INPUT   DROP
${IPTABLES} -t filter -P OUTPUT  ACCEPT
${IPTABLES} -t filter -P FORWARD DROP
echo -e "\t\t${GREEN}OK${NORMAL}"
 
### Filtrage ###
 
echo -en "${BOLD}${YELLOW}Etablissement des règles de filtrage :${NORMAL}"
# On autorise tout les services locaux
${IPTABLES} -A INPUT -i $IFSI -j ACCEPT
 
# On autorise les connexions déjà établies à passer
${IPTABLES} -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
 
# On autorise les différents services utilisés
${IPTABLES} -A INPUT -p tcp --dport 22 -i eth0 -j ACCEPT
${IPTABLES} -A INPUT -p tcp --dport 21 -i eth0 -j ACCEPT
${IPTABLES} -A INPUT -p udp --dport 21 -i eth0 -j ACCEPT
${IPTABLES} -A INPUT -p tcp --dport 80 -i eth0 -j ACCEPT
 
# On accepte le ping
iptables -I INPUT -p icmp --icmp-type destination-unreachable -j ACCEPT
iptables -I INPUT -p icmp --icmp-type source-quench -j ACCEPT
iptables -I INPUT -p icmp --icmp-type time-exceeded -j ACCEPT
echo -e "\t\t${GREEN}OK${NORMAL}"
 
# PSAD DDoS log
echo -en "${BOLD}${YELLOW}Integration de PSAD  :${NORMAL}"
DIR="/usr/src/fw"
INTERVAL="5"
HITCOUNT="20"
SF="ddos.conf"
 
cd $DIR
if [ -f $SF ]; then
       IPS=$(grep -Ev "^#" $SF)
  for i in $IPS
  do
       iptables -A INPUT -s $i -j ACCEPT
  done
fi
 
iptables -A INPUT -m state --state NEW -m recent --set
iptables -A INPUT -m state --state NEW -m recent --update --seconds $INTERVAL --hitcount $HITCOUNT -j LOG
echo -e "\t\t\t\t${GREEN}OK${NORMAL}"

Vous noterez que j’utilise actuellement un dir /usr/src/fw, le script étant toujours en test, je vous conseille de le passer dans du /usr/local/xx.

Je ne vous met à disposition pour le moment que la partie firewall, je ferais un petit post demain concernant la partie PSAD qui est un poil plus complexe.

En attendant si vous avez des remarques ou des suggestions à apporter au script présenté, je suis ouvert et prêt à intégrer.

A bon entendeur,