Corporate Project: From Risk to Resilience: Eliminating Jump Servers, Port 22 for Better Security

Introduction

In the realm of cloud computing, security vulnerabilities are a persistent concern. During the execution of the Server Security Management (SSM) project, I uncovered a critical security flaw in server access management that warranted immediate attention. This article delves into the identified issue, the steps taken to mitigate it, and the lessons learned, offering insights for individuals and teams facing similar challenges.

Problem: Critical Security Concern with Port 22 (SSH)

A major security threat was identified: Port 22 (SSH), opened for inbound access over the internet.

1. A jump server was being used to access the application server securely.

2. The Security Group (SG) was configured to allow SSH access (Port 22) for both the jump server and the application server, restricted to company or Zscaler IPs.

This configuration effectively exposed the servers to potential breaches, necessitating an overhaul of security protocols.

Execution:

Mitigating Vulnerabilities To safeguard server integrity, the following measures were implemented:

1. Eliminating Internet-Based SSH Access:

   Disabled SSH access (Port 22) from all external sources, mitigating server exposure.

2. Replacing Key Pair Management and Local Storage:

   Introduced alternatives to prevent key storage and management vulnerabilities.

3. Implementing a Centralized Management Solution:

   Adopted a unified interface for managing multiple instances across diverse environments.

Project Structure:

The project structure consists of a root main.tf file that orchestrates various modules, including a VPC module for networking, EC2 Module provisions compute resources and security groups, IAM Module defines roles and policies for resource access and S3 Module manages storage configurations.

VPC Module Overview

It is designed to create a robust and scalable networking environment. All resources are tagged appropriately for identification and manageability.

1. VPC Creation:

   Configures a Virtual Private Cloud (VPC) with the CIDR block 10.0.0.0/16.

2. Subnets:

   Public Subnet: Used for resources requiring internet access (e.g., NAT Gateway). Instances launched here are assigned public IPs.

   Private Subnet (App): Dedicated to application resources without direct internet access.

   Private Subnet (Sharing): Segregates additional private resources for sftp and data transfer.

3. Gateways:

   Sets up an Internet Gateway to enable outbound internet access for public resources.

   Provisions a NAT Gateway within the public subnet to securely route internet traffic for private subnets without exposing them to external networks.

   Allocates an Elastic IP for the NAT Gateway, ensuring static outbound communication.

4. Route Tables and Associations:

   Configures Public Route Table: Routes all outbound traffic (0.0.0.0/0) from public subnets via the Internet Gateway.

   Configures Private Route Tables (App and Sharing): Routes outbound traffic from private subnets to the internet through the NAT Gateway. Associates each route table with its respective subnet(s) to enforce traffic rules.

5. Security Groups:

   Defines security groups for private subnets with egress-only rules, allowing secure communication through AWS Systems Manager endpoints.

IAM Module Overview

The IAM module is designed to enforce role-based access control, ensuring each user has only the permissions they need. It focuses on creating specific IAM users, policies, and role assignments tailored to developers and admin access.

1. IAM User Creation:

   Defines three users: dev1, dev2, and admin, each tagged for management and identification.

   Creates login profiles for these users, enabling console access with password policies.

   • Developers (dev1, dev2): Limited access users for secure and specific operations.

   • Admin: Elevated privileges user for broader testing and management tasks.

2. SSM Session Management:

   mc-mum-ssm-session-policy allows developers (dev1, dev2) to securely manage and interact with instances via Systems Manager (SSM), enabling actions like starting sessions and sending commands while restricting broader access.

   Grants the admin user full access to EC2 and SSM using predefined AWS-managed policies (AmazonEC2FullAccess and AmazonSSMFullAccess).

3. S3 Bucket Access:

   This policy grants folder-specific access to the bucket created for data transferring. Users can list all buckets, view objects in the bucket, and have read/write permissions only for their assigned folder (e.g., dev1/*). Any access to other buckets or paths is explicitly denied, ensuring secure and isolated usage.

EC2 Module Overview

This module provisions EC2 instances for the SSM test environment, configuring roles, policies, and profiles to ensure secure operations.

1. IAM Role and Policies for EC2

   Creates an IAM role (ec2_role) that allows EC2 instances to assume the necessary permissions for Systems Manager. The policies attached are AmazonSSMManagedInstanceCore(provides permissions for SSM agent communication), Custom S3 Policy and AmazonS3FullAccess. The IAM role to instances via Instance profile.

2. Aws Instances:

   The private EC2 instances (private_app_ssmtest and private_sharing_ssmtest) are deployed in their respective private subnets. They are configured with IAM instance profiles, security groups, and custom tags for identification. Both run tailored user data scripts to install utilities, create users, configure SSH, and enable logging.

S3 Module Overview

The S3 module creates an S3 bucket (ssm-test-s3-temp) for secure file storage and integrates it with a VPC Gateway Endpoint for private network access.

1. Bucket Creation: Sets up a tagged S3 bucket for organizing and storing files specific to the project.

2. VPC Endpoint: Configures a Gateway Endpoint to allow private, secure, and cost-effective access to the S3 bucket from within the VPC, without needing public internet access.

3. Routing Integration: Associates the VPC endpoint with specific route tables, ensuring controlled access to S3 from private subnets.

Why Use an S3 VPC Endpoint?

1. Enhanced Security: Ensures data traffic between the VPC and S3 stays within AWS's private network, avoiding exposure to the public internet.

2. Reduced Latency: Optimizes data transfer by leveraging AWS's internal network.

3. Cost Efficiency: Eliminates the need for NAT Gateways or public IPs for accessing S3.

4. Simplified Management: Enables routing traffic through specific route tables, ensuring controlled access to S3 from within the VPC.

Demonstration:

Pre-requisites:

1. Ec2 Server

   AmazonSSMManagedInstanceCore: This policy must be attached to all EC2 instances to enable communication with SSM.

   SSM Agent: SSM Agent must be installed and running on all instances.

2. IAM Group/User
   Developers: IAM policy should grant permissions for essential SSM operations, such as starting and terminating sessions, sending commands, and viewing session details, limited to specified EC2 instances and SSM resources within the account.
   Admins: IAM should assign broader permissions to facilitate full administrative control over SSM and its resources.

3. Tagging AWS Users

   When creating an AWS user, assign the tag SSMSessionRunAs with the value set to the corresponding OS username. This tag dictates which OS user the AWS user will assume during an SSM session. This will do the mapping for OS user and AWS user.

Connecting the Server

You can connect to the instance using two methods:

1. SSM Dashboard:

   Go to the Session Manager section in the Systems Manager Console.

   Start a session for the instance.

   If "Run As" is enabled, commands will execute as the specified user (e.g., dev1).

   If not enabled, the session defaults to the ssm-user.

2. EC2 Console:

   Use the Connect option in the EC2 Console.

   Select Session Manager as the connection method.

   Verify the user context by running whoami or checking the home directory.

You will by default be logged in as ssm-user, which has sudo privileges. So anybody who has permission to connect to server will have full access. This can be restricted in below manner:

IAM user and OS user Mapping

IAM user and OS user mapping is the process of linking AWS IAM users with specific OS-level user accounts on EC2 instances. This mapping is critical for managing access and permissions seamlessly across AWS services and the operating system.

• An IAM user can assume a specific OS user account using the SSMSessionRunAs tag, as configured in IAM roles or policies.

  During an SSM session, the Run As feature ensures that the IAM user's commands are executed as the mapped OS user.

  When mapping is enabled, the session runs as the mapped OS user (e.g., dev1, admin) with their associated permissions. If not mapped, the session defaults to the ssm-user, a system-level user created by the SSM agent.

• Granting Sudo Access:

  Specific OS users (e.g., admin) can be granted sudo privileges by adding them to the sudoers file.

Advantages:

1. Enhanced Security: Eliminates the need for open inbound ports (e.g., SSH port 22), reducing exposure to external threats.

2. Centralized Management: Provides a unified interface to manage multiple instances across various environments.

3. Auditability: Offers detailed logging of all actions performed, aiding in compliance and monitoring.

4. No Need for SSH Keys: Removes the requirement to distribute and manage SSH keys, simplifying credential management.

5. Cross-Platform Support: Allows management of both AWS and on-premises servers, facilitating hybrid cloud strategies.

6. Eliminate Jump Server: Jump server is not required as the instance need not be access through another server.

Conclusion:

This setup showcases the power of SSM in simplifying server management while maintaining the highest security standards, offering a scalable and secure infrastructure for future growth.

###