SMPFR

Hello,

Bon, comme d'hab, mes super boss ont acheté un module pour un super logiciel qui tourne sur une machine du LAN et qui n'est pas accessible de l'extérieur.
Ce super module c'est justement pour que des externes puissent faire des inputs dans le logiciel à partir de n’ importe où (vous commencez à voir le problème ???)

Évidement, je suis le dernier au courant, et je viens gaiement d'annoncer a mes boss que ça serait pas possible (raison de sécurité déjà, c'est une appli hyper sensible qu'on a isolé sur le LAN volontairement, et surtout, le port 80 de notre IP publique est déjà natté sur autre chose)

Sauf que voila, comme d'hab c'est démerde toi, on a payé, faut que ça marche.
Pour l'instant, je les ai calmés, la réponse reste non, sauf que si j'arrive à le faire marcher, je pense que les relations actuellement extrêmement tendues entre moi et la direction pour différentes raisons vont se relâcher de manière très significative.

Donc, les contraintes:
Tout passe par le 80 (a moins qu'il y ait encore des choses cachées, aucune doc dispo, appli propriétaire).
Serveur applicatif isolé sur le LAN (firewall pour lui tout seul, seul quelques IP sont autorisés)
Le 80 est déjà NATté vers une autre machine du LAN, et ne peut être modifié (webmail utilisé sur les terminaux mobiles, couper ça serait pire que ne pas faire fonctionner le module)
Tout notre parc (DC, serveur WEB etc.) tourne sur du 2003 sauf le serveur applicatif qui est en 2008, ce qui signifie qu'on a que du IIS6 accessible de l'extérieur. Migration impossible.
Impossible de mettre autre chose que IIS sur le frontal (exit apache donc). IIS soit être sur le 80 (et le 443) pour le webmail (c'est comme ça, pas le choix, c'est du Microsoft )

Solution envisagée:
Proxy ! (pas sur que ce soit la terminologie exacte, je ne suis pas expert dans le domaine)
L’idée est de proxyfier le serveur applicatif sur le serveur WEB frontal de la boite
http://www.toto.com/module -> http://module.local/
Ça me permettrait en passant de rendre accessible certaines parties de l'intranet sur le WEB (pas du tout une contrainte forte mais même problématique)

À partir de la j'ai 2 implémentations possibles:
-- installer un module au IIS (celui la par ex http://iirf.codeplex.com/) sur le serveur WEB frontal pour réécrire les requêtes dans les 2 sens
Du coup, je conserve mon accès webmail sur le serveur lui même et j'ai une "redirection" pour un des vhost
-- faire une VM (j’ai un ESXi avec de la ressource dispo) Linux + apache qui ne fera que proxy, transférer le NAT dessus au lieu du WEB frontal
Du coup je n'ai que des vhost sur la VM qui ne feront que de la "redirection"

Déjà est-ce que ça vous parait correct ?
Ensuite, quelle solution me conseillez-vous ? Perso je serais plus pour la première, ça reste simple et surtout je reste en environnement connu ! Ce qui m'inquiète c'est la robustesse et la charge que ça va induire
En parlant de charge, est-ce que justement ça consomme ? RAM ? CPU ?
Voyez vous des problèmes potentiels ? (autre que le code du module non compatible auquel cas le problème sera vite réglé)

Merci !

PS: j'ai mis "redirection" avec des quottes à chaque fois car ce n'est pas une redirection proprement dite
PS2: le premier qui dit "linux !! windaube c'est de la merde" je demande à kro de la bannir pour pourrissage

niveau securité la deuxieme solution me parrait la mieux. Mais pour les ressources et autre, la premiere est plus propre.
c'est quoi comme type de module? Beaucoup de demandes dessus?

edit; paie ton usine a gaz

non, pas plus de details sur l'outil, dsl....

nombre de demandes, difficielement quantifiable
potentiellement 150 externes mais quasi jamais connectés ensemble.
comme ya pas de doc, difficile de quantifier la quantité de données/requetes qui vont transiter a chaque utilisation

j'ai aussi calmé les boss a ce sujet, la connection internet n'est pas extensible a l'infini (on a deja été obligés d'externaliser le site web publique qui consommait trop de BP)

edit:> niveau ressources, je suis inquiet plus dans le cas de la premiere solution, dans le cas de la seconde, j'ai du CPU et de la RAM dispo en quantité, mais je trouve que ça complexifie plus....

bah pars sur le deuxieme, ça te permettra plus de flexibilité selon moi.
Surout si tu es large niveau machine a cet endroit. C'est plus complexe oui, apres il faut voir niveau configuration. Et vu les infos que tu as sur le module, je serai d'avis de justement essayer de separer au maximum ce merdier du reste qui fonctionne...

j'ai peut être pas tout compris (fortement possible ^^)

mais pk ne pas mettre en place un vpn simple avec openvpn ou consort?

ca t'éviterais de toucher à tes NAT et puis si vous rajoutez un autre service à rendre accessible c'est déjà op

après c'est peut être une grosse connerie ^^

comme Gizmo, et pour le VPN et pour le peut etre pas tout compris
Si ta machine ne doit pas être accessible de l'extérieur, le plus simple est de permettre aux utiliisateurs nomades de faire comme s'ils etaient sur ton LAN.
Le seul bémol à ça seraient qu'ils n'utilisent pas toujours les mêmes moyens de connexion

comme Gizmo, et pour le VPN et pour le peut etre pas tout compris
Si ta machine ne doit pas être accessible de l'extérieur, le plus simple est de permettre aux utiliisateurs nomades de faire comme s'ils etaient sur ton LAN.
[#FF1C00]Le seul bémol à ça seraient qu'ils n'utilisent pas toujours les mêmes moyens de connexion[/#FF1C00]

A part la derniere phrase oui c'est peut etre pas mal...

Tu peux faire une petite VM avec nginx comme reverse proxy, c'est vraiment simple à utiliser.

Tu fais par serveur web une liste des domaines qui doivent être transmis, c'est tout

Doit même y avoir moyen de rajouter un http_auth dans nginx pour protéger certaines applications ! (le truc qu'on fait en général tout dégueulasse avec un .htaccess sous apache)

niet pour le VPN
je vais pas me coltiner 150 demeurés qui n'arriveront pas a le faire marcher.
une page WEB ça marche chez tout le monde, pas de conf a faire.

de plus, je vous rappelle que le but n'est pas de rendre la machine accessible mais bien le module qui s'attaque par du http.
vu la sensibilité du bouzin, hors de question de le mettre en frontal ou de le rendre accessible par quelque moyen que ce soit (VPN) a des noobs qui ne bitent rien a l'info.

bah pars sur le deuxieme, ça te permettra plus de flexibilité selon moi.
Surout si tu es large niveau machine a cet endroit. C'est plus complexe oui, apres il faut voir niveau configuration. Et vu les infos que tu as sur le module, je serai d'avis de justement essayer de separer au maximum ce merdier du reste qui fonctionne...

justement, si je prend la 2eme soluce, je suis obligé de tout changer
NAT pour pointer sur la VM au lieu du IIS actuel
que des vhost sur apache ou autre piour pointer sur l'intranet, le IIS webmail, le module

avec pas mal de chances qu'il y ait des soucis de reecriture sur ce qui marche actuellement.

je sais que j'y met beaucoup de mauvaise volonté, j'essaie juste de voir le pire avant de commencer une implementation plutot qu'une autre, pas envie de perdre du temps, c'est pas le moment (comme je disais, grosses tensions au taf en ce moment)

Tu peux faire une petite VM avec nginx comme reverse proxy, c'est vraiment simple à utiliser.

Tu fais par serveur web une liste des domaines qui doivent être transmis, c'est tout

Doit même y avoir moyen de rajouter un http_auth dans nginx pour protéger certaines applications ! (le truc qu'on fait en général tout dégueulasse avec un .htaccess sous apache)

Code : Tout sélectionner

server { server_name
                dev.bidule.fr
                truc.local
                ;

        location / {
                client_max_body_size 1G;
                proxy_read_timeout 7200;
                proxy_send_timeout 7200;
                proxy_pass http://192.168.x.20/;
                access_log /var/log/nginx/dev.access.log;
        }
}

server { server_name
                machin.truc.com
                machin.local
                ;

        location / {
                client_max_body_size 1G;
                proxy_read_timeout 7200;
                proxy_send_timeout 7200;
                proxy_pass http://192.168.x.10/;
                access_log /var/log/nginx/pre.access.log;
        }
}

c'est ma 2eme solution ça
après qu'est-ce que je vais utiliser, je sais pas encore

niet pour le VPN
je vais pas me coltiner 150 demeurés qui n'arriveront pas a le faire marcher.
une page WEB ça marche chez tout le monde, pas de conf a faire.

de plus, je vous rappelle que le but n'est pas de rendre la machine accessible mais bien le module qui s'attaque par du http.
[#FF0000]vu la sensibilité du bouzin, hors de question de le mettre en frontal ou de le rendre accessible par quelque moyen que ce soit (VPN) a des noobs qui ne bitent rien a l'info.[/#FF0000]

Ouai, te laisse pas bouffer par ce p***in de users quoi

je precise que ces "p***in de users" on un pouvoir de nuisance maximal, gros sous en jeu, d'ou la sensibilité du sujet (aussi bien pour que ça marche de la maniere la plus simple possible, que niveau securité du bouzin)

il y a un truc qui me perturbe (ou alors je n'ai pas tout compris)
Si tu rediriges les requetes depuis ton serveur Web, ça veut dire que tu vas autoriser son adresse IP à passer le firewall de ton application sensible. Si c'est le cas, c'est pas transcendental en matière de sécurité il me semble.(j'ai commencé à lire la doc de iirf.codeplex.com pour comprendre et c'est le premier truc qui m'est apparu)

justement, ce n'est pas de la redirection mais un reverse proxy.
je suis pas non plus très calé sur le sujet mais de ce que j'ai compris:
-- WEB envoie une requete au proxy
-- proxy reecrit la requete et l'envoi a l'intranet
-- l'intranet repond, le proxy fait la reecriture inverse
-- le proxy repond au WEB

de cette maniere, je peux autoriser que le proxy sur le firewall , pas besoin d'autoriser la terre entiere (ce que je ne veux pas faire)

http://cheeso.members.winisp.net/Iirf21 ... m#Section5 "Proxy requests based on the Hostname"

la diff entre rewrite/rpoxy/redirect ici: http://cheeso.members.winisp.net/Iirf21Help/frames.htm

De ce que j'ai pu tester, le reverse proxy est totalement transparent. Les seuls problèmes que j'ai eu c'est pour les requêtes en POST de plusieurs Mo ou les temps d'attente. Dans la config de NGINX que j'ai posté au-dessus les problèmes sont résolus.

yaura peu de données en entrée
seulmeent qq chiffres/cases a cocher
yara certainement plus de consommation en sortie (LAN -> WEB) avec des joli ecrans "ki servent a rien mais ça plait a celui ki y connait rien"

bon j'ai testé IIRF.

deja ça part mal, il supporte pas l'authentification NTLM, donc c mort pour l'intranet.

concernant le but premier, ça se passe mal aussi.
le module est codé avec des chemins absolus, genre /toto/tata.html, qui ne sont donc pas reecris par le reverse proxy (c'est pas une URL mais juste le chemin)

je vais donc tester vite fait avec autre chose, si ça bute sur le meme problème (ce dont je ne doute pas) => je laisse tomber, et tant pis.

je viens de regarder nginx, supporte pas non plus NTLM

edit: bon, ça va calmer les ardeurs de certains :
http://board.issociate.de/thread/485380 ... rvers.html

NTLM isn't a legitimate HTTP authentication protocol, it's a point to
point connection oriented protocol, while HTTP is a stateless protocol.

So in short, it cannot be proxied.

Y a un module Apache http://modntlm.sourceforge.net/

Par contre Apache en reverse proxy, c'est un petit peu plus compliqué que nginx ^^

le module apache c'est pour l'authentification sur le serveur web, pas en reverse proxy

je suis en train de regarder squid, il a l'air de laisser passer le NTLM

apparement, squid 3.2 supporte http 1.1 et l'autehntification NTLM en reverse (necessite HTTP 1.1)

donc je vais tester ça vendredi

Squid fait aussi du reverse PROXY même si Apache le fait très bien.
L'avantage d'apache c'est le mod sécurity

Et ça reste une solution fiable, et qui pourrait par la suite te permettre de déployer d'autre application sur le port 80 en jouant sur les URL.

Apache a été écarté, pas de support du ntlm en reverse proxy

Le seul que j'ai trouve est squid pour l'instant

Je l'avais testé en prod pour un OWA ça fonctionnait sans problème

(l'authentification restait porte sur l'OWA)