[OpenSIPS-Users] Weird behaviour
Juri Nysschen
juri at greydotelecom.com
Mon Feb 14 09:59:51 CET 2011
yeah, you're right, there's also probably no harm in filtering SUBSCIBE as
well...
Regards
Juri Nysschen
-----Original Message-----
From: users-bounces at lists.opensips.org
[mailto:users-bounces at lists.opensips.org] On Behalf Of Dave Singer
Sent: Monday, February 14, 2011 10:42 AM
To: OpenSIPS users mailling list
Subject: Re: [OpenSIPS-Users] Weird behaviour
Juri,
Thanks for the compliment!
Great addition yourself!
I hadn't looked at the premissions module before and it looks to be a
good resource for potentially many tasks.
Using it as you show would be much faster than trying to do db lookup
and cache_store method!
Only one thing, you are only showing to do it for OPTIONS, what about
NOTIFY?
Dave,
On Sun, Feb 13, 2011 at 11:40 PM, Juri Nysschen <juri at greydotelecom.com>
wrote:
> 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
>
>
> _______________________________________________
> 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
More information about the Users
mailing list