Management of Exceptions in Access Control Policies
- J. G. Alfaro, F. Cuppens, N. Cuppens
Management of Exceptions in Access Control Policies J. G. Alfaro, - - PowerPoint PPT Presentation
Management of Exceptions in Access Control Policies J. G. Alfaro, F. Cuppens, N. Cuppens ENST Bretagne, Rennes RSM/SERES Outline - 2 - Problem domain Main strategies Use of full expressiveness Conclusions and Perspectives
All physicians are allowed to consult patient’s medical records
Physicians on strike can’t access medical records
For emergency purposes, even physicians going on strike can access patient’s medical records
Internet Firewall Private
Example:
Zone Private can access web resources of zone Internet
Condition → accept
Condition → deny
Where condition is a conjunctive set of attributes in the form:
(s)ource ∧ (d)estination ∧ source-port(sport) ∧ destination-port (dport) ∧ (p)rotocole
R: s ∈ ∈ ∈ ∈ 111.222.1.0/24 ∧ ∧ ∧ ∧ d ∈ ∈ ∈ ∈ any ∧ ∧ ∧ ∧ p = tcp ∧ ∧ ∧ ∧ dport = 80 →
→ → → accept
Example (continuation):
web resources on the zone Internet
Exclusion of address 111.222.1.1 from zone Private
Exclusion of zone Admin from zone Private
Exclusion of zone Corporate from zone Internet
Firewall
Private Admin
Firewall
Private Admin
Zone (Private — Admin — Interf-fw) has the permission of accessing web resources in zone (Internet — Corporate)?
1. First/Last Matching Algorithms
2. Segmentation of Rules
3. Partial Ordering of Rules
If the rule is a permission, traffic is accepted Otherwise, traffic is refused
policy:
In the case of an open policy, traffic is accepted If the policy is closed, traffic is refused
R: s ∈ ∈ ∈ ∈ (A ∧ ∧ ∧ ∧ ¬ ¬ ¬ ¬B) → → → → accept
R1: (s ∈ B) → deny R2: (s ∈ A) → accept
Firewall
Private Admin
web resources from zone (Internet — Corporate)”
R1: s ∈ 111.222.1.1 ∧ ∧ ∧ ∧ d ∈ ∈ ∈ ∈ any ∧ ∧ ∧ ∧ p = tcp ∧ ∧ ∧ ∧ dport = 80 → deny R2: s ∈ [111.222.1.13, 111.222.1.25] ∧ ∧ ∧ ∧ d ∈ ∈ ∈ ∈ any ∧ ∧ ∧ ∧ p = tcp ∧ ∧ ∧ ∧ dport = 80 → deny R3: s ∈ 111.222.1.0/24 ∧ ∧ ∧ ∧ d ∈ ∈ ∈ ∈ 111.222.0.0/16 ∧ ∧ ∧ ∧ p = tcp ∧ ∧ ∧ ∧ dport = 80 → deny R4: s ∈ 111.222.1.0/24 ∧ ∧ ∧ ∧ d ∈ ∈ ∈ ∈ any ∧ ∧ ∧ ∧ p = tcp ∧ ∧ ∧ ∧ dport = 80 → accept
Solution implemented in most existing firewalls
Necessity of defining a total order between rules Transformation of local rule’s exceptions into global exceptions
Risk of interference between rules Administration of setups becomes error prone
Combinations of rules not always possible to implement by simple
R1,1: (s ∈ B) → deny R1,2: (s ∈ A) → accept R2,1: (s ∈ A) → deny R2,2: (s ∈ B) → accept
∩ ∩ ∩ B and the following transformations:
R1,1: (s ∈ (A∩B)) → deny R1,2: (s ∈ A) → accept R2,1: (s ∈ (A∩B)) → deny R2,2: (s ∈ B) → accept
R1: (s ∈ (A∩B)) → deny R2: (s ∈ A) → accept R3: (s ∈ B) → accept
The hosts of Private can access to web resources in DMZ
Firewall
Private Admin
∈ ∈ ∈ ∧ ∧ ∧ ∧ d ∈ ∈ ∈ ∈ ∧ ∧ ∧ ∧ ∧ ∧ ∧ ∧ → → → →
R1: s ∈ ∈ ∈ ∈ 111.222.1.0/24 ∧ ∧ ∧ ∧ d ∈ ∈ ∈ ∈ 111.222.2.0/24 ∧ ∧ ∧ ∧ p = tcp ∧ ∧ ∧ ∧ dport = 80 → → → → accept R2: s ∈ ∈ ∈ ∈ 111.222.1.1 ∧ ∧ ∧ ∧ d ∈ ∈ ∈ ∈ any ∧ ∧ ∧ ∧ p = tcp ∧ ∧ ∧ ∧ dport = 80 → → → → deny R3: s ∈ ∈ ∈ ∈ [111.222.1.13, 111.222.1.25] ∧ ∧ ∧ ∧ d ∈ ∈ ∈ ∈ any ∧ ∧ ∧ ∧ p = tcp ∧ ∧ ∧ ∧ dport = 80 → → → → deny R4: s ∈ ∈ ∈ ∈ 111.222.1.0/24 ∧ ∧ ∧ ∧ d ∈ ∈ ∈ ∈ 111.222.0.0/16 ∧ ∧ ∧ ∧ p = tcp ∧ ∧ ∧ ∧ dport = 80 → → → → deny R5: s ∈ ∈ ∈ ∈ 111.222.1.0/24 ∧ ∧ ∧ ∧ d ∈ ∈ ∈ ∈ any ∧ ∧ ∧ ∧ p = tcp ∧ ∧ ∧ ∧ dport = 80 → → → → accept
Only possibility!
– In case of an open policy
– In case of a closed policy Transformation of general rules taking into account the set of exceptions
Example: R: s ∈ ∈ ∈ ∈ (A ∧ ∧ ∧ ∧ ¬ ¬ ¬ ¬B) → → → → accept
R: (s ∈ (A — B) → accept
Zone (Private — Admin — Interf-firewall) has the permission of accessing web resources from zone (Internet — Corporate) Private = 111.222.1.* Admin = [111.222.1.13 , 111.222.1.25] Interf-firewall = { 111.222.1.1 , 111.222.100.1 } Private – Admin – Interf-firewall: [111.222.1.2 , 111.222.1.12] ∪ [111.222.1.26 , 111.222.1.255] Internet = *.*.*.* Corporate = 111.222.*.* Internet – Corporate: [1.1.1.1 , 111.221.255.255] ∪ [111.223.1.1, 255.255.255.255]
Zone (Private — Admin — Interf-firewall) has the permission of accessing web resources from zone (Internet — Corporate)
R1: s ∈ ∈ ∈ ∈ [111.222.1.2 , 111.222.1.12] ∧ ∧ ∧ ∧ d ∈ ∈ ∈ ∈ [1.1.1.1 , 111.221.255.255] \ ∧ ∧ ∧ ∧ p = tcp ∧ ∧ ∧ ∧ dport = 80 → → → → accept R2: s ∈ ∈ ∈ ∈ [111.222.1.26 , 111.222.1.255] ∧ ∧ ∧ ∧ d ∈ ∈ ∈ ∈ [1.1.1.1 , 111.221.255.255] \ ∧ ∧ ∧ ∧ p = tcp ∧ ∧ ∧ ∧ dport = 80 → → → → accept R3: s ∈ ∈ ∈ ∈ [111.222.1.2 , 111.222.1.12] ∧ ∧ ∧ ∧ d ∈ ∈ ∈ ∈ [1.223.1.1 , 255.255.255.255] \ ∧ ∧ ∧ ∧ p = tcp ∧ ∧ ∧ ∧ dport = 80 → → → → accept R4: s ∈ ∈ ∈ ∈ [111.222.1.26 , 111.222.1.255] ∧ ∧ ∧ ∧ d ∈ ∈ ∈ ∈ [1.223.1.1 , 255.255.255.255] \ ∧ ∧ ∧ ∧ p = tcp ∧ ∧ ∧ ∧ dport = 80 → → → → accept
– Necessity of third party tools to manage intervals – The number of rules may significantly increase – Rule updates may require further segmentation processing
111.222.1.2/31 ∪ 111.222.1.4/29 ∪ 111.222.1.12/32
When a general rule applies, jump to verify its exceptions
If no exception applies, the traffic is accepted Otherwise, test of the following general rule
∈ ∈ ∈ (A ∧ ∧ ∧ ∧ ¬ ¬ ¬ ¬(B ∨ ∨ ∨ ∨ C)) → → → → accept
R1: (s ∈ A) → jump_to chainA R2: deny Rchain_A
1: (s ∈ B) → return
Rchain_A
2: (s ∈ C) → return
Rchain_A
3: accept
resources from zone (Internet — Corporate)
Rmain
1: s ∈
∈ ∈ ∈ 111.222.1.0/24 ∧ ∧ ∧ ∧ d ∈ ∈ ∈ ∈ any ∧ ∧ ∧ ∧ p = tcp ∧ ∧ ∧ ∧ dport = 80 → → → → jump priv-to-int Rmain
2: s ∈
∈ ∈ ∈ 111.222.1.0/24 ∧ ∧ ∧ ∧ d ∈ ∈ ∈ ∈ 111.222.2.0/24 ∧ ∧ ∧ ∧ p = tcp ∧ ∧ ∧ ∧ dport = 80 → → → → accept Rmain
3: deny
Rpriv-to-int
1: s ∈
∈ ∈ ∈ 111.222.1.1 → → → → return Rpriv-to-int
2: s ∈
∈ ∈ ∈ [111.222.1.13, 111.222.1.25] → → → → : return Rpriv-to-int
3: s ∈
∈ ∈ ∈ 111.222.1.0/24 d 111.222.0.0/16 → → → → return Rpriv-to-int
4: accept
iptables -N Priv_To_Internet iptables -A FORWARD -s $PRIVATE -p tcp --dport 80 -j Priv_To_Internet iptables -A FORWARD -s $PRIVATE –d $DMZ -p tcp --dport 80 -j ACCEPT iptables -A FORWARD –j DROP iptables -A Priv_To_Internet -s $ADMIN -j RETURN iptables -A Priv_To_Internet -s $FW-INT1 -j RETURN iptables -A Priv_To_Internet -d $CORPORATE -j RETURN iptables -A Priv_To_Internet -j ACCEPT
NetFilter must be patched in order to manage ranges Definition of variables such as $PRIVATE, $ADMIN, etc.
Complete separation between exceptions and general rules The ordering of general rules is no longer relevant The insertion and elimination of rules is much easier
Number of rules may increase Performance issues
Combination of both positive and negative statements (e.g., A ∧ ¬B) for a single attribute at the same time
Use of a SQL-like language may allow us to express the rule R: (s ∈ (A ∧ ¬B)) → accept in the form
select decision from firewall where (s ∈ A) ∧ (s ∉ B)
specify exceptions in the form R: (s ∈ (A ∧ ¬B)) → accept as follows:
iptables --s[+] $A --s[–] $B -j ACCEPT
(1) All hosts in (Private – Admin) are allowed to access web resources on (Internet – Corporate); (2) All the hosts in (Private – Admin) are allowed to access web resources on the zone DMZ.
iptables --s[+] $PRIV --s[–] $ADMIN --d[+] $INTERNET --d[–] $CORP -p tcp --dport 80 -j ACCEPT iptables --s[+] $PRIV --s[–] $ADMIN --d[+] $DMZ -p tcp --dport 80 -j ACCEPT iptables -j DROP
Extension of kernel’s code, by writing a new module (ipt_fex.ko) Extension of user space’s program iptables, by writing a new shared library (iptables_fex.so)
vs number of iptables rules
IPTables Performance
(netperf --m 65535; MTU: 1500)
Matching process of IPTables
(pseudocode)
protocol, source, destination, in-interface,
fragment i.e,--sport,
Overhead!!
matching process