Host Based Role Based Network Security Model Hassan Ahmed, Ladislav Hudec Department of Computer Science and Engineering, Faculty of Electrical Engineering and Information Technology, Slovak University of Technology, Ilkovicova 3, 812 19, Bratislava.
[email protected],
[email protected] Abstract Security in computer networks is a very complex task ranges from the level of separation of corporate network from public internet to the level of dividing a company's intranets into multiple zones. The network security policy that describes this task in a high-level form is implemented mainly using firewall technology. One of the main difficulties facing the network administrator is how to translate the high-level policy description to lowlevel rule-base of the firewall. In this paper we presented a Role Based Network Security (RBNS) model that we can use as an intermediary level between High-level policy form and low-level firewall rule-base. Our model uses the Role Based Access Control (RBAC) model as a framework. Also, our model is based on the host network security model that captures the topology-dependent part of the security policy. The main concept of our model is that network services are assigned to roles, and hosts, that are defined via their IP addresses, are made members of appropriate roles thereby acquiring the roles' network services. Using this model, we can separate the security policy from the underlying enforcement mechanism, firewall technology, offering easier management and debugging of low level firewall rule-base.
1. Introduction Security of networks has become one of the primary concerns when it is required to connect a private network to the Internet or, even to isolate a particular subnet from the overall corporate network. To provide the required level of protection, an organization needs a security policy to prevent unauthorized users from accessing resources on the private network and to protect against the unauthorized export of private information. Even if an organization is not connected to the Internet, it may still want to establish an internal security policy to manage user access to portions of the network and protect sensitive or secret information [1][2].
This security policy is primarily presented in a high level form. An example of high-level service specific policy is described in [3]. In a host based network security policy, the security policy concentrates on controlling network access to hosts and services. In this case, firewall technology is the main security mechanism that can be used to enforce the security policy [4][5][6]. The single most important factor of firewall's security is how we configure it [7]. However, while firewalls themselves have been some impressive technological advances, firewall configuration and management seem to be lagging behind [7]. It is useful to examine briefly what makes firewall management a difficult task [7]. A firewall is typically placed on a gateway, separating the corporate Intranet from the public Internet. Most of today's firewalls are configured via a rule-base. This rule-base instructs the firewall, which inbound packets to let pass and which to block. Similarly, the rule-base specifies what outbound packets are allowed. The administrator needs to implement the high-level corporate security policy using this low-level rule-base. The configuration interface typically allows the security administrator to define various host-groups and service-groups. A single rule typically includes a source, a destination, a service-group, and an appropriate action [6]. The source and destination are host-groups, and the action is either "pass" or "drop". The most important point we want to conclude from this examination is that the security of whole Intranet depends on the exact content of the rule-base, with no higher level of abstraction available. This problem become worse for a medium- or largesized company which uses more than a single firewall. These firewalls divide the company's departments into multiple zones. In this case the security policy is typically realized by multiple rule-bases, located on multiple gateways that connect the different zones to each other. Thus the interplay between theses bases must be carefully examined so as not to introduce security holes.
To solve these problems, we presented a network security model, which acts as an intermediary level between high-level security policy and low-level firewall rule-base configuration file, figure 1.
example to illustrate the using of our model. Finally, in section 4 we concluded and mentioned possible extension of our work.
2. RBNS model 1.1. Big picture of the problem When we examined the problem we found that it has a similar flavour to access control problem in the sense that we want to assign some services (corresponding to permissions in access control problem) to IP addresses (corresponding to users in access control problem). This led us to chose RBAC model, a generalized approach to access control, as a framework to our model [8][9][10][11]. However, we added some foundational work in the RBAC model to extend it to make it possible to be used as a network security model. High level security Policy
RBNS Model
Low Level Firewall Rule-Base
Figure 1. RBNS model as intermediary level.
In this section we presented our model in some details. We started with brief definition of the terminology we use. Then in section 2.2 we introduced the concept and details of our RBNS model. In section 2.3 we described an extension for our basic model; the constrained RBNS model.
2.1. Terminology Before we discuss our model we need to define precisely the following terms, [5]: Gateways: These are the packets filtering machines, which can be either firewalls or routers. Interfaces: By definition a gateway is multi-homed host, since it has at least two Internet connections. Each connection goes through an interface, which has its own unique IP address. We assume that each interface has a packet filtering rule-base associated with it. (This is more general than assuming only a single rule-base per gateway). Zones: The gateways partition the IP address space into disjoint zones. Most zones correspond to a corporation’s subnet(s), usually with one big “Internet” zone corresponding to the portion of the IP address space that is not used by the corporation.
1.2. Advantages of the model
2.2. RBNS model description
The main advantages of using this model are: 1- Separation of the security policy design from the firewall/router vendor specifics. This allows a security administrator to focus on designing an appropriate policy without worrying about firewall rule complexity, rule ordering, and other low-level configuration issues. It also enables a unified management of network components from different vendors and a much easier transition when a company switches vendors. 2- Separation the security policy design from the actual network topology. This enables the administrator to maintain a consistent policy in the face of Intranet topology changes. Furthermore, this modularization also allows the administrator reuse the same policy at multiple corporate sites with different network details, or to allow smaller companies to use default/ exemplary policies designed by experts. In section 2 we introduced in details our role-based network security model. Then, in section 3 we used an
The main concept of RBNS model is that services are associated with roles, and host are assigned to appropriate roles. Our model has two levels; the base RBNS level and the constrained RBNS level. The first level can be used if the security policy assumes that all hosts in various subnets of the network are trusted. If this assumption is not satisfied the second level must be used to decrease the possibility of spoofing attacks. As we see in figure 2, Base RBNS level, there are three sets of entities called hosts (H), roles (R), and services (S). A host entity models a machine on the network with its IP address. The host entity represents the topologyrelated part on our model. The host entity plays double parts in our model. The host may appear as a source IP requesting a service (client-host) or appear as a destination IP announcing which services can be supplied by it (server-host).
A service entity is the combination of a protocol-base (e.g., TCP, UDP, etc.) and the port numbers on both the source and destination sides. For instance, the service telnet is defined as TCP with destination port 23 and any source port. These services are always positive and confer the ability to the holder of the services to perform some actions on the network. In our framework the services are modelled in two ways: in the first way the "default = discard" firewall policy is considered. It means, if there is no match to any rule in the rule-base of the firewall, the packet is discarded. In the second way, the “default = forward" firewall policy is considered. However, the denial of services is modelled as constraints. A role is properly viewed as a semantic construct around which network security policy is formulated. We have two types of roles; client-role and server-role. Client-role intermediates a client-host to the network services permitted to that host. Server-role intermediates a server-host to the network services supplied by that host Figure 2 shows client-hosts assignment (CHA), serverhosts assignment (SHA), client-services assignment (CSA), and server-services assignment (SSA) relations. All are many-to-many relations. A host can be a member of many roles, and a role can have many hosts. Similarly, a role can have many services, and the same service can be assigned to many roles. The key to our model lies in these relations. The placement of a role as an intermediary to enable a host to exercise a service provides much greater control over services assignment management than that does direct relating hosts to services like host based model. CHA
CSA
Client Hosts Assignment H Hosts
SSA ⊆ S × RS, a many-to-many service to server role assignment relation, CHA ⊆ H × RC, a many-to-many host to client role assignment relation. SHA ⊆ H × RS, a many-to-many host to server role assignment relation.
2.3. Constrained RBNS model The previous level of our model generates firewall configuration rules that have no protection against spoofing attacks. Any packet comes on an interface of the gateway claiming that it comes from another host will take all the services associated to the roles in which this claimed IP is a member. To reduce the possibility of spoofing attacks we added some constraints to our model. These constraints, defined in the table 1, define the direction of the packet. Table 1. Model constraints Interface Internal Internal External External
Server Hosts Assignment SHA
CHA
SSA
Figure 2. The RBNS model
CSA
Client Hosts Assignment
S Services Server Services Assignment
Action Pass Drop Drop Pass
As it is clear from the table, The packet passes only if the packet source IP field is in the same zone of the inbound interface. These constraints can be translated in the firewall configuration rule list by a direction field. As we see in figure 3, the only difference between this level and the basic level is the constraints entity that is completely defined in table1.
Client Services Assignment RC&RS Roles
Source IP Internal External Internal External
H Hosts
Client Services Assignment RC&RS Roles
Server Hosts Assignment SHA
S Services Server Services Assignment SSA
The RBNS model is mathematically described as: H, RC, RS, and S (hosts, client roles, server roles, and services respectively), CSA ⊆ S × RC, a many-to-many service to client role assignment relation,
Constraints
Figure 3. Constrained RBNS model
Firewall administration zone 172.20.2.*
fw_admin
Screening router Internet 172.20.100.1
muli_serve 172.20.1.254 r dns_server 172.20.1.1
172.20.2.1 Screening router 172.20.3.1
Server zone 172.20.1.* Corporate network 172.20.3.*
control
Figure 4. The network topology of the example
3. Illustrative example In this section we illustrate using an example how we can use our model to translate high-level security policy into intermediate-level that can be compiled easily to generate low-level firewall configuration file. Consider a corporation with a two-firewall network configuration. We list the corporation IP addresses as 172.20.*.* subnet, as shown in Figure 4. The external firewall guards the corporation’s Internet connection. Behind it is the DMZ (demilitarized zone), which contains the corporation’s externally visible servers. In our case these servers provide web, ftp, smtp, and dns services. The corporation actually only uses two hosts to provide these services, one for dns and the other (called multi server) for all the other services. Behind the DMZ is the internal firewall, which guards the corporation’s Intranet. This firewall actually has three interfaces: one for the DMZ, one for the corporate network zone, and a separate interface connecting to the firewall administration host. Securing the firewall administration host is critical to the network’s integrity, so it is more appropriate to separate it from the other corporate hosts. Within the corporate network zone, there is one distinguished host, control, which provides the administration for the servers in the DMZ.
3.1. Policy goals The policy we consider is a rather simple one, which has the following goals:
1. Internal corporate hosts can access all the resources on the Internet. 2. The DMZ servers can be updated only by the web administrator host control. Other corporate hosts have the same privileges as Internet hosts with respect to the DMZ servers. 3. The firewall gateway interfaces are only accessible from the fw-admin host and are otherwise inaccessible to any host (this practice is usually called “stealing” the gateway).
3.2. Applying of the model We can obtain the intermediate level by defining precisely all the entities of the model as described in the following steps: 1- Services entity definition: The first step is to define the various services that we deal with according to the following syntax [7]: ‘=’ ‘[’ ‘,’ ‘]’ The following examples define some widely used services: smtp = TCP [25] ssh = TCP [22] ping = ICMP [8,0] all-tcp= TCP [*] 2- Roles entity definition: The second step is to define the various roles according the following syntax. ‘[’‘,’‘]’‘:’‘[’ ‘,’‘]’
As some examples of required roles: R-admin: firewall administration role (client role) R-corporate: any host on the corporate network role (client role) R-mail-server: the mail server role (server role) R-interface: the gateway interface role (server role) 3- Hosts entity definition: The third step is topology-specific. It involves defining all IPs of the network as declared in Figure 4. 4- Services-roles assignment: The fourth step is to assign the appropriate services to each role. 5- Hosts-roles assignment: The last step is to make hosts members in the appropriate roles. For example, to satisfy goal 1, • Assign the service “all-tcp” to “R-corporate” role • Make all corporate users’ IPs members in “R corporate”. All these steps define precisely the various entities of the model. We can say that this definition represents an intermediate description of the security policy. Then, this definition can be compiled easily to low-level firewall configuration file.
4. Conclusion We have presented a host-based role-based network security model. We discussed in details the various components of the model. Also, we have described briefly through an illustrative example how this model can be used as an intermediary-level between high-level policy description and low-level firewall configuration rule list. A more substantial extension to our work is to implement a complete firewall management kit that includes a graphical user interface (GUI) for the definition of the model entities. Also, this kit may include a compiler to translate the model definition to the low-level firewall rule-base configuration file.
5. References [1] C.P. Pfleeger, Security in Computing, Prentice-Hall Inc., Second Edition, 1997. [2] D. Golmann, Computer Security, John Wiely and Sons, 1999. [3] B. Guttman, and R. Bagwill, "Implementing Internet Firewall Security Policy", NIST Special Publication, 800XX, 1998. [4] W. Stallings, Cryptography and Network Security: Principles and Practice, Prentice-Hall Inc., second edition, 1999.
[5] C.L. Schuba, "On the Modeling, Design, and Implementation of Firewall Technology", Ph.D. Thesis, Purdue University, Dec. 97. [6] M. Strebe, and C. Perkins, Firewalls 24seven, Sybex Inc., 1999. [7] Y. Bartal, A. Mayer, K. Nissim, and A. Wool "Firmato: A Novel Firewall Management Toolkit", IEEE Symposium on Security and Privacy, May 9-12, 1999. [8] R.S. Sandhu, "Role-based access contr ol", In Zelkowitz editor, Advances in Computers, Volume 46, Academic Press,1998 [9] D.F. Ferraiolo, R. Sandhu & S. Gavrila. ACM Transactions on Information and Systems Security, Volume 4, Number 3 / August 2001 [10] R.S. Sandhu, D.F. Ferraiolo, and R. Kuhn, "The NIST Model for Role-Based Access Control: Towards A Unified Standard", ACM, In proceedings of 5th ACM Workshop on Role-Based Access Control, Berlin, Germany, July 2000. [11] R.S. Sandhu, E.J. Coyne, H.L. Feinstein, and C.E. Youman, "Role-based access control models" IEEE Computer, Volume 29, Number 2, pp. 38-47, Feb. 1996.
