Le Fri, 28 May 2004 13:17:27 +0000, root a écrit :
qq1 aurait il une idée pour securiser un accé OUTLOOK WEB ACCESS avec iptables.
À part filtrer les accès au port 80 ou 443 (selon que tu utilises SSL ou non) de la machine hébergeant l'OWA, Netfilter ne pourra pas grand chose pour toi. Si on veut sécuriser une application Web (donc OWA), il faut passer par un reverse-proxy (apache+mod_proxy+mod_rewrite typiquement).
-- BOFH excuse #236:
Fanout dropping voltage too much, try cutting some of those little traces
Le Fri, 28 May 2004 13:17:27 +0000, root a écrit :
qq1 aurait il une idée pour securiser un accé OUTLOOK WEB ACCESS avec
iptables.
À part filtrer les accès au port 80 ou 443 (selon que tu utilises SSL ou
non) de la machine hébergeant l'OWA, Netfilter ne pourra pas grand chose
pour toi. Si on veut sécuriser une application Web (donc OWA), il faut
passer par un reverse-proxy (apache+mod_proxy+mod_rewrite typiquement).
--
BOFH excuse #236:
Fanout dropping voltage too much, try cutting some of those little traces
Le Fri, 28 May 2004 13:17:27 +0000, root a écrit :
qq1 aurait il une idée pour securiser un accé OUTLOOK WEB ACCESS avec iptables.
À part filtrer les accès au port 80 ou 443 (selon que tu utilises SSL ou non) de la machine hébergeant l'OWA, Netfilter ne pourra pas grand chose pour toi. Si on veut sécuriser une application Web (donc OWA), il faut passer par un reverse-proxy (apache+mod_proxy+mod_rewrite typiquement).
-- BOFH excuse #236:
Fanout dropping voltage too much, try cutting some of those little traces
root
OK, Merci pour la reponse. Je suis en ssh. J'utilise un ISA sur la DMZ avec des regles de publication, qui point sur un FRONT sur mon LAN. J'ai un certif pour la liaison internet<->DMZ et un certif pour DMZ<->LAN. Je ne vois pas l'interet de cryter entre la DMZ et LAN. Qu'en pesensez vous ??
Merci
OK,
Merci pour la reponse.
Je suis en ssh. J'utilise un ISA sur la DMZ avec des regles de
publication, qui point sur un FRONT sur mon LAN. J'ai un certif pour la
liaison internet<->DMZ et un certif pour DMZ<->LAN. Je ne vois pas
l'interet de cryter entre la DMZ et LAN.
Qu'en pesensez vous ??
OK, Merci pour la reponse. Je suis en ssh. J'utilise un ISA sur la DMZ avec des regles de publication, qui point sur un FRONT sur mon LAN. J'ai un certif pour la liaison internet<->DMZ et un certif pour DMZ<->LAN. Je ne vois pas l'interet de cryter entre la DMZ et LAN. Qu'en pesensez vous ??
Merci
Patrick MATHEVON
root wrote: :: OK, :: Merci pour la reponse. :: Je suis en ssh. J'utilise un ISA sur la DMZ avec des regles de :: publication, qui point sur un FRONT sur mon LAN. J'ai un certif pour :: la liaison internet<->DMZ et un certif pour DMZ<->LAN. Je ne vois pas :: l'interet de cryter entre la DMZ et LAN. :: Qu'en pesensez vous ??
J'ai tenté pour ma part le setup suivant : - machine avec Exchange 2000 en mode front end, juste OWA. Mon firewall n'autorisant que http et https (redirection automatique si l'utilisateur arrive en http vers la page https) - configuration d'IPSEC pour que les connexions entre OWA et les controleurs d'Active Directory (authentification) et entre OWA et les serveurs Exchange de boites et de dossiers publics se fassent en IPSEC (dans les deux sens) - un firewall n'autorisant que HTTP et HTTPS d'Internet vers l'OWA - deux firewalls entre le LAN et la DMZ
Cette configuration a été un cauchemar. le tunnel IPSEC met trop de temps à monter pour que les services d'Exchange démarrent sur l'OWA. J'ai tenté de mettre une dépendance des services Exchange avec le service IPSEC mais le service IPSEC peut monter sans que les tunnels soient actifs. Il fallait, en cas de reboot de l'OWA, que quelqu'un ouvre une session, ping les DC ou un Exchange 2 ou 3 fois pour que les tunnels soient montés. Apres, on pouvait monter Exchange. Au final, j'ai été obligé de virer IPSEC et d'ouvrir mes deux firewalls intermédiaires sur toute une batterie de ports (DNS, NetBios...).
Mon retour d'experience irait dans le sens de ne pas chiffrer les fluxs DMZ<-->LAN.
Patrick
root wrote:
:: OK,
:: Merci pour la reponse.
:: Je suis en ssh. J'utilise un ISA sur la DMZ avec des regles de
:: publication, qui point sur un FRONT sur mon LAN. J'ai un certif pour
:: la liaison internet<->DMZ et un certif pour DMZ<->LAN. Je ne vois pas
:: l'interet de cryter entre la DMZ et LAN.
:: Qu'en pesensez vous ??
J'ai tenté pour ma part le setup suivant :
- machine avec Exchange 2000 en mode front end, juste OWA. Mon firewall
n'autorisant que http et https (redirection automatique si l'utilisateur
arrive en http vers la page https)
- configuration d'IPSEC pour que les connexions entre OWA et les controleurs
d'Active Directory (authentification) et entre OWA et les serveurs Exchange
de boites et de dossiers publics se fassent en IPSEC (dans les deux sens)
- un firewall n'autorisant que HTTP et HTTPS d'Internet vers l'OWA
- deux firewalls entre le LAN et la DMZ
Cette configuration a été un cauchemar. le tunnel IPSEC met trop de temps à
monter pour que les services d'Exchange démarrent sur l'OWA. J'ai tenté de
mettre une dépendance des services Exchange avec le service IPSEC mais le
service IPSEC peut monter sans que les tunnels soient actifs. Il fallait, en
cas de reboot de l'OWA, que quelqu'un ouvre une session, ping les DC ou un
Exchange 2 ou 3 fois pour que les tunnels soient montés. Apres, on pouvait
monter Exchange.
Au final, j'ai été obligé de virer IPSEC et d'ouvrir mes deux firewalls
intermédiaires sur toute une batterie de ports (DNS, NetBios...).
Mon retour d'experience irait dans le sens de ne pas chiffrer les fluxs
DMZ<-->LAN.
root wrote: :: OK, :: Merci pour la reponse. :: Je suis en ssh. J'utilise un ISA sur la DMZ avec des regles de :: publication, qui point sur un FRONT sur mon LAN. J'ai un certif pour :: la liaison internet<->DMZ et un certif pour DMZ<->LAN. Je ne vois pas :: l'interet de cryter entre la DMZ et LAN. :: Qu'en pesensez vous ??
J'ai tenté pour ma part le setup suivant : - machine avec Exchange 2000 en mode front end, juste OWA. Mon firewall n'autorisant que http et https (redirection automatique si l'utilisateur arrive en http vers la page https) - configuration d'IPSEC pour que les connexions entre OWA et les controleurs d'Active Directory (authentification) et entre OWA et les serveurs Exchange de boites et de dossiers publics se fassent en IPSEC (dans les deux sens) - un firewall n'autorisant que HTTP et HTTPS d'Internet vers l'OWA - deux firewalls entre le LAN et la DMZ
Cette configuration a été un cauchemar. le tunnel IPSEC met trop de temps à monter pour que les services d'Exchange démarrent sur l'OWA. J'ai tenté de mettre une dépendance des services Exchange avec le service IPSEC mais le service IPSEC peut monter sans que les tunnels soient actifs. Il fallait, en cas de reboot de l'OWA, que quelqu'un ouvre une session, ping les DC ou un Exchange 2 ou 3 fois pour que les tunnels soient montés. Apres, on pouvait monter Exchange. Au final, j'ai été obligé de virer IPSEC et d'ouvrir mes deux firewalls intermédiaires sur toute une batterie de ports (DNS, NetBios...).
Mon retour d'experience irait dans le sens de ne pas chiffrer les fluxs DMZ<-->LAN.
Patrick
Djoume SALVETTI
Si on veut sécuriser une application Web (donc OWA), il faut passer par un reverse-proxy (apache+mod_proxy+mod_rewrite typiquement).
Est-ce que tu peux apporter un peu plus de précision sur ce qu'il est possible de sécuriser par ce biais?
-- Djoumé SALVETTI
Si on veut sécuriser une application Web (donc OWA), il faut
passer par un reverse-proxy (apache+mod_proxy+mod_rewrite typiquement).
Est-ce que tu peux apporter un peu plus de précision sur ce qu'il est
possible de sécuriser par ce biais?
Si on veut sécuriser une application Web (donc OWA), il faut passer par un reverse-proxy (apache+mod_proxy+mod_rewrite typiquement).
Est-ce que tu peux apporter un peu plus de précision sur ce qu'il est possible de sécuriser par ce biais?
-- Djoumé SALVETTI
Cedric Blancher
Le Tue, 01 Jun 2004 09:41:24 +0000, Djoume SALVETTI a écrit :
Est-ce que tu peux apporter un peu plus de précision sur ce qu'il est possible de sécuriser par ce biais?
Cela permet de filtrer les requêtes HTTP envoyées au serveur, et donc les paramètres, aux seules requêtes valides et prévenir les attaques Web classiques (SQL injection, XSS, directory traversal, code injection, etc.).
Le Tue, 01 Jun 2004 09:41:24 +0000, Djoume SALVETTI a écrit :
Est-ce que tu peux apporter un peu plus de précision sur ce qu'il est
possible de sécuriser par ce biais?
Cela permet de filtrer les requêtes HTTP envoyées au serveur, et donc
les paramètres, aux seules requêtes valides et prévenir les attaques
Web classiques (SQL injection, XSS, directory traversal, code injection,
etc.).
Le Tue, 01 Jun 2004 09:41:24 +0000, Djoume SALVETTI a écrit :
Est-ce que tu peux apporter un peu plus de précision sur ce qu'il est possible de sécuriser par ce biais?
Cela permet de filtrer les requêtes HTTP envoyées au serveur, et donc les paramètres, aux seules requêtes valides et prévenir les attaques Web classiques (SQL injection, XSS, directory traversal, code injection, etc.).
Le Tue, 01 Jun 2004 09:41:24 +0000, Djoume SALVETTI a écrit :
Est-ce que tu peux apporter un peu plus de précision sur ce qu'il est possible de sécuriser par ce biais?
Cela permet de filtrer les requêtes HTTP envoyées au serveur, et donc les paramètres, aux seules requêtes valides et prévenir les attaques Web classiques (SQL injection, XSS, directory traversal, code injection, etc.).
Merci.
Donc, si j'ai bien compris, en pratique on va filtrer un certain nombre de requetes comme étant connues pour être dangereuse (cas du directory traversal). Mais je vois mal comment on va réellement pouvoir se protéger des injections au niveau du reverse proxy.
-- Djoumé SALVETTI
Le Tue, 01 Jun 2004 09:41:24 +0000, Djoume SALVETTI a écrit :
Est-ce que tu peux apporter un peu plus de précision sur ce qu'il est
possible de sécuriser par ce biais?
Cela permet de filtrer les requêtes HTTP envoyées au serveur, et donc
les paramètres, aux seules requêtes valides et prévenir les attaques
Web classiques (SQL injection, XSS, directory traversal, code injection,
etc.).
Merci.
Donc, si j'ai bien compris, en pratique on va filtrer un certain nombre
de requetes comme étant connues pour être dangereuse (cas du directory
traversal). Mais je vois mal comment on va réellement pouvoir se
protéger des injections au niveau du reverse proxy.
Le Tue, 01 Jun 2004 09:41:24 +0000, Djoume SALVETTI a écrit :
Est-ce que tu peux apporter un peu plus de précision sur ce qu'il est possible de sécuriser par ce biais?
Cela permet de filtrer les requêtes HTTP envoyées au serveur, et donc les paramètres, aux seules requêtes valides et prévenir les attaques Web classiques (SQL injection, XSS, directory traversal, code injection, etc.).
Merci.
Donc, si j'ai bien compris, en pratique on va filtrer un certain nombre de requetes comme étant connues pour être dangereuse (cas du directory traversal). Mais je vois mal comment on va réellement pouvoir se protéger des injections au niveau du reverse proxy.
-- Djoumé SALVETTI
Patrice Auffret
On 01 Jun 2004 11:57:34 GMT Cedric Blancher wrote:
Le Tue, 01 Jun 2004 09:41:24 +0000, Djoume SALVETTI a écrit :
Est-ce que tu peux apporter un peu plus de précision sur ce qu'il est possible de sécuriser par ce biais?
Cela permet de filtrer les requêtes HTTP envoyées au serveur, et donc les paramètres, aux seules requêtes valides et prévenir les attaques Web classiques (SQL injection, XSS, directory traversal, code injection, etc.).
On peut également citer mod_security qui est construit spécifiquement pour se battre contre ces attaques: http://www.modsecurity.org/
On 01 Jun 2004 11:57:34 GMT
Cedric Blancher <blancher@cartel-securite.fr> wrote:
Le Tue, 01 Jun 2004 09:41:24 +0000, Djoume SALVETTI a écrit :
Est-ce que tu peux apporter un peu plus de précision sur ce qu'il est
possible de sécuriser par ce biais?
Cela permet de filtrer les requêtes HTTP envoyées au serveur, et donc
les paramètres, aux seules requêtes valides et prévenir les attaques
Web classiques (SQL injection, XSS, directory traversal, code injection,
etc.).
On peut également citer mod_security qui est construit spécifiquement
pour se battre contre ces attaques:
http://www.modsecurity.org/
On 01 Jun 2004 11:57:34 GMT Cedric Blancher wrote:
Le Tue, 01 Jun 2004 09:41:24 +0000, Djoume SALVETTI a écrit :
Est-ce que tu peux apporter un peu plus de précision sur ce qu'il est possible de sécuriser par ce biais?
Cela permet de filtrer les requêtes HTTP envoyées au serveur, et donc les paramètres, aux seules requêtes valides et prévenir les attaques Web classiques (SQL injection, XSS, directory traversal, code injection, etc.).
On peut également citer mod_security qui est construit spécifiquement pour se battre contre ces attaques: http://www.modsecurity.org/
Bilbo
Bonjour,
qq1 aurait il une idée pour securiser un accé OUTLOOK WEB ACCESS avec iptables.
Merci a tous.
Désolé, je ne réponds pas à ton problème, mais un truc me choque. Tu regardes tes mails en étant loggé sous root ? Même s'il n'existe que très peu de virus pour Linux, c'est un comportement (très) dangereux.
Juste ma petite remarque à 2 centimes...
Bonjour,
qq1 aurait il une idée pour securiser un accé OUTLOOK WEB ACCESS avec
iptables.
Merci a tous.
Désolé, je ne réponds pas à ton problème, mais un truc me choque. Tu
regardes tes mails en étant loggé sous root ? Même s'il n'existe que
très peu de virus pour Linux, c'est un comportement (très) dangereux.
qq1 aurait il une idée pour securiser un accé OUTLOOK WEB ACCESS avec iptables.
Merci a tous.
Désolé, je ne réponds pas à ton problème, mais un truc me choque. Tu regardes tes mails en étant loggé sous root ? Même s'il n'existe que très peu de virus pour Linux, c'est un comportement (très) dangereux.
Juste ma petite remarque à 2 centimes...
Cedric Blancher
Le Tue, 01 Jun 2004 12:47:21 +0000, Djoume SALVETTI a écrit :
Donc, si j'ai bien compris, en pratique on va filtrer un certain nombre de requetes comme étant connues pour être dangereuse (cas du directory traversal).
Non. On ne va laisser passer que les requêtes qui répondent aux schémas autorisés sur le site, et tout ce qui sort de ce schémas, étant à priori une attaque, sera refusé. Par exemple, j'ai un script de login qui accepte deux paramètres en POST, login et passwd. Je vais forcer la vérification du fait que login est une chaîne alphabétique de 8 caractères maximum et que passwd est une chaîne d'au maximum 16 caractères parce que j'ai décidé que ce serait comme clea que seraient formés mes login et mot de passe. Etc.
Mais je vois mal comment on va réellement pouvoir se protéger des injections au niveau du reverse proxy.
Le reverse proxy est chargé de recevoir les requêtes, les décoder (pour les ramener à une forme normale), les filtrer et les proxifier le cas échéant.
-- Alcotest> OUi, mais aussi pour la création des 2 autres ducon, Expliquez moi, pourquoi voulez vous créer deux autres ducon ? Vous vous sentez seul ? -+- FF in Guide du Neuneu sur Usenet - Les deux font l'impair -+-
Le Tue, 01 Jun 2004 12:47:21 +0000, Djoume SALVETTI a écrit :
Donc, si j'ai bien compris, en pratique on va filtrer un certain nombre
de requetes comme étant connues pour être dangereuse (cas du directory
traversal).
Non.
On ne va laisser passer que les requêtes qui répondent aux schémas
autorisés sur le site, et tout ce qui sort de ce schémas, étant à
priori une attaque, sera refusé.
Par exemple, j'ai un script de login qui accepte deux paramètres en POST,
login et passwd. Je vais forcer la vérification du fait que login est une
chaîne alphabétique de 8 caractères maximum et que passwd est une
chaîne d'au maximum 16 caractères parce que j'ai décidé que ce serait
comme clea que seraient formés mes login et mot de passe. Etc.
Mais je vois mal comment on va réellement pouvoir se
protéger des injections au niveau du reverse proxy.
Le reverse proxy est chargé de recevoir les requêtes, les décoder (pour
les ramener à une forme normale), les filtrer et les proxifier le cas
échéant.
--
Alcotest> OUi, mais aussi pour la création des 2 autres ducon,
Expliquez moi, pourquoi voulez vous créer deux autres ducon ?
Vous vous sentez seul ?
-+- FF in Guide du Neuneu sur Usenet - Les deux font l'impair -+-
Le Tue, 01 Jun 2004 12:47:21 +0000, Djoume SALVETTI a écrit :
Donc, si j'ai bien compris, en pratique on va filtrer un certain nombre de requetes comme étant connues pour être dangereuse (cas du directory traversal).
Non. On ne va laisser passer que les requêtes qui répondent aux schémas autorisés sur le site, et tout ce qui sort de ce schémas, étant à priori une attaque, sera refusé. Par exemple, j'ai un script de login qui accepte deux paramètres en POST, login et passwd. Je vais forcer la vérification du fait que login est une chaîne alphabétique de 8 caractères maximum et que passwd est une chaîne d'au maximum 16 caractères parce que j'ai décidé que ce serait comme clea que seraient formés mes login et mot de passe. Etc.
Mais je vois mal comment on va réellement pouvoir se protéger des injections au niveau du reverse proxy.
Le reverse proxy est chargé de recevoir les requêtes, les décoder (pour les ramener à une forme normale), les filtrer et les proxifier le cas échéant.
-- Alcotest> OUi, mais aussi pour la création des 2 autres ducon, Expliquez moi, pourquoi voulez vous créer deux autres ducon ? Vous vous sentez seul ? -+- FF in Guide du Neuneu sur Usenet - Les deux font l'impair -+-
Djoume SALVETTI
On ne va laisser passer que les requêtes qui répondent aux schémas autorisés sur le site, et tout ce qui sort de ce schémas, étant à priori une attaque, sera refusé. Par exemple, j'ai un script de login qui accepte deux paramètres en POST, login et passwd. Je vais forcer la vérification du fait que login est une chaîne alphabétique de 8 caractères maximum et que passwd est une chaîne d'au maximum 16 caractères parce que j'ai décidé que ce serait comme clea que seraient formés mes login et mot de passe. Etc.
Donc il faut configurer le reverse proxy pour chaque application en prennant en compte toutes les variables remplies par l'utilisateur?
Il y a alors autant de boulot que lorsque l'on fait ces controles directement au niveau du code de l'appli non?
-- Djoumé SALVETTI
On ne va laisser passer que les requêtes qui répondent aux schémas
autorisés sur le site, et tout ce qui sort de ce schémas, étant à
priori une attaque, sera refusé.
Par exemple, j'ai un script de login qui accepte deux paramètres en POST,
login et passwd. Je vais forcer la vérification du fait que login est une
chaîne alphabétique de 8 caractères maximum et que passwd est une
chaîne d'au maximum 16 caractères parce que j'ai décidé que ce serait
comme clea que seraient formés mes login et mot de passe. Etc.
Donc il faut configurer le reverse proxy pour chaque application en
prennant en compte toutes les variables remplies par l'utilisateur?
Il y a alors autant de boulot que lorsque l'on fait ces controles
directement au niveau du code de l'appli non?
On ne va laisser passer que les requêtes qui répondent aux schémas autorisés sur le site, et tout ce qui sort de ce schémas, étant à priori une attaque, sera refusé. Par exemple, j'ai un script de login qui accepte deux paramètres en POST, login et passwd. Je vais forcer la vérification du fait que login est une chaîne alphabétique de 8 caractères maximum et que passwd est une chaîne d'au maximum 16 caractères parce que j'ai décidé que ce serait comme clea que seraient formés mes login et mot de passe. Etc.
Donc il faut configurer le reverse proxy pour chaque application en prennant en compte toutes les variables remplies par l'utilisateur?
Il y a alors autant de boulot que lorsque l'on fait ces controles directement au niveau du code de l'appli non?
