[OpenSIPS-Users] Weird behaviour

Thu Feb 10 21:41:01 CET 2011

Adrian,

I was just thinking about the implementing no response for INVITE a
little more...
You would want to handle the response checking similar to the
register.  If not found in the cache where you check the location
table if there is a registered user at the source ip.
That way it can handle opensips reboots and other situations where the
cache is lost or unavailable. Like a memcached server fails.
Advantage to using external memcached vs local cache would be that
cache would not be cleared on opensips restart.

Dave

On Thu, Feb 10, 2011 at 11:16 AM, Dave Singer <dave.singer at wideideas.com> wrote:
> I've found that generally they start out with the sip NOTIFY or
> OPTIONS message. So recently I set in the script to drop them from
> sources I'm not expecting them from. Might not work so well for some
> situation like ATA's sending pings for nat keep alives. But for the
> nat to keep open, generally it doesn't need a response, just as long
> as they keep sending the packets. Some devices I've seen actually send
> essentially an empty packet to the sip port, just enough to keep the
> nat alive but opensips just discards it because it is empty.
> The one I do send a reply to is my network monitoring server. Kind of
> helpful to know when things stop responding. :-)
> If an ATA model need to actually get a reply you could on registration
> check the model listed in the sip agent header and use localcache or
> memcached to store the source IP as ok to respond to. See
> http://www.opensips.org/Resources/DocsCoreFcn16#toc98
> cache_store and cache_fetch
> at registration something like
>   save("location");
>   cache_store("local", "ping_ok_$si", "ok", 86000);
>  and at ping
>   if ( $rm =~ "OPTIONS|NOTIFY" ) {
>     if( $si == "<monitor server>" || $cache_fetch("local",
> "pingok_$si", $avp(i:5)) {
>        sl_send_reply("200", "Ok");
>     }
>     drop;
>  }
>
> Might not need pike if they never start the brute force scan because
> they didn't get the initial reply.
> I just came up with this the other day so it is an unproved theory.
> The other day I left a packet capture running over night on the
> testing server and in the morning I saw all the failed register
> attempts. I looked back to the first packet from the registering
> source and found the first one was an OPTIONS packet.... and thus my
> theory.
>
> Could apply it to INVITE and other messages. For registrations if
> there wasn't a hit in the cache you would want to do a db lookup to
> see if the from user is one of yours. But generally that would only be
> for a first time registration since registrations usually happen every
> 30 min. (This is just brainstorming) ;-)
> Let me know if you implement some of it and what results you find.
>
> Dave
>
>
> On Thu, Feb 10, 2011 at 10:28 AM, Adrian Vasile <yoyo at opennet.ro> wrote:
>> I know of these issues. And all client are either behind NAT either separate
>> voice vlans.
>> As for securing the proxy. What methods either than Pike combined with
>> fail2ban would you advise?
>>
>>
>> And I finally found the culprit. "Auth INVITE":
>> "When enabled, authorization is required for initial incoming INVITE
>> requests from the SIP proxy."
>> On Feb 10, 2011, at 6:57 PM, Dave Singer wrote:
>>
>> Adrian,
>>
>> There are lots of people out there with servers doing sip scans to see
>> if an ip will respond to a sip ping (NOTIFY or OPTIONS message). Then
>> they will either try to send register and/or invites for all sorts of
>> numbers trying to get a hit. Of course the invites are not actual
>> calls so if the sip scanner gets an ATA, the customer answers the
>> phone and there is no one there. Depending on the scanner it may keep
>> trying through it's whole list of common sip source accounts. Then it
>> can get interesting. The scanner would then mark the IP as a success
>> and the hacker can then start trying to send calls through it. Though
>> likely they would try a call to something like a Home Depot number and
>> when the customer answers they just say sorry wrong number and mark
>> the IP off their list. Customer is left alone till the next scanner
>> comes sniffing.
>> So ATA's many times have settings for not answering calls from places
>> that shouldn't be sending them calls. The options are usually
>> something like "calls ok: from register server, from proxy server,
>> call to registered user, auth call" or similar.
>> See what you can find in the docs for that model.
>>
>> Dave
>>
>> On Thu, Feb 10, 2011 at 5:07 AM, Adrian Vasile <yoyo at opennet.ro> wrote:
>>
>> Hi,
>>
>> I attached the trace.
>>
>>
>> why does the cisco spa ask for authorization?
>>
>> Thanks,
>>
>> Adrian Vasile
>>
>> yoyo at opennet.ro
>>
>> On Feb 10, 2011, at 12:42 PM, Laszlo wrote:
>>
>> Hi Adrian,
>>
>> 2011/2/10 Adrian Vasile <yoyo at opennet.ro>
>>
>> Hello all,
>>
>> Maybe it has happened to you too.. I've got a couple of cisco spa504g
>>
>> everything is fine with them, registering, calling out, but there seems to
>>
>> be a problem with the "calling in feature"..
>>
>> When I try to call the spa's all they return is 403 Forbidden. Any ideas
>>
>> how I could remedy the situation?
>>
>>
>> Try to capture one call with ngrep, and post here the output.
>>
>> Use ngrep like this: ngrep 'xxx' port 5060 -Wbyline -q -dany -t >
>>
>> mytrace.txt
>>
>> (where xxx is the number/extension what you going to trace)
>>
>>
>>
>>
>> Thanks,
>>
>> Adrian Vasile
>>
>> yoyo at opennet.ro
>>
>>
>>
>>
>> _______________________________________________
>>
>> Users mailing list
>>
>> Users at lists.opensips.org
>>
>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>
>> _______________________________________________
>>
>> Users mailing list
>>
>> Users at lists.opensips.org
>>
>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>
>>
>>
>> _______________________________________________
>>
>> Users mailing list
>>
>> Users at lists.opensips.org
>>
>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>
>>
>>
>> _______________________________________________
>> Users mailing list
>> Users at lists.opensips.org
>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>
>> Adrian Vasile
>> yoyo at opennet.ro
>>
>>
>>
>> _______________________________________________
>> Users mailing list
>> Users at lists.opensips.org
>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>
>>
>