Chapter 15 Concepts

Multifactor Authentication best practices

having multilayer authentication is better than just a password. biometrix, passcode, etc.

Bootloader passwords best practice

Another level of passwords can be set in a bootloader, such as GRUB. These passwords help prevent others from booting to Linux and entering single useer mode.

Install or verify that TCP wrappers package is installed

Ensure that the TCP wrappers package (tcpd) is installed with 'rpm -q' or 'dpkg -d' commands. If not, use dnf, zypper, or apt-get to install it

CVE best practices

Finally, you should also monitor the Common Vulnerabilities and Exposures system, which is maintained by the US government. It's a reference for publicly known security vulerabilities. There are applications and scripts that can automate this task and make recommendations to mitigate vulnerabilities.

Type in /etc/security/limits.conf

For the type: 1. Use hard to set a limit that cannot be exceeded 2. Use soft to set a limit that can be exceeded temporarily.

Protocols best practices

Protocols define basic rules for exchanging ingo, and they can become unsecure too. Older protocols may lack encryption, making it easy to sniff credentials on the network. Some of these protocols are FTP, HTTP, IMAP, Telnet, Finger, Send,ail, and Postfix. Avoid using these protocols for services that share sensitive data.

PKI and SSH best practices

Public Key Infrastructure has all the hw, sw, and people necessary to support the creation and distribution of digital certs. Certs are required to enable SSL and TLS cryptographic security protocols to secure communication. One of the benefits of using PKI is that you can set up password-less SSH logins by distributing a server SSH cert.

Restart xinetd

Restart the xinetd to enforce the changes made to the /etc/xinetd.d daemon file(s). Complete by using the command 'service inetd restart'.

'scp'

Securely copies the client's pub key file to the server

Ports best practices

To increase security, you can change the default TCP and UDP ports for commonly used services and apps.

/etc/security/limits.conf

Us the /etc/security/limits.conf file to limit resouce utilization by users. This file is from the pam_limits module of the Pluggable Authentication Modules (PAM) module set. Entries in the /etc/security/limits.conf use the following syntax: Domain Type Limit Value

Confirm TCP wrapper configuration

Use 'tcpdchk' to test and display any potential or real problems with the TCP wrapper configuration. 'tcpdchk' compares the /etc/hosts.deny and /etc/hosts.allow files against the configuration files.

AppArmor Modes

1. *enforce* - When using this mode, the setting specified in the profiles will prevent apps from taking any restricted actions 2 *complain* - This mode, AKA the "learning mode," uses the profiles loaded, but they are not enforced. Instead, any policy violation attempts are stored in a log file. This is useful, for example, when you want to test an AppArmor profile, because it lets you see any errors that would occur in enforce mode which would be helpful for fine tuning the profile.

Commands and files to enable public key authentication

1. /etc/ssh/sshd_config or /etc/ssh/sshd.config 2. 'ssh-keygen' 3. 'scp' 4. 'ssh' 5. 'cat' 6. 'ssh-agent bash' and 'ssh-add' 7. 'ssh-copy-id'

Disable Ctrl+Alt+Del best practices

Anyone that has a physical access to the keyboard can type Ctrl+Alt_Del to reboot the server without having to log on. Consider disabling this key combination. Doing so also prevents accidental reboots.

Key facts of SSH

Be aware that SSH: 1. Uses a public and private key pair to encrypt and transfer a symmetric key that is then used by both hosts to encrypt and decrypt transmissions during the SSH session. The public key is available to all users. The private key is kept secure and is never shared. 2. Can use associated key management sw and scripts to automate the exchange of public keys. 3. Can be used to create a secure tunnel through which other unsecure network protocols, such as IMAP, POP3, SMTP, and X server traffic can be transmitted. 4. Is available in two versions: -- SSH version 1 is an older, less secure version of SSH. SSH1 only supports RSA encryption. -- SSH version 2 (SSH2) is the current standard SSH implementation. It can use either DSA or RSA encryption.

xinetd Key Facts

Be aware that the xinetd daemon: 1. Starts and stops network daemons as necessary to provide port security and conserve resources 2. Receives requests for network services from client computers 3. Acts as an intermediary between the user requesting a network service and the actual daemon that provides the service 4. Can be configured to grant and deny access to specific services based on the IP address of the computer making the request. This is done using a separate package called TCP wrappers. 5. Increases server latency and might not be optimal for servers with very high request volumes. 6. Must be restarted after configuration changes.

'ssh-agent bash' and 'ssh-add'

Configures the client to automatically provide the private key passphrase when needed so that it does not have to be typed for every new connection to a server. 1. Use *ssh-agent bash* to enable passphrase agent. 2. Use *ssh-add* to specify the name of the private key to add to the agent. For protocol 2, this is one of the following: -- *~/.ssh/id_rsa* -- *~/.ssh/id_dsa* After the *ssh-add* command, enter the passphrase when prompted. The passphrase stays in memory while the user is logged in to the client.

'ssh-copy-id'

Copies the pub key of your default ID to the remote host using *ssh-sopy-id [email protected]*. If you have only one ssh key, you do not have to ener your ID.

'ssh-keygen'

Creates a key on the client to use when authenticating to a server. *'ssh-keygen'* options include (default is RSA): 1. *'-t dsa'* creates a DSA key pair (e.g., id_dsa and id_dsa.pub). 2. *'-t rsa'* creates an RSA key pair (e.g., id_rsa and id_rsa.pub).

Packet Loss (DTLS)

DTLS adds a simple retransmission timer allowing it to retransmit packets without relying on the transport protocol.

Login Blocking Process

Force all users to log out of the system: 1. Log in directly as the root user. 2. Use the 'w' command to view all active user accounts 3. Use 'pkill -KILL -u [username]' to force the user to log out for each active user. Disable the ability to login to the system: 1. Create the /etc/nologin file 2. Add a message to the file that will be displayed to users when they attempt to log in. ** Rename or delete this file to re-enable logins

'ssh'

Logs in to the server

Authenticate using a public key

Public key auth uses a public key instead of a username and password to authenticate an SSH connection. The following method is used to authenticate using a public key: 1. The client specifies which pub key the server uses for auth. Then, the server checks to ensure the key has previously been authenticated to the server. 2. If the key is known to the server, it encrypts a random number with the pub key and sends the encrypted number to the client. 3. The client decrypts the number with a private key and uses its own pub key and the random number to create a hash (MD5 checksum). The client sends the hash back to the server. 4. The server uses the public key and the random number to create its own hash (MD5 checksum) and then checks whether both hash values match. 5. If the hashes match, the server grants access to the user. If the hashes do not match, the user is prompted to log in using a password.

Runas_Alias

Specifies a username that is used when running commands with 'sudo'. Usually, this is just root.

Steps to use TCP wrappers to restrict daemon access

TCP wrappers (tcpd) use the IP addresses of incoming network packets to allow or deny access to computers or daemons. Xinetd can use tcpd to restrict access to enabled daemons. To use tcpd with xinetd, consider: 1. Install or verify that the TCPwrappers package is installed 2. Edit the daemon files in /etc/xinetd.d 3. Restart xinetd 4. Modify tcpd control files 5. Confirm TCP wrapper configuration

Commands to manage root-level access

The following commands are used to manage root-level access to the system: 1. 'su' 2. 'exit' 3. 'logout'

USB storage devices best practice

USB storage devices can be an entry point for unwanted files, malicious scripts, and other sw to enter a system. You should discourage users from using USB stroage devices. Additionally, you can disable USB storage support by rmoving the storage driver.

Domain in /etc/security/limits.conf

When specifiying the entry: 1. Specify a single user with a username 2. Use an ampersand (@) 3. Use an asterisk (*) as a wildcard

/etc/pam.conf

When using PAM, the system admin is free to choose how individual service-providing apps will authenticate users. This dynamic is set by the contents of the single Linux-PAM configuration file: /etc/pam.conf. Alternatively, the configuration can be set by individual configuration files located in the /etc/pam.d/ directory. The presence of this directory will cause Linux-PAM to ignore /etc/pam.conf.

'aa-disable'

disables one or more profiles. This command will unload the profile from the kernel and prevent the profile from being loaded on AppArmor startup. The *'aa-enforce'* and *'aa-complain'* utilities may be used to change this behavior. This command also moves the profile from the /etc/apparmor.d directory to the /etc/apparmor.d/disable directory.

'aa-complain'

is used to set the enforcement mode for one or more profiles to the complain mode. In this mode the security policy is not enforced but instead, access violations are logged to the system log. Note that *deny* rules will be enforced even in complain mode. This is often used to help troubleshoot apps being protected with AppArmor.

cron and at

Another vulnerability is the use of the cron and at commands. Malware often uses these utilities to make sure malicious code persists even after it's been removed. Normally, these commands are only available to Linux admins. You should monitor your cron and at jobs and consider restricting access to these commands.

LADP Integration

Lightweight Directory Access Protocol is an app protocol used over an IP network to manage and access the distributed directory info service. When authenticating a user, pam_ldap first maps the user's login name to a distinguished name by searching the directory server. This must be possible using the local system's identity, which is specified in pam_ldap.conf. To authenticate a user, pam_ldap attempts to bind the directory server using the distinguished name of the user (retrieved previously). Both simple and SASL authentication mechanisms are supported; in the former case, one should take care to use trasport security to prevent the user's password being transmitted in the clear. Pam_ldap stores its configuration in the pam_ldap.conf file. See your man pages for the configuration options available for your distro.

Check for unneeded network services

Unneeded network services waste the computer's resources and might provide attackers with an entry point for an attack. To view a list of installed services, use one of the following commands: 1. for init-based systems, run 'chkconfig' at the shell prompt 2. for systemd systems, run 'systemctl list-unit-files' at the shell prompt. Review the output of these commands and look for unusual or unrecognized services. Then use the man command and the internet to determine whether they can be safely removed or disabled. Use 'chckconfig', 'insserv', or 'init' to disable the service on init-based systems. On systemd distros, you can use the 'systemctl disable' or the 'systemctl mask' command to disable a service. Alternatively, you could use yum, zypper, rpm, or dpkg to remove the package entirely.

Remove unneeded software

Unneeded sw takes disk space and could introduce security risks. To remove unneeded sw: 1. Run one of the following commands: -- Use 'dnf list installed' to see installed RPM packages on the computer -- use 'dpkg -get-selections' to see installed Debian packages on the computer 2. Research the function of any unrecognized package to determine whether it is necessary. 3. Use yum, rpm, or dpkg to uninstall unneeded packages.

xinetd Configuration files

Use the following to configure the xinetd super daemon: 1. /etc/xinetd.conf 2. /etc/xinetd.d

auditd best practices

You can enable auditd to monitor log files and audit access to system files, directories, and resources. The auditd utility can also monitor apps misconducts or code malfuntions. You can configure a set of rules to ensure any security policy violation is addressed.

Network and system security configuration with /etc/sysctl

You can harden your Linux network and system setting using 'sysctl'. The 'sysctl' command is used to modify kernel parameters at runtime. /etc/sysctl.conf is a text file containing sysctl values to be read in and set by sysctl at boot time.

'aa-status'

displays a list of the AppArmor modules that are loaded, and which ones are running in enforce mode and which ones are running in complain mode.

'aa-enforce'

sets one or more profiles to enforce mode. This command is only relevant in conjunction with the *'aa-complain'* utility which sets a profile to complain mode and the *'aa-disable'* utility which unloads and disables a profile. The default mode for a security policy is enforced and the *'aa-complain'* utility must be run to change this behavior.

Message fragmentation (DTLS)

Fragmentation occurs when a packet datagram is too large to fit within th max transmission unit (MTU). DTLS provides fragmentation offset and length values in the DTLS message. This ensure that both ends of the communication have provided fragmentation info regardless of the underlying transport.

Message reordering (DTLS)

If a packet arrives out of order and is not reassembled correctly, the packet cannot be decrypted properly. DTLS adds sequence numbering to the app, allowing it to not be dependent on the underlying transport tech.

SSH root login best practices

It's important that you disable root login via SSH. This is usually the configuration when SSH is first installed.

Commands used to audit

1. 'find / type f -perm': audits files that pose a security risk. -- '-o=x': audits for the execute permission for others -- '-o=w': audits for the write permission for others -- '-g=x': sudits for the execute permissions for group owners -- '-g=s': audits for the SGID bit -- '-u=s': audits for the SUID bit Include the -ls option to display the results with the long listing. 2. 'crontab -e': Schedules the auditing task to run on a regualr basis.

*'openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout /etc/ssl/private/my-selfsigned.key -out /etc/ssl/certs/my-selfsigned.crt'*

1. 'openssl' - The command used for creating and managing OpenSSL certs 2. 'req' - Specifies that the X.509 certificate signing request (CSR) will be used. X.509 is a pub key infrastructure standard that SSL and TLS adheres to for its key and cert management. 3. '-x509' - Specifies that the cert being created will be a self-signed instead of a signed cert. 4. '-nodes' - Specifies that openssl should skip the option to secure our cert with a passphrase. This allows a connection to the server (such as an Apache Web Server) without user intervention. 5. '-days [xxx]' - Specifies the new length of time that the cert will be considered valid, where [xxx] is the number of days. 6. '-newkey rsa:2048' - Specifies that a new cert and new key will be created at the same time. The 'rsa:2048' portion tells it to make an RSA key that is 2048 bits long. 7. 'keyout' - Specifies the directory and filename for the private key being created. 8. '-out' - Specifies the directory and filename for the self-signed key being created.

MOTD best practices

A login banner or message-of-the-day is a message that's presented when a user first connects to a Linux machine. A banner that states that only authorized users are allowed might not deter malicious users, but the banner is also there for legal and privacy reasons. The banner should also inform the user that their actions on the system may be monitored.

chroot jail SSH best practices

Another technique to secure SSH is to shroot jail the SSH service. You can also do this with other services. The chroot jail notion uses the chroot command to rmeap the root directory to include only certain directories and files. This makes it harder for malicious users to gain access to other sensitive info.

Understanding AppArmor profiles

AppArmor is a MAC method used to protect your Linux system from untrusted or insecure processes. It does this by locking down an application and the files to be accessed with absolute path names, followed by the common read and write access modes. In other words, the Linux kernel queries AppArmor before eact system call to determine whether the process being requesteed is authorized to do the given operation. To accomplish all of this, AppArmor applies a set of rules, known as a profile, on each program being protected. These plain-text profiles are stored in the /etc/apparmor.d directory and contain a list of access control rules on the applicable resources that each program can make use of. Additional profiles can be typically downloaded or new profiles can be created using the aa-genprof utility.

AppArmor tunables

AppArmor provides a way to fine tune how AppArmor functions without having to adjust your profiles. The items that can be tuned are stored in files located in /etc/apparmor.d/tunables directory and are text-based files.

'cat'

Appends the pub key to the *~/authorized_keys* file. Be aware of the following: -- overwriting the file deletes all other keys (be sure to use *>>* instead of *>* when redirecting the output of the *'cat'* command) -- If the same user logs in from multiple clients, the file must have all client keys in it. -- Always remove the public key file after appending it to the *~/authorized_keys* file.

SELinux policy modes

In addition to types of policies, SELinux uses modes to control how policies are applied and how access is granted or denied. There are two modes: 1. *Enforcing* mode allows or denies access based on policy rules. Any attempted action that occurs on the system that is against the defined policy is blocked and logged. 2. *Permissive* mode allows access even if the access violates SELinux policy rules. However, it does log any action that violates policy rules. ** Use permissive mode to troubleshoot or test a new SELinux system, or one that you've changed. You can switch between the two modes without a system reboot.

Limit in /etc/security/limits.conf

Limts include: 1. core limits the size of core dump files (in KB) 2. data limits the amount of RAM an app can use (in KB) 3. fsize limits the max file size (in KB) 4. nofile limits the number of concurrently open data files 5. stack limits the stack size (in KB) 6. cpu limits the amount of CPU time a process can use (in minutes) 7. nproc limits the number of concurrent processes a user can have 8. maxlogins limits the number of concurrent logins 9. priority sets process priority limits. The value range is from -20 (highest priority) to 19 (lowest priority) with 0 being the default. 10. nice sets the lowest nice value a user is allowed to set a process to. 11. rss limits the total amount of memory a user can use (in KB)

Modify tcpd control files

Modify the following tcpd control files to determine which computers can access the services: 1. /etc/hosts.deny denies services to the specified host(s) or subnets. 2. /etc/hosts.allow permits services to the specified host(s) or subnets. Be aware that: -- The /etc/hosts.allow file is read first and applied before /etc/hosts.deny. -- In each of these files, the search is stopped and all remaining rules are ignored if tcpd finds a matching rule. Both files have this syntax: -- Use *service: [ipaddresses]* to specify the host(s). -- Use *service: [subnet]* to specify a subnet

AppArmor status commands

Most of the commands must be run using root permissions. If you are not logged in as root, you can use 'sudo' to gain root permissions. 1. *'systemctl status apparmor'* checks the status of the AppArmor service and also tells you if AppArmor is enabled on boot. 2. *'systemctl start apparmor'* - use this command to start the apparmor service 3. *'systemctl enable apparmor'* - this command configures AppArmor to start each time your system is booted.

Authentication technologies

Once a user has authenticated and logged into a Linux system, there are several techs and protocols that allow the user to access other resources beyond the local computer. These include RADIUS, TACTACS+, LDAP, and Kerberos. 1. RADIUS, the Remote Authentication Dial-In User Service, provides centralized authentication. A RADIUS server can act as a proxy client to other kinds of authentication servers. 2. TACTACS+ (the Terminal Access Controller Access-Control System Plus protocol), is similar to RADIUS. 3. With Lightweigh Directory Access Protocol (LDAP), the user authenticates to an LDAP server to access directory info about users, computers and services in a network. 4. The Kerberos protocol is based on tickets that allow nodes communicating over a non-secure network to prove their identity. -- The kinit shell command authenticates with a Kerberos server -- The klist command lists the Kerberos tickets held in a credentials cache.

Locate open ports

Open ports can provide info about what os a computer uses and can provide entry points for an attack. To locate open ports: 1. Install the 'nmap' utility 2. Udse one of the following commands to scan for open ports: -- 'nmap -sT [host_IP_address]' scans for open TCP ports -- 'nmap -sU [host_IP_address]' scans for open UDP ports 3. From the results of the scan, determine which ports to close and which services use the ports. 4. Disable the services using those ports. 5. Consider changing default port assignments to different ports ** Consider running 'nmap' on the local system as well as from a different network host. This will reveal what ports are open and which services are actually allowed through the host's firewall.

Services best practices

Services can become unsecure when there's weak or nonexistent authentication or encryption. This also happens when services run as root. Be sure to use safe authentication methods and encryption, especially when dealing with sensitive info. Also, if you find a service is not being used or is vulnerable, consider disabling or uninstalling.

Cmnd_Alias

Specifies a set of commands that users can execute using the 'sudo' command.

User_Alias

Specifies a set of users who are allowed to execute a specific set of commands using the 'sudo' command.

/etc/ssh/sshd_config

The /etc/ssh/sshd_config file configures the SSH daemon on the server. Commonly used uptions fro the configuring an SSH tunnel include: -- *AllowTcpForwarding* allows TCP traffic to be sent from the SSH daemon when set to *yes* -- *ForwardX11* specifies that clients to which requests are forwarded are regarded as untrusted, and have restricted access to certain GUI features. -- *ForwardX11Trusted* specifies that clients to which requests are forwarded are regarded as trusted, and have unrestricted access to all GUI features. -- *X11Forwarding* Is used on some distros instead of *ForwardX11Trusted*. -- *VNC* allows any computer to act as a graphical terminal server that supports multiple desktops and multiple users.

PAM Overview

The Linux Pluggable Athentication Modules (PAM) provide dynamic authentication support for applications and services in a Linux system, such as 'login' and 'su'. PAM separates the tasks of authentication into four independent management groups: account management, authentication management, password management, and seesion management. In other words, these groups take care of the different aspects of a typical user's request for a restricted service.

/etc/nologin

The auth requisite pam_nologin.so line in the /etc/pam.d/login file configures PAM to check if a file named /etc/nologin exists. If /etc/nologin does exist and the user is not root, authentication is blocked and an optional message is displayed to the end user.

Parameters you can use with sysctl

The parameters available for sysctl are listed under /proc/sys/. Procfs is required for sysctl support in Linux. You can use sysctl to both read and write sysctl data. 1. variable: The name of a key to read from. An example is kernel.ostype. 2. variable=value: Variable is the key and value is the value to set it to. If the value contains quotes or characters which are parsed by the shell, enclose the value in double quotes. 3. -n: This option disables printing the key name when printing values 4. -q: This option prevents displaying the values sent to stdout 5. -w: When all arguments prescribe a key to be set, use this option 6. -p[file]: This option loads sysctl settings from the file specified or /etc/sysctl.conf if a file name is not given. Using this option indicates arguments to sysctl are files. The files are read in the order they are specified.

Security Guidelines

To protect the root user account, use the following guidelines: 1. When performing tasks that require the root user account, use the 'su -' command to switch to the root user and execute the command and then use the 'exit' command to revert back to the regular user account. 2. As a general rule, create a user account that gives sufficient permissions to perform most daily tasks. Use this account instead of the root user account when logging in to the system.

VPN access and auth

VPNs are most commonly used by employees who are working remotely, yet require access to their company's network resources, and by companies that want to maintain a secure connection between remote sites. The soctware required to connect your Linux client to a VPN may vary depending on the type of VPN to which you are connecting. After contacting your VPN provider, you can check your local system to see if the correct software is installed. If not, go to the sw installer app and search for the NetworkManager package which works with your VPN and install it. Once installed, you will need to create a new VPN network, configured to the specs of your VPN to which you are connecting.

Value in /etc/security/limits.conf

Values include integers, such as 1, 5, or 3000.

SELinux policies

When SELinux is enables, policies are used to determine how and what items are protected. Policies are a set of rules that guide the SELinux security engine. There are two types of policies: 1. Targeted policies apply access controls to certain (targeted) processes. Targeted processes run in a confined domain. Processes that are not targeted run in an unconfined domain. 2. Multi-Level Security (MLS) policies specify multiple levels of access. MLS applies labels to files, processes and other system objects to control the flow of info between security levels. Each level has different rules for user access. Labels for security levels might rang from top secret to unclassified.

tty Security

When a root user attempts to log in to a system using tty, the pam_securetty module uses the /etc/securetty file to decide which virtual terminals (tty#) root is allowed to log in from. In older distros, /etc/securetty was referenced by programs like login directly, but PAM handles this on its own. Therefore, changes to the /etc/securetty file affect anything using PAM with a configuration file that uses pam_securetty.

Using pam_faillock

You can lock a user's account for failed password attempts using the pam_faillock module. This is accomplished in a similar fashion by adding the required lines to the same two files used with pam_tally2; /etc/pam.d/system-auth and /etc/pam.d/password-auth. 1. For both files, add the following in the "auth" section: 'auth requred pam_faillock.so preauth silent audit deny=3 unlock_time=900 auth [default=die] pam_faillock.so authfail audit deny=3 unlock_time=900' 2. For both files, add the following in the "account" section: 'account required pam_faillock.so' -- the options are: 'audit' (enabling user auditing), 'deny=' (used to define the number of attempts, after which the user account should be locked), and 'unlock_time=' (sets the time in secconds for which the account should remain locked.

Syntax in /etc/pam.conf

1. 'required' - Failure of a PAM will ultimately lead to the PAM-API returning failure but only after the remaining stacked modules (for this service and type) have been invoked. 2. 'requisite' - Requisiste is similar to required; however, if a module returns a failure, control is directly returned to the app or the superior PAM stack. 3. 'sufficient' - If a module succeeds and no prior required module has failed, the PAM framework returns success to the app or to the superior PAM stack immediately without calling any further modules in the stack. A failure of a sufficient module is ignored, and processing of the PAM module stack continues unaffected.

Commands for configuring and using 'sudo'

1. 'visudo': Opens the /etc/sudoers file for editing. The command opens the vi editor and checks the file for sudo syntax errors before saving and exiting. 2. 'sudo': Executes a command as the root user. To use this command, first type 'sudo' and then type the command as you normally would. 3. 'sudoedit': Allows users to securely edit files. This command is equivalent to running 'sudo -e'. When using 'sudoedit', users edit the desired file as themselves, and not the root account. When run, 'sudoedit' first creates a temp cp of the desired file. Changes are then made to that file. When done, the changes made to the temp files are cp back to their original location, and the temp versions are removed. To use 'sudoedit' to limit users in the managers group to edit a specific file, edit the sudoers file and add a 'sudoedit' line similar to the following example: '%managers ALL = sudoedit /[path_to_file]' A common implementation of this is to use the wheel group. Most Linux systems that controls access to the 'su' or 'sudo' command. Therefore, to use 'sudoedit' to limit users in the wheel group, add a 'sudoedit' line similar to the following example: '%wheel ALL = sudoedit /[path_to_the_file]'

SELinux commands

1. *'sestatus'* displays a status of a system running SELinux. The info it displays includes: -- SELinux status: enabled or disabled -- Loaded policy type: targeted or MLS -- Current mode: permissive or enforcing 2. *'getenforce'* displays the current SELinux mode: Enforcing, Permissive, or Disabled. 3. *'setenforce'* switches between permissive and enforcing mode. The command syntax is *'setenforce [mode] [value]'*. -- You must have root level permission to run this command. Change the /etc/status.conf to permanently change the mode or disable SELinux. 4. *'getsebool'* displays a list of booleans. Booleans allow you to change part of the SELinux policy at run time without reloading or recompiling the SELinux policy. Enter: -- *'getsebool -a'* to view the value of all booleans. -- *'getsebool [boolean]'* to view the value of the specified boolean. 5. *'setsebool'* changes the current state of an SELinux boolean. -- *'setsebool [boolean_name] [switch]'* turns the specified boolean on or off. -- Add the *'-P'* command to make the change permanant. 6. *'ls'* displays the SELinux context for a specified file by using the -Z parameter. *'ls -Z [filename]'*. 7. *'ps'* displays the SELinux context for all active processes by using the *'-eZ'* parameter.

Error results

1. *type=AVC* indicates this is an SELinux error 2. *avc: denied {creat}* indicates a command to create something was denied 3. *pid=5136* indicates the offending processor id was 5136 4. *comm="gdm-session-wor"* indicates the command issued was 'gdm-session-wor'. (This is the pam authentication backend for both the login process and the screensaver process.) 5. *name="gdm"* gdm is the abbreviation for GNOME 6. *scontext=* The source context for the error was: -- system_u (a system account user) -- system_r (a system account role) -- xdm_t (the type, e.g. the display manager) 7. *tcontext=* The target contxt fro the error was: -- system_u (user) -- object_r (role) -- admin_home_t (type) -- s0 tclass=dir (level)

Steps to establish an SSH connection

1. A client running SSH establishes a connection to any system running the SSH daemon (sshd) over *port 22*. 2. The computers determine which SSH version to use based on the specifications in the conf files. Typically, this is SSH2. 3. The server sends one of the following public keys from the /etc/ssh/ directory to the client: -- *ssh_host_key.pub* (This is the SSH1 public key) -- *ssh_host_rsa_key.pub* (This is the SSH2 public key when using RSA. The associated private key file is *ssh_host_rsa_key*.) -- *ssh_host_dsa_key.pub* (This is the SSH2 public key when using DSA. The associated private key file is *ssh_host_dsa_key*.) 4. When the client receives the public key from the server, it compares the key to the keys it has received and stored in one of the following files: -- /etc/ssh/ssh_known_hosts -- ~/.ssh/known_hosts ** if the key is not present in either of these files, then the client prompts the user to accept and store the key. 5. One of the following occurs: -- If SSH1 is being used, the client generates a 256-bit symmetric key. It then uses the server's public key to encrypte the symmetric key and then sends it to the server. Because the secret key was encrypted with the public key, it can only be decrypted by the server using its private key. -- If SSH2 is being used, the server and the client use the Diffie-Hellman key exchange system to agree on a symmetric key that will be used to encrypt data for the rest of the session. The secret key is not actually transmitted over the network. 6. The data transmitted between hosts is encrypted and decrypted using the same symmetric key.

Possible steps to use the self-signed cert

1. Configure the server to use SSL 2. Adjust the firewall. If you are using the ufw firewall in the enabled mode, you might need to adjust the settings to allow for SSL traffic. 3. Install the self-signed cert in your server such as the Apache Web server. 4. Restart the server. 5. Test the website with https.

File types that pose a risk

1. Executables owned by the root user that have the SUID permission. With the SUID permission, executables will run with the owner permissions, not with the permissions of the user who runs them. 2. Executable files owned by the root group that have the SGID permission. With the SGID permission, executables will run with the group permissions, not with the permissions of the user who runs them. 3. Files that have their write and execute permissions for others (everyone on the Linux system who is not a user or group owner of the file). If the file is writable by others, anyone can replace the file with a malicious script to create a security risk.

When using the /etc/securetty file, consider:

1. If the /etc/securetty doesn't exist, root is allowed to login from any tty 2. If /etc/securetty exists and is empty, root access will be restricted to single user mode or programs that are not restricted by pam_securetty (such as su, sudo, scp, and sftp). 3. Removing a tty# (where # is a number) entry from this file will disable a root user from loggin on using the associated /dev/tty# terminal. 4. A pseudo-terminal (pty) is a pair of virtual character devices that provide a bidirectional communication channel. One end of the channel is called the master; the other end is called the slave. The slave end of the pty provides an interface that behaves exactly like a classic terminal. Adding entries to the /etc/securetty file (such as pts/[0-9]) allow programs that use ptys and pam_securetty to log in into root, assuming the allocated pty is one of the ones listed. Best practice is to exclude these entries because it's a security risk since it would allow, for example, someone to login into root via telnet, whech sends passwords in plain text.

sysctl and settings in /etc/sysctl.conf include the ability to:

1. Limit network-transmitted configuration for IPv4 and IPv6 2. Turn on Exec Shield buffer overflow protection 3. Protect against syn flood attacks 4. Turn on source IP address verification 5. Protect against a spoofing attack on the IP address of the server 6. Log several types of suspicious packets, such as spoofed packets, source-routed packets, and redirects

DTLS workaround components:

1. Message fragmentation 2. Message reordering 3. Packet loss

General Security Procedures

1. Remove unneeded software 2. Check for unneeded network services 3. Locate open ports 4. Check network connections If you have application or hw issues, check to make sure that you have not blocked an essential component in your efforts to increase security. You can check availability: -- Software: use 'dnf list installed' to see install RPM packages, or 'dpkg -get-selections' to see installed Debian packages -- Network services: use 'chkconfig' for init. Use 'systemctl list-unit-file' for systemd. -- Ports: use 'nmap' -- Connections: use 'netstat' -- Protocols or firewall ACLS: use 'iptables -L' for the current firewall configuration or cat /etc/sysconfig/iptables to read the firewall file

SSH Port Tunneling Process

1. The client sends the non-secure protocol info to the port on the server running the SSH daemon 2. The SSH daemon intercepts all traffic sent to that port, encrypts it, and sends it to the SSH client. 3. The SSH client receives the encrypted traffic, decrypts it, and forwards it to the default port for the client. 4. The client receives the data on its usual port.

IPsec modes

1. Tunnel -- The default mode. The entire og IP packet is protected by IPsec, meaning that IPsec wraps and encrypts the og packet and then adds a new IP header which is then sent on to the other side of the VPN tunnel. -- When using VPN tunnel mode and NAT, the NAT info is stripped off and the og IP packet is sent on presercing the digital sig. 2. Transport -- Only the payload of the IP packet is encrypted, and the og IP headers are left intact. Although this lessens the number of additional bytes required to use VPN, it also allows devices on the pubnet to see the final source and destination of the packet. By passing the IP header as unencrypted data, the transport mode allows an attacker to percorm some traffic analysis. The transport mode is often used for end-to-end communications, such as when connecting a client and server.

UEFI/BIOS passwords best practices

A computer's BIOS or UEFI can be configured to require a user to enter a password before it will boot an operating system. This is only a miner deterrent, since you can reset the BIOS or UEFI by removing the motherboard battery, but it can be part of a good security play.

Digital signature vs public keys

A digital signature uses an asymmetric key pair to allow a sender's ID to be verified by a recipient. The sender creates the digital signature with a private key. The recipient decrypts the signature with the corresponding public key to verify the signature. The digital signature provides non-repudiation, meaning that the sender can not repudiate being the sender of the message. Digital signatures do not provide message integrity. Public keys can also verify the integrity of messages sent. To ensure message integrity, the sender of a message creates a hash value for the message being transmitted. This hash value is called a message digest. The sender sends both the message digest nd the message to the recipient. The recipient creates a hash for the message. If the recipient's hash matches the message digest, the integrity of the message is verified.

Creating self-signed certificates

A self-signed cert lets you encrypt communication between your server and a client but is not signed by any trusted certificates are ofted used when you don't have domain name associated with your server where the encrypted web interface is not user-facing. The exact steps to create a self-signed cert will vary from distro to distro. The follwoing is one example of how to create a self-signed cert on Ubuntu. These steps may need to b e modified for other distros. To create a self-signed cert, open a teminal and as root or using sudo, run the following command: *'openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout /etc/ssl/private/my-selfsigned.key -out /etc/ssl/certs/my-selfsigned.crt'*

Asymmetric encryption

AKA public key encryption - uses two keys that are mathematically related. Both keys together for a key pair. -- The public key is made available to anyone; the private key is kept secret. -- Data encrypted with the public key can only be decrypted using the private key. Data encrypted with the public key cannot be decrypted using the same public key. -- The strength of an asymmetric encryption system lies in the security of its private keys. If the private key is ever compromised, a new key pair must be generated. -- Asymmetric encryption is slower than symmetric encryption and is CPU-intensive. Processing speeds are much slower than symmetric key encryption.

Symmetric key encryption

AKA secret key encryption, pre-shared key or private key encryption - uses only one key to encrypt and decrypt data. -- Symmetric encryption is well suited for bulk encryption, because it is less CPU-intensive and much faster than other encryption methods. -- Before communications begin, both parties must exchange the shared secret key using a secure channel. This is often doen manually or with some form of asymmetric key cryptography. -- Each pair of communicating entities requires a unique shared key. -- As the number of bits in the key increases, so does the strength of the encryption. However, the greater the number of bits in the key, the more CPU resources are required to perform the encryption.

SSL

An SSL VPN is a type of VPN that uses the SSL protocol or the TLS protocol to provide secure, remote-access VPN capability (TLS is updated SSL). However, in most cases, TLS is most often used since the internet engineering task force deprcated SSL. Although, TLS is most often used, most still refer to them together as SSL/TLS. The Transport Layer Scurity protocol is an improved version of SSL. It ensures that messages being transmitted on the Internet are private and tamper proof.

/etc/ssh/sshd_config or /etc/ssh/sshd.config

Configures the server to accept public key authentication. Commonly used options for configuring a public key authentication on the server include: 1. *PubkeyAuthentication* enables and disables public key authentication on the server 2. *AuthorizedKeysFile [location]* specifies the location of the file that contains the public keys.

DTLS

DTLS is based on the TLS protocol and provides security for datagram-based apps by allowing them to communicate in a way that is designed to prevent eavesdropping, tampering, or message forgery. The main diff between DTLS and TLS is that DTLS used UDP and TLS uses TCP. TLS relies on TCP to guarantee that the packet was delivered correctly in the event that the packet was fragmented, reordered, or lost. Getting rid of any one of those TCP features would normally break the TLS crypto logic, but DTLS has created its on soluton or workaround for this. One disadvantage of using DTLS, is that the above built-in recovery functions requires additional mem.

Disk encryption best practices

Disk encryption is an effective security practice. Linux Unified Key Setup (LUKS) is an open-source disk encryption sw. It requires a user to enter a password to access data on a disk.

Edit the daemon files in /etc/xinetd.d

Edit and save the /etc/xinetd.d daemon file(s) for the daemon(s) as follows: 1. Comment out the existing *server=* line with the number symbol (#). 2. Add the line *server=/usr/sbin/tcbd* to send requests through the tcpd so it can grant or deny access. 3. Add the line *server_args=[path_to_executable]* to provide the tcpd daemon with the path to the executable file of the service. 4. Set the disable line to *no*.

IPsec

Internet Protocol Security is an extension to the IP protocol and like SSL, also secures sessions between computers by validating and encrypting the packets of data that are sent across a network.

AppArmor management commands

Most of the commands must be run using root permissions. If you are not logged in as root, you can use 'sudo' to gain root permissions. 1. *'aa-status'* 2. *'aa-disable'* 3. *'aa-complain'* 4. *'aa-enforce'* 5. *'aa-unconfined'*

Data Partition best practices

Often, when Linux is installed, an independent partition is added for user data. This keeps the operating system files separated from user data. If the user data partition inadvertently fills up, the Linux system can continue to operate while you consider how to increase user data storage or free up storage by moving or deleting user files. If not already configured, stor user data on a separate partition from system data.

Check network connections

Open network connections (e.g. open sockets) on a computer also create a security risk. A socket is an endpoint of a bidirectional communication flow across a computer network. Use the following 'netstat' options to identify the open network connections on the Linux system: '-a': lists both listening and non-listening sockets '-l': lists listening sockets '-s': displays statistics for each protocol. '-i': displays a table of all network interfaces.

Mandatory access control

SELinux is a kernel security module that provides a strong and flexible, mandatory access control (MAC) system for the Linux kernel. It can be used to enforce access control on resources based on variables, such as users and applications. Standard Linux uses access controls, such as granting permission using read, write, and execute, that can be modified by users and also by applications. SELinux enhances security by using policies to restrict access based on variables, such as user, role, type, and optionally, level.

Security Context

SELinux uses a "security context," also referred to as a "security label," to classify resources, such as processes and files. This context specifies how and by whom a given resource can be accessed. The security context of files and processes are listed in the /etc/sestatus.conf file. A security context is typically shown as a string of three or four words. Each word specifies a different component of the security context, namely the user, role, type, and level of that file or process. Each word is separated by a colon.

Analyzing and troubleshooting SELinux context violations

SELinux violations are logged when an SELinux policy rule has been violated. SElinux violations are recorded as AVC (Access Vector Cache) event errors and are stored in the *audit.log* files (audit.log, audit.log.1,audit.log.2, etc.). These audit log files are saved in the */var/log/audit* directory. To locate these errors, you can search through the log files looking for 'type=ACV'. For example, as root or using 'sudo', you could use the 'cat' command to display the contents of the log file. To see only ACV errors, you can pipe the result as: *'cat /var/log/audit/audit.log | grep type=ACV'*

Host_Alias

Specifies a list of computers on which 'sudo' users can perform commands.

/etc/sudoers

The following are the sections of the /etc/sudoers file: 1. User_Alias 2. Cmnd_Alias 3. Host_Alias 4. Runas_Alias

inetd Daemon

The inetd daemon is a super-daemon (similar to xinetd) that was used on older Linux distros. Like xinetd, the inetd daemon acts as a mediator for connection requests to network services running on the Linux host. It accepts connection requests from client systems, starts the requested service, and then forwarrds the requests from clients to the newly started daemon. When the transaction is complete and the connection from the client is terminated, the daemon is stopped on the Linux host. Unlike the xinetd daemon, all of the services managed by inetd are configured using a single conf file (/etc/inetd.conf). Each line in this file configures a single service to be managed by inetd using the following syntax: *service_name socket_type protocol flags user executable arguments*

/etc/xinetd.d Configuration files

This directory contains a file for each network daemon managed by xinetd. The conf file determines how xinetd will enable the network daemon. Parameters include: 1. *disable:* enables and disables the daemon 2. *service:* names the daemon. The name often comes from the /etc/services file 3. *socket_type:* determines wheter the socket type is a stream 4. *wait:* specifies whether the daemon is single-threaded or multi-threaded. A Yes specifies single-threaded 5. *user:* determines the user under which the daemon runs 6. *server:* lists the path to the daemon's executable 7. *log_on_failure:* defines logging specifications for failed logins. ** Each enabled daeon requires an exception in the host-based firewall to open the port for that daemon.

/etc/xinetd.conf Configuration file

This file configures the xinetd daemon. The default configuration for this file rarely needs adjustment; however, be aware of the following parameters: 1. *instances:* sets the max concurrent requests xinetd can support. 2. *lof_type:* configures the location where xinetd writes logs to. The default is /var/log/xinetd.log file. 3. *log_on_success:* determines whether successful connections are logged 4. *log_on_failure:* determines whether failed or disallowed connections are logged. 5. *cps:* limits the number of connections per second 6. *includedir:* /etc/xinetd.d: tells the xinetd daemon to use the service-specific conf files in the /etc/xinetd.d directory

SELinux troubleshooting tools

To aid in troubleshooting SELinux errors, you can also install additional tools. Perhaps the most common tool is semanage. Semanage is installed as a part of the policycoreutils-python package. On Centos 7, this can be installed by running: *'yum install -y setroubleshoot-server'*. Once installed, you can view SELinux errors by running the semanage command *sealert* (SELinux Alert). Sealert can be run from the command line or from the GUI (if installed) and will aid you in determining the cause of the error and any possible solutions. -- To run from the command line, run: *'sealert -a /var/log/audit/audit.log'*

Locking with 'pam_tally2'

To lock and unlock an account after a specific number of incorrect password attempts, you must add two lines to both the /etc/pam.d/system-auth and the /etc/pam.d/password-auth files. 1. int the "auth" section of each file, add: 'auth required pam_tally2.so file=/var/log/tallylog deny=3 even_deny_root unlock_time=900' defined as: -- 'file=/var/log/tallylog': the default log file where login counts are kept. This is a binary file. -- 'deny=3': deny access after three attempts and lock the user account. -- 'even_deny_root': apply this policy for the root user -- 'unlock_time=900': after failing the specified number of times, the account will be locked for 900 seconds (15 minutes), after which the account will be unlocked. 2. In the "account" section of each file, add: 'account required pam_tally2.so'

SELinux implementation

With SELinux, access controls are determined by an SELinux policy. Using this type of implementation, SELinux access controls: -- Can only be added, deleted, or changed by an administrator. This prevents users or apps from making access changes -- Provides finer granularity in permission, such as the ability to unlink, append only, and move a file -- Extends access control to many resources, such as network resouces and interprocess communication (IPC) ** SELinux was designed to enhance existing security solutions, not replace them, It is not a replacement for antivirus software, passwords, firewalls, or other security systems. It is not an all-in-one security solution.

To set up your SSL/TLS installation:

You must define your channels used to connect your systems to use SSL or TLS. You'll also have to create and manage your digital certs. Once everything is set up, you can test your SSL or TLS conditions using self-signed certs. Be aware, however, that self-signed certs cannot be revoked, which could allow an attacker to spoof an ID after a private key has been compromised, so only use thes types of certs for testing. OpenSSL is a command-line tool that is often installed on many Linux distros by default or it can be downloaded and installed as needed. With OpenSSL, you can create and view certs, and test your SSL/TLS connections.

'aa-unconfined'

uses the *'ss'* or *'netstat'* command to determine which processes have open network sockets and do not have AppArmor profiles loaded into the kernel. This command supports the following options: 1. *'aa-unconfined --with-ss'* -- runs the unconfined command using the 'ss' command to find and list the processes listening on the network sockets. This is the default option used if no options are explicitly entered. 2. *'aa-unconfined --with-netstat'* -- performs the same function as -ss, but instead of using the ss command it uses the older netstat command to find and list the processes listening on the network sockets. 3. *'aa-unconfined --paranoid'* -- The most thorough option which will display all of the processes from the /proc fs with TCP or UDP ports that are not protected by AppArmor profiles.