Documentation

Documentation.Tutorials-Topology-Hiding History

Hide minor edits - Show changes to markup

April 13, 2017, at 12:11 PM by ionutionita92 -
March 11, 2015, at 06:57 PM by 89.120.101.121 -
Changed lines 43-45 from:
            xlog("Succesfully matched this request to a topology hiding dialog. Calller side callid is $ci , callee side callid is $TH_callee_callid \n");
to:
            xlog("Succesfully matched this request to a topology hiding dialog. \n");
            xlog("Calller side callid is $ci \n");
            xlog("Callee side callid  is $TH_callee_callid \n");
March 11, 2015, at 06:57 PM by 89.120.101.121 -
Changed line 43 from:
            xlog("Succesfully matched this request to a topology hiding dialog \n");
to:
            xlog("Succesfully matched this request to a topology hiding dialog. Calller side callid is $ci , callee side callid is $TH_callee_callid \n");
March 11, 2015, at 06:42 PM by 89.120.101.121 -
Changed lines 17-19 from:

Also, the topology_hiding module can help ease integration by propagating various parts of the Contact header from one side to the other. The Contact username can be propagated ( eg. useful when you are dipping against LRN servers, but don't want to disclose your full topology to the service provider ). Also, various Contact header parameters can be passed, in order to allow for end-to-end features that rely on such params.

to:

Also, the topology_hiding module can help ease integration by propagating various parts of the Contact header from one side to the other. The Contact username can be propagated ( eg. useful when you are dipping against LRN servers, but don't want to disclose your full topology to the service provider ). Also, various Contact header parameters can be passed, in order to allow for end-to-end features that rely on such params.

See the full module README for all the available parameters and functions.

March 11, 2015, at 06:39 PM by 89.120.101.121 -
Added lines 29-71:
loadmodule "topology_hiding.so"


route {

    ....
    ....
    ....

    if (has_totag()) {
        if (topology_hiding_match()) {
            xlog("Succesfully matched this request to a topology hiding dialog \n");
            t_relay();
            exit;
        } else {
            if ( is_method("ACK") ) {
                if ( t_check_trans() ) {
                    t_relay();
                    exit;
                } else
                    exit;
            }
            sl_send_reply("404","Not here");
            exit;
        }
    }

    ....
    ....
    ....

    # if it's an INVITE dialog, we can create the dialog now, will lead to cleaner SIP messages
    if (is_method("INVITE"))
        create_dialog();


    # we do topology hiding, preserving the Contact Username and also hiding the Call-ID
    topology_hiding("UC");
    t_relay();
    exit;
}
March 11, 2015, at 05:08 PM by 89.120.101.121 -
Added lines 18-27:

How It Works

The module can work on top of the dialog and TM modules, or just on top of the TM module.

When running strictly on top of the TM module, the topology hiding SIP messages will be bigger when compared to the initial requests ( since OpenSIPS will encode all the needed information in a parameter of the Contact header ), but all type of SIP requests and dialogs will be supported ( INVITE dialogs, Presence dialogs, SIP MESSAGE, etc ).

When running on top of the DIALOG module, you will get shorter messages ( all the removed headers will be kept internally in the dialog module ) , but you will only be able to hide INVITE based dialogs.

Example Script

March 11, 2015, at 04:57 PM by 89.120.101.121 -
Changed line 17 from:

Also, the topology_hiding module can ease integration by propagating various parts of the Contact header from one side to the other ( Username and various Contact header parameters currently can be passed )

to:

Also, the topology_hiding module can help ease integration by propagating various parts of the Contact header from one side to the other. The Contact username can be propagated ( eg. useful when you are dipping against LRN servers, but don't want to disclose your full topology to the service provider ). Also, various Contact header parameters can be passed, in order to allow for end-to-end features that rely on such params.

March 11, 2015, at 04:55 PM by 89.120.101.121 -
Changed lines 14-18 from:

Optionally, the module can also hide the Call-ID on the outbound side, since often enough the Call-ID will contain the IP of the traffic originator.

to:


Optionally, the module can also hide the Call-ID on the outbound side, since often enough the Call-ID will contain the IP of the traffic originator.

Also, the topology_hiding module can ease integration by propagating various parts of the Contact header from one side to the other ( Username and various Contact header parameters currently can be passed )

March 11, 2015, at 04:53 PM by 89.120.101.121 -
Changed lines 9-14 from:

Topology hiding is usually utilized as an approach to enhance SIP network security. Since, in regular SIP traffic, critical IP address data is forwarded to other networks, the concern is that third parties can use that information in order to direct attacks at your internal SIP network.

to:

Topology hiding is usually utilized as an approach to enhance SIP network security. Since, in regular SIP traffic, critical IP address data is forwarded to other networks, the concern is that third parties can use that information in order to direct attacks at your internal SIP network.

Current Features

By default, when engaged, the module will hide the VIA, Record-Route, Route and Contact headers. VIA, Record-Route and Route headers will be fully removed when routing message from one side to the other, while the Contact header will be mangled to point to the outgoing interface IP.
Optionally, the module can also hide the Call-ID on the outbound side, since often enough the Call-ID will contain the IP of the traffic originator.

March 11, 2015, at 01:40 PM by 89.120.101.121 -
Changed lines 8-9 from:

The purpose of this tutorial is to help you understand how the topology_hiding module works and also how it should be used. Topology hiding is utilized as an approach to enhance SIP network security. Since, in regular SIP traffic, critical IP address data is forwarded to other networks, the concern is that third parties can use that information in order to direct attacks at your internal SIP network.

to:

The purpose of this tutorial is to help you understand how the topology_hiding module works and also how it should be used.
Topology hiding is usually utilized as an approach to enhance SIP network security. Since, in regular SIP traffic, critical IP address data is forwarded to other networks, the concern is that third parties can use that information in order to direct attacks at your internal SIP network.

March 11, 2015, at 01:39 PM by 89.120.101.121 -
Added lines 6-9:

Tutorial Overview

The purpose of this tutorial is to help you understand how the topology_hiding module works and also how it should be used. Topology hiding is utilized as an approach to enhance SIP network security. Since, in regular SIP traffic, critical IP address data is forwarded to other networks, the concern is that third parties can use that information in order to direct attacks at your internal SIP network.

March 11, 2015, at 01:30 PM by 89.120.101.121 -
Added lines 1-5:
Documentation -> Tutorials -> Topology Hiding with OpenSIPS

This page has been visited 25983 times. (:toc-float Table of Content:)



Page last modified on April 13, 2017, at 12:11 PM