SME 7.5 + sme7admin + PuTTY ; Y a-t-il eu intrusion ?

[HP77]

Bonjour,

J'hésite un peu à poster ce message dans le forum "Sécurité et réseaux", peut-être serait-il mieux de la placer dans le forum "E-smith / SME"...

Je viens de découvrir deux e-mails de la part de sme7admin dont voici le contenu :

[ALRT] ServeurHome.MonDomaine : cnx ssh = 10 (max=7) Dimanche 3 octobre 2010 20h35
De: "sme7admin-daemon@MonDomaine" <sme7admin-daemon@MonDomaine>
À: admin@MonDomaine

ServeurHome.MonDomaine : Mon Oct 4 02:35:07 2010
There are 10 opened SSH sessions on the server, you had set the alert limit to 7 sessions.
(Advice : check if it is known administrative connections, and not hackers.)
If you have access to the server-manager, use this link to modify the limit :
https://ServeurHome.MonDomaine/server-m ... ert=MaxSsh

et

[STATUS] MonServeurHome.MonDomaine Lundi 4 octobre 2010 0h25

De: "sme7admin-daemon@MonDomaine" <sme7admin-daemon@MonDomaine>
À: admin@MonDomaine
Server status Mon Oct 4 06:25:07 2010
Number of opened connections : ssh=1 ftp=0 vpn=0 netbios=0

#>tail /var/log/messages :
Oct 4 06:24:27 ServeurHome sshd(pam_unix)[1805]: authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=host-219-235-y-xxx. iphost . gotonets . com user=daemon
Oct 4 06:24:33 ServeurHome sshd(pam_unix)[1808]: authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=host-219-235-y-xxx. iphost . gotonets . com user=bin
Oct 4 06:24:39 ServeurHome sshd(pam_unix)[1810]: check pass; user unknown
Oct 4 06:24:39 ServeurHome sshd(pam_unix)[1810]: authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=host-219-235-y-xxx. iphost . gotonets . com
Oct 4 06:24:45 ServeurHome sshd(pam_unix)[1813]: check pass; user unknown
Oct 4 06:24:45 ServeurHome sshd(pam_unix)[1813]: authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=host-219-235-y-xxx. iphost . gotonets . com
Oct 4 06:24:51 ServeurHome sshd(pam_unix)[1815]: check pass; user unknown
Oct 4 06:24:51 ServeurHome sshd(pam_unix)[1815]: authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=host-219-235-y-xxx. iphost . gotonets . com
Oct 4 06:25:01 ServeurHome sshd(pam_unix)[1817]: check pass; user unknown
Oct 4 06:25:01 ServeurHome sshd(pam_unix)[1817]: authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=host-219-235-y-xxx. iphost . gotonets . com

#>netstat --numeric-hosts -tpu :
Active Internet connections (w/o servers)
Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name
tcp 0 68 219 . 74 . 24 . 227:ssh 219.235.y.xxx:54181 ESTABLISHED 1874/sshd: unknown

#>service httpd status

#>service smb status
run: /service/nmbd: (pid 4860) 603969s, normally down; run: log: (pid 3535) 603991s
run: /service/smbd: (pid 4877) 603964s, normally down; run: log: (pid 3524) 603991s

#>service sshd status
run: /service/sshd: (pid 4704) 603973s, normally down; run: log: (pid 3541) 603991s

Cela ressemble très fortement à un "bot" en provenance d'un site "chinois" (cf. l'écriture), si je ne me trompe pas.
(je ne suis pas encore capable de déterminer l'emplacement géographique d'une adresse IP...)


Ma question est donc, s'il y a eu 10 connexions ouvertes, il y a-t-il eu intrusion ?

Lors de ma connexion SSH de ce matin en tant que root, via PuTTY, j'ai pu constater que la dernière connexion datait du 22 septembre.


Maintenant, je me pose aussi les questions suivantes :

- Est-ce là, la date de dernière connexion SSH réussie sur le serveur en tant que root ?
- -> il semblerait que oui : une seconde connexion en tant que root me donnait la date et heure de la 1ère d'aujourd'hui.

- Est-ce la date de dernière connexion établie depuis mon PC portable du boulot ? (mon intuition me dit que non mais j'ai un doute et pas d'autre PC pour vérifier...)

- Eventuellement, Est-ce là, la date de dernière connexion SSH réussie sur le serveur ? (= j'en doute un peu, et même beaucoup mais, cela serait rassurant...)

Bon, je vais tâcher de lire la doc de PuTTY plus en détails quand j'aurais le temps (pas aujourd'hui) mais si quelqu'un peut m'éclairer sur la question, ça mévitera de stresser (peut-être inutilement) trop longtemps.


Sur ce, merci de m'avoir lu. Bonne journée !

Cordialement,
HP

[jdh]

C'est un peu incroyable que ne soit pas précisé si c'est une SME en "server only" ou en "server+gateway" ! Cela change beaucoup la problématique !

Si le serveur SME offre l'accès ssh depuis l'extérieur et sur le port standard (22/tcp), il n'est pas surprenant qu'il y ait tentatives d'accès (avec force brute). C'est pour cela que des programmes comme fail2ban ou denyhosts ont été créés : blocage des ip effectuant ce type de tentative.

Il est possible d'agir directement en modifiant la règle d'ouverture iptables avec -m state et des nombres de tentatives (ce que j'ajoute très volontiers).

Il est encore plus simple de ne pas ouvrir ssh vers l'extérieur ...

Au besoin, si cela peut faire comprendre pourquoi il faut choisir des mots de passe un peu solides ...

[ccnet]

ssh accessible directement depuis internet reste une option très risquée. Le vpn (ipsec ou ssl) s'impose évidement. Dans tous les cas le mot de passe root (et les mot de passe importants) doit être solide, c'est à dire 8, mais plutôt 10, caractères aléatoires comportant chiffes, lettres, caractères spéciaux et non dérivé d'un mot susceptible de figurer dans une dictionnaire.

[HP77]

Bonsoir,

C'est un peu incroyable que ne soit pas précisé si c'est une SME en "server only" ou en "server+gateway" ! Cela change beaucoup la problématique !

Désolé, j'avais tellement "la tête dans le guidon" sur d'autres choses que j'ai un peu oublié de préciser certaines choses lors de cette surprenante découverte.

Bon, le serveur est en mode "Server & Gateway" dans las DMZ d'une "Box" (c'est mon serveur perso pour les photos que je partage avec ma famille...)

Si le serveur SME offre l'accès ssh depuis l'extérieur et sur le port standard (22/tcp), il n'est pas surprenant qu'il y ait tentatives d'accès (avec force brute). C'est pour cela que des programmes comme fail2ban ou denyhosts ont été créés : blocage des ip effectuant ce type de tentative.

Je te remercie pour ce partage d'infos, je vais jeter un oeil sur Contribs.org pour voir s'il y a quelque chose qui s'intègre à Server-Manager. Autrement, je me permettrais de te consulter pour un "REX" si j'ai besoin d'aide supplémentaire à la doc (en espérant ne pas avoir l'équivalent d'un annuaire à faire rentrer dans ma "caboche" )

Et, voui, le port SSH par défaut est bien le 22 mais je ne sais plus si c'est toi ou Jibe qui avait dit un jour, "changer le port SSH est une ânnerie, les logs ne voudront plus rien dire..." mais, si j'ai bonne mémoire, cela concernait l'utilisation du port 443 (HTTPS) pour passer à travers un firewall...
Cela dit, les ports ont des valeurs specifiques et reservées, en théorie, à des usages tout aussi spécifiques.
Pour finir, un scanneur de ports va, pour aller plus vite, interroger les ports standard mais, pas seulement ceux-là...
Bref, changer les numéros de port peux réduire le nombre d'attaques mais, AMHA, juste allonger un peu le temps nécessaire pour faire un sal boulot sur un serveur ciblé.

C'est là que, si j'ai bien compris, il y a intérêt à savoir ce que signifie sécuriser un système informatique...

Il est possible d'agir directement en modifiant la règle d'ouverture iptables avec -m state et des nombres de tentatives (ce que j'ajoute très volontiers).

Là, j'ai encore pas mal à apprendre : je connaît de nom, crois savoir à peu près à quoi cela sert et ce que l'on peut en faire mais, si j'en suis encore à SME "out of the box", c'est que je ne suis pas encore un expert en administration sous Linux (...)

Il est encore plus simple de ne pas ouvrir ssh vers l'extérieur ...

J'en conviens mais, comment administrer à distance autrement que par SSH ?

Au besoin, si cela peut faire comprendre pourquoi il faut choisir des mots de passe un peu solides ...

Ca, pas de souci, c'est compris depuis bien longtemps comme le fait que les mots de passe compliqués ne protègent de rien du tout mais permettent seulement de rendre les choses plus compliquées et plus longues aux gens mal intentionés (la course de la vitesse et puissance de calcul contre la longueur et les méthodes d'encryption (...), de maniè-re un peu plus "globale".

ssh accessible directement depuis internet reste une option très risquée.

J'en conviens mais comment faire autrement lorsque l'accès à la console est le seul moyen pour pour certaines tâches administratives ?

Le vpn (ipsec ou ssl) s'impose évidement.

Humm ?
Mouais, peut-être que deux logins + deux mots de passe pour accéder à "Server-Manager", ça peut assaisoner les choses de manières plus corsées, avec en prime le "filtrage" opéré par SME permettant un accès seulement aux adresses IP appartenant au(x) réseau(x) local(aux) de SME.

MAis pour moi, encore amateur / "newbie", cela passe encore et toujours par de bons mots de passe bien chiants à mémoriser pour les humains.

Dans tous les cas le mot de passe root (et les mot de passe importants) doit être solide, c'est à dire 8, mais plutôt 10, caractères aléatoires comportant chiffes, lettres, caractères spéciaux et non dérivé d'un mot susceptible de figurer dans une dictionnaire.

+1

C'est pourquoi je fais grogner mes utilisateurs en ne changeant pas les paramètres SME par défaut sur les mots de passe.


Bon, maintenant, comment pourrais-je faire pour savoir vraiment s'il y a eu intrusion sur mon système ?
SystemMonitor et SME7admin ne me permettent pas trop de cibler précisément sur ce que je cherche, enfin, du peu que j'en sâche / vois depuis Server-Manager..

Quels logs devrais-je, selon vous, consulter de toute urgence voire, sauvegarder pour les relire à tête reposée ce weekend ?


En attendant, faute de mieux, je vais modifier ma configuration actuelle pour tenter de brouiller les pistes en cas de récidive.

Dans tous les cas, je vous remercie pour vos apports sur le sujet.

Bonne soirée.

Cordialement,
HP


P.S. - 2010-10-05 @ 00h55 :
Je viens de faire une recherche depuis Server-Manager pour qu'il me sorte toutes les occurences pour "iphost" et là, c'est inquiétant : toute la journée d'hier, ça a "bombardé" !!
Ils m'ont "dégoté", (je ne sai pas comment ), deux noms "d'utilisateurs humains", c'est là que ça devient vraiment inquiétant.
pour plus d'infos, voici un lien vers un "copié-collé" ans un fichier texte : http://hp1977.dyndns.org/ixus/docs_pers ... 35_sgt.txt
Bon, tant pis pour mon accès SSH, je le ferme pour quelques temps, le temps de tester les deux solutions proposoées par JDH, c'est un minimum...
Quand au FTP, il est désactivé (mots de passe en clair, c'est de la pure çonnerie, même sur un LAN (il peut y avoir une machine verrolée qui espionne... ) !!)

[HP77]

Bonjour (euh, plutôt bonsoir ou bonne nuit pour les français...),

Je risque d'avoir à nouveau besoin d'accéder à mon serveur à distance via SSH (retour en France, en hiver... brrrr ) et je ne voudrais pas m'exposer de nouveau à 20h ou plus de "Force Brute" sur SSH.

J'ai donc questioné G**gle sur fail2ban et les premiers résultats ne sont pas très engageants :

Aller à fail2ban‎: fail2ban. impossible pour le moment de le faire tourner avec SME 7 les log de sshd sont fait avec multilog, le format est reconu dés ...

Bon, je vais me tourner vers denyhosts pour ne pas risquer davantage de mettre le bazard dans mon système SME.

Juste par curiosité, j'aurais bien aimé connaître vos points de vue sur ces deux solutions.

En même temps, s'il y a d'autres solutions pour SME, que devrais-je rechercher précisément (mots clefs) ?
(Entre 4h et 6h du matin, j'avoue avoir bien du mal à me concentrer à deviner ce que j'ignore encore "pour faire mouche")

Bon sérieusement, je vais regarder denyhosts de plus près s'il ne fait pas objet lui aussi d'incompatibilités et autres bugs (sinon, comment essayer ou seulement voir à quoi ça ressemble, etc... ??


Bien merci pour votre précieux temps et tout aussi précieuses connaissances en partage ici-même.

Cordialement,
HP

[jdh]

SME supporte le VPN PPTP me semble-t-il, c'est déjà ça !
Cela vaudrait déjà mieux que d'ouvrir ssh sur l'extérieur ...

[HP77]

Bonsoir,

Qu'est-ce qui est mieux entre PPTP et OpenVPN ?

Mon premier serveur perso était configuré avec OpenVPN et mes clients WinXP exploitaient une interface "TAP" mais, je n'ai pas réinstaller après le crash disque de mon système en Mai/Juin dernier car OpenVPN ne passait pas à travers le firewall du campus où je travaille.

Aurais-je plus de chance via PPTP ?

Cela dit, je n'aurais plus la main sur SSH hormis, peut-être, s'il n'accepte les connexions QUE depuis le LAN mais serais-je vraiment sur le LAN avec PPTP ?

Pour OpenVPN, j'avais bénéficié de l'un des deux modes de fonctionnement possibles, à savoir :
- soit dans une plage d'adresses IP appartenant au LAN (ex. 192.168.2.100 - 150 pour LAN et 192.168.2.151 - 200 pour OpenVPN) (ce qui était mon cas à l'époque)
- soit dans un autre sous réseau (ex. 192.168.2.xxx pour LAN et 192.168.3.xxx pour OpenVPN)

Qu'en sera-t-il de PPTP ?

[ccnet]

Qu'est-ce qui est mieux entre PPTP et OpenVPN ?

Sans l'ombre d'un doute Open VPN qui est un vpn SSL. Pour PPTP il est indispensable si vraiment vous devez l'utiliser de choisir un mot de passe très, très robuste. J'insiste : long et complexe.

[HP77]

Bonsoir,

Je reviens enfin sur mon problème d'attaques "force brute" sur le port 22.

Pour résumer :
- fail2ban est toujours dans mon viseur et je souhaite de tout coeur ( ) que nos amis unnilennium et SibSib aient pu progresser vers quelque chose de reproductible par quelqu'un de mon espèce... (ne me demandez pas laquelle, j'en suis toujours à la déterminer entre amateur électronicien et informaticien, entre autres choses... )
- denyhosts est peut-être plus à ma portée mais avant de me jeter corps et âme dans la bataille, j'aimerais bien savoir ce qu'en pensent les éventuels adeptes et aussi Pourquoi nos amis ont-ils préféré fail2ban ?

Bon, avant d'installer quoi que ce soit, sous forme de version Bêta ou pas, je me suis dit que je pourrais bien essayer ceci :
[quote="jdh"]Il est possible d'agir directement en modifiant la règle d'ouverture iptables avec -m state et des nombres de tentatives (ce que j'ajoute très volontiers).quote]

"man iptables" me donne ceci au sujet de l'option "-m" :

Code: Tout sélectionner

COMPATIBILITY WITH IPCHAINS
       This iptables is very similar to ipchains by Rusty Russell.  The main difference is that the chains INPUT and OUTPUT are only traversed for packets
       coming  into  the  local  host  and  originating  from the local host respectively.  Hence every packet only passes through one of the three chains
       (except loopback traffic, which involves both INPUT and OUTPUT chains); previously a forwarded packet would pass through all three.

       The other main difference is that -i refers to the input interface; -o refers to the output interface, and both are available for packets  entering
       the FORWARD chain.

       iptables is a pure packet filter when using the default 'filter' table, with optional extension modules.  This should simplify much of the previous
       confusion over the combination of IP masquerading and packet filtering seen previously.  So the following options are handled differently:
        -j MASQ
        -M -S
        -M -L
       There are several other changes in iptables.

A la lecture (en diagonale) du reste de la page du man, je ne me sents vraiment pas "chaud" pour me plonger dans un exercice de style IPTables, surtout sans pouvoir prendre le temps d'apprendre cet élément "de base" indispensable (à mes yeux).


En bref, si vous connaissez une recette pas trop compliquée (sauf stopper SSH depuis le panneau adécquat de Server-Manager) que je pourrais reproduire, elle serait vraiment bienvenue pour me dépanner car, perfectioniste que je suis, si tôt que j'aurais compris le "truc", je sentirais l'envie d'assaisoner le tout à ma façon dès que possible.


Bon, et bien, je retourne à SystemMonitor et cie que je "dois" ré-installer, puisque je reparts de zéro pour la "ème fois avec ce serveur...


Bonne soirée et bien merci à vous.

Cordialement,
HP