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 [email protected] 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 <[email protected]> > 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 <[email protected]> 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 <[email protected]> wrote: >>> >>> Hi, >>> >>> I attached the trace. >>> >>> >>> why does the cisco spa ask for authorization? >>> >>> Thanks, >>> >>> Adrian Vasile >>> >>> [email protected] >>> >>> On Feb 10, 2011, at 12:42 PM, Laszlo wrote: >>> >>> Hi Adrian, >>> >>> 2011/2/10 Adrian Vasile <[email protected]> >>> >>> 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 >>> >>> [email protected] >>> >>> >>> >>> >>> _______________________________________________ >>> >>> Users mailing list >>> >>> [email protected] >>> >>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >>> >>> _______________________________________________ >>> >>> Users mailing list >>> >>> [email protected] >>> >>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >>> >>> >>> >>> _______________________________________________ >>> >>> Users mailing list >>> >>> [email protected] >>> >>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >>> >>> >>> >>> _______________________________________________ >>> Users mailing list >>> [email protected] >>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >>> >>> Adrian Vasile >>> [email protected] >>> >>> >>> >>> _______________________________________________ >>> Users mailing list >>> [email protected] >>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >>> >>> >> > > _______________________________________________ > Users mailing list > [email protected] > http://lists.opensips.org/cgi-bin/mailman/listinfo/users _______________________________________________ Users mailing list [email protected] http://lists.opensips.org/cgi-bin/mailman/listinfo/users
