OVH Community, votre nouvel espace communautaire.

Encore : Plesk et accès SQL depuis l'extérieur


Chabi01
30/06/2016, 21h24
(soupir) : c'est ce que je lui ai dit cet après midi. Un réplica de la base mis à jour périodiquement.
Bonne soirée
Xavier

cassiopee
30/06/2016, 19h37
Citation Envoyé par Chabi01
Apparemment, le dev me dit que le logiciel de caisse n'accepte que la mise à jour via une connexion mysql
Ah oui, là c'est un peu embêtant. A mon niveau, j'aurais créé une base MySQL locale afin que le logiciel de caisse fasse
sa mise à jour localement puis un script PHP qui va lire cette base MySQL locale et appeller l'URL
vue plus haut "http://mon_domaine.fr/vente.php?code_produit=14&quantite=4&prix_unitaire =50"
afin de mettre à jour la base principale.

C'est un peu usine à gaz mais ce serait bien plus sécurisé comme ça.

Chabi01
30/06/2016, 19h27
Citation Envoyé par cassiopee

Ouh là, mais c'est très différent ce genre de problématique (donc "foutez le dehors" ).

Pour ce genre de remontée d'info, plutôt que d'ouvrir l'accès à distance à la base MySQL,
je ferais appel à des scripts (PHP ou autre) hébergés dans le dédié avec les paramètres qui vont bien.

Du genre un appel à l'URL "http://mon_domaine.fr/vente.php?code_produit=14&quantite=4&prix_unitaire =50"
pour refléter une vente du produit 14, au prix unitaire de 50 Euros en 4 exemplaires, par exemple.
( plutôt que de faire en SQL un "INSERT INTO table_vente SET quantite=4, prix_unitaire=50, code_produit=14" )
dans un script PHP s'exécutant dans le PC local.

Comme ça, pas besoin de s'embêter avec une autorisation d'IP, d'ouvrir MySQL sur Internet, etc.

C'est bien plus sécurisé (dans ton approche, si tu as 50 points de vente, c'est 50 endroits avec
le login et mot de passe MySQL de ta base ... il suffit qu'un seul lieu soit compromis pour tout
mettre par terre)

Bien entendu, avant d'appeler l'URL vue ci-dessus, il y aurait une première URL à appeler
avec un login et un mot de passe, donnant un identifiant de session temporaire à ré-utiliser
dans les URL appelées ensuite (ou encore via un cookie). ça peut être un login et un mot de
passe par lieu de vente.

Et le tout sans doute en "https" plutôt qu'en "http" de façon à éviter un sniffage réseau toujours possible.
Oui, c'est ce que j'avais indiqué au développeur à peu de chose près.
Je lui ai bien demandé de faire un script php pour le stocker sur le serveur exactement comme tu le décris, script qui serait chargé de faire les mises à jour entre la boutique et le point de vente.
Apparemment, le dev me dit que le logiciel de caisse n'accepte que la mise à jour via une connexion mysql (ce qui en soit me gonfle un peu : si le dev ne sait pas ce que "fait" le logiciel de caisse, cela peut tourner au grand n'importe quoi).
C'est bien toute l'origine de mon histoire dans ce post en fait..
Bon, au moins, j'ai compris la logique du parefeu et de mysql, ce qui est le principal ici.
Je vous tiendrai au courant si j'ai une réponse du gars sur le fofo plesk.
Bonne soirée à tous
Xavier

cassiopee
30/06/2016, 19h01
Citation Envoyé par Chabi01
Ta solution Cassiopée (tu me dis si je me trompe).
Sur ma machine, je fais un script bash que je mets à jour en cron du genre :
Code:
wget -q -O - checkip.dyndns.org|sed -e 's/.*Current IP Address: //' -e 's/<.*$//' > /home/mondossier/ipencours.txt
(sous Windows, faudrait que je regarde comment faire ou voir si ça marche..).

Après ça, il faudrait que mon poste ftp le fichier sur le serveur (toujours par cron).
Le serveur serait lui chargé de vérifier le fichier qui lui a été envoyé et de mettre à jour le firewall avec iptables, ok.
(J'ai bon là ? J'ai bon ?
Presque : moi je ferais un petit script (en Python, en PHP, en PERL, peu importe) appelé via cron
toutes les 1 minutes.
Ce script :

1) appelle une URL du genre "checkip.dyndns.org" ou équivalent

2) regarde si cette IP est identique à la précédente IP stockée lors de l'appel précédent au script

3a) si IP identique, on fait rien de plus, le script s'arrête là

3) si IP différente, le script appelle une URL du serveur dédié du genre "http://mon.ddomaine.fr/tralala/toctoc.php"
ou autre nom bien difficile à trouver pour un pirate.

Ce script "toctoc.php" récupère l'IP publique du PC local (variable PHP : $_SERVER["REMOTE_ADDR"] )
et exécute une commande "iptables" (via l'instruction PHP "system()" ou équivalent) afin
d'autoriser l'IP récupérée à se connecter sur le port 3306 du serveur dédié. + suppression
de l'autorisation précédente, commande "iptables -D ...")

4) On stocke la nouvelle IP dans un fichier dans le PC local (afin de servir de base de comparaison
pour le prochain appel du script via cron)

Ok, mais si j'ai bien compris, il faudrait que l'ip soit vérifiée trèèèès fréquemment pour éviter un "j'peux plus m'connecter, qu'est-ce qui s'passe !?"
Oui, genre toutes les minutes. Vu ce que fait le script, ça ne va pas charger la mule

Je vous donne alors un cas concret : un logiciel de caisse qui doit se synchro avec un crm ou un site d'e-commerce au niveau des stocks. Si au moment de la synchro de base il y a l'ip qui n'est pas à jour, on se retrouve alors avec une erreur de connexion...

Votre avis :
"Xavier n'a :
A - Rien compris, c'est une brèle, foutez-le dehors
B - Beaucoup trop travaillé aujourd'hui, on dirait qu'il ne comprends plus grand chose (foutez le dehors)
C - à peu près compris. Mais foutez le dehors quand même.
"
Merci
Ouh là, mais c'est très différent ce genre de problématique (donc "foutez le dehors" ).

Pour ce genre de remontée d'info, plutôt que d'ouvrir l'accès à distance à la base MySQL,
je ferais appel à des scripts (PHP ou autre) hébergés dans le dédié avec les paramètres qui vont bien.

Du genre un appel à l'URL "http://mon_domaine.fr/vente.php?code_produit=14&quantite=4&prix_unitaire =50"
pour refléter une vente du produit 14, au prix unitaire de 50 Euros en 4 exemplaires, par exemple.
( plutôt que de faire en SQL un "INSERT INTO table_vente SET quantite=4, prix_unitaire=50, code_produit=14" )
dans un script PHP s'exécutant dans le PC local.

Comme ça, pas besoin de s'embêter avec une autorisation d'IP, d'ouvrir MySQL sur Internet, etc.

C'est bien plus sécurisé (dans ton approche, si tu as 50 points de vente, c'est 50 endroits avec
le login et mot de passe MySQL de ta base ... il suffit qu'un seul lieu soit compromis pour tout
mettre par terre)

Bien entendu, avant d'appeler l'URL vue ci-dessus, il y aurait une première URL à appeler
avec un login et un mot de passe, donnant un identifiant de session temporaire à ré-utiliser
dans les URL appelées ensuite (ou encore via un cookie). ça peut être un login et un mot de
passe par lieu de vente.

Et le tout sans doute en "https" plutôt qu'en "http" de façon à éviter un sniffage réseau toujours possible.

Chabi01
30/06/2016, 18h58
Encore moi, j'ai une autre question sur un autre sujet, je vais créer un autre post pour pas tout mélanger

Chabi01
30/06/2016, 18h38
Ta solution Cassiopée (tu me dis si je me trompe).
Sur ma machine, je fais un script bash que je mets à jour en cron du genre :
Code:
wget -q -O - checkip.dyndns.org|sed -e 's/.*Current IP Address: //' -e 's/<.*$//' > /home/mondossier/ipencours.txt
(sous Windows, faudrait que je regarde comment faire ou voir si ça marche..).

Après ça, il faudrait que mon poste ftp le fichier sur le serveur (toujours par cron).
Le serveur serait lui chargé de vérifier le fichier qui lui a été envoyé et de mettre à jour le firewall avec iptables, ok.
(J'ai bon là ? J'ai bon ?

Ok, mais si j'ai bien compris, il faudrait que l'ip soit vérifiée trèèèès fréquemment pour éviter un "j'peux plus m'connecter, qu'est-ce qui s'passe !?"
Je vous donne alors un cas concret : un logiciel de caisse qui doit se synchro avec un crm ou un site d'e-commerce au niveau des stocks. Si au moment de la synchro de base il y a l'ip qui n'est pas à jour, on se retrouve alors avec une erreur de connexion...

Votre avis :
"Xavier n'a :
A - Rien compris, c'est une brèle, foutez-le dehors
B - Beaucoup trop travaillé aujourd'hui, on dirait qu'il ne comprends plus grand chose (foutez le dehors)
C - à peu près compris. Mais foutez le dehors quand même.
"
Merci

cassiopee
30/06/2016, 18h16
Citation Envoyé par Nowwhat
J’ai bien vu, mais conceptuellement, je me trompe pas : ça fonctionne :
Ok, je n'avais pas bien compris ce que tu voulais dire.

ça fonctionne, oui, mais c'est quand même un peu le marteau pour écraser une mouche

Disons que dans ta solution, c'est le serveur dédié qui fait l'effort de vérifier l'IP dynamique associée
à tel nom "toto.mon_domaine.fr" et ce 24/24h, 7/7j et il y a besoin d'un nom de domaine.

Dans ma solution, c'est le poste local qui fait l'effort de vérifier le changement d'IP et, le cas échéant,
de mettre à jour les IP autorisées dans le dédié et pas besoin de nom de domaine.

Bon, après c'est une nuance, une question de feeling, certains seront plus à l'aise avec
la logique de ta solution, d'autres avec la seconde mais globalement c'est presque pareil.

Chabi01
30/06/2016, 18h04
@Nowwhat (par rapport à l'ip dynamique)
Donc, si on veut que cela fonctionne, il faut dans l'absolu prendre un service externe (no ip ou autre) ou encore prendre un domaine. Dès lors, si on dig le domaine (via un script lancé en cron), on a l'ip, c'est ça ?

Chabi01
30/06/2016, 17h58
Cassiopée... mon aspirine....

Effectivement, le risque me semble plus grand avec un site pas à jour (Wordpress pas à jour... Y faut pas taper sur Wordpress... Non...c'est pô bien...

En faisant des recherches, le truc qui revient souvent, c'est que si mysql est ouvert, il peut alors être attaqué en brute force.
Oui, mais si seule 1 ip a le droit de se connecter sur le port 3306 depuis l'extérieur, comment un hacker arriverait il simplement à avoir une seule réponse lui permettant de lancer une attaque en brute force ??
La seule chose que je vois serait que le poste avec l'ip ayant l'autorisation de se connecter soit infecté par un virus qui permettent alors au hacker de récupérer les infos de connexion.
Je vais voir ce que me réponds le gars chez Plesk.
Xavier

Nowwhat
30/06/2016, 17h52
Citation Envoyé par Chabi01
Euh...y'a un gars qui me fait un peu flipper sur le forum Plesk...
Regardez le dernier message de ce post : https://talk.plesk.com/threads/how-t...1/#post-804173
SI - et seulement SI t'as quelqu'un qui sais quelle IP est dans la (ta) liste d'exception de tes règles parafeu,
et SI ce même type arrivé à spoofer cet IP (ou un ces IP's), yes ..... Il aura accès - mais accès devant la porte d’entrée de MySQL, faut il encore trouver le login et mot de passe.
Mais entre temps, il a cassé "Internet" bien comme il faut avec des conséquences "pas troll du tout", et ça ne sera pas vraiment passer inaperçu.

Citation Envoyé par cassiopee
Dans la problématique de Chabi01, c'est le contraire : le serveur dédié a une adresse IP fixe et c'est le poste local
(de l'admin, du développeur, etc.) qui a une adresse IP dynamique et on cherche à autoriser cette adresse IP
dynamique à accéder au port 3306 du serveur dédié.
J’ai bien vu, mais conceptuellement, je me trompe pas : ça fonctionne :

Le « PC » avec IP dynamique qui questionne le serveur MySQL (lui, avec un IP fixe) aura besoin d’un nom de domaine (URL ou DynDNS) qui doit être mise jour (un Livebox / Freebox / etc saura le faire) dès que son IP 'WAN' (== le IP dans la liste de parafeu sur le serveur) change. Jusqu’à la, rien de très sourcier

Sur le serveur ‘MySQL’ : questionne le URL et récupère l’IP à la main (comme exécuter « host sous.domaine.tld en boucle). Dès que l’IP change, change les règles parafeu concernant.

L’idée est : ces deux, trois manips peuvent très bien être sous-traités à un script ‘bash’ sur le serveur.

cassiopee
30/06/2016, 17h46
Citation Envoyé par Chabi01
Euh...y'a un gars qui me fait un peu flipper sur le forum Plesk...
Regardez le dernier message de ce post : https://talk.plesk.com/threads/how-t...1/#post-804173

En clair, le mec me dit qu'il y a un risque... qu'en pensez-vous ?
Merci de vos avis,
Xavier
Oui, enfin si on va par là, on ne fait plus rien.

Si on active Apache et que l'on a un site web actif, on court le risque d'avoir un jour un script PHP piraté
(au hasard : un WordPress pas à jour ).

A partir du moment où il ya restriction sur les adresses IP pouvant se connecter, le risque est quand même
plus que minime. Pour 99,9999% d'Internet le port 3306 de ton dédié apparaitra comme fermé.

Chabi01
30/06/2016, 17h40
Euh...y'a un gars qui me fait un peu flipper sur le forum Plesk...
Regardez le dernier message de ce post : https://talk.plesk.com/threads/how-t...1/#post-804173

En clair, le mec me dit qu'il y a un risque... qu'en pensez-vous ?
Merci de vos avis,
Xavier

cassiopee
30/06/2016, 17h39
Citation Envoyé par Nowwhat
Si ton "DYN-IP-DOMAINE " est géré ailleurs (pas sur ton serveur):
Un script qui s'exécute par cron chaque 5 minutes - et dès qu'il découvre que l'IP a changé, il change la règle(s) de ton parafeu.

Si tu gère toi même tes domaines avec par exemple "bind" (un serveur DNS) sur ton serveur, c'est plus vite et plus fiable : avec bind on peut exécuter des scripts dès que quelque change (ici : le IP d'un domaine ou sous-domaine). Cherche "RFC 2136" sur le net pour avoir plus des détails.
J'utilise moi même un tel mécanisme.

Exemple :
J'ai un abonnement ADSL "Orange" - mon IP change donc chaque semaine.
Sur mon LAN, derrière le "box" (pas de Livebox, mais peu importe) j'ai un serveur Windows R2 2012.
J'accède régulièrement à ce serveur "à distance", et j'utilise comme URL "server.domaine-chez-moi.tld".
Ce sous domaine et domaine est géré par mon serveur SYS chez OVH.
Mon router, un pfSense pour tout dire, va mettre à jour mon serveur DNS qui gère "server.domaine-chez-moi.tld" dès que mon IP "WAN" (== l'IP de ma connexion Orange) change. De cette façon, j'ai toujours accès avec un URL - qui ne change jamais - sachant que mon IP change tout le temps.
Oui mais attention, cette explication correspond à la situation inverse : c'est valable lorsque l'on cherche
à accéder à un serveur (web/FTP/etc.) hébergé dans/via une IP dynamique.

Dans la problématique de Chabi01, c'est le contraire : le serveur dédié a une adresse IP fixe et c'est le poste local
(de l'admin, du développeur, etc.) qui a une adresse IP dynamique et on cherche à autoriser cette adresse IP
dynamique à accéder au port 3306 du serveur dédié.

Chabi01
30/06/2016, 17h35
@Cassiopée : je comprends le principe. En gros, il faut quand même avoir un "point de référence" que l'on va mettre à jour pour "tenir le firewall à jour" en passant par un vérification d'une "adresse qui ne change pas" (un script, un domaine, etc..).

Merci encore à tous
Xavier

cassiopee
30/06/2016, 17h35
Citation Envoyé par Chabi01
J'ai trouvé cela : http://guide.ovh.com/ConnexionDistanteMySQL
Mais quid de la sécurité dans cette explication ?
Xavier
L'explication de ce guide ne concerne que l'étape n°3 de mon explication.

La sécurité sera quand même bonne dans la mesure ou seule telle ou telle IP (dynamique)
sera autorisée à se connecter sur le port 3306 du serveur dédié, via iptables ou Plesk.

Cette vérification iptables/plesk a lieu en amont de la vérification faite par MySQL lui-même
quant aux droits du compte utilisateur.

Si on est jusqu'au-boutiste : le script PHP "toctoc.php" que j'évoquais plus haut pourrait
également modifier les autorisations des utlisateurs MySQL de façon à n'autoriser
que "toto@82.83.84.85" (82.83.84.85 étant l'IP dynamique du moment)
à se connecter à MySQL et non "toto@%", en plus des modifications faites dans
iptables ou API Plesk selon.

Chabi01
30/06/2016, 17h31
Merci NowWhat
Cela veut dire que tu passes par un service comme dyndns ou noip ? Ou c'est la même chose ? Ou j'ai rien compris ?

Xavier

cassiopee
30/06/2016, 17h29
Citation Envoyé par Chabi01
@cassiopee (je prends un abonnement !)
Tu m'as demandé si l'ip était fixe ou dynamique parce que la solution différait. Du coup cela m'intrigue.
Je viens de terminer la mise en place de la première solution : cela fonctionne parfaitement (merci ! - Tu vas te lasser à force mais quand même). La base est accessible depuis l'ip cible et refuse les autres ip : testé, ok
Parfait

Quelle aurait alors été la démarche en se basant sur ton explication détaillée pour mettre en place la solution avec une ip dynamique tout en gardant la même sécurité ?

Merci à tous,
Xavier
Ce n'est pas moi mais Buddy je crois qui avait posé cette question.

Ceci dit, oui, dans ce cas c'est un peu plus compliqué. On ne peut pas autoriser directement une adresse IP dans le parefeu
du serveur dédié car elle change plus ou moins fréquemment.

Il y a plein de solutions différentes, la plus adaptée dépendra des contraintes que l'on a
( déjà est-ce que l'IP change une fois par heure ? une fois par jour ? une fois par mois ?
la réponse dépendant des FAI utilisés)

De manière générique, il s'agit d'autoriser l'IP dynamique et de mettre à jour ces autorisations
au fur et à mesure que l'adresse IP change.

Par exemple : Avant de se connecter à MySQL, on appelle une URL spécifique dans le navigateur web
de son poste local, cette URL étant hébergée dans le dédié,

Du genre "http://mon_domaine.fr/tralala/toctoc.php". Ce script PHP récupère l'adresse IP de mon poste client
et va l'ajouter aux adresses IP autorisées à se connecter sur le port 3306 du serveur dédié
(via iptables directement ou via un appel à l'API de Plesk dans ton cas)

On peut vouloir tout automatiser : avoir dans son PC local un script qui tourne, mettons toutes les minutes
et qui vérifie que l'IP du poste local n'a pas changé. Si jamais c'est le cas, le script appel tout seul l'URL vue ci-dessus.
Ce qui fait que le PC sera alors autorisé en permanence à accéder à distance à MySQL, comme avec
une IP fixe.

Nowwhat
30/06/2016, 16h52
Citation Envoyé par Chabi01
....
Quelle aurait alors été la démarche en se basant sur ton explication détaillée pour mettre en place la solution avec une ip dynamique tout en gardant la même sécurité ?
Si ton "DYN-IP-DOMAINE " est géré ailleurs (pas sur ton serveur):
Un script qui s'exécute par cron chaque 5 minutes - et dès qu'il découvre que l'IP a changé, il change la règle(s) de ton parafeu.

Si tu gère toi même tes domaines avec par exemple "bind" (un serveur DNS) sur ton serveur, c'est plus vite et plus fiable : avec bind on peut exécuter des scripts dès que quelque change (ici : le IP d'un domaine ou sous-domaine). Cherche "RFC 2136" sur le net pour avoir plus des détails.
J'utilise moi même un tel mécanisme.

Exemple :
J'ai un abonnement ADSL "Orange" - mon IP change donc chaque semaine.
Sur mon LAN, derrière le "box" (pas de Livebox, mais peu importe) j'ai un serveur Windows R2 2012.
J'accède régulièrement à ce serveur "à distance", et j'utilise comme URL "server.domaine-chez-moi.tld".
Ce sous domaine et domaine est géré par mon serveur SYS chez OVH.
Mon router, un pfSense pour tout dire, va mettre à jour mon serveur DNS qui gère "server.domaine-chez-moi.tld" dès que mon IP "WAN" (== l'IP de ma connexion Orange) change. De cette façon, j'ai toujours accès avec un URL - qui ne change jamais - sachant que mon IP change tout le temps.

fritz2cat
30/06/2016, 16h38
knock, c'est pour ouvrir une porte dans le firewall quand une séquence de connexions arrive sur des portes fermées.
L'article de OVH => aucune considération sur la sécurité => c'est pour apporter une soluce à ceux qui sont déjà bloqués à la toute première étape...

Chabi01
30/06/2016, 16h12
J'ai trouvé cela : http://guide.ovh.com/ConnexionDistanteMySQL
Mais quid de la sécurité dans cette explication ?
Xavier

fritz2cat
30/06/2016, 15h59
Ca m'intéresse aussi.
Je regarderais du côté de knock ( https://www.system-linux.eu/index.ph...ing-sur-Debian )

Chabi01
30/06/2016, 15h46
@cassiopee (je prends un abonnement !)
Tu m'as demandé si l'ip était fixe ou dynamique parce que la solution différait. Du coup cela m'intrigue.
Je viens de terminer la mise en place de la première solution : cela fonctionne parfaitement (merci ! - Tu vas te lasser à force mais quand même). La base est accessible depuis l'ip cible et refuse les autres ip : testé, ok

Quelle aurait alors été la démarche en se basant sur ton explication détaillée pour mettre en place la solution avec une ip dynamique tout en gardant la même sécurité ?

Merci à tous,
Xavier

Chabi01
30/06/2016, 15h07
Je comprends parfaitement
Je dis juste que la difficulté d'un forum est d'être capable de garder toujours la même "fraicheur" en abordant un problème posé par quelqu'un (même si cela peut être agaçant dans plusieurs cas).
Dans le post que tu me donnes en exemple, on voit bien que le type est largué sur un truc qui pour moi semble simple (ah !) : ses questions montrent qu'il n'a jamais fait ça et du coup, c'est fouillis, et même avec les différents liens et questions que vous lui avez tous posées.
C'est pas simple de filer un coup de main sur un forum quand on sait qu'on pourrait résoudre l'opération en 3 mn si on le faisait directement... oui, mais dans ce cas, il n'y aurait pas de forums et on perdrait alors la chance de pouvoir poser des questions à d'autres qui ont la connaissance et la solution à notre problème

Merci à tous pour l'implication ici
Xavier

fritz2cat
30/06/2016, 14h45
Tu peux voir dans un autre fil (forum.ovh.com/showthread.php/110129) qu'on en est à plus de 30 messages et ce n'est pas encore gagné.
Et dans ce cas, on avait même le nom du domaine en question.

Frédéric

Chabi01
30/06/2016, 14h37
Bonjour Fritz2cat,
C'est complètement vrai ce que tu écris (je suis le premier à demander les configs exactes sur un autre fofo où je suis modo) mais je voulais surtout comprendre la logique du bouzin et l'ordre : en faisant une recherche google sur le problème ou même en allant sur le forum Plesk, on a des milliers de réponses et il est compliqué alors de déméler les réponses pour avoir une procédure logique correcte.
Vous savez comme moi que ce qui nous semble logique et simple peut sembler obscur aux autres simplement par que nous donnons des solutions en considérant que plusieurs éléments que l'on met sous silence sont acquis par ceux qui nous lisent ("Comment ? Tu t'occupes d'un serveur et tu ne sais pas comment ouvrir un port avec iptables ???? Mmmm... Arrêtes l'informatique et mets toi à la broderie, c'est mieux pour toi... Ah ? Tu veux juste savoir ce point ? Désolé, je ne peux te répondre, je suis au dessus de ça, cela fait longtemps que je ne me pose plus la question !" - caricatural, mais fréquent sur les forums !). Cassiopee a répondu du "début à la fin" et c'est en cela que je lui suis reconnaissant : j'avais des morceaux mais pas la globalité du problème, ce qui me le rendait incompréhensible.
Je ne vais pas faire "ma mauvaise" parce que je suis vraiment content d'avoir compris quelque chose de nouveau ici, mais c'est quelque chose qu'il ne faut pas oublier quand on "répond" à quelqu'un : on ne sait pas qui est en face
Merci à tous pour votre temps et le partage de vos connaissances
Xavier

fritz2cat
30/06/2016, 11h31
Chabi01, tu as raison.
Mais dans certains cas (en particulier ceux qui ont des problèmes avec leur configuration DNS) il est vraiment inopportun de tout masquer jusqu'à la dernière adresse IP car on ne peut rien diagnostiquer, et on entame des conversations 100% stériles.

cassiopee
30/06/2016, 11h24
De rien, de rien

Chabi01
30/06/2016, 09h50
Je ne peux que dire une chose : très content que tu aies vu et répondu à ce post
La difficulté sur les forums et que l'on tombe sur des gens sympas comme toi mais également sur des personnes qui ne font que te dire que "ah ! comme tu es mauvais ! Si tu ne sais pas faire, abstiens toi et laisse ça à ceux qui savent faire ! Et comme tu ne donnes pas assez d'infos, de toute façon tu es perdu, personne ne te répondra !". Si je faisais ça avec les questions que l'on me pose de mon côté, cela ferait longtemps que j'aurai été viré des forums où je réponds !
Je sais m'occuper de beaucoup de problèmes particuliers mais je n'avais compris le principe ici : merci (chaleureusement) encore de ton explication.

Xavier

cassiopee
30/06/2016, 00h24
Citation Envoyé par Chabi01
Au niveau du parefeu où je vais indiquer les ips autorisées à se connecter, on est d'accord qu'il ne faut pas ajouter l'ip même du serveur ?
Non en effet, nul besoin d'ajouter l'IP du serveur dédié lui-même.

C'est seulement de dire :

1) j'autorise telle et telle adresse IP distante (poste d'admin, poste de développeur, etc.)
à se connecter sur le port 3306 du serveur MySQL du dédié.

2) j'interdis à toute autre adresse IP provenant d'Internet de se connecter à distance
sur le port 3306 de du serveur MySQL dans le dédié.

Pour être tout à fait complet : si tu ajoutais l'IP du serveur dédié lui-même,
cela n'aurait absolument aucun effet car les connexions locales se feront
via l'adresse IP locale 127.0.0.1 via un mécanisme de communication
qui s'appelle des "sockets", (un genre particulier de "fichier" local).

Cela court-circuite la pile réseau TCP/IP et donc le parefeu (firewall) dont
les règles ne s'appliquent pas.

buddy
29/06/2016, 22h00
non, pas besoin de mettre l'ip de ton serveur "hote".
çà passe en local.

Chabi01
29/06/2016, 21h25
Cassiopee... Grande classe.
Merci beaucoup pour cette aide complète et précise.
Je vais pouvoir tenter cela demain.
Une dernière petite précision. Au niveau du parefeu où je vais indiquer les ips autorisées à se connecter, on est d'accord qu'il ne faut pas ajouter l'ip même du serveur ?
Merci encore pour le temps et l'explication
Xavier

cassiopee
29/06/2016, 20h21
Permettre l'accès à distance à une base MySQL suppose pas mal d'étapes :

1) il faut que le serveur MySQL soit à l'écoute sur l'adresse IP publique du serveur (IP "normale" ou IP failover,
peu importe) et pas seulement à l'écoute sur l'adresse IP locale 127.0.0.1 (qui est la configuration par défaut
de MySQL, dans un souci de sécurité accrue)

2) A partir du moment où le serveur MySQL est à l'écoute sur l'extérieur, il vaut mieux restreindre qui peut
se connecter à lui à distance, (par défaut, tout le monde est autorisé) sinon les risques de piratages sont grands.
Pour cela il faudra utiliser le parefeu (firewall) du serveur dédié.

3) Enfin, une fois que les étapes 1) et 2) sont réglées, il faut encore autoriser la connexion distante à la base
de données elle-même, du point de vue de la gestion des droits des utilisateurs MySQL.

---

Etape 1 : ça se règle dans la configuration du serveur MySQL, cf là par exemple :

https://kb.plesk.com/fr/1134

Lire seulement jusque "dans l'état de commentaire." dans un premier temps.
Ne pas oublier de redémarrer MySQL une fois les modifications effectuées
afin que les changements soient pris en compte.

Si la configuration de MySQL est bonne, un simple :

Code:
telnet  3306
effectué dans le PC local devrait fonctionner, tout dumoins ne pas se faire jeter
par un "telnet: Unable to connect to remote host: Connection refused"
comme vu précédemment.

Seulement si c'est le cas, on peut passer à la suite. Si déjà là, ça ne va pas,
inutile de poursuivre les étapes suivantes, ça ne pourra pas fonctionner.


Etape 2 : afin d'éviter que tout le monde ne puisse se connecter à MySQL à distance,
il faut indiquer explicitement quelles sont les adresses IP fixes autorisées
(puisqu'il n'y a pas d'IP dynamique ici, côté poste client).

Cf là : http://www.codero.com/knowledge-base/questions/72/
à partir de l'étape 7 seulement. Il s'agit de configurer le parefeu (firewall) de Plesk
dans ce sens. On pourrait également le faire à plus bas niveau avec la commande
'iptables' mais bon, quitte à avoir un panel de gestion, autant s'en servir

Pour vérifier que tout est bon à cette étape :

1) ne pas autoriser/ajouter sa propre IP fixe dans un premier temps (mais autoriser les 2-3 autres)
2) vérifier que le telnet vu plus haut est désormais rejeté
3) autoriser son IP fixe en plus des autres IP déjà autorisées au point 1
4) vérifier que le telnet passe bien à nouveau.


Etape 3 : Il faut reprendre le tuto vu plus haut :

https://kb.plesk.com/fr/1134

et lire à partir de "Maintenant, vous devez accorder l'accès à l'adresse IP distante".

Si tout va bien à cette étape, c'est terminé.

Pour le vérifier, une commande telle que :

Code:
mysql -u utilisateur_mysql -p -h 11.22.33.44 mabase
à taper dans le PC local devrait permettre l'accès à distance à la base.

où :

- "utilisateur_mysql" est à remplacer par le compte utilisateur MySQL
- "11.22.33.44" est l'adresse IP publique du dédié
- "mabase" est le nom de la base de données.


Cette commande demandera interactivement le mot de passe du compte
utilisateur MySQL en question. Il faudra le taper en aveugle.

Si tout va bien, on obtient en retour l'invite de commande (prompt)
de MySQL :

Code:
mysql>_
et là on peut sabrer le champagne

Chabi01
29/06/2016, 17h47
Merci de ton "aide" NowWhat.
Voilà l'info : Ubuntu 14.04.2 LTS

Nowwhat
29/06/2016, 17h25
Citation Envoyé par Chabi01
.....: Plesk 12 sous Linux
Sous " Linux " .....
C'est comme dire : "j'ai une voiture" - or nous, il nous faut la marque, type - année de construction - version.

Le wiki machin de Linux : https://fr.wikipedia.org/wiki/Linux#...n_Timeline.svg

Une solution simple http://www.cyberciti.biz/tips/linux-...g-request.html
Il s'agit d'un exemple ou tu autorise un IP ( 202.54.1.50 ) et personne d'autre.
(note : je ne sais pas ce que tu parait faire avec Plesk - je ne le connais pas )

Chabi01
29/06/2016, 17h03
Bonjour Buddy,
2 ou 3 ip fixes.
1 pour moi, 1 pour un autre dev, 1 pour une machine de prod.

Pour compléter mon message précédent, voilà ce qui est répondu fréquemment (y compris dans la doc de Plesk) pour ouvrir une base sur l'extérieur :
https://forum.ovh.com/showthread.php...onnexion-Mysql

Merci pour l'aide
Xavier
[EDIT] : une info importante que je n'ai pas donnée : Plesk 12 sous Linux

buddy
29/06/2016, 17h01
Tu veux ouvrir mysql à une ip fixe ou dynamique ? Car les solutions diffèrent..

Chabi01
29/06/2016, 16h42
Merci pour vos réponse super rapides
@Sich : c'est bien là ma question : si j'autorise toutes les ip et pas seulement localhost avec 0.0.0.0, cela m'inquiète un peu...
@nowwhat : Oui, j'ai bien cherché sur Google et sur le forum et je suis tombé sur les réponses indiquant de commenter ou d'autoriser tous les réseaux via 0.0.0.0. Ce n'est pas vraiment ma question Mais merci pour la messe
Ce qui me pose question, c'est plus au niveau du parefeu et de la logique "Plesk".
- Dans my.cnf, j'ouvre tout le réseau avec 0.0.0.0
- Dans le parefeu, Mysql indique "Accepte entrant à partir de tout".
Dans ma petite tête, je comprends "Ok, on ouvre Mysql et n'importe qui peut entrer" !

Mais alors à quoi correspondent ces options dans Plesk si cela ne fonctionne pas ???
- quand on crée la base de données, on peut autoriser une ou plusieurs ip depuis l'extérieur
- Le firewall par défaut autorise toutes les connexions entrante sur mysql
- Malgré cela (et c'est ce qui me semble absurde), mysql n'écoute que locahost !

D'où mon incompréhension de la logique du problème ici !
Ma question n'est donc pas de comprendre pourquoi cela ne marche pas (il suffit d'ouvrir sur 0 0 0 0), mais :
- Quelle est la "logique Plesk" pour ouvrir une base mysql pour y accéder depuis l'extérieur si le paramétrage de base ne fonctionne pas (autoriser mysql sur tous les ports + paramétrer l'utilisateur depuis une ou plusieurs adresses ip) ?
- Comment paramétrer le parefeu de Plesk pour que je ne transforme pas le serveur mysql en Rave Party en autorisant tout le monde à venir faire la fête dessus ?
Ce qui m'intéresse donc, c'est comprendre la logique du paramétrage sur Plesk

Merci de vos réponses
Xavier

Nowwhat
29/06/2016, 16h27
Vu le sujet, t'as pas deux mots pour expliquer comment t'as cherché ?
Citation Envoyé par Chabi01
J'ai cherché (longgggtemps !) sur le forum et sur le web : toutes les solutions données ne passent pas...
Si je question Google, moi, j'ai la réponse immédiatement :
Code:
Google.fr : ouvrir MySQL pour un accès depuis l'extérieur
Ça donne au moins 3000+ réponses direct ...

Bien sur, il ne faut pas inclure le mot 'Plesk' - ce mot indique que tout devient plus compliqué ..... il suffit de l'oublier.

Le plus fun est que tu donne la réponse toi même déjà :
[QUOTE=Chabi01;673799]Au niveau de mon my.cnf, j'ai un bind-adress sur 127.0.0.1
Tout est dit, la messe est fini.
Tu cantonne MySQL à écouter à localhost, ou 127.0.0.1, l'IP qui est accessible QUE à partir de ton serveur lui même et nulle part ailleurs.

T'aurais pu aussi lancer un :
Code:
netstat -napt | grep 'mysql'
grenre :
Code:
root@ns311465:~# netstat -napt | grep 'mysql'
tcp        0      0 127.0.0.1:3306          0.0.0.0:*               LISTEN      21820/mysqld
tcp        0      0 127.0.0.1:3307          0.0.0.0:*               LISTEN      1317/mysqld
ce qui me dit que j'ai deux serveurs MySQL, sur la porte 3306 (par défaut ) et 3307 (mon MariaDB, un clone de MySQL)

Ne le prend pas mal, mais si tu ne sais pas ce que ça implique, ce "127.0.0.1" je te déconseille fortement de toucher à ton parafeu.
Pour autant, t'as besoin de ton parafeu pour protéger la porte "3306" si tu décide d’exposer ton serveur MySQL sur l'IP de ton serveur.

sich
29/06/2016, 15h59
si tu bind sur 127.0.0.1 c'est parfaitement normal que cela ne fonctionne pas.
Il faut effectivement bind mysql sur 0.0.0.0 pour que cela fonctionne.

Par contre il serait bon que tu n'autorises sur ton parefeu que des ips bien précises (la tienne et celle qui doivent accéder à MySQL).

Ou l'autre solution serait de monter un vpn entre tes machines pour ne pas ouvrir le port 3306 sur le web.

Perso je n'aime pas du tout ouvrir MySQL sur l'extérieur... Peut être un peu parano. Peut être que d'autres considèrent que l'on peux ouvrir ce service sans risque...
A la limite au moins changer le numéro de port pour éviter les scans de bots...

Chabi01
29/06/2016, 15h47
Bonjour à tous,
J'ai cherché (longgggtemps !) sur le forum et sur le web : toutes les solutions données ne passent pas...

Sur un Plesk 12, j'ai une base de données que j'ai configuré avec accès distant sur mon ip.
Au niveau du Firewall, Mysql a "Accepte entrant à partir de Tout".
Malgré cela, impossible de me connecter à la base à distance.
Si je fais un
Telnet xx.xx.xx.xx 3306
J'obtiens :
telnet: Unable to connect to remote host: Connection refused

Si je tente un
mysql -u nomutilisateur -h xx.xx.xx.xx -p
et que je saisis le mot de passe, j'ai en retour :
ERROR 2003 (HY000): Can't connect to MySQL server on 'xx.xx.xx.xx' (111)

Est-ce que le fait de paramétrer la base comme étant accessible de l'extérieur avec la règle du Firewall ne suffit pas ?
Au niveau de mon my.cnf, j'ai un bind-adress sur 127.0.0.1
Si je le mets sur 0 0 0 0 ou que je la commente, quid de la sécurité ?? N'importe qui va pouvoir se connecter au serveur ?

Quelqu'un aurait il la gentillesse de m'expliquer ce que j'ai raté ?
Merci
Xavier