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

Support Debian
#21

[quote=“thomas.leclerc”]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[/quote]

En toute première approximation c’est vrai, lorsque tu fais du NAT, le serveur ne voit arriver sur ses ports que les paquets sur les ports «routés», les autres ports apparaissent fermés. Donc il a une certaine tranquillité. Cependant

  • C’est du filtrage tout ou rien, tu ne peux pas faire un filtrage plus subtil (en fonction du nombre de connexions, de l’IP source, du type de paquet, du port knocking, etc) sauf à mettre un parefeu sur le routeur bien sûr…
  • En général on ne s’occupe pas du routeur lui même, on peut se poser la question de savoir si lui aussi a des ports ouverts ou non. Si c’est une machine passerelle, la question se pose et on peut se poser la question d’un parefeu sur cette passerelle.
  • Enfin, sur des installations très sensibles ou pour des ports très particuliers, les ports autorisés en sortie sont importants (n’importe quel gestionnaire d’un parc contenant une machine Windows sait qu’il faut au moins bloquer en sortie le port 25).

Bref, le NAT assure une protection minimale qui peut convenir dans un cadre trnaquille modulo quelques précautions mais considérer que ça fait un parefeu automatiquement est réducteur sur ce qu’est un parefeu et sur les possibilités d’iptables par exemples…

(Enfin c’est ma vision des choses)

#22

m’enfin fran.b ne me fait pas dire ce que je n’ai pas dit, je n’ai pas parlé de filtrage ou de connexions sortantes, ou même dit que le nat était la panacée en matière de sécurité et qu’il se suffisait à lui même.

mon erreur a juste été de penser que, comme indiqué dans les doc cisco, le fait d’activer le NAT sur un routeur active en même temps le blocage des connexions entrantes ce qui est une sécurisation minimum nécéssaire du réseau privé, mais apparemment le mécanisme ne se fait pas automatiquement sur un routeur linux. j’en ai peut être fait une généralité un peu vite. mais quelle que soit le materiel utilisé, l’interface publique du routeur/fw devra bien sur être ‘blindée’ et ‘inpenétrable’.

enfin tout ça pour dire à EvensF que si il n’a ouvert que le port 22 de son routeur linksys avec une redirection vers le port 22 de sa debian il ne risque pas se faire attaquer sur le ‘port aléatoire de mon ordinateur’ comme il dit. mais seul le port 22 serait à surveiller sur cette machine. et le reste du trafic directement sur le routeur.

#23

Si je peux me permettre une question supplémentaire (J’ai quand même commencé ce fil de discussion :slightly_smiling: )

[quote=“PascalHambourg”]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. [/quote]

J’ai eu un flash. Serait-il possible que ces messages que je reçois d’Iptables puissent être provoquées par une réinitialisation du routeur? Je sais que parfois je dois réinitialiser mon routeur parce qu’il n’arrive plus à faire suivre les requêtes DNS à propos d’un site que j’étais en train de consulter. La plupart du temps en pesant sur reset sur le routeur, je peux recommencer à naviguer sur Internet.

Serait-il possible que si une ou plusieurs connexions avaient été ouvertes au moment où j’aurais fait cette réinitialisation mon ordinateur ait pu renvoyé ces paquets en particulier? Iptables les auraient alors bloqués et enregistrés dans syslog?

Evens

#24

[quote=“thomas.leclerc”]m’enfin fran.b ne me fait pas dire ce que je n’ai pas dit,[/quote]Il semble que je ne suis pas adroit sur ce fil :frowning:

Oui.

#25

Evens :
Ce n’est pas ton ordinateur qui envoie ces paquets RST, ce sont les serveurs web avec lesquels il communique. Du moins en apparence, si on ne se fie qu’à l’adresse source. Ils pourraient en fait être émis par le routeur. C’est ce que ferait une règle iptables de ce type :

Pour déterminer lequel du serveur ou du routeur les a envoyés, il faut examiner le TTL (Time To Live). Un paquet IP est émis avec un TTL initial entre 1 et 255 et sa valeur est diminuée de 1 par chaque routeur traversé. Ici on voit qu’il vaut 255, la valeur maximum. C’est donc certainement le routeur qui les a émis (à moins qu’il trafique le TTL, mais ce serait tordu).

La première chose à faire pour vérifier, c’est de comparer les dates de réception de ces paquets avec les moments où tu as réinitialisé le routeur.

Le scénario pourrait être le suivant. Ton poste établit une connexion avec un serveur web distant à travers le routeur. Supposons que le navigateur a demandé une connexion persistante, permettant de faire plusieurs requêtes HTTP dans la même connexion TCP, au lieu d’établir une connexion TCP séparée pour chaque requête HTTP. Là-dessus, tu réinitialise le routeur, ce qui efface sa table de suivi d’état de connexion/NAT. Puis ton navigateur fait une nouvelle requête HTTP, provoquant l’envoi d’un paquet dans la connexion existante. Comme cette connexion n’existe pas pour le routeur, celui-ci rejette le paquet avec un RST envoyé à ton poste, en imitant l’adresse source du serveur. Jusqu’ici, rien d’anormal. Mais là où ça ne colle plus, c’est que ces paquets RST sont bloqués et loggés par iptables probablement parce que le suivi de connexion TCP de ton poste les classe dans l’état INVALID. Or ils devraient normalement être classés comme ESTABLISHED et acceptés. Les raisons possibles incluent :

  • une anomalie dans le numéro de séquence ou d’acquittement de ces paquets (la faute au routeur),
  • un bug dans le suivi de connexion TCP de ton poste (la faute au noyau),
  • ces paquets sont dupliqués (envoyés en double), le premier est accepté (et coupe la connexion TCP) et c’est le second qui est loggé et bloqué (la connexion TCP ayant été coupée par le premier).
#26

Hmmm… La manière dont j’ai réglé les règles Iptables fait en sorte qu’il ne faut pas nécessairement qu’un paquet soit INVALID pour qu’il soit loggué. Par exemple, ça ressemble à :

iptables --append INPUT --match state --state "ESTABLISHED,RELATED" --jump ACCEPT
iptables --append INPUT --protocol tcp --destination-port ssh --jump ACCEPT
iptables --append INPUT --protocol icmp --jump ACCEPT
iptables --policy INPUT DROP
[...]
# Par exemple : trafic Netbios du réseau local (pour éviter qu'il soit enregistré dans la règle suivante)
iptables --append INPUT --protocol udp --destination-port netbios-ns:netbios-ssn --in-interface eth1 --source 192.168.XX.0/24 --jump DROP
[...]
iptables --append INPUT --jump LOG

(Oui, je sais, j’utilise les options d’Iptables au long parce que c’est plus facile pour moi lorsque je dois revenir jouer dans ces règles)

Donc comme tu peux le voir, je définis les règles de manière à ce que par défaut iptables rejette les paquets. Mais avant de rejeter un paquet je définis plusieurs autres règles où je le laisse passer ou non. Juste avant que le paquet se rende au comportement par défaut (iptables --policy INPUT DROP) le paquet est envoyé au journal (iptables --append INPUT --jump LOG).

Est-ce qu’il faudrait que j’ajoute une règle quelque part pour tenir compte de cette situation particulière qui arrive?

Evens

#27

Si les paquets RST avaient été classés dans l’état ESTABLISHED, ils auraient été acceptés par la première règle. Avant d’envisager d’ajouter une règle pour tenir compte de ce cas particulier, l’important est de savoir si c’est gênant ou non que ces paquets soient bloqués par iptables. La conséquence d’un RST bloqué, c’est à peu près la même que celle d’un filtrage par DROP plutôt que par REJECT : l’émetteur envoie un paquet, ne reçoit pas de réponse, fait éventuellement des retransmissions, attend jusqu’à expiration d’un délai et finalement abandonne. As-tu constaté cela ?

Si ce n’est pas gênant et que tu veux juste que ces paquets ne soient pas enregistrés dans le journal, il suffit d’insérer une règle comme pour les ports NetBIOS.

#28

Je veux voir si j’ai bien compris.
[ul]
[li]Ces paquets sont le résultat du serveur web qui demande à mon ordinateur de fermer la connexion persistante TCP que celui-ci a probablement ouverte par le passé. [/li]
[li]Iptables l’enregistre dans le journal (selon les règles que j’ai définies) parce qu’il ne le retrouve pas dans sa liste de connexions établies. [/li]
[li]Il y a des bonnes chances que la connexion ne soit plus établie parce que j’aurais probablement réinitialisé mon routeur qui à ce moment-là [/li][/ul]

Si c’est bien ça, je dois avouer que je ne l’avais constaté auparavant parce que je n’avais pas fait le lien entre la réinitialisation de mon routeur et ces messages enregistrés. D’ailleurs, lorsque j’arrivais pas à rejoindre un site web, je considérais que c’était probablement un problème de réseau.

Je vais faire quelques tests et ramener les résultats ici bientôt.

[quote=“PascalHambourg”]Si les paquets RST avaient été classés dans l’état ESTABLISHED, ils auraient été acceptés par la première règle. Avant d’envisager d’ajouter une règle pour tenir compte de ce cas particulier, l’important est de savoir si c’est gênant ou non que ces paquets soient bloqués par iptables.

[…]

Si ce n’est pas gênant et que tu veux juste que ces paquets ne soient pas enregistrés dans le journal, il suffit d’insérer une règle comme pour les ports NetBIOS.[/quote]

Toujours si j’ai bien compris la situation, j’ai l’impression qu’il faudrait que j’accepte ce paquet plutôt que de le rejeter pour s’assurer que tout le monde ferme bien ses connexions correctement, non? Mais est-ce que ça rend mon ordinateur vulnérable? Est-ce que quelqu’un pourrait y trouver une faille et s’introduire dans mon ordinateur?

Evens

#29

[quote=“EvensF”]Je veux voir si j’ai bien compris.
[ul]
[li]Ces paquets sont le résultat du serveur web qui demande à mon ordinateur de fermer la connexion persistante TCP que celui-ci a probablement ouverte par le passé. [/li]
[li]Iptables l’enregistre dans le journal (selon les règles que j’ai définies) parce qu’il ne le retrouve pas dans sa liste de connexions établies. [/li]
[li]Il y a des bonnes chances que la connexion ne soit plus établie parce que j’aurais probablement réinitialisé mon routeur qui à ce moment-là [/li][/ul][/quote]
En fait, si on se fie au TTL enregistré par iptables, ces paquets sont plutôt émis par le routeur, et non par le serveur. S’ils étaient émis spontanément par le serveur après que le routeur ait été réinitialisé, le résultat serait différent : le routeur ne les reconnaîtrait pas comme appartenant à une connexion existante, et les jetterait au lieu de les transmettre au poste client. S’ils étaient émis par le serveur en réponse à un paquet émis par le poste client après que le routeur ait été réinitialisé (par exemple parce que le routeur a changé d’adresse ou de port source), d’une part ils devraient avoir un TTL inférieur à 255, et d’autre part le suivi de connexion du poste client devrait les reconnaître comme appartenant à une connexion existante.

[quote=“EvensF”]
Toujours si j’ai bien compris la situation, j’ai l’impression qu’il faudrait que j’accepte ce paquet plutôt que de le rejeter pour s’assurer que tout le monde ferme bien ses connexions correctement, non? Mais est-ce que ça rend mon ordinateur vulnérable? Est-ce que quelqu’un pourrait y trouver une faille et s’introduire dans mon ordinateur?[/quote]
Il ne faut accepter ces paquets que s’il s’avère que les bloquer perturbe le bon fonctionnement. Sinon, tu peux laisser courir. Les accepter reviendrait à accepter des paquets RST dans l’état INVALID. Au pire cela pourrait être exploité par un attaquant pour couper des connexions TCP établies, si jamais un tel paquet RST était accepté par la pile TCP/IP (il ne suffit pas qu’il passe iptables pour avoir un effet, car la pile TCP/IP vérifie aussi les numéros de séquence indépendamment du suivi de connexion de netfilter).

#30

[quote=“PascalHambourg”]
Il ne faut accepter ces paquets que s’il s’avère que les bloquer perturbe le bon fonctionnement. Sinon, tu peux laisser courir. Les accepter reviendrait à accepter des paquets RST dans l’état INVALID. Au pire cela pourrait être exploité par un attaquant pour couper des connexions TCP établies, si jamais un tel paquet RST était accepté par la pile TCP/IP (il ne suffit pas qu’il passe iptables pour avoir un effet, car la pile TCP/IP vérifie aussi les numéros de séquence indépendamment du suivi de connexion de netfilter).[/quote]

Bon, à première vue, ça ne semble pas perturber mon système si je les bloque donc c’est ce que je vais faire. Si jamais j’observe que quelque chose ne fonctionne plus comme avant, j’ajusterai en conséquence.

Merci à tous pour votre aide et particulièrement à PascalHambourg.

Evens