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
| ||
|
Message-ID: <1289764664.2743.110.camel@edumazet-laptop> Date: Sun, 14 Nov 2010 20:57:44 +0100 From: Eric Dumazet <eric.dumazet@...il.com> To: Kevin Cernekee <cernekee@...il.com> Cc: Patrick McHardy <kaber@...sh.net>, "David S. Miller" <davem@...emloft.net>, Alexey Kuznetsov <kuznet@....inr.ac.ru>, "Pekka Savola (ipv6)" <pekkas@...core.fi>, James Morris <jmorris@...ei.org>, Hideaki YOSHIFUJI <yoshfuji@...ux-ipv6.org>, netfilter-devel@...r.kernel.org, netfilter@...r.kernel.org, coreteam@...filter.org, linux-kernel@...r.kernel.org, netdev@...r.kernel.org Subject: Re: [PATCH/RFC] netfilter: nf_conntrack_sip: Handle quirky Cisco phones Le dimanche 14 novembre 2010 à 10:33 -0800, Kevin Cernekee a écrit : > On Sun, Nov 14, 2010 at 12:59 AM, Eric Dumazet <eric.dumazet@...il.com> wrote: > > I would like to get an exact SIP exchange to make sure their is not > > another way to handle this without adding a "Cisco" string somewhere... > > > > Please provide a pcap or tcpdump -A > > Existing nf_nat_sip: phone sends unauthenticated REGISTER requests > over and over again, because it is not seeing the replies sent back to > port 50070: > > 10:05:53.496479 IP 192.168.2.28.50070 > 67.215.241.250.5060: SIP, length: 723 > E`...[..@.......C...........REGISTER sip:losangeles.voip.ms SIP/2.0 > Via: SIP/2.0/ > Hmm, partial tcpdump... you should use" tcpdump -s 1000 -A" We miss the Via: SIP/2.0/UDP 192.168.2.28:5060;branch=xxxxxxxx Maybe a fix would be to use this "5060" port, instead of hardcoding it like you did ? > > Patched nf_nat_sip: router sends the replies back to port 5060, so the > phone is now able to register itself and make calls: > > 10:09:46.221631 IP 192.168.2.28.50618 > 67.215.241.250.5060: SIP, length: 723 > E`...G..@.......C...........REGISTER sip:losangeles.voip.ms SIP/2.0 > Via: SIP/2.0/ > > 10:09:46.253052 IP 67.215.241.250.5060 > 192.168.2.28.5060: SIP, length: 491 > E....+..4..$C...............SIP/2.0 100 Trying > Via: SIP/2.0/UDP 192.168.2.28:5060 > > 10:09:46.253472 IP 67.215.241.250.5060 > 192.168.2.28.5060: SIP, length: 550 > E..B.,..4...C...............SIP/2.0 401 Unauthorized > Via: SIP/2.0/UDP 192.168.2.2 > > 10:09:46.261602 IP 192.168.2.28.50618 > 67.215.241.250.5060: SIP, length: 900 > E`...H..@.......C...........REGISTER sip:losangeles.voip.ms SIP/2.0 > Via: SIP/2.0/ > > 10:09:46.290211 IP 67.215.241.250.5060 > 192.168.2.28.5060: SIP, length: 491 > E....-..4.."C...............SIP/2.0 100 Trying > Via: SIP/2.0/UDP 192.168.2.28:5060 > > 10:09:46.295041 IP 67.215.241.250.5060 > 192.168.2.28.5060: SIP, length: 579 > E.._....4...C............K..SIP/2.0 200 OK > Via: SIP/2.0/UDP 192.168.2.28:5060;bra > > > BTW, I thought of two possible issues with the original patch: > > 1) Might need to call skb_make_writable() prior to modifying the > packet. Presumably the second invocation inside > nf_nat_mangle_udp_packet() will have no effect. > > (Is there a cleaner way to mangle just the port number? Most of the > utility functions only help with modifying the data area.) > > 2) I should probably be checking to make sure request == 0 before > mangling the packet. The current behavior is harmless if the SIP > proxy is on port 5060, but that might not always be the case. > > I can roll these, along with any other suggestions, into v2. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists