~50% packet loss sur serveur debian

[PascalHambourg]

Utilisant surtout tcpdump, je ne suis pas familier avec le format d'affichage de wireshark mais j'ai l'impression que 62 est la taille du paquet et non un numéro de port. Les numéros de ports source et destination seraient respectivement 21079 et 8611, qui ne m'évoquent rien ni l'un ni l'autre.

Au lieu de bloquer le trafic vers des ports et adresses inconnues, tu pourrais au contraire n'autoriser les connexions sortantes que vers les ports et/ou adresses connus que ton serveur est censé utiliser (réseau local, DNS, HTTP, HTTPS...).

Il n'est pas facile de savoir quel processus a émis un paquet. Avec "netstat -n4p" (en root) tu peux afficher les sockets IPv4 et les processus qui les ont ouvertes. Mais s'il s'agit d'un processus malveillant, il risque de dissimuler sa présence.

[lol]

Salut,

Je ne suis pas un adepte de la réinstallation, mais si la machine est corrompue c'est tout de même prudent...
Le serveur est dans ton LAN tout de même, il a accès à tout.

Concernant ton pare-feu, je suis étonné de voir ceci:

Code : Tout sélectionner

:INPUT ACCEPT [1044:495560]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [1017:461669]

Chez moi ça commence comme ça:

Code : Tout sélectionner

:INPUT DROP [124:31405]
:FORWARD DROP [0:0]
:OUTPUT DROP [0:0]

Ensuite, j'autorise, au compte goutte ce qui doit l'être.
PascalHambourg confirmera (ou pas) mais je crois qu'il vaut mieux commencer par tout bloquer et n'ouvrir que ce dont on a besoin.

[PascalHambourg]

Je suis d'accord sur la réinstallation en cas de suspicion de compromission et sur la politique d'iptables.

[harkness]

J'ai déjà eu le problème avec ce serveur et je l'avais résolu avec une réinstallation, il y a environ 1 mois(je n'avais pourtant jamais eu de probleme avant de changer d'un vieux eee-pc pour un nuc). Mais le problème est revenu.
Et d'accord, je vais tout bloquer et autoriser seulement les choses dont j'ai besoin. Et si tout était autorisé c'est que j'ai utiliser une commande pour reset tout les règles d'iptable avec

Code : Tout sélectionner

iptables -F && iptables -X && iptables -t nat -F && iptables -t nat -X && iptables -t mangle -F && iptables -t mangle -X && iptables -P INPUT ACCEPT && iptables -P OUTPUT ACCEPT && iptables -P FORWARD ACCEPT

Mais étrangement depuis que je l'ai reboot vers 19h, je n'ai plus aucun trafic réseau louche ni problème de connexion, je ne sais pas trop d’ou ça vient :o

[lol]

Salut,

J'ai déjà eu le problème avec ce serveur et je l'avais résolu avec une réinstallation, il y a environ 1 mois(je n'avais pourtant jamais eu de probleme avant de changer d'un vieux eee-pc pour un nuc). Mais le problème est revenu.
...
Mais étrangement depuis que je l'ai reboot vers 19h, je n'ai plus aucun trafic réseau louche ni problème de connexion, je ne sais pas trop d’ou ça vient :o

Tu as quoi d'installer comme softs dessus ? Il sert à quoi ce serveur ?
Tu utilise les dépôts Debian officiels ou tu utilise aussi des dépôts plus exotiques ?

[harkness]

Bon j'ai enfin réussi à autoriser que les ports dont j'ai besoin après des jours a galéré avec iptables. Donc je pense que cette fois ça devrait être bon, mais c'est vrai que toutes ces requêtes sont tres louches.
Sinon comme je l'ai dit dans mon 1er message mon serveur me sert juste pour des services perso à savoir : gitlab, openvpn, nextcloud, flood(front pour rtorrent), jeedom, plex et je crois que c'est tout.
Voici le résultat de la commande dpkg-query -l : http://textup.fr/238415zb
Et sinon au niveau des dépôts je pense que j'utilise les officiel voici mon fichier sources.list

Code : Tout sélectionner

#

# deb cdrom:[Debian GNU/Linux 9.2.1 _Stretch_ - Official amd64 NETINST 20171013-13:07]/ stretch main

# deb cdrom:[Debian GNU/Linux 9.2.1 _Stretch_ - Official amd64 NETINST 20171013-13:07]/ stretch main

deb http://ftp.fr.debian.org/debian/ stretch main non-free
deb-src http://ftp.fr.debian.org/debian/ stretch main non-free

deb http://security.debian.org/debian-security stretch/updates main non-free
deb-src http://security.debian.org/debian-security stretch/updates main non-free

# stretch-updates, previously known as 'volatile'
deb http://ftp.fr.debian.org/debian/ stretch-updates main non-free
deb-src http://ftp.fr.debian.org/debian/ stretch-updates main non-free
deb https://apt.dockerproject.org/repo debian-stretch main

[lol]

Salut,
Rtorrent et Plex sont susceptibles de provoquer des connexions incessantes.

Si tu as une seedbox, c'est normal d'avoir de la saturation réseau (d'autant plus si tu ne limite pas raisonnablement le débit...), et des connexions incessantes vers des ip externes. Du coup je comprend mieux. Le protocole torrent est assez difficile à contrôler, il ne lâche pas la bande passante facilement...

J'ai laissé tombé Plex que je trouvais de moins en moins ouvert et de plus en plus commercial... Il ne tournait plus sans être connecté à un serveur extérieur, ça m'a gonflé...
J'ai remplacé par Kodi sur les clients (Le serveur délivre les fichiers multimédias via Samba ou NFS).

[harkness]

Salut ^^, je n’avais pratiquement rien en seed sur rtorrent et les requêtes était toujours a la même IP(avant que je la bloque et que d'autres IP prennent le relais) chinoise et pour plex on est que 2 a l'utiliser et jamais au même moment donc je ne pense pas que ce soit ça :o
Surtout que j'ai tout configuré avec iptables, ma seedbox fonctionne très bien, mais plus avec ce flood de requête a la même IP en continu(y en avais tellement a la seconde que c'était illisible sur le terminal). Mais je ne vois vraiment pas ou j'aurais pus attraper un truc vérolé(deux fois de suite en plus Oo).
Et sinon c'est vrai que plex est pas hyper ouvert, mais j'aime beaucoup l'interface et c'est facile de partager le contenu avec d'autres utilisateurs^^. Y'a emby qui est pas mal aussi et opensource mais ils nous poussent a prendre un abo aussi.

Enfin en tous cas merci beaucoup de votre aide, tout a l'air de fonctionner

[PascalHambourg]

avec ce flood de requête a la même IP en continu(y en avais tellement a la seconde que c'était illisible sur le terminal)

L'affichage sur le terminal n'est pas une bonne métrique. Il suffit de 10 paquets par seconde pour que ce soit illisible, et pourtant au niveau trafic réseau ce n'est rien du tout.

Mais je ne vois vraiment pas ou j'aurais pus attraper un truc vérolé(deux fois de suite en plus Oo).

Il suffit d'une faille de sécurité dans un des services de la machine qui sont accessibles de l'extérieur.

[piratebab]

si tu as seulement ouverts les quelques ports dont tu as besoin, un client de torrent ne fonctionnera pas. autant le virer complètement.
et tu pourras faire un test en ré-ouvrant les ports et voir si c'était lui mettait le bazar.
Mais j'en doute, les clients torrents ouvrent de trés nombreuses connexions vers de trés nombreuses IP différentes.
ta réinstall, tu l'as faites from scratch ?

[franb]

Ta connexion arrivait sur un port, tu peux regarder via netstat le processus concerné et sa justification... Tu peux eventuellement faire une capture par tcpdump pour analyser un peu finement le trafic