SKP ENGINEERING COLLEGE

(Affiliated to Anna University)

TIRUVANNAMALAI.

DEPARTMENT OF COMPUTER SCIENCE AND ENGINEERING

CCS354 – NETWORK SECURITY LABORATORY

(Regulation 2021, V Semester)

LABORATORY MANUAL
for
B.E (CSE) III YEAR – VI SEM (R-2021)
ACADEMIC YEAR: 2024 – 2025

(Even Semester)
 S.K.P ENGINEERING COLLEGE
TIRUVANNAMALAI – 606 611

DEPARTMENT OF COMPUTER SCIENCE AND ENGINEERING

BONAFIDE CERTIFICATE

Name :

University Reg. No :

Course /Branch : B. E / CSE

Year / Semester : III / VI

Section :

Certified that this bonafide record of work is done by the above student in CCS354-
NETWORK SECURITY LABORATORY during the year 2024– 2025.

STAFF-IN-CHARGE HEAD OF THE DEPARTMENT

Submitted for the practical examination held on……………….....................………………. at

[Link] COLLEGE, TIRUVANNAMALAI.

INTERNAL EXAMINER EXTERNAL EXAMINER

 INSTRUCTIONS TO BE FOLLOWED IN MAINTAINING THE RECORD BOOK

A. 1. The Record of an experiment should be submitted on the day the students come to the same
laboratory to perform the next experiment.
2. Only such experiments as done by the candidate should be recorded in the order in which they are
done.

B. The Record should be written neatly in ink, except for the diagrams which should be in pencil

C. Every experiment should begin on a new page.

D. The right hand page should contain:

1. Date of performance of the experiment in the margin at the top.
2. Serial Number just below the date.

E. Experiment Number and the title of experiment on the first line followed by:

1. Aim of the experiment.

2. Apparatus required.
3. Materials required.
4. Principle.
5. Procedure (Including precaution if any)
6. Results.

F. The left hand page should contain the following in the same order:
1. Diagram of the apparatus if any.
2. Circuit diagrams if any.
3. Observations, if any, in tabular form.
4. Sample calculations, if any.
5. Results in tabular form, if any.
6. Graphs if any, to be pasted.
 INDEX

EX. PAGE. MARKS

DATE LIST OF EXPERIMENT SIGNATUE
NO. NO (10)

1a. Implement symmetric key algorithms - DES

1b. Implement symmetric key algorithms - AES

2a. Implement asymmetric key algorithms (RSA) and

Implement key exchange algorithms (Diffie -

2b.
Hellman Key Exchange algorithm)

Implement the SIGNATURE SCHEME - Digital

3.
Signature Standard.
Installation of Wire shark, tcp dump and observe
data transferred in client-server communication
4.
using UDP/TCP and identify the UDP/TCP
datagram.
Check message integrity and confidentiality using
5.
SSL

Experiment Eavesdropping, Dictionary attacks,

6.
MITM attacks

7. Experiment with Sniff Traffic using ARP Poisoning

Demonstrate intrusion detection system using any

8.
tool.

9. Explore network monitoring tools

10. Study to configure Firewall, VPN.

SOFTWARE REQUIREMENTS: Java jdk.

 [Link]: 1a)
IMPLEMENT SYMMETRIC KEY ALGORITHMS - DES

AIM:
To use Data Encryption Standard (DES) Algorithm for a practical application like User
Message Encryption.

ALGORITHM:

1. Create a DES Key.

2. Create a Cipher instance from Cipher class, specify the following information and separated
by a slash (/).
a. Algorithm name
b. Mode (optional)
c. Padding scheme (optional)
3. Convert String into Byte[] array format.
4. Make Cipher in encrypt mode, and encrypt it with [Link]() method.
5. Make Cipher in decrypt mode, and decrypt it with [Link]() method.
PROGRAM: ([Link])

import [Link];
import [Link];
import [Link];
import [Link];

import [Link];

import [Link];

import [Link];

import [Link];

public class DES

public static void main(String[] argv)

try
{

[Link]("message Encryption Using DES Algorithm\n-------");

KeyGenerator keygenerator = [Link]("DES");

SecretKey myDesKey = [Link]();

Cipher desCipher;desCipher =

[Link]("DES/ECB/PKCS5Padding");

[Link](Cipher.ENCRYPT_MODE, myDesKey);

byte[] text = "Secret Information ".getBytes();

[Link]("Message [Byte Format] : " + text);

[Link]("Message : " + new String(text));

byte[] textEncrypted = [Link](text);

[Link]("Encrypted Message: " + textEncrypted);

[Link](Cipher.DECRYPT_MODE, myDesKey);

byte[] textDecrypted = [Link](textEncrypted);

[Link]("Decrypted Message: " + new

String(textDecrypted));

catch(NoSuchAlgorithmException e)

[Link]();

}catch(NoSuchPaddingException e){

[Link]();

}catch(InvalidKeyException e){

[Link]();
}catch(IllegalBlockSizeException e){

[Link]();

}catch(BadPaddingException e){

[Link]();

OUTPUT:

Message Encryption Using DES Algorithm

-------------------------------------------------------------

Message [Byte Format]: [B@4dcbadb4

Message: Secret Information

Encrypted Message: [B@504bae78

Decrypted Message: Secret Information

RESULT:

Thus the java program for DES Algorithm has been implemented and the output verified
successfully.
 [Link]. 1b)
IMPLEMENT SYMMETRIC KEY ALGORITHMS - AES

AIM:
To use Advanced Encryption Standard (AES) Algorithm for a practical application like URL
Encryption.

ALGORITHM:

1. AES is based on a design principle known as a substitution–permutation.

2. AES does not use a Feistel network like DES, it uses variant of Rijndael.
3. It has a fixed block size of 128 bits, and a key size of 128, 192, or 256 bits.
4. AES operates on a 4 × 4 column-major order array of bytes, termed the state.

PROGRAM:

import [Link];
import [Link];
import [Link];
import [Link];
import [Link].Base64;
import [Link];
import [Link];
public class AES {
private static SecretKeySpec secretKey;
private static byte[] key;
public static void setKey(String myKey)
{
MessageDigest sha = null;
try
{
key = [Link]("UTF-8");
sha = [Link]("SHA-1");
key = [Link](key);
key = [Link](key, 16);
secretKey = new SecretKeySpec(key, "AES");
} catch (NoSuchAlgorithmException e)
{
[Link]();
}
catch (UnsupportedEncodingException e)
{
[Link]();
}
}
public static String encrypt(String strToEncrypt, String secret)
{
try
{
setKey(secret);
Cipher cipher = [Link]("AES/ECB/PKCS5Padding");
[Link](Cipher.ENCRYPT_MODE, secretKey);
return
[Link]().encodeToString([Link]([Link]("UTF8")));
}
catch (Exception e)
{
[Link]("Error while encrypting: " + [Link]());
}
return null;
}
public static String decrypt(String strToDecrypt, String secret)
{
try
{
setKey(secret);
Cipher cipher = [Link]("AES/ECB/PKCS5PADDING");
[Link](Cipher.DECRYPT_MODE, secretKey);
return new
String([Link]([Link]().decode(strToDecrypt)));
}
catch (Exception e)
{
[Link]("Error while decrypting: " + [Link]());
}
return null;
}
public static voidmain(String[] args) {
final String secretKey = "annaUniversity";
String originalString = "[Link]";
String encryptedString = [Link](originalString, secretKey);
String decryptedString = [Link](encryptedString, secretKey);
[Link]("URL Encryption Using AES Algorithm\n------------");
[Link]("Original URL: " + originalString);
[Link]("Encrypted URL: " + encryptedString);
[Link]("Decrypted URL: " + decryptedString);
}
}

OUTPUT:

URL Encryption Using AES Algorithm

----------------------------------------------------
Original URL: [Link]
Encrypted URL: vibpFJW6Cvs5Y+L7t4N6YWWe07+JzS1d3CU2h3mEvEg=
Decrypted URL: [Link]

RESULT:

Thus the java program for AES Algorithm has been implemented for URL Encryption and
the output verified successfully.
 [Link].2a)
IMPLEMENT ASYMMETRIC KEY ALGORITHMS (RSA)

AIM:

To write java program to implement RSA Encryption algorithm.

ALGORITHM:

1. Key Generation: o
 Choose two distinct prime numbers, p and q.
 Compute n = p * q, which is the modulus for both the public and private keys.
 Compute the totient of n, φ(n) = (p-1) * (q-1).
 Choose an integer e such that 1 < e < φ(n) and gcd(e, φ(n)) = 1; e will be the
public exponent.
 Compute d such that d * e ≡ 1 (mod φ(n)); d will be the private exponent.
2. Public Key:

 The public key consists of the pair (n, e).

3. Private Key:

 The private key consists of the pair (n, d).

4. Encryption:

 Represent the plaintext message as an integer M where 0 ≤ M < n. o Compute the

ciphertext C = M^e mod n.
5. Decryption:

 Given the ciphertext C, compute the plaintext message M = C^dmodn.

Here's the step-by-step algorithm for RSA decryption:

1. Decryption:
 Given the ciphertext C, compute the plaintext message M = C^dmodn.
2. Encryption:
 Represent the plaintext message as an integer M where 0 ≤ M < n. o Compute the ciphertext
C = M^e mod n.
PROGRAM:
[Link]

import [Link];
import [Link];
import [Link].*;
import [Link];
import [Link];
public class RSA
{
static Scanner sc=new Scanner([Link]);
public static void main(String[] args)
{
[Link]("Enter a Prime Number:");
BigInteger P=[Link]();
[Link]("Enter another prime number:");
BigInteger q=[Link]();
BigInteger n=[Link](q);
BigInteger n2=[Link]([Link]).multiply([Link]([Link]));
BigInteger e=generateE(n2);
BigInteger d=[Link](n2);
[Link]("Encryption keys are:"+e+","+n);
[Link]("Decryption Keys are:"+d+","+n);}
public static BigInteger generateE(BigInteger fiofn){
int y,intGCD;
BigInteger gcd;
BigInteger e;
Random X=new Random();
do
{
y=[Link]([Link]()-1);
String Z=[Link](y);
e=new BigInteger(Z);
gcd=[Link](e);
intGCD=[Link]();
}
while(y<=2 || intGCD!=1);
return e;
}
}

OUTPUT:

Enter a Prime Number:

Enter another prime number:

11

Encryption keys are:27,55

Decryption Keys are:3,55

=== Code Execution Successful ===

RESULT:

Thus the java program to implement RSA Encryption algorithm was executed
successfully.
 [Link]: 2b)
IMPLEMENT ASYMMETRIC KEY EXCHANGE ALGORITHMS
(DIFFIE -HELLMAN KEY EXCHANGE ALGORITHM)

AIM:
To implement the Diffie-Hellman Key Exchange algorithm for a given problem.

ALGORITHM:

1. Alice and Bob publicly agree to use a modulus p = 23 and base g = 5

(Which is a primitive root modulo 23).

2. Alice chooses a secret integer a = 4, then sends Bob A = g a mod p o A = 5 4 mod 23 = 4

3. Bob chooses a secret integer b = 3, then sends Alice B = g b mod p o B = 5 3 mod 23 = 10
4. Alice computes s = B a mod p o s = 10 4 mod 23 = 18
5. Bob computes s = A b mod p o s = 4 3 mod 23 = 18
6. Alice and Bob now share a secret (the number 18).

PROGRAM:

[Link]

import [Link];

import [Link];

import [Link];

import [Link];

import [Link];

import [Link];

import [Link];

import [Link];

class DiffieHellman

{
public static void main(String args[]) {

int p = 23; /* publicly known (prime number) */

int g = 5; /* publicly known (primitive root) */

int x = 4; /* only Alice knows this secret */

int y = 3; /* only Bob knows this secret */

double aliceSends = ([Link](g, x)) % p;

double bobComputes = ([Link](aliceSends, y)) % p;

double bobSends = ([Link](g, y)) % p;

double aliceComputes = ([Link](bobSends, x)) % p;

double sharedSecret = ([Link](g, (x * y))) % p;

[Link]("simulation of Diffie-Hellman key exchange algorithm\n----------------------");

[Link]("Alice Sends : " + aliceSends);

[Link]("Bob Computes : " + bobComputes);

[Link]("Bob Sends : " + bobSends);

[Link]("Alice Computes : " + aliceComputes);

[Link]("Shared Secret : " + sharedSecret);

/* shared secrets should match and equality is transitive */

if ((aliceComputes == sharedSecret) && (aliceComputes == bobComputes))

[Link]("Success: Shared Secrets Matches! " + sharedSecret);

else

[Link]("Error: Shared Secrets does not Match");

}
OUTPUT:

Simulation of Diffie-Hellman Key Exchange Algorithm

------------------------

Alice Sends : 4.0

Bob Computes : 18.0

Bob Sends : 10.0

Alice Computes : 18.0

Shared Secret : 18.0

Success: Shared Secrets Matches! 18.0

=== Code Execution Successful ===

RESULT:

Thus the Diffie-Hellman key exchange algorithm has been implemented using Java
Program and the output has been verified successfully.
 [Link]: 3
IMPLEMENT THE SIGNATURE SCHEME - DIGITAL
SIGNATURE STANDARD.

AIM:

To implement the SIGNATURE SCHEME - Digital Signature Standard.

ALGORITHM:

1. Create a KeyPairGenerator object.

2. Initialize the KeyPairGenerator object.
3. Generate the KeyPairGenerator. ...
4. Get the private key from the pair.
5. Create a signature object.
6. Initialize the Signature object.
7. Add data to the Signature object.
8. Calculate the Signature.

PROGRAM:

[Link]

import [Link];

import [Link];

import [Link];

import [Link];

import [Link];

public class CreatingDigitalSignature

public static void main(String args[]) throws Exception

Scanner sc = new Scanner([Link]);

[Link]("Enter some text");

String msg = [Link]();

KeyPairGenerator keyPairGen = [Link]("DSA");

[Link](2048);

KeyPair pair = [Link]();

PrivateKey privKey = [Link]();

Signature sign = [Link]("SHA256withDSA");

[Link](privKey);

byte[] bytes = "msg".getBytes();

[Link](bytes);

byte[] signature = [Link]();

[Link]("Digital signature for given text: "+new String(signature, "UTF8"));

OUTPUT:

Enter some text

Hai My name is Manigandan

Digital signature for given text: 0=@gRD???-?.???? /yGL?i??a!?

=== Code Execution Successful ===

RESULT:

Thus the Digital Signature Standard Signature Scheme has been implemented and the output
has been verified successfully.
 [Link]: 4 INSTALLATION OF WIRE SHARK, TCP DUMP AND OBSERVE
DATA TRANSFERRED IN CLIENT-SERVER COMMUNICATION
USING UDP/TCP AND IDENTIFY THE UDP/TCP DATAGRAM.

AIM:

To install the Wire shark, TCP dump and observe data transferred in client- server
communication using UDP/TCP and identity the TCP/UDP datagram.

PROCEDURE:

UDP (User Datagram Protocol) is an alternative communications protocol to Transmission

Control Protocol (TCP) used primarily for establishing low- latency and loss tolerating connections
between applications on the Internet. Both UDP and TCP run on top of the Internet Protocol (IP) and
are sometimes referred to as UDP/IP or TCP/IP. Both protocols send short packets of data, called
data grams. To look at the details of UDP (User Datagram Protocol). UDP is a transport protocol
used throughout the Internet as an alternative to TCP when reliability is not required. UDP provides
two services not provided by the IP layer. It provides port numbers to help distinguish different user
requests and, optionally, a checksum capability to verify that the data arrived intact. TCP has
emerged as the dominant protocol used for the bulk of Internet connectivity owing to services for
breaking large data sets into individual packets, checking for and resending lost packets and
reassembling packets into the correct sequence. But these additional services come at a cost in terms
of additional data overhead, and delays called latency. In contrast, UDP just sends the packets,
which means that it has much lower bandwidth overhead and latency. But packets can be lost or
received out of order as a result, owing to the different paths individual packets traverse between
sender and receiver. UDP is an ideal protocol for network applications in which perceived latency is
critical such as gaming, voice and video communications, which can suffer some data loss without
adversely affecting perceived quality. In some cases, forward error correction techniques are used to
improve audio and video quality in spite of some loss. UDP can also be used in applications that
require lossless data transmission when the application is configured to manage the process of
retransmitting lost packets and correctly arranging received packets. This approach can help to
improve the data transfer rate of large files compared with TCP. We first examine UDP.
STEP 1: CAPTURE A UDP TRACE

There are many ways to cause your computer to send and receive UDP messages since UDP is
widely used as a transport protocol. The easiest options are to:

 Do nothing but wait for a while. UDP is used for many “system protocols” that typically run
in the background and produce small amounts of traffic, e.g., DHCP for IP address
assignment and NTP for time synchronization.
 Use your browser to visit sites. UDP is used by DNS for resolving domain names to IP
addresses, so visiting fresh sites will cause DNS traffic to be sent.
 Be careful not to visit unsafe sites; pick recommended sites or sites you know about but
have not visited recently. Simply browsing the web is likely to cause a steady stream of DNS
traffic.
 Start up a voice-over-IP call with your favorite client. UDP is used by RTP, which is the
protocol commonly used to carry media samples in a voice or video call over the Internet.

Launch Wire shark by entering Wire shark in the “ask my anything” search box in Windows.

Once Wire shark starts, select the Ethernet interface.

Wireshark will automatically start capturing packets on the network. Now, enter a filter of udp.
(This is shown below).

When the capture is started, it will collect UDP traffic automatically.

Wait a little while (say 60 seconds) after you have stopped your activity to also observe any
background UDP traffic. It is likely that you will observe a trickle of UDP traffic because system
activity often uses UDP to communicate. We want to see some of this activity.

Use the Wireshark menus or buttons to stop the capture.

You should now have a trace with many UDP packets.

STEP 2: INSPECT THE TRACE

Different computers are likely to capture different kinds of UDP traffic depending on the
network setup and local activity. Observe that the protocol column is likely to show multiple
protocols, none of which is UDP. This is because the listed protocol is an application protocol
layered on top of UDP. Wireshark gives the name of the application protocol, not the (UDP)
transport protocol unless Wireshark cannot determine the application protocol. However, even if the
packets are listed as an application protocol, they will have a UDP protocol header for us to study,
following the IP and lower-layer protocol headers.
Select different packets in the trace (in the top panel) and browse the expanded UDP header (in the
middle panel). You will see that it contains the following fields:
Source Port, the port from which the UDP message is sent. It is given as a number and
possibly a text name; names are given to port values that are registered for use with a specific
application.

Destination Port. This is the port number and possibly name to which the UDP message is
des-tined. Ports are the only form of addressing in UDP. The computer is identified using the IP ad-
dress in the lower IP layer.

Length. The length of the UDP message.

Checksum. A checksum over the message that is used to validate its contents. Is your
checksum carrying 0 and flagged as incorrect for UDP messages sent from your computer? On
some computers, the operating system software leaves the checksum blank (zero) for the NIC to
compute and fill in as the packet is sent. This is called protocol offloading. It happens after
Wireshark see the packet, which causes Wireshark to believe that the

checksum is wrong and flag it with a different color to signal a problem. You can remove
these false errors if they are occurring by telling Wireshark not to validate the checksums. Select
“Preferences” from the Wireshark menus and expand the “Protocols” area. Look under the list until
you come to UDP. Uncheck “Validate checksum if possible”.

The UDP header has different values for different messages, but as you can see, it is short and
sweet. The remainder of the message is the UDP payload that is normally identified the higher-layer
protocol that it carries, e.g., DNS, or RTP.

STEP 3: UDP MESSAGE STRUCTURE

The figure below shows the UDP message structure as you observed. It shows the position of
the IP header, UDP header, and UDP payload. Within the UDP header, it shows the position and
size of each UDP field. Note how the Length field gives the length of the UDP payload plus the
UDP header. The checksum is 16 bits long and the UDP header is 8 bytes long.
STEP 4: UDP USAGE

The Protocol field in the IP header is how IP knows that the next higher protocol layer is
UDP. The IP Protocol field value of 17 indicates UDP. You might be surprised to find UDP
messages in your trace that neither come from your computer or are sent only to your computer.
You can see this by sorting on the Source and Destination columns.

The source and destinations will be domain names, if Network layer name resolution is
turned on, and otherwise IP addresses. (You can toggle this setting using the View menu and
selecting Name resolution.) You can find out the IP address of your computer using the “ip config”
command (Windows). The reason you may find UDP messages without your computer’s IP address
as either the source or destination IP address is that UDP is widely used as part of system protocols.
These protocols often send messages to all local computers who are interested in them using
broadcast and multicast addresses.

In our traces, we find DNS (the domain name system), MDNS (DNS traffic that uses IP
multicast), NTP (for time synchronization), NBNS (NetBIOS traffic), DHCP (for IP address
assignment), SSDP (a service discovery protocol), STUN (a NAT traversal protocol), RTP (for
carrying audio and video samples), and more.

A variety of broadcast and multicast addresses may be found. These include the Internet
broadcast ad- dress of [Link], subnet broadcast addresses such as [Link] and
multicast IP ad- dresses such as [Link] for multicast DNS. Note also that UDP messages can
be as large as roughly 64Kbytes but most often they are a few hundred bytes or less, typically
around 100 bytes.
TCP

OBJECTIVE

To see the details of TCP (Transmission Control Protocol). TCP is the main transport layer
protocol used in the Internet.

Step 1: Open the Trace

Open the trace file here: [Link] [Link]

Step 2: Inspect the Trace

Select a long packet anywhere in the middle of your trace whose protocol is listed as TCP.
Expand the TCP protocol section in the middle panel (by using the “+”expander or icon). All
packets except the initial HTTP GET and last packet of the HTTP response should be listed as TCP.
Picking a long packet ensures that we are looking at a download packet from the server to your
computer. Looking at the protocol layers, you should see an IP block before the TCP block. This is
because the TCP segment is carried in an IP. We have shown the TCP block expanded in our figure.
You will see roughly the following fields

First come the source port, then the destination port. This is the addressing that TCP adds be-
yond the IP address. The source port is likely to be 80 since the packet was sent by a web server and
the standard web server port is 80.

Then there is the sequence number field. It gives the position in the byte stream of the first
pay-load byte. Next is the acknowledgement field. It tells the last received position in the reverse
byte stream. The header length giving the length of the TCP header. The flags field has multiple
flag bits to indicate the type of TCP segment. You can expand it and look at the possible flags. Next
is a checksum, to detect transmission errors.

There may be an Options field with various options. You can expand this field and explore if
you would like, but we will look at the options in more detail later. Finally, there may be a TCP
payload, carrying the bytes that are being transported. As well as the above fields, there may be
other informational lines that Wireshark provides to help you interpret the packet. We have covered
only the fields that are carried across the network.

Step 3: TCP Segment Structure

This drawing differs from the text drawing in the book in only minor respects:

The Header length and Flags fields are combined into a 2-byte quantity. It is not easy to
deter-mine their bit lengths with Wireshark. The Urgent Pointer field is shown as dotted. This field
is typically not used, and so does not show up in Wireshark and we do not expect you to have it in
your drawing. You can notice its existence in Wireshark, however, by observing the zero bytes in
the segment that are skipped over as you select the different fields.

The Options field is shown dotted, as it may or may not be present for the segments in your
trace. Most often it will be present, and when it is then its length will be a multiple of four bytes.

The Payload is optional. It is present for the segment you viewed, but not present on an Ack
only segment, for example.
Step 4: TCP Connection Setup/Teardown Three-Way Handshake

To see the “three-way handshake” in action, look for a TCP segment with the SYN flag on.
These are up at the beginning of your trace, and the packets that follow it (see below).

The SYN flag is noted in the Info column. You can also search for packets with the SYN flag
on using the filter expression “[Link]==1”. (See below)

A “SYN packet” is the start of the three-way handshake. In this case it will be sent from your
computer to the remote server. The remote server should reply with a TCP segment with the SYN
and ACK flags set, or a “SYN ACK packet”. On receiving this segment, your computer will ACK it,
consider the connection set up, and begin sending data, which in this case will be the HTTP request.
Step 5: TCP Connection Setup/Teardown

Next, we wish to clear the display filter [Link]==1 so that we can once again see all the
packets in our original trace.

Do this by clearing the display filter as shown below.

If you do this correctly, you should see the full trace. We are most interested in the first three
packets.

Below is a time sequence diagram of the three-way handshake in your trace, up to and
including the first data packet (the HTTP GET request) sent by ‘your computer’ when the
connection is established.

As usual, time runs down the page, and lines across the page indicate segments.

There are several features to note:

 The initial SYN has no ACK number, only a sequence number. All subsequent packets have
ACK numbers. The initial sequence numbers are shown as zero in each direction. This is because
our Wireshark is configured to show relative sequence numbers. The actual sequence number is
some large 32-bit number, and it is different for each end.

The ACK number is the corresponding sequence number plus 1.

Our computer sends the third part of the handshake (the ACK) and then sends data right
away in a different packet. It would be possible to combine these packets, but they are typically
separate (because one is triggered by the OS and one by the application). For the Data segment, the
sequence number and ACK stay with the previous values. The sequence number will advance as the
sender sends more data. The ACK number will advance as the sender receives more data from the
remote server.

The three packets received and sent around 88ms happen very close together compared to the
gap between the first and second packet. This is because they are local operations; there is no
network delay involved.

STEP 5: CONNECTION OPTIONS

As well as setting up a connection, the TCP SYN packets negotiate parameters between the
two ends using Options. Each end describes its capabilities, if any, to the other end by including the
appropriate Options on its SYN. Often both ends must support the behavior for it to be used during
data transfer.

Common Options include Maximum Segment Size (MSS) to tell the other side the largest
segment that can be received, and Timestamps to include information on segments for estimating the
round trip time. There are also Options such as NOP (No-operation) and End of Option list that
serve to format the Options but do not advertise capabilities.

You do not need to include these formatting options in your answer above. Options can also
be carried on regular segments after the connection is set up when they play a role in data transfer.
This depends on the Option. For example: the MSS option is not carried on each packet because it
does not convey new information; timestamps may be included on each packet to keep a fresh
estimate of the RTT; and options such as SACK (Selective Acknowledgments) are used only when
data is received out of order.
 Our TCP Options are Maximum Segment Size, Window Scale, SACK permitted, and
Timestamps. Each of these Options is used in both directions. There are also the NOP & End of
Option List formatting options.

Here is an example of a FIN teardown:

Points to note:

The teardown is initiated by the computer; it might also be initiated by the server.

Like the SYN, the FIN flag occupies one sequence number. Thus, when the sequence number
of the FIN is 192, the corresponding Ack number is 193.

Your sequence numbers will vary. Our numbers are relative (as computed by Wireshark) but
clearly depend on the resource that is fetched. You can tell that it is around 1 MB long.

The RTT in the FIN exchange is like that in the SYN exchange, as it should be. Your RTT
will vary depending on the distance between the computer and server as before.

STEP 6: FIN/RST TEARDOWN

Finally, the TCP connection is taken down after the download is complete. This is typically
done with FIN (Finalize) segments. Each side sends a FIN to the other and acknowledges the FIN
they receive; it is similar to the three-way handshake. Alternatively, the connection may be torn
down abruptly when one end sends a RST (Reset). This packet does not need to be acknowledged
by the other side.

Below is a picture of the teardown in your trace, starting from when the first FIN or RST is
issued until the connection is complete.

It shows the sequence and ACK numbers on each segment.

Points to note:

The teardown is initiated by the computer; it might also be initiated by the server.

The teardown is abrupt – a single RST in this case, and then it is closed, which the other end
must accommodate.

The sequence and Ack numbers do not really matter here. They are simply the (relative
Wireshark) values at the end of the connection. Since there is no round trip exchange, no RTT can
be estimated.

STEP 7: TCP DATA TRANSFER

For this part, we are going to launch an older version of Wireshark called Wireshark legacy.
You do this by selecting the Wireshark legacy application as follows.
When it launches, you should open the trace-tcp file which is in your downloads folder from earlier.

You should then be presented with the same trace-tcp as used previously in this exercise.

The middle portion of the TCP connection is the data transfer, or download, in our trace. This
is the main event. To get an overall sense of it, we will first look at the download rate over time.

Under the Statistics menu select an “IO Graph” (as shown below).

Under the Statistics menu select an “IO Graph” (as shown below).
 You should end up with a graph like below. By default, this graph shows the rate of packets
over time. You might be tempted to use the “TCP Stream Graph” tools under the Statistics menu
instead.

However, these tools are not useful for our case because they assume the trace is taken near
the computer sending the data; our trace is taken near the computer receiving the data.

Now we will tweak it to show the download rate with the changes given below

On the x-axis, adjust the tick interval and pixels per tick. The tick interval should be small
enough to see into the behavior over the trace, and not so small that there is no averaging. 0.1
seconds is a good choice for a several second trace.
 The pixels per tick can be adjusted to make the graph wider or narrower to fill the window.
Make this 10. See below

On the y-axis, change the unit to be Bits/Tick. The default is Packet/Tick. By changing it,
we can easily work out the bits/sec throughput by taking the y-axis value and scaling as appropriate,
e.g., 10X for ticks of 0.1 seconds.

Add a filter expression to see only the download packets. So far we are looking at all of the
pack-ets. Assuming the download is from the usual web server port of 80, you can filter for it with a
filter of “[Link] port==80”.

Don’t forget to press Enter, and you may need to click the “Graph” button to cause it to redisplay.

To see the corresponding graph for the upload traffic, enter a second filter in the next box. Again
assuming the usual web server port, the filter is “[Link] port==80”. After you press Enter and click
the Graph button, you should have two lines on the graph. Our graph for this procedure is shown in
the figure on next page. From it we can see the sample down- load rate quickly increase from zero
to a steady rate, with a bit of an exponential curve. This is slow- start.

The download rate when the connection is running is approximately 2.5 Mbps. The upload
rate is as teady, small trickle of ACK traffic. Our download also proceeds fairly steadily until it is
done. This is the ideal, but many downloads may display more variable behavior if, for example, the
available bandwidth varies due to competing downloads, the download rate is set by the server
rather than the network, or enough packets are lost to disrupt the transfer.

Note, you can click on the graph to be taken to the nearest point in the trace if there is a
feature you would like to investigate. Try clicking on parts of the graph and watch where you are
taken in the Wireshark trace window.
Inspect the packets in the download in the middle of your trace for these features:

You should see a pattern of TCP segments received carrying data and ACKs sent back to the
server. Typically, there will be one ACK every couple of packets. These ACKs are called Delayed
ACKs. By delaying for a short while, the number of ACKs is halved.

Since this is a download, the sequence number of received segments will increase; the ACK
number of subsequently transmitted segments will increase correspondingly.

Since this is a download, the sequence number of transmitted segments will not increase
(after the initial get). Thus the ACK number on received segments will not increase either.

Each segment carries Window information to tell the other end how much space remains in
the buffer. The Window must be greater than zero, or the connection will be stalled by flow control.
Note the data rate in the download direction in packets/second and bits/second once the TCP
connection is running well is 250 packet/sec and 2.5 Mbps.

Our download packets are 1434 bytes long, of which 1368 bytes are the TCP payload
carrying contents. Thus 95% of the download is content.

The data rate in the upload direction in packets/second and bits/second due to the ACK
packets is 120 packets/sec and 60,000 bits/sec. We expect the ACK packet rate to be around half of
the data packet rate for the typical pattern of one delayed ACK per two data packets received.
 The ACK bit rate will be at least an order of magnitude below the data bit rate as the packets
are much smaller, around 60 bytes. The Ack number tells the next expected sequence number
therefore it will be X plus the number of TCP payload bytes in the data segment.

RESULT:

Thus the above Installation of Wire shark, tcp dump and observe data transferred in client-
server communication using UDP/TCP and identify the UDP/TCP datagram is installed and verified
Successfully.
 [Link]: 5
CHECK MESSAGE INTEGRITY AND CONFIDENTIALITY USING
SSL

AIM:
To implement the Check message integrity and confidentiality using SSL.

ALGORITHM:

1. **Setting up SSL/TLS:**
Use Java's `SSLSocket` and `SSLServerSocket` classes to establish a secure
connection between client and server.

2. **Ensuring Confidentiality:**
Use SSL/TLS to encrypt the communication between client and server. This
encryption ensures that the message content is secure from eavesdropping.

3. **Ensuring Integrity:**
SSL/TLS provides integrity by using cryptographic hashing algorithms (like HMAC)
to verify that the transmitted data has not been altered during transmission.

PROGRAM:

import [Link].*;
import [Link].*;
import [Link].*;
public class Server
{
public static void main(String[] args)
{
try
{
SSLServerSocketFactory serverSocketFactory = (SSLServerSocketFactory)
[Link]();
SSLServerSocket serverSocket = (SSLServerSocket)
[Link](9999); SSLSocket sslSocket = (SSLSocket)
[Link]();
// Read data from client
BufferedReader input = new BufferedReader(new InputStreamReader([Link]()));
String clientMessage = [Link]();
[Link]("Received from client: " + clientMessage);
// Close streams and socket
[Link](); [Link](); [Link]();
} catch (IOException e) { [Link]();
}
} }
**Client:**
import [Link].*;
import [Link].*;
import [Link].*;
public class Client {
public static void main(String[] args)
{
try
{
SSLSocketFactory sslSocketFactory = (SSLSocketFactory) [Link]();
SSLSocket sslSocket = (SSLSocket) [Link]("localhost", 9999);
// Send data to server
PrintWriter output = new PrintWriter([Link](), true);
[Link]("Hello, server!");
// Close streams and socket [Link](); [Link]();
} catch (IOException e) { [Link]();
}
}
}

RESULT:

Thus the message integrity and confidentiality using SSL is executed Successfully.
 [Link]: 6
EXPERIMENT EAVESDROPPING, DICTIONARY ATTACKS, MITM
ATTACKS

AIM:
To study the Eavesdropping, Dictionary attacks, MITM attacks.

PROCEDURE:

A man-in-the-middle attack is a type of eavesdropping attack, where attackers interrupt an

existing conversation or data transfer. After inserting themselves in the "middle" of the transfer, the
attackers pretend to be both legitimate participants.

This enables an attacker to intercept information and data from either party while also
sending malicious links or other information to both legitimate participants in a way that might not
be detected until it is too late.

You can think of this type of attack as similar to the game of telephone where one person's
words are carried along from participant to participant until it has changed by the time it reaches the
final person. In a man-in-the-middle attack, the middle participant manipulates the conversation
unknown to either of the two legitimate participants, acting to retrieve confidential information and
otherwise cause damage.

Man-in-the-middle attacks:

 Are a type of session hijacking

 Involve attackers inserting themselves as relays or proxies in an ongoing, legitimate
conversation or data transfer
 Exploit the real-time nature of conversations and data transfers to go undetected
 Allow attackers to intercept confidential data
 Allow attackers to insert malicious data and links in a way indistinguishable from legitimate
data

Examples of MITM Attacks

Although the central concept of intercepting an ongoing transfer remains the same, there are
several different ways attackers can implement a man-in-the-middle attack.
Scenario 1: Intercepting Data

1. The attacker installs a packet sniffer to analyze network traffic for insecure
communications.
2. When a user logs in to a site, the attacker retrieves their user information and redirects
them to a fake site that mimics the real one.
3. The attacker's fake site gathers data from the user, which the attacker can then use
on the real site to access the target's information.

In this scenario, an attacker intercepts a data transfer between a client and server. By tricking the
client into believing it is still communicating with the server and the server into believing it is still
receiving information from the client, the attacker is able to intercept data from both as well as inject
their own false information into any future transfers.

Scenario 2: Gaining Access to Funds

1. The attacker sets up a fake chat service that mimics that of a well-known bank.
2. Using knowledge gained from the data intercepted in the first scenario, the attacker pretends to
be the bank and starts a chat with the target.
3. The attacker then starts a chat on the real bank site, pretending to be the target and passing
along the needed information to gain access to the target's account.

In this scenario, the attacker intercepts a conversation, passing along parts of the discussion to
both legitimate participants.
Real-World MITM Attacks

In 2011, Dutch registrar site DigiNotar was breached, which enabled a threat actor to gain
access to 500 certificates for websites like Google, Skype, and others. Access to these certificates
allowed the attacker to pose as legitimate websites in a MITM attack, stealing users' data after
tricking them into entering passwords on malicious mirror sites. DigiNotar ultimately filed for
bankruptcy as a result of the breach.

In 2017, credit score company Equifax removed its apps from Google and Apple after a breach
resulted in the leak of personal data. A researcher found that the app did not consistently use
HTTPS, allowing attackers to intercept data as users accessed their accounts.

Interactions Susceptible to MITM Attacks

Any improperly secured interaction between two parties, whether it's a data transfer between a
client and server or a communication between two individuals over an internet messaging system,
can be targeted by man-in-the- middle attacks. Logins and authentication at financial sites,
connections that should be secured by public or private keys, and any other situation where an
ongoing transaction could grant an attacker access to confidential information are all susceptible.

Other Forms of Session Hijacking

Man-in-the-middle attacks are only one form of session hijacking. Others include:

 Sniffing - An attacker uses software to intercept (or "sniff") data being sent to or from
your device.
 Side jacking - An attacker sniffs data packets to steal session cookies from your device,
allowing them to hijack a user session if they find unencrypted login information.
 Evil Twin - An attacker duplicates a legitimate Wi-Fi network, enabling them to
intercept data from users who believe they are signing on to the real network.

RESULT:

Thus the study of Eavesdropping, Dictionary attacks, MITM attacks is successfully

completed.
 [Link]: 7`
EXPERIMENT WITH SNIFF TRAFFIC USING ARP POISONING

AIM:

To demonstrate Intrusion Sniff Traffic using ARP Poisoning.

STEPS FOR CONFIGURING ARP:

ARP is the acronym for Address Resolution Protocol. It is used to convert IP address to
physical addresses [MAC address] on a switch. The host sends an ARP broadcast on the network,
and the recipient computer responds with its physical address [MAC Address]. The resolved
IP/MAC address is then used to communicate. ARP poisoning is sending fake MAC addresses to
the switch so that it can associate the fake MAC addresses with the IP address of a genuine
computer on a network and hijack the traffic.

ARP Poisoning Countermeasures:

Static ARP entries: these can be defined in the local ARP cache and the switch configured to
ignore all auto ARP reply packets. The disadvantage of this method is, it’s difficult to maintain on
large networks. IP/MAC address mapping has to be distributed to all the computers on the network.

ARP poisoning detection software: these systems can be used to cross check the IP/MAC address
resolution and certify them if they are authenticated.

Uncertified IP/MAC address resolutions can then be blocked.

Operating System Security: this measure is dependent on the operating system been used. The
following are the basic techniques used by various operating systems.

 Linux based: these work by ignoring unsolicited ARP reply packets.

 Microsoft Windows: the ARP cache behavior can be configured via the registry. The
following list includes some of the software that can be used to protect networks against
sniffing;
 Anti ARP– provides protection against both passive and active sniffing
 Agnitum Outpost Firewall–provides protection against passive Sniffing.
 XArp– provides protection against both passive and active sniffing
  Mac OS: ArpGuard can be used to provide protection. It protects against both active and
passive sniffing.

Hacking Activity: Configure ARP entries in Windows

We are using Windows 7 for this exercise, but the commands should be able to work on other
versions of windows as well. Open the command prompt and enter the following command arp –a

HERE,

 aprcalls the ARP configure program located in Windows/System32 directory

 -a is the parameter to display to contents of the ARP cache

You will get results similar to the following.

Note: dynamic entries are added and deleted automatically when using TCP/IP sessions with remote
computers. Static entries are added manually and are deleted when the computer is restarted, and the
network interface card restarted or other activities that affect it. Adding static entries Open the
command prompt then use the ipconfig /all command to get the IP and MAC address.
The MAC address is represented using the Physical Address and the IP address is IPv4Address.

Enter the following command

arp –s [Link] 60-36-DD-A6-C5-43

Note: The IP and MAC address will be different from the ones used here. This is because they are
unique.

Use the following command to view the ARP cache arp –a

You will get the following results

Note the IP address has been resolved to the MAC address we provided and it is of a static type.
Deleting an ARP cache entry

Use the following command to remove an entry arp –d [Link]

P.S. ARP poisoning works by sending fake MAC addresses to the switch.

RESULT:

Thus the Sniff Traffic using ARP Poisoning is demonstrated successfully.

 [Link]: 8
DEMONSTRATE INTRUSION DETECTION SYSTEM USING ANY
TOOL.

AIM:

To demonstrate Intrusion Detection System (IDS) using Snort software tool.

STEPS ON CONFIGURING AND INTRUSION DETECTION:

1. Download Snort from the [Link] website. ([Link] downloads)

2. Download Rules([Link] You must register to get the rules. (You
should download these often)
3. Double click on the .exe to install snort. This will install snort in the “C:\Snort” [Link] is
important to have WinPcap ([Link] installed
4. Extract the Rules file. You will need WinRAR for the .gz file.
5. Copy all files from the “rules” folder of the extracted folder. Now paste the rules into
“C:\Snort\rules” folder.
6. Copy “[Link]” file from the “etc” folder of the extracted folder. You must paste it into
“C:\Snort\etc” folder. Overwrite any existing file. Remember if you modify your [Link]
file and download a new file, you must modify it for Snort to work.
7. Open a command prompt ([Link]) and navigate to folder “C:\Snort\bin” folder. (at the
Prompt, type cd\snort\bin)
8. To start (execute) snort in sniffer mode use following command: snort -dev -i 3

-i indicates the interface number. You must pick the correct interface number.

In my case, it is 3.

-dev is used to run snort to capture packets on your network.

To check the interface list, use following command:

snort -W
Finding an interface

You can tell which interface to use by looking at the Index number and finding Microsoft. As
you can see in the above example, the other interfaces are for VMWare. My interface is 3.

9. To run snort in IDS mode, you will need to configure the file “[Link]”
according to your network environment.

10. To specify the network address that you want to protect in [Link] file, look for the
following line. var HOME_NET [Link]/24 (You will normally see any here)
11. You may also want to set the addresses of DNS_SERVERS, if you have some on
your network.
Example:
example snort
12. Change the RULE_PATH variable to the path of rules folder. var
RULE_PATH c:\snort\rules path to rules

13. Change the path of all library files with the name and path on your system. and you
must change the path of snort_dynamicpreprocessorvariable.
C:\Snort\lib\snort_dynamiccpreprocessor

You need to do this to all library files in the “C:\Snort\lib” folder. The old path might
be: “/usr/local/lib/…”. you will need to replace that path with your system path. Using
C:\Snort\lib

14. Change the path of the “dynamicengine” variable value in the “[Link]” file.
 Example:
dynamicengine C:\Snort\lib\snort_dynamicengine\sf_engine.dll
15. Add the paths for “include [Link]” and “include [Link]”
files.
include c:\snort\etc\[Link]
include c:\snort\etc\[Link]

16. Remove the comment (#) on the line to allow ICMP rules, if it is
commented
with a #.
include $RULE_PATH/[Link]
17. You can also remove the comment of ICMP-info rules comment, if it is
commented.
include $RULE_PATH/[Link]

18. To add log files to store alerts generated by snort, search for the “output log” test
in [Link] and add the following line: output alert_fast: snort- [Link]
19. Comment (add a #) the whitelist $WHITE_LIST_PATH/white_list.rules and the
blacklist
Change the nested_ip inner, \ to nested_ip inner #, \

20. Comment out (#) following lines:

#preprocessor normalize_ip4
#preprocessor normalize_tcp: ips ecn stream
#preprocessor normalize_icmp4 #preprocessor
normalize_ip6
#preprocessor normalize_icmp6

21. Save the “[Link]” file

22. To start snort in IDS mode, run the following command:

snort -c c:\snort\etc\[Link] -l c:\snort\log -i 3
(Note: 3 is used for my interface card)

If a log is created, select the appropriate program to open it. You can use WordPard or
NotePad++ to read the file.
 To generate Log files in ASCII mode, you can use following command while running snort
in IDS mode:
snort -A console -i3 -c c:\Snort\etc\[Link] -l c:\Snort\log -K ascii

23. Scan the computer that is running snort from another computer by using PING or
NMap (ZenMap).
After scanning or during the scan you can check the [Link] file in the log
folder to insure it is logging properly. You will see IP address folders appear.
Snort monitoring traffic –

RESULT:

Thus the Intrusion Detection System (IDS) has been demonstrated by using the Open
Source Snort Intrusion Detection Tool.
 [Link]: 9
EXPLORE NETWORK MONITORING TOOLS

AIM:

To download the N-Stalker Vulnerability Assessment Tool and exploring the features.

EXPLORING N-STALKER:

 N-Stalker Web Application Security Scanner is a Web security assessment tool.

 It incorporates with a well-known N-Stealth HTTP Security Scanner and 35,000 Web

attack signature database.

 This tool also comes in both free and paid version.

 Before scanning the target, go to “License Manager” tab, perform the update.

 Once update, you will note the status as up to date.

 You need to download and install N-Stalker from [Link].

1. Start N-Stalker from a Windows computer. The program is install edunder

Start ➪ Programs ➪ N-Stalker ➪ N-Stalker Free Edition.

2. Enter a host address or a range of addresses to scan.

3. Click Start Scan.

4. After the scan completes, the N-Stalker Report Manager will prompt

5. You to select a format for the resulting report as choose Generate HTML.

6. Review the HTML report for vulnerabilities

Now goto “Scan Session”, enter the target URL.
In scan policy, you can select from the four options,
 Manual test which will crawl the website and will be waiting for manual attacks.
 full xss assessment
 owasp policy
 Web server infrastructure analysis.
Once, the option has been selected, next step is “Optimize settings” which will crawl the
whole website for further analysis.
In review option, you can get all the information like host information, technologies
used, policy name, etc.
Once done, start the session and start the scan.

The scanner will crawl the whole website and will show the scripts, broken pages,
hidden fields, information leakage, web forms related information which helps to analyze
further.
 Once the scan is completed, the NStalker scanner will show details like severity level,
vulnerability class, why is it an issue, the fix for the issue and the URL which is vulnerable to the
particular vulnerability?

RESULT:

Thus the N-Stalker Vulnerability Assessment tool has been downloaded, installed and the
features has been explored by using a vulnerable website.
 [Link]: 10
STUDY TO CONFIGURE FIREWALL, VPN.

AIM:
To configure the Firewall and VPN networks.
CONFIGURE FIREWALL RULES
When you configure Cloud VPN tunnels to connect to your peer network, review and modify
firewall rules in your Google Cloud and peer networks to make sure that they meet your needs. If
your peer network is another Virtual Private Cloud (VPC) network, then configure Google Cloud
firewall rules for both sides of the network connection.
GOOGLE CLOUD FIREWALL RULES

Google Cloud firewall rules apply to packets sent to and from virtual machine (VM)
instances within your VPC network and through Cloud VPN tunnels.

The implied allow egress rules allow VM instances and other resources in your Google
Cloud network to make outgoing requests and receive established responses. However, the implied
deny ingress rule blocks all incoming traffic to your Google Cloud resources.

At a minimum, create firewall rules to allow ingress traffic from your peer network to
Google Cloud. If you created egress rules to deny certain types of traffic, you might also need to
create other egress rules.

Traffic containing the protocols UDP 500, UDP 4500, and ESP (IPsec, IP protocol 50) is
always allowed to and from one or more external IP addresses on a Cloud VPN gateway. However,
Google Cloud firewall rules do not apply to the post- encapsulated IP sec packets that are sent from
a Cloud VPN gateway to a peer VPN gateway.

Example configurations

For multiple examples of restricting ingress or egress traffic, see the configuration examples
in the VPC documentation.

The following example creates an ingress allow firewall rule. This rule permits all TCP,
UDP, and ICMP traffic from your peer network's CIDR to your VMs in your VPC network.
Permissions required for this task

1. In the Google Cloud console, go to the VPN tunnels page. Go to VPN tunnels
2. Click the VPN tunnel that you want to use.
3. In the VPN gateway section, click the name of the VPC network. This action directs
you to the VPC network details page that contains the tunnel.
4. Click the Firewall rules tab.
5. Click Add firewall rule. Add a rule for TCP, UDP, and ICMP:
Name: Enter allow-tcp-udp-icmp.
Source filter: Select IPv4 ranges.
Source IP ranges: Enter a Remote network IP range value from when you created
the tunnel. If you have more than one peer network range, enter each one. Press the
Tab key between entries. To allow traffic from all source IPv4 addresses in your peer
network, specify [Link]/0.
Specified protocols or ports: Select tcp and udp.
Other protocols: Enter icmp.
Target tags: Add any valid tag or tags.
6. Click Create.
If you need to allow access to IPv6 addresses on your VPC network from your
peer network, add an allow-ipv6-tcp-udp-icmpv6 firewall rule.

1. Click Add firewall rule. Add a rule for TCP, UDP, and ICMPv6:
Name: Enter allow-ipv6-tcp-udp-icmpv6.
Source filter: Select IPv6 ranges.
Source IP ranges: Enter a Remote network IP range value from when you
created the tunnel. If you have more than one peer network range, enter each
one.
Press the Tab key between entries. To allow traffic from all source IPv6
addresses in your peer network, specify::/0.
Specified protocols or ports: Select tcp and udp.
Other protocols: Enter 58. 58 is the protocol number for ICMPv6.
Target tags: Add any valid tag or tags.
2. Click Create.
Create other firewall rules if necessary. Alternatively, you can create rules
from the Google Cloud console Firewall page.
Peer firewall rules

When configuring your peer firewall rules, consider the following:

 Configure rules to allow egress and ingress traffic to and from the IP ranges used by the
subnets in your VPC network.
 You can choose to permit all protocols and ports, or you can restrict traffic to only the
necessary set of protocols and ports to meet your needs.
 Allow ICMP traffic if you need to use ping to be able to communicate among peer
systems and instances or resources in Google Cloud.
 If you need to access IPv6 addresses on your peer network with ping, allow ICMPv6
(IP protocol 58) in your peer firewall.
 Both your network devices (security appliances, firewall devices, switches, routers, and
gateways) and software running on your systems (such as firewall software included
with an operating system) can implement on-premises firewall rules. To allow traffic,
configure all firewall rules in the path to your VPC network appropriately.
 If your VPN tunnel uses dynamic (BGP) routing, make sure that you allow BGP traffic
for the link-local IP addresses. For more details, see the next section.

BGP considerations for peer gateways

Dynamic (BGP) routing exchanges route information by using TCP port 179. Some VPN
gateways, including Cloud VPN gateways, allow this traffic automatically when you choose
dynamic routing. If your peer VPN gateway does not, configure it to allow incoming and outgoing
traffic on TCP port 179. All BGP IP addresses use the link-local [Link]/16 CIDR block.

If your peer VPN gateway is not directly connected to the internet, make sure that it and peer
routers, firewall rules, and security appliances are configured to at least pass BGP traffic (TCP port
179) and ICMP traffic to your VPN gateway. ICMP is not required, but it is useful to test
connectivity between a Cloud Router and your VPN gateway. The range of IP addresses to which
your peer firewall rule should apply must include the BGP IP addresses of the Cloud Router and
your gateway.

RESULT:

Thus the study of Firewall and VPN is demonstrated successfully.