[OpenSIPS-Users] Weird behaviour

[Dave Singer]

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
>
>