In this video,
we're going to discuss how you can leverage identity
and access management programs
to automate and streamline access management,
because organizations can really boost
a lot of their operational efficiencies by doing this.
Now, the need for security to protect the data
on the systems and networks that you have
has skyrocketed in recent years.
Cyber security professionals
perform a wide variety of roles, analysis, forensics,
and administration as part of their daily jobs.
And one major dimension of cybersecurity
is known as IAM or Identity and Access Management.
Now, many security teams today are understaffed
and overextended,
and so often,
they're going to ask for system administrators
to help them with IAM,
and that way you can help them manage
and protect the increasing number of devices,
data, users, and systems
by implementing the proper IAM controls.
Now, IAM or Identity and Access Management
is a security process that provides identity,
authentication, and authorization mechanisms
for users, computers, and other entities
to work with organizational assets,
things like networks, operating systems, and applications.
IAM enables you to define the attributes
that are going to comprise the entity's identity.
This includes things like its purpose, its function,
its security clearance, and more.
Now, in most business environments,
IAM is considered a crucial service
for provisioning and managing access,
as well as bolstering the overall security
of your IT infrastructure.
Now, SSH is the first thing we're going to talk about,
and the SSH protocol is used to support
lots of different methods of authentication
when people try to connect to an SSH server.
Now, one of the most important of these is known as PKI
or Public Key Infrastructure.
Now, public key authentication
is used for interactive and automated connections
between different servers or between users and servers.
The motivation for using public key authentication
over using a simple password really comes down to security.
Now, public key authentication
provides cryptographic strength
that is really, really powerful
in comparison to a regular password.
Now, with SSH,
public key authentication is going to be used
to improve the security considerably,
because it frees up the users
from having to remember these long complicated passwords
and it does it in a more secure manner.
Now, in addition to security,
public key authentication can also offer usability benefits,
because it allows users to implement single sign-on
across multiple different SSH servers
that they're going to need to connect to.
Now, by using public key authentication,
you can also have automated passwordless logins available
by logging in with a digital certificate
instead of having to remember a password
each and every time.
Now, there's lots of different files
that you're going to have to touch
when you configure key-based authentication inside of SSH.
These files are going to be included
inside the ~/.shh directory.
Inside of here,
you're going to find lots of different files
that are related to your SSH keys.
For example, we have the id_rsa file.
This contains the user's private key.
We have the id_rsa.pub file,
which contains the user's public key.
We have the authorized_keys file,
which is located on your remote server,
that's going to list out all the public keys
that that server will accept as a means of authentication
when somebody tries to authenticate their client.
We also have the known_hosts file.
This contains a list of all the public keys
that the client is going to accept
as a means for that client to use that file
to authenticate the servers to try to connect to it.
And we also have the config file,
and this is going to be used to configure
your SSH connection settings,
such as using an identity file directive
to associate multiple keys with specific servers.
Now, there are various commands that are available
that you can use to work with these SSH keys.
The first one we're going to talk about
is the ssh-keygen command.
This is used to generate a public private key pair
using specified asymmetric encryption algorithms.
Now, the ssh-copy-id command
is going to be used to append the user's public key
to the remote server's authorized_keys file.
That way, the server can authenticate
the user's private key whenever they try to connect.
The public key is going to be sent over SSH,
and typically, it requires password authentication
to be enabled.
Now, on the other hand,
we also have the ssh-add command,
and this is going to be used to add the private key identifier
to the SSH key agent.
If the key is protected by a password,
the user only needs to enter the password once
and the agent will automatically authenticate that user.
Another file you're going to look into
is the /etc/ssh/sshd_config file.
And this is used to configure an SSH server
on your Linux system.
Now, some of the settings you're going to configure here
include things like the password authentication setting,
which is used to enable
or disable password-based authentication.
You can also configure the PubkeyAuthentication setting,
which enables or disables
the use of public key-based authentication.
You can also configure the Hostkey setting,
and this is used to reference the locations
of the server's private keys.
You can configure the UsePAM setting,
which is used to enable or disable support
for pluggable authentication modules,
known as PAM or P-A-M.
There's also a Port setting
that's going to be used to change the port number
to buy the SSH service to a particular port.
By default, this will be on port 22,
but you can actually set it to any port you want.
You can also configure your SyslogFacility setting,
and this is used to change the logging level
of the SSH events over to your syslog server.
You can also configure your ChrootDirectory setting,
which is used as a reference point for a chroot jail path
for a giving user.
You can go ahead and set up your AllowUsers
or AllowGroup settings.
And this enables user-specific access
to be allowed for specific users or groups over SSH.
In converse to that,
you could set up the DenyUsers or DenyGroup settings,
which is used to restrict or block certain users or groups
from accessing your server using SSH.
And finally,
you can configure the PermitRootLogin setting,
which is used to enable or disable
the ability for the root user to log in over SSH.
As a good security practice,
you usually want to disable the ability for the root user
to log in over SSH,
because that is considered dangerous.
All right, now, in addition to allowing
or denying users and groups,
you can also deny connections to the SSH server itself
that come from specific hosts.
This is done by wrapping the SSH service
in what's known as a TCP Wrapper.
This is going to give you the ability
to check which hosts are explicitly allowed or denied
before permitting that host to connect your SSH service.
To be able to configure this,
you could specify the host that you want to allow
inside the /etc/hosts.allow file
and the host that you want to deny
inside the /etc/hosts.deny file.
Next, let's talk a little bit more about PAM,
the Pluggable Authentication Modules.
Now, Pluggable Authentication Modules
are used to help applications make the proper use
of user accounts inside of Linux.
This is going to separate the standard
and specialized tasks of authentication
from the applications themself.
Programs like Login, GDM, SSHD, and FTPD, and many others,
all want to know that a user is who they say they are,
and there's a lot of different ways to do that.
A user could provide a username and password credential
for each individual service
or they can authenticate remotely
with an LDAP or Kerberos server.
Now, PAM is really pluggable
in the way that it can have different applications
running different tests and modules
in a way that we can now add different methods
with new libraries for authentication.
Now, as I said,
LDAP is one of the common ways we can do this.
And one of the most popular implementations of LDAP
is Microsoft's Active Directory
if you're running a Windows domain environment.
Now, Active Directory is primarily going to be implemented
within Windows,
but Linux systems can still leverage
pass through authentication over to those systems
by forwarding their Active Directory credentials
through PAM.
For example,
you can configure a System Security Services Daemon or SSSD
to cache the credentials provided by Active Directory
or another external authentication mechanism.
And then SSSD can then be used with PAM
to manage those identities.
PAM configuration files are going to be located
inside the /etc/pam.d directory.
And each PAM-aware service or application
is going to have its own file inside that directory.
Now, each of these files are going to include directives
and these directives are formatted as four different things,
the module interface, the control flag,
the module name, and the module arguments.
The module interfaces are going to define the functions
of the authentication and authorization process
that are contained within a given module.
The control flags indicate what should be done
upon a success or failure of that module.
And the module name is going to find the module
that the directive is going to apply to.
While the module arguments are additional options
that you can pass into that module.
For example, let's say I was setting up
a password policy directive.
I would set that up
by using four different pieces of information.
Password required pam_cracklib.so retry=5.
Notice here, the module interface is known as password.
This indicates that this directive
is pertaining to changing passwords.
The required control flag
means that the result of the module must be successful,
otherwise, the authentication process is not going to continue.
The pam_cracklib.so module contains the functionality
that prompts a user for a password,
and then test that password to see if it's easily cracked
in a dictionary attack.
And the retry=5 argument gives the user five chances
to fail this dictionary test before locking them out.
Now, there are four module interfaces inside of PAM
that we need to discuss.
The first one is the account module.
Now, the account module interface
is going to check to see if a user
is allowed access to something.
For example, it might check if a user account is expired
or is allowed to log in at a particular time of day.
Auth is our second one.
Now, auth is used to verify passwords
and set credentials such as Kerberos tickets.
The password interface is our third one,
and this is used to change and verify passwords.
On the other hand,
the session interface is going to configure
and manage user sessions.
Modules with this interface
can also perform additional tasks
that are needed to allow access,
like mounting a user's home directory
and making the user's mailbox available.
Now, all PAM modules are going to generate a success
or failure result when they're called.
The control flags tell PAM what to do with that result.
Since the modules can be stacked up in a particular order,
control flags need to decide how important
the success or failure is of a particular module
in the overall goal of authenticating the user
to a given service.
Now, there are four predefined control flags,
these are optional, required, requisite, and sufficient.
The optional control flag
shows that the module result is ignored.
A module flagged as optional
only becomes necessary for successful authentication
when there are no other modules referencing that interface.
When you're using a required flag,
this module result must be successful
for the authentication to continue.
If a required module result fails,
the user is not going to be notified
until the results on all modules
that reference that interface have been completed.
The requisite flag is going to be considered the same
as required,
however, the requisite module, if it fails,
is going to notify that user immediately
with a message reflecting the first failed
required or requisite modules.
And the final one we have is sufficient.
The sufficient control flag
means that the module result is going to be ignored
upon a failure.
Now, in addition to the prior dictionary test example
I gave you with passwords,
there's other examples of PAM password policy directives
that we can look at.
For example, if we type,
password requisite pam_pwquality.so local_users_only,
this would allow a module to require the user
to enter a strong password.
This means we want a high password quality,
which means we're going to have to have a long,
strong password for it to meet this requirement.
Another one we might have would be something like,
password requisite pam_pwhistory.so remember=90.
This would actually enforce a password history
so that users don't reuse old passwords
when they're changing theirs.
In this case, the password must be remembered
for at least 90 days,
because we're having this 90-day lockout history
being applied by this requisite requirement.
Now, conversely,
if we wanted a module to not do any password checks,
we can do that too
by pulling in the password
that's already been checked for a prior module.
We can do this by using,
password sufficient pam_unix.so sha512 use_authtok.
Now, there's also two PAM modules you should be aware of
that can actually trigger a temporary user lockout
if multiple authentication attempts are attempted
and they fail.
These are known as pam_tally2 and pam_faillock.
Now, pam_faillock is a module
that we're recommending you use,
because it's a newer module
that improves upon the older pam_tally2
by supporting user lockouts,
even if they're trying to authenticate
over a screensaver on newer systems.
To be able to place these user lockout directives
into your files,
you need to put them in two places.
The first is /etc/pam.d/password-auth
and the second one is /etc/pam.d/system-auth,
because you want to make sure you're applying this
against both password authentications
and system-based password authentications.
If somebody has locked themselves out
because they've logged in wrong too many times,
you can unlock that user and reset their failure count
by issuing the command, pam_tally2 -r -u and their username.
Now, you can also configure PAM to use LDAP
by leveraging the pam_ldap module.
And so if you're integrating this Linux system
in a Windows-based domain environment,
then you're going to want to use the pam_ldap module.
By using this module,
you can specify other directives
that restrict what users can log into
and how they can access different resources on the network.
If they meet the criteria that you set up in the module,
then the pam_ldap module can authenticate the user
with the LDAP service.
You can add these directives
into the /etc/pam.d/common file.
Now, I mentioned before that you don't want people
to log in as the route user over SSH,
and this is because anytime somebody can operate
as the root user,
either over SSH or into a terminal directly on the system,
this can be a huge security risk,
because if they have root access,
they can essentially issue any command on the system
and the system is going to do it.
To help prevent this,
you're going to go into the file known as /etc/securetty.
By configuring this file,
you can leverage the pam_securetty module
to determine what controlling terminals
the root user is allowed access to.
This means you can allow root
to only log in on a certain workstation or server
and not on the other ones.
And this gives you a higher level of security
by using least privilege.
Now, the next thing we're going to talk about is PKI.
And I mentioned Public Key Infrastructure
a little bit earlier,
but we're going to dive a little deeper now.
Now, a PKI or Public Key Infrastructure
is really just a system that's composed
of certificate authorities, certificates, software,
services, and other cryptographic components
for the purpose of enabling authenticity
and validation of data and entities.
The PKI system can be implemented
using various hierarchical structures
and can be publicly available
or maintained privately by your organization.
Now, you learned a lot about PKI
back in your security plus studies,
so we're not going to focus on how PKI works,
but in this lesson,
we're going to talk more about how you can implement PKI
using your Linux system.
Now, there are many cryptographic components
that make up the PKI system,
and some of the most important components
include digital signatures, digital certificates,
certificate authorities, and certificate signing requests.
A digital signature is a message digest
that has been encrypted with the user's private key.
Asymmetric encryption algorithms
can also be used with hashing algorithms
to create these digital signatures.
A digital certificate is an electronic document
that associates credentials with the public key.
Both users and devices can hold these certificates.
Now, the certificate is going to validate
the certificate holder's identity
through a digital signature.
It's a way to distribute the holder's public key
in a safe and secure manner.
Now, certificate authority is the server
that's going to issue the digital certificates for entities
and it maintains the associated
public and private key pairs.
Now, a certificate signing request or CSR
is a message that you're going to send to the CA
or certificate authority
in which the entity is going to apply for their certificate.
Typically, this is going to include the information
that should go into the entity's certificate,
like it's public key, digital signature,
and other identifying information.
Now, OpenSSL is an open-source implementation
of the SSL and TLS protocol
and it's used for securing data in transit
using cryptography.
On Linux, the OpenSSL command is an interface
to accessing a variety of OpenSSL features.
It's also one of the most common tools
for generating and managing components of a PKI system.
Using OpenSSL,
you can generate public and private keys,
generate self-signed digital certificates
in various formats,
generate digital certificates for other entities
based on CSRs or Certificate Signing Requests,
as well as calculating the hash values
using various functions,
encrypting and decrypting data using various algorithms,
managing keys and certificates in a certificate authority,
and much more.
The OpenSSL command can be used interactively
through one of several sub-commands
or you could provide these sub-commands
and any options non-interactively.
To open up the OpenSSL command,
simply type in openssl, the sub command you want to use,
and the options you want to use.
Now, in order to authenticate clients
and encrypt data in transit,
we often are going to use VPNs.
VPNs employ many different types of tunneling protocols,
depending on how you configure your system.
One of the most prominent and most used protocols
for site-to-site connections is known as IPsec
or Internet Protocol Security.
Now, IPsec is a set of open and non-proprietary standards
that can be used to secure data
as it travels across the network or across the internet.
It's going to use different protocols and services
to provide data authenticity and integrity,
anti-replay protections, non-repudiation,
and protection against eavesdropping and sniffing.
IPsec a has two primary modes of operation,
transport mode and tunnel mode.
In transport mode,
only the packets contents are going to be encrypted,
but the header itself is not.
When you're using transport mode
is typically going to be used for remote access to VPNs.
Now, when you use tunnel mode, on the other hand,
both the packet and its header are going to be encrypted.
Tunnel mode is typically used
when you're doing site-to-site VPNs.
Now, one popular utility for implementing IPsec tunnels
for VPN clients is known as StrongSwan,
and you can download this using the StrongSwan package.
With StrongSwan,
you can set up user names and password authentication
or you can generate a digital certificate
as a method of authenticating as well.
The main configuration file for StrongSwan
is located in the /etc/strongswan/ipsec.C-O-N-F file.
And the user accounts are going to be configured
inside the /etc/strongswan/ipsec.secrets file.
SSL and TLS is another method you can use
to create a VPN connection.
By using SSL or TLS,
you can handle the authentication and encryption
using the SSL or TLS tunnel,
and this is primarily used for remote access connections.
Now, unlike IPsec,
SSL and TLS is considered an application-layer
or layer-seven protocol in the OSI model,
and therefore,
it's dependent on the applications you're using
to make it work properly.
Now, on Linux, the most popular one we're going to use
is known as OpenVPN.
OpenVPN supports password-based, certificate-based,
and smart card-based authentication mechanisms
for your Linux clients.
For certificate-based authentication,
OpenVPN can generate self-signed certificates
or it can leverage certificates
that are issued from an existing certificate authority.
OpenVPN is available by downloading the OpenVPN package
and installing it on your system.
To configure it,
you can go into /etc/openvpn as a directory
and you'll find the configuration files there.
The next thing we need to talk about is DTLS.
Now, DTLS is the Datagram Transport Layer Security protocol,
and essentially, this implements SSL or TLS over datagrams,
which means we're using UDP instead of TCP
as our transmission protocol.
Now, because we're using UDP instead of TCP,
this means that DTLS traffic is not susceptible
to the same delays that TCP traffic normally has.
This will give you a better overall performance
than using a VPN over a TCP connection,
because UDP does tend to be much faster.
Now, when you're setting up remote access,
there's a couple of issues that you may run into
where your users cannot successfully authenticate.
When this happens,
you need to make sure
that these users have set up the proper credentials
for their accounts
and that they're transmitting those credentials
to the server they're trying to connect to,
whether that's SSH, VPN,
or some other external authentication server.
For example, if you're using a public key
SSH authentication environment,
users have to have the correct key pair
in their home directory,
as well as place the SSH server
in their list of known hosts.
If they don't do that, they're going to get connection errors.
You should also check to see
if their remote connection attempts
are triggering a policy violation.
For example, if they're trying to use a password
when your configuration file says
you must use public key authentication only,
that's going to cause an error for them.
If remote access is still having issues,
try signing on to the account locally
to see if it's a service issue
or if it's some other kind of networking issue.
Also, you can test to see if it's a local issue
by ensuring the account is active and not expired
and that their password is still valid.
If the users are authenticating through an external service
like a Kerberos or RADIUS or TACACS server,
you should always ensure the user entities
are correctly configured in those services
and those servers as well
and that they're available over the network.
These days, remote access is a huge attack vector
against our organizations.
So you want to make sure that you're protecting
all of your privilege access management in some way.
There's lots of violations
of privileged access management policies,
such as failures to configure the account
with a suitably strong password or other things like that.
Remember, if you have lax PAM policies,
this is going to be a leading cause
of unauthorized users accessing your resources
that they really shouldn't have access to.
And this indicates
that you need to tighten up your policies.
It's critical that you really put some importance
on your privileged access management
and use your PAM modules properly
to ensure that you have a tight and secure network
that can be used by your authorized users.