Re: [Ekiga-list] DOS problem

[Eugen Dedu <Eugen Dedu pu-pm univ-fcomte fr>]

bnc netspeed com au wrote:
> Eugen,
>>>>>> I have mentioned this problem before but I now have some more
>>>>>> info.
>>>>>>
>>>>>> I have about 40 numbers in my contact list, when ekiga tries to
>>>>>> register it issues a dns subscribe request for every single phone
>>>>>> number really quickly and repeats this.
>>>>>> I have just rung my isp and they saw the requests coming in and
>>>>>> treat it as a DOS attack and block my phone for 30mins.
>>>>>> Hence the registration drops out, and the cycle starts again.
>>>>>>
>>>>>> In my case most of my contact list are normal phones not actual
>>>>>> sip addresses, it makes no sense to try to determine their
>>>>>> status.
>>>>>>
>>>>>> So my ekiga 3.2.6 is unusable at present.
>>>>>>
>>>>>> Please advise if there is a way to turn this function off.
>>>>> There is no way currently.
>>>>> I do not know how to fix that without adding a new obscure setting
>>>>> to Ekiga.
>>>>>
>>>>> Perhaps using the address book would be more appropriate than the
>>>>> contact list for that specific case ?
>>>> The problem is not that ekiga does a DNS request for each contact
>>>> (even if a DNS cache could be implemented in opal to optimise
>>>> this); the problem is that it issues many DNS requests.  How does
>>>> this happen?
>>>>
>>>> Could that be a DNS configuration problem?  Reporter, could you
>>>> check:
>>>> - how many DNS requests are sent with only one contact (one or
>>>> many?)
>>> I removed all of my contacts except one.
>>> Fired up ekiga again and approx 8 dns messages got fired off. These
>>> were being repeated every 30secs or so.
>>> Went into accounts and unregistered, the dns messages stopped.
>>>
>>> Waited 30mins because my isp told me that they block the port for
>>> that time.
>>>
>>> Went into accounts and reregistered, same deal as above.
>>>
>>>> (In *normal* gconf configuration, you could save your config  with
>>>> "cp -a .gconf/apps/ekiga .gconf/apps/ekiga-save", and restore it
>>>> afterwards)
>>> did not do this but I can soon put the numbers back.
>>>
>>>> - with wireshark if your firsts DNS requests receive errors, so
>>>> ekiga
>>>>
>>> Ok, I am familiar with wireshark, but have not done this yet. What
>>> would be the best ports to put it on?
>>> dns(53) or 5060?
>> Close network-using applications (such as icedove/thuderbird).  You
>> start wireshark, listen to your interface, start ekiga, wait for the
>> flood, stop listening in wireshark.  That's all.
>>
> Ok, I now have a wireshark trace from a machine I can dial from using
> 3.0.1 and another machine with 3.2.6 which fails. 
>  
> Comparing the two I find this PUBLISH request.
> 
> 
> PUBLISH sip:99999999 sip internode on net SIP/2.0
> CSeq: 73 PUBLISH
> Via: SIP/2.0/UDP 192.168.1.2:5066;branch=z9hG4bK76c50d8f-87bf-de11-98df-0025d35ead70;rport
> User-Agent: Ekiga/3.2.6
> From:
> <sip:99999999 sip internode on net>;tag=e0980c8f-87bf-de11-98df-0025d35ead70
> Call-ID: d2e4f18e-87bf-de11-98df-0025d35ead70 lbnc To:
> <sip:99999999 sip internode on net> Contact:
> <sip:99999999 192 168 1 2:5066> Expires: 500
> Event: presence
> Content-Type: application/pidf+xml
> Content-Length: 343
> Max-Forwards: 70
> 
> <?xml version="1.0" encoding="UTF-8"?>
> <presence xmlns="urn:ietf:params:xml:ns:pidf"
> entity="pres:99999999 sip internode on net"> <tuple
> id="sip:99999999 sip internode on net_on_lbnc"> <note>online</note>
> <status>
> <basic>open</basic>
> </status>
> <contact priority="1">99999999 sip internode on net</contact>
> </tuple>
> </presence>
> SIP/2.0 405 Method Not Allowed
> CSeq: 73 PUBLISH
> Via: SIP/2.0/UDP
> 192.168.1.2:5066;received=202.78.39.96;branch=z9hG4bK76c50d8f-87bf-de11-98df-0025d35ead70;rport=5066
> From:
> <sip:99999999 sip internode on net>;tag=e0980c8f-87bf-de11-98df-0025d35ead70
> Call-ID: d2e4f18e-87bf-de11-98df-0025d35ead70 lbnc To:
> <sip:99999999 sip internode on net>;tag=aprqngfrt-8jnrul00000i4
> Allow: INVITE,ACK,BYE,REGISTER,CANCEL,PRACK,INFO,SUBSCRIBE,NOTIFY,UPDATE
> 
> I do not understand what it is trying to publish, but PUBLISH does not
> appear in the Allow string.

So sending a PUBLISH request while not having it put in the Allows field
is a bug?

Julien, could you take a look?  It's in
./lib/engine/components/opal/sip-endpoint.cpp:

f342bafd        (Julien Puydt   2009-08-16 22:18:01 +0200       325)
  data += "<status>\r\n";
f342bafd        (Julien Puydt   2009-08-16 22:18:01 +0200       326)
  data += "<basic>";
f342bafd        (Julien Puydt   2009-08-16 22:18:01 +0200       327)
  data += "open";
f342bafd        (Julien Puydt   2009-08-16 22:18:01 +0200       328)
  data += "</basic>\r\n";
f342bafd        (Julien Puydt   2009-08-16 22:18:01 +0200       329)
  data += "</status>\r\n";

-- 
Eugen