Skip to main content

Computer Systems Security Planning for Success

Dr. Jan Pearce, Editor

Section 7.3 Network Access

Subsection 7.3.1 Active Directory

Active Directory (AD) is a directory service typically used in Windows networks to control and track resources. AD is a Microsoft technology that enables centralized network management. It has proven to be very scalable and is commonly deployed in the enterprise environment (corporations, universities, schools, etc.)
🔗
Active Directory relies upon the Lightweight Directory Access Protocol (LDAP) for its communications. While AD is probably the largest deployed user of LDAP other implementations for various operating systems exist, including Apple OpenDirectory, RH Directory Server, and OpenLDAP. LDAP is often used by internal applications and process.
🔗
The cornerstone of an AD environment is the Domain Controller (DC). DCs stores directory information about Users, Groups, Computers, Policies, and more. They respond to auth requests for the domain (network) they are supporting. A standard network will have multiple DCs with fail-over in place in case something goes wrong.
🔗
For many environments, AD is the mechanism used for authentication, authorization, and accounting. As many services have migrated to the web, the need to access AD from anywhere has become increasingly important. This has kindled the growth of Azure Active Directory, a cloud-based version of active directory. Increasingly we are seeing deployments that utilize cloud-based resources instead of local DCs.
🔗
🔗

Subsection 7.3.2 Privileged Identity Management (PIM)

Privileged Identity Management (PIM) is a method of managing access to resources such as locations, commands, audit reports, and services. PIM aims to provide more granular access control. By recording more information about access it allows for better reporting regarding suspicious behavior and anomalies. PIM is used in the Windows operating system and for many Microsoft Azure services.
🔗
🔗

Subsection 7.3.3 Privileged Access Management (PAM)

Privileged Access Management (PAM) is a framework for safeguarding identities with advanced capabilities, such as superusers in a *NIX system. PAM is common in the Linux world, where it is used to control how administrators log in. PAM supports many more features than the older "become root and perform admin tasks" model. With PAM passwords can be set to expire, better auditing can be put in place, and privilege escalation can be made temporary.
🔗
🔗

Subsection 7.3.4 Identity and Access Management (IAM)

Identity and Access Management is a framework for managing digital identities. IAM manages the user database, logs when users sign in and out, manages the creation of groups or roles, and allows for the assignment and removal of access privileges. Many different groups offer IAM frameworks, the most famous of which may be Amazon Web Systems (AWS) which use it for controlling access to the infrastructure as a service (IaaS) technologies they offer.
🔗
IAM often makes use of PIM and PAM to accomplish these goals. A well-implemented, thorough IAM framework can work across operating systems and handle many different types of resources.
🔗
🔗

Subsection 7.3.5 Unix File Permissions

From its inception, Unix was designed to be a multi-user environment, and as such, a lot of attention was paid to file permissions. Every file in a Unix system has an owner and a group. Each file also has permissions for owner, group, and all users. Permissions are set using octal numbers where each bit represents read (bit 0: 1), write (bit 1: 2), or execute (bit 2: 4) permission.
🔗
Diagram illustrating Unix-style file permissions (read, write, execute).
The image would provide a visual explanation of the Unix-style file permission system. This includes a breakdown of the symbolic notation (e.g., `rwx` for read, write, and execute) and how these permissions apply to the three categories of users: owner, group, and others. It also illustrates the octal (numeric) representation of these permissions (e.g., 4 for read, 2 for write, 1 for execute) and how they combine to form a complete permission.
🔗
Figure 7.3.1. Unix-style File Permissions (Read, Write, Execute)
🔗
For example, if you wanted a read and execute permission the number would be 5 (1 + 4). Read and write permission would be 3 (1 + 2).
🔗
Permissions are specified with the chmod command, the first octal number is the permissions for the owner, the second is for the group, and the third is for all user. So to change a file to have read, write, and execute permissions for the owner, read permissions for the group, and no permissions for everyone else, the command would be chmod 710 <filename> where <filename> is the name of your file.
🔗
The owner and group of a file can be set with the chown command: chown <owner>:<group> <filename>. If <group> is not specified only the owner is changed.
🔗
🔗

Subsection 7.3.6 ACLs

Access Control Lists (ACL) are used to permit or deny access based on a characteristic. They tend to be based on a simple characteristic and either deny access to anyone not on the list, allowlist, or deny access to anyone who is on the list, denylist.
🔗
ACLs used in networking and typically filter based on IP address. You can find examples of ACLs in most firewall products as well as in Amazon Web Services (AWS) Virtual Private Cloud (VPC).
🔗
Filesystem ACLs apply the same concept to files. Linux uses filesystem ACLs to permit or deny access in a more nuanced way than possible with Unix File Permissions 7.3.5.
🔗
🔗

Subsection 7.3.7 SSH Keys

Secure Shell Server (SSH) supports the use of asymmetric encryption keys for authentication. Most severs support RSA, DSA, and ECDSA keys, with RSA being the most common. An SSH server maintains a list of authorized keys, typically in ~/.ssh/authorized_keys, that can be used to connect to the server. When a client connects, the SSH server issues a challenge asking the client to sign a random piece of data using their private key. If the private key matches the public key stored in the authorized_keys file, the user is logged in.
🔗
SSH keys have the advantage of being easier to use as the user doesn’t need to remember and type in a password. For this reason, keys are often used for authentication when running protocols over SSH such a git
 1 
git-scm.com/
. Keys also have the advantage of possibly thwarting MitM attacks. While a password can be easily stolen by a malicious actor impersonating an SSH server, authentication via key will only transmit a signed bit of random data. This bit of data is useless to the MitM.
🔗
🔗

Subsection 7.3.8 Sessions and Cookies

HTTP sessions can also be used to control access to a resource. This is often employed in web applications. Upon successful sign-in, a user is given a cookie with a cryptographically tamper-resistant session ID. Every request the user makes to that site will include that cookie. Eventually the session will time out and the user will make a request that is denied based on their session ID no longer being valid. Typically the website will redirect them from the protected resource to a login page where they can log in again.
🔗
Website cookies may also be used to store user preferences or the current state of the application. A cookie could list the items currently in a users shopping cart or specify whether or not the user prefers dark mode. Cookies have been a target of scrutiny as they can be used in attacks. If cookies can be accessed by an outside application or by a separate malicious tab in a web browser, then can be used to gain access to a users session.
🔗
🔗

Subsection 7.3.9 Single Sign On (SSO)

Given the ubiquitous nature of web applications, maintaining separate usernames and passwords can be difficult for users. A recent trend has been to support Single Sign On, where one identity provider is used to confirm that users are who they claim to be. There are a few protocols that make this possible, including SAML and OAuth.
🔗
SAML stands for Security Assertion Markup Language and is an XML based Single Sign On solution. The SAML workflow centers around the SAML identity provider or IDP. The following steps take place to grant access to a resource via SAML:
🔗
  1. User accesses a service.
    🔗
    🔗
  2. User is redirected to SAML IDP with SAML request.
    🔗
    🔗
  3. User logs in.
    🔗
    🔗
  4. Credentials are verified.
    🔗
    🔗
  5. SAML IDP sends credentials to the service.
    🔗
    🔗
🔗
OpenID is another protocol that allows users to authenticated using a third-party identity provider in a similar fashion to SAML. One of the main differences is that OpenID was designed to be decentralized, allowing for multiple IDPs for users to choose from. In February 2014 OpenID introduced OpenID Connect (OIDC), a more modern system that allows IDPs to provide information about users via a REST API. This move was largely in response to the popularity of OAuth.
🔗
OAuth is a method for allowing websites to access parts of a user’s profile with the user’s permission. OAuth is not technically a full-fledged authentication protocol, but it is often used as part of one. The following diagram highlights the differences between OpenID authentication and an OAuth flow:
🔗
Diagram comparing OpenID Authentication with Pseudo-Authentication using OAuth, illustrating metaphorical credential exchanges with an identity/API provider.
The diagram is divided into two horizontal panels, contrasting "OpenID Authentication" (top) and "Pseudo-Authentication using OAuth" (bottom), with an Android application, a user icon, and a Google building icon representing the provider in each flow.
🔗
In the "OpenID Authentication" panel, the Android app asks the user for a "notarized referral letter." The user requests this from "Google - The Identity Provider," specifically asking for a referral stating "I’m user@gmail." Google issues a "certificate" (detailing "name: Real Name, email: user@gmail, notary: Google"), which the user then presents to the app.
🔗
In the "Pseudo-Authentication using OAuth" panel, the Android app asks the user for a "valet key*" to their "house (account)" to verify ownership. The user requests "Please issue me a valet key* for the core APIs" from "Google - The Identity Provider & the API Provider." Google issues a "valet key*," which the user gives to the app. A footnote clarifies "*valet key = limited scope OAuth Token."
🔗
The diagram uses these metaphors to simplify the different authentication and authorization mechanisms. An attribution "adapted from a drawing by @_nat_en" is present in the lower right of the OAuth panel.
🔗
Figure 7.3.2. OpenID Authentication (top) vs. Pseudo-Authentication using OAuth (bottom)
🔗
OpenID vs. Pseudo-Authentication using OAuth
 2 
commons.wikimedia.org/wiki/File:OpenIDvs.Pseudo-AuthenticationusingOAuth.svg
by Perhelion
 3 
commons.wikimedia.org/wiki/File:OpenIDvs.Pseudo-AuthenticationusingOAuth.svg
used under CC0 1.0
 4 
commons.wikimedia.org/wiki/File:OpenIDvs.Pseudo-AuthenticationusingOAuth.svg
🔗
🔗

Subsection 7.3.10 Kerberos

Kerberos is an authentication protocol for client server connections. It was developed by MIT in the 1980s and is most largely deployed on Windows networks, but many Linux distributions support using it for authentication as well. Kerberos makes extensive use of time-based tickets and as such all client participating must have their clocks in sync. When functioning correctly, Kerberos allows for full authentication on an untrusted network.
🔗
Kerberos makes use of many different services and concepts to perform its duties. Some of these services may run on the same machine and they are almost always abbreviated:
🔗
  • Authentication Server (AS): performs the authentication step with clients
    🔗
    🔗
  • Ticket-Granting Service (TGS): service which creates and signs tickets
    🔗
    🔗
  • Ticket-Granting Tickets (TGT): time stamped and encrypted (with the TGS secret key) ticket that grants the ability to create tickets and sessions for services
    🔗
    🔗
  • Key Distribution Center (KDC): runs the TGS and grants TGTs
    🔗
    🔗
  • Service Principle Name (SPN): name of a service that uses Kerberos authentication
    🔗
    🔗
🔗
To sign in and client reaches out to the AS which gets a TGT from the TGS running on the KDC and gives it to the client. The client gets the SPN of the service it wants to utilize and sends it along with the TGT to the TGS. Assuming the client has permission to access the service the TGS issues a ticket and session to the client. The ticket is then used to connect to the service.
🔗

Example 7.3.3. Golden Ticket.

A dangerous attack against Kerberos authentication exists and goes by the name Golden Ticket. TGTs are the cornerstone of Kerberos security and the Golden Ticket exploit targets them specifically.
🔗
Using the fully qualified domain name, security identifier, username of an account, and a KRBTGT password hash an attacker can create their own TGTs that will grant access to services. The KRBTGT account is an account that Windows machines use to perform Kerberos administrative tasks. The KRBTGT password hash can be obtained from any machine where that account was used if the attacker has complete access to the files on the hard drive. This may be done with physical access or through the use of malware on a victim machine.
🔗
An attacker will only be able to forge TGTs until the KRBTGT account password is changed, so a common remediation strategy is to change the password
 5 
blog.quest.com/what-is-krbtgt-and-why-should-you-change-the-password/
. Ultimately the administrator will need to determine how the KRBTGT password hash was obtained in the first place.
🔗
🔗
🔗

Subsection 7.3.11 Tokenization

Tokenization may be used as part of an access control scheme to protect sensitive information. Information that would be highly valuable if compromised is replaced with a random token known to the parties involved in the transaction. In a typically scenario once the tokens have been established, only the token is sent out over an untrusted network.
🔗
Imagine you don’t want your credit card number exposed to merchants. One solution would be if you used a payment service that issued you a new credit card number for each transaction. This credit card number would only be valid for a single transaction and would be billed to your regular credit card (which the payment service would have access to). In this case the token is the one-time-use credit card number and the sensitive information is your actual credit card number. Payment services like ApplePay and GoogleWallet do exactly this.
🔗
🔗
You have attempted 1 of 1 activities on this page.
🔗
PrevTopNext