[OpenSIPS-Users] Weird behaviour
Juri Nysschen
juri at greydotelecom.com
Mon Feb 14 08:40:19 CET 2011
Hi All
Filtering OPTIONs is brilliant, I've taken it one step further by also
filtering against the opensips address table.
So if the ip is listed in the table OR had registered beforehand there will
be a reply on the OPTIONs message:
if (is_method("OPTIONS")){
xlog("L_INFO","OPTIONS [$fd/$fu/$rd/$ru/$si/]\n");
if (check_source_address("1")) ||
(cache_fetch("local","ip_allowed_$si",$avp(i:60))){
xlog("L_INFO","OPTIONS OK
[$fd/$fu/$rd/$ru/$si/]\n");
sl_send_reply("200", "Got it");
exit;
};
drop;
};
On a successful register:
cache_store("local","ip_allowed_$si","$si",1200);
Regards
Juri Nysschen
-----Original Message-----
From: users-bounces at lists.opensips.org
[mailto:users-bounces at lists.opensips.org] On Behalf Of Adrian Vasile
Sent: Saturday, February 12, 2011 9:26 AM
To: OpenSIPS users mailling list
Subject: Re: [OpenSIPS-Users] Weird behaviour
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
_______________________________________________
Users mailing list
Users at lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
More information about the Users
mailing list