Un serveur (slack) avec serveur openssh - pop - smtp
Un client w32 avec le client mail mozilla - putty.
Je souhaite donc "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 !
Firewall désactivé :
Le tunnel fonctionne mais le relevé et l'envoi sont atrocement longs.
J'ajoute que le firewall est statefull. voici brievement les regles
mises en place :
$ipt -P INPUT DROP
$ipt -P FORWARD DROP
$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
...
# 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
# [conntrack]
for i in INPUT FORWARD
do
$ipt -A $i -m state --state ESTABLISHED -p tcp ! --syn -j ACCEPT
$ipt -A $i -m state --state ESTABLISHED -p udp -j ACCEPT
$ipt -A $i -m state --state RELATED -p icmp -j ACCEPT
done
# --- [INPUT]
# [eth0] guardian = 192.168.0.X
$ipt -A INPUT -i eth0 -m state --state NEW -p tcp --syn --sport 1024: -m
multiport --dports 22,80,53,139,3306 -s $lan -d $guardian -j ACCEPT
$ipt -A INPUT -i eth0 -m state --state NEW -p udp --sport 1024: -m
multiport --dports 53,137,138 -s $lan -d $guardian -j ACCEPT
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
Etienne de Tocqueville
Arnaud a écrit sur fr.comp.securite :
Firewall activé : Coté serveur, le port 22 est ouvert et la session ssh fonctionne nickel. Par contre, impossible d'établir le tunnel !
Si la session ssh fonctionne bien avec le firewall, je ne vois pas comment le tunnel peut ne pas fonctionner, puisque la connexion se fait alors sur localhost (ou tout du moins sur une machine du même coté du firewall).
D'après moi, le problème ne vient pas d'un problème de configuration du firewall, mais d'un problème de création ou d'utilisation du tunnel... Si tel est le cas, il faudrait donc plutôt voir ça sur fr.comp.reseaux.ip
Etienne
Arnaud <arnaud.lacroix@voila.fr> a écrit sur fr.comp.securite :
Firewall activé :
Coté serveur, le port 22 est ouvert et la session ssh fonctionne nickel.
Par contre, impossible d'établir le tunnel !
Si la session ssh fonctionne bien avec le firewall, je ne vois pas
comment le tunnel peut ne pas fonctionner, puisque la connexion se fait
alors sur localhost (ou tout du moins sur une machine du même coté du
firewall).
D'après moi, le problème ne vient pas d'un problème de configuration du
firewall, mais d'un problème de création ou d'utilisation du
tunnel... Si tel est le cas, il faudrait donc plutôt voir ça sur
fr.comp.reseaux.ip
Firewall activé : Coté serveur, le port 22 est ouvert et la session ssh fonctionne nickel. Par contre, impossible d'établir le tunnel !
Si la session ssh fonctionne bien avec le firewall, je ne vois pas comment le tunnel peut ne pas fonctionner, puisque la connexion se fait alors sur localhost (ou tout du moins sur une machine du même coté du firewall).
D'après moi, le problème ne vient pas d'un problème de configuration du firewall, mais d'un problème de création ou d'utilisation du tunnel... Si tel est le cas, il faudrait donc plutôt voir ça sur fr.comp.reseaux.ip
Etienne
T0t0
"Etienne de Tocqueville" <et+ wrote in message news:
Si la session ssh fonctionne bien avec le firewall, je ne vois pas comment le tunnel peut ne pas fonctionner, puisque la connexion se fait alors sur localhost (ou tout du moins sur une machine du même coté du firewall).
Dans les règles on voit l'autorisation pour les paquets NEW mais pas ESTABLISHED ou RELATED pour lo, la règle a juste été zappée ou elle n'existe pas ?
D'après moi, le problème ne vient pas d'un problème de configuration du firewall, mais d'un problème de création ou d'utilisation du tunnel... Si tel est le cas, il faudrait donc plutôt voir ça sur fr.comp.reseaux.ip
Il faudrait voir quelle est la commande SSH donnée pour lancer le tunnel.
-- Posted via Mailgate.ORG Server - http://www.Mailgate.ORG
"Etienne de Tocqueville" <et+news@steph.teaser.fr> wrote in message
news:x78yaupj2l.fsf@steph.teaser.fr
Si la session ssh fonctionne bien avec le firewall, je ne vois pas
comment le tunnel peut ne pas fonctionner, puisque la connexion se fait
alors sur localhost (ou tout du moins sur une machine du même coté du
firewall).
Dans les règles on voit l'autorisation pour les paquets NEW mais pas
ESTABLISHED ou RELATED pour lo, la règle a juste été zappée ou elle
n'existe pas ?
D'après moi, le problème ne vient pas d'un problème de configuration du
firewall, mais d'un problème de création ou d'utilisation du
tunnel... Si tel est le cas, il faudrait donc plutôt voir ça sur
fr.comp.reseaux.ip
Il faudrait voir quelle est la commande SSH donnée pour lancer le
tunnel.
--
Posted via Mailgate.ORG Server - http://www.Mailgate.ORG
"Etienne de Tocqueville" <et+ wrote in message news:
Si la session ssh fonctionne bien avec le firewall, je ne vois pas comment le tunnel peut ne pas fonctionner, puisque la connexion se fait alors sur localhost (ou tout du moins sur une machine du même coté du firewall).
Dans les règles on voit l'autorisation pour les paquets NEW mais pas ESTABLISHED ou RELATED pour lo, la règle a juste été zappée ou elle n'existe pas ?
D'après moi, le problème ne vient pas d'un problème de configuration du firewall, mais d'un problème de création ou d'utilisation du tunnel... Si tel est le cas, il faudrait donc plutôt voir ça sur fr.comp.reseaux.ip
Il faudrait voir quelle est la commande SSH donnée pour lancer le tunnel.
-- Posted via Mailgate.ORG Server - http://www.Mailgate.ORG
arnaud
T0t0 wrote:
Dans les règles on voit l'autorisation pour les paquets NEW mais pas ESTABLISHED ou RELATED pour lo, la règle a juste été zappée ou elle n'existe pas ?
D'après moi, le problème ne vient pas d'un problème de configuration du firewall, mais d'un problème de création ou d'utilisation du tunnel... Si tel est le cas, il faudrait donc plutôt voir ça sur fr.comp.reseaux.ip
Il faudrait voir quelle est la commande SSH donnée pour lancer le tunnel.
Le tunnel est créer par l'intérmédiaire de putty.
Prenons l'exemple de l'access au smtp.
dans mozilla : serveur : localhost port 25
Le tunnel putty est donc configurer comme suit : local port : 25 remote : 192.168.0.1:25
Evidemment, je suis contraint d'initier une session ssh pour que le tunnel fonctionne.
Dans le doute, je vous donne mes règles de firewalling :
.... # default police. $ipt -P INPUT DROP $ipt -P FORWARD DROP $ipt -P OUTPUT ACCEPT
# [localhost] $ipt -A INPUT -i lo -m state --state NEW,ESTABLISHED -s 127.0.0.0/8 -d 127.0.0.0/8 -j ACCEPT
# [bad packets]
$ipt -t nat -A PREROUTING -i eth1 -s 192.168.0.0/16 -j DROP $ipt -t nat -A PREROUTING -i eth1 -s 172.16.0.0/12 -j DROP $ipt -t nat -A PREROUTING -i eth1 -s 10.0.0.0/8 -j DROP
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
# [conntrack] for i in INPUT FORWARD do $ipt -A $i -m state --state ESTABLISHED -p tcp ! --syn -j ACCEPT $ipt -A $i -m state --state ESTABLISHED -p udp -j ACCEPT $ipt -A $i -m state --state RELATED -p icmp -j ACCEPT done
# --- [INPUT]
# [eth0] guardian = 192.168.0.1 $ipt -A INPUT -i eth0 -m state --state NEW -p tcp --syn --sport 1024: -m multiport --dports 22,80,53,139,3306 -s $lan -d $guardian -j ACCEPT $ipt -A INPUT -i eth0 -m state --state NEW -p udp --sport 1024: -m multiport --dports 53,137,138 -s $lan -d $guardian -j ACCEPT $ipt -A INPUT -i eth0 -p udp --sport 68 --dport 67 -j ACCEPT
... ...
Par avance merci, Arnaud
T0t0 wrote:
Dans les règles on voit l'autorisation pour les paquets NEW mais pas
ESTABLISHED ou RELATED pour lo, la règle a juste été zappée ou elle
n'existe pas ?
D'après moi, le problème ne vient pas d'un problème de configuration du
firewall, mais d'un problème de création ou d'utilisation du
tunnel... Si tel est le cas, il faudrait donc plutôt voir ça sur
fr.comp.reseaux.ip
Il faudrait voir quelle est la commande SSH donnée pour lancer le
tunnel.
Le tunnel est créer par l'intérmédiaire de putty.
Prenons l'exemple de l'access au smtp.
dans mozilla :
serveur : localhost
port 25
Le tunnel putty est donc configurer comme suit :
local port : 25
remote : 192.168.0.1:25
Evidemment, je suis contraint d'initier une session ssh pour que le
tunnel fonctionne.
Dans le doute, je vous donne mes règles de firewalling :
....
# default police.
$ipt -P INPUT DROP
$ipt -P FORWARD DROP
$ipt -P OUTPUT ACCEPT
# [localhost]
$ipt -A INPUT -i lo -m state --state NEW,ESTABLISHED -s 127.0.0.0/8 -d
127.0.0.0/8 -j ACCEPT
# [bad packets]
$ipt -t nat -A PREROUTING -i eth1 -s 192.168.0.0/16 -j DROP
$ipt -t nat -A PREROUTING -i eth1 -s 172.16.0.0/12 -j DROP
$ipt -t nat -A PREROUTING -i eth1 -s 10.0.0.0/8 -j DROP
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
# [conntrack]
for i in INPUT FORWARD
do
$ipt -A $i -m state --state ESTABLISHED -p tcp ! --syn -j ACCEPT
$ipt -A $i -m state --state ESTABLISHED -p udp -j ACCEPT
$ipt -A $i -m state --state RELATED -p icmp -j ACCEPT
done
# --- [INPUT]
# [eth0] guardian = 192.168.0.1
$ipt -A INPUT -i eth0 -m state --state NEW -p tcp --syn --sport 1024: -m
multiport --dports 22,80,53,139,3306 -s $lan -d $guardian
-j ACCEPT
$ipt -A INPUT -i eth0 -m state --state NEW -p udp --sport 1024: -m
multiport --dports 53,137,138 -s $lan -d $guardian -j ACCEPT
$ipt -A INPUT -i eth0 -p udp --sport 68 --dport 67 -j ACCEPT
Dans les règles on voit l'autorisation pour les paquets NEW mais pas ESTABLISHED ou RELATED pour lo, la règle a juste été zappée ou elle n'existe pas ?
D'après moi, le problème ne vient pas d'un problème de configuration du firewall, mais d'un problème de création ou d'utilisation du tunnel... Si tel est le cas, il faudrait donc plutôt voir ça sur fr.comp.reseaux.ip
Il faudrait voir quelle est la commande SSH donnée pour lancer le tunnel.
Le tunnel est créer par l'intérmédiaire de putty.
Prenons l'exemple de l'access au smtp.
dans mozilla : serveur : localhost port 25
Le tunnel putty est donc configurer comme suit : local port : 25 remote : 192.168.0.1:25
Evidemment, je suis contraint d'initier une session ssh pour que le tunnel fonctionne.
Dans le doute, je vous donne mes règles de firewalling :
.... # default police. $ipt -P INPUT DROP $ipt -P FORWARD DROP $ipt -P OUTPUT ACCEPT
# [localhost] $ipt -A INPUT -i lo -m state --state NEW,ESTABLISHED -s 127.0.0.0/8 -d 127.0.0.0/8 -j ACCEPT
# [bad packets]
$ipt -t nat -A PREROUTING -i eth1 -s 192.168.0.0/16 -j DROP $ipt -t nat -A PREROUTING -i eth1 -s 172.16.0.0/12 -j DROP $ipt -t nat -A PREROUTING -i eth1 -s 10.0.0.0/8 -j DROP
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
# [conntrack] for i in INPUT FORWARD do $ipt -A $i -m state --state ESTABLISHED -p tcp ! --syn -j ACCEPT $ipt -A $i -m state --state ESTABLISHED -p udp -j ACCEPT $ipt -A $i -m state --state RELATED -p icmp -j ACCEPT done
# --- [INPUT]
# [eth0] guardian = 192.168.0.1 $ipt -A INPUT -i eth0 -m state --state NEW -p tcp --syn --sport 1024: -m multiport --dports 22,80,53,139,3306 -s $lan -d $guardian -j ACCEPT $ipt -A INPUT -i eth0 -m state --state NEW -p udp --sport 1024: -m multiport --dports 53,137,138 -s $lan -d $guardian -j ACCEPT $ipt -A INPUT -i eth0 -p udp --sport 68 --dport 67 -j ACCEPT
... ...
Par avance merci, Arnaud
MLC
"arnaud" a écrit dans le message de news:4159eaf7$0$13506$ [...]
Le tunnel est créer par l'intérmédiaire de putty.
Prenons l'exemple de l'access au smtp.
dans mozilla : serveur : localhost port 25
Le tunnel putty est donc configurer comme suit : local port : 25
Salut,
Je pense que le pb vient du fait que dans tes règles iptables tu interdit les connexions sur le port 25 alors que dans la conf du PuTTY tu indiques
remote : 192.168.0.1:25
Tu dois te débrouiller pour avoir ces lignes de configuration dans le menu "PuTTY ConfigurationConnectionSSHTunnels" pour sécuriser ton accès POP et SMTP via un tunnel SSH : L110 127.0.0.1:110 L25 127.0.0.1:25
Pour les explications : http://the.earth.li/~sgtatham/putty/0.55/htmldoc/Chapter3.html#S3.5
Tes serveurs POP et SMTP doivent bien entendu écouter sur les interfaces locales.
@+ Marc
"arnaud" <arnaud.lacroix@voila.fr> a écrit dans le message de
news:4159eaf7$0$13506$626a14ce@news.free.fr...
[...]
Le tunnel est créer par l'intérmédiaire de putty.
Prenons l'exemple de l'access au smtp.
dans mozilla :
serveur : localhost
port 25
Le tunnel putty est donc configurer comme suit :
local port : 25
Salut,
Je pense que le pb vient du fait que dans tes règles iptables tu interdit
les connexions sur le port 25 alors que dans la conf du PuTTY tu indiques
remote : 192.168.0.1:25
Tu dois te débrouiller pour avoir ces lignes de configuration dans le menu
"PuTTY ConfigurationConnectionSSHTunnels" pour sécuriser ton accès POP et
SMTP via un tunnel SSH :
L110 127.0.0.1:110
L25 127.0.0.1:25
Pour les explications :
http://the.earth.li/~sgtatham/putty/0.55/htmldoc/Chapter3.html#S3.5
Tes serveurs POP et SMTP doivent bien entendu écouter sur les interfaces
locales.
"arnaud" a écrit dans le message de news:4159eaf7$0$13506$ [...]
Le tunnel est créer par l'intérmédiaire de putty.
Prenons l'exemple de l'access au smtp.
dans mozilla : serveur : localhost port 25
Le tunnel putty est donc configurer comme suit : local port : 25
Salut,
Je pense que le pb vient du fait que dans tes règles iptables tu interdit les connexions sur le port 25 alors que dans la conf du PuTTY tu indiques
remote : 192.168.0.1:25
Tu dois te débrouiller pour avoir ces lignes de configuration dans le menu "PuTTY ConfigurationConnectionSSHTunnels" pour sécuriser ton accès POP et SMTP via un tunnel SSH : L110 127.0.0.1:110 L25 127.0.0.1:25
Pour les explications : http://the.earth.li/~sgtatham/putty/0.55/htmldoc/Chapter3.html#S3.5
Tes serveurs POP et SMTP doivent bien entendu écouter sur les interfaces locales.
@+ Marc
MLC
"T0t0" a écrit dans le message de news: [...]
Dans les règles on voit l'autorisation pour les paquets NEW mais pas ESTABLISHED ou RELATED pour lo, la règle a juste été zappée ou elle n'existe pas ?
Yop
Elle existe pour ESTABLISHED ! en fait pour toutes les interfaces et pas uniquement pour lo.
# [conntrack] for i in INPUT FORWARD do $ipt -A $i -m state --state ESTABLISHED -p tcp ! --syn -j ACCEPT
Marc
"T0t0" <bibi@antionline.org> a écrit dans le message de
news:1d55345df350e35f9f29f770df52ab52_28089@mygate.mailgate.org...
[...]
Dans les règles on voit l'autorisation pour les paquets NEW mais pas
ESTABLISHED ou RELATED pour lo, la règle a juste été zappée ou elle
n'existe pas ?
Yop
Elle existe pour ESTABLISHED ! en fait pour toutes les interfaces et pas
uniquement pour lo.
# [conntrack]
for i in INPUT FORWARD
do
$ipt -A $i -m state --state ESTABLISHED -p tcp ! --syn -j ACCEPT
Dans les règles on voit l'autorisation pour les paquets NEW mais pas ESTABLISHED ou RELATED pour lo, la règle a juste été zappée ou elle n'existe pas ?
Yop
Elle existe pour ESTABLISHED ! en fait pour toutes les interfaces et pas uniquement pour lo.
# [conntrack] for i in INPUT FORWARD do $ipt -A $i -m state --state ESTABLISHED -p tcp ! --syn -j ACCEPT
