Contenu | Rechercher | Menus

Annonce

Si vous rencontrez des soucis à rester connecté sur le forum (ou si vous avez perdu votre mot de passe) déconnectez-vous et reconnectez-vous depuis cette page, en cochant la case "Me connecter automatiquement lors de mes prochaines visites".
Test de l'ISO d'Ubuntu francophone : nous avons besoin de testeurs pour la version francophone d'Ubuntu 14.04. Liens et informations ici.

Attention, une faille de sécurité dans bash a récemment été rapportée, il est recommandé de mettre à jour son système (plus de détails)

#1 Le 29/01/2013, à 01:44

hebus

Sécurité - Log phpmyadmin ( serveur nginx )

Bonjour à tous,

Je replonge les mains dans le cambouis et dans l'administration système ! Mais voilà : je bloque et j'ai besoin d'un coup de réflexion partagée, il doit y avoir un endroit où je ne regarde pas ... bref je poste !

Je tente de "sécuriser" un hébergement.
Pour empêcher les brute-force sur phpmyadmin je souhaitais mettre en place un fail2ban mais les logs du serveur ne montrent aucune trace des tentatives de connexions infructueuses. Cela fait 48 heures que je cherche mais je suis à court de pistes !

Des idées ? De la doc à me conseiller ?

Config : Ubuntu 12.04, nginx, php-fpm, ufw
Les access et error logs sont dirigés vers des fichiers précis pour chaque vhosts, en permissions 644 ( j'ai tenté un changement en 777 pour tester mais cela n'a rien donné ), on voit passer certains phpmyadmin ( des GET par exemple ).

Je prends toutes les idées merci smile

Hors ligne

#2 Le 29/01/2013, à 10:35

mazarini

Re : Sécurité - Log phpmyadmin ( serveur nginx )

Les recherches de l'url de phpmyadmin génèrent des erreur 404 dans les log d'erreur.
Par contre, une fois l'url trouvée, les tentatives de connexion sont gérées via php et ne génèrent pas d'erreur. Tu peux rechercher la gestion de la connexion dans et ajouter l'écriture dans un fichier de log que fail2ban par exemple pourra surveiller.
Je ne sais pas si l'ajout d'une protection par htpasswd permet de générer des logs pouvant être exploitée par fail2ban simplement.


Je suis désolé de t'avoir blessé en te traitant de con. Je croyais que tu le savais déjà...

Hors ligne

#3 Le 29/01/2013, à 10:53

tiramiseb

Re : Sécurité - Log phpmyadmin ( serveur nginx )

Je te conseille :

- soit de limiter les droits vers le répertoire phpmyadmin à une ou deux adresses IP sources particulières (celle(s) du/des admin(s) de la base)
- soit de désinstaller totalement phpmyadmin


Sébastien Maccagnoni-Munch - administrateur Linux depuis le XXe siècle
Consultant informatique indépendant - http://www.smm-informatique.fr
Geek et tout plein d'autres choses - http://www.tiramiseb.fr

Hors ligne

#4 Le 29/01/2013, à 11:03

mazarini

Re : Sécurité - Log phpmyadmin ( serveur nginx )

tiramiseb a écrit :

...
- soit de désinstaller totalement phpmyadmin

Une solution moins radicale, désactiver/activer phpmyadmin en modifiant l'extension du nom de fichier /ets/apache2/mods/phpmyadmin.conf (j'ai un doute sur "mods")
Penser à faire un reload de la configuration après modification.


Je suis désolé de t'avoir blessé en te traitant de con. Je croyais que tu le savais déjà...

Hors ligne

#5 Le 29/01/2013, à 12:25

bruno

Re : Sécurité - Log phpmyadmin ( serveur nginx )

Effectivement ce n'est pas dans « mods ». Phpmyadmin n'est pas un module Apache, mais un lien symbolique : /etc/apache2/conf.d/phpmymyadmin.conf qui pointe vers /etc/phpmyadmin/apache.conf contient les directives apache pour accéder à phpmyadmin.

Pour limiter les attaques brute force sur phpmyadmin on peut utiliser ce fichier pour limiter l'accès à certaines IP comme suggéré plus haut et en profiter pour renommer le dossier d'accès en remplaçant :

Alias /phpmyadmin /usr/share/phpmyadmin

par un truc du genre

Alias /maillesquioule /usr/share/phpmyadmin

wink

Hors ligne

#6 Le 29/01/2013, à 12:29

tiramiseb

Re : Sécurité - Log phpmyadmin ( serveur nginx )

mazarini a écrit :
tiramiseb a écrit :

...
- soit de désinstaller totalement phpmyadmin

Une solution moins radicale[...]

Je suis de ceux qui trouvent ce logiciel totalement inutile (surtout sur un serveur de prod'), donc je n'ai en effet pas proposé de solution "moins radicale" permettant de seulement le désactiver.


La limitation par adresse IP reste parmi les solutions les plus sécurisées.


bruno a écrit :
Alias /maillesquioule /usr/share/phpmyadmin

C'est un peu de la sécurité par l'obscurité, ce que tu proposes... smile
http://fr.wikipedia.org/wiki/S%C3%A9cur … urit%C3%A9

Si la limitation par adresse IP est en place, bah je doute que cela apporte grand chose de plus...


Sébastien Maccagnoni-Munch - administrateur Linux depuis le XXe siècle
Consultant informatique indépendant - http://www.smm-informatique.fr
Geek et tout plein d'autres choses - http://www.tiramiseb.fr

Hors ligne

#7 Le 29/01/2013, à 13:23

hebus

Re : Sécurité - Log phpmyadmin ( serveur nginx )

Merci pour les réponses !
Je suis de l'autre côté de l'atlantique je réponds avec le décalage !

Alors les pistes sont pas mal, tant que j'ai pas des logs clairs à faire analyser à fail2ban je le désactive effectivement.
En revanche je ne tourne pas avec apache, c'était un peu cela le challenge je me suis mis sous NginX en solo  ( pas en proxy ). Donc pas de fichier .ht à ma connaissance !
Je pense que mes logs qui posent problème viennent peu être du fait que nginx et phpmyadmin ne sont pas encore les meilleurs amis du monde ! Je regarde du côté de Adminer en ce moment pour pallier à cela.

Le filtrage d'une seule ip me plait assez comme idée, mais en cas de déplacement .... je dois changer.

@Tiramiseb je te rejoins assez sur l'idée que ce prog ne m'est pas nécessaire au quotidien. Les sites que j'héberge vont rarement avoir un soucis dans la base. C'est plus lors du passage dev - prod que je vais devoir m'en servir. Mais une fois de plus je peux bloquer sur une ip et activer le temps des modifs.

@mazarini peux tu m'en dire plus sur la gestion de la connection en php ? Cette piste me plait aussi, faire un petit script qui te remplit un log.

En revanche là où je comprends pas c'est que j'ai pas mal cherché et j'ai pas trouvé de personnes qui avaient la même galère, je me dis que j'ai du raté un bout quelque part.

Merci encore, ca relance bien ! Bien utile des regards neufs sur la situation.

Je reste ouvert aux propositions encore un peu, je trancherai après et je [ résolurai ].

ps : les edits c'est l'orthographe, 6h du mat j'ai pas fini mon premier café, mea culpa.

@Bruno : j'aime bien ta technique de sioux et nginx fonctionne à peu prêt pareil qu'Apache à ce niveau là donc un chemin /aliaskikouloldelamort dans le vhost me fait à la fois sourire et laisse une piste intéressante aussi. Je me dit que celui qui rentre par là l'aura mérité ! wink

Dernière modification par hebus (Le 29/01/2013, à 13:32)

Hors ligne

#8 Le 29/01/2013, à 13:32

tiramiseb

Re : Sécurité - Log phpmyadmin ( serveur nginx )

Donc pas de fichier .ht à ma connaissance !

Et alors ?
Les fichiers ".htaccess" et tout ça ce n'est que pour pallier le fait qu'on n'a pas accès à la configuration d'Apache !
Quand on a accès à la configuration du serveur web, ces fichiers sont de toute façon à éviter.

Le filtrage d'une seule ip me plait assez comme idée, mais en cas de déplacement .... je dois changer.

Oui, cela nécessite d'avoir une IP fixe (ou d'utiliser un proxy avec authentification smile ... mais bon ce n'est pas la panacée).

C'est plus lors du passage dev - prod que je vais devoir m'en servir.

Et pour ces rares fois, tu ne peux pas utiliser le client MySQL en ligne de commande ?

Mais une fois de plus je peux bloquer sur une ip et activer le temps des modifs.

Bah si tu l'active l'espace de quelques minutes le risque est vachement limité, et si tu as des adresses IP changeantes alors le blocage par IP risque de t'emmerder plus qu'autre chose.

En revanche là où je comprends pas c'est que j'ai pas mal cherché et j'ai pas trouvé de personnes qui avaient la même galère, je me dis que j'ai du raté un bout quelque part.

Car la plupart des gens ne sécurisent pas leurs outils. Et se plaignent quand ils se font pirater.

Dernière modification par tiramiseb (Le 29/01/2013, à 13:32)


Sébastien Maccagnoni-Munch - administrateur Linux depuis le XXe siècle
Consultant informatique indépendant - http://www.smm-informatique.fr
Geek et tout plein d'autres choses - http://www.tiramiseb.fr

Hors ligne

#9 Le 29/01/2013, à 13:39

hebus

Re : Sécurité - Log phpmyadmin ( serveur nginx )

@tiramiseb je te suis pas sur les .ht. Ne sont ils pas utilisés seulement par Apache comme serveur ? Pour la ligne de commande tu as raison c'est jouable mais je dois avouer ma fainéantise ( tu noteras que je préfère lire de la doc et tenter de sécuriser que de passer par là ! .... GUI mon gourou wink ). Je suis bien d'accord avec ta dernière remarque. Pourtant je trouve cela assez fascinant la sécurité et cela "selon mon avis" te fais comprendre pas mal le fonctionnement du serveur. L'activation et la désactivation me tente assez effectivement sachant que la config de Nginx te permet un reload à chaud des vhosts et du fichier de config donc pas de coupure de service. ( Je ne sais pas si je peux faire un test avant reload mais cela devrait être jouable ).

Hors ligne

#10 Le 29/01/2013, à 13:44

tiramiseb

Re : Sécurité - Log phpmyadmin ( serveur nginx )

je te suis pas sur les .ht. Ne sont ils pas utilisés seulement par Apache comme serveur ?

C'est possible qu'ils ne soient utilisés que sur Apache.
Mais de toute façon, les ".htaccess" et compagnie sont là pour contourner le fait qu'on ne peut pas modifier la configuration du serveur web (pour un hébergement mutualisé par exemple).
Quand on a accès à la configuration d'Apache, on n'utilise pas de .htmachin, on met tout dans la configuration d'Apache.
Les .httruc réduisent les performances d'Apache.
Donc même si tu avais Apache, tu n'utiliserais pas de .htbidule...


Pour la ligne de commande tu as raison c'est jouable mais je dois avouer ma fainéantise

Moi j'avoue ma fainéantise d'installer et utiliser une interface web.
On me file un dump sql, je tape "mysql < fichier.dump" et basta ! C'est plus rapide que de cliqueter dans une interface web smile


Sébastien Maccagnoni-Munch - administrateur Linux depuis le XXe siècle
Consultant informatique indépendant - http://www.smm-informatique.fr
Geek et tout plein d'autres choses - http://www.tiramiseb.fr

Hors ligne

#11 Le 29/01/2013, à 14:23

mazarini

Re : Sécurité - Log phpmyadmin ( serveur nginx )

Le problème des .htaccess, c'est qu'ils sont interprétés à chaque appel d'une page. Comme ils sont valable dans les sous-répertoires, apache doit les rechercher depuis le répertoire courant jusqu'au répertoire racine du site et les interpréter.

On a tout intérêt lorsque l'on gère un serveur entièrement à intégrer le contenu des fichiers .htaccess dans la configuration d'apache pour que ce soit interprété qu'au démarrage ou au rechargement de la config. Il faut également désactiver la prise en compte des .htaccess pour qu'ils ne soit pas recherchés.

Pour ce qui est de faire une log via le php, il faut retrouver l'endroit ou est vérifier la saisie du user/mot de passe dans phpmyadmin et écrire dans un fichier l'ip du demandeur (à minima) en cas de mauvaise saisie. Reste ensuite à paramétrer un filtre pour extraire l'adresse IP pour que fail2ban fasse son boulot. Le principal problème est qu'il faudra refaire le travail en partie à chaque mise à jour de phpmyadmin (vite chiant).

Autrement, il y a un package : knockd (je crois) qui permet de lancer une commande suite à l'envoi d'une serie de paquets sur des ports. La suite des protocoles (tcp/upd) et des numéros de port forme un mot de passe. Ca peut te permettre de lancer un script pour activer/désactiver phpmyadmin. Perso, je m'en sers pour ouvrir le port 22 quelques secondes sur l'adresse envoyant les paquets pour me connecter en ssh.
Ca donne :

knock 123 1233 1232 321 3212 && ssh zerzrze@domaine.com

knock est la partie client, mais peut être remplacée par n'importe quel utilitaire permettant d'envoyer des paquets tcp ou udp


Je suis désolé de t'avoir blessé en te traitant de con. Je croyais que tu le savais déjà...

Hors ligne

Haut de page ↑