[OpenSIPS-Users] Weird behaviour

Adrian Vasile yoyo at opennet.ro
Sat Feb 12 08:25:34 CET 2011 

That's why I dropped the ideea of having numbered usernames…

On Feb 11, 2011, at 10:45 PM, Dave Singer wrote:

> Adrian,
> 
> Probably want to only respond to registers that are to valid user
> accounts, drop the rest, as they start scanning with like 100, 101,
> ....., 5000, .... etc
> 
> Dave
> 
> On Fri, Feb 11, 2011 at 6:25 AM, Adrian Vasile <yoyo at opennet.ro> wrote:
>> Hi Dave,
>> 
>> Yeah, you're right.. Basically allow only REGISTER requests from anywhere and
>> the rest check the source ip.
>> Great ideea.
>> 
>> I will implement it as soon as possible.
>> 
>> Thanks,
>> Adrian Vasile
>> yoyo at opennet.ro
>> 
>> 
>> On Feb 10, 2011, at 10:41 PM, Dave Singer wrote:
>> 
>>> 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
>>>>> 
>>>>> 
>>>> 
>>> 
>>> _______________________________________________
>>> 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

More information about the Users mailing list