Autoriser des domaines via un htaccess

[StephWe]

L'arborescence depuis le dossier root d'apache :
volume1/web/
volume1/web/site1
volume1/web/site2

Liste des hôtes virtuels :
Nom du sous-dossier : site1
Nom d’hôte : www.site1.com
Protocole : HTTP
Port : 80

Nom du sous-dossier : site2
Nom d’hôte : www.site2.com
Protocole : HTTP
Port : 80

Et le tout fonctionne parfaitement. Mais il y a plusieurs problèmes de sécurités.

1. l'adresse IP de la BOX vu de l’extérieur à accès au dossier volume1/web/ et les sous-dossiers.
2.  j’ai un autre nom de domaine www.site3.com ou le VH n’est pas configuré. il a donc accès au dossier volume1/web/ par défaut. Et également aux sous-dossiers des deux autres sites volume1/web/site1 et volume1/web/site2 
3. et jamais deux sans 3, au départ chez mon hébergeur, j’ai modifié les dns de 3 noms de domaine www.site1.com, www.site2.com et www.site3.com pour qu’ils pointent vers mon serveur nas. Ils ont accès au dossier par défaut volume1/web/. Il serait intéressant de bloquer par défaut tous les domaines qui pointent sur mon nas. Et de donnée une autorisation aux 2 domaines www.site1.com et www.site2.com. 

La solution évidente est un .htaccess dans le dossier /volume1/web/

Order deny,allow
Deny from all
Allow from site1.com
Allow from site2.com

Mais pour une raison qui m’échappe, cela ne fonctionne pas.
Il y a uniquement les adresses IP qui sont acceptés.
J'ai également fait le même teste sur mon serveur local (wamp) et pareil.
J'ai regardé la doc et pour que cela fonctionne, ce module doit être actif dans la conf d'apache et c'est le cas :
LoadModule authz_host_module modules/mod_authz_host.so

Si quelqu'un a une piste, je suis tout ouïe 

[Fenrir]

De manière générale, le .htaccess est une salo***rie à fuir dès que possible. Je vois malheureusement plein de produit en mettre partout alors que même apache déconseille de s'en servir (ça bouffe les perf, ça peut compromettre la sécurité, ça limite la portabilité, ...).

Maintenant pour tes problèmes :

1. accès pas IP : mets simplement un fichier d'index à la racine qui redirige par défaut sur le site de ton choix (http 301 par exemple) ou qui affiche une page d'erreur (http 403)
2. site3 : déclare ton vhost pour le site3
3. cf 1

Il n'y a rien de plus à faire coté Syno, ça devrait suffire.

Si tu veux faire plus compliqué, utilise le paquet haproxy.

[StephWe]

Je te remercie pour ta réponse.

Mon bute principal n'est pas de faire du workaround et bien sûr, le paquet haproxy est très certainement ce dont j'ai besoin .
Je débute et c'est mon premier serveur.
Je viens d'installer ceci dans le centre des packets

• Nom : SynoCommunity
• Emplacement : http://packages.synocommunity.com

Ce qui me donne accès à l’installation du paquet haproxy.

Je vais tester cela et revenir par la suite.

Merci pour ton aide.

[Fenrir]

il y a 9 minutes, StephWe a dit :

Mon bute principal n'est pas de faire du workaround

ce n'est pas un workaround ce que je propose (un htaccess c'est un workaround) mais la façon normale de faire, surtout si tu débutes

haproxy c'est pour les besoins plus complexes (mixer des ports et/ou des services et/ou des sous dossiers - sous un ou plusieurs nom).

 

[StephWe]

Oui tout à fait. On est bien d'accord qu'un htaccess n'est pas une solution optimisé pour sécuriser toute un serveur.
Mais n'oublions pas que tu ne m'as pas proposé un htaccess, mais de le fuir  sans me dire pourquoi les ip sont pris en considération et non les domaines.
Je me doutais que l'on pouvait allé plus loin. Avec le paquet haproxy que je ne connaissais pas, c'est peut-être ce que je cherchais. 
Il y a pleins de possibilités. Ce tuto est très intéressant http://www.nas-forum.com/forum/topic/39737-tuto-haproxy-et-regroupement-des-param/.

Et même si je t'ai dis que je débute sur la gestion d'un serveur pro (Je suis Analyst Developer Web et j'ai commencé en 2004), mon esprit va au delà d'une simple application à mettre en place. Je cherche une solution efficace pour sécuriser chaque applications et dossiers sur le serveur sans devoir tout déplacé pour un mauvais choix au départ. Je dois encore comprendre comment tout cela fonctionne pour trouver la solution à mes besoins.

[Fenrir]

Il y a 1 heure, StephWe a dit :

pourquoi les ip sont pris en considération et non les domaines

La manière la plus courante pour orienter les utilisateurs sur différents sites est d'utiliser des VirtualHosts, un virtualhost se sert de la première partie de l'url pour travailler (http://www.site1.com ou http://1.2.3.4), ça ne sécurise pas, ça oriente, en général on ajoute un vhost par défaut qui répond à tout ce qui n'est pas défini (en particulier ce qui vient avec une IP dans l'url). Chez Synology, ce vhost par défaut renvoi sur la racine du dossier web (l'interface du synology ne permet pas de changer le vhost par défaut).

--------------

Si tu cherches une solution type "pro", tu risque d'être vite limité sur un nas (même si on peut faire pas mal de choses avec Docker). En vrac quelques points de bases pour commencer proprement (comme je pense que tu fais du php, je ne parlerai pas des autres techno), ces points concernent les interactions avec le système ou le monde extérieur :

• séparation des privilèges : on ne travail pas en root mais avec des utilisateurs dédiés (si possible un par application/site)
• on ne fait JAMAIS de chmod 777 =>
  • idéalement on fait : chmod -R u=rX,g=,o= DOSSIER
  • au max on fait : chmod -R u=rwX,g=rX,o= DOSSIER
• on règle la sécurité des accès réseau coté serveur (firewall, allow/deny dans les vhost, location, ...)
• on règle l'authentification en utilisant des groupes (même d'un seul utilisateur), idéalement l’authentification est déportée (SAML, RADIUS, LDAP, ..., mais pas sql)
• on ne change pas les comportements du serveur depuis le site (donc pas de htaccess, pas de ini_set, ...)
• apache : une légende raconte que nginx est beaucoup plus rapide qu'apache dès qu'on parle de php, c'est faux, un apache installé correctement est aussi performant que nginx
  • on évite le module php d'apache, il est plus rapide et plus fiable d'utiliser php-fpm (en fast_cgi)
  • on évite le mode rewrite, il est très rarement nécessaire
  • on utilise redirect pour, par exemple, passer de http à https
  • on ne faut pas utiliser d'htaccess, ça bouffe les perf et ça permet de créer des trous de sécurité => AllowOverride none
  • on utilise apache worker ou event, mais pas prefork (qui vient par défaut si on installe le module php d'apache)
  • include c'est bien
  • on sert les fichiers statiques (images, zip, ...) avec le serveur web, pas en php
  • on désactive les modules qui ne servent pas
• nginx :
  • attention aux IF, c'est à éviter sauf à maitriser
  • on évite le mode rewrite, il est très rarement nécessaire
  • on utilise return pour, par exemple, passer de http à https
  • include c'est bien
  • on sert les fichiers statiques (images, zip, ...) avec le serveur web, pas en php, si on veut sécuriser les liens on utilise secure link
  • on désactive les modules qui ne servent pas
• on fait un pool fpm par application/site et on limite open_basedir au strict minimum, idem pour upload_tmp_dir
• on fait attention quand on utilise des "caches" :
  • disque : à régler avec open_basedir et à optimiser avec tmpfs
  • mémoire : que ce soit memcached ou redis, il faut mettre en place et utiliser l’authentification
  • attention aux cookies, par défaut ils sont tous à plat dans le même dossier, on peut les stocker en mémoire ou en base (c'est plus rapide et plus sécurisé)
• pour les bases (sql, ldap, mongodb, ...) il ne faut pas hésiter à créer plusieurs comptes avec des droits différents pour une même application
• on évite les blob
• il n'existe pas que MySQL ou MariaDB, mais aussi Cassandra, CouchDB, Couchbase, ElasticSearch, HBase, MongoDB, PostgreSQL, Redis, Riak ...
• quand on est en mono serveur, il faut privilégier les socket unix aux socket réseaux
• on de met JAMAIS d'ip dans un code, uniquement des fqdn (ou éventuellement localhost)
• on ne défini JAMAIS l'adresse du site dans le code, on utilise les entêtes renvoyés par le serveur HTTP
• on ne doit pas non plus écrire d'url internes absolues (http://www.site/fichier.php), mais uniquement des url relatives (/fichier.php)
• on défini la timezone
• on défini les entête etag et/ou expire, ça fait économiser de la bande passante
• on fait attention à l'encodage (UTF-8 c'est le plus standard)
• on règle les logs :
  • un log par application
  • tout n'a pas vocation à être loguer (un log c'est en général écrit sur disque, donc c'est lent et ça prend de la place)
• ...je t'ai fait cette liste de tête, au travail je fais ou recommande plein d'autres choses, mais je ne suis pas au travail là

[gaetan.cambier]

Il y a 17 heures, Fenrir a dit :

Si tu veux faire plus compliqué, utilise le paquet haproxy.

compliqué ?

si dom1 --> dom1
si dom2 --> dom2

sinon, pour tous les con qui essayé via une autre manière que les domainr donné, on bloque  (on a aussi le tarpit dans haproxy :p)

c pas compliqué c du copier coller à chaque nouveau site :p

[Fenrir]

Il y a 4 heures, gaetan.cambier a dit :

compliqué ?

plus compliqué que ce qu'il demande ...

[StephWe]

En effet ! Pour mes besoins actuel, je voudrais uniquement sécuriser quelque point d'accès.

Pour faire simple, voici ce que je voudrais faire pour débuté sur mon serveur DS716+ DSM 5.2

1. Interdire l'accès aux répertoires Virtualhost par un domaine qui a accès au dossier root d'apache /volume1/web/*.
2. Avoir accès par ssl  à phpMyAdmin

Pouvez-vous m’aiguiller pour y arriver ?

Par la suite, je voudrais installer le serveur node.js Je sais que le serveur node peut être lancé par ssh mais le but est qu'il soit autonome et qu'il puisse se relancer si une erreur survient. Il faudrait qu'un script test si le serveur est HS et le relance si c'est le cas.

Avez-vous une idée comment réaliser ce script ?

Je sais qu'il est possible via le DMS de créer une tache via le Planificateur de tache > Script défini par l'utilisateur.

[Fenrir]

1. fais simplement ce que je t'ai indiqué plus haut :
   • /volume1/web/index.php : redirection vers ton site par défaut pour les utilisateurs qui se sont juste trompés
   • /volume/web/site*/index.php : tu test que le nom de domaine est bien celui attendu (tu refuses http://*/site1/)
2. si tu veux sécuriser, n'installe pas phpmyadmin (ou sécurise à mort son accès) : dans le genre passoire attaquée h24 c'est pas mal
   • sinon, n'utilises pas le paquet phpmyadmin mais installe le comme un autre site (c'est une archive à dézipper)
   • et pour le ssl, c'est comme pour n'importe quel autre site

Pour nodeJS il suffit d'un script qui vérifie que le process tourne (ps | grep ...) et si ce n'est pas le cas qui le relance. Par contre au cas où tu ne serais pas au courant, nodeJS c'est un serveur à part entière, donc il écoute sur un port ...

[StephWe]

Très bien, je vais faire cela.

Avec NodeJS, oui en effet, il faut utiliser un autre port. J'utilise le port 1337 en local http://localhost:1337/socket.io/lib/socket.io.js.

Merci pour tout tes bon conseils.
Je reviens si je rencontre un problème ou si cela fonctionne.

[StephWe]

Re , j'ai un problème pour configurer le virtualhost pour le phpMyAdmin.

Mon premier problème est que je n'ai pas trouvé le dossier ou sont contenues les fichiers server.crt et server.key (Nas DS716+ - DSM 5.2).
Donc provisoirement, j'ai exporté le certificat et j'ai ajouté les deux fichiers dans un répertoire sur le serveur.
J'ai ajouté ceci dans le fichier httpd-vhost.conf-user :

NameVirtualHost	*:443

<VirtualHost *:80>
    ServerName db.site3.com
    Redirect / https://db.site3.com
</VirtualHost>

<VirtualHost *:443>
    ServerName db.site3.com
    DocumentRoot /var/services/web/xxx-xxx/phpMyAdmin-4.5.3.1
    SSLEngine on
    SSLCertificateFile /var/mon_dossier/server.crt
    SSLCertificateKeyFile /var/mon_dossier/server.key
</VirtualHost>

Voici l'erreur après un redémarrage du serveur apache : 
/usr/syno/sbin/synoservicecfg --restart httpd-user
service [httpd-user] restart failed, synoerr=[0x0000]

Et également, ceci ne fonctionne pas : https://192.168.1.xxx:443/xxx-xxx/phpMyAdmin-4.5.3.1/
Il est redirigé vers https://192.168.1.xxx/xxx-xxx/phpMyAdmin-4.5.3.1/ il supprime le port 443 dans l'url et affiche également "Page Web inaccessible" 
Je dois peut-être déjà configurer cela ?

Peux-tu m'éclairer s.t.p

 

[Fenrir]

Pour le certificat, c'est à faire dans l'interface du Syno (panneau de conf/sécurité/certificat) comme indiqué dans l'écran de configuration du Service Web.

Pour ta conf, elle n'est pas valide, elle entre en conflit avec celle du syno, fais le depuis l'interface :

1. Enable Web Station
2. Virtual Host :
   1. phpmyadmin/db.site3.com/http/80
   2. phpmyadmin/db.site3.com/https/443
3. Enable HTTPS connection for web services
4. =>ça fonctionne (je viens de tester)

De manière générale, évite de modifier les fichiers de configuration manuellement, la plupart des fichiers (pas seulement de webstation) sont générés automatiquement et écrasés lors de changements dans l'interface ou au reboot.

[StephWe]

J'ai testé et cela fonctionne pas en https.

J'ai suivi un tuto pour sécurisé via mysql et cela na pas fonctionné.
Est-ce-qu'il pourrait avoir un conflit avec la conf du Syno ?

[Fenrir]

 

[StephWe]

En effet, je croyais avoir coché "Enable HTTPS connection for web services", maintenant c'est le cas.
Ça fonctionne  merci.

J'ai ajouté ceci dans le fichier config.ini.php pour forcer ssl

$cfg['ForceSSL'] = true;

J'ai également une question sur l'accès au DSM via l’extérieur. 
Dans la rubrique Accès externe > DDNS, il est possible d'ajouter un accès par ex. *.synology.me et cela fonctionne très bien mais je voudrais limiter cette connexion à un sous-domaine personnel. Comme il est possible d'avoir accès au DSM via l'IP https://ip_fixe_externe:5001, comment puis-je configurer le DNS de mon sous-domaine pour avoir accès à cette ip_fixe_externe et le port à reprendre dans la configuration  ?

[Fenrir]

Tu t'embrouilles tellement que tu arrives à m'embrouiller avec ta phrase (j'ai du la relire une dizaine de fois)

• Dans ton cas (et dans celui de 99% de la planète), un DNS ça sert à résoudre une IP. (point, rien d'autre, terminé, fin) -> aucun rapport ou lien avec des ports
• Ensuite viennent les ports, ils permettent de tomber sur tel ou tel serveur (web, ftp, ...), tu peux dire à apache d''écouter sur plusieurs ports (80, 81, ...)
• Après tu dis au serveur WEB ce qu'il doit faire des requêtes en fonction de ce qui est écrit dans l'url : c'est le rôle des vhosts

Donc si j'ai bien compris ce que tu souhaites (avoir un site qui écoute sur un port particulier), il faut créer un vhost avec le nom de ce site, qui écoute sur le port choisi

[StephWe]

, Pour éviter que le syno écrase mon vhost fait manuellement, est-ce possible de le faire via le DMS et comment ?

[Fenrir]

Pourquoi tu ne créés pas, via DSM, un vhost avec le nom de domaine en synology.me qui écoute sur le port de ton choix ?

Comme dit plus haut, si tu souhaites faire plus complexe que ce que propose DSM, haproxy est là pour ça (mais ce n'est pas simple à appréhender au début, surtout quand on ne sait pas ce qu'est un reverse proxy).

Comme tu débutes dans ce domaine, je te recommande de faire des choses simples dans un premier temps.

Maintenant si tu veux gérer tes conf à la main, tu peux installer Docker et monter ton propre serveur web+php avec tes fichiers de conf, mais a mon avis le chemin sera long ...

[StephWe]

Le soucis, c'est que je ne connais pas les limites du DSM et de ce que vhost propose. Mes questions doivent te paraître étranges car je ne maîtrise en rien cette logique. Une configuration de base sans sécurité du réseau ma toujours suffit pour le dev en local. Un vhost en local est très simple à mettre en place quand on utilise Wamp serveur. C'est la première fois que je vais aussi loin car je n'ai jamais eu de serveur dédié personnel. C'est l'administrateur système de mon boss qui me prépare le terrain sur les serveurs sur les quels je travailles.

Mais revenons à nos moutons , si je veux que dsm.site3.com sert de sous-domaine, comment je peux le configurer d'une façon simple ?

[Fenrir]

Du point de vue vhost, la limite est simple, c'est ce qui est prévu dans l'interface, c'est à la fois peu et suffisant pour la plupart des besoins. Mais même en tapant directement dans la conf d'Apache, tu ne ferais pas grand chose de plus avec les vhosts.

Il y a 2 heures, StephWe a dit :

si je veux que dsm.site3.com sert de sous-domaine, comment je peux le configurer d'une façon simple ?

Ça dépend de ce que tu appelles "sous domaine" : dsm est un sous domaine de site3 qui est un sous domaine de com qui est sous domaine de "." (la racine)

=> http://www.bortzmeyer.org/parties-nom-domaine.html

Du point de vue apache et vhost, c'est la même chose, il s'en fou du nombre de niveaux, donc techniquement, faire un vhost pour dsm.site3.com c'est comme en faire un pour site3.com ou pour www.perso.synology.maison.ville.dsm.site3.com

=> http://httpd.apache.org/docs/2.4/mod/core.html#virtualhost

[StephWe]

Oui, le processus du vhost avec le dossier associé qui devient le dossier root. Par défaut, le dossier root d'apache sur le syno est /volume1/web. Mais avec le port 5001 (ssl), le dossier root du DSM ce trouve à quel niveau du serveur ? Pour configurer un vhost, il faut connaitre le chemin qui servira ou qui sert de dossier root au vhost.

C'est pour cela que plus haut, je parlais de dns et son type pour utiliser le port 5001 dans une éventuel configuration possible. Car j'imaginais qu'avec l'interface du syno, il était impossible de faire un vhost vers le DSM. https://dsm.site3.com => https://ip_fixe_extern:5001

Sans passer par haproxy, toi tu ferais comment ?

[Fenrir]

http ou https, c'est la même chose pour les vhosts, la racine est au même niveau => c'est toujours le partage "web"

La seule limitation c'est que tu ne peux pas spécifier de vhosts par IP (mais comme ton Syno n'a qu'une IP, ça n'a pas d'importance et n’oublie pas que tu as un nat devant, donc ton apache ne connait pas ton ip public et ne peut rien faire avec) et qu'on ne peut pas changer le vhost par défaut.

Je crois que je n'ai toujours pas compris ce que tu souhaites faire (ou l'utilité de ce que tu veux faire si j'ai bien compris.)

[StephWe]

Pour me connecter de l’extérieur à l'interface du nas, je voudrais utiliser ce domaine https://dsm.site3.com sans utiliser haproxy.
Tu ferais comment ?

Tu ne trouves pas cela utile  ?

[loli71]

Pour la solution la plus simple:

il te suffit donc d'utiliser l'URL https://dsm.site3.com:5001/ , d'activer le port 5001 pour le HTTPS dans l'interface DSM (pour l'accès DSM) et de forwarder le port 5001 externe sur ta box vers le port 5001 de ton syno en interne.

Tu peux aussi choisir un autre port moins connu côté internet (pour plus de sécurité) et le forwarder toujours vers le port 5001 du NAS.

 

Pour une solution plus complexe:

l'utilisation d'un reverse proxy (comme haproxy ou une conf de nginx) est obligatoire si tu veux utiliser uniquement HTTPS sur le port standard 443 et que les redirections dépendent de la première partie du nom FQDN  utilisé dans l'url :

haproxy : http://www.nas-forum.com/forum/topic/39737-tuto-haproxy-et-regroupement-des-param/

nginx : http://www.nas-forum.com/forum/topic/41813-reverse-proxy-avec-nginx/#comment-1319235263