Logo GNT
Actualités Tests & Guides Bons Plans
GTA 6 iPhone 17 Copilot Switch 2 Temu ChatGPT Tesla
OVH Cloud OVH Cloud
Entraide Sécurité Sécurité Sécurité Tentatives de scans en utilisant l'adresse DNS du FAI comme emetteur

Tentatives de scans en utilisant l'adresse DNS du FAI comme emetteur

9 réponses
Avatar
ludo06
Bonjour,

J'ai depuis quelques temps de nombreuses tentatives de scans UDP sur ma
machine, et comme le nombre va en s'intensifiant j'aimerais trouver une
solution. La catacteristique de ces scans est qu'ils utilisent l'adresse
IP de machines de mon FAI comme adresse source (adresse du serveur
DNS...). Je ne peux donc pas blacklister ces machines, car mon serveur
DNS interne les utilise pour notamment la resolution des noms. J'ai
d'abord pense que ca venait reellement de mon FAI, et l'ai contacte a ce
sujet, mais en attendant, et comme on m'a suggere que l'adresse ip
source etait sans doute spoofe, je souhaiterais identifier l'origine
reelle des scans [ou au moins ecarter l'hypothese que ca vienne
reellement de mon FAI).

Quelqu'un pourrait me decrire brievement une methode ? ou me renvoyer
sur un pointeur approprie ?

Par ailleurs je suis tres souvent deconnecte de l'Internet, se pourrait
il que les types de scans que je subis en sois la cause ? [je n'ai pas
encore correle les dates des scans et mes periodes de deconnections]

Merci par avance et bonne journee,
Ludo

Annexes:
--------

Extraits des rapports Snort des deux derniers jours

Ces rapports montre la progression en nombre des scans. J'imagine que la
recrudescence des scans est liee a mon passage en ip fixe en fin de
semaine derniere.

Rapport snort d'hier:

Dimanche
--------
Events between 04 03 07:33:43 and 04 04 06:11:55
Total events: 92
Signatures recorded: 18
Source IP recorded: 15
Destination IP recorded: 2

Events from same host to same destination using same method
=========================================================================
# of from to method
=========================================================================
45 212.27.32.176 192.168.0.2 (portscan) UDP Portscan
12 212.27.32.177 192.168.0.2 (portscan) UDP Portscan
4 207.46.98.124 192.168.0.2 WEB-MISC robots.txt access
4 85.180.25.108 192.168.0.2 SCAN FIN
3 81.56.72.58 192.168.0.2 ICMP PING NMAP
2 80.182.36.154 192.168.0.2 SCAN FIN
2 207.46.98.126 192.168.0.2 WEB-MISC robots.txt access
2 212.27.32.176 192.168.0.2 (portscan) UDP Decoy Portscan
2 84.56.109.38 192.168.0.2 ICMP PING NMAP
2 212.27.32.176 192.168.0.2 (portscan) UDP Distributed
Portscan
2 66.46.15.40 192.168.0.2 (http_inspect) BARE BYTE
UNICODE ENCODING



Samedi
------
Events between 04 02 06:43:23 and 04 03 00:49:06
Total events: 19
Signatures recorded: 9
Source IP recorded: 10
Destination IP recorded: 2


Events from same host to same destination using same method
=========================================================================
# of from to method
=========================================================================
4 192.168.0.2 192.168.0.3 (portscan) UDP Portsweep
4 207.46.98.124 192.168.0.2 WEB-MISC robots.txt access
2 212.27.39.136 192.168.0.2 (portscan) TCP Portscan




Vendredi
--------

Events between 04 01 09:23:30 and 04 02 05:37:10
Total events: 41
Signatures recorded: 10
Source IP recorded: 12
Destination IP recorded: 4


Events from same host to same destination using same method
=========================================================================
# of from to method
=========================================================================
13 212.27.32.176 192.168.0.2 (portscan) UDP Portscan
6 192.168.0.3 192.168.0.2 (http_inspect) OVERSIZE
REQUEST-URI DIRECTORY
4 212.27.32.177 192.168.0.2 (portscan) UDP Portscan
4 207.46.98.124 192.168.0.2 WEB-MISC robots.txt access
2 212.27.39.136 192.168.0.2 (portscan) TCP Portscan
2 192.168.0.2 192.168.0.3 (portscan) UDP Portsweep
Signaler un problème avec ce contenu

9 réponses

Supprimer
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire

Veuillez sélectionner un problème

Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Avatar
Cedric Blancher
Le Mon, 04 Apr 2005 06:58:41 +0000, ludo06 a écrit :
J'ai depuis quelques temps de nombreuses tentatives de scans UDP sur ma
machine, et comme le nombre va en s'intensifiant j'aimerais trouver une
solution. La catacteristique de ces scans est qu'ils utilisent l'adresse
IP de machines de mon FAI comme adresse source (adresse du serveur
DNS...).


Je ne dis pas que ce qui va suivre est ton cas, mais le cas du port scan
UDP depuis le serveur DNS du FAi est un cas assez classique de faux
positif. Lorsque la liaison entre toi et le DNS rame un peu, il se passe
souvent ceci :

1. tu émets une requête
2. la réponse n'arrive pas avant le timeout
3. tu fermes la socket et tu réémets une requête
4. la réponse à la première arrive, mais trop tard
5. etc.

Comme les ports sources choisis par ton OS sont consécutifs, tu vas
recevoir une série de paquets, venant du port 53 du serveur DNS de ton
FAI, destinés à une série de port UDP fermés sur ta machine. Et pas le
port scan.

C'est un grand classique sur les connexions bas débit type RTC, ce qui
ne semble pas êrtre ton cas cependant (ADSL). Ceci dit, ça arrive aussi
sur des liens de plus haut débit.

Matte un peu ton log Snort complet pour voir quels sont les ports source
et destination de ces scans, histoire de confirmer ou non l'hypothèse
émise au dessus.

-> les IDS, c'est comme les scanners de vuln, ça lève énormément de
faux positifs, et il donc la plupart du temps repasser derrière à la
mimine pour vérifier (mais pour ça, faut des logs)...

Je ne peux donc pas blacklister ces machines, car mon serveur
DNS interne les utilise pour notamment la resolution des noms.


Tu peux configurer ton serveur DNS sans forwarder pour qu'il aille taper
les root servers directement. Tu dois virer les directives de forward et
te trouver un fichier hint à jour (un coup de dig et hop).

J'ai d'abord pense que ca venait reellement de mon FAI, et l'ai contacte
a ce sujet, mais en attendant, et comme on m'a suggere que l'adresse ip
source etait sans doute spoofe, je souhaiterais identifier l'origine
reelle des scans


Identifier la source réelle des scans n'est pas possible sur un scan UDP
bien fait, vu que le paquet ne va contenir aucune info sur la source autre
que l'adresse IP source, qui serait spoofée. Ceci dit, quel est
l'intérêt de lancer un scan UDP spoofé, dans la mesure il y a très peu
de chance qu'on soit suffisamment bien placé pour voir les réponses
(s'il y en a) ?

--
Le jeu est disponible sur le cédérom de PCJeux du mois de juin.
Cela ne permet pas pour l'instant d'accéder au jeu
-+- betatest-prophetie in Guide du Petit Joueur: Oui, mais non -+-

Avatar
ludo06
Bonjour,

Et merci pour ta reponse rapide qui eclaire bien des aspects pour moi.
J'ai une petite question par rapports a ta reponse, mais ne te sens pas
oblige ou presse d'y repondre, j'ai deja fort a faire pour regler mon
snort et prendre en compte tes remarques pour remedier au probleme.

Cedric Blancher wrote:
...

Je ne peux donc pas blacklister ces machines, car mon serveur
DNS interne les utilise pour notamment la resolution des noms.



Tu peux configurer ton serveur DNS sans forwarder pour qu'il aille taper
les root servers directement. Tu dois virer les directives de forward et
te trouver un fichier hint à jour (un coup de dig et hop).

Je ne connais pas en profondeur DNS, mais l'auteur du scan peut usurper

aussi l'identite des root servers ?

Merci encore,
Cordialement,
Ludo


Avatar
Stephane Catteau
Cedric Blancher nous disait récement dans fr.comp.securite
<news: :

Ceci dit, quel est l'intérêt de lancer un scan UDP spoofé, dans la
mesure il y a très peu de chance qu'on soit suffisamment bien
placé pour voir les réponses (s'il y en a) ?


Il me semblait qu'il y avait une variante UDP de l'idlescan, ma
mémoire m'a joué des tours ? Ou j'ai mal compris son principe, ce qui
est possible aussi.


--
"En amour, on plaît plutôt par d'agréables défauts que par des qualités
essentielles ; les grandes vertus sont des pièces d'or, dont on fait
moins usage que de la monnaie"
Ninon de Lenclos

Avatar
Cedric Blancher
Le Mon, 04 Apr 2005 09:16:13 +0000, Stephane Catteau a écrit :
Il me semblait qu'il y avait une variante UDP de l'idlescan, ma
mémoire m'a joué des tours ? Ou j'ai mal compris son principe, ce qui
est possible aussi.


Tu pourrais effectivement faire à peu près la même chose, mais il faut
s'appuyer sur un port fermé du zombie, et détecter l'émission du ICMP
port unreachable. Ça me semble nettement plus hasardeux, mais possible.

Cependant, tu vas faire face aux problèmes classiques du scan UDP, à
savoir faire générer une réponse au port quand il est ouvert, ce qui
veut dire se tourner vers des scans avec des vrais payloads applicatifs,
genre une requête DNS pour tester le port 53.


--
#if 0
2.2.16 /usr/src/linux/fs/buffer.c

Avatar
ludo06
ludo06 wrote:
La catacteristique de ces scans est qu'ils utilisent l'adresse
IP de machines de mon FAI comme adresse source (adresse du serveur
DNS...).
Precision: ce sont les adresses en 212.27.* qui posent probleme.

@+
Ludo

Avatar
Manu
ludo06 wrote:
Bonjour,

J'ai depuis quelques temps de nombreuses tentatives de scans UDP sur ma
machine, et comme le nombre va en s'intensifiant j'aimerais trouver une
solution. La catacteristique de ces scans est qu'ils utilisent l'adresse
IP de machines de mon FAI comme adresse source (adresse du serveur
DNS...). Je ne peux donc pas blacklister ces machines, car mon serveur


Est-ce que ceci ne pourrait pas être la cause :
voir "Increasing cases of DNS poisoning being spotted"
http://www.viruslist.com/en/weblog

Peut-être faudrait-il avoir le contenu de ces packets.

Avatar
ludo06
Manu wrote:
ludo06 wrote:

Bonjour,

J'ai depuis quelques temps de nombreuses tentatives de scans UDP sur ma
machine, et comme le nombre va en s'intensifiant j'aimerais trouver une
solution. La catacteristique de ces scans est qu'ils utilisent l'adresse
IP de machines de mon FAI comme adresse source (adresse du serveur
DNS...). Je ne peux donc pas blacklister ces machines, car mon serveur



Est-ce que ceci ne pourrait pas être la cause :
voir "Increasing cases of DNS poisoning being spotted"
http://www.viruslist.com/en/weblog

Peut-être faudrait-il avoir le contenu de ces packets.
C'est peut etre ca car j'ai les remontees suivantes dans le resume de snort:


3 212.27.32.176 192.168.0.2 (portscan) UDP Portscan
2 212.27.32.176 192.168.0.2 DNS zone transfer UDP

Ceci dit j'ai les regles suivantes dans mon firewall:
Chain INPUT (policy DROP)
....
ACCEPT tcp -- 192.168.0.0/24 anywhere tcp dpt:domain
ACCEPT tcp -- 192.0.0.0/2 anywhere tcp spt:domain
ACCEPT udp -- 192.168.0.0/24 anywhere udp dpt:domain
ACCEPT udp -- 192.0.0.0/2 anywhere udp spt:domain

Qui a priori interdise a quiconque exterieur a mon reseau (enfin sauf la
freebox sur 192.168.0.254 - mais je m'en charge dans la conf bind) de
faire quelque chose de mon serveur DNS.

Mon DNS ne va pas sur les serveurs DNS de mon FAI [dans mes messages
d'hier j'avais oublie ce detail, je viens de le voir], ce qui interdit
tout piratage non ? A moins que l'on puisse affecter le routage pour
faire atterrir les paquets destines aux DNS de mon FAI ailleurs, mais ca
doit pas etre possible a moins de controler le(s) routeur(s) entre moi
et lui non ?

Addendum securite:

J'utilise une configuration bind comme telle (c'est peut etre pas le top
- j'espere aussi que ce n'est pas trop long par rapports aux regles du
forum. Peut etre allez vous me dire que c'est moi qui l'ai tellement mal
configure que je declenche tout ce binz :-)):

:~$ cat /etc/bind/named.conf.local
// Ubik Products Com zone
// All machines except gateway
acl ubik-corp {
!192.168.0.254;
192.168.0/24;
127.0.0.1;
};

view "internal" {
match-clients { ubik-corp; };
recursion yes;

//Here i have added all the zones since we provide services only for
//the local network
//Also, when using 'view' statements, all zones must be in views.

zone "." {
type hint;
file "/etc/bind/db.root";
};

zone "localhost" {...};

zone "127.in-addr.arpa" {...};

zone "0.in-addr.arpa" {...};

zone "255.in-addr.arpa" {...;

// Provide a complete view of the ubik-products.com zone
// including addresses of internal hosts.
zone "ubik-products.com" {
type master;
file "/etc/bind/ubik-products.com.db";
};

//Reverse mapping for local network
zone "0.168.192.in-addr.arpa" {
type master;
file "/etc/bind/192.168.0.rev";
};

};

//
view "external" {
match-clients { any; };
recursion no;

zone "." {
type hint;
file "/etc/bind/db.root";
};

zone "localhost" {...};

zone "127.in-addr.arpa" {...};

zone "0.in-addr.arpa" {...};

zone "255.in-addr.arpa" {...};

// Provide a complete view of the ubik-products.com zone
// including addresses of internal hosts.
// redirect to the NS of zoneedit.com
zone "ubik-products.com" {
type forward;
forwarders {
216.110.187.226;
216.122.4.160;
};
};

};

key "rndc-key" {...};

//controls {
// inet 127.0.0.1 port 953
// allow { ubik-corp; } keys { "rndc-key"; };
//};


Mon resolv.conf:

:~$ cat /etc/resolv.conf
nameserver 127.0.0.1
domain ubik-products.com
search ubik-products.com
#nameserver 212.27.32.176
#nameserver 212.27.32.177

Merci par avance pour vos reponses, et bonne journee,
Cordialement,
Ludo


Avatar
ludo06
ludo06 wrote:
Ceci dit j'ai les regles suivantes dans mon firewall:
Chain INPUT (policy DROP)
....
ACCEPT tcp -- 192.168.0.0/24 anywhere tcp dpt:domain
ACCEPT tcp -- 192.0.0.0/2 anywhere tcp spt:domain
ACCEPT udp -- 192.168.0.0/24 anywhere udp dpt:domain
ACCEPT udp -- 192.0.0.0/2 anywhere udp spt:domain

Je viens d'enlever

ACCEPT tcp -- 192.0.0.0/2 anywhere tcp spt:domain
et
ACCEPT udp -- 192.0.0.0/2 anywhere udp spt:domain
de mon iptable. Ca fait du bien de se relire parfois. Cela peut etre ca
? Il faudrait que l'attaquant ait forge des paquets avec l'adresse
bizarre adequate ceci dit.

Cordialement,
Ludo

Avatar
ludo06
ludo06 wrote:
ludo06 wrote:

Ceci dit j'ai les regles suivantes dans mon firewall:
Chain INPUT (policy DROP)
....
ACCEPT tcp -- 192.168.0.0/24 anywhere tcp
dpt:domain
ACCEPT tcp -- 192.0.0.0/2 anywhere tcp
spt:domain
ACCEPT udp -- 192.168.0.0/24 anywhere udp
dpt:domain
ACCEPT udp -- 192.0.0.0/2 anywhere udp
spt:domain

Je viens d'enlever

ACCEPT tcp -- 192.0.0.0/2 anywhere tcp spt:domain
et
ACCEPT udp -- 192.0.0.0/2 anywhere udp spt:domain
de mon iptable. Ca fait du bien de se relire parfois. Cela peut etre ca
? Il faudrait que l'attaquant ait forge des paquets avec l'adresse
bizarre adequate ceci dit.

Cordialement,
Ludo
Pour terminer sur le sujet, apres un bon nettoyage de mes regles

iptables j'ai bien moins de ports exposes et j'ai installe portsentry
pour bloquer les tentatives de scans en temps reel. Je m'interroge sur
les effets de bords de portsentry (que va-t-il se passer le jour ou on
va faire un scan sous l'identite de Google ? Portsentry devrait le
bloquer tel que configure actuellement)

J'etudie le sujet et fait des tests, merci pour votre aide en tout cas,
Cordialement

Ludo
--
-----BEGIN GEEK CODE BLOCK-----
Version: 3.1
GCS/ED dx s-: a- C+++ UBL*+++>$S++ P++ L+++ E W+++ N++ o-- K+++++ w---
O- M++ V-- PS+++ PE+++ Y++ PGP++ t+ 5 X-- R+++ tv+ b+++ DI+++ D+ G+ e++
h-- r++ z++++
------END GEEK CODE BLOCK------
"La souveraine Puissance doit laisser chacun libre de penser ce qu'il
veut et d'exprimer sa pensee" - Spinoza - Traite des autorites
theologiques et politiques