Netfilter, nfconntrack et état RELATED

seb-ksl · Janvier 17, 2017, 6:04pm

Bonsoir à tous !

J’ai besoin d’un peu d’aide pour comprendre des principes réseaux qui m’étaient jusqu’il y a peu étrangers. Je vais commencer par les questions générales, puis suivre avec les questions pratico-pratiques liées à ma situation.

Questions générales

Il m’a semblé comprendre certaines notions, de façon empirique, mais j’aimerais que vous me corrigiez :

Il existe pour les paquets réseau un état RELATED, lequel est supposé marquer les paquets qui “dérivent” d’une connexion établie sur un autre port. Cette “relation” entre les deux connexions est détectée par Netfilter grâce à ses modules nf_conntrack_xxx (par exemple nf_conntrack_ftp). Si on définit une règle iptables qui autorise les paquets RELATED, on laissera donc passer ces paquets alors qu’ils ne transitent pas forcément à travers un port autorisé a priori.

Ma situation, concrètement

J’ai installé sur mon réseau local une caméra IP. Celle-ci émet un flux RTSP que je peux récupérer sur un poste local sans pare-feu. Mais si j’active mon pare-feu, configuré par iptables (dont je vous colle ci-dessous la configuration), je ne peux plus récupérer le flux RTSP.

# Generated by iptables-save v1.4.21 on Tue Jan 17 18:40:14 2017
*filter
:INPUT DROP [1663:177041]
:FORWARD DROP [0:0]
:OUTPUT DROP [4367:1432376]
:fail2ban-ssh - [0:0]
-A INPUT -p tcp -m multiport --dports 22 -j fail2ban-ssh
-A INPUT -p tcp -m multiport --dports 22 -j fail2ban-ssh
-A INPUT -p tcp -m multiport --dports 22 -j fail2ban-ssh
-A INPUT -i lo -j ACCEPT
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -p icmp -m icmp --icmp-type 8 -m conntrack --ctstate NEW -m limit --limit 1/sec --limit-burst 1 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 22 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 8080 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 5000 -j ACCEPT
-A OUTPUT -o lo -j ACCEPT
-A OUTPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A OUTPUT -p icmp -m icmp --icmp-type 8 -m conntrack --ctstate NEW -j ACCEPT
-A OUTPUT -p tcp -m tcp --dport 22 -j ACCEPT
-A OUTPUT -p tcp -m tcp --dport 80 -j ACCEPT
-A OUTPUT -p tcp -m tcp --dport 443 -j ACCEPT
-A OUTPUT -p udp -m udp --dport 53 -j ACCEPT
-A OUTPUT -p tcp -m tcp --dport 53 -j ACCEPT
-A OUTPUT -p udp -m udp --dport 123 -j ACCEPT
-A fail2ban-ssh -j RETURN
-A fail2ban-ssh -j RETURN
-A fail2ban-ssh -j RETURN
COMMIT
# Completed on Tue Jan 17 18:40:14 2017
# Generated by iptables-save v1.4.21 on Tue Jan 17 18:40:14 2017
*nat
:PREROUTING ACCEPT [2668:232813]
:INPUT ACCEPT [535:32100]
:OUTPUT ACCEPT [8333:1635209]
:POSTROUTING ACCEPT [3966:202833]
COMMIT
# Completed on Tue Jan 17 18:40:14 2017
# Generated by iptables-save v1.4.21 on Tue Jan 17 18:40:14 2017
*mangle
:PREROUTING ACCEPT [279842:127319620]
:INPUT ACCEPT [279371:127295896]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [65701:60141537]
:POSTROUTING ACCEPT [61334:58709161]
COMMIT
# Completed on Tue Jan 17 18:40:14 2017
# Generated by iptables-save v1.4.21 on Tue Jan 17 18:40:14 2017
*raw
:PREROUTING ACCEPT [279844:127319724]
:OUTPUT ACCEPT [65703:60142041]
COMMIT
# Completed on Tue Jan 17 18:40:14 2017

Le port usuellement utilisé par le protocole RTSP est le 554/tcp, et un nmap de ma caméra confirme que ce port est ouvert. J’ai donc essayé d’autoriser les paquets à transiter à travers ce port dans ma config iptables. Mais toujours impossible de lire le flux RTSP. J’ai donc lancé une capture avec Wireshark, pare-feu désactivé, pour voir ce qui pouvait coincer. Mon poste local est le 192.168.0.2 et la caméra 192.168.0.51.

"No."	"Time"		"Source"	"Destination"	"Protocol"	"Length"	"Info"
"1"	"0.000000000"	"192.168.0.2"	"192.168.0.51"	"TCP"	"74"	"46454 > 554 [SYN] Seq=0 Win=29200 Len=0 MSS=1460 SACK_PERM=1 TSval=722718 TSecr=0 WS=128"
"2"	"0.012049439"	"192.168.0.51"	"192.168.0.2"	"TCP"	"74"	"554 > 46454 [SYN	 ACK] Seq=0 Ack=1 Win=14480 Len=0 MSS=1460 SACK_PERM=1 TSval=7570777 TSecr=722718 WS=4"
"3"	"0.012097737"	"192.168.0.2"	"192.168.0.51"	"TCP"	"66"	"46454 > 554 [ACK] Seq=1 Ack=1 Win=29312 Len=0 TSval=722721 TSecr=7570777"
"4"	"0.012133566"	"192.168.0.2"	"192.168.0.51"	"RTSP"	"153"	"OPTIONS rtsp://192.168.0.51:554/onvif1 RTSP/1.0"
"5"	"0.014436721"	"192.168.0.51"	"192.168.0.2"	"TCP"	"66"	"554 > 46454 [ACK] Seq=1 Ack=88 Win=14480 Len=0 TSval=7570777 TSecr=722721"
"6"	"0.073933820"	"192.168.0.51"	"192.168.0.2"	"RTSP"	"194"	"Reply: RTSP/1.0 200 OK"
"7"	"0.073971295"	"192.168.0.2"	"192.168.0.51"	"TCP"	"66"	"46454 > 554 [ACK] Seq=88 Ack=129 Win=30336 Len=0 TSval=722736 TSecr=7570783"
"8"	"0.074150859"	"192.168.0.2"	"192.168.0.51"	"RTSP"	"179"	"DESCRIBE rtsp://192.168.0.51:554/onvif1 RTSP/1.0"
"9"	"0.087270287"	"192.168.0.51"	"192.168.0.2"	"TCP"	"66"	"554 > 46454 [ACK] Seq=129 Ack=201 Win=14480 Len=0 TSval=7570784 TSecr=722736"
"10"	"0.089841514"	"192.168.0.51"	"192.168.0.2"	"RTSP/SDP"	"567"	"Reply: RTSP/1.0 200 OK"
"11"	"0.090347221"	"192.168.0.2"	"192.168.0.51"	"RTSP"	"214"	"SETUP rtsp://192.168.0.51:554/onvif1/track1 RTSP/1.0"
"12"	"0.103503863"	"192.168.0.51"	"192.168.0.2"	"RTSP"	"242"	"Reply: RTSP/1.0 200 OK"
"13"	"0.103920655"	"192.168.0.2"	"192.168.0.51"	"RTSP"	"233"	"SETUP rtsp://192.168.0.51:554/onvif1/track2 RTSP/1.0"
"14"	"0.124692047"	"192.168.0.51"	"192.168.0.2"	"RTSP"	"242"	"Reply: RTSP/1.0 200 OK"
"15"	"0.124991140"	"192.168.0.2"	"192.168.0.51"	"RTP"	"54"	"PT=ITU-T G.711 PCMU	 SSRC=0x0	 Seq=0	 Time=0"
"16"	"0.125009341"	"192.168.0.2"	"192.168.0.51"	"RTCP"	"50"	"Receiver Report   "
"17"	"0.125020845"	"192.168.0.2"	"192.168.0.51"	"RTP"	"54"	"PT=ITU-T G.711 PCMU	 SSRC=0x0	 Seq=0	 Time=0"
"18"	"0.125031775"	"192.168.0.2"	"192.168.0.51"	"RTCP"	"50"	"Receiver Report   "
"19"	"0.125048231"	"192.168.0.2"	"192.168.0.51"	"RTSP"	"188"	"PLAY rtsp://192.168.0.51:554/onvif1 RTSP/1.0"
"20"	"0.133527265"	"192.168.0.51"	"192.168.0.2"	"ICMP"	"78"	"Destination unreachable (Port unreachable)"
"21"	"0.133907151"	"192.168.0.51"	"192.168.0.2"	"ICMP"	"78"	"Destination unreachable (Port unreachable)"
"22"	"0.135242646"	"192.168.0.51"	"192.168.0.2"	"RTSP"	"279"	"Reply: RTSP/1.0 200 OK"
"23"	"0.147237839"	"192.168.0.51"	"192.168.0.2"	"RTP"	"802"	"PT=DynamicRTP-Type-96	 SSRC=0x3BCEF335	 Seq=39921	 Time=2545750094	 Mark"
"24"	"0.179073285"	"192.168.0.2"	"192.168.0.51"	"TCP"	"66"	"46454 > 554 [ACK] Seq=638 Ack=1195 Win=34560 Len=0 TSval=722763 TSecr=7570789"
"25"	"0.213560552"	"192.168.0.51"	"192.168.0.2"	"RTP"	"214"	"PT=ITU-T G.711 PCMA	 SSRC=0x3BCEF335	 Seq=1791	 Time=608063688"
"26"	"0.213919431"	"192.168.0.51"	"192.168.0.2"	"RTP"	"214"	"PT=ITU-T G.711 PCMA	 SSRC=0x3BCEF335	 Seq=1792	 Time=608063808"
"27"	"0.214541761"	"192.168.0.51"	"192.168.0.2"	"RTP"	"214"	"PT=ITU-T G.711 PCMA	 SSRC=0x3BCEF335	 Seq=1793	 Time=608064008"
"28"	"0.215312372"	"192.168.0.51"	"192.168.0.2"	"RTP"	"214"	"PT=ITU-T G.711 PCMA	 SSRC=0x3BCEF335	 Seq=1794	 Time=608064128"
[...]

De 1 à 14, c’est bien le 554/tcp de 192.168.0.51 qui est utilisé pour échanger. En revanche, après ça se met à discuter sur quatre ports UDP différents choisis aléatoirement (j’ai fait trois captures pour vérifier).

D’où ma question : ai-je raison de penser que la connexion ne peut pas se faire à travers mon pare-feu, parce que même si la négociation initiale se fait à travers 554/tcp, la suite se fait à travers d’autres ports qui sont interdits par ma config iptables, le tout en l’absence de module nf_conntrack_rtsp ?

Merci de m’avoir lu

PengouinPdt · Janvier 17, 2017, 9:09pm

Bonsoir @seb-ksl:

Il est vrai que je suis très fatigué ce soir … mais je ne vois rien en sortie, dans tes règles, concernant du flux TCP 554 ! ?
Et, apparemment, il faut aussi l’ouvrir en UDP 554

Protocole RTSP

seb-ksl · Janvier 18, 2017, 7:52am

Ah, désolé, je me suis mal fait comprendre : la config iptables que j’ai collée ne contenait pas encore ces règles. Mais comme précisé en-dessous dans mon premier message, la première chose que j’aie tenté est évidemment :

iptables -A OUTPUT -p tcp --dport 554 -j ACCEPT
iptables -A OUTPUT -p udp --dport 554 -j ACCEPT

Sans succès .

cedric058 · Janvier 18, 2017, 8:44am

Et si tu tentes :

iptables -p tcp --dport 554 -j ACCEPT iptables -p udp --dport 554 -j ACCEPT

Ça fonctionne ?

seb-ksl · Janvier 18, 2017, 12:36pm

Non, suite à ma première tentative j’avais essayé d’ouvrir en INPUT aussi, mais pas mieux. Note que normalement ouvrir l’INPUT est inutile car redondant avec la règle -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT (si j’ai tout bien suivi ;-)).

seb-ksl · Janvier 18, 2017, 5:12pm

Bon, c’est un peu étrange parce que la commande conntrack (que je découvre) m’indique quand même les connexions UDP (sur des ports aléatoires) effectuées à la suite de la connexion TCP (sur le port 554) :

# conntrack -L --dst 192.168.0.51

tcp      6 431991 ESTABLISHED src=192.168.0.2 dst=192.168.0.51 sport=51150 dport=554 src=192.168.0.51 dst=192.168.0.2 sport=554 dport=51150 [ASSURED] mark=0 use=1
udp      17 21 src=192.168.0.2 dst=192.168.0.51 sport=19521 dport=7035 [UNREPLIED] src=192.168.0.51 dst=192.168.0.2 sport=7035 dport=19521 mark=0 use=1
udp      17 179 src=192.168.0.2 dst=192.168.0.51 sport=19518 dport=7032 src=192.168.0.51 dst=192.168.0.2 sport=7032 dport=19518 [ASSURED] mark=0 use=1
udp      17 28 src=192.168.0.2 dst=192.168.0.51 sport=19519 dport=7033 [UNREPLIED] src=192.168.0.51 dst=192.168.0.2 sport=7033 dport=19519 mark=0 use=1
udp      17 36 src=192.168.0.2 dst=192.168.0.51 sport=14142 dport=7028 src=192.168.0.51 dst=192.168.0.2 sport=7028 dport=14142 [ASSURED] mark=0 use=1
udp      17 21 src=192.168.0.2 dst=192.168.0.51 sport=19520 dport=7034 [UNREPLIED] src=192.168.0.51 dst=192.168.0.2 sport=7034 dport=19520 mark=0 use=1

Pour ceux qui s’y connaissent en réseau : est-ce que le fait que conntrack me montre ces connexions signifie qu’elles ont l’état RELATED ?

cedric058 · Janvier 18, 2017, 11:25pm

Suite à ce lien :
https://bbs.archlinux.org/viewtopic.php?id=131895

D’où je cite :

conntrack: This module, when combined with connection tracking, allows access to the connection tracking state for this packet/connection.
…
state: This module, when combined with connection tracking, allows access to the connection tracking state for this packet.

Et cet autre lien tiré de la page précédente :
https://wiki.archlinux.org/index.php/Simple_stateful_firewall

Ne faut il pas utiliser ?
-m conntrack --ctstate RELATED,ESTABLISHED
Au lieu de :
-m state --state RELATED,ESTABLISHED

PengouinPdt · Janvier 19, 2017, 7:48am

Absolument
Le suivi de connexion par le module ‘conntrack’ se gère ainsi au-travers d’iptables.
https://www.inetdoc.net/guides/iptables-tutorial/theconntrackentries.html

Mais il est vrai que les états de connexion peuvent être suivi par le match ‘state’ …
Il faut comprendre la subtilité entre l’état de connexion et le suivi de celle-ci

Ce qui m’ennuie est quand même cette réponse ICMP que retourne ta caméra !

L’état RELATED n’est pas forcément liée à une connexion précédemment établie. Cela peut être simplement une réponse d’erreur ICMP à une tentative de connexion TCP/UDP qui échoue.
C’est bien expliqué là : https://www.inetdoc.net/guides/iptables-tutorial/icmpconnections.html

seb-ksl · Janvier 19, 2017, 8:35am

@cedric058 et @PengouinPdt : merci pour la piste, mais malheureusement l’ajout d’une règle -A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT n’y change rien . La connexion initiale sur le port 554/tcp s’effectue bien grâce aux règles spécifiques de ce port (elle est marquée ESTABLISHED), mais les connexions UDP consécutives n’arrivent toujours pas à se faire (elles n’apparaissent ni dans le retour de netstat, ni dans celui de conntrack).

La caméra n’arrive effectivement pas à pinger mon poste local, il faudra que je m’en occupe. Mais étant donné que cette capture de paquets a été effectuée avec une politique d’OUTPUT à ACCEPT et que j’arrivais à lire le flux RTSP, ça n’a pas l’air de la déranger tant que ça.[quote=“PengouinPdt, post:8, topic:72386”]
L’état RELATED n’est pas forcément liée à une connexion précédemment établie. Cela peut être simplement une réponse d’erreur ICMP à une tentative de connexion TCP/UDP qui échoue. C’est bien expliqué là : https://www.inetdoc.net/guides/iptables-tutorial/icmpconnections.html
[/quote]

J’avais fini par tomber sur ce lien aussi, merci pour la source ;-). Ça m’a aidé à y voir un peu plus clair sur cet état RELATED, mais ça ne fait que confirmer mon intuition initiale : j’ai l’impression que les connexions UDP qui devraient être marquées RELATED ne le sont pas, et que donc elles sont bloquées par ma policy d’OUTPUT à DROP.

ricardo · Janvier 19, 2017, 8:49am

Pas de réponse immédiate mais pour marquer mon intérêt et suivre ce fil.
J’utilise aussi des cams IP, mais avec une liaison zoneminder.
Et bien sûr, j’utilise ton tuto pour ipatbles.
Si je peux être utile pour des tests, explicités parfaitement car mon esprit est de plus en plus fatigué, j’aurai un peu de disponibilité.

cedric058 · Janvier 19, 2017, 10:39am

Je pense que tu dois le faire pour INPUT, OUTPUT, et éventuellement FORWARD.

Je viens de faire le test sur le protocole FTP (en client).
# modprobe nf_conntrack_ftp

Et je viens de supprimer une règle en OUTPUT (1024:65535)

Après le suivi de connexion est t’il possible avec ces genres de protocoles RTSP et RTP ? Probablement.
Faut il installer un paquet ?

# lsmod | grep nf_con
# ls -l /lib/modules/3.16.0-4-amd64/kernel/net/netfilter | grep nf_con

Peut être un début de réponse ?
https://people.netfilter.org/chentschel/docs/sip-conntrack-nat.html

# modprobe ip_conntrack_sip

PengouinPdt · Janvier 19, 2017, 11:07am

En quoi FORWARD doit-il être impacté ?
Le flux relatif à RTSP n’est en rien redirigé par le biais du poste en question vers d’autres réseaux !

OUTPUT : oui, puisque tu sors de ta machine vers la cam.
Mais INPUT, en quoi ? La machine ne reçoit et ne doit recevoir aucune demande d’entrée depuis la cam !
Par contre, oui, pour les entrées relatives à tes demandes de connexion à la cam.

Pour finir, en quoi un module de gestion SIP, peut-il gérer un flux RTSP ?!

@cedric058: je ne veux pas t’agresser, ou que tu te sentes agresser, mais faut arrêter de recommander n’importe quoi, sous le doux propos qu’on ne sait pas trop quoi faire …

@seb-ksl: tu as passé aussi les états RELATED et ESTABLISHED en suivi de connexion ?!

cedric058 · Janvier 19, 2017, 12:27pm

Ce sont des règles qui sont là par “commodité”, pour éviter entre autre de décortiquer tous les protocoles.
Si il utilise du “FORWARDING” et qu’il en a besoin du suivi de connexion en FORWARDING, il peut les placer, par commodité. Sinon, bien sur, aucun intérêt.

Perso, par commodité, je ferai cela :

-A OUTPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT

Ça, ça fonctionne PengouinPdt ?

-A OUTPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A INPUT -j DROP

cat https://fr.wikipedia.org/wiki/Session_Initiation_Protocol | grep RTP
cat https://fr.wikipedia.org/wiki/Real_Time_Streaming_Protocol | grep RTP

Je précise, les commandes ci-dessus sont farfelus, et indiquent simplement qu’une lecture de ces pages, que je n’ai pas faite, peut éventuellement être profitable et mentionnent toutes les deux le protocole RTP.

Je cite, en partie le second lien précédent :

RTSP ne transporte pas les données elles-mêmes et doit être associé à un protocole de transport comme RTP ou RDT de RealNetworks pour cette tâche.

Après bien, sur ce ne sont des éventuelles pistes pour faire éventuellement, avancer le Schmilblick.

PengouinPdt · Janvier 19, 2017, 12:30pm

En aucun cas, il ne sera impacté.
(Re?)lis l’intérêt de la chaîne FORWARD.
Cela ne sert à rien, dans ce cas …

Oui, pour le premier.
Non, pour le second.
En effet, en entrée tu as du flux TCP/UDP liés aux connexions reconnues ESTABLISHED voire RELATED.

C’est pour cela que j’ai interpellé @seb-ksl, dans mon post précédent :

seb-ksl · Janvier 19, 2017, 2:10pm

Pour être sûr qu’on parle de la même chose et que vous avez toutes les infos en mains, je colle ici la config complète que j’ai testé et qui ne fonctionne pas :

# Generated by iptables-save v1.6.0 on Thu Jan 19 14:54:23 2017
*raw
:PREROUTING ACCEPT [4893:2939784]
:OUTPUT ACCEPT [4694:390040]
COMMIT
# Completed on Thu Jan 19 14:54:23 2017
# Generated by iptables-save v1.6.0 on Thu Jan 19 14:54:23 2017
*mangle
:PREROUTING ACCEPT [4893:2939784]
:INPUT ACCEPT [4891:2938632]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [4694:390040]
:POSTROUTING ACCEPT [4649:381975]
COMMIT
# Completed on Thu Jan 19 14:54:23 2017
# Generated by iptables-save v1.6.0 on Thu Jan 19 14:54:23 2017
*nat
:PREROUTING ACCEPT [2:1152]
:INPUT ACCEPT [0:0]
:OUTPUT ACCEPT [971:66512]
:POSTROUTING ACCEPT [971:66512]
COMMIT
# Completed on Thu Jan 19 14:54:23 2017
# Generated by iptables-save v1.6.0 on Thu Jan 19 14:54:23 2017
*filter
:INPUT DROP [0:0]
:FORWARD DROP [0:0]
:OUTPUT DROP [18:3487]
-A INPUT -i lo -j ACCEPT
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -p icmp -m icmp --icmp-type 8 -m conntrack --ctstate NEW -m limit --limit 1/sec --limit-burst 1 -j ACCEPT
-A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A OUTPUT -o lo -j ACCEPT
-A OUTPUT -p tcp -m tcp --dport 554 -j ACCEPT
-A OUTPUT -p udp -m udp --dport 554 -j ACCEPT
COMMIT
# Completed on Thu Jan 19 14:54:23 2017

# ls -l /lib/modules/4.8.0-2-amd64/kernel/net/netfilter/ | grep nf_con
-rw-r--r-- 1 root root  12034 janv.  6 05:14 nf_conntrack_amanda.ko
-rw-r--r-- 1 root root   5610 janv.  6 05:14 nf_conntrack_broadcast.ko
-rw-r--r-- 1 root root  28338 janv.  6 05:14 nf_conntrack_ftp.ko
-rw-r--r-- 1 root root 102250 janv.  6 05:14 nf_conntrack_h323.ko
-rw-r--r-- 1 root root  17554 janv.  6 05:14 nf_conntrack_irc.ko
-rw-r--r-- 1 root root 192154 janv.  6 05:14 nf_conntrack.ko
-rw-r--r-- 1 root root   6794 janv.  6 05:14 nf_conntrack_netbios_ns.ko
-rw-r--r-- 1 root root  58274 janv.  6 05:14 nf_conntrack_netlink.ko
-rw-r--r-- 1 root root  27938 janv.  6 05:14 nf_conntrack_pptp.ko
-rw-r--r-- 1 root root  21146 janv.  6 05:14 nf_conntrack_proto_dccp.ko
-rw-r--r-- 1 root root  19954 janv.  6 05:14 nf_conntrack_proto_gre.ko
-rw-r--r-- 1 root root  34754 janv.  6 05:14 nf_conntrack_proto_sctp.ko
-rw-r--r-- 1 root root  13850 janv.  6 05:14 nf_conntrack_proto_udplite.ko
-rw-r--r-- 1 root root  14714 janv.  6 05:14 nf_conntrack_sane.ko
-rw-r--r-- 1 root root  44410 janv.  6 05:14 nf_conntrack_sip.ko
-rw-r--r-- 1 root root   7562 janv.  6 05:14 nf_conntrack_snmp.ko
-rw-r--r-- 1 root root  14802 janv.  6 05:14 nf_conntrack_tftp.ko

# lsmod | grep nf_con
nf_conntrack_ipv6      20480  3
nf_defrag_ipv6         36864  1 nf_conntrack_ipv6
nf_conntrack_ipv4      20480  3
nf_defrag_ipv4         16384  1 nf_conntrack_ipv4
nf_conntrack_ftp       20480  0
nf_conntrack          114688  7 nf_conntrack_ipv6,nf_conntrack_ftp,nf_conntrack_ipv4,nf_nat_ipv6,xt_conntrack,nf_nat_ipv4,nf_nat

Je viens d’essayer de charger les modules nf_conntrack_sip et ip_nat_sip, ça ne change rien : la connexion 554/tcp initiale se fait, mais toujours pas les UDP consécutives.

Je suis d’accord avec le FORWARD et l’OUTPUT.
Mais pour l’INPUT, il me semble que j’attends justement que la caméra m’envoie ses paquets RTSP sur les ports UDP. C’est d’ailleurs clairement ce qu’indique la capture Wireshark : à partir du paquet 25, c’est bien 192.168.0.51 (la caméra) qui bombarde mon poste local (192.168.0.2) de trames RTP. Ce qui n’arrive pas lorsque l’OUTPUT est en DROP, et ce quelles que soient les règles que je teste .

seb-ksl · Janvier 19, 2017, 2:12pm

Si je ne m’abuse, Zoneminder doit, d’une façon ou d’une autre, établir une connexion RTSP avec les caméras, lui aussi. Dans ton pare-feu iptables, quelle est la politique et quelles sont les règles pour la chaîne OUTPUT ?

seb-ksl · Janvier 19, 2017, 2:25pm

En cherchant encore un peu plus, je tombe sur ces deux pages :

Qui semblent suggérer que, par défaut, le protocole RTSP n’est pas supporté par conntrack sous Linux. Mais les deux pages ne datent pas d’hier…

C’est assez vexant de ne pas trouver comment font les autres . Pour le moment, j’ai dû opter pour un peu restrictif : -A OUTPUT -d 192.168.0.51/32 -j ACCEPT.

cedric058 · Janvier 19, 2017, 3:06pm

Sans mentionner :
-A OUTPUT -m state --state RELATED,ESTABLISHED -j ACCEPT

Si tu l’aurais mentionné, cette règle serait elle nécessaire ? (En supposant que le conntrak fonctionne )
-A OUTPUT -p udp -m udp --dport 554 -j ACCEPT

Elle découle normalement de la connexion initiale TCP 554.


"No."	"Time"		"Source"	"Destination"	"Protocol"	"Length"	"Info"
"1"	"0.000000000"	"192.168.0.2"	"192.168.0.51"	"TCP"	"74"	"46454 > 554 [SYN] Seq=0 Win=29200 Len=0 MSS=1460 SACK_PERM=1 TSval=722718 TSecr=0 WS=128"
"3"	"0.012097737"	"192.168.0.2"	"192.168.0.51"	"TCP"	"66"	"46454 > 554 [ACK] Seq=1 Ack=1 Win=29312 Len=0 TSval=722721 TSecr=7570777"
"4"	"0.012133566"	"192.168.0.2"	"192.168.0.51"	"RTSP"	"153"	"OPTIONS rtsp://192.168.0.51:554/onvif1 RTSP/1.0"
"7"	"0.073971295"	"192.168.0.2"	"192.168.0.51"	"TCP"	"66"	"46454 > 554 [ACK] Seq=88 Ack=129 Win=30336 Len=0 TSval=722736 TSecr=7570783"
"8"	"0.074150859"	"192.168.0.2"	"192.168.0.51"	"RTSP"	"179"	"DESCRIBE rtsp://192.168.0.51:554/onvif1 RTSP/1.0"
"11"	"0.090347221"	"192.168.0.2"	"192.168.0.51"	"RTSP"	"214"	"SETUP rtsp://192.168.0.51:554/onvif1/track1 RTSP/1.0"
"13"	"0.103920655"	"192.168.0.2"	"192.168.0.51"	"RTSP"	"233"	"SETUP rtsp://192.168.0.51:554/onvif1/track2 RTSP/1.0"
"15"	"0.124991140"	"192.168.0.2"	"192.168.0.51"	"RTP"	"54"	"PT=ITU-T G.711 PCMU	 SSRC=0x0	 Seq=0	 Time=0"
"16"	"0.125009341"	"192.168.0.2"	"192.168.0.51"	"RTCP"	"50"	"Receiver Report   "
"17"	"0.125020845"	"192.168.0.2"	"192.168.0.51"	"RTP"	"54"	"PT=ITU-T G.711 PCMU	 SSRC=0x0	 Seq=0	 Time=0"
"18"	"0.125031775"	"192.168.0.2"	"192.168.0.51"	"RTCP"	"50"	"Receiver Report   "
"19"	"0.125048231"	"192.168.0.2"	"192.168.0.51"	"RTSP"	"188"	"PLAY rtsp://192.168.0.51:554/onvif1 RTSP/1.0"
"24"	"0.179073285"	"192.168.0.2"	"192.168.0.51"	"TCP"	"66"	"46454 > 554 [ACK] Seq=638 Ack=1195 Win=34560 Len=0 TSval=722763 TSecr=7570789"

Seb-ksl, ces connexion sont elles toutes sur le ports 554 ? Ne sont elles pas en OUTPUT ?

Un lien récent qui va dans ce sens :
https://forum.videolan.org/viewtopic.php?t=133616

PengouinPdt · Janvier 19, 2017, 4:06pm

Règle à supprimer !!!

Règle à garder :

Mais il te faut aussi l’équivalent en sortie !
Sinon, cela ne peut fonctionner …

-A OUTPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT

ricardo · Janvier 19, 2017, 4:24pm

Si je ne m’abuse, Zoneminder doit, d’une façon ou d’une autre, établir une connexion RTSP avec les caméras, lui aussi. Dans ton pare-feu iptables, quelle est la politique et quelles sont les règles pour la chaîne OUTPUT ?

Non, je ne réussis pas à le faire fonctionner avec RTSP.
Je suis en HTTP comme protocole.
Maintenant, en direct sur mes cams, via l’interface Foscam, je n’ai jamais cherché à faire des enregistrements d’alertes, c’est trop complexe ou je ne comprends rien.
Cela dit, les cams sont fonctionnelles si je tape l’IP ad hoc dans la case qui va bien.