Transcript Document

Access Control
Dr. Ron Rymon
Efi Arazi School of Computer Science
IDC, Herzliya. 2008/9
Pre-requisite: Basic Cryptography, Identity Authentication
Overview
 Access Control and Identity Management
 Public-Key Infrastructure (PKI)
 Firewalls
 Client/Server Authentication (Kerberos)
 Remote User Authentication Service
(RADIUS)
Access Control and
Identity Management
Main Sources: Kaufman et al
Access Control Model
Mandatory, Discretionary, Role-based
 Mandatory Access Control (MAC)
– Access is restricted not individually but based on a user
attribute (e.g., title, clearance, or a group he belongs to)
 Discretionary Access Control (DAC)
– Every user/admin that owns a resource can decide (at
his discretion) who may have which access
 Role-based Access Control (RBAC)
– A user is granted access to privileges according to her
role(s) in the enterprise
Access Control
 Specification and implementation of policies and rules
 Which users (and applications)
• Internal and external users, applications
 Can access which resources
• Files, databases, applications
 For what purpose
• Read/Write/Execute (access levels)
• Limits, e.g., buy up to $5000, (authority level)
 When
• Time of the day, specific sessions
 Under which conditions
• Additional authentication, supervisor or dual-approval
 Etc…
Access Control – Where
 Physical access control
– Keys, Key Rings, Master Keys are all ways to control
physical access
– Increased deployment of biometric identification for
physical access control
 Access Control Software/Hardware Mechanisms
– On routers, e.g., Cisco’s TACACS+, and network
access control servers (e.g., RADIUS)
– Systems, e.g., Unix, Windows, Mainframe (file level)
– Within Enterprise applications, databases, Web servers
Access Control Mechanisms
 Access Control Lists (ACL)
– Specification of access rights per resource: which users (by userid)
can access this resource
– One problem: there might be too many such users
 User Groups
– Group users so that can refer to and specify access policy for the
entire group
– Some systems also allow grouping of resources
– Group membership can be part of the organizational “directory”,
and/or part of the (signed) certificate of each user
– Examples: administrators, power users, marketing, guests
– Still, a lot of replication, e.g., Marketing, Sales, and R&D groups
may all share a certain subset of access rights
 Hierarchical groups
– Employee can be the parent/child of each of Marketing, Sales, R&D
Example: Access Control to File
System in Unix, NT
 Unix
– Every file associated with a “mode”
– Read, Write, and eXecute rights, for
owner, group, world
– e.g., dr--r-xrwx
– getacl, setacl functions support
additional ACL entries for users, groups,
and objects
 Windows NT
– NTFS allows specifying which users,
groups can do what to a file, folder,
registry, and other system objects
– A few groups are pre-defined, e.g., admin,
power-users, users
Hardening to Restrict OS Access
 Background: Operating Systems were originally designed
without security in mind
– many “friendly” services, e.g., mail, ftp, file, printer, login
– many pre-configured accounts, e.g., system, administrator, backup
 Problem: Hackers use these extra services to penetrate
 Solution: “harden” OS (aka secured shell)
– remove services, e.g., sendmail, remote login
– monitor for unexpected traffic, usually using IDS tools
Role Based Access Control (RBAC)
 NIST RBAC Standard
– ANSI INCITS 359-2004, Ferraiolo et al, 2/2004
Ad-Hoc Direct Privileges
Users
UA
Hierarchy
Roles
Permissions
PA
Operations
Objects
Session
 Today implemented in most enterprise software
 Mandated or recommended by industry regulations
Role-Based Security
 A “logical” layer that links users and allowed resources
– A role specifies the need or circumstances in which a user needs a
resource
– User-Role and Role-Resource relations simplify User-Resource
relations
Credit
Telemarketers
Manager
Admin
Roles Layer
 Employee
 Org role(s)
 Geography
 Member of
committee
 Reporting to
 In charge of
process
 Weekend shift
 Roles can be
hierarchical
1
3
2
Credit
Screen
Credit
Marketing
Alert
Mgmt Security
HQ
RBAC Productivity/Security Gains
 Productivity Gains
– Easier to provision new employees
• Alice replaces Bob as VP of Marketing
• John joins the security administration team
– Easier to manage change
• Richard was relocated to the Singapore office
• Bonnie replaces Jack in the computing committee
 Security Gains
– Many users are “collectors” of access rights
– Facilitates compliance with regulations and audit of
access rights
Policy-based Access Control
 A policy is of a set of rules that govern access control
– Policy Administration Point (PAP)
– Policy Decision Point (PDP)
– Policy Enforcement Point (PEP)
 Can itself be based on roles, groups, identity attributes, and
resource attributes
PAP
Define & Manage Policies
Many systems,
PDP
PDP
Evaluate & Decide
Evaluate & Decide
PEP
PEP
PEP
PEP
PEP
Enforce
locations
Governance, Risk & Compliance (GRC)
 Regulations:
– Industry regulations: banking,
SEC, payment, insurance, utilities
– National, e.g., competition
– Enforcement + Demonstration
 Fine-grained entitlement
management
– User/resource attributes
– Roles/groups
– Access context
 IT controls
– Segregation of duties, checks and
balances, business process rules
 Risk
– Assess, prioritize, remediate
Sarbanex-Oxley (SOX), GLB, HIPPA
FERC, ISO, PCI, FISMA, Basel II
Identity Management / Provisioning
 A set of tools for managing organizational identities and
their access privileges
 Management functions
– Add/remove/update info about users, resources
– Add/delete privileges to platforms and/or applications
– Manage access policies
 Automated Provisioning
– Automates requests and approvals processes
– Provisions and de-provisions on target systems (accounts, group
membership, etc.)
 Main Benefits
– Centralized store for organizational identities
– Centralized management
– Automated provisioning and removal of privileges
Typical ID Mgmt Functions









User provisioning
Role Management
Password reset and password management
Web access control
Self-service requests and approvals
Authentication & Single sign-on
Log management and analysis
Public Key Infrastructure
Federation of identities
 Many IdMs use directories to store identities and policies
 Some IdM start to provide Governance, Risk, and
Compliance (GRC) capabilities
Directories
 Goal: centralized repository of users and privileges
 Solution: Directory
– Centralized repository of users, resources, and privileges
– Implements a hierarchical database
– Users (leaves) appear with their specific information (attributes)
• name, user names, certificates, org, etc.
– Fast retrieval
– Difficult update
 IETF X.500 Directory Access Protocol (DAP)
– Defines access to the Directory
– Runs on top of TCP
– Almost all implementations are Lightweight DAP (LDAP)
 Federated Directories (a.k.a. Meta-directories)
– Integrate and implement trust between directories
Maturity of IdM Technologies
Firewalls and Proxy Servers
Main Sources: Stallings, Checkpoint Software
The Firewall Principle
 Create a controlled link between the protected network
and the outside world
– Inspects all inbound and outbound traffic
 Allows only authorized traffic
– Per specified security policy
Server
 Firewall itself can be
– Hardware
– Software (mostly)
Server
 Must itself be immune to penetration
– Hardware, or a trusted system,
implemented on top of a hardened OS
HUB
Router
Internet
private
network
FW-enforced Policies
 Service control : which services are allowed
– may determine valid ports
– may use a proxy to interpret requests before they are passed on
– may host the service outside the internal network (web, e-mail)
 Direction control
– may limit certain services to only one direction
 User control : who is allowed to use the service
– may apply access control policy to internal users
– may use IPSec to authenticate external users
 Behavior control : how a service can be used
– may implement intrusion prevention or anti-virus filter
– may filter spam in either direction
Limitations and Other Uses
 Limitations
– The FW cannot protect against internal attacks (unless traffic is filtered)
– The FW cannot protect against back-door attacks, e.g., through a dial-up
line that goes directly into the internal network
 In addition to its filtering uses, the FW location is ideal for other
functions as well
–
–
–
–
–
VPN implementation
Network Address Translation (NAT)
Intrusion detection / prevention
URL filtering
Anti-virus filtering
 Personal firewalls (highly recommended)
– Control what executes on and communicates from a given machine
– Can protect against intra-net attacks
FW types: Packet-Filtering




Implemented in IP layer
Applies a set of rules to individual IP packets
Rules are based on IP and TCP header parameters
The first rule that matches the packet is applied
Rule
action
Dir
Protocol source
untrusted block
any
any
123.4.5.*
*
192.168.*.*
*
email
allow
in
TCP
*
*
*
25
Spoofing block
in
any
192.168.*.*
*
*
*
Default
any
any
*
*
*
*
block
Port destination Port
• If no rule applies, the default is usually to drop the packet
 Advantages: application independent, fast
FW types: Application Gateways
 Application-specific software that brokers between the
server and its clients
 Brokers and examines each C/S transaction
 Pros:
– better security through app
awareness
 Cons:
– application dependent
– slow
– requires awareness of
internal user
 Examples: FTP, Telnet,
Web apps
FW types: Stateful Inspection
 Problem: packet filters examine isolated packets
– e.g., may not want to allow FTP data communication on a port that is not
associated with an open FTP session
 Solution: maintain a state
– Communication-derived state,
e.g., which ports are open
– Application-derived state, e.g.,
whether the user was already
authenticated by the service
 Packets intercepted at IP layer, but
also tracked in upper layers
– Creates a virtual session, useful
even for connectionless protocols
 Cons (vs. app gateway): usual
implementations do not analyze
packet internals
Bastion Host
 Bastion Host services external users
– Hosts proxy servers + externally available services
– Only server addressable directly from outside network
– Usually located after a packet filter
– Must be very well protected
• hardened OS
• requires authentication
 Examples:
– Victim BH : provides unprotected services to external
users
– Non-routing dual-homed BH : services internal and
external users (does not transfer packets between them)
– Internal BH : located inside network, and services
external users – must be very well secured
Example: Firewall Configuration (1)
 Screened host firewall with single-homed Bastion Host
– All communication with external network goes through the BH
– BH may perform authentication and proxy functions
Example: Firewall Configuration (2)
 Screened host firewall with dual-homed Bastion Host
– In the single-homed BH, if the packet-filter is compromised then
intruder has access to rest of the network
– Here, there is a physical separation, so intruder must gain control
of the BH as well (an example of Defense-in-Depth)
Example: Firewall Configuration (3)
 Screened subnet firewall
– Another packet filter offers a third level of protection
– Outside router does not advertise internal network, and therefore
hard for intruder to map it
 The screened subnet a.k.a. perimeter network or DMZ is
often used to host services for external users
Proxy Servers
 An “Application Gateway” Firewall
 Usually located on a BH
 Must be written specifically for each application
– Standard ones for TCP services: FTP, Telnet, HTTP
– Generic ones that can be configured for new applications
 Every proxy server software must be configured to
maximize security
–
–
–
–
–
–
may be configured to access only specific hosts
may require additional authentication
a simple software that can be more easily audited for security flaws
maintain log for future audit
proxies are independent
proxies run in a non-privilege mode, and in own private folders
Example: Web Application Gateway
 Web applications are very common, and hackers often try
to penetrate and exploit them
 A Web gateway “hides” the actual web server
 Enforce intended business logic and business policies
– Build/learn policy for web application, reflecting the intended use
Web App Gateway Functions (2007)







Multi-application gateway
Web app firewall, including “deep” packet inspection”
Web app access control
Web services protection (for SOA)
Automated learning of legitimate use patterns
App layer Denial-of-Service protection
Website cloaking: hiding from crawlers (but not Google...)
 Application gateway devices often include functions of
regular packet filters and/or stateful inspection firewall
 And also other security features
– Access control to protect specific sensitive data
– Encryption
– NAT
Attacks on Firewalls
 Firewalls can be difficult to configure and many contain
bugs in their policies
– Most implementations of firewalls are fairly superficial in
examining the application fields
– Usually firewalls cannot deal with IP spoofing
 Perimeter-based firewall cannot protect against internal
attacks and Trojans
 Firewall cannot prevent DoS attacks
 Market trends:
–
–
–
–
application gateways, e.g., for web services and XML
Smarter firewalls, e.g., “learning”, “identity role-based”
combined security appliances
centralized consoles for management
Client/Server Authentication
Kerberos
Main sources: Stallings, Schneier, Kaufman et al
Kerberos
 Background
– Client/Server authentication service, developed by Project Athena
– Deployed as a Single-Sign On service
 Services
–
–
–
–
Client/Server authentication
Allows users and servers to mutually authenticate
Key Distribution Center (KDC)
Uses symmetric key as proof of identity (DES/RC4)
• New versions use other forms of authentication
 Requirements
–
–
–
–
–
Protect against user impersonation
Protect against spoofing of device identity
Protect against replay attacks
Provide high availability
Provide transparency to the user and application server
Kerberos Protocol
Ticket
Granting
Server
Grant
Ticket
Req
Ticket Grant
TGT
Req
Service
Client
Server
Req
TGT
Kerberos
Authentication
Server (AS)
 Ticket: T(c,s) = s,EKs(c,a,v,Kc,s)
– c-client, s-server, a-client address, v-validity time
– Used as a “pass” until expiration
 Authenticator: A(c,s) = E Kc,s(c,t,k)
– t-time stamp, k-additional session key
– Used once, but the client can generate as many as she wishes
Kerberos Protocol
Ticket
Granting
Server
Grant
Ticket
Req
Ticket Grant
TGT
Req
Service
Client
Server
Req
TGT
 Req TGT: Send c,tgs
 Grant TGT: Gen Kc,tgs; Send EKc(Kc,tgs), T(c,tgs)
 Req Ticket: Send A(c,tgs), T(c,tgs), s
 Grant Ticket: Gen Kc,s; Send EKc,tgs(Kc,s), T(c,s)
 Req Service: A(c,s), T(c,s)
Kerberos
Authentication
Server (AS)
Kerberos Security Features
 Kerberos acts as a KDC (Key Distribution Center)
 Kerberos AS verifies the identity of a client through the
key, and comparing identity and address to a database
– Key can be symmetric key, or derived from password
 Tickets T(c,tgs/s) is given to the client but is locked
 Server continuously verifies client through session key in
authenticator
 Timestamps used to ensure synchronicity and against
original ticket validity (typically 8 hours)
 It is common to quickly replace use of client long-term key
with a session key
Example: Windows 2000 Kerberos
1
Application Server
User
Client
1. Locate the Active Directory
and Kerberos KDC for the
domain using DNS lookup.
Client receives key encrypted
with own password
2. Authenticate user
and get a Ticket
Granting Ticket (TGT)
from KDC
2
Windows 2000
Active Directory
KDC
AS
TGS
Windows 2000 Domain Controller
Attacks on Kerberos Security
 Kerberos itself stores many keys and should be protected
 Tickets may be replayed within allowed lifetime. Server
should store recent requests and check for replays
 Adversary may cache many TGTs and work offline to
decrypt them (see Wu’s attack). Clients shall use safe
passwords.
 By changing server clocks, adversary may replay tickets.
Hosts shall synchronize clocks often
 Enhancements
– Allow authentication using public-key certificates, smart cards
– Mutual authentication, where server returns signed timestamp
Wu’s Attack
 Dictionary attack on the TGT ticket returned by AS
 Kerberos authentication exchange step-by-step
– Initial request sent in clear
• User name, requested ticket/service information
– AS responds, message encrypted with key based on user password
• Session key, service name, …
– Client decrypts (verifying identity through knowledge of the key)
 Attacking Kerberos client
– Applies dictionary attack, decrypting with different passwords
– Seeking service name = “krbtgt”
 In two weeks, Wu has broken 2045 passwords in a real
25,000 users domain
 Kerberos V5 requires pre-authentication
– Client sends timestamp encrypted with authenticating key
Other Kerberos Features
 Kerberos Administration Server (KADM)
– Purpose: add/manage users in the Kerberos database
– Employs another protocol
 Kerberos Replication and Realms
– In large organizations, it is possible to replicate the TGT/Ss, with
one copy serving as a master and the others being read-only
– It is also common to divide the network services into Realms, each
covered by different Kerberos servers, with a trust between realms
 Kerberos is widely implemented
– Most popular in network authentication
– Main authentication mechanism in Win2K and up (esp. in domains
that require Unix integration), and MS Passport
– Directory servers and API available from Microsoft, Sun, etc.