Forum Linux.debian/ubuntu [Résolu] HaProxy - Probleme de transfert de cookies session entre backends (crsf token)

Posté par . Licence CC by-sa.
0
14
juin
2019

Bien le bonjour les troublions du net !

Avec HaProxy j'essaye de dispatcher les requêtes WEBDAV vers 2 backends différents en fonction du type de requêtes.

Ainsi les requêtes de lecture doivent aller vers les serveurs backends cloud_read et les requêtes d'écriture vers les serveurs backends cloud_write.

Voici la config (simplifiée) qui renvoie toutes les requêtes PUT vers cloud_write et tout le reste vers cloud_read :

frontend my_frontend
        bind *:80 v4v6
        bind *:443 v4v6 ssl crt /etc/haproxy/certs/cloud.belgium.com.pem
        http-response set-header Referrer-Policy no-referrer # for privacy, use no-referer or same-origin ;
        mode http
        option httpclose
        option forwardfor
        reqadd X-Forwarded-Proto:\ https
            # Manage your HOSTS here
    acl host_cloud.belgium.com hdr(host) -i cloud.belgium.com
    acl is_cloud_write method PUT MOVE MKCOL
    acl backend_cloud_is_dead nbsrv(cloud_read) lt 1
    use_backend cloud_write if host_cloud.belgium.com is_cloud_write or backend_cloud_is_dead
    use_backend cloud_read if host_cloud.belgium.com !is_cloud_write

backend cloud_read
        mode http
        balance leastconn
        http-request add-header X-Forwarded-Proto https if { ssl_fc }
        option forwardfor
        http-check expect status 204
        option httpchk GET http://cloud.belgium.com/HealthCheck.php HTTP/1.0
        cookie SERVERID insert indirect nocache
        default-server inter 6s fastinter 500 fall 2 rise 2
                #on force https
        acl http      ssl_fc,not
        http-request redirect scheme https if http
    server ClusterNode1.LAN ClusterNode1.LAN:443 weight 1 check cookie ClusterNode1.LAN ssl verify required ca-file /etc/haproxy/certs_ssl_backend/ssl-cert-ClusterNode1.pem
    server ClusterNode1.VPN ClusterNode1.VPN:80 weight 1 check cookie ClusterNode1.VPN backup


backend cloud_write
        mode http
        balance leastconn
        http-request add-header X-Forwarded-Proto https if { ssl_fc }
        option forwardfor
        http-check expect status 204
        option httpchk GET http://cloud.belgium.com/HealthCheck.php HTTP/1.0
        cookie SERVERID insert indirect nocache
        default-server inter 6s fastinter 500 fall 2 rise 2
                #on force https
        acl http      ssl_fc,not
        http-request redirect scheme https if http
    server storageServer.LAN storageServer.LAN:443 weight 1 check cookie storageServer.LAN ssl verify required ca-file /etc/haproxy/certs_ssl_backend/ssl-cert-storageServer.pem
    server storageServer.VPN storageServer.VPN:80 weight 1 check cookie storageServer.VPN backup

Nextcloud annonce un "csrf check not passed" quand on essaye d'uploader un fichier. Le reste semble fonctionnel (mais ne nécessite pas des requêtes qui partent vers les deux backends).

Si je tue tout les serveurs de cloud_read et que toutes les requêtes sans exception sont envoyées sur cloud_write, alors cela fonctionne.

Y a-t-il une solution pour partager les cookies (surtout nc_token) entre les backends ou est-ce un problème insoluble ?

Solution : https://linuxfr.org/forums/linux-debian-ubuntu/posts/resolut-haproxy-probleme-de-transfert-de-cookies-session-entre-backends-crsf-token#comment-1774835

  • # Partager la session et non le cookie

    Posté par (page perso) . Évalué à 5 (+4/-0).

    Ce sont les sessions qu'il faut partager, pas les cookies. Les cookies sont stockés par les clients, et généralement permettent de retrouver une session côté serveur.

    Quand tu as plusieurs serveurs qui potentiellement servent la même session, il faut partager le stockage de session. Tu peux configurer PHP pour faire ça avec Memcached ou Redis.

    • [^] # Re: Partager la session et non le cookie

      Posté par . Évalué à 2 (+1/-0). Dernière modification le 15/06/19 à 00:02.

      Pas mal, problème résolu en passant par un serveur cache Redis. Gros merci ! (merci aussi à digital océan pour leurs tutos)

      1. Désactiver l'utilisation de mot de passe sur votre serveur Redis (commentez la ligne avec requirepass votre_mot_de_passe) et redémarrez ce dernier *1

      2. Éditer /etc/php/*/apache2/php.ini

      3. remplacer session.save_handler = files par session.save_handler = redis

      4. et ajouter session.save_path = "tcp://adresse_serveur_redis:6379" (fortement conseillé de n'écouter que sur une adresse privé (127.0.0.1 via SSH tunneling, ou 10.8.x.x via VPN par exemple)

      *1 si non on chope l'erreur "PHP Fatal error: Uncaught RedisException: NOAUTH Authentication required" car redis demande maintenant que l'authentification se fasse avant la commande, se que ne semble pas permettre PHP à première vue de recherche

      🇪🇺

      • [^] # Re: Partager la session et non le cookie

        Posté par . Évalué à 3 (+1/-0). Dernière modification le 15/06/19 à 10:50.

        Pour info: résolu ne prend pas de "t" : on dit une affaire résolue, pas résolute.

        D'ou vient cette manie de mettre un t à résolu? En plus ça fait tâche sur un titre de forum (dans un commentaire ça reste plus discret).

      • [^] # Re: Partager la session et non le cookie

        Posté par (page perso) . Évalué à 1 (+0/-0).

        Fais attention avec la désactivation du mot de passe, assure-toi bien que personne d'autre ne peut se connecter à ton Redis ! Sinon un attaquant pourrait facilement voler des sessions et accéder aux données de tes utilisateurs.

        • [^] # Re: Partager la session et non le cookie

          Posté par . Évalué à 1 (+0/-0). Dernière modification le 16/06/19 à 14:04.

          Fais attention avec la désactivation du mot de passe

          Oui, cette idée est fort déplaisante. Vivement que PHP corrige ce bug étonnant.

          assure-toi bien que personne d'autre ne peut se connecter à ton Redis

          Redis ne disposant pas d'un système anti-brute-force, avec ou sans mot de passe il est fortement déconseillé d'écouter sur une adresse joignable par autre chose que les clients autorisés :)

          🇪🇺

Envoyer un commentaire

Suivre le flux des commentaires

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