Shorewall, iptables et noyau ?

> > Il me reste toutefois un souci. Je souhaite utiliser sslh (merci
> > Yves ;-))). J'ai donc un port unique en entrée et 2 ports en
> > local. Si je fais uniquement :
> > iptables -A INPUT -p tcp --dport port_entrée -j ACCEPT
> > ça ne marche pas !!!
> C'est censé marcher comment au niveau réseau, sslh ?
On arrive sur un port spécifique, et, ensuite, en fonction de ce qui
arrive, on est redirigé vers le bon service sur un autre port.
Je me demande si je ne pourrais pas faire un mix des règles
précédentes, du genre :
iptables -t filter -A INPUT -s 127.0.0.1 -p tcp --dport port_local1 -j
ACCEPT

Pascal Hambourg <pascal.mail@plouf.fr.eu.org> a écrit :

David BERCOT a écrit :

iptables -t filter -A INPUT -s 127.0.0.1 -i lo -j ACCEPT

L'option -s est trop restrictive, les paquets émis sur l'interface de
loopback peuvent avoir n'importe quelle adresse source locale. Cela
inclut la plage 127.0.0.0/8 et toutes les adresses configurées sur
les interfaces de la machine.

Mhummm, il me semble que je n'ai que 127.0.0.1 (de visible en tous
cas)...

C'est censé marcher comment au niveau réseau, sslh ?

On arrive sur un port spécifique, et, ensuite, en fonction de ce qui
arrive, on est redirigé vers le bon service sur un autre port.

Je me demande si je ne pourrais pas faire un mix des règles
précédentes, du genre :
iptables -t filter -A INPUT -s 127.0.0.1 -p tcp --dport port_local1 -j
ACCEPT

David BERCOT a écrit :
> Pascal Hambourg <pascal.mail@plouf.fr.eu.org> a écrit :
>> David BERCOT a écrit :
>>> iptables -t filter -A INPUT -s 127.0.0.1 -i lo -j ACCEPT
>> L'option -s est trop restrictive, les paquets émis sur l'interface
>> de loopback peuvent avoir n'importe quelle adresse source locale.
>> Cela inclut la plage 127.0.0.0/8 et toutes les adresses
>> configurées sur les interfaces de la machine.

En clair, je te conseille fortement de supprimer l'option -s dans
cette règle. Quel bénéfice en terme de sécurité apporte-t-elle ?

> Mhummm, il me semble que je n'ai que 127.0.0.1 (de visible en tous
> cas)...

Tu peux penser ce que tu veux, ou bien vérifier avec cette commande
qui affichera toutes les destinations locales à la machine (installer
le paquet iproute si nécessaire) :

ip route list type local table local

>> C'est censé marcher comment au niveau réseau, sslh ?
>
> On arrive sur un port spécifique, et, ensuite, en fonction de ce q ui
> arrive, on est redirigé vers le bon service sur un autre port.

Redirigé comment ? En établissant une seconde connexion locale ? Avec
quelles adresses source et destination ?

> Je me demande si je ne pourrais pas faire un mix des règles
> précédentes, du genre :
> iptables -t filter -A INPUT -s 127.0.0.1 -p tcp --dport port_local1
> -j ACCEPT

Cette règle est plus restrictive que celle-ci dessus, donc bof.

Pour savoir quels paquets nécessaires sont bloqués, tu peux ajo uter
une règle avec LOG en fin de chaîne et regarder dans les logs du
noyau :

iptables -t filter -A INPUT -j LOG

Mais avec l'adresse de la machine (comme je l'ai mis dans un autre
post), ça semble ok :
iptables -t filter -A INPUT -p tcp --source 'adresse_ip' -j ACCEPT

Pour savoir quels paquets nécessaires sont bloqués, tu peux ajouter
une règle avec LOG en fin de chaîne et regarder dans les logs du
noyau :

iptables -t filter -A INPUT -j LOG

Ben oui, mais non ;-) Je retrouve mon problème de shorewall où ça
bloque sur le LOG !!!

David BERCOT a écrit :
>
> Mais avec l'adresse de la machine (comme je l'ai mis dans un autre
> post), ça semble ok :
> iptables -t filter -A INPUT -p tcp --source 'adresse_ip' -j ACCEPT

L'adresse de la machine, tu veux dire du serveur ?

>> Pour savoir quels paquets nécessaires sont bloqués, tu peux ajouter
>> une règle avec LOG en fin de chaîne et regarder dans les log s du
>> noyau :
>>
>> iptables -t filter -A INPUT -j LOG
>
> Ben oui, mais non ;-) Je retrouve mon problème de shorewall oà ¹ ça
> bloque sur le LOG !!!

Ah zut, c'est vrai. Donc ce serait bien l'absence de la cible LOG qui
gêne shorewall.

Dans ce cas tu peux utiliser tcpdump ou
wireshark/tshark sur l'interface externe et sur l'interface de
loopback pour voir le début de la communication et où ça c ommence à
coincer. Mais c'est moins pratique.

Pascal Hambourg <pascal.mail@plouf.fr.eu.org> a écrit :

David BERCOT a écrit :

Mais avec l'adresse de la machine (comme je l'ai mis dans un autre
post), ça semble ok :
iptables -t filter -A INPUT -p tcp --source 'adresse_ip' -j ACCEPT

L'adresse de la machine, tu veux dire du serveur ?

Toutafé ;-)

Ah zut, c'est vrai. Donc ce serait bien l'absence de la cible LOG qui
gêne shorewall.

Oui, apparemment. Ca me semble bizarre que cette cible ait été
supprimée. Mais bon, j'imagine qu'il doit y avoir une bonne raison (ou
alors, c'est oubli ;-))).

David BERCOT a écrit :
> Pascal Hambourg <pascal.mail@plouf.fr.eu.org> a écrit :
>> David BERCOT a écrit :
>>> Mais avec l'adresse de la machine (comme je l'ai mis dans un autre
>>> post), ça semble ok :
>>> iptables -t filter -A INPUT -p tcp --source 'adresse_ip' -j ACCEPT
>> L'adresse de la machine, tu veux dire du serveur ?
>
> Toutafé ;-)

Un paquet émis par le serveur (puisqu'avec son adresse source) et
reçu par lui-même (puisque traversant chaîne INPUT) passe forcément
par l'interface de loopback lo. Par conséquent c'était l'option -s
127.0.0.1 dans la règle autorisant le trafic sur cette interface qui
le bloquait. Si tu as supprimé cette option, la règle supplà ©mentaire
ci-dessus ne devrait plus être nécessaire.

>> Ah zut, c'est vrai. Donc ce serait bien l'absence de la cible LOG
>> qui gêne shorewall.
>
> Oui, apparemment. Ca me semble bizarre que cette cible ait été
> supprimée. Mais bon, j'imagine qu'il doit y avoir une bonne raison
> (ou alors, c'est oubli ;-))).

Sûrement un oubli. Parce que pour débugger et journaliser le fi rewall
sans ça...

Le Mon, 26 Jan 2009 17:34:07 +0100,
Pascal Hambourg <pascal.mail@plouf.fr.eu.org> a écrit :
> David BERCOT a écrit :
> > Pascal Hambourg <pascal.mail@plouf.fr.eu.org> a écrit :
> >> David BERCOT a écrit :
> >>> Mais avec l'adresse de la machine (comme je l'ai mis dans un
> >>> autre post), ça semble ok :
> >>> iptables -t filter -A INPUT -p tcp --source 'adresse_ip' -j
> >>> ACCEPT
> >> L'adresse de la machine, tu veux dire du serveur ?
> >
> > Toutafé ;-)
>
> Un paquet émis par le serveur (puisqu'avec son adresse source) et
> reçu par lui-même (puisque traversant chaîne INPUT) pass e forcément
> par l'interface de loopback lo. Par conséquent c'était l'opti on -s
> 127.0.0.1 dans la règle autorisant le trafic sur cette interface q ui
> le bloquait. Si tu as supprimé cette option, la règle suppl émentaire
> ci-dessus ne devrait plus être nécessaire.

Ah, exact ;-) Je vais tester ça tout de suite ! Si je peux mettre une
ligne en moins, c'est toujours ça de gagné !
Bon, ça marche. Tu avais donc raison (même si je n'en ai pas
douté ;-))).

> >> Ah zut, c'est vrai. Donc ce serait bien l'absence de la cible LOG
> >> qui gêne shorewall.
> >
> > Oui, apparemment. Ca me semble bizarre que cette cible ait étà ©
> > supprimée. Mais bon, j'imagine qu'il doit y avoir une bonne rais on
> > (ou alors, c'est oubli ;-))).
>
> Sûrement un oubli. Parce que pour débugger et journaliser le
> firewall sans ça...

Oui, mais malheureusement, je leur ai déjà écrit sur ce su jet et ils
m'ont clairement répondu que le noyau était fixe et qu'on ne po uvait
rien faire à moins de prendre une autre offre !
Peut-être qu'ils le changeront prochainement.
En attendant, je n'aurais pas de log là-dessus et c'est bien dommage.

David BERCOT <debian@bercot.org> à écrit le Mon, 26 Jan 2009 14 :56:51
+0100

je réponds à mon post de réponse non encore arrivé su r la liste :

modprobe ipt_LOG