NATIONAL

UNIVERSITY OF
TECHNOLOGY
(Department of Computer Science)

Course Title : Information Security Course code : CS4017

FM Name : Dr. Muhammad Iqbal Submitted by :

Question No.1
Answer
Honeypot deployment

1. Tracks attempts to connect to an unused IP address; can't help with inside attackers
2. In DMZ; must make sure the other systems in the DMZ are secure; firewalls may
block traffic to the honeypot
3. Full internal honeypot; can detect internal attacks

Question No.2
Answer

1. Monitor attacks from outside

(See attacks to servers)
Within a single site, a key decision for the security administrator is the placement of
the sensors. Figure illustrates a number of possibilities. In general terms, this
configuration is typical of larger organizations. All Internet traffic passes through an
external firewall that protects the entire facility. Internal firewalls may also be used
to provide more specific protection to certain parts of the network.
A common location for a NIDS sensor is just inside the external firewall (location 1 in
the figure), where it can attacks, originating from the outside world. Instead of
placing a NIDS sensor inside the external firewall, the security administrator may
choose to place a NIDS sensor between the external firewall and the Internet or
WAN (location 2). In this position, the sensor can monitor all network traffic,
unfiltered. A sensor at location 2 has a higher processing burden than any sensor
located elsewhere on the site network. In addition to a sensor at the boundary of the
network, on either side of the external firewall, the administrator may configure a
firewall and one or more sensors to protect major backbone networks, such as those
that support internal servers and database resources (location 3). Thus, a sensor at
location 3 is able to monitor for both internal and external attacks. Because the
sensor monitors traffic to only a subset of devices at the site, it can be tuned to

1|Page
 specific protocols and attack types, reducing the processing burden. Finally, the
network facilities at a site may include separate LANs that support user workstations
and servers specific to a single department. The administrator could configure a
firewall and NIDS sensor to provide additional protection for all of these networks or
target the protection to critical subsystems, such as personnel and financial networks
(location 4). As with a sensor at location 3, a sensor at location 4 can be tuned to
specific protocols and attack types, reducing the processing burden.

2. Monitor and documents unfiltered packets; more work to do

3. Protect major backbones; monitor internal/external attacks

4. Special IDS to provide additional protection for critical systems (e.g., bank accounts)

Question No.3
Answer

User A owns files 1 and 3 and has read and write access rights to those files. User B has
read access rights to file 1, and so on.
In practice, an access matrix is usually sparse and is implemented by decomposition in
one of two ways. The matrix may be decomposed by columns, yielding access control
lists (ACLs), entry. This allows users that are not explicitly listed as having special rights
to have a default set of rights. The default set of rights should always follow the rule of
least privilege or read-only access, whichever is applicable. Elements of the list may
include individual users as well as groups of users. When it is desired to determine
which subjects have which access rights to a particular resource, ACLs are convenient,
because each ACL provides the information for a given resource. However, this data
structure is not convenient for determining the access rights available to a specific user.
Decomposition by rows yields capability tickets. A capability ticket specifies authorized
objects and operations for a particular user. Each user has a number of tickets and may
be authorized to loan or give them to others. Because tickets may be dispersed around
the system, they present a greater security problem than access control lists. The
integrity of the ticket must be protected, and guaranteed (usually by the operating
system). In particular, the ticket must be unforgettable. One way to accomplish this is to
have the operating system hold all tickets on behalf of users. These tickets would have
to be held in a region of memory inaccessible to users. Another alternative is to include
an unforgeable token in the capability. This could be a large random password, or a
cryptographic message authentication code. This value is verified by the relevant
resource whenever access is requested. This form of capability ticket is appropriate for
use in distributed environment, when the security of its contents cannot be guaranteed.

2|Page
 The convenient and inconvenient aspects of capability tickets are the opposite of those
for ACLs. It is easy to determine the set of access rights that a given user has, but more
difficult to determine the list of users with specific access rights for specific resource.
It proposes a data structure that is not sparse, like the access matrix, but is more
convenient than either ACLs or capability lists in Table. An authorization table contains
one row for one access right of one subject to one resource. Sorting or accessing the
table by subject is equivalent to a capability list. Sorting or accessing the table by object
is equivalent to an ACL. A relational database can easily implement an authorization
table of this type. This section introduces a general model for DAC developed by
Lampson, Graham, and Denning [LAMP71, GRAH72, DENN71]. The model assumes a set
of subjects, a set of objects, and a set of rules that govern the access of subjects to
objects. Let us define the protection state of a system to be the set of information, at a
given point in time that specifies the access rights for each subject with respect to each
object. We can identify three requirements: representing the protection state, enforcing
access rights, and allowing subjects to alter the protection state in certain ways. The
model addresses all three requirements, giving a general, logical description of a DAC
system.

Objects
File 1 File 2 File 3 File 4

Own Own
Read Read
User A
Write Write
Own
Read Read Write Read
Subjects User B Write
Own
Read Read Read
User C Write Write

Question No.4
Answer

a) Allow all internal hosts to connect to all web servers.

Interface SrcIP SrcPort DestIP DestPort Protocol Action

1 * * * 80 TCP Allow

3|Page
 b) Allow all hosts on network F to connect to the secure shell (SSH) server on C.7.

Interface SrcIP SrcPort DestIP DestPort Protocol Action

2 F.* * C.7 22 TCP Allow

c) Allow all hosts on network C, except the two servers (C.3 and C.7), to connect
to all email servers.

Interface SrcIP SrcPort DestIP DestPort Protocol Action

1 C.3 * * 25 TCP Drop
1 C.7 * * 25 TCP Drop
1 C.* * * 25 TCP Allow

Question No.5
Answer

a) Computationally hard to compute the inverse of a hash function, i.e. to determine the
original message, given only the hash value. If H(X) = A, then hard to compute H-1(A)
to obtain X.
b) Given a message X and its hash value A (H(X) = A), computationally hard to find
another message Y such that H(X) = H(Y) = A.
c) Computationally hard to find two messages, X and Y, such that their hash values are the
same,
i.e. H(X) = H(Y).
d) An attacker could intercept the message and signature, find another message Y and
forward the modified message Y with the original signature (unmodified bits). The
receiver would compare the H(Y) and the received H (M), find they are the same and not
detect the modification.

4|Page