Possible attaque de réseau? [Résolu]

Support Debian
#1

Bonsoir,

J’ai une situation pour laquelle je ne sais pas si je dois m’inquièter ou non. Je me considère entre un débutant et un intermédiaire sur mon ordinateur debian. En effet, j’y ai installé un serveur SSH, NTP et Bacula pour l’instant et tout semble fonctionner (jusqu’à maintenant) (Version etch, en passant). J’ai eu aussi à jouer avec les règles de Iptables pour m’assurer que mon ordinateur ait été suffisament protégé même s’il se situe en arrière d’un routeur Linksys.

J’ai aussi pris l’habitude de lire régulièrement mes fichiers journaux (particulièrement auth.log et syslog) pour détecter les anomalies. Dernièrement (en fait hier) j’ai reçu plusieurs messages d’Iptables sur syslog concernant des paquets d’informations non-autorisés. En voici deux exemples:

Dec 5 19:46:21 localhost kernel: IN=eth1 OUT= MAC=XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX SRC=66.102.1.104 DST=192.168.XX.101 LEN=40 TOS=0x00 PREC=0x00 TTL=255 ID=10961 PROTO=TCP SPT=80 DPT=44993 WINDOW=0 RES=0x00 RST URGP=0
Dec 5 21:18:50 localhost kernel: IN=eth1 OUT= MAC=XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX SRC=74.54.73.229 DST=192.168.XX.101 LEN=40 TOS=0x00 PREC=0x00 TTL=255 ID=13558 PROTO=TCP SPT=80 DPT=34638 WINDOW=0 RES=0x00 RST URGP=0

(J’ai mis des « XX » pour me garder une petite gêne :wink:)

J’en avais reçu par le passé un de temps en temps. Mais hier c’était 12 en l’espace de deux heures et de 4 adresses IP différentes. Ça a évidemment attiré mon attention.

Donc si j’ai bien compris, il s’agit de:
[ul][li]Paquets reçus[/li]
[li]À partir du port d’un serveur web (80)[/li]
[li]Sur un port aléatoire de mon ordinateur[/li]
[li]Qui visait mon ordinateur en particulier (pas un broadcast)[/li][/ul]

Je crois avoir bien configuré mon routeur. Il n’y a qu’une redirection pour le port SSH pour que je puisse accéder à mon ordinateur à distance. Et pourtant je ne comprends pas comment quelqu’un a pu se rendre jusqu’à mon ordinateur.

Est-ce que c’est déjà arrivé à quelqu’un? Est-ce que je peux faire quelque chose pour améliorer la sécurité de mon ordinateur? Est-ce que je devrais m’inquièter de la situation?

Merci

Evens

#2

Si quelqu’un essaye un DOS sur un serveur Web en lui envoyant des requêtes d’origine aléatoire, ce serveur répondra aux adresses aléatoires, tu peux être dans ces adresses… Laisse courir.

#3

Oui, fran.b, mais ça n’explique pas comment ce serveur web peut envoyer même par hasard des paquets sur un port 80, alors que seul le 22 est ouvert théoriquement. Je crois que tu as encore survolé la question.

EvensF: à par sniffer pour voir, je ne vois pas comment déterminer d’ou ça peut venir.
pistes:

  • ces paquets sont des réponses légitimes à ton surf sur le serveur web, et les règles iptables qui te loguent ces paquets dans la catégorie “bizarre” sont un peu abusives et t’alertent inutilement,
  • c’est toi qui emet d’une autre manière des paquets à destination du serveur web, et les paquets retour que tu reçois sont considèrés comme légitimes par le pare feu du linksys,
  • ton linksys est mal configuré.

En tous cas, j’irais dans le sens de fran.b pour dire qu’il n’y a pas trop à s’inquièter.

#4

Non, non…
SPT=80 DPT=34638
le port source est le 80, donc ça vient d’un serveur Web extérieur vers le port de la machine (censé être aléatoire et pas sur le port 80). Le fait même qu’il reçoit un paquet sur un port autre que le 22 prouve 3 choses:

  • Sa machine est en DMZ
    OU
  • Il y a un souci dans le routeur
    OU
  • Il a interrogé le serveur et ce paquet est un paquet retour mal interprété par iptables (pbm de connexion, 2ième paquet ACK envoyé par le serveur, …)

PS: De mauvais poil ce matin?

#5

Non pourquoi ?
Non non, je t’assure, je suis dans une phase de réveil calme. Ma supposition quant au survol est juste pour me moquer d’un de tes défauts habituel, mais qui ne me gène pas du tout. ça me fait juste rigoler quand ça arrive.

#6

[quote=“mattotop”]Non pourquoi ?
Non non, je t’assure, je suis dans une phase de réveil calme. Ma supposition quant au survol est juste pour me moquer d’un de tes défauts habituel, mais qui ne me gène pas du tout. ça me fait juste rigoler quand ça arrive.[/quote]
En fait, j’ai lu ce message 30s après que ma chère et tendre m’ait dit que je n’étais pas attentif à ce qu’elle disait [ce qui était vrai remarque], du coup comme je me disais qu’elle était de mauvais poil [ce qui s’est avéré], j’ai rajouté ce PS… (comme ça je ne lui ai rien dit…)

#7

Bonjour,

Merci pour les réponses rapides. À partir de vos réponses, j’ai continué mon enquête et voici des éclaircissements et des éléments de réponse:

[ul]
[li]Mon ordinateur n’était pas en DMZ[/li]
[li]J’ai essayé de localiser les sites référencés dans ces messages avec le site GeoMapLookup (geomaplookup.cinnamonthoughts.org/) et je me suis aperçu que plusieurs de ces adresses étaient en fait des sites que j’avais visités à peu près à ces moments-là. Même que une des adresses a un nom de domaine qui se termine en .google.com![/li][/ul]

Donc j’en conclus qu’il s’agit probablement d’effets secondaires de ma navigation sur internet. Il reste quelques adresses bizarres mais en beaucoup moins grand nombre.

Il avait été mentionné de peut-être utiliser un packet sniffer. Je me suis dit que ça vaudrait la peine que je regarde ça. Ça pourrait m’être utile. Est-ce qu’il y en a que vous me recommandez? (J’ai vu Wireshark [wireshark.org/], par exemple)

Merci encore

Evens

#8

Wireshark est très bien: tu captures l’ensemble du bazar lors de ta navigation puis tu vas regarder les logs, tu vois les 2-3 paquets bizaroïdes et tu regardes ce qu’ils sont. J’avoue que je suis curieux de savoir ce que c’est mais je parie sur un ACK surnuméraire ou retardataire…)

#9

Bon, je vais prendre le temps d’apprendre Wireshark et jouer un peu avec lui. C’est moins une urgence maintenant, mais lorsque j’aurai des nouvelles, je vous tiendrai au courant.

Merci encore.

Evens

#10

je ne vois pas bien le but de rajouter une couche d’iptables si tu es déjà derrière un pare feu qui protège tes machines grace au NAT. mais bon…

par contre si tu n’as ouvert que le port 22 vers ton PC, c’est clair qu’il ne faut te soucier que des adresses à destination de ce port. donc tu peux tout de suite faire un filtre sur DPT=22.

tu as aussi le soft failtoban (je crois) qui va automatiquement blacklister les adresses IP sources des méchants sur ton serveur SSH.

#11

François et Mathieu :
Ne vous battez pas, vous avez tous les deux raison, vos hypothèses sont valables. Sauf celle de l’ACK en trop ou en retard, il suffit de regarder le message du noyau : c’est un RST (reset) ayant pour but de couper la connexion, peut-être en trop ou en retard. Je crois aussi me rappeler que le suivi de connexion TCP de netfilter est plus strict concernant les paquets RST, afin d’éviter que des paquets contrefaits puissent couper une connexion établie.

Thomas :
Le NAT n’est pas une protection. Au contraire, ajouterais-je en faisant un peu de provocation.

#12

[quote=“PascalHambourg”]François et Mathieu :
Ne vous battez pas, vous avez tous les deux raison, vos hypothèses sont valables.[/quote]
Ben la prochaine fois, j’engueulerais ma moitié, j’en entendrais moins parler :slightly_smiling:

Je croyais que le RST était plutôt une réinitialisation que je voyais comme
<- RST
-> SYN
<- SYN ACK
-> ACK
puis la suite. Quelle est la différence avec FIN?

Edit: Mais je viens de lire que le paquet RST peut venir en réponse à un paquet SYN si le port est fermé sur un routeur ou un parefeu…?? Tu as des idées précises là dessus?

#13

Je ne suis pas un grand spécialiste de TCP, hein.
RST provoque bien une réinitialisation de la connexion, mais dans son état initial, c’est-à-dire LISTEN pour le serveur ou CLOSED pour le client. Il peut être émis en réponse à un segment TCP reçu qui ne correspond pas à une connexion TCP existante sur le destinataire (ça peut a arriver quand un des côtés a été déconnecté brusquement sans que l’autre en soit informé). Il n’y a pas forcément de resynchronisation ensuite, sauf si le client décide d’établir une nouvelle connexion. Effectivement RST est le mécanisme normal pour signaler que le port de destination est fermé, pas seulement pour un pare-feu ou un routeur mais pour toute pile TCP/IP. Certains pare-feu utilisent plutôt un message ICMP “port unreachable” (type 3 code 3) ou “communication adminitratively prohibited” (type 3 code 13).

FIN sert à terminer “proprement” une connexion établie. Il fonctionne de façon similaire à SYN, avec une séquence en trois phases :
-> FIN
<- FIN/ACK
-> ACK

#14

[quote=“PascalHambourg”]
Thomas :
Le NAT n’est pas une protection. Au contraire, ajouterais-je en faisant un peu de provocation.[/quote]

oui d’accord il n’en est qu’une partie et simplifie la vie des utilisateurs de box ADSL.

mais le principe routeur + nat permet quand même de ne pas router les paquets dans les sens WAN vers LAN sauf si tu as fait une rêgle spécifique pour un port ou si le paquet est une réponse.

donc à partir de là il est quand même plus simple de se concentrer sur les logs du pare feu qui concernent les ports ‘ouverts’ sur celui çi, que de rajouter de l’iptable et du log sur chaque machine.

non ?

#15

Je ne suis pas du tout d’accord. Voici ma vision des choses.

Ce n’est pas le NAT qui fait que les paquets ne sont pas routés, c’est l’utilisation sur le LAN d’adresses privées non routées sur l’internet public (à ne pas confondre avec non routables). La situation de base, adresses privées sans NAT, c’est donc que le LAN est injoignable de l’extérieur. Là-dessus on est obligé d’ajouter du NAT pour rétablir un semblant de connectivité (et non pour la limiter) ; le NAT source (masquerading) permet d’établir des connexions sortantes et de recevoir les réponses, le NAT destination (redirection de port…) permet de recevoir des connexions entrantes. Nulle part il n’est question de filtrage.

Quand tu dis que le NAT facilite la vie des utilisateurs, je m’inscris en faux. Au contraire, les exemples pullulent (trois lettres : FTP). Ce n’est pas pour des prunes qu’on pousse l’IPv6 (pas assez fort hélas). Le niveau de simili-sécurité pourrait aussi bien être atteint sans NAT en filtrant les connexions entrantes, de la même façon qu’on crée des redirections de ports.

#16

le nat a été conçu pour trois choses :

  • permettre l’utilisation d’adresses IP privées pour palier au manque de celles çi
  • permettre au personnes qui utilisent des adresses IP publiques sur leur réseau privée de ne pas rentrer en conflit avec les vrai possesseurs de ces adresses
  • permettre l’interconnexion de deux réseaux privés qui utilisent la même plage d’adresse

c’est bien le fait d’activer le NAT sur tes interfaces qui fait que les adresses du réseau privé ne seront pas transmises sur le réseau publique (qu’elles soient rouatbles ou non d’ailleurs) mais c’est l’adresse IP du routeur (dans le cas du MASQ) qui fera office d’adresse IP source.

donc le nat ‘cache’ tout le réseau privé derrière une ou plusieurs adresses IP publiques.

et sur un routeur avec le NAT (MASQ) activé tu ne peux pas rentrer sur le réseau privé sauf si une translation de port te l’autorise explicitement ou si la connexion a été initiée par une machine du réseau privé.

c’est là que je voyais une simplicité d’utilisation et de sécurisation pour l’utilisateur lamba qui n’a donc pas besoin de rajouter du pare-feu sur toutes les machines du réseau privé.

donc vu cela, il est tout à fait possible que ce principe de translation(même si il n’est pas parfait) persiste même après la migration en IPV6.

#17

quote="PascalHambourg"
Au contraire, les exemples pullulent (trois lettres : FTP).
(…)[/quote] La solution est plus longue ip_nat_ftp.

#18

Thomas :
Les exemples que tu cites de situations où le NAT est utile mettent en évidence que le NAT sert à créer une connectivité IP là où elle ne serait pas possible sans NAT. Le NAT en lui-même n’est donc pas une protection ni un pare-feu dont le rôle est exactement inverse : limiter une connectivité IP existante.

Certes, en un sens le mécanisme du NAT cache le réseau local qui est derrière pour les communications sortantes et les communications entrantes redirigées. Mais rien ne dit que ce même NAT empêche de communiquer directement avec le réseau local si ce dernier utilise des adresses routées depuis l’extérieur (publiques, pour faire simple). En ce qui concerne le NAT de Linux, c’est clair : il ne l’empêche pas. Pas besoin de translation de port, il suffit de connaître l’adresse de la machine cible et le routeur transmet. Le NAT ne se substitue pas au routage, il s’y ajoute. C’est l’utilisation d’adresses privées non routées depuis l’extérieur en plus du NAT ou la présence d’un filtrage (pare-feu) qui empêche de communiquer directement depuis l’extérieur.

Quant à la prétendue simplicité de configuration et d’utilisation du NAT pour sécurisé le réseau local, en quoi est-elle meilleure qu’un simple pare-feu sans NAT sur le routeur ? Les paramètres seraient exactement les mêmes : protocole, port et adresse de destination. Mais l’action serait simplement ACCEPT au lieu de DNAT.

J’espère qu’il n’y aura jamais de NAT pour IPv6. En ce qui concerne Linux, aux dernières nouvelles il n’en est pas question. IPv6 intègre des mécanismes qui ont pour but de s’en passer :

  • suffisamment d’adresses globales pour éviter tout risque de pénurie ;
  • attribution d’un préfixe global et non d’une simple adresse globale à chaque utilisateur, contenant suffisamment d’adresses pour n’importe quel nombre de machines ;
  • génération d’adresses locales uniques avec un algorithme conçu pour éviter au maximum les conflits en cas d’interconnexion entre réseaux privés.

Mathieu :
ip_nat_ftp (ou nf_nat_ftp pour les noyaux récents, 2.6.20 et plus) n’est pas la solution parfaite et universelle. Il a quelques limites, notamment :

  • ne marche que pour les ports déclarés, par défaut le port 21 seulement ;
  • ne marche pas avec le FTP chiffré par TLS/SSL ;
  • ne marche pas si la commande PORT/EPRT ou la réponse à la commande PASV/EPSV est fragmentée entre plusieurs segments (j’ai vu passer des messages concernant une implémentation qui envoyait le retour chariot final dans un segment séparé).

Pour être juste ces limitations concernent en réalité le module assistant de suivi de connexion FTP ip_conntrack_ftp/nf_conntrack_ftp, dont dépend le module assistant de NAT FTP. Elles s’appliquent donc aussi à un pare-feu à état (stateful). Ceci dit, avec un simple pare-feu sans NAT il reste au moins la possibilité d’autoriser une plage de ports pour les connexions de données. Avec du NAT ce n’est pas suffisant, c’est plus compliqué. Une différence entre filtrage et NAT, c’est que le filtrage se contente d’inspecter le trafic, alors que le NAT doit en plus le modifier (et pas seulement les adresses et/ou ports).

#19

ah ! si tu le dis ! aussi je n’ai jamais essayé de routeur/pare-feu linux. je voulais en installer un à titre perso mais depuis ce post sur les serveurs d’impression ou ils ont calculé la facture électrique annuelle d’un pc, j’ai décidé de me calmer.

Donc une fois de plus je me rends compte en lisant des docs sur lesquelles il est écrit :

que ce qui est valable chez cisco n’est pas valable partout. et comme on est sur un forum debian et non sur un forum cisco je m’incline. :smt102

#20

ha les échanges entre mat et pascal, un vrai régal!
Est ce qu’on peut se procurer des routeurs/wifi/parefeu IPv6/IPv4 à un prix raisonnable ?
Je n’en est pas encore croisé …