IT 4823
Information Security Administration
Internet Authentication Protocols
Linux and Windows Security
July 9
Lecture slides prepared by Dr Lawrie Brown for “Computer Security: Principles and Practice”, 1/e, by William Stallings and Lawrie Brown, Chapter 6 “Intrusion Detection”.
Notice: This session is being recorded.
Identification and Authentication
• Identification?
• Authentication?
• Authorization
Copyright © 1993The New Yorker On the Internet, nobody knows you’re a dog.
On-Line Identity
• Application-level authentication and digital
signatures
• Implementations:
• Kerberos symmetric key authentication service • X.509 public-key directory authentication • Public-key infrastructure (PKI)
• Federated identity management
Internet Authentication Applications
Kerberos
• Trusted key server system from MIT
• Provides centralised secret-key third-party
authentication in a distributed network
• Allows users access to services distributed through network…
• …without needing to trust all workstations • Instead all trust a central authentication server
• Two versions in use: 4 and 5
Kerberos Overview
• A basic third-party authentication scheme
• Two servers (possibly one one machine)
• Authentication Server (AS)
• users initially negotiate with AS to identify self • AS provides a non-corruptible authentication
credential (ticket granting ticket TGT)
• Ticket Granting Server (TGS)
• users subsequently request access to other services from TGS on basis of users TGT
Kerberos Overview
Kerberos Performance Issues
• Works with larger client-server installations
• Kerberos performance impact is very little if
system is properly configured, since tickets
are reusable
• Kerberos security is best assured if the server
is a separate, isolated machine
• Motivation for multiple realms is
administrative, not performance
PKI: Certificate Authorities
• A digital certificate consists of:
• a public key plus ID of the key owner • signed by a third party trusted by community • a certificate authority(CA)
• Goal:bind an identity to a public key
• Users obtain certificates from CA
• User creates keys and unsigned certificate, gives to CA
• CA signs certificate, returns to user
• Other users can verify certificate by checking
signature on certificate using CA’s public key
X.509 Authentication Service
• Universally accepted standard for formatting
public-key certificates
• widely used in network security applications, including IPSec, SSL, SET, and S/MIME
• Part of CCITT X.500 directory service standards
• Uses public-key cryptography and digital
signatures
• algorithms not standardised, but RSA
recommended
Federated Identity Management
• Definition: use of a common identity
management scheme:
• across multiple enterprises and numerous applications
• supporting many thousands, even millions of users
• Principal elements are:
• authentication, authorization, accounting, provisioning, workflow automation, delegated administration, password synchronization, self-service password reset, federation
• Kerberos contains many of these elements
Federated Identity Management
Standards Used
• Extensible Markup Language (XML)
• characterizes text elements in a document on appearance, function, meaning, or context
• Simple Object Access Protocol (SOAP)
• for invoking code using XML over HTTP
• WS-Security
• set of SOAP extensions for implementing message integrity and confidentiality in Web services
• Security Assertion Markup Language (SAML)
• XML-based language for the exchange of security information between online business partners
Questions
IT 4823
Information Security Administration
Linux Security
April 23
Lecture slides prepared by Dr Lawrie Brown for “Computer Security: Principles and Practice”, 1/e, by William Stallings and Lawrie Brown, Chapter 6 “Intrusion Detection”.
Notice: This session is being recorded.
Linux Security
• Linux has evolved into one of the most popular
and versatile operating systems
• Many features mean broad attack surface
• You can create highly secure Linux systems
• We will review:
• Discretionary Access Controls
• typical vulnerabilities and exploits in Linux • best practices for mitigating those threats • new improvements to Linux security model
Linux Security Model
• Linux’s traditional security model is:
• people or proceses with “root” privileges can do anything
• other accounts can do much less
• Hence, attackers want to get root privileges
• One can run robust, secure Linux systems
• The crux of the problem is use of
Discretionary Access Controls
(DAC)
File System Security
• In Linux
everything
is treated as a file
• e.g.memory, device-drivers, named pipes, and
other system resources
• hence why filesystem security is so important
• I/O to devices is via a “special” file
• e.g./dev/cdrom
• There are other special files like named pipes
• a conduit between processes / programs
Users and Groups
• A user-account (user)
• represents someone capable of using files • associated both with humans and processes
• A group-account (group)
• is a list of user-accounts • users have a main group • may also belong to other groups
• Users and groups are
not
files
Users and Groups
• user’s details are kept in
/etc/password
maestro:x:200:100:Maestro Edward Hizzersands:/home/maestro:/bin/bash
• additional group details in
/etc/group
conductors:x:100:
pianists:x:102:maestro,volodya
• use
useradd
,
usermod
,
userdel
to alter
File Permissions
• files have two owners: a user and a group
• each with its own set of permissions
• with a third set of permissions for other
• permissions are to read/write/execute in order
user/group/other, cf.
-rw-rw-r-- 1 maestro user 35414 Mar 25 01:38 baton.txt
• set using chmod command
Directory Permissions
• read = list contents
• write = create or delete files in directory
• execute = use anything in or change working
directory to this directory
•
e.g.
$ chmod g+rx extreme_casseroles $ ls -l extreme_casseroles
drwxr-x--- 8 biff drummers 288 Mar 25 01:38 extreme_casseroles
Sticky Bit
• originally used to lock file in memory
• now used on directories to limit delete (and other things)
• if set must own file or dir to delete
• other users cannot delete even if they have write permission
• set using chmod command with +t flag, e.g.
chmod +t extreme_casseroles
• directory listing includes t or T flag
drwxrwx--T 8 biff drummers 288 Mar 25 01:38 extreme_casseroles
• only apply to specific directory not child dirs
SetUID and SetGID
• setuid bit means program “runs as” owner
• no matter who executes it
• setgid bit means run as a member of the group
which owns it
• again regardless of who executes it
• “run as” = “run with same privileges as”
•
are very dangerous
if set on file owned by root
or other privileged account or group
SetGID and Directories
• setuid has no effect on directories
• setgid does; causes any file created in a
directory to inherit the directory’s group
• This is useful if users belong to other groups
and routinely create files to be shared with
other members of those groups, instead of
manually changing its group
Numeric File Permissions
Each digit represents a bit in a mask: 1 = execute, 2 = write, 4 = read
For specials: 1=sticky bit, 2=setgid, 4=setuid
Kernel vs. User Space
• Kernel space
• refers to memory used by the Linux kernel and its
loadable modules (e.g.,device drivers)
• User space
• refers to memory used by all other processes
• Since the kernel enforces Linux DAC and
security, it is critical to isolate kernel from user
• so kernel space is never swapped to disk • only root may load and unload kernel modules
setuid root Vulnerabilities
• A
setuid root
program runs as root
no matter
who executes it
• Used to provide unprivileged users with access
to privileged resources
• Must be very carefully programmed because
errors could be exploited.
• Distributions now minimize setuid-root
programs
Web Vulnerabilities
• A very broad category of vulnerabilities with
big and visible attack surfaces
• When written in scripting languages
• not as prone to classic buffer overflows • can suffer from poor input-handling
• Few “enabled-by-default” web applications
• But users install vulnerable web applications
• Or write custom web applications having
easily-identified and easily-exploited flaws
Rootkits
• Allow attackers to cover their tracks
• If successfully installed before detection, all is
very nearly lost
• Originally, collections of hacked commands
• hiding attacker’s files, directories, processes
• Now rootkits use loadable kernel modules
• intercepting system calls in kernel-space • hiding attacker from standard commands
• May be detectable with chkrootkit
• Generally have to wipe and rebuild system
Linux System Hardening
• We consider how to mitigate Linux security
risks at system and application levels
• First, look at OS-level security tools and
techniques that protect the entire system
OS Installation
• Security begins with OS installation • Especially what software is run
• since unused applications liable to be left in default, un-hardened and un-patched state
• Generally should not run:
• X Window system, RPC services, R-services, inetd, SMTP daemons, telnet etc
• Initial system software configuration:
• setting root password • creating a non-root user account
• setting an overall system security level (initial file permissions) • enabling a simple host-based firewall policy
• enabling SELinux
Patch Management
• Installed server applications must be:
• configured securely
• kept up to date with security patches
• Patching can never win “patch rat-race”
• There are tools to automatically download
and install security updates
• e.g.up2date, YaST, apt-get
• Note: one should not run automatic updates on change-controlled systems without testing • There is tension between change control and
automagic updates.
Network Access Controls
• The network is a key attack vector to secure
• TCP wrapper is a key tool to check access
• originally tcpd inetd wrapper daemon • before allowing connection to service checks
• if requesting host explicitly in hosts.allowis ok • if requesting host explicitly in hosts.denyis blocked • if not in either is ok
• Checks on service, source IP, username • Now often part of application using libwrappers
Network Access Controls
• Linux has a very powerful netfilterkernel-based native
firewall mechanism and iptablesuser-space front end
• Useful on firewalls, servers, desktops
• Direct configuration is tricky, steep learning curve • There are automated rule generators
• Typically, “personal” firewall use will:
• allow incoming requests to specified services • block all other inbound service requests • allow all outbound (locally-originating) requests
• Can be configured manually for greater security
Antivirus Software
• Historically, Linux has not been as vulnerable to
viruses ad MS systems
• This is more due to popularity than security
• Prompt patching was effective for worms
• Viruses abuse users privileges, so non-root users
have less scope to exploit
• Growing Linux popularity means growing exploits
• Hence, antivirus software will be more important
• There are various commercial and free Linux A/V
products.
User Management
• Guiding principles in user-account security:
• need care setting file / directory permissions • use groups to differentiate between roles • use extreme care in granting / using root privs
• Commands: chmod, useradd/mod/del,
groupadd/mod/del, passwd, chage
• Critical information in files /etc/passwd and
/etc/group
• Manage user’s group memberships
• Set appropriate password ages
Root Delegation
• Linux has “root can to anything, users do little” issue • “su” command allows users to run as root
• either root shell or single command • must supply root password
• means likely too many people know this
• SELinux RBAC can limit root authority, complex to configure
• “sudo” allows users to run as root
• but only need their password, not root password • /etc/sudoers file specifies what commands allowed
• Or configure user/group perms to allow, tricky
Logging
• Effective logging is a key resource
• Linux logs using syslogd or Syslog-NG
• receive log data from a variety of sources
• sorts by facility(category) and severity
• writes log messages to local/remote log files
• Syslog-NG preferable because it has:
• variety of log-data sources / destinations • much more flexible “rules engine” to configure • can log via TCP which can be encrypted
• One should check and customized defaults
Log Management
• Balance number of log files used
• size of few to finding info in many
• Manage size of log files
• must rotate log files and delete old copies • typically, use logrotate utility run by cron • to manage both system and application logs
Application Security
• Many security features are implemented in
similar ways across different applications
• Approaches:
• running as unprivileged user/group • running in chroot jail
• modularity • encryption • logging
Running As Unprivileged User/Group
• Every process “runs as” some user
• Extremely important that this user is not root
since any bug can compromise entire system
• May need root privileges,
e.g.
bind port
• have root parent perform privileged function • but main service from unprivileged child
• User/group used should be dedicated, making it
easier to identify source of log messages
Running in chroot Jail
• chroot confines a process to a subdirectory
• maps a virtual “/” to some other directory • useful if have a daemon that should only access a
portion of the file system, e.g. FTP
• directories outside the chroot jail aren’t visible or reachable at all
• Contains effects of compromised daemon
• Complex to configure and troubleshoot; must
mirror portions of system in chroot jail
Modularity
• Applications running as a single, large,
multipurpose process can be:
• more difficult to run as an unprivileged user • harder to locate / fix security bugs in source • harder to disable unnecessary functionality
• Hence, modularity is a highly prized feature
providing a much smaller attack surface
•
cf.
postfix
vs
sendmail, Apache modules
Encryption
• Sending logins and passwords or application
data over networks in clear text exposes them to
network eavesdropping attacks
• Many network applications now support
encryption to protect such data, often using
OpenSSL library
• OpenSSL may need X.509 certificates
• can generate/sign using openssl command • may use commercial/own/free CA
Logging
• Applications can usually be configured to log
to any level of detail (debug to none)
• Must decide whether to use dedicated file or
system logging facility (
e.g.
syslog)
• central facility useful for consistent use
Mandatory Access Controls
• Linux uses a DAC security model
• But Mandatory Access Controls (MAC) impose a global security policy on all users
• users may not set controls weaker than policy
• normal admin done with accounts without authority to change the global security policy
• but MAC systems have been hard to manage
• Novell’s SuSE Linux has AppArmor • RedHat Enterprise Linux has SELinux
• Use “pure” SELinux for high-sensitivity, high-security
SELinux
• NSA’s powerful implementation of mandatory access controls for Linux
• Linux DACs still applies, but if it allows the action, SELinux then evaluates it against its own security policies
• Subjects are processes (run user commands) • Actions are permissions
• Objects are not just files and directories • To manage complexity SELinux has:
• “that which is not expressly permitted, is denied” (default deny)
• groups of subjects, permissions, and objects
Security Contexts
• Each individual subject and object in SELinux is
governed by a security contextbeing a:
• user - individual user (human or daemon) • SELinux maintains its own list of users • user labels on subjects specify account's privileges • user labels on objects specify its owner • role - like a group, assumed by users
• a user may only assume one role at a time, • may only switch roles if and when authorized to do so
• domain (also called a type) - a sandbox being a combination of subjects and objects that may interact with each other
• This model is called Type Enforcement(TE)
Decision Making in SELinux
Two types of decisions: • accessdecisions
• when subjects do things to objects that already exist, or create new things in expected domain
• transitiondecisions
• invocation of processes in different domains than the one in which the subject-process is running
• creation of objects in different types (domains) than their parent directories
• transitions must be authorized by SELinux policy
RBAC and MLS Controls
• SELinux has
Role Based Access Control
(RBAC)
• rules specify roles a user may assume
• other rules specify circumstances when a user may
transitionfrom one role to another
• and
Multi Level Security
(MLS)
• concerns handling of classified data
• Similar to Bell-LaPadula: “no read up, no write down”
• MLS is enforced via file system labeling
SELinux Policy Management
• Creating and maintaining SELinux policies is
complicated and time-consuming
• A single SELinux policy may consist of
hundreds of lines of text
• RHEL has a default “targeted” policy
• defines types for selected network apps • allows everything else to use DAC controls
• There is a (large) set of SELinux commands; RH
has a GUI for configuring
Novell AppArmor
• Novell’s MAC for SuSE Linux
• enforced at kernel level • using Linux Security Modules
• Restricts behavior of selected applications in a
very granular but targeted way
• hence a compromised root application’s access will be contained
• has no controls addressing data classification • Hence, it is only a partial MAC implementation
• Non-protected applications just use Linux DAC
Windows and Windows Vista Security
• Windows is the world’s most widely-used O/S
• An advantage is that security enhancements can
protect millions of nontechnical users (effort by
Microsoft pays large rewards)
• A challenge is that vulnerabilities in Windows
can also affect millions of users
• We will review overall security architecture of
Windows 2000 and later. (Changed since
Win9X.)
Windows Security Architecture
• Security Reference Monitor (SRM)
• a kernel-mode component that performs access checks, generates audit log entries, and manipulates user rights (privileges)
• Local Security Authority (LSA)
• responsible for enforcing local security policy
• Security Account Manager (SAM)
• a database that stores user accounts and local users and groups security information
• local logins perform lookup against SAM DB • passwords are stored using MD4
Windows Security Architecture
• Active Directory (AD)
• Microsoft’s LDAP directory
• all Windows clients can use AD to perform security operations including account logon
• authentication uses AD when the user logs on using a domain rather than local account
• user’s credential information is sent securely across the network to be verified by AD
• WinLogon (local) and NetLogon (net) handle
login requests
Local vs. Domain Accounts
A networked Windows computer can be:
• domain joined
• can login with either domain or local accounts • if local may not access domain resources • centrally managed and much more secure
• in a workgroup
• a collection of computers connected together • only local accounts in SAM can be used • no infrastructure to support AD domain
Windows Login Example
• Domain admin adds user’s account info (name, account, password, groups, privileges)
• Account is represented by a Security ID (SID), unique to each account within a domain
• Username in one of two forms:
• SAM format: DOMAIN\Username • User Principal Name (UPN):
username@domain.company.com
• Login requires username and password or smartcard • The user is issued with token (SID, groups, privileges)
Windows Privileges
• Are system wide permissions assigned to user
accounts
• e.g.backup computer, or change system time
• Some are deemed “dangerous” such as:
• act as part of operating system privilege • debug programs privilege
• backup files and directories privilege
• Others are deemed “benign” such as
• bypass traverse checking privilege
Access Control Lists
Two forms of access control list (ACL):
• Discretionary ACL (DACL)
• grants or denies access to protected resources such as files, shared memory, named pipes etc
• System ACL (SACL)
• used for auditing
• in Windows Vista, to enforce mandatory integrity policy
Access Control Lists
• Objects needing protection are assigned a DACL
(and possible SACL) that includes
• SID of the object owner
• list of access control entries (ACEs)
• Each ACE includes a SID and access mask
• Access mask could include ability to:
• read, write, create, delete, modify, etc
• Access masks are object-type specific
e.g.
service abilities are create, enumerate
Security Descriptor (SD)
• Data structure with object owner, DACL, & SACL, e.g.
Owner: CORP\Blake
ACE[0]: Allow CORP\Paige Full Control ACE[1]: Allow Administrators Full Control ACE[2]: Allow CORP\Cheryl Read, Write and Delete
• There is no implied access, if there is no ACE for requesting user, then access is denied
• Applications must request correct type of access: if just request “all access” when need less (I read) some user’s who should have access will be denied
More on SD’s and Access Checks
• Each ACE in the DACL determines access
• An ACE can be an allow or a deny ACE
• Windows evaluates each ACE in the ACL until
access is granted or explicitly denied
• So, deny ACEs come before allow ACEs
• default if set using GUI
• explicitly order if create programmatically
• When user attempts to access a protected object,
the O/S performs an access check, comparing
user/group info with ACE’s in ACL
Impersonation
• Processes can have multiple threads
• common for both clients and servers
• Impersonation allows a server to serve a user,
using the access privileges of the user
• e.g.ImpersonateNamedPipeClient function sets
user’s token on the current thread
• then access checks for that thread are performed against this token not server’s, with user’s access rights
Mandatory Access Control
• Windows Vista has “Integrity Control” that limits operations changing an object’s state
• Objects and principals are labeled (using SID) as:
• Low integrity (S-1-16-4096) • Medium integrity (S-1-16-8192) • High integrity (S-1-16-12288) • System integrity (S-1-16-16384)
• When a write operation occurs, first check whether subject’s integrity level dominates object’s integrity level
• Much of O/S marked medium or higher integrity
Vista User
Account
Windows Vulnerabilities
• Windows, like all O/S’s, has security bugs
• and bugs have been exploited by attackers to compromise customer operating systems
• Microsoft now uses a process called the Security
Development Lifecycle
• net effect approx 50% reduction in errors
• Windows Vista used SDL start to finish
• IIS v6 (in Windows Server 2003) had only 3
vulnerabilities in 4 years, none critical
Windows Security Defenses
• Attackers are now criminals rather than
poorly-socialized pre-adolescents, and are
highly motivated by money
• Windows has categories of security defenses:
• account defenses • network defenses • buffer overrun defenses. • browser defenses
Windows System Hardening
• Hardening is the process of shoring up defenses,
reducing exposed functionality, disabling features
• known as attack surface reduction
• use 80/20 rule to decide which features to enable • e.g.requiring RPC authentication in XP SP2 • e.g.strip mobile code support on servers
• Servers are easier to harden:
• are used for very specific and controlled purposes • perceive server users are administrators with better computer
configuration skills than typical users
Account Defenses
• User accounts can have privileged SIDs
• Least privilege dictates that users operate with just enough privilege for tasks
• Windows XP users are in “Local Administrators” for application compatibility reasons (bad)
• Windows Vista reverses default with UAC
• users prompted to perform a privileged operation • unless admin on Server
Low Privilege Service Accounts
• Windows services are long-lived processes started after booting
• many ran with elevated privileges • but many do not need elevated requirements
• Windows XP added Local Service and Network service accounts
• allow a service local or network access • otherwise operate at much lower privilege level
• Windows XP SP2 split RPC service (RPCSS) in two (RPCSS and DCOM Server Process)
• example of least privilege in action, see also IIS6
Stripping Privileges
• Another defense is to strip privileges from an
account soon after an application starts
• e.g.Index server process runs as system to access all
disk volumes
• but then sheds any unneeded privileges as soon as possible
• using AdjustTokenPrivileges
• Windows Vista can define privileges required by
a service
• using ChangeServiceConfig2
Network Defenses
• We need more than user defenses
• Because Windows is vulnerable to attack via
network service
• We have IPSec and IPv6 with authenticated
network packets enabled by default in Windows
Vista
• IPv4 also enabled by default, expect less use
• There is a built-in software firewall
• block inbound connections on specific ports
• Vista can allow local net access only
• optionally block outbound connections (Vista) • default was off (XP) but now default on (Vista)
Buffer Overrun Defenses
• Many compromises exploit buffer overruns
• Windows Vista has “Stack-Based Buffer
Overrun Detection (/GS)” default enabled
• source code compiled with special /GS option • does not affect every function; only those with at
least 4-bytes of contiguous stack data and that takes a pointer or buffer as an argument
• Defends against “classic stack smash”
Windows Stack and /GS flag
Buffer Overrun Defenses
• No eXecuteNamed (NX) / Data Execution Prevention (DEP) / eXecution Disable (XD)
• prevent code executing in data segments • as commonly used by buffer overrun exploits • applications linked with /NXCOMPAT option
• Stack Randomization (Vista only)
• randomizes thread stack base addresses
• Heap-based buffer overrun defenses:
• add and check random value on each heap block • heap integrity checking
Other Defenses
• Image Randomization
• O/S boots in one of 256 configurations • makes O/S less predictable for attackers
• Service Restart Policy
• services can be configured to restart if fail • great for reliability but lousy for security
• Vista sets some critical services so can only restart twice, then manual restart needed
• gives attacker only two attempts
Browser Defenses
• Web browser is a key point of attack
• via script code, graphics, helper objects
• Microsoft added many defenses to IE7
• ActiveX opt-in
• unloads ActiveX controls by default
• when any then first run prompts user to confirm
• Protected mode
• IE runs at low integrity level (see earlier) • so more difficult for malware to manipulate O/S
Cryptographic Services
• Cryptographic primitives for encryption, hashing, signing
• Encrypting File System (EFS)
• allows files / directories to be encrypted / decrypted transparently for authorized users
• generates random key, protected by DPAPI
• Data Protection API (DPAPI)
• manages encryption key maintenance protection • keys derived in part from user’s password
• BitLocker Drive Encryption
• encrypts an entire volume with AES • key either on USB or TPM chip
