Skip to main content

Academic Paper Examples — Linux Security —2016

Professional IT Expert, Technology Enthusiast, Strategist, Writer and Video Gamer.

Introduction

Introduction: These are Academic Paper Examples for Linux Security cases.
Purpose: The purpose of posting this is to help educate, provide ideas, or help students write similar papers/help design a template.
School: ITT Technical Institute — Student: Alex Ovanisian
Date: 2016 (Please note that some information may become outdated due to the speed at which technology changes)

Paper 1:

Risk Overview Analysis Report

Assets that pose potential risks:

A Web server

A database server

A Simple Mail Transfer Protocol (SMTP) server

A file server for customers’ loan applications and other personal data files

General Overview

There are various security aspects to look at, one major aspect is the assets and services running on them. For example, the web server needs to be secure regarding proper local security: firewall, user security, proper port security, etc. The communication between these servers need to be secure: ensure proper firewalls, authentication, etc. Physical security should also be implemented and prevent unauthorized access into the location of these devices. There are also laws and regulations that may need to be considered: SOX and GLBA which could generate fines if we don’t properly secure the servers in question. We need to also have a proper backup server in place as there’s potential for customer data loss.

Basic Project Requirements

  • Local Security on Operating System Levels:
    • Web Server Aspects
      • HTTPS
      • User-Level Security and Permissions
      • File-Level Security and permissions
      • Directory-Level Security and Permissions
      • Apache – Security Best Practices
      • Local Security Configurations
      • SSH and SSH Risks
      • Firewalls
      • Basic Web Server with very limited services, applications, proper logs
      • Web Application Security
      • Information and data security in regards to SOX and GLBA
      • Extra Security Considerations: SElinux , Secure GRUB boot loader, Data Encryption, Drive Encryption
    • Database Server Aspects
      • User-Level Security and Permissions
      • File-Level Security and permissions
      • Directory-Level Security and Permissions
      • mySQL – Security Best Practices
      • Local Security Configurations
      • SSH and SSH Risks
      • Firewalls
      • Basic Database Server with very limited services, applications, proper logs
      • Database Security
      • Information and data security in regards to SOX and GLBA
      • Extra Security Considerations: SElinux , Secure GRUB boot loader, Data Encryption, Drive Encryption
    • SMTP Server Aspects
      • User-Level Security and Permissions
      • File-Level Security and permissions
      • Directory-Level Security and Permissions
      • mySQL – Security Best Practices
      • Local Security Configurations
      • SSH and SSH Risks
      • Firewalls
      • Basic Mail Server with very limited services, applications, proper logs
      • Mail Security
      • Information and data security in regards to SOX and GLBA
      • Extra Security Considerations: SElinux , Secure GRUB boot loader, Data Encryption, Drive Encryption
    • File Server Aspects
      • User-Level Security and Permissions
      • File-Level Security and permissions
      • Directory-Level Security and Permissions
      • Local Security Configurations
      • SSH and SSH Risks
      • Firewalls
      • Basic File Server with very limited services, applications, proper logs
      • Information and data security in regards to SOX and GLBA
      • Extra Security Considerations: SElinux , Secure GRUB boot loader, Data Encryption, Drive Encryption
    • Backup Server Aspects
      • User-Level Security and Permissions
      • File-Level Security and permissions
      • Directory-Level Security and Permissions
      • Local Security Configurations
      • SSH and SSH Risks
      • Firewalls
      • Basic Backup Server with very limited services, applications, proper logs
      • Information and data security in regards to SOX and GLBA
      • Extra Security Considerations: SElinux , Secure GRUB boot loader, Data Encryption, Drive Encryption
  • Physical Security and On-Site Location:
    • Server Room and Server Location Access
      • Keycard Implementation
      • Locked Door
    • Servers
      • Secured and Locked in Rack
      • BIOS locked down
    • Layers of Security in Building
      • Multiple Layers of Door Locks/Keycards
      • Security Staff
        • Proper Background Checks
        • Validation of Credentials
      • Security Cameras
  • Data Communication Security:
    • Secure Communications between Servers
    • Authenticated Security Between Servers
    • Encrypted Communication between Servers
    • Proper Firewalls, Routing, and Access Controls
    • Ports and services locked down to bare minimums
    • Servers communicating to only the specific servers
    • Certificates setup on all services to provide certification of authenticity of servers
    • Proper VLANs or network segregation between networks not needing to access these resources
    • Proper network-side logging, intrusion and security watch
    • DMZ network and proxy servers in place as needed

Optional Project Requirements

  • Virtualization:
    • Security measures regarding virtual host
      • User-Level Security and Permissions
      • File-Level Security and permissions
      • Directory-Level Security and Permissions
      • Local Security Configurations
      • SSH and SSH Risks
      • Firewalls
      • Basic Host Server with very limited services, applications, proper logs
      • Information and data security in regards to SOX and GLBA
      • Extra Security Considerations: SElinux , Secure GRUB boot loader, Data Encryption, Drive Encryption
      • Virtual Machine Security Considerations
Scroll to Continue


Project Overview

There are various security aspects to look at, one major aspect is the assets and services running on them. We need to ensure we properly setup HTTPS/SSL certificates to properly secure our Web Site, we need to setup the Web Services using best practices, provide all security and permissions in the best manner possible, authenticate all accounts and ensure we have the correct account access, firewall rules on the devices as well as proper firewall and access rules on our hardware firewall/router, the operating systems should be customized based on their individual needs and remove services or functionality not needed, we need to absolutely follow the laws and regulations set forth by SOX and GLBA, we should heavily consider: SElinux, secure GRUB boot loader, and Encryption on all levels, we need to make sure our database, file server is secure, ports, services, and IP address access should be limited to only the bare minimum and servers that should communicate using that port or service. We need proper backups to prevent customer data loss. We should also implement all levels of physical security to ensure no unauthorized access has occurred.

There are the basic aspects we need to look into in completing this project based on security principles and guidelines. We must follow all best practices as this is customer information we will hold on a server. We must look into implementing security measures in all aspects of local server security, physical security, and data communications security. There can be heavy consequences to any aspect we miss or decide not to include. I recommend we also ensure we have proper Firewall and Backups in regard to these servers to keep it all secure and maintained.

After this project is completed, we need to be able to maintain this setup. We should ensure the personnel are enough to sustain the level of security we desire. We need them to properly review all aspects of security on a daily basis going from data communications to local security to reviewing logs and firewall live and history data. The complexity of some of these requirements may increase and decrease by adding Virtualization as well.

Paper 2:

Unit 2 Discussion 1: Identifying Layers of Access Control in Linux

There a multitude of improvements we can implement in terms of Access Control within a Linux Web Server environment which will allow the environment to be much more secure.

We should first implement standard file and directory permissions and access control lists to provide basic user security. Both users and groups should be used to provide specific permissions to files, folders, services, etc. These are Discretionary Access Control functions because they provide basic system security that the owner has some control over.

We should also implement SELinux to provide a more enchanced layer of security; we can implement it with iptables to provide an additional layer of security in terms of specific rules. These are Mandatory Access Control functions and provide a much more protective layer of security where the IT/Linux/System Administrator will only be able to manage.

We should look into a layered Access Control Security within the e-commerce aspects as well. The database and web application both require layered security and access controls. We need to ensure Access Control is all managed and administered in a way that prevents security holes. Everything should be authenticated by proper security measures.

Paper 3:

Compromising an Online System

This was an attack where the attackers had discovered various holes and ways around the system. For example, if Apache had made OPIE a mandatory setup, it would’ve have been much harder for the attacker to gain visibility on passwords just by capturing communication since this would enforce one-time use passwords, another major issue was that many passwords were linked or the same; the more passwords, the more layers of locks in place on different systems. If you have one key for your house with one lock vs if you have 4 keys of your house on different doors, this is far more layers the attacker needs to cross. SSH was still allowed for login using the normal SSH password over the internet which would allow seeing of that traffic and an attacker could try to gather the password from that secured communication. They should’ve also logged and tracked all user login attempts and had it reported to the Infrastructure Team.

They need to secure their web server and keep it logged far more. They should mandate the OPIE option that PAM has. Increase the variation of passwords to have many different layers of security. Put out policies to force the account or service that runs jira to have very limited access to other functionality. There can also be iptables rules that lock down communication between all the hosts and force only specific ports and services to communicate. Ensure this server is a bastion server as it sounds like it may have too much functionality and open ports.

This content was accurate and true to the best of the author’s knowledge at the time of publication but may be out of date. The information contained in this article may not reflect current policies, laws, technology, or data.

© 2021 alexovanisian

Related Articles