0
Posted by alex on Aug 22nd, 2008

elephpant-elephant-php-logoPour ceux d'entre vous qui font du PHP le moindrement sérieusement, vous avez sans doute remarqué que PHP manque quelque chose du coté de la POO.

C, Visual Basic, C#, et plusieurs autres langages ont la capacité d'avoir des variables publiques en lecture seule dans une classe. C'est à dire que la variable peut être modifié à l'intérieur de la classe, mais à l'extérieur on ne peut que la lire !
Prenons l'exemple suivant:

J'ai une classe qui s'appelle utilisateur et qui gère une session utilisateur:

Class utilisateur {

[....]

public $id = 0;

public $nom = '';

[....]

}

Admettons que les valeurs de $nom et $id proviennent d'une base de données, il serait fort probablement utile de pouvoir y accéder depuis l'extérieur de la classe! Bref j'aimerais pouvoir lire $nom et $id mais je ne veux pas qu'elles puissent être modifier à l'extérieur de la classe (cela pourrait causer des erreurs, des problèmes de sécurité, des problèmes de conception, etc).

Par exemple:

echo "Je suis  {$utilisateur->nom} et mon id est {$utilisateur->id}";

Mais en les mettant publique, il y a un problème, on peut aussi les modifier depuis l'extérieur de la classe. Parfois cela est voulu, mais souvent cela pourrait provoquer des erreurs.

$utilisateur->nom = 'robert';

echo "Je suis  {$utilisateur->nom} et mon id est {$utilisateur->id}";

Une solution à ce problème serait l'utilisation de getters, mais cela est très peu pratique si nous avons beaucoup de variables.

Par exemple:

Class utilisateur {

[....]

private $id = 0;

private $nom = '';

public function getNom(){

return $this->nom;

}

public function getId(){

return $this->id;

}

[....]

}

echo 'Je suis  '.$utilisateur->nom().' et mon id est '.$utilisateur->id();

À force de me creuser les méninges, j'en suis venu à une idée basée sur l'utilisation des méthodes magiques. (Pour ceux qui ne connaisse pas, les fonctions __get et __set sont appelées lorsqu'aucune variable publique ne correspond à celle demandé). Une petite astuce permet d'avoir des variables en readonly sans avoir recours à un getter pour chaque variable!

exemple:

Class utilisateur {

[....]

private $id = 0;

private $nom = '';

public function __get($name){

return $this->$name;

}

[....]

}

echo "Je suis  {$utilisateur->nom} et mon id est {$utilisateur->id}";

$toto->nom = 'robert'; // Va retourner une erreur :)

Et voilà, c'est magique ! Il reste un inconvénient (mais qui est facilement contournable) : On ne veut pas forcément donner accès à toutes nos variables privée publiquement, même si ce n'est qu'en lecture ! Il y a plusieurs façons de contourner ça, par exemple précéder toutes ses variables publiques+readonly par un underscore:

public function __get($name){

if ($name[0] === '_') return $this->$name;

}

Ou encore utiliser un array de variable readonly (mais ce n'est pas forcément performant...):

public function __get($name){

$readonly = array('id','nom');

if (in_array($name,$readonly)) return $this->$name;

}

Les exemples dans cet article devrait être complété avec des vérifications d'erreurs, des isset et l'appel à quelques autres méthodes magiques, mais dans un soucis de simplicité je n'expliquerai pas tout dans cet article :P

Enfin bref, vous comprennez le principe, à vous de vous amusez :)

Bonne prog !

0 comment
0
Posted by alex on Jun 16th, 2008

J'ai récemment fait l'acquisition d'un nouvel ordinateur portable équipée d'un processeur Core 2 Duo d'intel (architecture Santa Rosa Refresh). Après quelques jours d'utilisation sur l'alimentation secteur je décide de le débrancher afin de tester les limites de mon réseau sans fil. C'est à ce moment que le drame se produisit: Un petit sifflement (comme des milliers de beeps très rapides; un peu comme du code morse accéléré) venait de l'ordinateur !

Au début je n'y faisait pas trop attention, étant habitué à des cartes graphiques haut de gamme je savais très bien que du matériel informatique pouvait émettre un léger sifflement lorsqu'il est chargé, mais ça devint très vite agaçant. Le sifflement était présent seulement lorsque l'ordinateur fonctionnait sur la batterie et lorsque qu'il ne travaillait pas (idle ou presque). J'ai aussi remarqué que lorsqu'un périphérique usb était branché le cillement diminuait nettement. Sachant que Windows désactive les modes de veille profonde pour le CPU (C3 et C4) (correction: à vrai dire non il ne les désactive pas, mais plutôt il n'arrête jamais vraiment le cpu) lorsqu'un périphérique usb est présent, j'en ai donc déduit que c'était un problème au niveau de la gestion de l'énergie.

Après quelques recherches j'ai découvert que c'était généralisé à tous les ordinateurs utilisant la plateforme Centrino. Autant sur les ordinateurs d'entrée de gamme que ceux haut de gamme.

Pour ceux qui se demande ce dont je parle voila: http://www.youtube.com/watch?v=ErkhU2qK-fM

Dans mon cas c'était beaucoup moins fort.

Je suis parvenu à trouver plusieurs solutions à mon problème. Mais aucune n'est totalement satisfaisante pour le moment... Enfin je vous fait un petit résumé, ça peut vous aider !

Solution 1:

Si possible désactiver le mode C4 dans le BIOS.

+: Le sifflement arrête totalement. C'est une solution dans le BIOS, donc relativement sécuritaire.

-: Le processeur chauffe légèrement plus (puisqu'il dort moins, dans mon cas je vois une augmentation(en idle) de près de 4-5 degré, c'est loin d'être satisfaisant). L'autonomie de la batterie est légèrement réduite (en théorie, dans mon cas j'atteins approximativement le même temps qu'avant. Disons que dans le pire des cas ça va vous amputer de 4 à 8% de la durée de vie de votre batterie)

Solution 2:

Si votre bios ne permet pas de désactiver le mode C4 vous pouvez alors utiliser un petit logiciel qui va vous permettre de le faire. Ce programme s'appelle RMClock et existe en version gratuite.

Une fois le logiciel installé il faut aller dans la section "Advanced CPU Settings" -> Onglet Chipset -> Cocher "Disable C4 mode"

Appuyer sur "Apply" et le sifflement devrait disparaitre instantanément !

+:Solution efficace et simple

-: Même chose que solution 1 et en plus c'est relativement instable puisque le OS pense que le mode C4 est toujours disponible, un plantage peut survenir à tout moment. On s'encombre d'un logiciel. De plus il provoque des plantages aléatoire sur certain ordinateurs. Et évidement on doit être sous windows pour l'utiliser.

Solution 3:

Cette solution est identique à la solution 2 mais à la place de cocher "Disable C4 mode" nous allons décocher "Enable popup mode" et "Enable popdown mode"
+: Semble être plus stable que la solution 2 et sans gâcher autant de d'autonomie. Je n'ai pas tester profondément mais ça ne semble pas faire chauffer le processeur d'avantage (notez quand même une différence d'un ou deux degré).

-: C'est une solution logiciel qui ne fonctionnera que sous Windows. Avoir ces options dans le BIOS serait un très grand avantage ! Espérons que les constructeurs y pensent. Toujours une petite perte d'autonomie mais rien de catastrophique.

Solution 4:

Si vous êtes sous linux, il est possible de recompiler le kernel sans le support du mode C4 ou de le patcher.

+: C'est une solution propre, pas de logiciels supplémentaires, pas de changement dans le BIOS.

-: C'est peut être un peu compliqué à mettre en œuvre pour la plupart d'entre nous puisque cela implique une recompilation du kernel. Il est toutefois possible que la désactivation du mode c4 puisse se faire en run-time, c'est à dire pendant que le système fonctionne sans rien recompiler, mais je n'ai pas trouver comment.

Conclusion

Comme je le disais, aucune solution ne me satisfait totalement. La dernière solution semble être la meilleure, mais je déteste devoir m'encombrer d'un logiciel qui va faire ça à chaque démarrage. Bref la troisième solution mais ajustable depuis le BIOS ferait mon bonheur. En attendant je vie avec le bruit et lorsque je dois travailler dans un endroit plus calme je désactive le mode C4 depuis le bios (mais je vais tester d'avantage la troisième solution prochainement pour vous en donner des nouvelles)

Annexe:

Popup/Popdown: Cela signifie un changement progressif du mode de veille du processeur. Par exemple si le cpu est en mode C4, avec Popup activé il va passer par C3,C2 avant de retourner en C1.

0 comment
1
Posted by alex on May 6th, 2008

Pour un débutant, iptables peut être extrêment difficle à maitriser puisqu'il implique soit: de bien connaitre les différentes couches d'un réseau et les techniques de routage de base, soit de connaitre les arguments par coeur sans forcément les comprendres.

Je vais donc rassembler ici des petits exemples de commandes qui pourraient éventuellement vous être utiles. Si vous essayez de faire une règle de routage, de rebond, de redirection ou de dénie qui ne se trouve pas dans la liste, dites le moi et si j'ai le temps j'essayerai de l'écrire pour vous, et de l'ajouter dans cette liste.

C'est quoi Iptables ?

Iptables est une application en ligne de commande qui sert à configurer les règles du filtre de paquets du kernel de Linux (depuis 2.4). Il peut être utilisé autant comme firewall(plutot pour appliqué les règles du firewall) que pour configuré les NAT (Network Address Translation: la réécriture des headers des paquets et le réacheminement de ceux-ci. Du routage quoi.)

1. Interdire les connexions entrantes d'une certaine IP (Bannir)

bash-3.1# iptables -A INPUT -s 255.255.255.255 -j DROP

2. Interdire les connexions sortantes vers une certaine IP

bash-3.1# iptables -A OUTPUT -d 255.255.255.255 -j DROP

3. Bloquer tous les genres de requêtes ICMP [ping,trace,echo request, etc]

C'est dans un but de sécurité (ça réduit nettement l'impact d'une attaque DoS icmp (ping flood)) Évite de deviner le OS du système. Plusieurs autres avantages..

bash-3.1# iptables -t filter -A INPUT -p icmp -i eth0 -j DROP

4. Bloquer les connexions sortantes sur un port et une ip en particulier.

Dans cette exemple les connexions sortantes de 1.2.3.4 (ip local,source) vers n'importe quel IP extérieur sur le port 25 seraient refusées.

bash-3.1# iptables -A OUTPUT -p tcp --dport 25 -s 1.2.3.4 -j DROP

5. Routage des paquets d'un port à un autre (ou d'une ip à une autre)

Si vous avez plusieurs IP ou souhaitez rediriger des ports cette commande est pour vous.

Prenons comme exemple que votre application en local écoute sur le ip:port 1.2.3.4:25, et vous souhaitez que les clients puissent s'y connecter depuis un autre port mais sans forcer l'application à écouter sur deux ports. Avec la ligne ci-dessous les clients de l'extérieur pourront s'y connecter depuis le ip:port 1.2.3.4:25 ET 1.2.3.4:250.

bash-3.1# iptables -t nat -A PREROUTING -d 1.2.3.4 -p tcp --dport 250 -i eth0 -j DNAT --to 1.2.3.4:25

6. Voir toutes les règles de iptables

bash-3.1# iptables --list

7. Flusher les règles de iptables (effacer toute les règles)

bash-3.1# iptables --flush

Note: Les exemples utilisent les connexions venant de l'interface eth0 et étant destinés à 1.2.3.4 (l'adresse publique de eth0). Il faut aussi savoir qu'iptables ajoute une charge supplémentaire sur la couche réseau du kernel. Si vous avez besoin de faire du QoS ou du filtrage de façon plus intensive, un firewall matériel est beaucoup plus approprié ;) . Les valeures en rose sont celles que vous aurez sans doute à modifier.

Read more...
1 comment
3
Posted by alex on May 5th, 2008

Un petit survol des aspects de sécurité de base sur un serveur.

Première étape: Les applications

Bien lire la documentation des applications. Générallement, il est préférable d'utiliser les versions les plus récentes puisqu'elles corrigent bien souvent les failles connues. Après avoir lu la documentation rigoureusement, assurez vous de bien configurer les applications pour qu'elles répondent parfaitement à vos besoins et qu'elle soit sécurisée. La configuration par défaut est la pour fonctionner out of the box, pas pour être utilisé en production. Utiliser la loi du gros bon sens: Le root ne devrait jamais pouvoir se connecter directement au serveur (ssh), de même qu'AUCUN compte ftp ne devrait avoir une racine plus haute que son dossier personnel. Pour php pensez à l'open_basedir et à interdire l'execution de programmes externes (ou chrooté votre serveur, voir plus bas) et ce même si votre machine n'est pas partagé (Une faille dans VOTRE application pourrait tout détruire). Une étape importante est l'obscurcissement. Ne laissez pas trainer la moindre information qui pourrait aider un hacker : cacher les versions de vos applications, cachez les chemins de vos scripts critiques (par exemple un phpinfo ne devrait pas montrer le chemin de votre application principale). De même qu'un compte admin ne devrait jamais s'appeler root ou admin. (Je pense ici surtout au serveur de base de données).

Deuxième étape: Les permissions et attributs des fichiers

Une fois les fichiers de configuration personnalisés, vous devez règler les bonnes permissions et les bons attributs si vous ne voulez pas que n'importe qui puisse les lire ou pire les modifier. En règle générale, une permission de 0400 suffit pour les fichiers de configuration d'un démon ou d'un service et le propriétaire doit être root:root puisque c'est lui qui démarre les services. Une protection supplémentaire est de rendre le fichier immuable. Cela va empêcher même le root de le modifier, à moin qu'il enlève explicitement l'attribut immuable. Excellente protection contre les fausses manipulations et les failles ftp / injections.

Troisième étape: La surveillance

Lire les logs n'est pas une tâche très intéressante je vous l'accorde. Mais vous devez le faire. Évidement il est plus judicieux d'utiliser des analyseurs de logs ou bien d'écrire vous même vos scripts afin de repèrer rapidement une activité suspecte. La surveillance du système entier est très importante. Pourquoi ? Parce qu'un pirate sérieux ne posera peut être pas d'acte de vandalisme, il va simplement se laisser un backdoor (une porte dérobée) afin de pouvoir se reconnecter facilement à votre serveur, et ce, même si la faille utilisée est bloquée entre temps. Pourquoi ferait-il cela ? Si un jour il a besoin d'une passerelle dans le but de commettre des actes illégaux (envois de spam, piratage, déni de service) visant quelqu'un d'autre, il va déjà avoir accès à votre machine. Un hacker talentueux va même aller jusqu'à installer un rootkit afin de masquer leurs présence et les backdoors installées. Les rootkits sont très difficiles à détecter, sauf si on le détecte pendant son installation (voir watchdog plus bas). Une analyse forensique (après l'incident) permet de reconstituer les actions et les motivations d'un intrus. Cela consiste bien souvent à récuperer des données ayant été effacés (logs).

Quatrième étape: Le chien de garde

Ou outil de surveillance système en temps réel. Vous ne pouvez pas toujours être devant votre ordinateur à surveiller les logs ou le système. C'est pourquoi un watchdog peut être utilisé (codé par vous ou bien déja fait tel que monit) afin de surveiller l'activité des services. Par exemple il pourrait redémarrer un service qui aurait planter, ou en tuer un qui s'emballe afin de le redémarrer. Il peut surveiller périodiquement les fichiers critiques et restaurer une copie originale (situé dans un endroit protegé) si il détecte une modification innatendue. Dans l'extrème il pourrait même mettre le système en alerte et bloquer tous les accès en attendant l'administrateur si il trouve une activité suspecte. Le watchdog peut aussi surveiller les connexions ssh en temps réel. Bref le watchdog fait ce que vous voulez, faut juste penser à le faire ;) .

Cinquième étape: Limiter les dégats

Bon, une catastrophe se produit et un pirate s'infiltre ! Même si vous pensez avoir tout prévu, une faille peut être trouvé à n'importe quel moment dans une application que vous utiliser. C'est pourquoi il est important de limiter les dégats si un utilisateur réussit tout de même à infiltrer le système. Si votre watchdog est bien conçu, il va réussir à bloquer l'accès à l'intrut assez rapidement. Mais il ne faut pas s'y fier. Ici encore les notions de permissions de fichiers sont très importantes. Pensez à cacher, ou à rendre le plus difficilement accessible la moindre information critique. Une solution afin de "limiter" les dégats est le chroot. Si vous chrooter vos applications, le pirate sera coincé dans sa prison "virtuel" pour lui la racine / sera le dossier que vous aurez choisis, et non pas la racine de votre serveur ;) . Ça augmente aussi énormément la sécurité si vous pensez laisser vos utilisateurs executer des CGI. Sous BSD il y a les Jails qui sont BEAUCOUP plus puissantes. Il est aussi très important de bien concevoir vos scripts: Prenons un script de sauvegarde automatisé comme exemple. J'ai un script qui lit periodiquement dans une base de données afin de faire une sauvegarde sur demande. Il récupère le nom du dossier dans la base, et fait à peu près ça "tar czvf $dossier/backup/backup-`date +%F`.tar.gz $dossier". Si un pirate infiltre ma base, il pourrait facilement modifier le $dossier par ";rm -Rf /" et ainsi tout détruire. Et tout ça, juste en trouvant le mot de passe admin de ma base de donnée, sans même avoir accès au serveur. Le cryptage des données sensibles est aussi essentiel. Si vous avez une entreprise vous ne voulez pas qu'un pirate ait accès aux données de vos clients, parce que pour vous, ça serait la faillite assurée !.

Sizième étape: Les ressources

La gestion et le partage équitable des ressources font aussi partie de la sécurité d'un serveur. Pensez aux fs quotas, aux userlimits et aux règles du limit.conf par exemple. Ne négligez jamais cette étape, c'est sans doute une des plus importante sur un environement partagé. De même qu'une fork bomb pourrait vous forcer à redémarrer si vous ne controller pas ça !

Dernière étape: Le réseau

Votre système est stable et fonctionnel. Tout vas bien et vous êtes confiant en votre sécurité logiciel. Mais avez vous bien sécurisé la couche réseau ? Si une attaque de Déni de service, ou pire de Déni distribué de service, survient est-ce que votre serveur va tenir le coup ? Qu'en est-il d'un ping flood ? Il faut aussi appliquer un minimum de protection contre le spoofing IP (entre autre pour les authentifications qui se base sur un IP et le DoS).

Une attaque survient:

Il est important de tout de suite mettre hors-service la machine dès qu'on a conscience d'une attaque. Pourquoi est-ce que c'est si important ? Parce que si on attend trop longtemps, les données sensibles (tel que les logs ayant été effacé par le pirate) ne seront pas récupérable. Après avoir mis le système hors service, il faut d'abord mesurer l'ampleur des dégats. Trouvez ce qui a été modifier, quelles données ont été récuperés par le pirate, etc. Souvent cela consiste à faire une recherche par horodatage. Bref il faut reconstituer les événements dans le temps, et dans un ordre chronologique. Une fois cela fait ça va vous aider à comprendre les motivations du pirate mais surtout de comprendre comment il est entré.

Conclusion:

Le travail d'administrateur réseau/système, outre le fait de s'assurer que tout fonctionne correctement, est de se mettre dans la peau d'un pirate afin d'essayer d'infiltrer son propre système. Il doit connaitre les techniques utilisés par un pirate afin de comprendre et d'éviter les attaques potentielles. Il doit se tenir informé des nouvelles versions de ses logiciels et connaitre leurs vulnérabilités. On peut résumé tout le texte ci dessus en quatre mots (et je les répète à plusieurs endroits sur ce blog) : Vous devez être paranoïaque.

Malgré toutes les précautions que vous pouvez prendre, il va toujours y avoir quelqu'un plus fort que vous quelque part. Non, votre orgueil ne rend pas l'échec impossible. J'ai dit NON vous n'êtes PAS le plus fort :( . C'est pourquoi les sauvegardes dans un endroit sécuritaire et isolé sont très importantes. Il faut aussi garder les logs de connexions, afin de pouvoir porter plainte contre un éventuel hacker. Mais je ne vous mentirai pas, il est très peu probable que votre plainte soit prise au sérieux. Comme mentionné en début d'article, ce n'est qu'un survol et cet article ne contient rien de très concrêt dans les actions à prendre. Il ne fait que raconter brivement chacun des aspects de la sécurité d'un serveur. De toute façon il y a tellement de méthodes employés par les pirates qu'un seul article (même une centaine) ne suffierait pas ;) .

Read more...
3 comments
Go to Top