netdev - Re: H.245v10+ support in nf_conntrack

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 01 Sep 2009 14:20:51 +0200
From:	Patrick McHardy <kaber@...sh.net>
To:	Andreas Jaggi <aj@...n.ch>
CC:	Mark Brown <broonie@...nsource.wolfsonmicro.com>,
	Jing Min Zhao <zhaojingmin@...rs.sourceforge.net>,
	netdev@...r.kernel.org
Subject: Re: H.245v10+ support in nf_conntrack_h323?

Andreas Jaggi wrote:
> On Tue, Sep 01, 2009 at 01:25:22PM +0200, Patrick McHardy wrote:
>> Mark Brown wrote:
>>> I'd be surprised if the H.245 version were the source of your problems
>>> here - the new protocol versions are backwards compatible and I don't
>>> remember any changes in any of the stuff that's relevant for firewall
>>> transit.
>> Good point. The helper should also log packets dropped due to parsing
>> errors. If you don't get any messages, I'd suggest to use the iptables
>> TRACE target to figure out where the packets are dropped exactly.
> 
> I'm quite confident that the H.245 parsing/handling is involved in the
> packet dropping:
> 1. there are plenty of 'nf_ct_h245: packet dropped' messages
>    (but no nf_ct_q931 or nf_ct_ras messages)

Yes, that's the H.323 helper.

> 2. without nf_conntrack_h323 the videoconferencing works seamlessly
> 3. with nf_conntrack_h323 and a ...-j NOTRACK rule the videoconferencing
>    works too
> 
> In our setup there is a LOG rule preceding any DROP or ACCEPT rule, and
> there were no logentries for DROP rules showing up (only the nf_ct_h245:
> packet dropped messages).
> Would a TRACE rule provide more insight than this? (eg. by showing in
> which part of the nf_conntrack_h323 code a packet is dropped?)

No, it only shows the path of the packet through the ruleset.

> For me it looks like nf_conntrack_h323 is not only doing connection
> tracking, but also doing protocol enforcement (by dropping packets which
> do not correspond exactly to H.245v7).
> Perhaps there should be a config option to disable the protocol
> enforcement?

Its unfortunately necessary to drop packets in some cases after parsing
errors when the helper might have already (partially) mangled the
packet.

You could try this patch in combination with ulogd and the pcap output
plugin to capture the packets which are dropped by the helper for
analysis.

View attachment "x" of type "text/plain" (2387 bytes)