Reason Of TCP IP Unsecured Computer Science Essay

Published:

This essay has been submitted by a student. This is not an example of the work written by our professional essay writers.

Introduction: Beginning of the TCP/IP protocol was not needed too much security. But now a days technology are updating day by day. In this reason many security hole are uncovered of TCP/IP protocol. The most possible reason of TCP/IP unsecured is given bellow.

a) Reason of TCP/IP Unsecured

No traffic priority (easy to flood the network).

Traffic can be injected; packets can be stolen or hijacked.

UDP (datagram based) offers no authentication.

TCP (connection based) offers weak authentication.

No confidentiality (no encryption).

IP spoofing is easy (weak authentication), machines can lie about IP addresses. Routers can be tricked. Header checksums are not sufficient.

Checksums are easy to cheat (weak algorithm).

Attack on TCP/IP

IP Based Attacks

Network Sniffers (packet sniffing or eavesdropping):

IP spoofing attacks : Masquerade

Connection hijacking : Attack to Integrity

Data Spoofing : Attack to Integrity

To halt computers (disabling their intended use:

Attack to Availability Denial of Service

Win Nuke(Nuking)

Teardrop

Sapping

SYN Flooding

Attacks to Name service - DNS

Client flooding

Bogus name server cache loading

Rogue DNS servers

TCP "SYN" Attacks:

SYN attacks (also known as SYN Flooding) take advantage of a flaw in how most hosts implement this three-way handshake. When Host B receives the SYN request from A, it must keep track of the partially opened connection in a "listen queue" for at least 75 seconds. This is to allow successful connections even with long network delays. A malicious host can exploit the small size of the listen queue by sending multiple SYN requests to a host, but never replying to the SYN & ACK the other host sends back. By doing so, the other host's listen queue is quickly filled up, and it will stop accepting new connections, until a partially opened connection in the queue is completed or times out.

Figure 6. SYN Flooding

IP Spoofing:

IP Spoofing is an attack where an attacker pretends to be sending data from an IP address other than its own. The IP layer assumes that the source address on any IP packet it receives is the same IP address as the system that actually sent the packet -- it does no authentication. The remote host will send all replies to the spoofed source address -- not to the host actually doing the spoofing. So, an attacker using IP spoofing is unlikely to see output from the remote system. An attacker needs to use the correct TCP sequence numbers if they plan on establishing a TCP connection with the attacked host.

For the upper described reason TCP/IP are unsecured include Sequence Guessing, Source Routing, Connecting Hijacking, Desynchronization during connection establishment, Desynchronization in the middle of a connection, Routing (RIP) attacks, ICMP attacks, DNS attacks. It is not possible to describe briefly for word limitation.

b) Secure the TCP/IP use SSL, IPsec, Kerberos Protocol

SSL

Secure Sockets Layer, SSL, is the standard security technology for creating an encrypted link between a web server and a browser. This link ensures that all data passed between the web server and browser remains private and integral. SSL is an industry standard and is used by millions of websites in the protection of their online transactions with their customers. In order to be able to generate an SSL link, a web server requires an SSL Certificate.

The SSL protocol runs above TCP/IP and below higher-level protocols such as HTTP or IMAP. It uses TCP/IP on behalf of the higher-level protocols, and in the process allows an SSL-enabled server to authenticate itself to an SSL-enabled client, allows the client to authenticate itself to the server, and allows both machines to establish an encrypted connection.

The SSL protocol includes two sub-protocols: the SSL record protocol and the SSL handshake protocol. The SSL record protocol defines the format used to transmit data. The SSL handshake protocol involves using the SSL record protocol to exchange a series of messages between an SSL-enabled server and an SSL-enabled client

The SSL Handshake

The SSL protocol uses a combination of public-key and symmetric key encryption. Symmetric key encryption is much faster than public-key encryption, but public-key encryption provides better authentication techniques. An SSL session always begins with an exchange of messages called the SSL handshake. The handshake allows the server to authenticate it self to the client using public-key techniques, then allows the client and the server to cooperate in the creation of symmetric keys used for rapid encryption, decryption, and tamper detection during the session that follows. Optionally, the handshake also allows the client to authenticate itself to the server.

It is not possible to describe briefly the step of SSL Handshaking because the word limitation.

IPsec

Internet Protocol Security (IPsec) is a protocol suite for securing Internet Protocol (IP) communications by authenticating and encrypting each IP packet of a data stream. IPsec also includes protocols for establishing mutual authentication between agents at the beginning of the session and negotiation of cryptographic keys to be used during the session. IPsec can be used to protect data flows between a pair of hosts (e.g. computer users or servers), between a pair of security gateways (e.g. routers or firewalls), or between a security gateway and a host. IPsec is a dual mode, end-to-end, security scheme operating at the Internet Layer of the Internet Protocol Suite or OSI model Layer 3. IPsec can be used for protecting any application traffic across the Internet.

Authentication Header

Authentication Header (AH) is a member of the IPsec protocol suite. AH operates directly on top of IP, using IP protocol number 51.

The structure of Authentication Header is given bellow.

Authentication Header format

Offsets

Octet16

0

1

2

3

Octet16

Bit10

0

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30

31

0

0

Next Header

Payload Len

Reserved

4

32

Security Parameters Index (SPI)

8

64

Sequence Number

C

96

Integrity Check Value (ICV)

…

…

…

Next Header (8 bits) 

Type of the next header, indicating what upper-layer protocol was protected. The value is taken from the list of IP protocol numbers.

Payload Len (8 bits) 

The length of this Authentication Header in 4-octet units, minus 2 (a value of 0 means 8 octets, 1 means 12 octets, etcetera). Although the size is measured in 4-octet units, the length of this header needs to be a multiple of 8 octets if carried in an IPv6 packet. This restriction does not apply to an Authentication Header carried in an IPv4 packet.

Reserved (16 bits) 

Reserved for future use (all zeroes until then).

Security Parameters Index (32 bits) 

Arbitrary value which is used (together with the source IP address) to identify the security association of the sending party.

Sequence Number (32 bits) 

A monotonically increasing sequence number (incremented by 1 for every packet sent) to prevent replay attacks.

Integrity Check Value (multiple of 32 bits) 

Variable length checks value. It may contain padding to align the field to an 8-octet boundary for IPv6, or a 4-octet boundary for IPv4.

Encapsulating Security Payload

Encapsulating Security Payload (ESP) is a member of the IPsec protocol suite. In IPsec it provides origin authenticity, integrity, and confidentiality protection of packets. ESP operates directly on top of IP, using IP protocol number 50.

The structure of Encapsulating Security Payload is given bellow.

Encapsulating Security Payload format

Offsets

Octet16

0

1

2

3

Octet16

Bit10

0

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30

31

0

0

Security Parameters Index (SPI)

4

32

Sequence Number

C

96

Payload data

…

…

…

…

 

 

…

…

 

Padding (0-255 octets)

 

…

…

 

Pad Length

Next Header

…

…

Integrity Check Value (ICV)

…

…

…

Security Parameters Index (32 bits) 

Arbitrary value which is used (together with the source IP address) to identify the security association of the sending party.

Sequence Number (32 bits) 

A monotonically increasing sequence number (incremented by 1 for every packet sent) to protect against replay attacks. There is a separate counter kept for every security association.

Payload data (variable) 

The protected contents of the original IP packet, including any data used to protect the contents (e.g. an Initialization Vector for the cryptographic algorithm). The type of content that was protected is indicated by the Next Header field.

Padding (0-255 octets) 

Padding for encryption, to extend the payload data to a size that fits the encryption's cipher block size, and to align the next field.

Pad Length (8 bits) 

Size of the padding in octets.

Next Header (8 bits) 

Type of the next header. The value is taken from the list of IP protocol numbers.

Integrity Check Value (multiple of 32 bits) 

Variable length checks value. It may contain padding to align the field to an 8-octet boundary for IPv6, or a 4-octet boundary for IPv4.

Kerberos

Kerberos is a network authentication protocol. It is designed to provide strong authentication for client/server applications by using secret-key cryptography. Kerberos was created by MIT as a solution to these network security problems. The Kerberos protocol uses strong cryptography so that a client can prove its identity to a server (and vice versa) across an insecure network connection. After a client and server have used Kerberos to prove their identity, they can also encrypt all of their communications to assure privacy and data integrity as they go about their business.

Protocol

A simplified and more detailed description of the protocol follows. The following abbreviations are used:

AS = Authentication Server

SS = Service Server

TGS = Ticket-Granting Server

TGT = Ticket-Granting Ticket

The client authenticates to the AS once using a long-term shared secret (e.g. a password) and receives a TGT from the AS. Later, when the client wants to contact some SS, it can (re)use this ticket to get additional tickets from TGS, for SS, without resorting to using the shared secret. These tickets can be used to prove authentication to SS.

The phases are detailed below.

User Client-based Logon

1. A user enters a username and password on the client machine. The client performs a one-way function (hash usually) on the entered password, and this becomes the secret key of the client/user.

Client Authentication

The client sends a clear text message of the user ID to the AS requesting services on behalf of the user.

The AS checks to see if the client is in its database. If it is, the AS sends back the following two messages to the client:

Message A: Client/TGS Session Key encrypted using the secret key of the client/user.

Message B: Ticket-Granting Ticket (which includes the client ID, client network address, ticket validity period, and the client/TGS session key) encrypted using the secret key of the TGS.

Once the client receives messages A and B, it decrypts message A to obtain the Client/TGS Session Key. This session key is used for further communications with the TGS

Client Service Authorization

When requesting services, the client sends the following two messages to the TGS:

Message C: Composed of the TGT from message B and the ID of the requested service.

Message D: Authenticator encrypted using the Client/TGS Session Key.

Upon receiving messages C and D, the TGS retrieves message B out of message C. It decrypts message B using the TGS secret key. This gives it the "client/TGS session key". Using this key, the TGS decrypts message D (Authenticator) and sends the following two messages to the client:

Message E: Client-to-server ticket (which includes the client ID, client network address, validity period and Client/Server Session Key) encrypted using the service's secret key.

Message F: Client/server session key encrypted with the Client/TGS Session Key.

Client Service Request

Upon receiving messages E and F from TGS, the client has enough information to authenticate itself to the SS. The client connects to the SS and sends the following two messages:

Message E from the previous step (the client-to-server ticket, encrypted using service's secret key).

Message G: a new Authenticator, which includes the client ID, timestamp and is encrypted using client/server session key.

The SS decrypts the ticket using its own secret key to retrieve the Client/Server Session Key. Using the sessions key, SS decrypts the Authenticator and sends the following message to the client to confirm its true identity and willingness to serve the client:

Message H: the timestamp found in client's Authenticator plus 1, encrypted using the Client/Server Session Key.

The client decrypts the confirmation using the Client/Server Session Key and checks whether the timestamp is correctly updated.

Task 2

Trusted Computer System Evaluation Criteria (TCSEC)

Introduction:

Trusted Computer System Evaluation Criteria (TCSEC) is a United States Government Department of Defense (DoD) standard that sets basic requirements for assessing the effectiveness of computer security controls built into a computer system. The TCSEC was used to evaluate, classify and select computer systems being considered for the processing, storage and retrieval of sensitive or classified information.

Policy

The security policy must be explicit, well-defined and enforced by the computer system. There are two basic security policies:

Mandatory Security Policy - Enforces access control rules based directly on an individual's clearance, authorization for the information and the confidentiality level of the information being sought. Other indirect factors are physical and environmental. This policy must also accurately reflect the laws, general policies and other relevant guidance from which the rules are derived.

Discretionary Security Policy - Enforces a consistent set of rules for controlling and limiting access based on identified individuals who have been determined to have a need-to-know for the information.

Divisions and classes

The TCSEC defines four divisions: D, C, B and A where division A has the highest security. Each division represents a significant difference in the trust an individual or organization can place on the evaluated system. Additionally divisions C, B and A are broken into a series of hierarchical subdivisions called classes: C1, C2, B1, B2, B3 and A1.

Each division and class expands or modifies as indicated the requirements of the immediately prior division or class.

D - Minimal protection

Reserved for those systems that have been evaluated but that fail to meet the requirements for a higher division

C - Discretionary protection

C1 - Discretionary Security Protection

C2 - Controlled Access Protection

B - Mandatory protection

B1 - Labeled Security Protection

B2 - Structured Protection

B3 - Security Domains

A - Verified protection

A1 - Verified Design

Beyond A1

System Architecture demonstrates that the requirements of self-protection and completeness for reference monitors have been implemented in the Trusted Computing Base (TCB).

Security Testing automatically generates test-case from the formal top-level specification or formal lower-level specifications.

Formal Specification and Verification is where the TCB is verified down to the source code level, using formal verification methods where feasible.

Trusted Design Environment is where the TCB is designed in a trusted facility with only trusted (cleared) personnel.

b) Trusted Network Interpretation (TNI)

Key Feature

Red books also called Trusted Network Interpretation (TNI), addresses security evaluation topics for networks and network components.

The Red Book does not supply specific details about how to implement security mechanisms; instead, it provides a framework for securing different types of networks

It rates the confidentiality of data and operations that happen within a network and the network components and products.

Security Items addresses in the Red Books (TNI)

Communication integrity

Authentication Protects against masquerading and playback attacks. Mechanisms include digital signatures, encryption, timestamp, and passwords.

Message integrity protects the protocol header, routing information, and packet payload from being modified. Mechanisms include message authentication and encryption.

Non-repudiation ensures that a sender cannot deny sending a message. Mechanisms include encryption, digital signatures, and notarization.

Denial-of-service prevention

Continuity of operations Ensures that the network is available even if attacked. Mechanisms include fault tolerant and redundant systems and the capability to reconfigure network parameters in case of an emergency.

Network management Monitors network performance and identifies attacks and failures. Mechanisms include components that enable network administrators to monitor and restrict resource access.

Compromise protection

Data confidentiality Protects data from being accessed in an unauthorized method during transmission. Mechanisms include access controls, encryption, and physical protection of cables.

Traffic flow confidentiality ensures that unauthorized entities are not aware of routing information or frequency of communication via traffic analysis. Mechanisms include padding messages, sending noise, or sending false messages.

c) Information Technology Security Evaluation Criteria (ITSEC)

Introduction:

ITSEC was developed by the EU to address all the security evaluation issues.ITSEC provides following security issue.

Confidentiality - prevention of the unauthorized disclosure of information;

Integrity - prevention of the unauthorized modification of information;

Availability - prevention of the unauthorized withholding of information or resources.

The Criteria

Security policy- The policy must be explicit and well defined and enforced by the mechanisms within the system.

Identification- Individual subjects must be uniquely identified.

Labels Access- Control labels must be associated properly with objects.

Documentation- Documentation must be provided, including test, design, and specification documents, user guides, and manuals.

Accountability- Audit data must be captured and protected to enforce accountability.

Life cycle assurance- Software, hardware, and firmware must be able to be tested individually to ensure that each enforces the security policy in an effective manner throughout their lifetimes.

Continuous protection- The security mechanisms and the system as a whole must perform predictably and acceptably in different situations continuously.

The Assurance Levels

Division D: Minimal Protection- It is reserved for systems that have been evaluated but fail to meet the criteria and requirements of the higher divisions.

Division C: Discretionary Protection- the C rating category has two individual assurance ratings within it.

C1: Discretionary Security Protection

C2: Controlled Access Protection

Division B: Mandatory Protection- Mandatory access control is enforced by the use of security labels. The architecture is based on the Bell-LaPadula security model, and evidence of reference monitor enforcement must be available

B1: Labeled Security

B2: Structured Protection

B3: Security Domains

Division A: Verified Protection- Formal methods are used to ensure that all subjects and objects are controlled with the necessary discretionary and mandatory access controls. The design, development, implementation, and documentation are looked at in a formal and detailed way

A1: Verified Design

Formal techniques are used to prove the equivalence between the TCB specifications and the security policy model.

More stringent change configuration is put in place with the development of an A1 system, and the overall design can be verified

The type of environment that would require A1 systems is the most secure of secured environments. This type of environment deals with top-secret information and cannot adequately trust anyone using the systems without strict authentication, restrictions, and auditing.

d) Common Criteria

Introduction:

Common Criteria is a framework in which computer system users can specify their security functional and assurance requirements, vendors can then implement and/or make claims about the security attributes of their products, and testing laboratories can evaluate the products to determine if they actually meet the claims.

Key concepts

Common Criteria evaluations are performed on computer security products and systems. The evaluation serves to validate claims made about the target. To be of practical use, the evaluation must verify the target's security features. This is done through the following:

Protection Profile (PP) - a document, typically created by a user or user community, which identifies security requirements for a class of security devices (for example, smart cards used to provide digital signatures, or network firewalls) relevant to that user for a particular purpose. Product vendors can choose to implement products that comply with one or more PPs, and have their products evaluated against those PPs. In such a case, a PP may serve as a template for the product's ST, or the authors of the ST will at least ensure that all requirements in relevant PPs also appear in the target's ST document. Customers looking for particular types of products can focus on those certified against the PP that meets their requirements.

Security Target (ST) - the document that identifies the security properties of the target of evaluation. It may refer to one or more PPs. The TOE is evaluated against the SFRs (see below) established in its ST, no more and no less. This allows vendors to tailor the evaluation to accurately match the intended capabilities of their product. This means that a network firewall does not have to meet the same functional requirements as a database management system, and that different firewalls may in fact be evaluated against completely different lists of requirements. The ST is usually published so that potential customers may determine the specific security features that have been certified by the evaluation.

Security Functional Requirements (SFRs) - specify individual security functions which may be provided by a product. The Common Criteria presents a standard catalogue of such functions. For example, an SFR may state how a user acting a particular role might be authenticated. The list of SFRs can vary from one evaluation to the next, even if two targets are the same type of product. Although Common Criteria does not prescribe any SFRs to be included in an ST, it identifies dependencies where the correct operation of one function (such as the ability to limit access according to roles) is dependent on another (such as the ability to identify individual roles).

The evaluation process also tries to establish the level of confidence that may be placed in the product's security features through quality assurance processes:

Security Assurance Requirements (SARs) - descriptions of the measures taken during development and evaluation of the product to assure compliance with the claimed security functionality. For example, an evaluation may require that all source code is kept in a change management system, or that full functional testing is performed. The Common Criteria provides a catalogue of these, and the requirements may vary from one evaluation to the next. The requirements for particular targets or types of products are documented in the ST and PP, respectively.

Evaluation Assurance Level (EAL) - The numerical rating describing the depth and rigor of an evaluation. Each EAL corresponds to a package of security assurance requirements (SARs, see above) which covers the complete development of a product, with a given level of strictness. Common Criteria lists seven levels, with EAL 1 being the most basic (and therefore cheapest to implement and evaluate) and EAL 7 being the most stringent (and most expensive). Normally, an ST or PP author will not select assurance requirements individually but choose one of these packages, possibly 'augmenting' requirements in a few areas with requirements from a higher level. Higher EALs do not necessarily imply "better security", they only mean that the claimed security assurance of the TOE has been more extensively validated.

Where thorough testing is performed and the system design is verified.

EAL 1 Functionally tested

EAL 2 Structurally tested

EAL 3 Methodically tested and checked

EAL 4 Methodically designed, tested, and reviewed

EAL 5 Semi-formally designed and tested

EAL 6 Semi-formally verified design and tested

EAL 7 Formally verified design and tested

Certification and Accreditation

Certification

Certification is the comprehensive technical evaluation of the security components and their compliance for the purpose of accreditation.

A certification process may use safeguard evaluation, risk analysis, verification, testing, and auditing techniques to assess the appropriateness of a specific system.

The goal of a certification process is to ensure that a system, product, or network is right for the customer's purposes.

Accreditation

Accreditation is the formal acceptance of the adequacy of a system's overall security and functionality by management.

Certification is a technical review that assesses the security mechanisms and evaluates their effectiveness. Accreditation is management's official acceptance of the information in the certification process findings.

e) What type of products is evaluated using a security evaluation criterion?

Introduction:

All network devices should follow a standard security criterion. Such as router, switch, server firewall etc. Here is the some standard for router, switch are given bellow

Router and switch should maintain the following security standard. It's divided into two parts.

Baseline:

No local user accounts are configured on the router. Routers must use RADIUS for all user authentications.

The enable password on the router must be kept in a secure encrypted form. The router must have the enable password set to the current production router password from the router support organization.

Disallow the following:

IP directed broadcasts

TCP small services

UDP small services

All wed services running on router

Switch interfaces set with "dynamic" negotiation

Use SNMPv3 and MD5 hashing.

All router updates shall be done using secure routing updates.

Access control lists are to added and modified as business need arise.

Perimeter:

1. Disallow the followings:

Incoming packets at the router sourced with invalid addresses, such as RFC1918 address.

Block IP packets that have the same source and destination

Outgoing packets at the router sourced with valid addresses, such as RFC 1918 addresses

All source routing

CDP on internet connected interfaces

IP directed broadcast

Implement black hole routing, or null routing

Disable network auto loading via TFTP

Writing Services

Essay Writing
Service

Find out how the very best essay writing service can help you accomplish more and achieve higher marks today.

Assignment Writing Service

From complicated assignments to tricky tasks, our experts can tackle virtually any question thrown at them.

Dissertation Writing Service

A dissertation (also known as a thesis or research project) is probably the most important piece of work for any student! From full dissertations to individual chapters, we’re on hand to support you.

Coursework Writing Service

Our expert qualified writers can help you get your coursework right first time, every time.

Dissertation Proposal Service

The first step to completing a dissertation is to create a proposal that talks about what you wish to do. Our experts can design suitable methodologies - perfect to help you get started with a dissertation.

Report Writing
Service

Reports for any audience. Perfectly structured, professionally written, and tailored to suit your exact requirements.

Essay Skeleton Answer Service

If you’re just looking for some help to get started on an essay, our outline service provides you with a perfect essay plan.

Marking & Proofreading Service

Not sure if your work is hitting the mark? Struggling to get feedback from your lecturer? Our premium marking service was created just for you - get the feedback you deserve now.

Exam Revision
Service

Exams can be one of the most stressful experiences you’ll ever have! Revision is key, and we’re here to help. With custom created revision notes and exam answers, you’ll never feel underprepared again.