Using java.net.InetAddress.getByName() to validate an IP Address may be too permissive

java.net.InetAddress.getByName() static function can be used for validating a given IP Address.

But doing that way you need to pay attention to certain side effects border values :

String ip = "1.2.3.4"; // valid IP Address
InetAddress address = InetAddress.getByName( ip );
Assert.assertEquals( ip, address.getHostAddress() ); // Pass. OK

String ip = "1.2.3"; // invalid IP Address
InetAddress address = InetAddress.getByName( ip );
Assert.assertEquals( ip, address.getHostAddress() ); // Pass. KO !

If you have a look a little deeper, you will see that 1.2.3 is transformed in 1.2.0.3, which after transformation become a valid IP Address.

Having that in mind, a IP Address validation function can look like :

public static boolean validateIpAddress( String anIpAddress ) {
 try {
  InetAddress address = InetAddress.getByName( anIpAddress );
  return address.getHostAddress().equals( anIpAddress );
 } catch (final UnknownHostException e) {
  return false;
 }
}

Implémentation d'un serveur proxy HTTP

La question à la base de cet article est la suivante :

Comment faire pour que mes concurrents ne soient pas au courant que j'observe (très) régulièrement une section particulière de leur site internet ?

La première étape bien évidemment est de la légitimer cette question. Comment un concurrent pourrait savoir que je consulte régulièrement son site ?

La réponse est simple. Prenons un cas concret pour illustrer : ELCA Informatique possède les plages d'adresses ips 193.72.144.0 - 193.72.147.255 (bloc /22 = 1024 ips, hosté chez Cablecom) et 193.73.238.0 - 193.73.238.255 (bloc /24 = 256 ips, hosté chez Sunrise)

Ce genre d'info se trouve très facilement via un mélange whois, traceroute et autres informations DNS.

Une fois qu'on a ces ips, il suffit de rechercher dans les logs les hits faits par ces ips et on pourra dresser un profil précis des intérêts des collaborateurs d'ELCA sur notre site.

Donc comment faire pour éviter cette traçabilité ?

Connexion Internet à adresse ip dynamique (xDSL)

Une première solution est d'utiliser une connexion xDSL pour toutes les connexions humaines à Internet, et de dédier exclusivement les plages d'ips fixes et repérables aux services de l'entreprise. Cette pratique est de plus en plus courante, surtout avec l'arrivée des connexions VDSL et de boitiers qui permettent d'agréger plusieurs lignes xDSL afin d'une part d'avoir un redondance, et d'autre part de partager la somme des débits des lignes entre les utilisateurs. Le seul détail concernant cette solution est de vérifier que l'adresse ip change réellement, faute de quoi il faudrait forcer ce changement.

Serveur proxy

Une autre solution, que je vais détailler ici car elle est plus intéressante d'un point de vue ingénierie informatique, est de faire passer le traffic des utilisateurs par un proxy. Par proxy j'entends tout type de connexion indirect à Internet, donc autant les serveurs proxy HTTP, SOCKS, etc que les réseaux de proxy comme par exemple Tor.
Le fait d'accéder à Internet par l'intermédiaire d'un proxy permet de visualiser un site avec une adresse ip qui n'est pas notre, mais appartient à un prestataire de ce genre de service. Cependant l'anonymité à 100% n'existe pas : il existera toujours un intermédiaire qui saura qui a accédé où. La confiance des intermédiaires est donc de mises dans cette configuration.

Il existe une grande quantité de serveur proxy logiciel de qualité, open source ou commercial, comme par exemple Squid, Privoxy, Apache mod_proxy, etc... Mais une fois de plus, l'utilisation d'un logiciel existant nous priverait du plaisir de développer de notre propre implémentation.

Principe de base

Le principe d'un serveur proxy est donc d'intercepter la requête d'un navigateur, d'ouvrir une connexion vers le site cible, transmettre la requête original, lire le résultat et finalement renvoyer ce résultat au navigateur.

Protocole HTTP

La partie centrale d'un serveur proxy HTTP réside sa compréhension du protocole HTTP. Celui-ci comporte des particularités qui vont être détaillées.

Le serveur proxy va recevoir une requête du navigateur, dont la première ligne comporte l'action à exécuter, l'url de la cible et une éventuelle version du protocole utilisé :

GET http://www.noisette.ch/ HTTP/1.0

Cette première ligne va donc directement nous renseigner sur le serveur cible à connecter. Le reste de la requête est composée de lignes de header, contenant diverses informations sur la requête comme le navigateur utilisé ou le referer (en français on dit comment ?).

Transfer de la requête au serveur cible

La prochaine étape est le transfert de la requête au serveur cible. A ce moment on peut éventuellement modifier ou enlever des headers du client, voir en ajouter d'autres. Plus précisément, il peut être intéressant de filtrer tous les headers des clients qui pourraient trahir l'utilisateur du proxy (information leakage).
Reste la lecture du résultat, qui n'est de loin pas la partie la plus triviale.

Ne pas bufferiser la lecture du résultat

L'implémentation d'un serveur proxy dans laquelle on lit le résultat en entier (via un lib du style httpclient) avant de l'envoier ensuite au navigateur n'est à mon avis pas bonne : le délai entre la requête et la réponse risque d'en prendre un coup, surtout pour les grosses pages.
L'idée est donc de retourner directement les bytes lus du serveur web au client.

En pseudo code, ca donne quelque chose du style :

 // fromWeb : InputStream du socket de la connexion vers le serveur source
// toBrowser : OutputStream du socket de la connexion vers le browser
while ((i = fromWeb.read(buffer)) != -1) {
  toBrowser.write(buffer, 0, i);
  toBrowser.flush();
}

Fermeture des connexions

La fermeture des connexions est très importante afin de libérer les ressources et ne pas avoir un serveur qui explose après 20 requêtes. Facile en théorie, la fermeture de la connexion est la sous partie non triviale. Dans la mesure où le serveur ne ferme pas systématiquement la connexion à la fin du transfert si il reçoit un header "Connection: keep-alive", il faut détecter quand la réponse du serveur est complète pour pouvoir fermer la connexion.

Dans une grande majorité des réponses, la taille de la réponse est spécifiée via un header "Content-Length: 82". Il suffit donc de lire autant de bytes que nécessaire et la connexion peut être fermée. Mais quelques réponses ne vont pas retourner de taille. C'est le cas par exemple lors du streaming d'un fichier. Dans ce cas il faut lire la réponse jusqu'à ce que le serveur ferme lui-même la connexion.

Transfer-Encoding: chunked

Une autre difficulté à la lecture de la réponse est l'encodage chunked. Dans ce mode de transfert, le serveur sépare la réponse en plusieurs parties, les chunks. Ca lui permet d'envoyer une partie de la réponse tout en calculant la suite. Par exemple Google utilise ce mode de réponse : les 2-3 premiers résultats sont dans un cache direct, et Google les retourne dans un premier chunk. Puis il doit aller chercher les 7-8 autres dans un deuxième cache, opération un peu plus coûteuse, qui se fait pendant que le navigateur du client lit ce premier chunk. Ca permet au serveur de ne pas attendre d'avoir entièrement cherché les 10 résultats, et de profiter du temps de transfert avec le client. Du point de vu du client, une fois qu'il a fini de lire le premier chunk, les suivants sont prêts à être lus. L'impression de fluidité est donc parfaite. Mais malheureusement peu d'implémentations tirent intelligemment profit de ce type de transfert.

En pratique, la réponse d'une encodage chunked donne quelque chose du style :

taille du chunk en hexa \r\n
données \r\n
taille du prochain chunk \r\n
données \r\n
...
0\r\n
\r\n

Pour lire la réponse, il faut donc lire la taille du chunk, lire les données du chunk, lire la taille du prochain chunk, etc jusqu'à ce qu'on ait un chunk de taille null, signifiant la fin de la réponse.

HTTP/1.1 200 OK¶
Date: Fri, 31 Dec 1999 23:59:59 GMT¶
Content-Type: text/plain¶
Transfer-Encoding: chunked¶
¶
1a¶
abcdefghijklmnopqrstuvwxyz¶
10¶
1234567890abcdef¶
0¶
¶

Caching

Prochaine étape dans l'implémentation d'un serveur de cache utile est efficace, c'est l'ajout d'une couche de cache au niveau du proxy : le serveur cible va retourner une information sur la date de dernière modification de la page. Cette indication peut être utilisé pour retourner la page mise en cache plutôt que de relire la réponse du serveur.

Authentification

Dernier point important si on met un serveur proxy sur internet, il faut ABSOLUMENT implémenter un ACL (access control list) afin de restreindre l'accès et l'utilisation du proxy aux personnes authentifiées uniquement. Faute de quoi votre tout beau serveur proxy sera vitre trouvé et utilisé par des personnes malveillantes pour spammer, consulter des sites illégaux etc.

Prochaine étape : au travail !

Fonction url_get_contents en PHP

Plutôt que d'utiliser un bien moche file_get_contents($url) où $url est une url, je vous propose une petite fonction url_get_contents($url) utilisant l'extension curl de PHP qui permet aussi bien de télécharger le contenu d'une url via GET que POST :

function url_get_contents($url, $post = null) {
 $curl = curl_init();
 curl_setopt ($curl, CURLOPT_URL, $url);
 curl_setopt ($curl, CURLOPT_USERAGENT, $_SERVER['HTTP_USER_AGENT']);
 curl_setopt ($curl, CURLOPT_HEADER, 0);
 curl_setopt ($curl, CURLOPT_RETURNTRANSFER, 1);
 curl_setopt ($curl, CURLOPT_SSL_VERIFYPEER, 0);
 //curl_setopt ($curl, CURLOPT_FOLLOWLOCATION, 1); // if no safe_mode neither open_basedir

 if (is_array($post)) {
     curl_setopt ($curl, CURLOPT_POST, 1);
     curl_setopt ($curl, CURLOPT_POSTFIELDS, $post);
 }

 $html = curl_exec ($curl);
 curl_close ($curl);
 return $html;
}

L'utilisation est réellement simple :

$content = url_get_contents('http://www.noisette.ch');

Contourner le blocage du port SMTP

Votre provider bloque le port tcp/25 (SMTP) et donc vous ne pouvez pas envoyer de mails via votre serveur mail préféré ?

Une solution toute simple mais qui nécessite d'avoir un compte shell sur un serveur quelconque (qui peut être votre ordinateur local), qu'on va nommer srv_shell dans cet exemple, est de faire un tunnel entre votre ordinateur local, le srv_shell et votre serveur de mail préféré, appelé srv_mail ici.

La commande à exécuter sur votre ordinateur local est la suivante :

ssh -NL 2525:srv_mail:25 user@srv_shell

L'utilisation d'un clé ssh est encouragée.

Ensuite dans votre logiciel d'envoi de mail préféré il suffit de spécifier comme serveur sortant localhost sur le port 2525.

Et hop la sécurité le côté ennuyeux à ce type de sécurité mis en place par l'administrateur est bypassé. J'y reviendrai d'ailleurs dans un autre article, car il m'est arrivé récemment ce genre de mésaventure : ip fixe avec serveur Exchange + Storm Worm = blacklistage de l'ip...

Une deuxième solution pourrait venir à l'esprit si on possède son propre serveur dédié, mais je vais expliquer pourquoi cette solution est à bannir au plus vite.

La deuxième idée est d'utiliser un logiciel comme rinetd ou redir, qui ont pour but de rediriger le traffic adressé à un port vers un autre. Donc tout ce qui arriverait sur le port 2525 de srv_shell serait redirigé vers le port 25 du srv_mail. Le problème de cette solution est quand les deux serveurs srv_shell et srv_mail sont les mêmes, la connexion sur le port 25 est redirigé par la même machine, le service mail va donc recevoir une connexion depuis localhost. Et comme la très grande majorité des services mails sont configurés pour que localhost puisse envoyer sans restrictions des mails, cette configuration ouvre un open-relay. Quiconque trouve ce port 2525 sur votre serveur pourra l'utilisé pour spammer le monde entier -> la redirection de port sur un serveur mail est donc à bannir.

Création manuelle d'un botnet "localisé"

Une méchante idée m'est venue en lisant un article de Slashdot : Cracked Linux Boxes Used to Wield Windows Botnets.

Afin de se composer un réseau de botnets, il serait extrêmement simple à une personne malveillante de vendre des routers ADSL modifiés (rootkités) sur des sites comme Ebay ou Ricardo en Suisse. L'utilisation pour l'acheteur pourrait être strictement similaire, au point qu'il ne se douterait pas que quelqu'un d'autre à la main sur son nouveau routeur.

Dans cet ordre d'idée, on voit de plus en plus de router ADSL se faire rootkiter à la suite d'un piratage d'un ordinateur. La raison principale : un mot de passe par défaut... Idem pour les connexions wireless : on la casse (l'histoire d'une journée pour du WEP avec du matériel correct) avant de s'attaquer au router !

En résumé, il serait presque rentable de se monter un botnet "localisé" et persistant, car placé dans des endroits stratégiques.

Deux petites recommandations pour éviter toutes mauvaises surprises : TOUJOURS modifier le mot de passe de vos routeurs (quitte à le noter dessous, le pirates devant hacker votre webcam et le robot téléguidé du petit frère pour réussir à placer le mot de passe dans le champs de vision de la webcam), et abandonner les connexions wireless...

Une authentification sur les serveurs smtp des providers

Non content de perdre la guerre du spam, les providers contre-attaques.

Relayé par Rags, voici le mail explicatif de Green :

Chers clients de green.ch

Dans le cadre d'un projet commun, les 4 grands fournisseurs de service internet en
Suisse (Bluewin, Cablecom, green.ch et Sunrise) mettent en place des mesures pour
combattre l'affluence massive des spams. La 1.ère étape est l'imposition de
l'authentification du serveur SMTP (Simple Mail Transfert Protocole). Cela signifie
que votre programme eMail, pour la récéption et l'envoi des emails, doit toujours
s'authentifier au niveau du serveur mail avec un nom d'utilisateur et mot de passe.

Il est possible que cela soit déjà le cas à votre niveau. Pour être sûr, nous vous
invitons à procéder à une vérification.

Le guide pour le paramétrage exacte ainsi que la configuration de votre compte eMail
se trouve ici: http://dtg.green.ch nous vous invitons à suivre la démarche pas à
pas.

Si vous utilisez exclusivement le Webmail pour vos eMails, vous ne devez rien
entreprendre.

Il est préférable d'effectuer le contrôle tout de suite afin de vous assurer que vos
eMails seront aussi envoyés à l'avenir.

Nous vous remercions de votre coopération.

Avec nos meilleures salutations

Votre équipe de support de green.ch

Les clients des providers vont donc immédiatement devoir modifier les paramètres de leur compte mail sortant afin d'y ajouter une authentification.

Cette authentification a deux effets :

• premièrement elle est ABSOLUMENT INUTILE contre l'envoi de spam, puisque les malwares qui envoient du spam passent très majoritairement par des open-proxies, ou se connectent directement sur le smtp du MX du domaine.
• deuxièmement elle force à avoir une adresse email @<super_provider_de_luxe>, ce qui rend les clients dépendant d'eux, car il est pénible de changer une adresse email déjà diffusée à tous ses amis/contacts. Elle empêche de ce fait le confort d'utilisation que nous fourni des adresses email comme Gmail (à noter que le webmail n'est pas touché par cette restriction).

A mon humble avis, cette solution a dû être trouvée par les économistes du top management et ne sert qu'à se donner un semblant de paraitre d'essayer de combattre le spam, tout en fidélisant de force leur clients.

De ce point de vue, chapeau, il n'aurait jamais été si facile de faire passer la pilule sans cet argument de combattre le spam. D'un point de vu efficacité réelle, autant dire que c'est même pas un pet de constipé dans l'eau, c'est de la poudre aux yeux sans poudre. J'espère simplement que vous, chers providers, avez pensé à renforcer vos équipes de

hotline

, et que vous les avez former pour répondre à la question : "Je reçois toujours autant de spam, que faire ?".

Je serais tellement content de pouvoir expliquer mon poing point de vue à un décideur d'une de ces entreprises...

We are losing this war badly

Ou "Quand les RFCs sont trop difficiles à comprendre..."

Quand un serveur SMTP se connecte à un autre pour envoyer un mail, il doit s'annoncer. Cela fait parti du protocole SMTP définit dans la RFC 2821

- Connexion TCP à <server_destinataire> (telnet <server_destinataire> 25 pour simuler le comportent)
- HELO <server_name> (ou EHLO dans le cas de ESMTP)

Ce HELO <server_name> est une petite politesse introduite dans le protocole, mais qui permet, en plus de choisir la version de SMTP lors de l'échange, d'ajouter des tests pour détecter le spam.

En effet, à l'heure actuelle la plupart des moteurs SMTP utilisés pour envoyer du spam ne s'annoncent pas correctement. Le <server_name> est très souvent remplacé par une chaine de caractères aléatoires.
Si on part du principe qu'un serveur mail légitime a une adresse ip fixe, la correspondance entre l'ip inverse de <server_name> et de l'ip de la connexion du serveur serait un très bon test pour contrer le spam. Le problème devient un cauchemar quand même des providers ne configurent par correctement leurs serveurs SMTP :

Received: from smtp-auth-be-03.sunrise.ch (mail-proxy-be-01.sunrise.ch [194.158.229.48])
        (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
        by dns3.omne-serveurs.net (Postfix) with ESMTP id 342991EEE10
        for ; Sun, 31 Dec 2006 02:16:16 +0100 (CET)

Dans cet exemple, il s'agit d'un serveur Sunrise qui s'annonce smtp-auth-be-03.sunrise.ch, et dont l'ip est 194.158.229.48. C'est presque juste, le seul détail est que le reverse de 194.158.229.48 est mail-proxy-be-01.sunrise.ch.

Received: from swip.net (mailfe05.tele2.ch [212.247.154.136])
        by dns3.omne-serveurs.net (Postfix) with ESMTP id 0173F763C3C
        for ; Wed, 10 Jan 2007 07:54:31 +0100 (CET)

Dans ce deuxième exemple, la configuration est pire : le serveur qui se connecte avec l'ip 212.247.154.136, s'annonce comme étant swip.net, alors que le reverse de swip.net est 212.247.156.1.

En résumé, parce que les personnes qui administrent des serveurs mails ne sont pas un peu plus scrupuleux, comme il est dit dans cet article

We are losing this war badly

Spam image

Selon une analyse menée par une société spécialisée dans la sécurité informatique, le spam image a augmenté de façon impressionnante en un an, passant de 4,8 % du spam global en octobre 2005 à 25 % un an plus tard. Loin d'être en recul, le volume global du spam est passé de 31 milliards de messages par jour à 61 milliards sur la même période. De plus la taille moyenne des messages a elle aussi augmenté, passant de 8,9 Ko à 13 Ko. Le spam consomme donc désormais 819 téraoctets de bande passante par jour !

En attendant que d'efficaces techniques de prévention du spam image soient mises au point, n'hésitons pas à désactiver l'affichage automatique des images dans notre gestionnaire de courrier, ce sera déjà une première défense. Et ayons toujours en tête que le but des spammeurs est moins de vous vendre quelque chose que de vous arnaquer purement et simplement...

Bug de l'an 2038

Le format Unix pour les dates, c'est-à-dire le nombre de secondes depuis le 1er janvier 1970, est une très bonne chose car ça représentation est très compact, on peut facilement comparer 2 dates, calculer des intervalles, etc.

Le seul problème qui en découle est que son implémentation sous forme d'entier, 32 bits sur la majorité des systèmes actuels, et condamné à subir un integer overflow, et ce dans un peu plus de (2^^32 / 3600 / 24 / 365 =) 136 ans à partir de la date de référence si la date est codée en entier non signé, (2^^31 / 3600 / 24 / 365 =) 68 ans si le codage est signé, c'est-à-dire vers l'an 2106 ou 2038 respectivement.
Il nous reste de beaux jours devant nous, mais cela montre à quel point on est incapable de ne pas reproduire le bug de l'an 2000...

Un serveur en overload

Quels sont les signes qu'un serveur est en overload ?

La réponse est relativement simple un outil de monitoring tel que mrtg ou maintenant rrdtool est installé sur le serveur.

Considérons le graphique suivant :



Il représente la charge d'un serveur sur une moyenne journalière, avec en y le % de charge. Dès juillet, l'augmentation de la charge non négligeable que subit le serveur est un signe qu'il faut envisager rapidement un remplacement par une machine plus puissante. L'augmentation est linéaire, elle nous permet donc une bonne projection et donc une bonne prévision de quand le serveur arrivera à une charge moyenne de 100%.

Gagner de l'argent grâce aux botnets

Initialement posté sur Noisette.ch par KillerWhile le 23.08.2004

Définition

Les botnets sont des réseaux d'ordinateurs reliés à internet, sur lesquels ont été installés des logiciels à l'insu de leurs propriétaires. Ces zombies réagissent à des instructions précisent, permettant principalement de paralyser des sites par des attaques pas déni de service ou de relayer des spams en grande quantitée.

Voir aussi la définition d'un Botnet sur Wikipedia.

Construction

A l'heure actuelle, entre les exploits publiques et les proof of concept, beaucoup d'exemple de codes existent sur internet à partir desquels on peut infecter des machines pour construire son botnet.

Rémunération

Illégales
Deux méthodes illégales sont actuellement utilisées pour tirer profit d'un botnet :

• Le racket de site : on lance un dos sur un site et on arrête uniquement si le webmaster paie une rançon. C'est risqué mais en ciblant bien les victimes, ca peut rapporter gros.
• La revente de services à d'autres tiers.

Légales !
D'autres techniques sont un peu plus légales, mais je ne m'y aventurerais quand même pas :
Utiliser son botnet pour augmenter le trafic (raisonnablement) sur un site web, et générer par la même occasion des cliques sur des publicités présentes sur le site.
Bien que cette technique puisse aussi être utilisée pour faire payer cher un annonceur, une utilisation plus rationnelle permettrait de se générer de gros revenus (de l'ordre du millier d'euro par mois).

Résumé