Debian Jessie x64
Bonjour,
J’aimerais ouvrir les ports dans mon pare-feu pour Kodi (ex-XBMC), dans le but de faire fonctionner le DLNA.
J’utilise gufw comme pare-feu (interface graphique pour ufw).
Pare-feu désactivé, le DLNA fonctionne.
Pare-feu activé, je ne peux même pas lister les fichiers sur mon serveur DLNA.
J’ai essayé d’ouvrir ces ports : https://zaplanincan.wordpress.com/2015/02/14/kodi-network-ports/
Ça ne fonctionne pas.
Active le log des paquets bloqués pour voir ce qui manque. Ne connaissant pas ufw, je ne peux pas être plus précis.
Salut,
J’ai renommé l’ancien log de ufw (/var/log/ufw.log), puis activé le logging “high” ([mono]sudo ufw logging on high[/mono]).
Il n’y a pas de nouveau log de ufw qui se créé, même en redémarrant le service ufw.
J’ai démarré xbmc, essayé de me connecter au serveur.
Je quitte xbmc pour aller voir les logs :
Toujours pas de log.
Voilàvoilà. Si tu as une solution pour tester si le logging fonctionne…
Comme je l’ai écrit, je ne connais pas ufw. J’utilise directement iptables.
Sincérement, il me semble préférable que tu ailles poser le problème sur le forum d’entraide de Kodi : forum.kodi.tv/
Ce n’est pas un problème spécifique Debian …
Et, bien que ne maîtrisant pas le sujet autant que PascalHambourg, il m’est clair aussi que l’usage direct d’iptables est quand même mieux, à toutes ces surcouches … ufw étant une surcouche d’iptables, gufw une à ufw …
@PengouinPdt
C’est fait !
http://forum.kodi.tv/showthread.php?tid=220458&pid=2028279#pid2028279
Plus qu’à espérer une réponse…
Sinon, je trouve ta réponse assez en opposition avec ta signature xD.
J’ai du mal à m’imaginer rendre les choses simples sans utiliser de surcouche (graphique au minimum) 
.
Iptables nécessite tout un apprentissage de son dialecte, contrairement à ufw ou gufw. Cependant, c’est vrai qu’il y a plus de fonctionnalités.
Je suis tombé là-dessus lors de ma recherche sur le forum de Kodi :
forum.kodi.tv/showthread.php?tid … rewall+ufw
Un pare-feu qui se base sur la signature d’une application pour autoriser les connexions. C’est un concept qui me branche pas mal…
Y aurait-t-il un équivalent sous Linux ?
UPnP/DLNA a pour ports à ouvrir, au minimum :
Tu peux aussi ouvrir le mDNS : 5353 UDP …
Il faut veiller à ce que les connexions relatives et/ou établies, TCP et UDP, soient permises aussi.
Bref, c’est tout sauf simple à gérer !
Ensuite, libre à toi de croire que gérer Netfilter avec ufw, ou gufw est plus simple - qui ni l’un, ni l’autre ne sont un parefeu, de même pour iptables, qui se trouve être une surcouche textuel à Netfilter. Ce n’est pas parce que tu as l’illusion de la simplicité que cela l’est réellement.
En passant, il existe un projet relativement jeune, NFtables, qui à terme devrait remplacer iptables, dont le propos est de gérer plus “facilement” les couches ipv4, ipv6, arp, eb, etc …
Bref, chacun ses illusions 
Ce que tu as trouvé sur le forum kodi, à-propos du parefeu, est - si je ne me trompe pas - ce qu’on appelle un parefeu applicatif, dit de niveau 7, puisque c’est là que ce gère les applications, dans le standard OSI. Comme sous MS Windows, bien souvent …
À ma connaissance, sous Linux, il n’en existe pas … la gestion parefeu est géré par Netfilter, assez imbriqué dans le kernel Linux - mais, là encore, je peux me tromper, parce que je pense ne pas avoir tout saisi pleinement. C’est PascalHambourg qui pourrait t’en discourir bien plus aisément !
Quant à ma signature : c’est surtout une forme de provocation, “en connaissance de causes” !
C’est une vision erronée (mais courante) de ce que sont réellement netfilter et iptables.
Netfilter est une infrastructure générique de traitement des paquets au sein du noyau.
Iptables est un filtre de paquets qui s’intègre dans cette infrastructure. Il se compose de deux parties : la commande utilisateur (avec laquelle on le confond souvent comme tu le fais), qui permet de gérer les règles, et les modules du noyau qui appliquent les règles.
Il en est de même pour nftables, comme il en était de même dans les premières versions du noyau 2.4 avec ipchains (le pare-feu des noyaux 2.2) dont le module de compatibilité fonctionnait à l’intérieur de netfilter indépendamment des modules d’iptables.
PascalHambourg, merci des précisions. Qui ne sont jamais décrites ainsi, ou trop succinctement pour en saisir la subtilité (tel que sur la doc inet, par exemple, où ils parlent bien de l’espace noyau … mais tellement rapido, que je n’avais pas saisi ce détail important.)
Que Netfilter soit imbriqué dans le noyau, j’avais saisi … mais qu’iptables gère des modules noyau, non.
En effet, pour moi, iptables ne servait qu’à injecter les règles textuelles à Netfilter …
Et, sincèrement, ta description affine ma compréhension … 
Merci beaucoup.
Ça fonctionne !
J’ai autorisé tous ces ports : https://zaplanincan.wordpress.com/2015/02/14/kodi-network-ports/
ET ceux que PengouinPdt m’a donnés : 2869/tcp et 5353/udp
Merci pour votre aide
Sachant qu’UPNP par définition n’est pas sécurisé car c’est un protocole qui permet à un serveur de demander au client d’ouvrir un port. C’est un protocole qui est directement bloqué au niveau de ma BOX en fait.
Mais c’est de fait bien plus facile à gérer sous linux coté sécurité que ça ne l’est sous windows.
Hummm, bonjour le déterrage :
8 années plus tard
Ça, c’est normal, c’est même la moindre des choses, surtout venant du grand net.
Mais on n’est plus dans le contexte de Kodi de l’utilisateur 
(sur une station/serveur en local, il n’y a pas en soit d’intérêt à le brider, tout en veillant à n’autoriser que le flux local).
En fait même en interne, l’upnp pouvant etre utilisé via du javascript
De toute façon, je ne l’utilise pas ! 
Si besoin, point de montage par SSHFS, par exemple 
(mais là, on est encore plus hors sujet)