yeah, you're right, there's also probably no harm in filtering SUBSCIBE as well...
Regards Juri Nysschen -----Original Message----- From: users-boun...@lists.opensips.org [mailto:users-boun...@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 <j...@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-boun...@lists.opensips.org > [mailto:users-boun...@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 <y...@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 >>> y...@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.sin...@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 <y...@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 <y...@opennet.ro> > wrote: >>>>>> >>>>>> Hi, >>>>>> >>>>>> I attached the trace. >>>>>> >>>>>> >>>>>> why does the cisco spa ask for authorization? >>>>>> >>>>>> Thanks, >>>>>> >>>>>> Adrian Vasile >>>>>> >>>>>> y...@opennet.ro >>>>>> >>>>>> On Feb 10, 2011, at 12:42 PM, Laszlo wrote: >>>>>> >>>>>> Hi Adrian, >>>>>> >>>>>> 2011/2/10 Adrian Vasile <y...@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 >>>>>> >>>>>> y...@opennet.ro >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> >>>>>> Users mailing list >>>>>> >>>>>> Users@lists.opensips.org >>>>>> >>>>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >>>>>> >>>>>> _______________________________________________ >>>>>> >>>>>> Users mailing list >>>>>> >>>>>> Users@lists.opensips.org >>>>>> >>>>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> >>>>>> Users mailing list >>>>>> >>>>>> Users@lists.opensips.org >>>>>> >>>>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Users mailing list >>>>>> Users@lists.opensips.org >>>>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >>>>>> >>>>>> Adrian Vasile >>>>>> y...@opennet.ro >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Users mailing list >>>>>> Users@lists.opensips.org >>>>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >>>>>> >>>>>> >>>>> >>>> >>>> _______________________________________________ >>>> Users mailing list >>>> Users@lists.opensips.org >>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >>> >>> >>> >>> _______________________________________________ >>> Users mailing list >>> Users@lists.opensips.org >>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >>> >> >> _______________________________________________ >> Users mailing list >> Users@lists.opensips.org >> http://lists.opensips.org/cgi-bin/mailman/listinfo/users > > Adrian Vasile > y...@opennet.ro > > > > > _______________________________________________ > Users mailing list > Users@lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > > > _______________________________________________ > Users mailing list > Users@lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > _______________________________________________ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users _______________________________________________ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users