Journal Tentative de hack ?

Posté par  .
Étiquettes : aucune
0
1
avr.
2006
Salut mon journal,

J'ai pas l'habitude de poster ce genre d'histoire, mais c'est la première fois et j'ai eu un coup de flip, je voudrais donc des avis ...

Aujourd'hui (01/04/2006) je remarque grace à mes monitors (gkrellm), que j'ai du traffic réseau non identifié (900Ko /s en recv) alors je jete un coup d'oeil sur mon firewall (firestarter) et je découvre une connection ssh ouverte sur : 81.199.153.29:22

Question, je ne connais ni d'eve ni d'adam cette ip, qu'est ce que c'est !!! ou qu'est ce que ca peut etre ... certain d'entre vous on déjà eu a faire avec ce genre de connections parasites ? (pirates ?)
Je ne sais que penser (a part blinder mon firewall) et je sais pas du tout ce que c'était ...si certains ont des avis/infos, je suis preneur !

Merci journal
(au fait, cela n'a rien d'un poisson d'avril, malheureusement)
  • # Penses au routage

    Posté par  . Évalué à 2.

    Moi, j'ai mis le port XYZT comme port d'accès au routeur qui le redirige vers le port 22 sur ma machine dans le LAN.
    Je sais que c'est pas le top mais ça fait un peu plus de sécurité
  • # whois

    Posté par  (site Web personnel) . Évalué à 4.

    $ whois 81.199.153.29
    ...
    descr: Arobase Telecom, Ivory Coast
    ...

    A priori, c'est quelqu'un qui est en Côte d'Ivoire.
  • # C'est un monsieur de cote d'ivoire ...

    Posté par  (site Web personnel) . Évalué à 2.

    -> http://www.dnsstuff.com/tools/whois.ch?ip=81.199.153.29

    Ca doit etre un utilisateur avec un mot de passe faible. Pour savoir quel est l'utilisateur :

    w

    (enfin chez moi c'est pts/0 c'est les gens connectés en ssh)
  • # Et le forum c'est pour les chiens ?

    Posté par  (site Web personnel) . Évalué à 3.

    Bon pour ton problème plusieurs solutions sont a envisager :

    - Change ton mot de passe sur le compte qui a été ouvert (met un truc plus sécurisé la prochaine fois)
    - Passe ton serveur SSH en écoute sur le port 23 (ça évite les robot qui scan internet pour tenter de recto-perforer des serveurs SSH en se servant des mots de passe trop simple)
    - Vérifi si le porate ne t'as pas installé de Rootkit
    - Met à jour ton OpenSSH pour comblet les éventuels faille de sécurité si ce n'est pas déjà fait
    - Si tu peux filtre les adresses IP pouvant se connecter à ton serveur

    Je pense que déjà avec ça tu devrai être mieux protégé
  • # Il m'est arrivé un truc similaire

    Posté par  . Évalué à 7.

    Il y a quelques mois, en me connectant comme d'habitude je vois : last login from truc.ucalgary.ca. Comme je n'ai jamais été de ma vie dans ce patelin, je me suis dit que quelque chose n'allait pas. J'ai donc fouillé les logs. J'ai vu des connexions depuis deux ip totalement étrangères et le pire étant qu'ils se sont apparemment connecté directement mais mon bon login et mon bon mot de passe (qui est toujours du style random()). D'habitude je mets toujours un pare-feu pour limiter les connexions aux quelques adresses depuis lesquelles je suis susceptible de me connecter, mais là coup de paresse après une installation toute fraîche, je n'avais pas encore remis les bonnes règles. Ce qui m'étonne le plus dans l'affaire est que je n'ai strictement aucune idée comment ils ont obtenu la triplette IP/login/mot de passe. Soit un jour je me suis connecté sur une machine qui avait un key logger, soit une institution où j'ai un compte s'est fait pirater. J'aimerais beaucoup connaître l'explication exacte. Pour la petite histoire, j'ai vu dans mon history ce qu'à tenté de faire un petit malin. Il a visiblement tenté de passer root sans succès, et s'est rabattu dans ~/.ssh/known_hosts et il a tenté d'aller voir les autres machines (sans succès). Pas de dégât visible, ni de compromission au-delà de ça, mais par sécurité j'ai tout de même tout reformaté et changé tous mes mots de passe.
    Ce genre de mésaventure donne une bonne leçon. Je suis encore plus attentif maintenant qu'auparavant.
    • [^] # Re: Il m'est arrivé un truc similaire

      Posté par  (site Web personnel) . Évalué à 3.

      Tu oublies un parametre : la faille. Il se peut que cette/ces personne(s) se soi(en)t connectee(s) par le biais d'une faille documentee ou non et sans doute non corrigee.

      J'ai eu cette desagreable experience ou un mechant pirate a reussi a exploiter une faille logicielle pour obtenir le fichier /etc/shadow puis le cracker en environ une semaine.

      Il s'est ensuite tranquillement reconnecte sous le nom d'un utilisateur qui avait un mot de passe pas si protege que cela apparemment.

      Steph
    • [^] # Re: Il m'est arrivé un truc similaire

      Posté par  (site Web personnel) . Évalué à 4.

      Soit un jour je me suis connecté sur une machine qui avait un key logger, soit une institution où j'ai un compte s'est fait pirater.

      Pour éviter ce genre de mésaventure j'utilise libpam-opie pour me connecter chez moi en SSH.

      Pour ceux qui ne connaissent pas, c'est de l'authentification à base de mots de passe à usage unique (one time password dans la littérature) : à chaque connexion on utilise un mot de passe dynamique calculé à partir d'un secret partagé entre le client et le serveur et un challenge envoyé par le serveur ; comme le challenge change à chaque connexion, le mot de passe également.

      Et pour le côté client, j'ai écrit un petit soft en java pour mon téléphone portable qui me calcule le mot de passe dynamique à partir du challenge du serveur.
  • # Heu

    Posté par  . Évalué à 4.

    Commence à vérifier si il a effectivement réussi à se logger (auth.log)
    Si ca se trouve, ce que tu as vu sur ton firewall, c'est uniquement des "tentatives" de connexions. Une connexion établie uniquement pour s'identifier.
    • [^] # Re: Heu

      Posté par  . Évalué à 1.

      yep, merci pour le auth.log ....

      - POSSIBLE BREAK-IN ATTEMPT!
      Apr 1 18:37:02 ***my-IP*** sshd[8894]: error: Could not get shadow information for NOUSER
      Apr 1 18:37:02 ***my-IP*** sshd[8894]: Failed password for invalid user duke from 81.199.153.29 port 38557 ssh2
      Apr 1 18:37:04 ***my-IP*** sshd[8896]: Invalid user dennis from 81.199.153.29
      Apr 1 18:37:04 ***my-IP*** sshd[8896]: reverse mapping checking getaddrinfo for 81.199.153.29.ipplanet.net failed

      whaou ... ya plein de lignes comme ca ... il était en train de se taper le dico des noms .... flippant !

      bon donc apriori il est pas rentré, j'ai du couper ssh a temps, et le traffic réseau venait de sa Brute-Force.
      Bwallé, il me reste plus qu'a bien vérifier mes regles Firewall !

      Et comme les messages indiques "Possible break in attempt" (et en l'occurance ils ont raison) ya pas moyen de se bloquer completement l'acces internet si on recoit disont plus de 'n' messages de ce type ? (genre un firewall adaptatif selon l'attaque... je sais que ca existe mail il me semble pas que firestarter le fasse)
      • [^] # Re: Heu

        Posté par  . Évalué à 3.

        Ho oui il y en a beaucoup des comme ca ... vendredi de 3h50 a 6h30 y'a un mec qui a fait tourner tout un dictionnaire. Avec une tentative toutes les trois secondes ca en fait des logs.
      • [^] # Re: Heu

        Posté par  . Évalué à 3.

        Tu devrais essayer DenyHost, je ne l'ai jamais utilisé mais à priori c'est fait pour ce genre de situation.
        A voir sur http://denyhosts.sourceforge.net
      • [^] # Re: Heu

        Posté par  (site Web personnel) . Évalué à 10.

        Tu peux le faire directement avec iptables :
        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


        Si on a plus de 4 tentatives de connexions en moins d'une minute, l'ip est bloquée pendant une minute.
  • # ...

    Posté par  (site Web personnel) . Évalué à 2.

    maintenant qu'on parle de routeur/firewall/hacks, etc... j'en profite... petite question :
    est-ce que j'ai besoin d'un pare feu logiciel si j'utilise le modem de mon FAI, freebox, configuré en mode routeur, sans ordi avec IP DMZ et avec que le port 80 et 22 redirigé vers ma linux box (et avec apache et ssh a jour) ?

    merci.
    • [^] # Re: ...

      Posté par  . Évalué à 1.

      Je dirais non, s'il y a un routeur en facade et que tu es sur de la sécurité de la machine qui recoit les redirections de port.
      • [^] # Re: ...

        Posté par  (site Web personnel) . Évalué à 4.

        Eh bien moi je dirait que oui, je n'ai jamais ete fan des pare-feu integres sur les modems ADSL et autre black boxes du genre routeur ADSL/Wireless.

        Rien ne vaut un niveau de controle clair sous Linux ou tu controles tout le filtrage et tu comprends comment ca se passe et ce que tu peux consulter les logs pour voir si tu rencontres un probleme.

        Steph
        • [^] # Re: ...

          Posté par  (site Web personnel) . Évalué à 2.

          en meme temps l'avantage d'un routeur qui fait redirection de ports et controlable sur le site du fai (exemple freebox), c'est qu'un pirate/script kiddie qui meme arrive a avoir le mot de passe root de la machine ne pourra pas utiliser de trojan/serveur IRC/FTP sur la machine.

          me trompe-je ?
          • [^] # Re: ...

            Posté par  (site Web personnel) . Évalué à 2.

            Euh, je suis pas sur d'avoir bien saisi mais s'il fait redirection, il connecte alors un service sur ton ordinateur, donc techniquement, s'il est vulnerable, c'est de toute facon ta machine qui se fait violenter, donc je vois pas bien la difference.

            Steph
    • [^] # Re: ...

      Posté par  . Évalué à 3.

      Sur la freebox, IP DMZ = la machine qui détient cette adresse IP se voit forwarder tout le trafic qui arrive sur la freebox sauf exceptions listées dans les redirections de ports.

      Il est donc impératif de filtrer tout ce qui vient du réseau local, et qui n'aurait pas comme origine le réseau local.

      Avec Shorewall par exemple :

      Policy
      net all DROP info
      all all REJECT info


      Rules
      ACCEPT net:192.168.0.0/24 fw all

      Les règles dans policy refusent tout ce qui vient de net. net est ici la seule interface connectée au réseau local, et qui reçoit donc les infos du réseau local, mais aussi ce que lui forwarde la freebox depuis internet. Normalement j'aurais du nommer cette interface dmz...

      La règle de rules fait une exception à policy (comme d'hab), et autorise toutes les connexions au firewall qui viendraient du réseau local. À mettre en place de cette façon si on a une confiance totale dans son réseau local. Sinon, lister les ports qui sont acceptés dans cette règle.

      Petite astuce si tu es en freebox non dégroupée : la freebox ne renvoie pas les paquets émis depuis le réseau local vers ton IP publique, sur la machine dmz, ou même vers la machine spécifique pour les ports configurés un à un. La translation IP publique -> adresse interne ne se fait que pour les accès depuis l'intérieur. Il faut donc ajouter ça dans les rules :

      DNAT fw fw:192.168.0.1 tcp www - 81.56.a.b

      Autrement dit : tout ce qui vient de la machine firewall et qui voudrait sortir vers l'IP publique 81.56.a.b est redirigé sur la machine firewall.

      Bien utile quand on fait tourner un serveur web sur l'IP publique.
      • [^] # Re: ...

        Posté par  (site Web personnel) . Évalué à 2.

        et si on a aucun ordi sur l'IP DMZ ?
        • [^] # Re: ...

          Posté par  . Évalué à 2.

          Tu ne crains rien dans ce cas.
          Mais alors autant pas mettre d'IP dans DMZ. Laisser la valeur du dernier octet à 0.
  • # \o_ moi

    Posté par  (site Web personnel) . Évalué à 8.

    Oui, moi aussi ça m'est arrivé.

    Par contre c'était entièrement de ma faute.

    Je suis en Mandriva Cooker (version de dev) et j'ai eu le malheur de faire la mise à jour de ma Cooker au moment où un des packageurs avait merdé le package de freetype (Ce package défectueux l'a été moins de 20 mnutes sur les dépot rpm mais j'ai pas eu de bol). Ce package défectuex entrainait des ralentissements énormes de la réactivté des applications. Bien sûr je ne savais pas que c'était ça donc j'ai eu l'idée de créer rapidement un compte de test pour voir si un utilisateur avec une conf vierge avait ce problème. Un 'chti coup de useradd avec logn 'test' et pass 'test'. Hop ça marche, ça rame pas. J'en parle à un employé MandrivaSoft et mon problème rentre dans l'ordre et bien sûr j'oublie le nouveau compte créé.

    Mais j'ai été très con car d'une, j'ai un serveur ssh configuré sur ma machine et non limité à un seul compte donc mon compte 'test' était utilisable pour se connecter, de deux, j'ai utilisé les login et mot de passe les plus con du monde et trois, je n'ai pas supprimé le compte après test.

    Le lendemain matin au réveil, même chose, je vois mon gkrellm au taquet. Je fait vite un 'top' et je vois un 'pscan" qui tourne en bouffant 100% du CPU. Arggggg ! pscan ! Je me suis dis "p" comme password ! Je fais un who et je vois que 'test' est logué et là je me rends compte de ma connerie. Je kill sa session ssh, je kill le serveur ssh, je débranche la prise et je commence à voir ce que le script-kiddies a fait.

    Premier constat, il est toujours resté loggué en 'test' (ouf ! ce compte n'a aucun droit). Un petit tour dans /var/log/message m'apprends comme d'habitude que plein de script-kiddies ont essayé de se connecter sur mon ssh sans succès et avec pourtant des centaines de tentatives et j'apprends aussi que mon script kiddies a essayé test/test au premier coup et il a gagné \o/

    Petit tour dans ~test et là je vois le kit du petit script-kiddies laissé sur place. Je recherche les fichiers appartenant au compte 'test' et je trouve d'autres fichiers dans /var/tmp, pas grand chose en fait. Après analyse, j'ai l'ip de mon pirate, le nom de son club de H4CK3RS, ce qu'il faisait sur mon ordi à savoir scanner d'autres machines avec un dictionnaire de mots de passe et aussi avait hébergé un serveur irc pour discuté avec les potes de son club des prochaines attaques qu'ils allaient faire. A part ça, rien n'a été touché et il était connecté depuis moins de 20 minutes.

    En tout cas, maintenant j'ai limité mon serveur ssh à un compte avec un vrai mot de passe et je ne créé plus de compte temporaire ou alors j'utilise des vrais mots de passe :)

    Par contre, toi vu qu'il semble s'être connecté avec ton compte, il a eu accès à tes données donc vérifie bien qu'il n'a pas pu avoir accès à un fichier de mots de passe, de numéro de compte en banque,... car là c'est plus dangereux.

    Un conseil, lance un John The Ripper sur tn fichier de mot de passe pour voir si ton mot de passe arrive à être cracké facilement. N'hésites pas à aider John The Ripper en lui donnant des dictionnaires (français, des mots de ta page-web,...). Le maillon faible est souvent le mot de passe. Dans mon école on avait lancé John The Ripper et en 2 jours la moitié des mots de passe avait été crackés (dont quelques profs).

    L'association LinuxFr ne saurait être tenue responsable des propos légalement repréhensibles ou faisant allusion à l'évêque de Rome, au chef de l'Église catholique romaine ou au chef temporel de l'État du Vatican et se trouvant dans ce commentaire

    • [^] # Re: \o_ moi

      Posté par  . Évalué à 2.

      Question bète : tu as porté plainte ?

      "La première sécurité est la liberté"

      • [^] # Re: \o_ moi

        Posté par  (site Web personnel) . Évalué à 2.

        J'avoue que non. Le mec étant à l'étranger, j'imagine pas le bordel. En plus l'ip que j'ai est surement celle d'un autre ordi piraté

        L'association LinuxFr ne saurait être tenue responsable des propos légalement repréhensibles ou faisant allusion à l'évêque de Rome, au chef de l'Église catholique romaine ou au chef temporel de l'État du Vatican et se trouvant dans ce commentaire

        • [^] # Re: \o_ moi

          Posté par  (site Web personnel) . Évalué à 3.

          Pas grave. D'experience, c'est toujours une bonne idee de faire un whois, chercher l'email abuse et envoyer les details, j'ai deja eu plusieurs contacts fructueux, notemment avec la Suede qui reponds generalement tres favorablement avec ce genre de probleme.

          Steph
    • [^] # Re: \o_ moi

      Posté par  . Évalué à 7.

      sshd_config a pleins d'options bien commodes faciles a mettre en place, genre


      AllowUsers toi
      Seul toi pourras utiliser ssh

      MaxStartups Pour limiter le nombre de tentative d'identifications

      Le mieux est de bloquer le mot de passe et de s'authentifier par cle rsa...
  • # Pour clore ...

    Posté par  . Évalué à 1.

    Merci à tous pour vos contributions/astuces/avis,
    et pour clore, je tenais à dire que j'ai donc renforcé mes défenses Firewallesque et sshesque.

    J'en ai dailleurs profité pour changer de firewall pour passer de firestarter à KmyFirewall (kde).
    Firestarter est super pour les plutot débutants, et pour apprendre ce qu'est un firewall, mais kmyfirewall permet une gestion plus fine des regles, à mont gout en tout cas.

    Mes 2 cents

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n’en sommes pas responsables.