Improving Mobile Core Network Security with Honeynets

IEEE Security & Privacy, July-Aug. 2007, Issue 4, Volume 5,Page(s):40 - 47

Dimitriadis, C.K.;

University of Piraeus

Advisor: Frank Y. S. Lin

Presented by Yu-Shun Wang

Introduction Threat model Feasibility study 3GHNET’s architecture Security analysis Conclusion My applying model

112/04/21 2OPLab@IM, NTU



Despite improved security, core network vulnerabilities continue to threaten third-generation (3G) mobile systems.

To learn what security bottlenecks exist in the 3G network, we first introduce the network architecture.


The 3G core network consists circuit-switched (CS) domain packet-switched (PS) domain Internet Protocol (IP) multimedia subsystem (IMS)

This article focuses on the open security issues in the PS domain.


Cause of vulnerabilities Such vulnerabilities lead to threats

Lack of intrusion detection systems billing attacks via gateway filters.

Inadequate firewall architectures exposure of critical production systems that implement packet switching to attacks.

No security layers exposed GPRS elements used as springboards for critical system attacks.

Uncontrolled communication with roaming partners.

the mobile operator’s core network turned into an extension of a roaming partner’s core network, exposing both to serious attacks.



The above figure gives an overview of the systems in a 3G network affected by a compromised SGSN or GGSN.

The security assessment described in this article also revealed that legacy systems which don’t provide adequate facilities for logging user actions.




A threat model describes the threats that attackers can realize by exploiting vulnerabilities.

We can depict it graphically by using a combination of attack trees, each of which has a root node, leaf nodes, and child nodes.



In AG1, GTP packets with malformed headers might lead to GSSN or SGSN compromise or disruption (such attacks exploit badly configured or nonexistent GTP firewalls).

The compromised GSSN or SGSN can become a springboard on other critical systems.

Other attacks also exploit badly configured or nonexistent GTP firewalls, often with the same results.


No.

description

2 the submission of non-matching addresses between the GTP payload and the assigned address as defined in the Packet Data Protocol (PDP) context handshake.

3 a connection attempt from a roaming partner’s unauthorized or compromised SGSNs or GGSNs.

4 an attempt to connect to target systems in administration ports.

5 an attempt to initiate a great many PDP contexts, which could result in the disruption of a GGSN or SGSN, leading to loss of system availability.

6 a GTP packet with an invalid payload, which could result in packet spoofing and non-permitted sessions.

7 a GTP packet with a payload that contains non-permitted source or destination addresses, which can result in packet spoofing and non-permitted sessions.

8 an over-billing attack based on open sessions in which a specific IP address requests data from a server and releases the IP address, which is then reassigned to a new user. The new user keeps receiving the data and thus gets over-billed.

9 This AG focuses on insider attacks caused by uncontrolled communication between critical systems. 112/04/21 13OPLab@IM, NTU



To study the benefits of implementing 3GHNET, we used concepts from game theory.

We wanted to compare a mobile operator that implements a honeynet with one that doesn’t, and then study different security situations.


We defined a game called 3GHNET-G that is non-cooperative—the mobile operators don’t have a common security infrastructure, and the game is static because players can make simultaneous moves.

3GHNET-G is also a non-zero sum game, meaning that the total benefit to all players isn’t zero because there’s no relationship between one player’s gain and another’s loss.


For our two players, mobile operator 1 (MO1) implements a honeynet architecture, and mobile operator 2 (MO2) doesn’t.

Each player has two possible modes of behavior, depending on whether a security incident compromises the player’s nodes or not: Mode 1 represents compromised node behavior Mode 2 represents normal node behavior


By following this logic we study the gain of implementing a honeynet or not in different security-related situations.

The payoff gets specific values from a definite set P ={P1, P2, …, Pm}. Let each possible payoff Pi (where i = {1, 2, …, m}) be a sum of gains from Table 1, depending on a specific condition.


These gains correspond to the threats described in the previous section.

This corresponds to the knowledge produced by a security architecture that can study attacks and evolve in response to attacker tactics.

This is negative, corresponding to the cost of implementing the honeynet


We define the payoff Pi through the following equation: Pi = a1G1+a2G2+a3G3+a4G4+a5G5.

The parameters an={0, 1}, where n={1, 2, 3, 4, 5}, take a positive value when the player receives the corresponding gain in a specific condition and zero value in the opposite scenario.

A game’s payoff matrix shows what payoff each player will receive at the game’s outcome; it depends on the combined actions of all players.


MO1 receives all the gains.MO2 only receives gain G2 because it’s protected by MO1’s honeynet.MO1 doesn’t receive the G2 gain because MO2 isn’t attacking, but it receives the rest of the gains.MO2 receives gain G2.MO1 receives gains G2, G4, and G5, whereasMO2 receives only gain G3No player receives any positive gain, and MO1 pays for the cost of the honeynet.


The payoff matrix reveals two Nash equilibriums, which we find by searching for the best player response, taking as constant the best response of the other player.

If MO2 is in an attack mode (greatest payoff = 10), for example, then MO1’s attack mode is the one with the greatest payoff (equal to 35).


Analyzing the game’s results, we conclude the following: In the attack–attack situation, all players have a net benefit due to

the honeynet because overall security depends on the security of others. This net benefit could be increased by the proliferation of knowledge gained by MO1.

The two Nash equilibriums reveal that the implementation of a honeynet is useful to both players in either situation.

If MO2 is compromised and forced to attack, MO1 clearly benefits from implementing the honeynet.

MO1 gets the highest payoffs by implementing the honeynet, except when security incidents don’t arise.




The first countermeasure would be to separate the mobile operator’s infrastructure into security zones.

each type of affected element goes in a separate zone.



3GHNET’s honeywalls have the following characteristics: 3GHWALL_1 is a layer-2, non-IP-addressable element that controls and

captures data between emulated SGSN and GGSN and the mobile operator and roaming partner’s real ones.

3GHWALL_ 1 block all traffic from inside 3GHNET to the core network (or roaming partner).

3GHWALL_2 is a layer-2, non-IP-addressable element that controls and captures data between emulated SGSN and GGSN and the Internet.

This honeywall also control and log traffic between the two interfaces, Snort as an intrusion detection system for attacks from the Internet, and Snort_inline in combination with Netfilter as an IDS for attacks launched from the 3GHNET and targeted at the Internet.




we performed several experiments to emulate various attack scenarios:


According to the threat model, the first security layer is the establishment or improvement of GTP firewalls.

As a response, 3GHNET might directly address an attack targeted to it or indirectly contribute to the improvement of the existing GTP firewall configuration through the knowledge gained by its operation.

The second security layer involves the emulation of GGSNs or SGSNs: 3GHNET blocks an attack if it directly targets the emulated GGSN and SGSN, or it can notify a roaming partner about a possible compromise of its infrastructure.




A mobile operator can use our honeynet as: A laboratory for security officers and engineers

to customize, build, and enhance a multilayer security architecture.

A preventive, detective, and reactive security architecture for the PS domain of a 3G core network.

A way to transform a flat architecture into a core network architecture separated into security zones.




Assumption The defender has the complete information of network

that is attacked by several attackers with different budget, capabilities, and strategy.

The attackers are not aware that there are honeypots deployed by the defender in the network, i.e., the attackers have the incomplete information of network.

There are two types of defense resources, the honeypot and non-honeypot. Further, honeypots can be subdivided into two categories, one is for wasting attacker’s resource and learning their tactics, and the other is used to play the role of fake core node to distract the attackers.


Objective Attacker:

The attackers want to compromise the core node under budget constraint.

Defender: The defenders want to minimize the average

compromised probability of the core node.


Given Parameter

Notation DescriptionM The total simulation times for all attacker categoriesK The index set of all attacker categories

D Total possible defense strategiesThe strategies of an attacker, including attack budget, attacker’s capabilities and strategy for compromising next hop.

Sk( , )1 if the kth attacker category can compromise the core node under defense strategy, 0 otherwise, where k K

kA��

D��

kA��


Decision Variable

Objective function

subject to

Notation DescriptionThe strategy of defender to allocate defense resource on each node in the network.D

��

min( , )

k kk K

D

S D A

M

��

��

D D��


A possible scenario we let includes honeypots (both wasting attack

resource and distraction) and other defense resource that raise the attack cost.

For concealing honeypots, we will add artificial traffic in the network to make the amount of flows seem balanced between nodes since attackers may use link utilization as a guide to decide next candidate node.

To accomplish this goal, we control the link capacity and the routing of fake traffic to adjust the utilization.

D��


Given ParameterNotation Description

B The total budget of defender

Bk The total budget of kth type attacker, where k K

N The index set of honeypots for wasting attacker’s resource and learning their behavior

F The index set of honeypots to play the role of fake core nodes

I The index set of all general nodes in the network


Decision variableNotation Description

bi The budget allocated to protect on a node i, where i I

hn The cost of honeypot n deployed in the network ,where n N

hf The cost of honeypot f deployed as the fake core node in the network, where f F

rn The cost of generating and routing fake traffic to a honeypopt n in the network, where n N

rf The cost of generating and routing fake traffic to a honeypopt f in the network, where f F


Decision variableNotation Description

cn The cost of allocating capacity to a honeypopt n for fake traffic in the network, where n N

cf the cost of allocating capacity to a honeypopt f for fake traffic in the network, where f F

a(bi) The cost of attacking a general node i in the network, where i I

a(hn) The cost of attacking a honeypot n in the network, where n N

a(hf) The cost of attacking a honeypot f in the network, where f F


Constraint(IP 1.1.1)

(IP 1.1.2)

(IP 1.1.3)

(IP 1.1.4)

(IP 1.1.5)

(IP 1.1.6)

f n n f n fii N f Fn N n N f F n N f F

b h h r r c c B

0ib B i N

0fh B f F

0nh B n N

0nr B

n N 0

fr B

f F


(IP 1.1.7)

(IP 1.1.8)

(IP 1.1.9)

(IP 1.1.10)

(IP 1.1.11)

(IP 1.1.12)

0nc B n N

0fc B f F

( ) ( ) ( )i n f k

i I n N f F

a b a h a h B

0 ( )i k

i I

a b B

0 ( )n k

n N

a h B

0 ( )f k

f F

a h B


The above scenario is a special one that lead our model clearer.

However, this framework can also be applied in other situations for security analysis.

112/04/21 OPLab@IM, NTU 46/46


Documents

Improving Mobile Core Network Security with Honeynets