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