Vous ne le saviez peut-être pas, mais un de mes passes temps en ce moment est d’étudier la visualisation de données notamment pour le web, car ce domaine est en pleine ébullition actuellement avec l’apparition de l’HTML5 et de sa balise canvas (non standardisé dans la version 4) mais aussi toutes ces libraires JavaScript permettant de faire de beaux graphiques comme on aime.

J’utilise assez rarement des outils de visualisation de données, car j’en ai pas besoin dans mon travail actuel (études ou projets perso) mais je surveille de très prêt et teste une grande partie des solutions mises en avant (sauf flash & flex qui ont d’ailleurs de très bonnes librairies de visualisation.). Voici donc un petit résumé de ce qu’il se fait en la matière actuellement :

The JavaScript InfoVis Toolkit - Librairie vraiment sympa surtout en ce qui concerne données hiérarchisées. Elle possède une très large documentation avec de nombreux exemples.

Dygraphs – Très bonne libraire pour représenter sous forme de graphiques lambda (axes abscisses et ordonnées) des données plus couramment de type temporelles. Sympa pour des activités serveur par exemple.

Processingjs – On ne présente plus la librairie Java processing, véritable leader de la visualisation en Java. Voici son « équivalent » en Javascript. Tout comme processing en Java, son utilisation s’avère complexe pour des développeurs non matheux du dimanche (moi ?) cependant, elle permet de faire bien des choses !

jquery.sparkline – Cette libraire jquery permet de faire des petits charts vraiment superbes et peut posséder de multiples utilisations telles que pour modéliser des hits de téléchargements, de visites ou des activités clients side ou server side.

Protovis – Là, nous atteignons le summum de la visualisation de données en JavaScript. Cette librairie permet de tout faire (ou presque – sauf 3D) et possède un très bon rendu des charts. Si je me rappelle bien, c’est la seule permettant de parser des données par coordonnées parallèles permettant ainsi une bonne visualisation de données complexes du type logs de connexions par exemple. (étant une visualisation notamment utilisé par FP).

En ce qui concerne la visualisation de liens entre objet, nous pouvons noter quelques librairies sympa comme :

Moowheel – Cette libraire permet simplement de modéliser des liens entre objets disposés autour d’un même cercle avec de belles couleurs (ou non). L’utilité de ce script peut prendre sa place pour modéliser des liens entre personnes sur des réseaux sociaux ou autres.

JsViz – Cette libraire est assez cool, cependant elle reste mal gérée par les navigateurs. Elle permet là aussi de faire des liens dans l’espace entre différents objets et possède plusieurs modes d’affichage. Elle est encore trop lourde pour être ergonomique sur les différents navigateurs Internet ce qui en fait son principal défaut aujourd’hui.

The JavaScript InfoVis Toolkit – Là aussi cette librairie permet de modéliser des liens entre différents objets, notamment avec son mode Hypertree.

Voilà ce que l’on peut dire de la visualisation de données en javascript aujourd’hui. Récemment, google a mis en ligne une API de visualisation permettant là aussi de faire des beaux charts, mais je préfère pas en parler, car faire sa propre cuisine est toujours plus enrichissant. De plus, plusieurs hacks CSS/HTML permettent sans javascript de faire des trucs sympa tels que des pie charts ou autres.

Si vous voulez poursuivre votre voyage et avoir une réelle overview de ce qui se fait tant au point JS que PHP/Flash, voici un petit lien qui devrait vous plaire Tools for visualizing your data. =)

[Entête]

La prise d’empreinte d’un hôte ou réseau distant est une certaine science en attaque des systèmes d’information. Le but avoué est simplement de connaitre, dans le cadre d’un hôte, son système d’exploitation ou la présence de certains équipements réseau entre l’attaquant et la cible (reverse-proxy, load-balancers, firewalls, routeurs etc.) pouvant certaines fois aboutir à un cartographie très relative du réseau visé.

Obfusquer un système d’exploitation ou même le nombre d’hôtes/sous réseaux derrière un routeur ou tout autre périphérique réseau actif est une des principales mesures à réaliser face à un possible attaquant déterminé. Comme le dit souvent l’oncle Sun Tzu, il faut avant tout aveugler l’ennemi. Un ennemi aveuglé aura du mal à avancer et son attaque sera beaucoup plus longue.

De plus, le fait d’obfusquer un système montre bien que l’administrateur n’est pas né de la dernière pluie et qu’il possède des connaissances en sécurité informatique (wahou). En outre, dans le cadre de serveurs accessibles depuis le net, cette sécurisation évitera de se faire ficher par le nouveau né SHODAN qui se base sur les bandeaux des services du type SSH, Apache, IIS, Nginx ou toute autre application un peu trop bavarde.[1]

Il existe deux types de prise d’empreinte à distance, une active et une passive. (Et une autre un peu #WTF mais pas#NSFW pour certaines attaques)

La prise d’empreinte active, la plus connue, interagit directement avec le système distant. Nous pouvons citer comme logiciels Nmap ou Xprobe permettant ainsi, – suite à l’envoi de certains paquets forgés – déterminer grâce aux réponses faites par l’host, le système d’exploitation. Ce type de scanners, bien que répandus sont souvent utilisés dans leurs fonctions standard et les fonctions avancées sont souvent oubliées pour un Scan « basique ». De plus, ces dernières permettent de reconnaitre un OS de façon plus ou moins fiable suivant le type d’équipements réseaux/sécurités ou même les spécificités du scanner…

En ce qui concerne les services tournant sur les hôtes, la technique la plus triviale consiste en la récupération de bandeaux émis par ces derniers afin de déterminer de façon plus ou moins fiable la version des services et des fois, les modules ajoutés pouvant êtres faillibles. Cette technique, bien que sa mise en œuvre soit plus que facile, peut être facilement bloquée en quelques modifications sur les fichiers de configuration de ces services.

Pour ce qui est de la reconnaissance de load-balancers, il existe un petit tool sympa se basant sur la couche application (HTTP) du modèle OSI. Ainsi, Halberd compare les entêtes HTTP reçues telles que l’heure des serveurs, l’ordre des entêtes ou même le fameux header « X-Forwarded-For » (le tout par hash notamment) afin de déterminer la possible présence de plusieurs serveurs derrière un load-balancer. Pour résumé, cette méthode est simple mais surtout très astucieuse.

Enfin, nous n’allions pas parler de fringerprinting actif distant sans parler de WAF, aujourd’hui thème à la mode, les Firewalls pour Applications Web sont disposés tels des reverse-proxy. Ces derniers, permettent principalement de contrer les attaques par Injections (JS, LDAP, SQL etc.) mais possèdent bien des spécificités permettant de les fingerprinter. Aujourd’hui, un tool sort du lot pour cela, Wafwoof permettant de fringerprinté plus de 20 WAF différents parmi le plus connu dans l’OpenSource Mod_Security d’Apache. (Qui d’ailleurs avait une petite technique d’évasion sur les SQL injections il y a quelques jours… ;)

La prise d’empreinte passive quant à elle s’inscrit lorsqu’on n’a pas un « accès direct » (pour faire simple) vers l’hôte (réseau NATé, firewallé, load-balancé, IDSé etc.). Elle peut se faire par différents moyens. Cependant, les plus connus restent la prise d’empreinte de la pile TCP/IP, les TTL des paquets reçus (façon vague de déterminer l’OS – sert pour architecture interne d’un réseau NATé – mais tout de même performante lorsqu’on a pas de tools[2]). D’autres logiciels beaucoup plus fiables mais plus complexes se basent sur l’entête TCP/IP des systèmes d’exploitation grâce à (liste non exhaustive) : la taille de la fenêtre, TTL, les flags ou même les options contenues dans l’entête (avec p0f notamment <3. Il faut pour cela que l’hôte distant se connecte à un serveur dont l’attaquant possède les droits dessus (compromis ou pas, au bon vouloir de l’attaquant) ou qu’il sniffe la connexion entre deux systèmes (donc doit être déjà présent sur un réseau).

Nous pouvons aussi réaliser le fingerprinting passif grâce aux numéros de séquence (pseudo aléatoires) contenus dans les entêtes des paquets TCP-IP. Du fait de leur randomisation non parfaite, chaque système possède sa propre « empreinte ISN » pouvant être comparable dans le temps avec d’autres empreintes ISN. Ce type de fingerprinting est très bien documenté par son créateur sur ce site internet [3]). Cette technique possède cependant des limites. Ainsi il faut un grand nombre de paquets échangés afin de posséder une bonne empreinte permettant de déterminer quel est le système distant. En outre les systèmes actuels s’orientent vers une randomisation plus fiable. Cependant, sa mise en place peut être utilisée pour déterminer le nombre de serveurs derrière un load-balancer (avec ISNprober notamment). – Ci dessous, un fingerprinting des ISN générées par Windows XP (voir [3]) :

Un « troisième type », encore plus « rock’n’rool » et beaucoup moins « matheu » peut permettre la prise d’empreinte d’un système utilisé en regardant simplement les META-DONNES des fichiers déposés sur des serveurs web ou envoyés directement par l’entité par le biais de simples emails. Ainsi, certaines applications trop bruyantes laissent des infos pouvant permettre à un attaquant de déterminer le système cible (grâce à des full path, les applications etc. contenus dans les fichiers) et les versions (les paths users diffèrent par exemple d’un WinXP à un Vista) des programmes spécialisés permettent de récupérer ses informations juteuses telles que Metagoofil (par le biais de Google) ou des fois un bon éditeur full-text fera l’affaire. Certaines informations dépassent totalement le cadre du simple fingerprinting système mais sont croustillantes à souhait (noms d’utilisateurs, paths, applications utilisées avec leur version etc.).

Cependant, pour cette dernière, il faut absolument que le fichier ai été modifié ou créé sur le poste (ou le domaine si utilisateurs) que l’attaquant veut « visiter ». Donc en d’autres termes, c’est bien pour se renseigner sur des hôtes de (sous)-réseaux d’entreprises et les logiciels employés (quoi ? le service de com’ utilise semble-t-il une version vulnérable d’OpenOffice ?), cependant, dans le cadre d’un bastion, cela ne servira totalement à rien… après tout, c’est logique. (Note : Regarder les META des communiqués de presse et etc. sur les sites institutionnels des entreprises ;)

Peut-on se protéger contre le fingerprinting ?

Comme toujours, la sécurité d’un bastion ou d’une station en particulier est beaucoup plus facile à mettre en œuvre que la sécurité d’un système d’information composée de plusieurs hôtes, réseaux, sous-réseaux, serveurs etc… Je vais vous présenter quelques pistes pour sécuriser ce petit monde, cependant, il vous faudra poursuivre par vous-même la sécurisation de vos équipements, car comme dirait papy geek « Read that fu*king manual ».

Protection des services

Ainsi, pour bien protéger les services, il faut faire taire ses applications, la plupart des services http, ftp, ssh ou autres possèdent leurs propres directives à changer dans les fichiers de configuration des services afin de réduire le bruit émi et la possibilité de reconnaissance de services à distance. On essayera de réduire un max les infos, essayant de ne plus rien divulger.

Cependant, certains services laissent encore le nom du service tout en rendant invisible sa version (c’est le cas d’Apache par exemple ou il faut aller voir dans le apache2.conf et mettre ServerTokens sur Prod – et ne pas oublier par la même occasion ServerSignature sur off ;). En ce qui concerne IIS (éh oui…) il faut simplement valeur de registre DisableServerHeader à cette adresse HKLM\SYSTEM\CurrentControlSet\Services\HTTP\Parameters et hop, plus de signature. Et pour finir, autant faire ça pour Nginx où la manœuvre est un peu plus complexe. Pour cela, DIY dans le code source en éditant les constantes de version dans les fichiers src/core/nginx.h & src/http/modules/perl/nginx.pm et enfin, en re-compilant le tout. Dans le cas d’autres services c’est à peu prêt les mêmes méthodes, pour savoir comment faire, il vous suffit de faire un simple « [nom du service] disable server signature » ou même « [nom du service] disable welcome message » dans google pour avoir des réponses à vos questions :)

En ce qui concerne la protection de WAF, à ce que j’ai pu lire sur ce site, que nous pouvons facilement protéger mod_security en customisant les réponses du firewall suite à certaines requêtes ou en changeant simplement la signature du serveur apache (dans les headers HTTP) en utilisant l’option SecServerSignature dans la configuration de mod_security (contenue dans apache2.conf) (voir ici). Je n’ai jamais utilisé d’autres WAF donc l’aide sera limitée à cela.

Protection des bastions & hôtes

En ce qui concerne les scans liés au SI (hosts, bastions, firewalls, passerelles etc.) beaucoup de logiciels ont étés développés il y a quelques années afin de limiter les tentatives de fingerprinting de stations comme IPpersonnality ou Fingerprint Fucker patchant le kernel afin de modifier la pile TCP/IP des systèmes Linux pour se faire passer pour d’autres systèmes ou périphériques réseaux. Aujourd’hui est développé IPMorph permettant là aussi d’obfusquer le système d’exploitation réel et de le faire passer pour un autre (plus que prometteur car permettant de tromper des logiciels de fingerprinting actifs et passifs tels que Nmap, p0f, Xprobe2, ou même SinFP). Vous trouverez une bonne documentation technique sur le site du SSTIC’09 ICI. Je ne l’ai pas encore utilisé/testé mais j’ai vraiment hâte à la suite de cette lecture :)

Concernant le réseau, un attaquant peut s’amuser aussi à déterminé l’architecture interne de ce dernier de façon très superficielle (os et équipements) à l’aide des TTL des paquets. Effectivement, certains équipements réseaux décrémentent les TTL lors du passage d’un paquet. Il est donc bon de rétablir à une valeur par défaut le champ TTL des paquets sortant du réseau. Pour cela, il existe des options pour IPtables.

Je ne sais pas si PF le fait (sale inculte – je connais que la limitation de TTL de PF), cependant, il est fort probable que comme IpTables nous pouvons le faire en cherchant un peu dans les mailinglists ou docs de PF. En ce qui concerne les autres Firewalls, à vous de voir, je ne pourrai pas trop vous aider. On peut également aller voir dans /proc/sys/net/ipv4/ip_default_ttl pour Linux et je ne sais plus quelle clé de registre pour Windows.

Ensuite, pour le reste, libre à vous pour ce qui est de la configuration des firewalls pour laisser passer certains paquets (ICMP etc.)  ou non dans vos DMZ, réseaux internes etc. Je ne vais pas rentrer dans ce débat troolesque à souhait aujourd’hui.

Conclusion

Le procédé fingerprinting système/réseau est une science où chaque système/réseau possède ses particularités. Aujourd’hui, les principales attaques possèdent des contre-mesures pouvant être mises en place plus ou moins facilement par rapport à l’architecture du SI associé.

Cependant, il faut trouver comme toujours le juste milieu entre la sécurité voulue, le coup de mise en place de cette dernière et l’importance des données contenues dans le systèmes pouvant être la cible d’une tentative d’attaque (qu’elle soit bien évidement interne à l’entité ou externe.).

[1] SHODAN : Le grand jeu aujourd’hui est de trouver des tips&tricks sur Shodan shells disants ouverts (root ou non), serveurs vulnérables ou déjà compromis etc.

[2] PING/TTL : Un simple tracereoute ou un ping et roule ma poule. (Dans le cadre d’un bastion avec les requêtes ICMP vers ce dernier non dropées par un éventuel firewall.)

[3] Strange Attractors and TCP/IP Sequence Number Analysis

[4] Voir les champs /Producer /Creator et /CreationDate afin d’être sur que le PDF publié est récent, cependant, certains sont encodés demandant l’ouverture par Adobe AR ou tout autre logiciel lisant les « entêtes » des PDF.

Twitter et la sécurité ce n’est pas une histoire d’amour tant pour ses utilisateurs, que la société elle-même. Bref, il s’agit d’un certain Terence Eden, qui, après avoir changé son mot de passe qui était compromis s’est aperçu que le protocole OAuth permettait, même après le changement d’un mot de passe, d’avoir la main sur le compte Twitter de la victime. Et oui, la révocation du token d’authentification de OAuth n’est pas automatique suite au changement de son mot de passe sur le service.

Bref, une seule chose à faire, supprimer dans la configuration du profil d’éventuelles applications mises en place par l’attaquant ou tout simplement, pour les plus paranos d’entre nous, ne pas utiliser Twitter même si cela est « l’outil idéal » de veille en sécurité.

Tiens, cela me rappelle que l’on peut aussi facilement backdoorer des comptes Gmail, mais ceci est une autre histoire ;) Keep Update ! =)

[Source]

Cette histoire de POST pouvait poser quelques problèmes lors de lorsqu’un script appelait des variables en POST et que PHP était configuré sans les register_globals (donc à off). Ainsi, nous devions forcément passer par une requête POST afin de faire passer les variables, cela incluait alors, dans le cadre d’attaques CSRF l’utilisation d’ajax dans une page afin de perpétrer l’attaque et d’envoyer les données au script.

Gros problème, les navigateurs empêchent les requêtes ajax POST en cross domain pour des raisons évidentes de sécurité. Et puis, j’ai eu une idée, pourquoi ne pas passer par un formulaire HTML pur et de le valider sur un évènement ? Là était la réponse ! =) Il suffit simplement de réaliser une page contenant un formulaire et une image qui ne se charge pas contenant l’évènement (non DOM) onerror , par exemple, quelque chose dans ce genre :

<form id="form" action="[vers la page vuln aux CSRF]" method="POST">
<input name="test1" type="hidden" value="valeur test 1" />
<input name="test2" type="hidden" value="valeur test 2" />
</form>
<img src="xxxx" onerror="form.submit()" />

Et hop, vous avez votre requête POST, cross domain sans utiliser de l’Ajax =) Vous voulez voir ce que cela donne ? Allez par ici -> [ -]

Pour conclure, nous pouvons dire que le code est simple, très simple, voir même trop simple. Nous pourrions un peu le customiser afin que l’envoi des données soit invisible pour l’utilisateur, mais je reste dans le cadre d’un PoC, donc pas de choses très méchantes ici.

De plus, cette technique reste assez limitée dans l’efficacité qu’aurai pu avoir une requête à dose de javascript, car cela permet de faire autre chose bien plus élaborées… et surtout de récupérer certaines informations lorsque nous sommes sur le même domaine… (arf, le cross domaine, les navigateurs n’aiment pas cela et nous pouvons les comprendre… ah si, ie6 et < aiment ça, mais c’est une autre histoire…)

Personnellement, j’ai installé jolicloud sur une VMware permettant ainsi de faire différents tests sans réellement l’installer en dur et pouvoir ainsi facilement faire des tests réseaux, sécurité (je vous en parlerai plus tard, après que certaines découvertes soient corrigées) etc. Donc, vu que beaucoup de personnes se demandent comment l’installer sur une VMware et bien je vais vous montrer comment faire (c’est simple…). Mais le mieux est tout de même de le tester sur un netbook, afin de voir réellement la qualité de ce dernier comparé aux autres « Netbook os ».

Donc pour l’installer sur une VMware, vous créez tout d’abord une nouvelle machine avec un Linux 2.6 lambda, environ 512Mo de mémoire vive histoire que cela aille vraiment vite pendant le Boot. Après avoir créé votre machine, vous allez dans les préférences (settings) afin de changer les options de disques durs, vous supprimez l’ancien que vous avez créé. Enfin, vous en rajoutez un avec l’option « use physical disk » et sélectionnez votre clé USB, si vous ne savez pas laquelle c’est, vous avez juste à en sélectionner un puis ensuite regarder la taille du disque. Puis vous refaites un autre disque dur virtuel.

Et voilà, maintenant, vous allez pouvoir booter Jolicloud sur votre clé USB depuis VMware (mais aussi toutes les distributions Linux liveUSB).

1. Port-knockwa ?

Même si ce nom est assez barbare pour un français, son sens est devinable en deux secondes. Il veut littéralement signifier frapper sur les ports (…pour ouvrir la porte). En deux mots, c’est comme dans tous les films d’espionnage amateurs, on toc à la porte selon une certaine séquence afin que la personne étant derrière la porte sache que c’est vous pour venir l’ouvrir (voir le film Léon…).

Cette technique, passée à la moulinette informatique se traduit par la modification des règles de Firewall à la volée, suite à l’envoi par un client d’une séquence de paquets SYN sur différents ports de la BOX. Par exemple, la séquence de paquets SYN sur les ports 45324, 15432 et 23942 changera les règles d’Iptables afin d’accepter la réception de paquets sur le port 22 provenant de l’IP source (envoyant les paquets SYN). Nous ferons une autre séquence afin de refermer la porte derrière nous à la fin de notre session SSH.

2. L’intérêt du port-knocking

L’intérêt est simplement d’interagir avec le serveur sans passer par une connexion distante, ainsi, nous pouvons ouvrir un service, changer son état ou modifier les règles de son fonctionnement. Il est principalement utilisé par pour manipuler les Firewalls afin d’ouvrir des ports prétendus bloqués. Ceci permettant ainsi d’éviter les attaques sur certains services par des Botnets remuant un peu trop les logs, ou des attaques ciblés contre votre box se faisant à la main.

La chance de tomber par hasard sur la bonne combinaison pour un pirate est extrêmement petite (pour vous faire une petite idée) :

   * 65535^2 = 4 294 836 225 possibilités
   * 65535^3 = 2.81462092 × 10^14 possibilités
   * 65535^4 = 1.84456182 × 10^19 possibilités
   * etc...

Autant vous dire que cette protection va limiter grandement le pirate dans ses tentatives d’attaque tellement les possibilités sont énormes, cependant, il existe quelques faiblesses matérielles et humaines à cette technique.

3. Faiblesses

Il existe deux principales faiblesses à cette technique de port-knocking. Tout d’abord, la possibilité pour un attaquant d’effectuer une attaque Man In The Middle (Monkey in the Middle pour les intimes) en local permettant ainsi de récupérer la séquence dans le flot de données en sniffant simplement la connexion.

Une seconde vulnérabilité est plus imputable à l’humain, ainsi, nous avons pas un random service intégré dans notre cerveau donc souvent, un pirate expérimenté pourra tenter de deviner les numéros de ports employés par l’administrateur, souvent des multiples ou une séquence facilement mémorisable. (sans parler de l’administrateur qui laisse par défaut la séquence contenue dans le fichier de configuration après installation ou la lecture d’un tutoriel…).

Nous pouvons aussi noter d’autres faiblesses où le pirate doit avec accès au client exécutant knockd, ainsi, si l’administrateur ne supprime pas ses logs de sessions sur le terminal, le pirate pourra avoir la suite des ports en faisant un petit $cat .bash_history

Après avoir vu les faiblesses, nous allons passer à l’installation et la configuration du serveur, puis ensuite, l’utilisation du système de port-knocking avec un client.

4. Installation et configuration

Vu que nous n’allons pas réinventer la roue, nous allons utiliser un logiciel déjà développé afin de mettre en place la solution de port-knocking, son nom : knockd. L’installation (sur une Débian) se fait facilement avec un petit :

   * (# | sudo ) apt-get install knockd

Cela va installer proprement (et tant mieux…) le programme. Après, nous allons passer à la configuration de la chose, vous allez voir, c’est d’une simplicité détonante. Donc c’est parti, tapez dans votre shell (je sais, j’utilise nano et j’aime ça) :

   * (# | sudo ) nano /etc/default/knockd

Hop, là dans ce fichier knockd nous allons configurer le demon afin qu’il sache sur quelle interface réseau écouter et s’il doit s’exécuter au démarrage de la machine. pour ce faire, il suffit simplement de mettre :

   * START_KNOCKD=1 # Ainsi il démarrera au démarrage de la box
   * KNOCKD_OPTS="-i [votre interface (eth0, eth1 etc.)]"

(si vous ne savez par votre interface, faites un petit ifconfig et regardez…) Arrivé à ce point là, nous sommes déjà bien partis, le demon peut fonctionner, reste maintenant à éditer les règles, pour cela, go to :

   * (# | sudo ) nano /etc/knockd.conf

Et éditez vos rêgles simplement en faisant :

   * [Nom de la rêgle]
   * sequence = XXXXX, XXXX, XXXXX [séquence des ports]
   * seq_timeout = 5 [quant-est-ce que la séquence est "finie"]
   * command = /sbin/iptables (+règles) [commande à exec.]
   * tcpflags = syn

Par défaut, les ports de la séquence sont en TCP, mais on peut s’amuser pour compliquer encore l’affaire à alterner TCP et UDP en faisant : XXX:tcp, XXXXX:udp, XXXX:tcp, XXXXX:tcp… Ainsi, un fichier de configuration bien paramétré, ressemblera à quelque chose (comme cela – lien). (n’oubliez pas de droper les paquets par défaut sur Iptables… car sinon, cela ne sert à rien…) Ensuite, nous devons redémarrer knockd afin qu’il reprenne bien en compte les nouveaux paramètres, pour se faire, une simple commande suffit :

   * (# | sudo ) /etc/init.d/knockd restart

Voilà, l’installation, et la configuration est finie, reste plus qu’à tester avec un client !

5. Utilisation d’un client

Il existe des clients pour tous les systèmes d’exploitation, et cela, c’est cool ! Ainsi, il suffit simplement d’exécuter le binaire client knockd comme ceci afin de réaliser le port-knocking :

   * > knock (ip du serveur) (port):(tcp|udp) (port):(tcp|udp)...

Vous trouverez les binaires et sources des clients sur le site de knockd : http://www.zeroflux.org/projects/knock (il existe même un client pour Iphone!). Bref, libre à vous ensuite de vous amuser avec knockd, sur différentes box et à partir de différents clients.

Bref, donc tout d’abord, quel matériel choisir ?

Là, question coût, nous n’allons pas acheter quelque chose de très puissant, car il sera principalement réalisé afin de permettre le téléchargement de fichiers (après vous voyez pour la légalité), la mise en place d’un serveur web voire mail si vous le souhaitez. Donc pour faire « bien » à pas cher, vous avez deux choix :

1. Le choix Système-D : Allez acheter sur un site ex : leboncoin.fr un netbook avec un écran cassé, on en trouve de très bons à pas cher 50 à 80 euros avec 1go de Ram, 900hz, entre 4 et 16go de disque dur etc. Ceci est bien car les personnes vendant ce matériel ne savent pas que ce qui compte dans une grande partie des cas, ce n’est pas l’écran, mais bien l’intérieur de la bête.

2. Le choix résonné : Si vous avez un peu d’argent devant vous (environ 200 euros) vous pouvez vous prendre un petit soekris histoire d’être sûr d’avoir du bon matos. Il n’est pas bruyant et consomme rien. Cependant ceux qui sont allergiques aux lignes de commande vont vivre quelques heures de configuration fastidieuses. Ce choix est résonné par rapport à la consommation d’énergie si votre bébé va tourner 7j/7.

Maintenant que vous avez le matériel, où l’installer ? Là vous avez plusieurs possibilités et tout dépend là aussi de la chaleur qu’il dégage. J’ai fait des tests dans plusieurs endroits aussi atypiques les uns que les autres et ce qui en ressort c’est qu’un petit serveur comme vous allez faire n’a pas besoin d’une chambre froide afin de fonctionner non-stop. Cependant, j’ai testé la méthode dans le frigo et cela s’avère un assez bonne alternative :) (si vous n’avez pas de légumes/fruits/etc dedans).

Et le web fut !

Pour ce qui est de la connectivité, oubliez le WIFI et préférez le filaire cela permettra d’avoir moins de problèmes de paramétrage au cas où le serveur redémarre ou si le wifi merdoy. Une chose est sûre, les câbles, malgré ce que l’on en dit, ont encore de beaux jours devant eux ! Le raccordement à la box fait, sécurisez cette dernière, mettez un mot de passe d’accès si cela n’est pas déjà fait. Activez l’IP forwarding vers l’adresse IP statique de votre serveur en question à partir de la console d’administration. Pourquoi mettre un mot de passe ? Tout simplement pour éviter les attaques CSRF, mais aussi (et surtout) éviter que l’on ait accès à son administration si votre serveur est éteint.

Ceci fait, tous les flux entrants par le(s) port(s) que vous avez désignés vont être aiguillés vers votre serveur (Cool, non ? Non ? Bon d’accord…) Maintenant vous n’avez plus qu’à installer votre petite solution LAMP sur votre serveur et les différents services que vous voulez. N’oubliez pas d’activer les virtual hosts sur Apache si vous avez fait pointer des noms de domaines sur votre BOX.

La sécurité avant tout !

Passons maintenant à la sécurité du serveur, car il faut bien le dire, un serveur non implanté dans une DMZ présente un vrai risque pour la sécurité du réseau et la confidentialité des informations transférées sur ce dernier. Donc il faut absolument le sécuriser de toutes parts. Tout d’abord, contre le fingerprinting actif et passif. Il faut pour cela changer le TTL de Linux pour faire croire aux différents scanners que c’est Windows qui est sur la machine (on on change le TTL de 64 en 128) (les scanners ne se basent pas que sur le ttl pour déduire les version des Os, mais c’est une méthode, et autant la brouiller), on change aussi les différents bandeaux des différentes applications telles que SSH, Apache et autres trucs comme cela. Moins l’attaquant en sait sur le système visé depuis l’extérieur mieux c’est pour vos fesses ! (d’ailleurs documentez-vous sur ce petit soft bien sympa : IP personnality, même s’il est pour les 2.4, la doc est assez sympa histoire de voir comment cela fonctionne…). Il y a aussi ce petit lien avec quelques logiciels du même type.

Ceci fait, il nous faut changer quelques configurations par défaut, tout d’abord, SSH. On enlève la possibilité de login en Root à distance sur le système, on change le port par défaut du service histoire de ne pas être attaqué par des Boots où des SK. Ensuite on va configurer un petit utilitaire afin de détecter la moindre tentative manquée de connexion à différents services, cet utilitaire est connu et bien sympa. Surtout si on le couple à un service d’envoi d’SMS pour avec un temps de réponse post-attaque rapide. Son nom : fail2ban. Et oui, on ne change pas une équipe qui gagne ! Bon pour la documentation direction ICI où tout y est très bien expliqué. Amusez-vous avec IP tables afin de dropper les paquets qui sont méchant, pour cela, il existe des tonnes de ressources sur Internet donc je vous fait confiance.

Vous pouvez aussi envisager une solution de port knocking afin de gérer les ports dynamiquement, cette solution permet beaucoup de choses, et surtout réduit considérablement les logs de tentatives d’attaques :)

Il faut aussi créer un utilisateur dans un espace confiné, afin d’emprisonner le pirate dès l’obtention d’un shell d’attaque sur un processus utilisé par cet utilisateur. La technique s’appelle le chroot et est difficile à mettre en place si on ne l’a pas fait trente six mille fois sur différents logiciels (moi aussi j’ai encore du mal à chrooter). Au programme, récupération des librairies utiles au logiciel, création de l’espace restreint dans un répertoire à la racine et emprisonnement des processus. Vous pouvez le faire, ou pas. Si vous ne voulez pas passer par cette tâche longue et fastidieuse, vous pouvez désactiver pour les utilisateurs autres que le root les programmes utiles au pirate en tant d’attaque tels que wget, gcc, python, cURL, vim, nano, pico etc. afin qu’il ait beaucoup de mal à devenir root sur votre machine (chmod 700). On peut aussi, afin qu’il ne s’amuse pas à essayer d’entrevoir la topologie de notre réseau chmoder les ifconfig, ping etc. Vous pouvez aussi vous amuser avec le petit tool de la NSA dénommé SElinux perrmettant de mettre des droits pour des processus à des fichiers pécis, et cela, un Linux standard ne le fait pas ! :D Cela devient très vite utile en cas d’attaque. Voir plus d’infos ici ou sur Google ;)

Enfin, pour la configuration du serveur (apache, php etc.) désactivez tout ce qui peut permettre l’identification là aussi des versions utilisés, donc direction tout d’abord httpd.conf et désactivez les signatures du serveur. Vérifiez que la valeur expose_php dans le php.ini est à off, si elle ne l’est pas, mettez-là ! En ce qui concerne aussi le php.ini, mettez le safe_mod sur on, les magic_quotes aussi, modifier l’open base dir et mettez allow_url_fopen sur Off. Désactivez de plus certaines fonctions qui sont pas très très sympa… Ne laissez jamais MySQL s’exécuter avec l’utilisateur root de ce dernier, créez des utilisateurs avec des droits restreint afin de ne pas aller vers la catastrophe. Par ailleurs, mettez en place un petit IDS codé en PHP sur votre site dynamique afin de voir s’il est la cible d’attaques… (voir PHPIDS, même si à ma grande surprise, il ne contre pas certaines attaques que mon IDS php à moi détecte… :D)

Et maintenant ?

Et bien, si vous avez tout fait et que vous arrivez encore à lire ces lignes, je dois dire bravo ! Il ne vous reste plus qu’à veiller sur les mises à jour de votre système, de créer un Cron qui exportera vos logs (mysql/apache/acces/ssh) toutes les semaines vers une adresse mail mise en place pour l’occasion afin d’entrevoir des tentatives d’attaque qui seraient passées entre les mailles du filet. On peut aussi s’amuser à envoyer des mails ou des SMS, mais ceci est une autre histoire. Veillez à faire un rkhunter avec Cron quelques fois afin de voir s’il n’y a pas de rootkits sur le système et… voilà !

Désolé si cet article manque de références ou n’est pas complet, j’ai écrit cela – un peu – à l’arrache aujourd’hui et je ne vais pas aller chercher des références si j’en n’ai pas pris pour le réaliser. La prochaine fois, j’essayerai de faire quelque chose de plus « pro ».

C’est la deuxième fois qu’un problème de sécurité est présenté sur le service Twitter, la première était le piratage de quelques gros comptes suite à une attaque par force brute d’un compte d’administrateur.

Beaucoup de personnes ont donc parlées de cette possibilité de changement de statut par un site tiers, mais personne n’a encore solutionné le problème. Donc je vais vous livrer quelques astuces pour sécuriser son site internet contre ces attaques mais aussi, vous sécuriser vous. Car il est en partie possible de se sécuriser contre ces attaques connues appelées CSRF.

Attaque ? Où, où ça ?

Tout d’abord étudions l’attaque. En temps normal, la personne étant loggée envoie son statut par l’intermédiaire d’une requête POST et Twitter le met à jour. Cependant, les requêtes POST et GET peuvent se confondre donc nous pouvons charger dans l’URL les données que nous voulons envoyer par l’intermédiaire de la variables statut. Ex : http://twitter.com/home?status=le statut à mettre.

A partir de là, il devient facile pour une personne de mettre un script dans son site Internet faisant le travail et changeant le statut de n’importe qui loggé sur twitter et visitant le site. Voir le PoC (proof of concept) ici.

Bon, ceci dit, comment se protéger ?

Tout d’abord, le site Internet doit être protégé au niveau du code. Ainsi, on n’accepte pas n’importe quelle variable envoyée depuis n’importe quel site Internet. Pour ce faire, une technique assez simple est de mettre un champ en hidden avec une valeur aléatoire envoyée en même temps que notre valeur (dans le cas de Twitter le statut.). Ainsi, grâce aux sessions, le site Internet garde en mémoire cette valeur. Lorsque la page reçoit le statut, la valeur cachée est comparée à celle en mémoire. S’il y en a pas où si cela n’est pas la bonne, en refuse le changement de statut. (encore dans le cadre de Twitter.)

Je vous ai fait un petit script que l’on peut tester et disponible ICI.

Cette valeur doit réellement être aléatoire et être hashée de préférence en sha1 pour (encore) plus de sécurité. En fait, tout dépend de la longueur de la chaine et du nombre de possibilités pour chaque case. Si cette dernière est élevée (comme dans mon exemple, 32 cases) il n’est pas réellement nécessaire de prévoir un hashage de cette dernière.

De plus l’utilisateur, lui, ne peut jamais être protégé. Ainsi, même en désactivant le Javascript sur son navigateur, en empêchant l’affichage des iframes, cela ne fera que stopper les attaques CSRF complexes, mais pas ce genre de petites attaques, car l’URL peut être appelée depuis n’importe quel code que cela soit une iframe, une image, une feuille de style etc.

Développeurs, développeuses, je vous encourage à patcher tous les champs de vos différents formulaires car cette faille est très – trop ? – répendue ! (Administrations de routeurs, de box, réseaux sociaux, sites bancaires (?), sites d’ecommerce, services de blogs etc.). Bref, maintenant la balle est dans votre camp !