Jeedom sous Raspberry ralentit ma connexion Internet

Bonjour tout le monde,

Cela fait des années que j’utilise Jeedom, et récemment pour mettre à jour j’ai du faire la réinstallation pour passer sous Debian.

J’ai donc procédé à une nouvelle installation via ce lien :

https://doc.jeedom.com/fr_FR/installation/rpi

En prenant une image Jeedom Raspberry sur mon Raspberry 3

J’ai ensuite mis ma sauvegarde. Mais j’ai remarqué un énorme soucis, en branchant en Ethernet (comme j’ai toujours fait) mon raspberry, ma connexion Internet (je suis en fibre) jouait au yoyo avec des pertes de débit énorme. J’ai donc tout débranché pour pouvoir bosser cette semaine.

Je viens de rebrancher le raspberry et j’ai remarqué en le branchant sur un écran qu’il effectue des frrappes sur des adresses IP en continue pour télécharger des paquets, je me demande si ça viendrait pas de là.

Avez-vus déjà eu le soucis ?

Bonjour,

Qu’entendez-vous par « des frappes » ???

sinon un log peut-être?

Il effectue des téléchargement de paquets sur des IP quand je branche le RPI sur un écran.

Je vais essayer de récupérer un screen des logs qu’il effectue

Voilà les logs il tente d’accéder à des adresses IP avec permission denied, et ensuite tente le téléchargement d’un paquet pour zmap module, et ça en boucle

Et Qu’avez-vous ouvert comme traffic vers votre pi depuis internet ?
Y a-t-il un accès ssh ouvert par exemple ?
Ça pue quand même non ?

Perso je couperais immédiatement et je formaterais le tout.

D’après moi votre pi à été hack et un bot tourne dessus pour tester d’autres connexions.

2 « J'aime »

Hello,

C’est clair, ça sent le port 22/ssh avec l’accès direct … Il manque que plus qu’un mot de passe par défaut pour le sans faute

2 « J'aime »

un truc du genre

@belorom, ton pi est connecté directement sur le port 22 de ta box? C’est pas un peu dangereux? En général, il vaut mieux passer par un port non connu. Même avec un bon mot de passe, le port 22 c’est du pain béni pour un hacker qui a du temps et plusieurs ip disponibles…

Bonjour,

En effet un port non standard est conseillé.
Et un fail2ban en plus n’est pas du luxe non plus.

Conseillé, j’irai pas jusqu’à dire ça… Le SSH exposé directement, sur un port 22 ou un autre, c’est pas conseillé tout court ! Même quand on sait ce qu’on fait c’est dangereux

Un fail2ban n’est pas suffisant ?
Que conseilles-tu ?
J’avoue que mes connaissances en sécurité datent un peu.

Sur le principe, pas de ssh exposé. Certes, un fail2ban (bien configuré ça aide) mais c’est, je crois même pas par défaut dans la conf…
Quand c’est vraiment indispensable, il faut bannir les accès par mot de passe, et n’autoriser que ceux par clé sur un user spécifique. Le tout qui fonctionne sur une VM/machine dédiée, avec rien d’autre dessus… et surtout pas jeedom.

1 « J'aime »

Quelques infos pour la sécurité (bon sens):

  • tester tous les ports d’une adresse IP est couteux. un ssh sur le port 22 qui répond « login as: » c’est tenter le diable. Mais on sait pas encore quels sont les users accessibles :slight_smile:
  • le raspberry pi démocratise Linux et les comportements risqués aussi. Qu’il y ait un vers/virus qui tente d’exploiter cette faille est plutôt normal. Qu’une fois entré dans le réseau, il essaye d’infecter d’autres ordinateurs, c’est son boulot et qu’il essaye de se connecter à l’extérieur aussi :wink:
  • fail2ban est puissant, mais l’est t’il contre une attaque de plusieurs mois avec une grande plage d’ip source possible (j’ai pas regardé), d’ou la préconisation de naboleo de ne pas avoir de password en ssh (juste une clé public autorisée pour certains users uniquement)
  • pas jeedom dessus, j’ai pas les moyens de me payer un serveur de rebond, par contre je peux appliquer les conseils précédents

Hello

Le coût c’est très relatif, chaque machine à disposition pouvant servir de petite main, c’est uniquement une question de temps.
C’est même plus simple qu’un mot de passe, car il n’y a que 65536 choix

Exactement fail2ban ça aide mais c’est pas infaillible. Une source unique sur une longue période c’est complexe à détecter. Et avec des actions coordonnées c’est encore plus dur à voir

Ça n’a ni besoin d’être une bête de course, ni besoin d’être un matériel récent. Un pi3 sur une carte sd ça fera très bien l’affaire. Si la carte est fichue au bout d’un moment, on la remplace.
Donc c’est pas un coût nul mais très certainement bien faible par rapport à une installation domotique

1 « J'aime »

Utiliser un port non-standard est une erreur de base: cela ne fait que donner un sentiment de plus grande sécurité alors qu’il n’en est rien et donc potentiellement réduire notre attention sur le reste.

Si cela vous rassure de le faire, alors c’est mauvais car il n’en est rien.

Autrement dit: changer le port n’autorise de supprimer aucune autre précaution et si les autres précautions sont prises changer le port n’apporte aucune sécurité supplémentaire, au mieux cela ralentira une attaque.

1 « J'aime »

Il me semble que le port 0 n’est pas utilisé. :grin:

1 « J'aime »

Oui, donc ça va encore plus vite :joy:

1 « J'aime »

J’en suis conscient, et c’est pas ce que j’ai dit. Mais entre tester tous les ports pour accéder à un serveur domotique, et tester juste le port SSH et les ports standard, c’est pas le même effort. D’ailleurs c’est ce que fait le vers concerné. Il regarde que les ports 22 des @ip v4 et tente de se connecter en pi avec le password par défaut… basique, mais ça peut marcher

Merci de vos conseils, oui j’ai débranché directement le RPI.

Il était je crois sur un port 22, mais via la doc d’install on peut définir un nouveau port ?

Il ne faut juste pas ouvrir ce port sur votre box internet.
Donc il ne faut pas faire de redirection du port ssh (22 ou autre ne change rien) sur votre box internet vers votre pi.

Et/ou pas le mettre en DMZ

1 « J'aime »