（RHCA）Red Hat Enterprise Linux RHS333: Red Hat Enterprise Security: Network Services

Unit 5

Network Authentication: RPC,NIS and Kerberos

Objectives

Upon completion of this unit, you should be able to: The RPC protocol and portmap Protecting portmap NIS weaknesses Improving NIS security Secure authentication with Kerberos

Vulnerabilities

portmap exposes open ports to remote users Dynamic port assignment complicates protection of services NIS transmits account data unencrypted on the network NIS servers have easily spoofed client authentication mechanismsl

Resolutions

Use TCP wrappers and packet filtering to protect portmap and RPC services Restrict hosts that have access to NIS Do not pass RPC data on external networks Use Kerberos with NIS NIS provides account information Kerberos provides secure authentication

Network-managed users

Information about accounts may be stored on a remote server Two types of information must be provided Authentication: a way to prove the identity of a user Account Information: UID number, primary group, default shell, and so on

Account Management

Local accounts use files in /etc to store both account information and authentication information Network accounts store account information in directory services (NIS, LDAP, DNS/Hesiod) Network accounts may store authentication information in directory services, or in a separate authentication-only service (Kerberos)

What is Sun RPC

Remote Procedure Call protocol Session protocol used by NIS and NFS Protocol transported by TCP or UDP RPC services have program numbers Identifies particular RPC services Matched to ports through portmap

RPC Security Issues

portmap exposes the list of available RPC services $ rpcinfo -p [servername] Even if blocked from using portmap, an attacker may directly scan for the RPC service ports with nmap Dynamic port assignment makes use of firewalls hard

NIS Overview

Simple directory service for system and account information All NIS servers and clients are members of a named NIS domain Single master server, multiple slave servers Minimal network security Support for NIS version 1 and 2

Service Profile: NIS

Type: System V-managed services Packages: ypserv Daemons: ypserv, rpc.yppasswdd, rpc.ypxfrd Scripts: ypserv, yppasswdd, ypxfrd Ports: Dynamically assigned by portmap Configuration: /var/yp/*, /etc/ypserv.conf (/etc/yp.conf for ypbind) Related: portmap, ypbind, yp-tools

NIS Security Weaknesses

Server messages not authenticated to client No message integrity checks Easy to pose as server or forge data Client messages not authenticated to server Easy to pose as valid client and capture database No secrecy of data transmitted Sniffing can capture individual password hashes and other data

Improving NIS Security

Only allow NIS traffic on internal networks Block access to portmap and NIS services from external or untrusted hosts TCP wrappers and iptables Static ports /var/yp/securenets

Improving NIS Security

Do not allow server discovery by broadcast Prevents ypserv impersonation Do not store password hashes in NIS Use NIS only for account information Use Kerberos for authentication

Kerberos

Secure network authentication system Based around credentials called tickets Tickets secured by secret key encryption Three participants Key Distribution Center (KDC) Application Servers (network services) Client users

Principals

A principal identifies each participant in a Kerberos authentication Users and network services Identified by primary, instance, and realm Each principal has a password Passwords are used as encryption keys Users memorize passwords Services store passwords in a keytab file KDC knows all passwords

Initial Authentication

User enters username and password Login program sends request for a TGT for that principal to the KDC KDC sends the login program a TGT encrypted using the user's password If the login program can decrypt the TGT with the password provided by the user, the user is authenticated

Ticket Authentication

Client sends request for a service ticket to the KDC's ticket granting service KDC sends client two identical copies One encrypted with the TGT One encrypted with the service password Client sends the network service Ticket encrypted with service's password A timestamp encrypted with the ticket

Service Profile: Kerberos

Type: System V-launched daemon Packages: krb5-server, krb5-libs Services: krb5kdc, kadmind, kpropd Scripts: krb5kdc, kadmin, kprop Ports: 88/udp, 464/udp,749/tcp, 754/tcp Configuration: /etc/krb5.conf, /var/kerberos/krb5kdc/* Related: ntp, krb5-workstation, pam_krb5

/etc/krb5.conf

Configuration settings for the realm [libdefaults], [domain_realm], and [realm] sections Map DNS domain to realm name Client use file's settings to find KDC Can encode in file or use DNS SRV Kerberized apps use [appdefaults]

Installing a Master KDC

Set up /etc/krb5.conf Define basic settings for realm Set up kdc.conf and kadm5.acl Create database with kdb5_util Run kadmin.local Set up principals for users and services Create keytab file for kadmind Start krb5kdc and kadmind

Kerberos and DNS

In addition to dns_lookup_kdc, can replace [default_realms] with dns_lookup_realm Uses TXT record to determine realm DNS is normally not secure from spoofing Either option may make attacks simpler Use /etc/krb5.conf options instead

kdc.conf

Configuration settings for the KDC Stored in /var/kerberos/krb5kdc Default settings in [kdcdefaults] [realms] contains KDC parameters Divided into realm-specific subsections Supported principal encryption types ACL and keytab file locations

kadm5.acl

Specifies what access a principal has to the database through kadmin Stored in /var/kerberos/krb5kdc File format Principal, permissions, target principal Name, instance or realm may be wildcarded Lower-case permissions allow, upper-case permissions deny

Using kadmin

Can manage Kerberos principals addprinc, delprinc, modprinc, cpw Can set and manage password policies Password aging, minimum length, history addpol, delpol, modpol, getpol, listpols Can extract principals into keytab file ktadd, randomizes password

Installing Application Servers

Set up /etc/krb5.conf Run kadmin Create service principal addprinc host/[email protected] Extract service principal to keytab file ktadd -k krb5.keytab host/www.x.org Start Kerberized network service

Kerberos Clients

Set up /etc/krb5.conf Configure pam_krb5.so for Kerberos authentication, gets initial TGT kinit to get a new TGT klist lists available credentials kdestroy deletes all credentials Tickets stored in /tmp/krb5cc_UID

Debugging Kerberized Services

The password for the principal stored in the keytab file must match the one on the KDC ktutil can be used to view keytab files Can show the versions of the principals stored in a keytab file kvno requests a ticket from the KDC Can show which version of the principal requested is stored on the KDC

Kerberos Security

Assumes secure hosts, insecure net KDC compromise = Realm compromise Security of the KDC is critical If application server is compromised, service keys are compromised If client is compromised Stolen password compromises user Stolen TGT may be used to pose as user until it expires

Preauthentication

Ticket is encrypted with user password Normally can ask KDC for any user's TGT Can not use without user's password But can try to crack password used to encrypt captured ticket Require preauthentication if possible

Ticket Validation

Attacker can try posing as the KDC and a user to trick a client system into authenticating Client requests TGT for principal Fake KDC sends TGT for principal encrypted with password known to the attacker To defeat, login program must validate the KDC

Cross-Realm Trust

Two Kerberos realms may trust each other Users in one realm may authenticate to services in another Direct trusts share krbtgt principals krbtgt/[email protected] allows hosts in EXAMPLE.COM get tickets in OTHER.COM Indirect trusts: hierarchical, capaths

Kerberos Encryption

Kerberos session key can be used to encrypt data Often is not used by default No “Perfect Forward Security” If TGT is eventually cracked, can recover session key and decrypt data Some algorithms are weak (DES) or not widely supported yet (AES)

End of Unit 5

Questions and Answers Summary RPC and portmap NIS security issues Kerberos