Je galère depuis pal mal de temps sur ce problème.
Un serveur (slack) avec serveur openssh - pop - smtp (exim)
Un client w32 avec le client mail mozilla - putty.
Je souhaite "sécuriser" l'access au pop et smtp uniquement sur le lan de
mon entreprise.
Firewall activé :
Coté serveur, le port 22 est ouvert et la session ssh fonctionne nickel.
Par contre, impossible d'établir le tunnel :
"connecting to localhost ..." et plus rien alors que par exemple, j'ai
des messages en attente.
Firewall desactivé : le tunnel fonctionne mais le process est très lent.
Cependant, le relevé de mon compte s'opère.
Quelles peuvent en être les raisons ? quels tests simples mettre en
oeuvre pour entrevoir une solution ?
note: ce problème a été posté à l'origine sur fr.comp.securite. Il m'a
été conseillé de poster sur ce newsgroup.
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Dominique Blas
arnaud wrote:
Bonsoir,
Je galère depuis pal mal de temps sur ce problème.
Un serveur (slack) avec serveur openssh - pop - smtp (exim) Un client w32 avec le client mail mozilla - putty.
Je souhaite "sécuriser" l'access au pop et smtp uniquement sur le lan de mon entreprise.
Certes mais s'il faut demander à chaque utilisateur d'établir un tunnel SSH
avant de pouvoir expédier / récupérer son courrier ça va en décourager plus d'un ! Ce serait tout de même mille fois plus simple avec SSL non ? D'autant que les clients de mails incorporent ce type de chiffrement en standard. Faut pas non plus se compliquer la vie sous prétexte de sécurité (un peu mal plaçée dans ce cas). Les tunnels SSH c'est pratique pour sécuriser les échanges X (car il n'y a rien d'autre), pour sécuriser les échanges VNC (car il n'y a rien d'autre et que le VNC est, en général, utlisé par des administrateurs) ou pour tester des services depuis l'extérieur qui ne sont accessibles que depuis l'intérieur. En dehors de ces cas ... bof !
Firewall activé : Coté serveur, le port 22 est ouvert et la session ssh fonctionne nickel. Par contre, impossible d'établir le tunnel : "connecting to localhost ..." et plus rien alors que par exemple, j'ai des messages en attente.
Et le firewall et le serveur ne serait pas la même machine des fois ? Et dans ce cas le firewall n'interdirait pas la connexion au port localhost:pop depuis localhost lui-même des fois ?
Firewall desactivé : le tunnel fonctionne mais le process est très lent. Cependant, le relevé de mon compte s'opère. Problème de compression, de résolution de noms, etc
Quelles peuvent en être les raisons ? quels tests simples mettre en oeuvre pour entrevoir une solution ?
note: ce problème a été posté à l'origine sur fr.comp.securite. Il m'a été conseillé de poster sur ce newsgroup. Si c'est un souci de configuration du tunnel cou du firewall c'est
f.c.securite si c'est un souci de conf du DNS c'est limite ici ou sur f.c.mail.serveurs. Mais comme vraisemblablement il y a un peu des 2 mon coeur balance ...
db
Merci, Arnaud
-- email : usenet blas net
arnaud wrote:
Bonsoir,
Je galère depuis pal mal de temps sur ce problème.
Un serveur (slack) avec serveur openssh - pop - smtp (exim)
Un client w32 avec le client mail mozilla - putty.
Je souhaite "sécuriser" l'access au pop et smtp uniquement sur le lan de
mon entreprise.
Certes mais s'il faut demander à chaque utilisateur d'établir un tunnel SSH
avant de pouvoir expédier / récupérer son courrier ça va en décourager plus
d'un !
Ce serait tout de même mille fois plus simple avec SSL non ? D'autant que
les clients de mails incorporent ce type de chiffrement en standard.
Faut pas non plus se compliquer la vie sous prétexte de sécurité (un peu mal
plaçée dans ce cas).
Les tunnels SSH c'est pratique pour sécuriser les échanges X (car il n'y a
rien d'autre), pour sécuriser les échanges VNC (car il n'y a rien d'autre
et que le VNC est, en général, utlisé par des administrateurs) ou pour
tester des services depuis l'extérieur qui ne sont accessibles que depuis
l'intérieur.
En dehors de ces cas ... bof !
Firewall activé :
Coté serveur, le port 22 est ouvert et la session ssh fonctionne nickel.
Par contre, impossible d'établir le tunnel :
"connecting to localhost ..." et plus rien alors que par exemple, j'ai
des messages en attente.
Et le firewall et le serveur ne serait pas la même machine des fois ?
Et dans ce cas le firewall n'interdirait pas la connexion au port
localhost:pop depuis localhost lui-même des fois ?
Firewall desactivé : le tunnel fonctionne mais le process est très lent.
Cependant, le relevé de mon compte s'opère.
Problème de compression, de résolution de noms, etc
Quelles peuvent en être les raisons ? quels tests simples mettre en
oeuvre pour entrevoir une solution ?
note: ce problème a été posté à l'origine sur fr.comp.securite. Il m'a
été conseillé de poster sur ce newsgroup.
Si c'est un souci de configuration du tunnel cou du firewall c'est
f.c.securite si c'est un souci de conf du DNS c'est limite ici ou sur
f.c.mail.serveurs.
Mais comme vraisemblablement il y a un peu des 2 mon coeur balance ...
Je galère depuis pal mal de temps sur ce problème.
Un serveur (slack) avec serveur openssh - pop - smtp (exim) Un client w32 avec le client mail mozilla - putty.
Je souhaite "sécuriser" l'access au pop et smtp uniquement sur le lan de mon entreprise.
Certes mais s'il faut demander à chaque utilisateur d'établir un tunnel SSH
avant de pouvoir expédier / récupérer son courrier ça va en décourager plus d'un ! Ce serait tout de même mille fois plus simple avec SSL non ? D'autant que les clients de mails incorporent ce type de chiffrement en standard. Faut pas non plus se compliquer la vie sous prétexte de sécurité (un peu mal plaçée dans ce cas). Les tunnels SSH c'est pratique pour sécuriser les échanges X (car il n'y a rien d'autre), pour sécuriser les échanges VNC (car il n'y a rien d'autre et que le VNC est, en général, utlisé par des administrateurs) ou pour tester des services depuis l'extérieur qui ne sont accessibles que depuis l'intérieur. En dehors de ces cas ... bof !
Firewall activé : Coté serveur, le port 22 est ouvert et la session ssh fonctionne nickel. Par contre, impossible d'établir le tunnel : "connecting to localhost ..." et plus rien alors que par exemple, j'ai des messages en attente.
Et le firewall et le serveur ne serait pas la même machine des fois ? Et dans ce cas le firewall n'interdirait pas la connexion au port localhost:pop depuis localhost lui-même des fois ?
Firewall desactivé : le tunnel fonctionne mais le process est très lent. Cependant, le relevé de mon compte s'opère. Problème de compression, de résolution de noms, etc
Quelles peuvent en être les raisons ? quels tests simples mettre en oeuvre pour entrevoir une solution ?
note: ce problème a été posté à l'origine sur fr.comp.securite. Il m'a été conseillé de poster sur ce newsgroup. Si c'est un souci de configuration du tunnel cou du firewall c'est
f.c.securite si c'est un souci de conf du DNS c'est limite ici ou sur f.c.mail.serveurs. Mais comme vraisemblablement il y a un peu des 2 mon coeur balance ...
db
Merci, Arnaud
-- email : usenet blas net
Arnaud
Dominique Blas wrote:
Certes mais s'il faut demander à chaque utilisateur d'établir un tunnel SSH avant de pouvoir expédier / récupérer son courrier ça va en décourager plus d'un !
Ok. disons que c'est pour ma culture personnelle.
Firewall activé : Coté serveur, le port 22 est ouvert et la session ssh fonctionne nickel. Par contre, impossible d'établir le tunnel : "connecting to localhost ..." et plus rien alors que par exemple, j'ai des messages en attente.
Et le firewall et le serveur ne serait pas la même machine des fois ?
Oui. Exim et popa3d tourne sur le firewall.
Et dans ce cas le firewall n'interdirait pas la connexion au port localhost:pop depuis localhost lui-même des fois ?
Argh. J'ai un peu de mal à vous comprendre. Pourriez-vous m'expliquez justement comment se passe la transition de paquets dans le cadre du tunnel ?
Firewall desactivé : le tunnel fonctionne mais le process est très lent. Cependant, le relevé de mon compte s'opère.
Problème de compression, de résolution de noms, etc
La compression ssh est activé dans les 2 sens. J'ai renseigné l'ip du serveur plutôt que le FQDN.
Quelles peuvent en être les raisons ? quels tests simples mettre en oeuvre pour entrevoir une solution ?
note: ce problème a été posté à l'origine sur fr.comp.securite. Il m'a été conseillé de poster sur ce newsgroup.
Si c'est un souci de configuration du tunnel cou du firewall c'est f.c.securite si c'est un souci de conf du DNS c'est limite ici ou sur f.c.mail.serveurs. Mais comme vraisemblablement il y a un peu des 2 mon coeur balance ...
Ce n'est pas un pb de dns.
Arnaud
Dominique Blas wrote:
Certes mais s'il faut demander à chaque utilisateur d'établir un tunnel SSH
avant de pouvoir expédier / récupérer son courrier ça va en décourager plus
d'un !
Ok. disons que c'est pour ma culture personnelle.
Firewall activé :
Coté serveur, le port 22 est ouvert et la session ssh fonctionne nickel.
Par contre, impossible d'établir le tunnel :
"connecting to localhost ..." et plus rien alors que par exemple, j'ai
des messages en attente.
Et le firewall et le serveur ne serait pas la même machine des fois ?
Oui. Exim et popa3d tourne sur le firewall.
Et dans ce cas le firewall n'interdirait pas la connexion au port
localhost:pop depuis localhost lui-même des fois ?
Argh. J'ai un peu de mal à vous comprendre. Pourriez-vous m'expliquez
justement comment se passe la transition de paquets dans le cadre du
tunnel ?
Firewall desactivé : le tunnel fonctionne mais le process est très lent.
Cependant, le relevé de mon compte s'opère.
Problème de compression, de résolution de noms, etc
La compression ssh est activé dans les 2 sens. J'ai renseigné l'ip du
serveur plutôt que le FQDN.
Quelles peuvent en être les raisons ? quels tests simples mettre en
oeuvre pour entrevoir une solution ?
note: ce problème a été posté à l'origine sur fr.comp.securite. Il m'a
été conseillé de poster sur ce newsgroup.
Si c'est un souci de configuration du tunnel cou du firewall c'est
f.c.securite si c'est un souci de conf du DNS c'est limite ici ou sur
f.c.mail.serveurs.
Mais comme vraisemblablement il y a un peu des 2 mon coeur balance ...
Certes mais s'il faut demander à chaque utilisateur d'établir un tunnel SSH avant de pouvoir expédier / récupérer son courrier ça va en décourager plus d'un !
Ok. disons que c'est pour ma culture personnelle.
Firewall activé : Coté serveur, le port 22 est ouvert et la session ssh fonctionne nickel. Par contre, impossible d'établir le tunnel : "connecting to localhost ..." et plus rien alors que par exemple, j'ai des messages en attente.
Et le firewall et le serveur ne serait pas la même machine des fois ?
Oui. Exim et popa3d tourne sur le firewall.
Et dans ce cas le firewall n'interdirait pas la connexion au port localhost:pop depuis localhost lui-même des fois ?
Argh. J'ai un peu de mal à vous comprendre. Pourriez-vous m'expliquez justement comment se passe la transition de paquets dans le cadre du tunnel ?
Firewall desactivé : le tunnel fonctionne mais le process est très lent. Cependant, le relevé de mon compte s'opère.
Problème de compression, de résolution de noms, etc
La compression ssh est activé dans les 2 sens. J'ai renseigné l'ip du serveur plutôt que le FQDN.
Quelles peuvent en être les raisons ? quels tests simples mettre en oeuvre pour entrevoir une solution ?
note: ce problème a été posté à l'origine sur fr.comp.securite. Il m'a été conseillé de poster sur ce newsgroup.
Si c'est un souci de configuration du tunnel cou du firewall c'est f.c.securite si c'est un souci de conf du DNS c'est limite ici ou sur f.c.mail.serveurs. Mais comme vraisemblablement il y a un peu des 2 mon coeur balance ...
Ce n'est pas un pb de dns.
Arnaud
Dominique Blas
[...]
Argh. J'ai un peu de mal à vous comprendre. Pourriez-vous m'expliquez justement comment se passe la transition de paquets dans le cadre du tunnel ? Ben à votre avis ?
Lorsque le paquet tunnelisé sort du tunnel (sur le firewall) etr fait coucou quelle adresse source peut-il bien avoir ?
Firewall desactivé : le tunnel fonctionne mais le process est très lent. Cependant, le relevé de mon compte s'opère.
Problème de compression, de résolution de noms, etc
La compression ssh est activé dans les 2 sens. J'ai renseigné l'ip du serveur plutôt que le FQDN. Qu'est-ce qui est lent exactement au fait ?
Les échanges protocolaires ? (l'intervalle de temps entre le USER, le bla, bla, bla puis le PASS, bla, bla, bla est élevé ?). La récupération du courrier en elle-même ? ET en local comment cela se passe-t-il ?
db
-- email : usenet blas net
[...]
Argh. J'ai un peu de mal à vous comprendre. Pourriez-vous m'expliquez
justement comment se passe la transition de paquets dans le cadre du
tunnel ?
Ben à votre avis ?
Lorsque le paquet tunnelisé sort du tunnel (sur le firewall) etr fait coucou
quelle adresse source peut-il bien avoir ?
Firewall desactivé : le tunnel fonctionne mais le process est très lent.
Cependant, le relevé de mon compte s'opère.
Problème de compression, de résolution de noms, etc
La compression ssh est activé dans les 2 sens. J'ai renseigné l'ip du
serveur plutôt que le FQDN.
Qu'est-ce qui est lent exactement au fait ?
Les échanges protocolaires ? (l'intervalle de temps entre le USER,
le bla, bla, bla puis le PASS, bla, bla, bla est élevé ?).
La récupération du courrier en elle-même ?
ET en local comment cela se passe-t-il ?
Argh. J'ai un peu de mal à vous comprendre. Pourriez-vous m'expliquez justement comment se passe la transition de paquets dans le cadre du tunnel ? Ben à votre avis ?
Lorsque le paquet tunnelisé sort du tunnel (sur le firewall) etr fait coucou quelle adresse source peut-il bien avoir ?
Firewall desactivé : le tunnel fonctionne mais le process est très lent. Cependant, le relevé de mon compte s'opère.
Problème de compression, de résolution de noms, etc
La compression ssh est activé dans les 2 sens. J'ai renseigné l'ip du serveur plutôt que le FQDN. Qu'est-ce qui est lent exactement au fait ?
Les échanges protocolaires ? (l'intervalle de temps entre le USER, le bla, bla, bla puis le PASS, bla, bla, bla est élevé ?). La récupération du courrier en elle-même ? ET en local comment cela se passe-t-il ?
db
-- email : usenet blas net
Dominique Blas
Arnaud wrote:
J'avais pas vu ça dans l'autre ng : $ipt -P INPUT DROP $ipt -P FORWARD DROP ^^^^ C'est con du coup vous n'avez pas accès aux log.
$ipt -P OUTPUT ACCEPT ... # localhost $ipt -A INPUT -i lo -m state --state NEW -s 127.0.0.0/8 -d 127.0.0.0/8 -j ACCEPT Et les paquets non NEW ils font comment ?
Bon, c'est un peu compliqué tout ça hein ? INPUT, FORWARD, les différentes interfaces. Tout ce beau monde est joyeusement mélangé dans un même lot de règles. Quel est l'intérêt de surveiller le FLAG SYN dans un FORWARD par exemple lorsqu'on a affaire à un translateur d'adresses (qui assure ce boulot justement). nous avons bien affaire à un translateur n'est ce pas ? Si c'est le cas, du reste, je n'aperçois pas les règles de translation !
Ensuite, il est intéressant de journaliser ce qui est refusé par le firewall pour, justement, jauger l'efficacité de la règle et éventuellement la sucrer. Ensuite on ne traite pas l'interface externe comme on traite l'interface interne et encore moins comme on s'occupe de l'interface locale. Or, là, tout le monde est au même niveau. Ensuite ESTABLISHED et --syn dans la même ligne ça me choque. Soit on laisse passer les ESTABLISHED (sous-entendu les paquets faisant partie d'une session ouverte dont le flag SYN n'est PAS positionné) et on interdit les SYN ou l'inverse mais interdire les ESTABLISHED qui ont le flag SYN positionné c'est viceux et déjà pris en charge, il me semble, par le mot-clé ESTABLISHED et certainement par le flag INVALID. Ensuite, les règles comprenant les flags FIN,PSH,URG bon, est-ce vraiment utile ? Pourquoi n'avoir pas testé la combinaison SYN,PSH ou FIN, URG ? ET pourquoi, dans ce cas, n'avoir pas considéré les 2 flags ECE et CWR dans les tests (c'est fréquent sur les gros sites [Mcafee par exemple]) ?
Ma position serait de dire : nettoyez-moi tout ça, travaillons par interface et tout ira mieux !
db ... # bad packets for i in INPUT FORWARD do $ipt -A $i -m state --state INVALID -j DROP $ipt -A $i -m state --state ESTABLISHED -p tcp --syn -j DROP $ipt -A $i -m state --state NEW -p tcp ! --syn -j DROP $ipt -A $i -p tcp --tcp-flags ALL SYN,FIN -j DROP $ipt -A $i -p tcp --tcp-flags ALL SYN,PSH,URG -j DROP $ipt -A $i -p tcp --tcp-flags ALL FIN,PSH,URG -j DROP $ipt -A $i -p tcp --tcp-flags ALL NONE -j DROP $ipt -A $i -p tcp --tcp-flags ALL ALL -j DROP done -- email : usenet blas net
Arnaud wrote:
J'avais pas vu ça dans l'autre ng :
$ipt -P INPUT DROP
$ipt -P FORWARD DROP
^^^^
C'est con du coup vous n'avez pas accès aux log.
$ipt -P OUTPUT ACCEPT
...
# localhost
$ipt -A INPUT -i lo -m state --state NEW -s 127.0.0.0/8 -d 127.0.0.0/8
-j ACCEPT
Et les paquets non NEW ils font comment ?
Bon, c'est un peu compliqué tout ça hein ?
INPUT, FORWARD, les différentes interfaces. Tout ce beau monde est
joyeusement mélangé dans un même lot de règles.
Quel est l'intérêt de surveiller le FLAG SYN dans un FORWARD par exemple
lorsqu'on a affaire à un translateur d'adresses (qui assure ce boulot
justement). nous avons bien affaire à un translateur n'est ce pas ?
Si c'est le cas, du reste, je n'aperçois pas les règles de translation !
Ensuite, il est intéressant de journaliser ce qui est refusé par le firewall
pour, justement, jauger l'efficacité de la règle et éventuellement la
sucrer.
Ensuite on ne traite pas l'interface externe comme on traite l'interface
interne et encore moins comme on s'occupe de l'interface locale.
Or, là, tout le monde est au même niveau.
Ensuite ESTABLISHED et --syn dans la même ligne ça me choque. Soit on laisse
passer les ESTABLISHED (sous-entendu les paquets faisant partie d'une
session ouverte dont le flag SYN n'est PAS positionné) et on interdit les
SYN ou l'inverse mais interdire les ESTABLISHED qui ont le flag SYN
positionné c'est viceux et déjà pris en charge, il me semble, par le
mot-clé ESTABLISHED et certainement par le flag INVALID.
Ensuite, les règles comprenant les flags FIN,PSH,URG bon, est-ce vraiment
utile ?
Pourquoi n'avoir pas testé la combinaison SYN,PSH ou FIN, URG ?
ET pourquoi, dans ce cas, n'avoir pas considéré les 2 flags ECE et CWR dans
les tests (c'est fréquent sur les gros sites [Mcafee par exemple]) ?
Ma position serait de dire : nettoyez-moi tout ça, travaillons par interface
et tout ira mieux !
db
...
# bad packets
for i in INPUT FORWARD
do
$ipt -A $i -m state --state INVALID -j DROP
$ipt -A $i -m state --state ESTABLISHED -p tcp --syn -j DROP
$ipt -A $i -m state --state NEW -p tcp ! --syn -j DROP
$ipt -A $i -p tcp --tcp-flags ALL SYN,FIN -j DROP
$ipt -A $i -p tcp --tcp-flags ALL SYN,PSH,URG -j DROP
$ipt -A $i -p tcp --tcp-flags ALL FIN,PSH,URG -j DROP
$ipt -A $i -p tcp --tcp-flags ALL NONE -j DROP
$ipt -A $i -p tcp --tcp-flags ALL ALL -j DROP
done
--
email : usenet blas net
J'avais pas vu ça dans l'autre ng : $ipt -P INPUT DROP $ipt -P FORWARD DROP ^^^^ C'est con du coup vous n'avez pas accès aux log.
$ipt -P OUTPUT ACCEPT ... # localhost $ipt -A INPUT -i lo -m state --state NEW -s 127.0.0.0/8 -d 127.0.0.0/8 -j ACCEPT Et les paquets non NEW ils font comment ?
Bon, c'est un peu compliqué tout ça hein ? INPUT, FORWARD, les différentes interfaces. Tout ce beau monde est joyeusement mélangé dans un même lot de règles. Quel est l'intérêt de surveiller le FLAG SYN dans un FORWARD par exemple lorsqu'on a affaire à un translateur d'adresses (qui assure ce boulot justement). nous avons bien affaire à un translateur n'est ce pas ? Si c'est le cas, du reste, je n'aperçois pas les règles de translation !
Ensuite, il est intéressant de journaliser ce qui est refusé par le firewall pour, justement, jauger l'efficacité de la règle et éventuellement la sucrer. Ensuite on ne traite pas l'interface externe comme on traite l'interface interne et encore moins comme on s'occupe de l'interface locale. Or, là, tout le monde est au même niveau. Ensuite ESTABLISHED et --syn dans la même ligne ça me choque. Soit on laisse passer les ESTABLISHED (sous-entendu les paquets faisant partie d'une session ouverte dont le flag SYN n'est PAS positionné) et on interdit les SYN ou l'inverse mais interdire les ESTABLISHED qui ont le flag SYN positionné c'est viceux et déjà pris en charge, il me semble, par le mot-clé ESTABLISHED et certainement par le flag INVALID. Ensuite, les règles comprenant les flags FIN,PSH,URG bon, est-ce vraiment utile ? Pourquoi n'avoir pas testé la combinaison SYN,PSH ou FIN, URG ? ET pourquoi, dans ce cas, n'avoir pas considéré les 2 flags ECE et CWR dans les tests (c'est fréquent sur les gros sites [Mcafee par exemple]) ?
Ma position serait de dire : nettoyez-moi tout ça, travaillons par interface et tout ira mieux !
db ... # bad packets for i in INPUT FORWARD do $ipt -A $i -m state --state INVALID -j DROP $ipt -A $i -m state --state ESTABLISHED -p tcp --syn -j DROP $ipt -A $i -m state --state NEW -p tcp ! --syn -j DROP $ipt -A $i -p tcp --tcp-flags ALL SYN,FIN -j DROP $ipt -A $i -p tcp --tcp-flags ALL SYN,PSH,URG -j DROP $ipt -A $i -p tcp --tcp-flags ALL FIN,PSH,URG -j DROP $ipt -A $i -p tcp --tcp-flags ALL NONE -j DROP $ipt -A $i -p tcp --tcp-flags ALL ALL -j DROP done -- email : usenet blas net
