Salut,
J'ai remarqué que je ne pouvais pas me connecter en ssh sur mon PC à part en réseau local et que ça me fait un timeout systèmatique.
Apparement, ça serait du au fait que ma box n'est pas configuré pour autoriser le port 22, du coup je me demandais si l'autoriser présentait des risques importants pour tous les périphériques connectés au réseau wi-fi de la box ?

Sur une box à la maison, on n'"ouvre" pas un port, on le redirige vers une adresse IP locale. Je ne suis pas expert en réseau mais rediriger un port c'est ouvrir une liaison possible de l'exterieur vers un ordinateur spécifique de ton réseau LAN. Le risque d'ouvrir un accès sur le port 22 vers ton PC fera que n'importe qui testant ton adresse IP WAN sur le port 22 tombera sur ton ordinateur, où qu'il soit dans le monde donc tu vas avoir pas mal de bots qui vont tenter des connexions chez toi avec des mots de passe classique

Tu peux toujours tromper ces bots en ouvrant un autre port et en changeant, dans les paramètres d'OpenSSH, le port utilisé. Au moins tu seras plus tranquille.

Ce que je fais, chez moi, c'est de désactiver la connexion par mot de passe et d'utiliser les clés privé/publique pour permettre à tes périphériques reconnus de se connecter sans mot de passe où qu'ils se trouvent (à l'extérieur y compris) tout en empêchant quiconque de tenter de se connecter chez toi mais là, c'est toi qui voit (je ne sais pas ce que font les autres avec SSH, je n'en ai jamais parlé avec personne).

je redirige mon port exterieur ssh vers une machine interne. personnellement mon ssh est configure pour rejetter les connexions pour tous les utilisateur sauf ceux qui sont whitelistes.

rejetter les connexions pour tous les utilisateur sauf ceux qui sont whitelistes.

Quelle est l'idée derrière ta façon de faire, Godrik ? Ça m'intéresse de savoir

Il existe un fichier whitelist pour SSH ? (question bête mais j'ai jamais regardé).

C'est utile pour les machines sensibles multi utilisateurs, non ? Pour une machine simple utilisateur, ça sert à quelque chose ?

C'est pas (trop) risqué si tu suis un minimum de règles :

-Changer le port par défaut
-Ne pas autoriser root à se connecter en ssh
-Utiliser des clés pour se connecter
-Utiliser un fail2ban qui va bloquer les adresses ip au bout de x tentatives ratées
-Mettre en place du port knocking
-Mettre à jour l'OS/tes programmes régulièrement

Avec ça tu seras pas mal blindé

Le 29 janvier 2019 à 13:10:29 [deban]_Dakien a écrit :

rejetter les connexions pour tous les utilisateur sauf ceux qui sont whitelistes.

Quelle est l'idée derrière ta façon de faire, Godrik ? Ça m'intéresse de savoir

Il existe un fichier whitelist pour SSH ? (question bête mais j'ai jamais regardé).

le man de sshd_config dit:

AllowGroups
This keyword can be followed by a list of group name patterns, separated by spaces. If
specified, login is allowed only for users whose primary group or supplementary group
list matches one of the patterns. Only group names are valid; a numerical group ID is
not recognized. By default, login is allowed for all groups. The allow/deny directives
are processed in the following order: DenyUsers, AllowUsers, DenyGroups, and finally
AllowGroups.

See PATTERNS in ssh_config(5) for more information on patterns.

AllowUsers
This keyword can be followed by a list of user name patterns, separated by spaces. If
specified, login is allowed only for user names that match one of the patterns. Only
user names are valid; a numerical user ID is not recognized. By default, login is
allowed for all users. If the pattern takes the form USER@HOST then USER and HOST are
separately checked, restricting logins to particular users from particular hosts. HOST
criteria may additionally contain addresses to match in CIDR address/masklen format. The
allow/deny directives are processed in the following order: DenyUsers, AllowUsers,
DenyGroups, and finally AllowGroups.

See PATTERNS in ssh_config(5) for more information on patterns.

Donc:

AllowUsers erik #authorise seulement l'utilisateur erik a se logguer.

Ou plus precisement je fais:

AllowGroups ssh_user #seul les membres du groupe ssh_user peuvent se logguer par ssh

C'est utile pour les machines sensibles multi utilisateurs, non ? Pour une machine simple utilisateur, ça sert à quelque chose ?

Bah ca c'est toi qui voit. Mais il y a plein de compte creer automatiquement par different logiciel. J'ai pas l'impression fondamental qu'authoriser le login ssh dessus est utile. Mais par exemple, J'ai une machine qui est connecte au web et qui: sert des pages webs, sert de repository git a travers ssh, sert de serveur pour telecharger ... des iso debian, sert a jouer de la musique, et sert de smart tv. Ca veut dire qu'il y a quelques comptes sur la machine, mais fondamentalement, ils ont pas tous besoin d'access ssh.

sert de serveur pour telecharger ... des iso debian

Fais tourner

les kheys j'ai réussi à faire fonctionner tout ça.

Le 29 janvier 2019 à 12:18:43 Ezionolife1 a écrit :
Le mieux à faire c'est de rediriger un port autre que 22 sur ta box, par exemple tu rediriges le port 2200 de ta box vers le port 22 de ton PC.

Ouais alors utiliser un port autre que le 22 ça devrait être le conseil numéro #782 dans la liste, je sais pas pourquoi c'est systématiquement le premier qui est donné (pire, le seul la plupart du temps) mais seul, ce conseil vaut peanuts
Une vraie sécurisation en aval, c'est mieux. Avec comme dit plus haut un fail2ban ou toute autre solution de mitigation de bruteforce, root pas autorisé à se logger directement en SSH (et si possible, pas de sudo, tant qu'on y est), des clefs RSA solides, bref un truc propre.
Le coup du port tcp/9999 c'est l'équivalent de la clef cachée sous le pot de fleurs s'il n'y a rien d'autre pour protéger

Le 29 janvier 2019 à 19:11:17 Angulard a écrit :

sert de serveur pour telecharger ... des iso debian

Fais tourner

Oui enfin sinon il y a le BitTorrent pour ces choses-là

GoogleBot, personnellement le port knocking et changer le numero du port ssh, j'ai beaucoup de mal a croire que ca marche en pratique.
Changer le port ssh, ca ne resiste pas a nmap ce qui est quand meme l'outil 0 en securite.
Et le port knocking ca te force a te rappeller d'une sequence de plus; j'ai deja assez de motdepasse a me rappeller.

Je ne change jamais le port chez moi, même si je me tape des tentatives de connexion entrante, l'accès root est désactivé, l'accès par mot de passe aussi. Je n'utilise que le triplé id_rsa/id_rsa.pub/authorized_keys

Je sais pas trop si c'est suffisant ou pas...
Ah et pas de sudo, compte root et compte régulier séparé, c'est toujours un plus.

Idem, j'ai 18 serveurs sur le réseau public et je ne change pas de port.
Comme ça a été dit, n'importe quel utilitaire détecte en quelques secondes les ports qui répondent, accompagnés le plus souvent du protocole.

Après c'est clair il y aura des tentatives de connexion, mais 99.9999 pourcents du temps ce sont des bots qui testent "root" / password", "admin" / "12345" etc... et des choses comme ça. Un fail2ban et ils renoncent très vite.

note que depuis 10 ans, on voit une recrudessence de bot net qui font ce genre d'attaque. et du coup fail2ban n'est plus une protection si efficace que ca. en pratique les botnet attaquent un ensemble de serveur en envoyant qu'une ou deux tentatives de connexion par jour a une meme machine. mais ils attaquent 10 millions de machine a la fois.

bon ca les force a obtenir de plus gros botnet et cie. donc c'est important de les deployer. mais fondamentalement fail2ban est voue a l'echec contre des attaques modernes.
Vraiment un mot de passe unique et complexe (ou une cle ssh ce qui est fondamentalement la meme chose) est la seule solution convenable pour proteger l'access a une machine.

Alors puisqu'on entre dans les détails je vais décrire mon setup préféré:

• Port d'écoute tcp/22, classique
• Connexion par clef uniquement
• Pas de connexion directe sur root (j'utilise su, les vrais savent)
• Un petit montage à base d'iptables, hashlimit et ipset permettant à la fois de détecter les TCP SYN trop rapprochés dans le temps, d'enregistrer les IPs ayant émis ces SYN, et de les mettre au blackhole
• Le blackhole, le fameux, c'est une target spéciale qui drop en UDP (j'ai pas mieux à faire), qui crie "ach verboten" en ICMP, et last but not least, fait du TARPIT en TCP. Le TARPIT, pour ceux qui ne connaissent pas, c'est une ruse qui place la connexion en mode persistant avec une fenêtre TCP de 0, ce qui équivaut à dire à l'attaquant de fermer sa bouche quelques minutes, mais de maintenir la connexion ouverte malgré tout. Donc pour un bête script de bruteforce SSH non-customisé, le TARPIT va occuper un slot client (pire, pour un script mono-socket... le script sera juste bloqué) jusqu'à nouvel ordre.

J'avais gardé dans un coin la liste d'adresses IP "à problèmes" (car elle était sauvegardée et restaurée au reboot), il faudrait que je fasse quelques statistiques dessus un de ces quatre à titre informatif.

comment on fait pour voir si il y a eu des tentatives de connexion sur une machine accessible depuis l'exterieur? j'ai un rpi accessible uniquement en ssh via la NAT que j'utilise depuis l'exterieur pour acceder a des données et j'aimerais bien savoir si des gens on tenté de s'y connecter