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
