Just Another Geek

Aller au contenu | Aller au menu | Aller à la recherche

Une image de moi

Archive du blog de Nicolas Bareil · restaurée à partir d’Internet Archive · commentaires fermés

lundi 28 mars 2005

Reverse DNS tout pourri

Rappel, un reverse DNS, c'est récupérer un (ou des) nom de domaine depuis une adresse IP. Un reverse cassé est lorsque :

% dig +short -x 1.2.3.4
smtp.plop.org
% dig +short smtp.plop.org
2.4.5.6

Maintenant, amusons nous à compter les reverses DNS cassés qui envoient des mails à mon serveur SMTP :

% zcat /var/log/exim4/mainlog*gz | awk 'BEGIN {                         \
                           ok = 0;                                      \
                           ko = 0                                       \
                         };                                             \
                                                                        \
                       /broken reverse/ {                               \
                           if (getline > 0 && $0 !~ /rejected/) {       \
                              ok += 1                                   \
                           } else {                                     \
                              ko += 1                                   \
                           }                                            \
                       };                                               \
                                                                        \
                       END {                                            \
                           print "ok=", ok, "ko=", ko                   \
                       }'
ok= 48 ko= 448

Ce qui signifie que 448 machines avec un reverse DNS cassé ont vu leur message refusé dès la session SMTP (Spamassassin, ou sanity check réalisé par Exim4) contre 48 serveurs SMTP qui, malgré leur DNS tout pourri, ont vu leur message accepté tout de même.

Après avoir jeté un coup d'oeil rapide aux messages acceptés, seul une dizaine ne sont pas du spam.

En conséquence, cela signifie qu'il n'est pas possible de mettre en production ce type de règle car elle déclenche trop de faux-positif (10 pour 500 messages, c'est beaucoup trop). C'est dommage car cette solution est très économe en ressources et permet de bloquer très tot les messages...

jeudi 24 mars 2005

Grève des transports ?

J'adore les pertes de paquets ! Aujourd'hui, ma connexion ADSL dégroupée Free a déraillé complètement pendant une demie-heure : plus de 15% des paquets étaient perdus.

Le truc chouette. C'est que comme par hasard, tous les paquets DNS étaient perdus, pas un seul n'est arrivé, ou en tout cas, pas une seule réponse n'est parvenue. Et sans DNS, on peut pas faire grand chose : le serveur SMTP refuse tout temporairement étant donné qu'il ne peut pas faire de vérification DNS, on ne peut plus visiter de sites Internet, bref la joie.

C'était d'ailleurs assez étonnant que les connexions TCP fonctionnaient aussi bien (ma connexion ssh était juste un peu lente, mais pas de blocage particulier).

vendredi 18 mars 2005

Oups, panique a bord

Note pour plus tard, ne plus JAMAIS faire cp /usr/local/ssl/lib/*(.) /usr/lib/ pour la mise à jour d'Openssl lorsque vous êtes connecté en ssh car dès que les fichiers seront copiés, la communication sera coupée INSTANTANÉMENT ! Les clients ainsi que le serveur sshd seront tous killés !

Résultat, la machine, installée dans une belle salle machine située aux États-Unis se retrouve coupée du monde. Et là... c'est vraiment le drame car vous êtes un hébergeur [archive] tout de même, et le client attend.

Par chance, les connexions sortantes du serveur ne sont pas bloquées par le firewall (pas bien, quoique...) et vous avez un Apache qui peut executer vos scripts CGI uploadés via FTP (et non par SFTP comme d'hab').

Vous vous dîtes "facile", y a qu'à uploader un script qui appelle netcat afin de faire un reverse shell (oublier le reverse ssh puisque je vous ai dit qu'il était complément mort). Ce shell tournera avec l'identité d'Apache mais c'est pas grave, vous ferez un /bin/su... sauf que netcat n'ouvre pas un tty et donc su ou sudo refusent de travailler !

Le temps presse et vous vous rappelez de rrs [archive], un programme conçu pour faire des reverses shells proprement : il ouvre un tty au moins. Donc vous le compilez à la va-vite et l'uploadez par votre moyen favori...

Et c'est gagné ! La coupure ssh a duré 40 minutes, promis la prochaine fois, je ferais mieux :(

Non mais quelle idée de ne pas utiliser une distribution Debian et ses paquets magiques...

Update : Ah oui et puis j'ai oublié de dire que j'avais essayé phpshell.php [archive] mais comme le safe_mode est utilisé... Pas possible.

dimanche 13 mars 2005

HTTP Uploader

uploader.perl [archive] est un simple script Perl/CGI qui permet d'uploader des fichiers quelconques dans un répertoire donné. Le script est capable de calculer la somme MD5 du fichier reçu et de l'écrire dans un fichier MD5SUM.txt afin de vérifier le résultat plus tard. D'ailleurs, je fais afficher ce fichier lorsque je visite le répertoire d'upload grâce à mod_autoindex d'Apache et la directive :

 ReadmeName MD5SUM.txt 

vendredi 4 mars 2005

Analyse des logs Kismet en fonction du temps

En tant que pauvre étudiant qui se respecte, je n'ai pas les moyens de m'acheter une carte GPS PMCIA afin de conserver la localisation des access points découverts lors de balades wardrivantes [archive]. Une méthode qui vaut ce qu'elle vaut est de se baser sur le temps.

viewkismetlogs.perl [archive] crée une image représentant les minutes écoulées depuis le début sur une règle. Si un réseau est découvert, un baton est tracé sur cette règle et est coloré en orange/vert si ce point d'accès utilise WEP.

Mais plutot que de blablater, voici un exemple d'image [archive] qui clarifiera tout.

viewkismetlogs.perl [archive] récupère les informations via les fichiers XML que Kismet [archive] crée (/var/log/kismet/*xml sous Debian).