Network Namespaces In Linux Kernel

 

Introduction

Each kernel network namespace has its own network devices (even the loopback interface), IP addresses, firewall rules, the “/proc/net” and /sys/class/net directory trees, sockets, IP routing tables, port numbers,…etc

indexclone() is a system call used to create a child process. If the CLONE_NEWNET flag is set, then the child process will be created in a new network namespace. Execute system(“ip link”) and system(“ip netns”) in the child process and in the parent to see the difference.

unshare() system call which creates a new namespace and adds the current process to it.

setns() system call is used to join an existing namespace.

You can define a virtual network device (veth) in the namespace and you can create a tunnel between two virtual network devices from different namespaces. The implementation of this is like creating a pipe. To connect the namespace to the internet, a bridge need to be created in the root namespace and the virtual device (veth) in the child namespace will be linked/bounded to the bridge. The physical network device can be assigned only to the root namespace. Instead of creating a bridge, you can use IP forwarding with NAT rules in the root namespace.

The namespace is addresses by it name or by PID of a process inside the namespace.

If a service in a namespace has been infected, this will not affect other services in other namespaces. This is due to the isolation property.

Add New Network Namespace

We can use the “ip” networking configuration tool to play with namespaces.  The namespace can persist even if it has not processes running in it. To add new empty namespace:

# ip netns add BinanNameSpace

“BinanNameSpace” is the name of the new created namespace. A bind mount is created for “BinanNameSpace” under “/var/run/netns”.

Get The Current Namespaces

To get the current namespaces, execute: “ip netns” or “ls /var/run/netns

BinanNameSpace
qdhcp-ae4d3669-d1ab-4133-8ea6-059611dc524e
qrouter-f96c719a-56e9-4b52-b2cb-da326fc1a429

List The Interfaces In The Namespace

To list the interfaces inside the namespace, execute:

# ip netns exec BinanNameSpace ip link list

1: lo: <LOOPBACK> mtu 65536 qdisc noop state DOWN mode DEFAULT group default
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00

Note we have only loopback interface and it is down so we cannot ping it:

# ip netns exec BinanNameSpace ping 127.0.0.1

connect: Network is unreachable

To make the loopback interface up: # ip netns exec BinanNameSpace ip link set dev lo up

# ip netns exec BinanNameSpace ping 127.0.0.1

PING 127.0.0.1 (127.0.0.1) 56(84) bytes of data.
64 bytes from 127.0.0.1: icmp_seq=1 ttl=64 time=0.044 ms
64 bytes from 127.0.0.1: icmp_seq=2 ttl=64 time=0.035 ms
64 bytes from 127.0.0.1: icmp_seq=3 ttl=64 time=0.034 ms
^C
— 127.0.0.1 ping statistics —
3 packets transmitted, 3 received, 0% packet loss, time 2000ms
rtt min/avg/max/mdev = 0.034/0.037/0.044/0.008 ms

Create Virtual Network Device In The Namespace

To create a virtual network device (veth1) in the “BinanNamespace” and make it as a peer to veth0 in the root namespace:

# ip link add veth0 type veth peer name veth1

# ip link set veth1 netns BinanNameSpace

Set IP addresses To The Virtual Network Devices

For the veth0 in the root namespace: # ifconfig veth0 11.0.0.2/24 up

For the veth1 in the “BinanNameSpace”: # ip netns exec BinanNameSpace ifconfig veth1 11.0.0.1/24 up

Now to check the interface veth0:

# ifconfig veth0

veth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
inet 11.0.0.2  netmask 255.255.255.0  broadcast 11.0.0.255
…..

To check the interface eth1:

# ip netns exec BinanNameSpace ifconfig veth1
veth1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
inet 11.0.0.1  netmask 255.255.255.0  broadcast 11.0.0.255
……

Connection Test

To test the connection between the root namespace and “BinanNameSpace”, we ping in both direction:

From the root(veth0: 11.0.0.2) to BinanNameSpace(veth1:11.0.0.1):

# ping 11.0.0.1
PING 11.0.0.1 (11.0.0.1) 56(84) bytes of data.
64 bytes from 11.0.0.1: icmp_seq=1 ttl=64 time=0.042 ms
64 bytes from 11.0.0.1: icmp_seq=2 ttl=64 time=0.036 ms
64 bytes from 11.0.0.1: icmp_seq=3 ttl=64 time=0.044 ms
^C
— 11.0.0.1 ping statistics —
3 packets transmitted, 3 received, 0% packet loss, time 1999ms
rtt min/avg/max/mdev = 0.036/0.040/0.044/0.008 ms

From BinanNameSpace (veth1:11.0.0.1) to the root namespace (veth0: 11.0.0.2):

# ip netns exec BinanNameSpace ping 11.0.0.2

PING 11.0.0.2 (11.0.0.2) 56(84) bytes of data.
64 bytes from 11.0.0.2: icmp_seq=1 ttl=64 time=0.042 ms
64 bytes from 11.0.0.2: icmp_seq=2 ttl=64 time=0.034 ms
64 bytes from 11.0.0.2: icmp_seq=3 ttl=64 time=0.038 ms
^C
— 11.0.0.2 ping statistics —
3 packets transmitted, 3 received, 0% packet loss, time 1999ms
rtt min/avg/max/mdev = 0.034/0.038/0.042/0.003 ms

Delete A Namespace

To delete the namespace, execute: # ip netns delete BinanNameSpace


 More Information


SIP Stress Testing -Part 2 (SIPSAK)

.

This is part 2 of the “SIP Stress Testing” topic. In Part 1, I have talked about the definition of the stress, opensipsctl (command line tool) and OpenSIPS-CP (Web tool) and how they are used in testing. In this part, i will talk about SIPSAK. SIPSAK is a command line tool used by SIP administrators to test the performance and the security of the SIP servers or user agents. SIPSAK is a SIP traffic generator. It generates SIP requests and sends them to the target addressed by SIP-URI . To download SIPSAK on Fedora, simply:

 # yum install sipsak

SIPSAK runs in the following modes:

♣ Default mode: Using the OPTIONS SIP method, you can  ping a target addressed by SIP-URI.

♣ Traceroute mode (-T): This is useful for learning the request’s path. The number of SIP servers on the way to the destination is counted plus the round trip time of each request is printed out.

♣ Message mode (-M): Send a short message using MESSAGE SIP request. The content of the message will be set using the option (-B).

♣ Usrloc mode (-U): Register the user addressed by SIP-URI (Set by option -s).

♣ Randtrash mode (-R) :keeps sending randomly corrupted messages to torture a SIP server’s parser. OPTIONS requests with increasing numbers of randomly crashed characters are sent to the server.

♣ Flood Mode (-F): keeps sending requests to a SIP server at high pace. OPTIONS requests with increasing CSeq numbers are sent to the server.

Current SIPSAK is missing support for the Record-Route and Route headers and IPv6 is not supported. At the stressed SIP server’s side, you need monitoring and analyzing tool which display the state of the server as numbers and figures.

Examples

  • Ping the target “test1”: #sipsak -s sip:test1@testdomain.org. In this tutorial i will ping the user test1@10.0.0.9.

Here is the messages sent by SIPSAK and captured by SIPTRACE. See the User-Agent header field in the traced SIP message (User-Agent: sipsak 0.9.6). The message is taken from OpenSIPPS-CP SIPTRACE page.

If the server allows pinging. It will relay the ping message (SIP OPTION Request) and the response from the pinged target will come back to SIPSAK through the SIP server. The response will look like:

sipsak3The User-Agent: Jitsi2.2.4603.9615Linux . The target user (test1) must be registered otherwise you will get an error response message sent from the server (in case the server is programmed to do this in its routing script). The test server in this tutorial sends “404 Not Found” SIP failure:

sipsak4The server is “OpenSIPS (1.11.2-notls (x86_64/linux))” as written in the server’s response.

If you put the option -F , SIPSAK will flood the server with SIP OPTION Requests.

# sipsak -F  -s sip:test1@testdomain.org

SIPSAK is also used to test the security of the SIP server. In the previous example, flooding the server with OPTIONS SIP Requests (a lot of ping messages) is considered attack because after a short time the SIP service will be not available and the server became unable to handle more SIP requests. The test server in this tutorial sends an error message ” 500 Internal Error” after short time of flooding.

sipsak5Pinging is a way to check that the server is awake and not down. It must be available only for administration’s purposes.

Other SIPSAK examples:

  • Trace a call: # sipsak –T –s sip:test1@testdomain.org
  • Send a message to the user “test1” :# sipsak –M –s sip:test1@testdomain.org –c test2@testdomain.org –B “Message Text”
  • Register the user “test1” # sipsak –U –s sip:test1@testdomain.org

Nagios monitoring tool are good complement to SIPSAK traffic generator.

SO to test the server, generate requests and check the system’s response. If you get something you don’t like, change it and do it again (Make changes, Restart the server, Generate traffic , and Check the server’s response).


More Information


 Next

The Next Part will be about SIPp which is an emulation tool which generates SIP traffic and gives some statistics.