Bonjour à tous,j’ai scanné les ports en écoute sur ma machine perso (je fais juste tourner un serveur ssh pour se connecter à distance) et je me demandais si la sécurité en était assurée.
Voilà ce que ça donne:
Plus tu as de port ouvert et plus tu as de surface d’attaque.
Plus ta surface d’attaque est grande plus tu as de possibilité d’avoir une faille et donc une introduction possible.
C’est bien pour cela que les coffre fort n’ont pas de fenêtre 
En fait, les sockets écoutent sur localhost. C’est-à-dire que seuls les processus qui tournent sur ta machine peuvent utiliser ces ports.
Tu devrais t’assurer que tu veux bien du truc qui écoute sur le port 37212 en IPv6. Ajoutes l’option -p à netstat pour t’en assurer (à lancer en tant que root).
Celles qui ont comme adresse locale “localhost”, 127.x.x.x ou ::1, mais pas toutes.
Quelques-unes écoutent sur toutes les adresses IPv4 ("*" ou 0.0.0.0) ou IPv6 ("::"). A noter que dans certaines conditions une socket en écoute sur toutes les adresses IPv6 accepte aussi les connexions sur n’importe quelle adresse IPv4.
La solution de facilité consiste à autoriser l’accès seulement aux ports désirés avec des règles de filtrage iptables et ip6tables. Mais il est plus propre de désactiver ou désinstaller les services inutiles, ou de les configurer pour n’écouter que sur localhost quand c’est possible.
Le portmapper RPC (port sunrpc) est utilisé par d’autres services comme le partage de fichiers NFS. On peut afficher la liste de ces services avec
rpcinfo -p
Si la liste est vide, le paquet/service rpcbind peut être désinstallé ou désactivé.
1 J'aime
Tout d’abbord merci pour vos réponses, j’ai désinstallé bindrpc car je n’en avais pas l’utilité et je ne sais pas pourquoi mais certains sockets en écoute on disparu, notamment celui en Ipv6 sur le port 37212. Au final, il ne me reste que mon serveur ssh et des sockets en écoute sur ma machine (localhost), ce qui donne une table beaucoup plus propre:
Je suppose que la sécurité est assurée maintenant (surtout que je pense qu’il n’y a pas de personnes malveillantes sur mon réseau local, de plus le port 22 ssh n’est pas redirigé vers ma machine depuis la box).
Si tu veux sécuriser encore plus, tu peux modifer la configuration du serveur ssh dans le fichier /etc/ssh/sshd_config en définissant la clef PermitRootLogin à without-password ou no et PasswordAuthentication à no.
Après, il paraît qu’il y a un truc qui s’appelle fail2ban, mais je ne recommande jamais quelque chose que je n’ai jamais vu à l’œuvre.
Après, je ne connais pas l’utilisation de cette machine, mais tu peux aussi désactiver ou désinstaller le serveur ssh si tu ne t’en sers pas.
1 J'aime
Malveillante, on ne te le souhaite évidemment pas ;-). Ceci dit, un utilisateur maladroit et/ou un un appareil mal configuré peuvent vite créer un point d’entrée (ça risque, je crains, d’être de plus en plus vrai avec l’internet des objets). Pour ces raisons, je recommande quand même toujours l’utilisation d’un pare-feu sur la machine.
Ça protège effectivement bien des tentatives d’attaque “frontale” (brute force et dictionnaire).
Ah, moi, contre ça, je refuse toute authentification par mot de passe et j’ajoute une règle iptables pour n’accepter qu’une seule connexion ssh par minute.
-A INPUT_OK -p tcp -m tcp --dport ssh -m state --state NEW -j SSH_CHECK
-A SSH_CHECK -m recent --set --name SSH --rsource
-A SSH_CHECK -m recent --update --seconds 60 --hitcount 2 --name SSH --rsource -j DROP
-A SSH_CHECK -j ACCEPT
Pour ceux qui veulent utiliser cette règle, il faut ajouter 1 à la valeur hitcount voulue.
1 J'aime
Donc si un méchant connaît ton adresse IP, il peut t’empêcher de te connecter en envoyant un peu plus d’un paquet usurpant ton adresse IP par minute.
C’est exactement la remarque que j’allais te faire : tu peux te faire coincer dehors par un neuneu qui te brute force. Fail2ban bannit par IP, c’est quand même un net avantage ;-).
Ses règles iptables aussi grâce à l’option --rsource de la correspondence recent, mais elles résistent beaucoup moins bien que fail2ban à l’usurpation d’adresse (spoofing) car elles se basent sur un seul paquet sans qu’une connexion soit forcément établie alors que fail2ban se base sur des connexions établies. Or il est beaucoup plus difficile d’établir une connexion TCP en usurpant une adresse que d’envoyer un simple paquet.
J’oubliais l’autre inconvénient de sa méthode : elle a une mémoire limitée (100 adresses par défaut), donc on peut se faire oublier rapidement en envoyant des paquets avec une autre adresse.
Toutefois, ces deux attaques reposent sur la capacité de l’attaquant à usurper une adresse IP. Sur internet, les FAI sérieux empêchent l’usurpation d’adresse IP de la part de leurs clients (mais pas de la part des clients d’autres FAI, donc ne protègent pas leurs propres clients contre l’usurpation d’adresse IP de la part de clients d’autres FAI moins scrupuleux), cela fait partie des “bonnes pratiques”. Au sein d’un même réseau local, cela depend des équipements réseau.
1 J'aime
Merci pour les précisions @PascalHambourg , et désolé @Almtesh pour les conclusions hâtives, du coup ;-).
Pas de mal, mais il est vrai que je n’en attends pas une sécurité parfaite, ça fait juste une couche de sécurité supplémentaire.