TCP Session Logger
“Nertwork sniffer”
Dan Huru, Mihaita Catalin Barbu, Metin Gemil
Computer Science and Engineering Department
University “Politehnica” of Bucharest
Romania
{Danut.Huru, Mihaita.Barbu, Metin.Gemil}@gmail.com
January 2011
Abstract—In this project we propose a network sniffer that can act
as a detection system and an efficient provider of informatios. The
use of the TCP session logger as a network sniffer is necessary
when there is a need to analyse traffic on the network. TCPSL
makes use of its features to sniff, document and issue alarms for
the incoming and outgoing traffic of the local machine.
Keywords - sniffer, protocol, TCP, monitoring, detetion.
I. INTRODUCTION
The TCP session logger is a software application that
detects different issues in your tcp traffic by obtaining,
manipulating and interpreting data from open tcp sessions.
Tcp session logger listens on an interface and tracks all TCP
sessions it sees. Normally, only general information is
carried forward (seq#/ack#, negotiated SYN/ACK features,
etc). Whenever an anomaly happens - that is a duplicate
ACK, SACK response, out-of-order segment, retransmission
or others; it captures those packets into a tcpdump file for
later deep inspection. This tool is to be deployed on live
hosts and passive monitors to collect reliable condensed data
about real-world behavior of TCP on the global Internet.
Complexity and heterogeneity are hallmarks of network
services today, such as switched networks, load-balanced
configurations, redundant segments, virtual circuits, and
technology improvements to achieve higher speed delivery
transport, e.g. 10Gigabit Ethernet or OC-48. A solution that
provides comprehensive support throughout such mixed
environments, regardless of topology, across the core,
distribution, and access areas of the network is essential.
Monitoring solutions must profile traffic in a manner that
reflects not only the physical network but also the logical
flows of applications as they utilize these services.
Best practices in network monitoring must include the
following:
Incorporation of multiple intelligent data source types:
Performance data can be retrieved from a wide array of
sources, each offering a different level of granularity (see
“Data Sources”). Rather than individual management
solutions to handle each data source type, a performance
management solution should incorporate all types, taking
advantage of the strengths of each to provide an overall
picture of the network and its applications. In doing so, a
significant level of investment protection can be achieved
by leveraging existing data sources where available and
adding advanced instrumentation where greater levels of
detail and application visibility are required – particularly
for the most costly and highest utilized network segments.
Coverage of a broad range of topologies: Today's global
networks are built from diverse network topologies in the
core, distribution, access and storage areas of the network.
To ensure consistent visibility throughout the enterprise, the
performance management solution should support a full
range of topologies, including those in the WAN and LAN,
and those that will be grown into or migrated to, such as
MPLS or 10Gigabit Ethernet.
Visibility into encrypted networks: While technologies
such as VPNs and MPLS are being used for security, among
other purposes, the challenge is that it also obscures the
detailed data most network professionals require for
troubleshooting and traffic engineering. The performance
management product must have a solution for seeing the
details, including the applications that are traversing these
secure links.
Visibility into QoS and other complex network
configurations: Network configurations are becoming
increasingly complex. Deployments such as Quality of
Service implementations, redundant WAN links for fault
tolerance, and Fast EtherChannel and Gigabit EtherChannel
configurations for load balancing have been introduced to
help improve network efficiency. A performance
management solution must transparently measure and report
upon the network activity in aggregate across such
configurations while also retaining the detail of what traffic,
i.e., applications, is flowing across each individual link or
service class.
Visibility into virtual networks: Most networks today
use some form of virtual network technology, typically seen
as VLANs in the LAN, PVCs or DLCIs in the WAN, and
subnets or VRFs in MPLS networks. A performance
management solution must quantify traffic by virtual
network and should provide a full set of application and
volume performance statistics for each virtual segment.
 Continuous 24x7 monitoring that supports real-time and
historical analysis: The performance management solution
must continuously monitor, collect, display and store
information in multiple time frames to meet the needs of the
key performance management tasks. Real-time information
is required for status monitoring and troubleshooting, while
longer-term historical metrics are stored for capacity
planning, trend analysis, baselining, and forecasting.
A. Transmission Control Protocol
The TCP provides the service of exchanging data
directly between two hosts on the same network, whereas IP
handles addressing and routing message across one or more
networks.
A packet is a sequence of octets and consists of a header
followed by a body. The header describes the packet's
destination and, optionally, the routers to use for forwarding
until it arrives at its destination while the body contains the
data IP is transmitting.
Transmission Control Protocol accepts data from a data
stream, into chunks, and adds a TCP header creating a TCP
segment. The segment is then encapsulated into an IP
packet.
TCP also uses the notion of port numbers to identify
sending and receiving application end-points on a host, or
Internet sockets. Each side of a TCP connection has an
associated 16-bit unsigned port number (0-65535) reserved
by the sending or receiving application.
Arriving TCP data packets are identified as belonging to
a specific TCP connection by its sockets, that is, the
combination of source host address, source port, destination
host address, and destination port. This means that a server
computer can provide several clients with several services
simultaneously, as long as a client takes care of initiating
any simultaneous connections to one destination port from
different source ports.
Port numbers are categorized into three basic categories:
well-known, registered, and dynamic or private. The well-
known ports are assigned by the Internet Assigned Numbers
Authority (IANA) and are typically used by system-level or
root processes. Well-known applications running as servers
and passively listening for connections typically use these
ports. Some examples include: FTP (21), SSH (22),
TELNET (23), SMTP (25) and HTTP (80). Registered ports
are typically used by end user applications as ephemeral
source ports when contacting servers, but they can also
identify named services that have been registered by a third
party. Dynamic/private ports can also be used by end user
applications, but are less commonly so. Dynamic/private
ports do not contain any meaning outside of any particular
TCP connection.
Due to network congestion, traffic load balancing, or
other unpredictable network behavior, IP packets can be
lost, duplicated, or delivered out of order. TCP detects these
problems, requests retransmission of lost data, rearranges
out-of-order data, and even helps minimize network
congestion to reduce the occurrence of the other problems.
Once the TCP receiver has reassembled the sequence of
octets originally transmitted, it passes them to the
application program.
TCP is optimized for accurate delivery rather than timely
delivery, and therefore, TCP sometimes incurs relatively
long delays (in the order of seconds) while waiting for out-
of-order messages or retransmissions of lost messages.
B. Packet analyzer
A packet analyzer (also known as a network
analyzer, protocol analyzer or sniffer) is a computer
program (or a piece of computer hardware) that can
intercept and log traffic passing over a digital network or
part of a network. As data streams flow across the network,
the sniffer captures each packet and, if needed, decodes and
analyzes its content.
The captured information is decoded from raw
digital form into a human-readable format that permits users
of the protocol analyzer to easily review the exchanged
information.
A packet sniffer, which intercepts TCP traffic on a
network link, can be useful in debugging networks, network
stacks and applications that use TCP by showing the user
what packets are passing through a link. Some networking
stacks support the SO_DEBUG socket option, which can be
enabled on the socket using setsockopt. That option dumps
all the packets, TCP states, and events on that socket, which
is helpful in debugging.
PCAP (packet capture) consists of an application
programming interface (API) for capturing network traffic.
libpcap provide the packet-capture and filtering engines of
many open source and commercial network tools, including
packet sniffers (protocol analyzers), network monitors,
network intrusion detection systems, traffic-generators and
network-testers.
C. Libpcap
Libpcap is an open source library that provides a
high level interface to network packet capture systems. It
was created in 1994 by McCanne, Leres and Jacobson –
researchers at the Lawrence Berkeley National Laboratory
from University of California, at Berkeley as part of a
research project to investigate and improve TCP and
internet gateway performance.
Libpcap authors main objective was to create a
platform-independent API to eliminate the need for system
dependent packet capture modules in each aplication, as
virtually evrey OS vendor implements its own capture
mechanisms.
The libpcap API is designed to be used for C and
C++. However, there are many wappers that allow its use
from languages like Pearl, Python, Java, C# or
Ruby.Libpcap runs on most UNIX-like operating systems.
Today, libpcap is maintained by the Tcpdump Group.
libpcap also support saving captured packets to a
file, and reading files containing saved packets; applications
can be written, using libpcap or WinPcap, to be able to
capture network traffic and analyze it, or to read a saved
capture and analyze it, using the same analysis code. A
capture file saved in the format that libpcap and WinPcap
use can be read by applications that understand that format,
such as tcpdump, Wireshark, CA NetMaster, or Microsoft
Network Monitor 3.x.
II. RELATED WORK
Packet sniffing began with the need to obtain raw packets
across the several layers beneath the application protocol.
Normally the packets or data frames are stripped of their
headers and are passed to the upper layers. However in
promiscuous mode raw packets of lower layers can directly
be obtained alongside their headers. These samples are quite
useful to obtain the data flow patterns across the network.
This can also be used for network monitoring and
management.
Much of the idea behind packet sniffing began with the
use of BSD packet filters (BPF) . Because network monitors
run as user-level processes, packets must be copied across
the kernel/user-space protection boundary. This copying can
be minimized by deploying a kernel agent called a packet
filter, which discards unwanted packets as early as possible.
The BSD Packet Filter (BPF) uses a redesigned, register
based filter evaluator that can be implemented efficiently on
today’s register based RISC CPU. BPF uses a simple, non-
shared buffer model made possible by today’s larger address
spaces.
There are many types of network sniffers. That’s why It
is necessary to consider the properties of an ideal packet
sniffer. These can be summarized as shown below:
• View detailed IP or MAC connections statistics: IP
addresses, ports, sessions, etc.
• Display TCP sessions.
• Map packets to the application that is sending or
receiving them.
• View application protocols distribution, bandwidth
utilization, and network nodes charts and tables.
• Ability to monitor traffic in real time as well as
analyze traffic reports offline
• Ability to browse captured and decoded packets in real
time.
• Ability to search for strings or hex data in captured
packet contents.
• Ability to import and export packets in hex and text
formats from other sniffers
• Ability to configure alarms that can notify about
important events, such as suspicious packets, high
bandwidth utilization, unknown addresses, etc.
• Ability to create custom plug-ins for decoding any
protocol.
• Ability to exchange data with other application over
TCP/IP.
This are three of the primary and most useful packet
sniffers are TCPdump, Ngrep and Snoop.
1) TCPdump is the most common network debugging
and packet monitoring tool that runs under the command
line. It allows the user to intercept and display TCP/IP and
other packets being transmitted or received over a network
to which the computer is attached. TCPdump works on most
Unix-like operating systems: Linux, Solaris, BSD, Mac OS
X, HP-UX and AIX among others. In those systems,
tcpdump uses the libpcap library to capture packets. The
user may optionally apply a BPF-based filter to limit the
number of packets seen by tcpdump; this renders the output
more usable on networks with a high volume of traffic.
Tcpdump is frequently used to debug applications that
generate or receive network traffic. It can also be used for
debugging the network setup itself, by determining whether
all necessary routing is occurring properly, allowing the user
to further isolate the source of a problem.
2) Ngrep strives to provide most of GNU grep's
common features, applying them to the network layer.
Ngrep is a pcap-aware tool that will allow you to specify
extended regular or hexadecimal expressions to match
against data payloads of packets. It currently recognizes
IPv4/6, TCP, UDP, ICMPv4/6, IGMP and Raw across
Ethernet, PPP, SLIP, FDDI, Token Ring and null interfaces,
and understands BPF filter logic in the same fashion as
more common packet sniffing tools, such as tcpdump and
snoop.
Ngrep may simply feed the output of libpcap (or
tcpdump) into the regular expression parse, where the
expressions come from a file on the disk. Some even
simpler systems don't even use regular expressions and
simply compare packets with well-known byte patterns.
Ngrep has traditionally been used to debug plain text
protocol interactions such as HTTP, SMTP, FTP, etc.
3) Snoop is a very flexible command line packet
sniffer included as part of Sun Microsystems' Solaris
Operating System. It is pretty cable sniffer equal or better
then TCPdump.
Snoop displays packets in a single-line summary form or in
verbose multi-line forms. It can display packets as soon as
they are received or saved to a file. When snoop writes to an
intermediate file, packet loss under busy trace conditions is
unlikely. Snoop itself can be used read and interpret the file
e.g - print summary expended summary and full packets
dumps.
The only disadvantage being that since it is tightly
integrated within the Solaris kernel, its use is largely limited
to Sun based systems. Though there have been hacks to port
it to other kernels like FreeBSD and Linux, most of them
have been fairly limited by number.
 III. ARHITECTURE
In this section we provide details of the design and the
implementation of our program. The TCP Session Logger is
basically a C written sniffer that is concentrated on sniffing
TCP packets and is capable of taking best practice decisions
based on what data it has gathered over time.
A. Design
The main logic of the program can be easily followed on the
graph below (Fig 1):
1) First, we use the packet generator software to insert
several TCP packets over the Ethernet channel.
This way we can simulate a scenario where the
Linux guest is sustaining multiple connections that
run over the TCP protocol.
2) Meanwhile our sniffer will be in listen mode,
which basically means it will constantly monitor
the ethernet channel for any new packets.
The sniffer does not need to know whether the
packets are TCP packets or not because we use the
generator to send TCP packets only. Of course, if
we would have needed to send other type of
packets we could have introduced an additional
filter inside the sniffer, for reading TCP only. This
implementation would be needed for real scenario
purposes.
3) While cruising the ethernet channel, packets are
taken one by one by the sniffer. Afterwards the
sniffer will read the data inside and will provide the
Layer 2/3 fields necessary for further use.
4) After reading the data filters are applied. These
filters have the role to select only the TCP packets
we are really interested in. (e.g. ACK and NACK
packets may be filtered out if they do not
contribute in any way to our desired analysis).
Fig. 1. Architectural Diagram
5) Steps 2,3 and 4 are actually basic steps which can
be found in most sniffer implementations. The TCP
Session Logger adds a new block which is
responsible for making several decisions. This
decisions determine two new features, making use
of the best practice actions that can be taken when
dealing with networking.
6) The first one is relatively simple, but may prove
itself very useful. TCPSL documents the data that
it sniffs in different formats for future data
analysis. A statistical representation of the network
data may not be very useful to an end-user system,
but it is critical when dealing with different kind of
servers, that need a proficient management of their
connections.
7) The second feature consists of several decisions that
are to be taken based on the information the sniffer
is gathering. One example could be limiting the
number of connections initiated or accepted by the
server when there is high network load. Also,
introducing several Qos techniques for various
traffic could be reasonable actions.
Besides taking decisions, TCPSL could also issue
different kind of alarms to the administrator (by email, sms
or by using monitoring tools). For example, when the sniffer
receives a lot of NACK packets it could send a mail to the
human administrator warning of a possible connection
problem or too high traffic load.
The ability to identify a network fault and react to it, is a
also function of our aplication. The Tcp session logger
focuses on a more proactive approach to managing faults by
continuously monitoring for conditions that indicate an
emerging problem or degradation. This proactive approach
is essential to reducing mean-time-to-repair and rectifying
potential issues before end users ever notice. To support
best practices in accelerated fault detection, our solutions
include the following:
• Anomaly detection alarms: its automatically detect
abnormal behavior. In addition we have the ability to
diagnose the anomaly to specific traffic types, or KPIs
e.g. response time and availability.
• Conditional and evidence-gathering alarms: This
gathers crucial information for troubleshooting the
problem.
• Response time and availability alarms: Application
response time alarms, set per application type, notify
when an application is approaching poor performance,
such as a 3 second response time for an application
that typically responds within 800 milliseconds.
• Microburst alarms: Traffic microbursts can severely
disrupt the flow time-sensitive applications such as
voice over IP, streaming financial market data, or
trading applications, yet are often hard to detect or
diagnose.
• Rising and falling threshold alarms: It sets thresholds
of network activity to identify resources at risk of
failure is key to staying ahead of network problems
and ensuring that networked services continue to run
smoothly. The network alarm and application statistics,
including the following alarming capabilities:
• Utilization alarms: Are needed to identify potential
areas of congestion, such as 70% utilization on a
particular segment, or indicate potential failures, such
as the disappearance of traffic on a load-balanced link.
• Application alarms: Thresholds on application
utilization identify undesired traffic patterns (e.g.,
increasing amount of ICMP traffic indicating a
potential denial of service attack) or an undesired
network usage (e.g., AOL traffic).
B. Environment
As a test environment we used an Ubuntu 10 Linux
platform. The main scope was to send packets using a
packet generator from a loopback interface, called loopback
0 in our case, to an ethernet interface which in our case was
ethernet0. Our sniffer would listen on ethernet0 and extract
the necessary data.
The environment design and devices used is shown in
the image below:
Packet Generator:
As mentioned before we used a GUI based packet
generator called packETH, a useful freeware tool. The
application can easily send batches of packets of many types
over the network. However, we were mostly interested in
capturing TCP traffic so we used packETH to produce
different types of TCP packets.
Resources & Programming:
TCP Session Logger is entirely written in C. The
program makes use of the libpcap library which has a
variety of functions and structures. These functions operate
at the lower level of the system and can be used to obtain
valuable functionality for any kind of traffic sniffer or
analyzer.
We also used tools like Eclipse or gcc compiler for normal
debugging of the program.
C. Implementation
Some of the most common functions used within our
program are in the table below:
Function Description
gets a network device suitable for
pcap_lookupdev()
use
opens the specified network device
pcap_open_live()
for packet capture
reads and processes packets that are
pcap_loop()
being captured live
compiles a char array which is used
pcap_compile()
as a regex for filtering traffic
pcap_filter() applies various filters to the sniffer
Descriptor of an open capture
pcap_t instance, used when calling in
libpcap
Table 1
To start with the C program the simple steps would be:
Find all available devices – find_alldevs() is the function
which can be used to get a list of all available network
devices or interfaces present on the machine or which can
be opened by pcap_open_live() for sniffing purpose.
The basic implementation of the Main function is shown
here in Fig. 2:
The prototype is as: “int pcap_findalldevs(pcap_if_t
**alldevsp, char *errbuf)” where alldevsp is a pointer to an
array of pcap_if_t structures and errbuf is a character
pointer and will contain any error message that occurred
during the function call.
Select a device for sniffing data – pcap_open_live() is
the function to get a packet capture descriptor or a handle to
a device which has been opened up for sniffing.
The prototype is as follows:
pcap_t *pcap_open_live(const char *device, int
snaplen,int promisc, int to_ms, char *errbuf). The first
argument is the device that we specified in the previous
section. snaplen is an integer which defines the maximum
number of bytes to be captured by pcap. promisc, when set
to true, brings the interface into promiscuous mode
(however, even if it is set to false, it is possible under
specific cases for the interface to be in promiscuous mode,
anyway). to_ms is the read time out in milliseconds (a value
of 0 means no time out; on at least some platforms, this
means that you may wait until a sufficient number of
packets arrive before seeing any packets, so you should use
 int main(int argc, char *argv[] ){
int i=0, count=0;
pcap_t *descr = NULL; It returns a device handler in the form of the structure
char errbuf[PCAP_ERRBUF_SIZE], *device=NULL; pcap_t which can be used by pcap_loop() to capture data
memset(errbuf,0,PCAP_ERRBUF_SIZE); from.
if( argc > 1){ // If user supplied interface name, use it. Start sniffing the device – pcap_loop(). Process the
device = argv[1]; sniffed packet – user defined callback method (e.g. void
} processPacket(u_char *arg, const struct pcap_pkthdr*
else{ // Get the name of the first device suitable for pkthdr, const u_char * packet)).
capture The prototype for pcap_loop() is: int pcap_loop(pcap_t
if ((device = pcap_lookupdev(errbuf)) == NULL){ *p, int cnt, pcap_handler callback, u_char *user). The first
fprintf(stderr, "ERROR: %s\n", errbuf); argument is our session handle. Following that is an integer
exit(1); that tells pcap_loop() how many packets it should sniff for
} before returning (a negative value means it should sniff until
} an error occurs). The third argument is the name of the
printf("Opening device %s\n", device); callback function (just its identifier, no parentheses). The
// Open device in promiscuous mode last argument is useful in some applications, but many times
if ( (descr = pcap_open_live(device, is simply set as NULL. Suppose we have arguments of our
MAXBYTES2CAPTURE, 1, 512, errbuf)) == NULL){ own that we wish to send to our callback function, in
fprintf(stderr, "ERROR: %s\n", errbuf); addition to the arguments that pcap_loop() sends. This is
exit(1); where we do it. Obviously, you must typecast to a u_char
} pointer to ensure the results make it there correctly; as we
logfile=fopen("log.txt","w"); will see later, pcap makes use of some very interesting
if(logfile==NULL) printf("Unable to create file."); means of passing information in the form of a u_char
// Loop forever & call processPacket() for every received pointer.
packet Before we can provide an example of using pcap_loop(),
if ( pcap_loop(descr, -1, processPacket, (u_char *)&count) we must examine the format of our callback function. We
== -1){ cannot arbitrarily define our callback's prototype; otherwise,
fprintf(stderr, "ERROR: %s\n", pcap_geterr(descr) ); pcap_loop() would not know how to use the function. So we
exit(1); use this format as the prototype for our callback function:
} void got_packet(u_char *args, const struct pcap_pkthdr
areturn
non-zero0; timeout). Lastly, ebuf is a string we can store any *header, const u_char *packet); Let's examine this in more
}
error messages within (as we did above with errbuf). The detail. First, we notice that the function has a void return
Fig. 2
function returns our session handler. type.
device – is the name of the device as obtained from the call This is logical, because pcap_loop() wouldn't know how
to pcap_findalldevs. to handle a return value anyway. The first argument
snaplen – is the maximum amount of data to be captured. corresponds to the last argument of pcap_loop(). Whatever
65536 should be sufficient length. value is passed as the last argument to pcap_loop() is passed
promisc – 0 or 1 to indicate whether to open the device in to the first argument of our callback function every time the
promiscuous mode. function is called. The second argument is the pcap header,
to_ms – the timeout in milliseconds , 0 for no timeout which contains information about when the packet was
errbuf – buffer to contain any error message sniffed, how large it is, etc. The pcap_pkthdr structure is
defined in pcap.h as in Fig. 3:
 struct pcap_pkthdr {
struct timeval ts; /* time stamp */
bpf_u_int32 caplen; /*length of portion present*/
u_char* handle_IP
bpf_u_int32 len; /* length this packet (off wire)*/
(u_char *args,const struct pcap_pkthdr* pkthdr,const u_char*
}; packet)
Fig. 3 {
const struct my_ip* ip;
u_int length = pkthdr->len;
These values should be fairly self explanatory. The last u_int hlen,off,version;
argument is the most interesting of them all, and the most int i;
confusing to the average novice pcap programmer. It is int len;
another pointer to a u_char, and it points to the first byte of /* jump pass the ethernet header */
ip = (struct my_ip*)(packet + sizeof(struct ether_header));
a chunk of data containing the entire packet, as sniffed by
length -= sizeof(struct ether_header);
pcap_loop().
A packet contains many attributes, so as you can /* check to see we have a packet of valid length */
imagine, it is not really a string, but actually a collection of
structures (for instance, a TCP/IP packet would have an if (length < sizeof(struct my_ip))
Ethernet header, an IP header, a TCP header, and lastly, the {
packet's payload). This u_char pointer points to the printf("truncated ip %d",length);
serialized version of these structures. To make any use of it, return NULL;
we must do some interesting typecasting. }
len = ntohs(ip->ip_len);
Programming to print out the ethernet header, from now
hlen = IP_HL(ip); // header length
on we take the easy route. Here is a straightforward callback version = IP_V(ip);// ip version
function to handle ethernet headers, print out the source and
destination addresses and handle the type. // check version
A summary of the contents of the internet header:
if(version != 4)
{
bit 16– fprintf(stdout,"Unknown version %d\n",version);
0–3 4–7 8–13 14-15 19–31
offset 18 return NULL;
Differentiated Explicit }
Header
0 Version Services Code Congestion Total Length
Length
Point Notification // check header length
Fragment
32 Identification Flags
Offset if(hlen < 5 )
64 Time to Live Protocol Header Checksum {
fprintf(stdout,"bad-hlen %d \n",hlen);
96 Source IP Address
}
128 Destination IP Address
160 Options ( if Header Length > 5 ) // see if we have as much packet as we should
160
or Data if(length < len)
192+ printf("\ntruncated IP - %d bytes missing\n",len - length);
Fig. 4. Ethernet frame
// Check to see if we have the first fragment

off = ntohs(ip->ip_off);
We are following the tcpdump method of handling the if((off & 0x1fff) == 0 )/* aka no 1's in first 13 bits */
version and header length in Fig.5-6. {/* print SOURCE DESTINATION hlen version len offset */
fprintf(stdout,"IP source: ");
fprintf(stdout,"%s ;\n",
struct my_ip inet_ntoa(ip->ip_src));
u_int8_t ip_vhl; /* header length, version*/ fprintf(stdout,"IP destination: %s ;\n header lenght: %d ;\n
#define IP_V(ip) (((ip)->ip_vhl & 0xf0) >> 4) version: %d ;\n lenght: %d ;\n offset: %d\n",
#define IP_HL(ip) ((ip)->ip_vhl & 0x0f) inet_ntoa(ip->ip_dst),
u_int8_t ip_tos; /* type of service */ hlen,version,len,off);
u_int16_t ip_len; /* total length */ fprintf(stdout,"Time to Live: %d ;\n", ntohs(ip->ip_ttl)/256);
u_int16_t ip_id; /* identification*/ fprintf(stdout,"Protocol: %d ;\n", ip->ip_p);
u_int16_t ip_off; /* fragment offset field */ fprintf(stdout,"Checksum: %d ;\n", ip->ip_sum);
#define IP_DF 0x4000 /* dont fragment flag */ }
#define IP_MF 0x2000 /* more fragments flag */ return NULL;
#define IP_OFFMASK 0x1fff /* mask for }
fragmenting bits */ Fig. 6
u_int8_t ip_ttl; /* time to live */
u_int8_t ip_p; /* protocol */
u_int16_t ip_sum; /* checksum */
struct in_addr ip_src,ip_dst; /* source and dest address */
};
Fig. 5
 IV. RESULTS Future work may extend the functionality or the concept
The results we have with our application are not very of such an application to all kinds of traffic. Also a GUI/CL
elaborate, and the application still needs some final interface could be implemented in order to allow the users
debugging and testing. The results we will present are only to constantly adapt the application's behavior to their own
base test results. needs.
The functionality testing of our sniffer is shown in Fig. 7: By using statistical data, decisions about upgrading or
adding new servers could be made more exact. Also, the
Opening device eth0 business owner could have a better picture about how much
ethernet header source: 0:c:29:81:29:3c more traffic can the server sustain in good conditions.
destination: 0:50:56:fb:e0:d (IP) VI. REFERENCES
IP source: 192.168.79.138 ;
IP destination: 192.168.79.2 ; [1] http://elf.cs.pub.ro/so2/
header lenght: 5 ; [2] http://elf.cs.pub.ro/so/
version: 4 ; [3]http://recursos.aldabaknocking.com/libpcapHakin9LuisM
lenght: 77 ; artinGarcia.pdf
offset: 16384 [4]http://www.programmingpcap.aldabaknocking.com/code
Time to Live: 64 ; samples.html
Protocol: 17 ;
[5]http://www.tcpdump.org/release/libpcap-1.1.1.tar.gz
Checksum: 44446 ;
Grabbed packet of length 91 [6] http://www.tcpdump.org/#
Recieved at ..... Sat Jan 8 16:08:55 2011 [7] Vinton G. Cerf, Robert E. Kahn, A Protocol for Packet
Network Intercommunication, IEEE Transactions on
Ethernet address length is 14 Communications, Vol. 22, No. 5,May 1974.
Ethernet type hex:800 dec:2048 is an IP packet [8] Comer, Douglas E. (2006). Internetworking with TCP/
Destination Address: 0:50:56:fb:e0:d IP:Principles, Protocols, and Architecture. 1 (5th ed.).
Source Address: 0:c:29:81:29:3c [9] http://www.iana.org/assignments/tcp-parameters/
ethernet header source: 0:c:29:81:29:3c [10]http://citeseer.ist.psu.edu/stone00when.html
destination: 0:50:56:fb:e0:d (IP) [11] http://lwn.net/Articles/92727/
IP source: 192.168.79.138 ; [12] Peterson, Larry (2003). Computer Networks. Morgan
IP destination: 192.168.79.2 ; Kaufmann..
header lenght: 5 ; [13]Tanenbaum, Andrew S. (2003-03-17). Computer
version: 4 ; Networks (Fourth ed.).
lenght: 75 ; [14]http://www.gont.com.ar/talks/hacklu2009/fgont-
offset: 16384 hacklu2009-tcp-security.pdf
Time to Live: 64 ; [15] Business Wire (2007-12-06). "Solera Networks
Protocol: 17 ; Announces Advanced Deep Packet Inspection and Capture
Checksum: 44958 ; Solution for Full 10Gbps Speeds".
Grabbed packet of length 89 [16] Erik Hjelmvik (2008). "Passive Network Security
Recieved at ..... Sat Jan 8 16:08:55 2011 Analysis with NetworkMiner".
[17] Helman, Paul, Liepins, Gunar, and Richards, Wynette,
Fig. 7 "Foundations of Intrusion Detection," The IEEE Computer
Security Foundations Workshop V, 1992.
All the information is stored and used by our fault [18] Steven McCanne and Van Jacobso “ The BSD Packet
detection system, which analysis the information and take Filter: A New Architecture for User-level Packet Capture”
action based on the problems found. Lawrence Berkeley Laboratory 1992.
[19] Ashish Chaurasia “Network packet capturing for Linux
V. CONCLUSIONS AND FUTURE WORK “, IBM Corp.
A good implementation of a TCPSL application could be [20] Naveed Afzal “Host Fingerprinting and Firewalking
very useful in the case of servers that suffer of high load, With hping”.
and their uptime is essential for the business. Additional [21] Anderson, Ross (2001). Security Engineering: A Guide
servers or load balancing can, of course, be a solution, but to Building Dependable Distributed Systems. New York:
the additional costs may not be always affordable by the John Wiley & Sons. pp. 387–388.
business owner. One efficiently configured TCPSL may [22] Anderson, James P., "Computer Security Threat
well manage the existing load and may protect the server Monitoring and Surveillance," Washing, PA, James P.
from unwanted downtime periods. Anderson Co., 1980.
[23] Denning, Dorothy E., "An Intrusion Detection Model," Jonkman Marty, Raffael, and Poor, Mike, "Snort IDS and
Proceedings of the Seventh IEEE Symposium on Security IPS Toolkit," Syngress, 2007.
and Privacy, May 1986, pages 119–131 .
[24] Lunt, Teresa F., "IDES: An Intelligent System for
Detecting Intruders," Proceedings of the Symposium on
Computer Security; Threats, and Countermeasures; Rome,
Italy, November 22–23, 1990, pages 110–121.
[25] Lunt, Teresa F., "Detecting Intruders in Computer
Systems," 1993 Conference on Auditing and Computer
Technology, SRI International .
[26] Sebring, Michael M., and Whitehurst, R. Alan., "Expert
Systems in Intrusion Detection: A Case Study," The 11th
National Computer Security Conference, October, 1988
[27] Smaha, Stephen E., "Haystack: An Intrusion Detection
System," The Fourth Aerospace Computer Security
Applications Conference, Orlando, FL, December, 1988 .
[28] Vaccaro, H.S., and Liepins, G.E., "Detection of
Anomalous Computer Session Activity," The 1989 IEEE
Symposium on Security and Privacy, May, 1989 .
[29] Teng, Henry S., Chen, Kaihu, and Lu, Stephen C-Y,
"Adaptive Real-time Anomaly Detection Using Inductively
Generated Sequential Patterns," 1990 IEEE Symposium on
Security and Privacy .
[30] Heberlein, L. Todd, Dias, Gihan V., Levitt, Karl N.,
Mukherjee, Biswanath, Wood, Jeff, and Wolber, David, "A
Network Security Monitor," 1990 Symposium on Research
in Security and Privacy, Oakland, CA, pages 296–304
[31] Winkeler, J.R., "A UNIX Prototype for Intrusion and
Anomaly Detection in Secure Networks," The Thirteenth
National Computer Security Conference, Washington, DC.,
pages 115–124, 1990.
[32] Dowell, Cheri, and Ramstedt, Paul, "The
ComputerWatch Data Reduction Tool," Proceedings of the
13th National Computer Security Conference, Washington,
D.C., 1990 .
[33] Snapp, Steven R, Brentano, James, Dias, Gihan V.,
Goan, Terrance L., Heberlein, L. Todd, Ho, Che-Lin, Levitt,
Karl N., Mukherjee, Biswanath, Smaha, Stephen E., Grance,
Tim, Teal, Daniel M. and Mansur, Doug, "DIDS
(Distributed Intrusion Detection System) -- Motivation,
Architecture, and An Early Prototype," The 14th National
Computer Security Conference, October, 1991, pages 167–
176.
[34] Jackson, Kathleen, DuBois, David H., and Stallings,
Cathy A., "A Phased Approach to Network Intrusion
Detection," 14th National Computing Security Conference,
1991 .
[35] Paxson, Vern, "Bro: A System for Detecting Network
Intruders in Real-Time," Proceedings of The 7th USENIX
Security Symposium, San Antonio, TX, 1998 .
[36] Amoroso, Edward, "Intrusion Detection: An
Introduction to Internet Surveillance, Correlation, Trace
Back, Traps, and Response," Intrusion.Net Books, Sparta,
New Jersey, 1999.
[37] Kohlenberg, Toby (Ed.), Alder, Raven, Carter, Dr.
Everett F. (Skip), Jr., Esler, Joel., Foster, James C.,