AWS Infrastructure & Web Application Environment

I created the projectzero-jumpbox-group and assigned the required EC2 permissions to support management of the jumpbox infrastructure.

I created the projectzero-employees-group to separate standard employee permissions from administrative and infrastructure specific access.

I created a custom IAM policy defining the EC2 actions required by the environment instead of granting broader administrative access. I then attached the policy to the appropriate IAM group.

Why: This demonstrates how permissions can be scoped to the actions users actually require, reducing unnecessary access and supporting the principle of least privilege.

Created a dedicated IAM group for ProjectZero employee access:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "EC2DeployBasic",
      "Effect": "Allow",
      "Action": [
        "ec2:RunInstances",
        "ec2:CreateTags",
        "ec2:DescribeInstances",
        "ec2:DescribeImages",
        "ec2:DescribeKeyPairs",
        "ec2:DescribeSecurityGroups",
        "ec2:DescribeSubnets",
        "ec2:DescribeVpcs",
        "ec2:DescribeInstanceTypes",
        "ec2:DescribeAvailabilityZones",
        "ec2:DescribeAccountAttributes",
        "ec2:DescribeNetworkInterfaces",
        "ec2:CreateNetworkInterface",
        "ec2:AttachNetworkInterface"
      ],
      "Resource": "*"
    }
  ]
}

I created the projectzero-prod-vpc using the 10.0.0.0/16 IPv4 CIDR range to provide an isolated network for the ProjectZero production environment.

I created the projectzero-prod-igw Internet Gateway to provide internet connectivity for resources placed in the public subnet.

I attached the projectzero-prod-igw Internet Gateway to the projectzero-prod-vpc, making it available as a routing target for public network traffic.

I created the public subnet using the 10.0.0.0/24 CIDR range for resources that require public network connectivity.

I created the private web subnet using the 10.0.1.0/24 CIDR range to isolate internal web tier resources from direct internet access.

I created the private database subnet using the 10.0.2.0/24 CIDR range to provide a separate network segment for database resources.

I created projectzero-prod-public-rt, added a default 0.0.0.0/0 route through the ProjectZero Internet Gateway, and associated the route table with the public subnet.

I created projectzero-prod-private-rt and associated both the Private Web Subnet and Private DB Subnet with it. Unlike the public route table, no direct route to the Internet Gateway was configured.

I verified the completed VPC architecture and confirmed that the public, private web, and private database subnets were associated with their intended route tables. The public subnet routes internet bound traffic through the Internet Gateway, while the web and database subnets remain on private routing.

I configured the projectzero-prod-jumpbox EC2 instance using Ubuntu Server 24.04 LTS, a t3.micro instance type, and my existing SSH key pair for secure authentication.

I kept the default 8 GB gp3 root volume because the jumpbox only required minimal storage for administrative access and security tooling.

I added a user data script to automatically install and configure fail2ban when the jumpbox launched. The SSH jail monitors failed authentication attempts and temporarily blocks addresses that exceed the configured retry limit, helping protect the public facing jumpbox from SSH brute force attacks.

#!/bin/bash
apt-get update
apt-get install -y fail2ban

# Configure fail2ban
cat > /etc/fail2ban/jail.local <<EOF
[DEFAULT]
bantime = 3600
findtime = 600
maxretry = 5

[sshd]
enabled = true
port = ssh
logpath = /var/log/auth.log
maxretry = 3
bantime = 7200
EOF

# Start and enable fail2ban
systemctl enable fail2ban
systemctl start fail2ban

I launched the jumpbox with the configured Ubuntu image, public subnet, SSH key pair, security group, and fail2ban user-data script.

I connected to the public jumpbox using SSH with the configured key pair, then verified that the fail2ban service was successfully installed, enabled, and running.

ssh -i "My-Desktop-Key-Pair.pem" ubuntu@13.53.244.30

I configured the jumpbox as the controlled access point for reaching EC2 instances in the private subnets. This keeps private resources inaccessible directly from the internet while still providing an administrative path through the public jumpbox.

To access a private instance:

I changed the hostname to projectzero-prod-jumpbox so the system could be easily identified when administering the ProjectZero environment.

I deployed a NAT Gateway in the public subnet and assigned it an Elastic IP to provide outbound internet connectivity for resources located in the private subnets.

Why: The NAT Gateway allows private instances to reach external services, such as package repositories and software updates, without requiring those instances to have public IP addresses.

I updated the projectzero-prod-private-rt route table with a 0.0.0.0/0 route pointing to the NAT Gateway.

This routes internet bound traffic from the associated private subnets through the NAT Gateway while keeping the instances themselves private.

I reviewed the projectzero-prod-websvr-sg security group and updated its inbound rules to allow the network access required for configuring and updating the web server.

I connected to the private web server and tested outbound connectivity by sending ICMP traffic to 8.8.8.8. The successful replies confirmed that the private instance could reach the internet through the NAT Gateway.

Why: This verified that the private subnet routing and NAT configuration were working as intended without assigning a public IP address to the private instance.

I deployed projectzero-prod-websvr as an Ubuntu EC2 instance in the Private Web Subnet to host the ProjectZero threat-intelligence application. The server was configured without a public IP so it could not be accessed directly from the internet.

I placed the web server in the private subnet and configured its security group to allow SSH access only from the ProjectZero jumpbox. This keeps the server isolated from direct internet access while maintaining a controlled administrative path through the jumpbox.

Security Group

Configure inbound rules:

Since the web server is in a private subnet, we only allow SSH from the jumpbox security group. This ensures the web server is not directly accessible from the internet.

Configure Storage

I connected from the ProjectZero jumpbox to the private web server using its private IP address, verifying that administrative access to the server was available through the jumpbox.

SSH from Jumpbox to Web Server

ssh -i ~/.ssh/My-Desktop-Key-Pair.pem ubuntu@<websvr-private-ip>

I updated the server hostname to projectzero-prod-websvr to clearly identify the instance within the ProjectZero environment.

# Set the hostname using hostnamectl (modern method)
sudo hostnamectl set-hostname projectzero-prod-websvr

# Update /etc/hosts to include the new hostname
sudo sed -i 's/127.0.0.1 localhost/127.0.0.1 localhost projectzero-prod-websvr/' /etc/hosts

# Verify the hostname has been changed
hostnamectl

I installed Node.js and npm on projectzero-prod-websvr to provide the runtime and package management required by the Astro application.

curl -fsSL https://deb.nodesource.com/setup_22.x | sudo -E bash sudo apt install -y nodejs

I created the threat-intel-app project directory and initialized the Astro application that would be used for the ProjectZero Threat Intelligence Dashboard. Create Project Directory

mkdir -p ~/threat-intel-app cd ~/threat-intel-app

Initialize Astro Project

npm create astro@latest .

I installed and configured Tailwind CSS within the Astro project to provide the styling framework for the ProjectZero Threat Intelligence Dashboard.

Install Tailwind CSS

npm install -D tailwindcss@3 postcss autoprefixer

Initialize Tailwind Configuration

npx tailwindcss init -p