Il n’y a pas de véritable moyens DNS pour déterminer tous les noms de domaines pointant vers une IP

Le PTR ne donne pas ce que l’on recherche…
Les transferts de zones sont heureusement souvent non authorisés et ne donneraient pas tous les résultats (mais que ceux du serveur DNS en question)
La brute force..on oublie..

Bref.. Il reste l’indexation faite par les moteurs de recherche…

www.live.com permet de faire ce type de recherche en utilisant la syntaxe:

ip:194.109.137.218

L’appel à cette fonction permet d’afficher une petite animation d’attente lors du déroulement d’un script.

#!/bin/bash  

attente(){  
PROC=$1  
while [ -d /proc/$PROC ];do  
echo -en ' En cours... /\033[1G' ; sleep .07  
echo -en ' En cours... -\033[1G' ; sleep .07  
echo -en ' En cours... \ \033[1G' ; sleep .07  
echo -en ' En cours... |\033[1G' ; sleep .07  
# echo -en ' <DesEspacesIciSiBesoin> \033[1G'  
done  
}  
ping -c4 10.10.10.10 >/dev/null 2>&1 &  attente $(pidof ping)  

Une petite démo pour mieux visualiser le résultat:

On peut imaginer d’autres variantes:

Ce billet fait suite à celui présentant smtp-source

smtp-sink permet de recevoir des mails pour des tests, par exemple de performances…

• Le serveur en écoute:

$ smtp-sink -4c -d "%Y%m%d%H/%M." :2525 1024  

• L’envoi de mails par exemple avec smtp-source:

$ smtp-source -c -l 50 -m 5 -f test@example.org -t aaa@bbb.org -S Test -M www.example.org 127.0.0.1:2525

Les mails peuvent êtres stoqués sur le “serveur” dans des fichiers (ou pas).

$ ls 2008012700/  
31.02381c00 31.5e1a0566 31.62b49729 31.66cc641f 31.7241899a  
$  

$ cat 2008012700/31.02381c00   
X-Client-Addr: 127.0.0.1  
X-Client-Proto: SMTP  
X-Helo-Args: www.example.org  
X-Mail-Args: test@example.org  
X-Rcpt-Args: aaa@bbb.org  
Received: from www.example.org ([127.0.0.1])  
by smtp-sink (smtp-sink) with SMTP id 02381c00;  
Sun, 27 Jan 2008 00:31:10 +0100 (CET)  
From: test@example.org  
To: aaa@bbb.org  
Date: Sun, 27 Jan 2008 00:31:10 +0100 (CET)  
Message-Id: 31d3.0003.0003@www.example.org  
Subject: Test  

XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX  

$  

Bref… un “honeypot SMTP” sans risque, possible en 1 ligne…

Mémo: recherche que dans une colonne avec awk

• Un grep “normal”

$ grep c toto  
a b c d e  
b c d e a  
c d e a b  
$

• Recherche des lignes qui ne contiennent le pattern que dans la colonne définie:

$ awk '$2 == "c"' toto  
b c d e a  
$

• Introduction

OpenNTPD est le démon NTP du projet OpenBSD.

En général, c’est un autre démon NTP qui utilisé “par défaut” sous Gnu/Linux, il s’agit de ntpd ( Package Debian ntp)

Attention, dans les 2 cas le binaire s’appelle /usr/sbin/ntpd.

OpenNTPD présente, à mon sens et pour une utilisation générale (synchronistaion du serveur lui-même), deux avantages sur ntpd :

• Il n’ouvre pas de port en local (par défaut).
  A ma connaissance il n’est pas possible de restreindre ceci avec ntpd ???
• Sa configuration me semble beaucoup plus facile et limpide que celle de ntpd (même si les fonctionnalités ne sont pas forcément les mêmes).

Un démon NTP présente à mon sens et pour une utilisation générale, deux avantages principaux sur des clients NTP comme ntpdate:

• Les démons (qui utilisent adjtime) ne provoquent pas de changement brutaux de l’horloge (et encore moins des changements “dans le passé” qui provoquent l’arrêt de certains services)
• Les démons peuvent “gérer” les connexions vers plusieurs serveurs NTP (par exemple notion de “retry” ou de priorité).

Tests en vrac

(A noter que les résultats sont surement les mêmes avec ntpd que ceux ci-dessous réalisés avec OpenNTPD)

$ date -R  
Sun, 30 Dec 2007 15:22:53 +0100  

J’avance d’environ 5 minutes (pas + de 42 minutes) [1]

$ sudo date -s "Sun, 30 Dec 2007 15:28:53 +0100"  
dimanche 30 décembre 2007, 15:28:53 (UTC+0100)  

On démarre le démon:

$ sudo /etc/init.d/openntpd start  
Starting openntpd: ntpd.  

Voici les logs:

Dec 30 15:30:17 bipbip ntpd[12524]: adjusting local clock by -333.503437s  
Dec 30 15:33:24 bipbip ntpd[12524]: adjusting local clock by -333.484404s  
Dec 30 15:36:08 bipbip ntpd[12524]: adjusting local clock by -333.377035s  
Dec 30 15:39:48 bipbip ntpd[12524]: adjusting local clock by -333.287172s  
Dec 30 15:43:27 bipbip ntpd[12524]: adjusting local clock by -333.168930s  
Dec 30 15:45:41 bipbip ntpd[12524]: adjusting local clock by -333.087043s  
Dec 30 15:49:47 bipbip ntpd[12524]: adjusting local clock by -332.961041s  
Dec 30 15:51:58 bipbip ntpd[12524]: adjusting local clock by -332.854474s  
Dec 30 15:56:01 bipbip ntpd[12524]: adjusting local clock by -332.726167s  
Dec 30 16:00:20 bipbip ntpd[12524]: adjusting local clock by -332.589575s  
Dec 30 16:03:07 bipbip ntpd[12524]: adjusting local clock by -332.470866s  

On peut observer que:

• La correction est d’environ une seconde en l’espace de 30 minutes.

• L’écart se réduit mais en aucun cas le serveur ne fait un saut “dans le passé” pour revenir à l’heure réelle.

Extraits des man:

L’ajustement réalisé par adjtime() sur l’horloge est exécuté afin que l’horloge soit toujours incrémentée de façon monotone. Utiliser adjtime() pour ajuster le temps prévient les problèmes qui peuvent se poser avec certaines applications (par exemple, make(1)) lors de sauts temporels abrupts positifs ou négatifs de l’horloge système.

Si l’ajustement dans delta est positif, alors l’horloge système est accélérée d’un faible pourcentage (par exemple, en ajoutant une petite quantité de temps à chaque seconde de l’horloge) jusqu’à ce que l’ajustement soit réalisé. Si l’ajustement dans delta est négatif, l’horloge est ralentie selon le même procédé.

(Open)ntpd uses the adjtime system call to correct the local system time without causing time jumps. Adjustments larger than 128ms are logged using syslog. The threshold value is chosen to avoid having local clock drift thrash the log files.

Testons donc maintenant en retardant cette fois d’une minute environ (au lieu d’avancer de 5 minutes)

$ date -R  
Sun, 30 Dec 2007 16:01:02 +0100  
$ sudo date -s "Sun, 30 Dec 2007 16:00:00 +0100"  
dimanche 30 décembre 2007, 16:00:00 (UTC+0100)  

Dec 30 16:01:44 bipbip ntpd[12621]: adjusting local clock by 72.942552s  
Dec 30 16:05:19 bipbip ntpd[12621]: adjusting local clock by 72.925635s  
Dec 30 16:07:42 bipbip ntpd[12621]: adjusting local clock by 72.849986s  
Dec 30 16:10:33 bipbip ntpd[12621]: adjusting local clock by 72.782798s  
Dec 30 16:12:46 bipbip ntpd[12621]: adjusting local clock by 72.695125s  
Dec 30 16:16:33 bipbip ntpd[12621]: adjusting local clock by 72.634382s  
Dec 30 16:19:52 bipbip ntpd[12621]: adjusting local clock by 72.513312s  
Dec 30 16:23:46 bipbip ntpd[12621]: adjusting local clock by 72.437547s  
Dec 30 16:26:51 bipbip ntpd[12621]: adjusting local clock by 72.338498s  
Dec 30 16:30:07 bipbip ntpd[12621]: adjusting local clock by 72.245159s  
Dec 30 16:33:46 bipbip ntpd[12621]: adjusting local clock by 72.181572s  
Dec 30 16:38:02 bipbip ntpd[12621]: adjusting local clock by 72.057567s  
Dec 30 16:40:49 bipbip ntpd[12621]: adjusting local clock by 71.994909s  
Dec 30 16:45:07 bipbip ntpd[12621]: adjusting local clock by 71.881804s  

La correction est d’environ une seconde en l’espace de 45 minutes.

On a donc, dans un sens comme dans l’autre, une correction de l’heure très “douce”, à la manière de la dérive “normale” d’une horloge.

[1]

adjtime() est prévue pour faire de petit ajustement de l’horloge système. La plupart des systèmes impose une limite à l’ajustement qui peut être spécifié dans delta. Dans l’implémentation de la glibc, delta doit être inférieur ou égal à (INT_MAX / 1000000 - 2) et supérieur ou égal (INT_MIN / 1000000 + 2) (respectivement 2145 et -2145 secondes sur les x86).

Si je teste une différence d’une heure on obtient:

Dec 30 18:12:11 bipbip ntpd[12693]: adjusting local clock by -3860.229766s  
Dec 30 18:12:11 bipbip ntpd[12693]: adjtime failed: Invalid argument  

Donc pour un gros ajustement ntpdate peut être utile… (mais attention aux effets sur les services qui tournent comme par exemple Dovecot).