Autopsie de rc.firewall ... soluce inside ... (IpCopv1.3)

[Le_passant]

Bonjour,

Mon soucis est le suivant :

Agissant via l'interface Web sur des ouvertures de ports, je m'attends à les retrouver lister dans les règles Iptables suite à un "iptables -L".

Mais je ne trouve rien du tout.

Mon ouverture du port 222 d'une classe d'adresses du réseau local (192.168.xxx.0/24) pour utiliser ssh et Winscp en est absente .
Alors que ces modifications sont bien actives (je peux me connecter sans soucis via un client SSH).

Je me demande donc quel fichier a réellement été modifié, et quel petit démon se charge de cette tache (pas Iptable visiblement).

Une modif des règles Iptables ne me fait pas peur, mais visiblement quelque chose m'échappe, donc avant de se lancer ...

Il existe peut-être un lien avec les chaînes prédéfinies (XTACCESS, CUSTOMINPUT, etc...), mais je ne le trouve pas et ça me laisse perplexe...
(ces chaînes sont vides, donc on n'en fait rien).

Help SVP.

Merci

Le passant.

[Franck78]

iptables -L -t nat
iptables -L -t mangle

En l'absence de table précisée, c'est la filter que
tu utilises
iptables -L == iptables -L -t filter

La tu verras peut être un nat sur le port 222...

[Le_passant]

Euh, si je me trompe, c'est justement dans le display de la table filter que je devrais trouver quelque chose concernant le port 222 (sur la chaîne INPUT).

Mais là, rien ....

(Euh, j'avais quand même oublié l'histoire de devoir préciser le -t table )

Je ne trouve toujours pas comment le filtrage est possible dans ces conditions (et donc encore moins comment modifier les règles).

Surtout, je ne comprends pas le pourquoi des chaînes vides.

Par exemple :
/sbin/iptables -N PORTFWACCESS
/sbin/iptables -A FORWARD -j PORTFWACCESS

Comment marche cette partie ?

J'en suis resté à la création de chaînes supplémentaires et à leur valorisation immédiate avec de nouvelles règles au niveau du rc.firewall.
Par contre, toutes ces chaines "vides" me laisse réellement perplexe.

Bon, c'est déjà un truc qui m'avait échappé lors du montage manuel de mon FW basé sur une Slack ...
C'est peut-être un peu pour ça qu'elle est HS maintenant aussi .

Le passant.

Ps : même en précisant -L -n -v, je ne vois rien ... mais c'est quand même plus sympa .

[Franck78]

J'ai pas fouillé de fond en comble IPCOp.
Les chaines vides en fait doivent servir de
base pour les autres modules de ipcop.

rc.firewall fournit l'organisation commune, déclaration
initialisation, aiguillage tandis que le reste
se contente d'ajouter ses règles au bon endroit.

Il est normal de ne rien voir de particulier à propos
de 222. Par défaut tout ce qui vient de GREEN est
accepté en INPUT ou FORWARD.
Alors que la tu constates que le port 25 est bien naté vers
une machine locale:

Code: Tout sélectionner

root@thewall:~ # iptables -L -n |grep 25
ACCEPT     tcp  --  0.0.0.0/0            10.0.0.2            tcp dpt:25
root@thewall:~ # iptables -t nat -L -n |grep 25
DNAT       tcp  --  0.0.0.0/0            80.170.86.5         tcp dpt:25 to:10.0.0.2:25
SNAT       tcp  --  10.0.0.0/8           10.0.0.2            tcp dpt:25 to:10.0.0.100
root@thewall:~ #

Tiens je ne saisis pas le sens de la ligne SNAT

[Le_passant]

Effectivement ça doit servir d'aiguillage, mais je ne comprends po trop comment.

Petit élément de réponse, je viens de trouver ou était matérialisé mon ouverture de port 222 :

J'ai la ligne suivante :

Code: Tout sélectionner

tcp,192.168.xx.0/24,222,on,0.0.0.0

Dans le fichier : /var/ipcop/xtaccess/config

Miracle, il existe une chaîne vide XTACCESS dans rc.firewall.... Mais ça ne m'explique pas tout .

Par exemple, comment sont lié les deux ?

Ah, effectivement : avec une règle INPUT depuis le GREEN à ACCEPT, ne pas trouver d'indication sur une ouverture du port 222 est normal.

Donc, quel élément m'empèchait d'accéder à IpCop via ce port ?

Je comprends pas non plus ce SNAT sur le port 25 ...

Le passant.

[Franck78]

Port 25 en retour sans doute.

fichier XTACCESS C'est bien la que sont rangées les règles
d'accès RED vers INTERNAL
(internal c'est le firewall)

Code: Tout sélectionner

root@thewall:/ # grep -R XTACCESS /etc /var/ipcop
/etc/rc.d/rc.firewall:  # XTACCESS chain, used for external access
/etc/rc.d/rc.firewall:  /sbin/iptables -N XTACCESS
/etc/rc.d/rc.firewall:  /sbin/iptables -A INPUT -m state --state NEW -j XTACCESS

root@thewall:/ # grep -R setxtaccess /etc /var/ipcop
/etc/rc.d/rc.updatered:                 /usr/local/bin/setxtaccess
/etc/rc.d/rc.updatered: /usr/local/bin/setxtaccess
/var/ipcop/dhcpc/dhcpcd.exe:                    /usr/local/bin/setxtaccess
/var/ipcop/dhcpc/dhcpcd.exe:    /usr/local/bin/setxtaccess



On voit bien que la XTACCESS est branchée sur INPUT seulement. Elle est mise en place au démarrage
par /usr/local/bin/setxtaccess. Ce prog est aussi
appellé par le xtaccess.cgi et un changement dhcp.
D'ailleurs c'est bizarre:il n'y a pas de restriction
a une source RED

[Le_passant]

On avance, on avance ...

Je commence à percevoir l'influence de ces "fameuses" chaînes vides.

Une fois qu'on comprends que rc.firewall les créé et que l'éxécution de setxtacces (par exemple) "alimente" la chaînes XTACCESS depuis le fichier config (dont il est fait mention plus haut), ça va un peu mieux.

Le *.cgi est ce qui nous permet de lister les ports d'ouvert sous l'interface Web, et, sans doute, de les modifier via ce médium.

Il ne me reste plus qu'a trouver :
- le pourquoi de la syntaxe utilisée dans le fichier config
- le comment lister ces fameuses règles pour pouvoir les contrôler facilement
- et en règle générale, en apprendre un peu plus sur le fonctionnement de ces binaires d'alimentation des chaînes de filtrages.

C'est po gagné ... mais on est là pour apprendre, non ?

Prochaine étape : chasse aux infos et aux sources .

Euh, mes conclusions sont trop attives ?

Le passant.

ps : n'hésitez pas à me filer des p'tits coups de pouces.
pps : merci Franck78 pour ce coup de pouce, en espérant de nombreux autres

[Le_passant]

Bon j'ai plus d'éléments, et ... des fois je ..., bref :

J'ai récupéré les sources de ma version d'IpCop (v1.3), et donc étudié le bin setxtaccess.

Je vous passe les détails (que je n'ai pas forcément entièrement compris ), mais en gros, on éxécute, dans l'ordre :

Code: Tout sélectionner

/sbin/iptables -F XTACCESS

Puis, pour chaques lignes trouvées dans le config :

Code: Tout sélectionner

/sbin/iptables -A XTACCESS -i iface -p protocol -s remIP \
                             -d destIP --dport locport -j ACCEPT
iface=interface RED

Donc on doit normalement les retrouver par un "bête" IPTABLES -L -n -v sous la chaîne XTACCESS.

Je ne vois rien, mais ... c'est une bète histoire de fichier ipfile non trouvé, et de sortie en erreur d'une éxécution de setxtaccess.
Normal, pour l'instant je n'ai pas de RED d'installé .

Par contre, c'est un bo petit outil et je sens que je vais y faire un peu plus attention .

Un petit bonus, il ne sert à rien de préciser off dans le fichier config, le cas n'étant pas géré dans setxtaccess (me semble-t'il).

Le passant.


ps : Euh truc idiot, le GREEN Input étant en ACCEPT, pas la peine d'ouvrir le port 222 pour une machine du GREEN, mais euh, j'ai rien dit .
Dire que je me "prends" la tête avec ça depuis 2-3 jours .
Des fois, je vous jure ...
(et Frank78 qui me le dit, et je n'y fait même pas attention)

[Le_passant]

Un petit bonus, il ne sert à rien de préciser off dans le fichier config, le cas n'étant pas géré dans setxtaccess (me semble-t'il).

Petit ajout : ceci n'est pas totalement exact.

Le "off" est bien géré : on ne fait tout simplement rien. La ligne n'est pas traité, et on passe à la suivante.

Par contre, il n'existe pas de possibilité de préciser autre chose que "on" ou "off" : on ne peut donc pas "DROPer" quelquechose via l'utilisation de setxtaccess et de son fichier config.

Il faut plus prendre ma remarque précédente dans ce sens .

Le passant.

[Le_passant]

Encore ! Encore !

...


Plus sérieusement, pour ceux qui se posent la question : setdmzholes et setportfw fonctionnent de la même manière.

- setportfw traite lui d'ajout de règles de NAT sur la chaîne PORTFW et des règles en ACCEPT sur la chaîne PORTFWACCESS.

- setdmzholes ajoute uniquement des règles en ACCEPT sur la chaîne DMZHOLES.

Le passant.

[Franck78]

Et bien quel roman. Suffisait de te mettre sur la voie...
Maintenant c'est clair pour toi les chaines vides du début !



Tiens, le serveur phpbb est resté à l'heure d'hiver

[Le_passant]

Yep, fallait juste me donner la bonne piste.

Mici m'sieur .

Le passant.

Argh, j'avais oublié cette histoire de changement d'heure ....