Pour les serveurs, on lit souvent qu’il vaut mieux modifier les N° de port.
SSH ?
HTML ?
IMAP ?
Autres ?
Qu’en est-il exactement ?
Pour lesquels une modification présente-telle un véritable intérêt ?
Toute autre info bienvenue.
Bonjour,
il est possible d’identifier une adresse IP et d’identifier les ports ouverts sur le net.
Si le port 22 est ouvert, traditionnellement il est utilisé par ssh. Or, sur les systèmes GNU/Linux, il y a un compte commun à tous les ordinateurs : Root.
Du coup, on tape :
Il ne reste plus qu’à trouver le mot de passe Root pour se connecter à la machine.
D’où également le fait qu’il est fortement conseillé de mettre l’option PermitRootLogin sur no ( /etc/ssh/sshd_config) et d’avoir un mot de passe solide.
Salut,
Le port SSH oui. En principe tu es le seul à t’y connecter, donc en changer ne pose pas de problème.
Pour le reste… il vaut mieux (si ce sont des services “publics”) qu’ils restent sur les ports par défaut.
J’ai tenté une fois sur un serveur utilisé par beaucoup de monde de changer le port 21 (j’avais trop d’attaques, ça gonflait mes logs; et ça me gonflait…)
Quand j’ai vu la difficulté à expliquer aux utilisateurs que pour accéder au ftp il fallait “simplement” changer le port dans Filezilla, j’ai laissé tomber…
A mon avis le seul intérêt est de limiter les attaques automatiques sur les services à accès restreint (SSH, mais pas HTTP). La plupart du temps ce sont des attaques par force brute ou au dictionnaire qui ne font que polluer les logs (si on évite d’utiliser des mots de passe faibles), beaucoup plus rarement une tentative d’exploitation d’une faille de sécurité de type “zero day” avant que la mise à jour de sécurité soit disponible.
A noter qu’on ne peut pas modifier le port de certains services comme DNS ou SMTP.
Ou bien de désactiver l’authentification par mot de passe pour root ou même pour tous les utilisateurs, et d’autoriser uniquement l’authentification par clé.
Non, cela ne suffit pas toujours. Il peut être nécessaire d’autoriser ce port dans le pare-feu/NAT, et même de lui indiquer qu’il sert à la connexion de commande FTP, sinon les connexions de données liées (transfert de fichier et listage de répertoire) risquent de ne pas être reconnues en tant que telles et traitées correctement.
Salut,
Tout avait été fait pour que ça fonctionne, et ça fonctionnait.
La seule difficulté était d’expliquer qu’il ne fallait pas se connecter sur le port 21, mais sur un port plus exotique. Comme en plus c’était du FTPS (et qu’il fallait déjà expliquer que l’option devait être activée et qu’il fallait accepter le certificat) j’ai laissé tomber…
La plupart des utilisateurs se connectent sans même comprendre se qui se passe derrière, leur demander de modifier des paramètres par défaut relève de la gageure… 
Pascal, tu parles de SMTP, et je le comprends mais qu’en est-il d’IMAP Il y a un intérêt à en modifier le port ?
AMAH l’intérêt de changer certains port de certains service est de perdre un peu plus l’attaquant.
Il y a plusieurs profils :
- script : le port n’est pas ouvert il passe son chemin. Toi tu es content car tes logs n’explosent pas.
- persévèrent : il va essayer d’autre ports, faire un scan de port, etc. Le but n’est pas de le bloquer éternellement mais de le pousser à la faute et/ou te permettre de le repérer et le contrer plus facilement.
Pour IMAP je recommanderais de ne pas le changer, c’est un service «ouvert» dans le sens ou des clients externe peuvent se connecter au service. Donc a moins que tu ne contrôle parfaitement tous les clients qui vont s’y connecter, changer son port ne fera que rendre inaccessible ton service.
IMAP n’est pas un service « ouvert » puisqu’il requiert une authentification. Un logiciel client IMAP peut être configuré pour utiliser un port non standard, et pour un serveur de mail familial n’ayant que quelques utilisateurs, ce n’est pas bien compliqué de modifier le port. On peut faire répondre le serveur sur les deux ports à la fois pendant une période de transition pour éviter une interruption brutale du service.
Quant à l’intérêt, il dépend de la nuisance subie avec le port standard. Si c’est du même niveau que sur SSH, ça vaut autant le coup.
Sur les pare-feu/NAT des clients aussi ?
Je vois ce que tu veux dire. Ils n’étaient pas derrière des pare-feu bloquants.
Si cela avait été le cas j’aurais probablement proposé du ftp passif.