Vidéo de BIBI - sécuriser une connexion SSH iptable

ce petit scripte , sécurise le nombre de tentative de connexion sur le port SSH .

Admettons ; une personne ce connecte sur votre SSH pour vous hacker.
Ce scripte autorise 3 connexions SSH et les bloque sur une période de 60 secondes

Voici la vidéo
youtube.com/watch?v=xe_myiRCffg

Voici le scripte

[quote][b]#!/bin/bash -x
PSSH="22"
NTEN="03"
DTEN=“60”

iptables -F SSH_Except
iptables -X SSH_Except
iptables -N SSH_Except
iptables -A INPUT -p tcp --dport $PSSH -m state --state NEW -m recent --set --name SSH_limit
iptables -A INPUT -p tcp --dport $PSSH -m state --state NEW -j SSH_Except

Journalisation des attaques.

iptables -A INPUT -p tcp --dport $PSSH -m state --state NEW -m recent --update --seconds $DTEN --hitcount $NTEN --rttl --name SSH_limit -j LOG --log-prefix 'Attaque possible à SSH : ’

Blocage des attaques.

iptables -A INPUT -p tcp --dport $PSSH -m state --state NEW -m recent --update --seconds $DTEN --hitcount $NTEN --rttl --name SSH_limit -j DROP[/b][/quote]

ta video ne me fait pas confiance, tu as vu le nombre de lien qui sont bloqués par adblock, alors avec un sujet aussi sensible, je me méfie ???

En quoi c’est sécurisé :033

Et c’est SSH pas SSSH, et pour finir juste comme ça pourquoi la vidéo est faite depuis un cro$oft :116

tu limite le nombre de connexion sur perriode de X temps

Ca permet surement d’éviter le flood de connexion, et/ou une attaque par denie de service. Ca peut être intéressant.
Mais xinetd fait ca aussi, et plus simplement : tu choisis le nombre d’instances simultanées maximum que tu souhaites pour un service donné, et hop :mrgreen:

Donc en aucun cas tu empêche un vol de clé ou de password et en aucun cas tu empêche des gens de saturé ton SSH efficacement.

Il faut systématiquement blacklister toute personne qui cherche à abuser de ton ssh ( éviter de le laisser ouvert et pourquoi pas le déplacer sur un autre port ).
Bref ton tuto n’a pas le bon titre car en aucun cas il sécurise ton SSH :083

[quote=“dric64”]
Ca permet surement d’éviter le flood de connexion, et/ou une attaque par denie de service. Ca peut être intéressant.
Mais xinetd fait ca aussi, et plus simplement : tu choisis le nombre d’instances simultanées maximum que tu souhaites pour un service donné, et hop [/quote]

Exact :023

Wai, on va dire, ca retarde en fait.
Suis d’accord avec toi.

Mais ca dissuade aussi.

Tu limite l’axée de 5 mn sur 3 tentative de connexion ou 60 mn ou 24 H ou 48H ou illimité.

1 tentative, et BASTA ; la personne ne peut plus ce connecter sur une période de X temps

Je ne suis pas très calé en matière de ssh, je ne m’en sers qu’en interne, entre mes 3 machines.
J’aimerais bien que tu développes le côté “éviter de le laisser ouvert”.
Comment faire ?
question 2 : comment savoir si on essaie d’entrer sur ma machine, qui et où blacklister ?
merci.

Pour sécurisé ton SSH, tu as la possibilité de mettre un password différant de celui de l’utilisateur linux.

ca s’appelle des passes phrase.

j’ais trouver une video qui explique tres tres bien SSH
authsecu.com/cours-formation … en-ssh.php

[quote=“ricardo”][quote=“barbbabull”]

Donc en aucun cas tu empêche un vol de clé ou de password et en aucun cas tu empêche des gens de saturé ton SSH efficacement.

Il faut systématiquement blacklister toute personne qui cherche à abuser de ton ssh ( éviter de le laisser ouvert et pourquoi pas le déplacer sur un autre port ).

[/quote]

Je ne suis pas très calé en matière de ssh, je ne m’en sers qu’en interne, entre mes 3 machines.
J’aimerais bien que tu développes le côté “éviter de le laisser ouvert”.
Comment faire ?
question 2 : comment savoir si on essaie d’entrer sur ma machine, qui et où blacklister ?
merci.[/quote]

Pour la sécurité on peut commencer par créer une clé crypter ensuite on peut déplacer le port ssh vers un autre ie : 666 :077 et pour finir on gère les accès à ces machines avec des annuaire ldap ( ça par contre c’est un peut l’usine à gaz on peut faire aussi bien avec PAM tout simplement ) et pour finir fermer le port ssh implique pour la gestion d’une machine distante d’avoir un moyen de le rouvrir ( je fais ça sur une machine loué chez OVH ).

Pour résumé je commence par faire en sorte que mon SSH sur le port 22 n’accepte que les clé de OVH tout le restant est direct jeté, ensuite j’ai un panel depuis lequel je peut ouvrir ou fermé un port ssh différents sur lequel j’interdit root et avec lequel il faut une clé + un password ( trente deux caratères, :stuck_out_tongue: ) qui permet un à un compte crée pour la maintenance de la machine.
Pour ce qui est de l’accès au services de partage ftp, nfs, samba je passe par les modules adéquat de PAM et LDAP afin d’autoriser oui ou non l’accès à la machine.
Le fait d’avoir plus d’une machine interconnecter il suffirait d’avoir une synchronisation des annuaires d’authentification OpenLDAP le fait très bien.

Après pour expliquer tous ça plus en détail je verrai car je suis sur un projet qui me prends pas mal la tête et monopolise pas mal mon temps libre ( entre deux compilation ou séance de configuration, voir entre deux cloppes fumer sur le balcon … bébé oblige :083 ).

chapeau :038
De la bombe.

Donc moi j’ais interdit aussi au ROOT de sy connecter en SSH, et uniquement un utilisateur que j’ais désigner en particulier.

mais j’ais pas pencer a y changer le port

[quote=“fabdunet1313”]chapeau :038
De la bombe.

Donc moi j’ais interdit aussi au ROOT de sy connecter en SSH, et uniquement un utilisateur que j’ais désigner en particulier.

mais j’ais pas pencer a y changer le port[/quote]

Disons que ça évite les “kevin” mais si la personne à décidé de te foutre la mer… il fera un scan de l’ensemble des ports à la recherche de la faille à exploiter.
Après je doit avouer que c’est fastidieux mais indispensable pour sécuriser toute plateforme en ligne, après tous ce qui hors ligne libre à vous :wink:

Il y a encore des gens qui utilise “telnet” parmi nous ?

EDIT :

J’ai zappé aussi le blacklistage se fait par fail2ban comme ça si un gars veut s’amuser il a tout intérêt à savoir comment faire, et c’est aussi pour ça qu’avant de mettre en place une tel solution il vous faut une porte de sortie ( éh éh y a personne qui s’est déjà retrouvé blacklisté de sa propre machine distante, éh benh c’est vraiment pas marrant :033 ).

Et pour conclure si le port ssh est fermé bah il est sécurisé au maximum :005 c’est aussi simple.

Merci de toutes ces précisions.
Comment voir si on est “écouté” ou si on a tenté de l’être ?

Je pense que le portknocking est ce qu’il te faut ricardo

fr.wikipedia.org/wiki/Port_knocking

Il y a pas mieux

[quote=“artex”]Je pense que le portknocking est ce qu’il te faut ricardo

fr.wikipedia.org/wiki/Port_knocking

Il y a pas mieux[/quote]

Effectivement c’est une possibilité mais quelque peut complexe à mettre en place mais ça marche :023

[quote=“artex”]Je pense que le portknocking est ce qu’il te faut ricardo

fr.wikipedia.org/wiki/Port_knocking

Il y a pas mieux[/quote]

je plusplussois et je plussois encore

Le portknocking est méconnu de beaucoup d’admin et pourtant son concept est redoutablement efficace, mais c’est vrai un peu casse c… vu qu’il faut toujours se trimbaler avec son client pour la combinaison de port… En tout cas si la parano est ta meilleure amie alors met le en place…
Après il y a sshguard pour bloquer le bruteforcing et bannir des IP, c’est encore plus simple que trifouiller son iptables

Comme il a été indiqué plus haut par barbbabull, fail2ban le fait très bien aussi (et pas que sur le ssh… :wink: )… après, c’est vrai que la vidéo serait un peu courte… :laughing:

# apt-get install fail2banJe vous mets ça en vidéo ou ça ira?.. :005 :005 :005

:006

[quote=“Num’s”]Comme il a été indiqué plus haut par barbbabull, fail2ban le fait très bien aussi (et pas que sur le ssh… :wink: )… après, c’est vrai que la vidéo serait un peu courte… :laughing:

# apt-get install fail2banJe vous mets ça en vidéo ou ça ira?.. :005 :005 :005

:006[/quote]

:114 Si c’est une vidéo à la NixiePixel, OUI ! :118 :laughing:

:005 je connaissais pas cette petite… Sur certaines vidéos on la croirait tout droit sortie d’un package gtk2-engines-xxxxx de chez ubuntu… :open_mouth:

Le changement de port, c’est sûr que ça retiendra pas beaucoup plus longtemps quelqu’un d’un peu motivé pour attaquer ton serveur. Mais ça élimine un bon nombre de robots qui passent leur temps à essayer différentes combinaisons sur les serveurs qu’ils trouvent. Chez moi, en regardant mes logs, c’est vraiment le jour et la nuit…

fail2ban et autres, c’est mieux, mais l’un n’empêche pas l’autre…

Seul inconvénient, entre ssh, scp et sftp, ils n’ont pas pu se mettre d’accord pour utiliser le même paramètre pour indiquer le port (-p, -P, et -oPort). :unamused: M’enfin on s’y fait…