[OpenSIPS-Users] Weird behaviour

[Adrian Vasile]

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