Posts Tagged ‘acmepacket’

Oracle SBC: prevent OPTIONS forwarding

Thursday, May 6th, 2021

A quick howto with illustrations of what you need to do to prevent OPTIONS requests from being forwarded by your OracleSBC/AcmePacket from outside to the core of your VoIP network.

Just specify correct SIP methods in the policy-attributes of local-policy and add one more policy-attribute for OPTIONS.

Specifying ‘next-hop’ as ‘0.0.0.0’ will make SBC to reply 404.

Specifying ‘next-hop’ as ‘*’ will make SBC to reply 403.

Without these settings your SBC will forward OPTIONS sent by session-agents in the Internet (e.g. VoIP providers with which you configured SIP trunking) to your next-hops, usually this is your core network. Finally, such OPTIONS requests are answered not by SBC, but by your inner VoIP servers. These replies are not just undesirable, they also contain User-Agent header of your core equipment and the Contact header indicates their IP address.

You may also skip the creation of a separate policy-attribute for OPTIONS method, just leaving the one for every other methods you need (e.g. INVITE, PRACK, REFER, UPDATE). In this case your SBC will reply “480 No Routes Found”:

Tags:, , , , ,
Posted in Uncategorized | Comments Closed

AcmePacket: go on rejecting!

Thursday, May 19th, 2016

One more post about INVITE rejecting.

The task: reject malicious SIP traffic coming from some country to our number. All INVITEs contain a From: header with 12-digits number starting with 666. The may also contain a plus sign at the beginning or 810, or +810.

It is also important to set a ‘new-value’ parameter, containing a status code and SIP description (in form of “Code:Description”), as some (or maybe most) PBXses/softswitches/proxies go on sending INVITEs if we just do ‘action reject’. After answering from AcmePacket with something like “403 Forbidden” the remote side stops sending endless INVITEs to AcmePacket.

acme_reject_with_prefix

Part of sip-manipulation:

        header-rule
                name                                    dropHACKERS
                header-name                             From
                action                                  manipulate
                comparison-type                         pattern-rule
                msg-type                                any
                methods                                 INVITE
                match-value                             
                new-value                               
                element-rule
                        name                                    dropHACKERS1
                        parameter-name                          From
                        type                                    uri-phone-number-only
                        action                                  reject
                        match-val-type                          any
                        comparison-type                         pattern-rule
                        match-value                             666[0-9]{9}$
                        new-value                               403:Forbidden

This is how it looks like after rejecting malicious INVITE with “403 Forbidden”:
acme_reject_with_prefix2

Tags:, ,
Posted in Uncategorized | Comments Closed

acmepacket: import/export HMR

Tuesday, February 9th, 2016 
conf t -> session-router -> sip-manipulation

Select some HMR and then do:

export %filename%

After that a %filename%.gz will appear under /code/imports/ directory. And you can download it via FTP/SFTP.

It is also possible to import sip-manipulation rules. Put your .gz file with the same structure to /code/imports/ , then go to conf t -> session-router -> sip-manipulation and do:

import %filename%.gz

Tags:, , , , , , ,
Posted in Uncategorized | Comments Closed

AcmePacket: Reject calls from subscribers with hidden cell number

Thursday, February 26th, 2015

Depending on GSM operator the values in SIP headers may vary. In my case if a subscriber activated the ability to hide cell number, the ‘uri-user’ parameter in SIP-header ‘From’ contains not cell number but ‘anonymous’. I had a task to reject such calls.

There already were 2 header-rules – one doing storing of ‘To’ headers’ values with VoIP provider’s DIDs inside , and the second – manipulating the ‘From’ headers, according to the stored values.

If I added the 3rd header-rule (last in the list) trying to reject anonymous calls, it haven’t worked, so it was necessary to keep it on the top of header-rules. (the ‘move’ command doesn’t work for me, though I’ve read in one Oracle/AcmePacket HMR guide that it’s possible, maybe my firmware does not support it)

Here’s the rule itself:

header-rule
		name                           rejectAnonymous
		header-name                    From
		action                         manipulate
		comparison-type                case-insensitive
		msg-type                       request
		methods                        INVITE
		match-value                    
		new-value                      
		element-rule
			name                           rejAnonymous
			parameter-name                 From
			type                           uri-user
			action                         reject
			match-val-type                 any
			comparison-type                case-insensitive
			match-value                    Anonymous
			new-value

Have a look at these nice screenshots demonstrating the initial INVITE from anonymous:

invite_anonymous

… and rejecting this call by AcmePacket 4250 with ‘400 Bad Request’ response:

400_bad_request

Tags:, , , , , ,
Posted in Uncategorized | Comments Closed

AcmePacket: reject redirected calls

Friday, February 20th, 2015

What to do if somebody set up call redirect from his number to yours one, but you do not want to accept such calls?

According to RFC5806 – Diversion Indication in SIP,

The Diversion header SHOULD be added when a SIP proxy server, SIP
redirect server, or SIP user agent changes the ultimate endpoint that
will receive the call.

So, you have to reject INVITEs with Diversion header. This is how it looks like on the AcmePacket. One more header-rule (if you already have any) in sip-manipulation rule:

header-rule
	name                           reject_diversion
	header-name                    Diversion
	action                         manipulate
	comparison-type                case-sensitive
	msg-type                       request
	methods                        INVITE
	match-value                    
	new-value                      
	element-rule
		name                           rej_diversion
		parameter-name                 
		type                           header-value
		action                         reject
		match-val-type                 any
		comparison-type                pattern-rule
		match-value                    ^.*$
		new-value

You may also add something like “603:Decline” to “new-value” parameter.

Or even like this, without any responce codes and element-rules:

header-rule
                name                                    rejectDiversion
                header-name                             Diversion
                action                                  reject
                comparison-type                         boolean
                msg-type                                request
                methods                                 INVITE
                match-value                             
                new-value

Tags:, , ,
Posted in Uncategorized | Comments Closed

AcmePacket: session constraints

Wednesday, December 31st, 2014

# show sessions or # monitor session gives you a whole statistics of active sessions on your session director.

What to do if you want to see the number of sessions on each session-agent? Use # show sipd agents

This extremely useful command can help you to destinguish the suspiciously high (for your network) connections count on a concrete session-agent. And you will see the problem agent while being DDoSed or under real high load. Or just see sessions per session-agent.

# show sessions
The left column shows the number of active sessions on your Session Director. The right one demonstrates the highest number of sessions ever been on SD:
constr_show_sessions

This is how # show sipd agents looks like:
constr_show_sipd_agents

The letter I in the second column means that the session agent is ‘in service’.
The letter O means that it’s ‘out of service’, unused.
The letter C means that constraints are configured and are used right now: the number of sessions is higher than allowed. The ‘Active’ column shows the number of sessions. The column ‘ConEx’ is ‘Constraints exceeded’ – the number of ignored due to the limitations sessions for the last 100 seconds.
As you can see, session-agents may be inbound and outbound. In this example we see only inbound, they are peers with SIP providers. The outbound are peers with Asterisk nodes in the core of the network, they also have such statistics.

It is possible to see a detailed statistics for any of the configured session-agents:
# show sipd agents %ip address% or # show sipd agents %session-agent name%
Have a look at session-agent which is marked with I letter (in service):
constr_show_sipd_agents_i

And one more example for the session-agent with ConEx – constraints exceeded:
constr_show_sipd_agents_c

Constraints can be configured either in # configure terminal -> session-router -> session-constraints and then applying them variant_1) on the sip-interface (# configure terminal -> session-router -> sip-interface -> constraint-name), variant_2) on a realm (# conf t -> media-manager -> realm-config), or for the session-agent directly.

Here’s an example of a directly applied (but disabled) constraint on a session-agent:

constr_ses_ag_constr
Just be sure to set ‘constraints enabled‘ in your session-agent, not only the value, otherwise they will not be applied.

Tags:, ,
Posted in Uncategorized | Comments Closed