Piratage de mon serveur ssh?

Support Debian
#1

Bonsoir!!

En lisant ce post http://forum.debian-fr.org/search.php?search_id=active_topics, je me suis dis qu’il était peut être temps d’aller jeter un oeil du côté de mes logs.

J’ai monté un serveur sftp mysecureshell basé sur ssh.
Actuellement, je n’ai créé qu’un compte.

En éditant le fichier auth.log, j’ai eu la surprise de voir des choses bizarres…
J’ai “greppé” la sortie du fichier sur le service sshd
http://pastie.org/550010

Je suis un novice sur Debian et encore plus en sécurité mais je crois voir là des tentatives d’intrusions

Peut on me le confirmer??
Certaines IP ont l’air d’être des sociétés, je ne comprends pas ces tentatives à moins que l’on est “spoofé” ces IP??

Si ce sont bien des tentatives de pirateries, je me demande comment “ils” savent que j’ai un serveur ssh… :unamused:

Comment peut on bloquer ces tentatives? Imaginons qu’ils arrivent à se logger :neutral_face:
Mais je me dis qu’ils leur faudra obligatoirement le user+password du compte que j’ai créé pour se connecter??
Ou alors existe t il une faille sur openssh-server??

De plus, existe t il un moyen de coder un petit prog’ qui m’avertit de ces tentatives sans avoir besoin de consulter moi même les logs??

Un très grand merci à ceux qui prendront la peine de lire ce post… :smt002

Ces questions m’inquiètent quelque peu…

#2

Salut,

Oui c’est une attaque de type bruteforce…

Déjà, le truc à faire c’est d’installer fail2ban. Ensuite utiliser un username/password complexe.

Donc déjà, penses à fail2ban :slightly_smiling:

Après, le simple fait d’avoir un username complètement loufoque, ça protège pas mal contre ce type d’attaque, car dis-toi qu’il utilise là une liste pour les noms d’utilisateur et une autre liste de password.

#3

Merci ymer, je fais ça ASAP!!

Bonne nuit :smt006

#4

Pas de soucis, tiens nous au courant :wink:

Bonne nuit :smt002

PS : Ma réponse se voulait rapide (mais pas très complète) pour que tu puisses réagir vite.

#5

un mots de passe a 90 caractère c’est assez radical :slightly_smiling: le top une ipfix dans iptables il peux plus ce connecter que via l’ip et du coup il est coincer :slightly_smiling:
il reste la faille dans iptables ensuite a mon avis possible mai nettement plus rare

#6

je ne suis pas expert non plus mais bon j’apporte une réponse de débutant qui parait évidente pour les experts qui permettra au “nul” (comme moi)de faire quelque chose en voyant ce post
SSH ne doit pas etre sur le port 22
liste des ports http://fr.wikipedia.org/wiki/Liste_des_ports_logiciels
interdire root de se loguer cela permet de ce connecter avec un user et accéder a root via la commande su (2 mot de passe a découvrir)
autoriser que 1 seul (ou quelques uns ) user avec login et MDP complexe

voici un petit site pour securiser un minimum SSH
http://virologie.free.fr/documents/openSSH/ssh_configurations.html

faire une regle iptable qui limite les tentative d’accès en temps(jamais testé)

[quote=“virologie.free.fr”]Ensuite, ajoutez les 4 règles suivantes qui limiterons les connexions entrantes sur le port 22 à un maximum 4 tentatives par minutes, les autres étant ensuite directement “jetées” (dropped) :

iptables -A INPUT -p tcp --dport 22 -m state --state NEW -m recent --set --name SSH
iptables -A INPUT -p tcp --dport 22 -m state --state NEW -j SSH_WHITELIST
iptables -A INPUT -p tcp --dport 22 -m state --state NEW -m recent --update --seconds 60 --hitcount 4 --rttl --name SSH -j ULOG --ulog-prefix SSH_brute_force
iptables -A INPUT -p tcp --dport 22 -m state --state NEW -m recent --update --seconds 60 --hitcount 4 --rttl --name SSH -j DROP
[/quote]

:smt006

PS: j’ai fait un edit parce que je me suis trompé de bouton “Envoyer” au lieu de “Aperçu” :blush:

#7

Il y a un souci à ne pas mettre ssh sur un port 22, c’est que le port choisi soit filtré. Une astuce consiste à le mettre sur le port 443 avec derrière sslh qui commute le traffic sur le bon démon.

#8

Et toi aussi tu es coincé le jour où tu dois te connecter depuis une autre adresse pour tout un tas de raisons valables.

@sinozis : l’utilisation de la correspondance ‘recent’ d’iptables a des inconvénients :

  • elle est contournable par qui sait faire (profondeur mémoire finie),
  • elle peut être exploitée pour provoquer un déni de service par usurpation de l’adresse IP d’un utilisateur légitime (peut être atténué par l’utilisation d’une liste blanche),
  • elle peut être inadaptée dans certains cas où un client est susceptible d’ouvrir rapidement plusieurs connexions, par exemple avec scp ou sftp.

AMA, les méthodes de type fail2ban basées sur l’exploitation des logs d’échec sont plus fiables et efficaces. Le changement de port est efficace contre les attaques automatiques des robots qui ne visent que le port 22 mais se heurte au risque de blocage par certains pare-feux.

Mais la première mesure, c’est une authentification solide. Des attaques comme celle-ci, j’en reçois des tas chaque jour, comme tout le monde je suppose. Si je devais paniquer à chaque fois…

#9

il y a aussi la possibilité d’utiliser du portKnocking pour cacher sa connexion ssh (en plusde fail2ban).

Pour t’afficher les tentatives de connexion mais aussi tout soucis de log il y a logCheck qui est vraiment pas mal.

#10

Et toi aussi tu es coincé le jour où tu dois te connecter depuis une autre adresse pour tout un tas de raisons valables.

@sinozis : l’utilisation de la correspondance ‘recent’ d’iptables a des inconvénients :

  • elle est contournable par qui sait faire (profondeur mémoire finie),
  • elle peut être exploitée pour provoquer un déni de service par usurpation de l’adresse IP d’un utilisateur légitime (peut être atténué par l’utilisation d’une liste blanche),
  • elle peut être inadaptée dans certains cas où un client est susceptible d’ouvrir rapidement plusieurs connexions, par exemple avec scp ou sftp.
    [/quote]
    Si tu sa pas si ton ip va changer il est claire qu’on ne peux pas le faire sinon sa reste solide.

Petite question que veux tu dire par (profondeur mémoire finie) il y a un terme en anglais ??
On peux limiter le nombre de connections sur un serveur par ip , en principe pas plus de 5 par ip. après c est claire que si le mec a un reseaux important il faudra baisser la valeur, mai sa reste efficace surtout si la valeur est 1 par ip.

#11

Je pensais à l’éventualité de devoir se connecter de façon imprévue depuis un autre accès internet, une autre machine, avec une adresse différente, parce que la machine ou l’accès habituel est HS, qu’on n’est pas à son poste de travail habituel…

La correspondance ‘recent’ utilise une liste pour mémoriser les adresses des paquets. Cette liste a un profondeur finie N, c’est-à-dire qu’elle ne peut mémoriser que les N adresses les plus récentes. Par défaut N=100, mais on peut modifier sa valeur au chargement du module ipt_recent avec le paramètre ‘ip_list_tot’ (modinfo ipt_recent pour la liste des paramètres). Par conséquent un attaquant avisé peut déterminer cette limite avec quelques essais puis envoyer N paquets avec des adresses sources bidon pour se faire oublier entre chaque connexion.

#12

[quote=“PascalHambourg”]
La correspondance ‘recent’ utilise une liste pour mémoriser les adresses des paquets. Cette liste a un profondeur finie N, c’est-à-dire qu’elle ne peut mémoriser que les N adresses les plus récentes. Par défaut N=100, mais on peut modifier sa valeur au chargement du module ipt_recent avec le paramètre ‘ip_list_tot’ (modinfo ipt_recent pour la liste des paramètres). Par conséquent un attaquant avisé peut déterminer cette limite avec quelques essais puis envoyer N paquets avec des adresses sources bidon pour se faire oublier entre chaque connexion.[/quote]

sa serai valable si il n’y pas le suivis de connections, mai si tu join le suivis de connections + le module rescent sa reste a mon avis difficile a faire ?
mai seulement 100 entrée ? j’ai pas tester jusque la m’enfin sa me parait peux

#13

Dans les règles que tu as citées, le suivi de connexion ne sert qu’à limiter la correspondance aux paquets qui créent une nouvelle connexion, sinon une connexion établie serait bloquée après 4 paquets. Il n’atténue en rien la faiblesse intrinsèque de ‘recent’. Si tu trouves que la taille par défaut de la liste est trop petite, libre à toi de l’augmenter avec le paramètre que j’ai indiqué.

Un autre paramètre, ‘ip_pkt_list_tot’, règle le nombre de paquets mémorisés par adresse IP. Avec la valeur par défaut de 20, il est impossible de déclencher sur une valeur de --hitcount supérieure.

#14

effectivement rescent est pas très bon, dommage car je le trouvai pratique :unamused:

sinon une petite question me chatouille depuis un bon moment.

on ce contente de lire les log puis d’effectuer la tache ensuite ce qui veux dire que le paquet est entrer et est soit droper, soit rejeter ,soit acespter, sic est droper et qu’on doit ajouter une regle pour acepter la connection = perte de bande passante si c est rejeter idem
si c est accepter alors on fait rien…

Donc pourquoi plutôt que d’écrire un log on aurai pas une possibilité d’exécuter une commande genre -j ma_commande ?
évidement sa représente un risque mai utiliser a bon éssien sa permettrai de faciliter la tache. (m’est avis que c’est pour cette raison mai bon …)

#15

Ce n’est pas que la correspondance ‘recent’ ne soit pas bonne, en fait je trouve qu’elle n’est pas adaptée à la problématique de SSH. Le but est moins de limiter le nombre de connexions que de limiter le nombre d’authentifications ratées, ce qu’un filtre de paquets ne peut détecter. Les approches basées sur le résultat des tentatives d’authentification me semblent plus pertinentes.

Je n’ai pas compris ta question au sujet des paquets droppés ou acceptés, et de la perte de bande passante. Un paquet reçu occupe de la bande passante de toute façon, qu’il soit accepté ou bloqué.

Les règles iptables sont exécutées dans l’espace noyau, j’imagine qu’il pourrait être délicat de lancer une tâche utilisateur à partir d’elles. Il reste possible d’utiliser netlink, avec la cible QUEUE, NFQUEUE, NFLOG ou ULOG avec un plugin approprié pour transmettre des informations sur un paquet à l’espace utilisateur. Mais dans le cas de SSH, ce serait plutôt au démon sshd d’exécuter une commande en cas d’échec d’authentification.

#16

[quote=“PascalHambourg”]Ce n’est pas que la correspondance ‘recent’ ne soit pas bonne, en fait je trouve qu’elle n’est pas adaptée à la problématique de SSH. Le but est moins de limiter le nombre de connexions que de limiter le nombre d’authentifications ratées, ce qu’un filtre de paquets ne peut détecter. Les approches basées sur le résultat des tentatives d’authentification me semblent plus pertinentes.
[/quote]
hmm l’inconvénient c’est que sa va lui permettre de faire des essais. la question est aux nombre de combien a t-il droit ?
le gag du j’ai oublier le mots de passe et j’en essaye 200 avant de le retrouver…avidement on est pas supposer oublier. sauf pour l’être humain :laughing:

laisse tomber il y a fautes d’erreur :confused:

je pense que le risque est la c’est que exécuter quelque chose dans l’espace utilisateur serai un risque. c’est un peux domage car cela pourrai être pratique.
.

#17

C’est comme partout, tout est affaire de compromis entre la sécurité et l’utilisabilité. Par exemple avec une carte bancaire on a droit à trois essais (mais il n’y a que 10000 codes possibles). A chacun de définir le taux d’échec jugé acceptable.

#18

Une solution qui me parait pas mal pour me connecter sur mon serveur chez moi, c’est d’utiliser openvpn par défaut. La seule addresse IP qui à le droit de de se connecter en ssh directement, c’est celle de mon travail à cause du proxy.

#19

Merci à tous pour vos conseils, retours d’expériences, avis

Tous sont très précieux.

Je suis également les précautions prodiguées ICI

Peut être utile si d’autres personnes utilisent comme moi mysecureshell

Je viens de regarder un oeil sur le log auth.log, encore de nouvelles attaques avec un ip localisée au Japon, voici le site http://vps-115-146-18-31.secure.ne.jp/

Les pirates utilisent les ip de sites quelconques??
S’agit il d’ip spoofing ou autres??

De plus, comment font ils pour détecter l’utilisation de serveurs ssh sur le réseau??

Ont ils une armée de bot qui sniffent le réseau??

Merci de m’éclairer, je ne panique pas mais j’aimerais comprendre, suis très curieux moi :unamused:

#20

Pour revenir sur l’ip 115.146.18.31, le nom de domaine est celui-ci “sansei-cha.com”

Il s’agit donc bien de l’ip du site web :smiling_imp: