What Are AI Influence Levels?

AI Influence Levels provide a standardized way to communicate how much AI was involved in creating content. Again, reminder that Daniel Miessler created this framework, and I’m just using it here. The system uses a simple 0-5 scale:

• AIL 0: Human Created, No AI Involved
• AIL 1: Human Created, Minor AI Assistance
• AIL 2: Human Created, Major AI Augmentation
• AIL 3: AI Created, Human Full Structure
• AIL 4: AI Created, Human Basic Idea
• AIL 5: AI Created, Little Human Involvement

Why This Matters

In an era where AI can generate everything from blog posts to artwork, the line between human and machine creativity is increasingly blurred. Readers care about authenticity and origin, especially when that origin might not be entirely human.

This isn’t about judging whether AI assistance is “good” or “bad.” It’s about transparency. Some readers prefer purely human-written content, while others are curious about AI-augmented creativity. By clearly labeling content with its AIL rating, everyone can make informed decisions about what they’re reading.

How It Works on fz42.net

Starting today, you’ll notice a small ⚡ icon in the metadata section below post titles, followed by an AIL rating (e.g., “AIL 1”). Hover over the indicator to see a tooltip explaining what that level means.

Every post on the site will display an AIL rating:

• Posts without explicit ratings default to AIL 0 (human-only)
• Posts with AI involvement will show their appropriate level
• The rating reflects the content creation process, not the ideas or expertise behind it

My Commitment to Transparency

Most content on fz42.net will likely fall into AIL 0-2 range. I believe in human expertise and perspective, but I’m not opposed to using AI tools for editing, research assistance, or exploring ideas. When I do use AI in any meaningful way, you’ll know about it.

This post itself is rated AIL 2—I wrote the initial draft and structure, but used AI assistance to refine the language and ensure clarity. The ideas, perspective, and technical implementation are entirely my own.

Technical Implementation

For those curious about the technical side, the AIL system is implemented as:

1. An optional ai_influence_level parameter in post front matter
2. Hugo template logic that displays the appropriate indicator
3. Consistent visual design using the ⚡ icon across all levels
4. Descriptive tooltips explaining each level

The feature is backward-compatible—existing posts without AIL ratings automatically display as AIL 0.

Looking Forward

As AI tools evolve and become more sophisticated, having clear standards for disclosure becomes increasingly important. By adopting Daniel Miessler’s AIL framework, fz42.net joins a growing movement toward transparency in AI-assisted content creation.

I encourage other content creators to consider implementing similar disclosure systems. Transparency builds trust, and trust is the foundation of any meaningful reader relationship.

The Journey

Four months ago, my employer got acquired. Anyone who’s been through an acquisition knows the drill - uncertainty about the future naturally leads to resume polishing.

I got tired of installing TeX distributions just to build my resume. I created a GitHub Action that built the PDF as an artifact. Good enough… I was manually downloading it in case I had to start sending it around.

This week, I decided to tackle the profile automation. I realized those artifacts expire after 90 days (by default) and I wouldn’t be able to link to expiring artifacts. Time to evolve the system.

The Private Repo Problem

I upgraded to creating proper releases. But my resume repo is private. The automation worked great… for me. I was authenticated, so the PDF links worked. Everyone else got 404s.

Could I just make the resume repo public? Sure. But it needs cleanup first, and more importantly, I wanted to learn how to handle this when making a repo public isn’t an option.

I discovered repository_dispatch which lets one GitHub repo trigger workflows in another using a Personal Access Token.

Why the Hard Way?

This cross-repo integration pattern is valuable beyond my use case. What about:

• Client codebases that must stay private
• Internal tools with public documentation
• Any other scenario where “just make it public” isn’t possible

Learning repository_dispatch now means I have this tool ready when I actually need it.

How It Works

Resume repo (private):

1. Tag a release: git tag v1.0.3
2. Action builds PDF and creates release
3. Triggers profile repo update

Profile repo (public):

1. Receives dispatch event
2. Downloads PDF from private release
3. Commits PDF locally
4. Updates README

The Technical Details

In the resume workflow, after creating the release:

- name: Trigger Profile Repository Update
    if: startsWith(github.ref, 'refs/tags/v')
    run: |
      curl -X POST \
        -H "Authorization: token ${{ secrets.PAT_TOKEN }}" \
        -H "Accept: application/vnd.github.v3+json" \
        https://api.github.com/repos/fz42net/fz42net/dispatches \
        -d '{"event_type":"resume_updated","client_payload":{"version":"${{ steps.get_version.outputs.version }}"}}'

The profile workflow listens for this:

on:
  repository_dispatch:
    types: [resume_updated]

Then it fetches the PDF from the private repo:

- name: Download Latest Resume PDF
    if: github.event_name == 'repository_dispatch' || github.event_name == 'workflow_dispatch'
    run: |
      # Get the latest release from the private resume repo
      echo "Fetching latest release info..."
      LATEST_RELEASE=$(curl -s -H "Authorization: token ${{ secrets.PAT_TOKEN }}" \
        https://api.github.com/repos/fz42net/resume/releases/latest)

      # Check if we got a valid response
      if echo "$LATEST_RELEASE" | jq -e '.assets' > /dev/null; then
        # Extract the download URL for resume.pdf
        DOWNLOAD_URL=$(echo "$LATEST_RELEASE" | jq -r '.assets[] | select(.name=="resume.pdf") | .url')
        
        if [ "$DOWNLOAD_URL" != "null" ] && [ -n "$DOWNLOAD_URL" ]; then
          # Download the PDF
          curl -L -H "Authorization: token ${{ secrets.PAT_TOKEN }}" \
            -H "Accept: application/octet-stream" \
            "$DOWNLOAD_URL" -o resume.pdf
          
          echo "Downloaded resume.pdf from version: ${{ github.event.client_payload.version || 'manual trigger' }}"
        else
          echo "Error: Could not find resume.pdf in release assets"
          exit 1
        fi
      else
        echo "Error: Invalid API response or no releases found"
        echo "$LATEST_RELEASE"
        exit 1
      fi
    env:
      PAT_TOKEN: ${{ secrets.PAT_TOKEN }}

The Result

My profile now shows:

• Latest blog posts from fz42.net
• Posts from my employer’s blog
• Link to current resume (from public repo)

All updated automatically. The resume source stays private until I’m ready to clean it up.

Full workflows: profile updater (resume builder stays private for now)

Front Door WAF has a specific fingerprint: 403 responses include both x-azure-ref and x-cache headers. Application Gateway WAF doesn’t include these.

I’ll definitely forget these details in six months. That’s why I wrote this BCheck:

metadata:
    language: v2-beta
    name: "Azure Front Door WAF Detection"
    description: "Detects Azure Front Door WAF based on 403 response headers"
    author: "fz42"
    tags: "azure", "waf", "bypass"

given response then
    if 
        {latest.response.status_code} is "403" and 
        {latest.response.headers} matches "(?i)x-azure-ref" and 
        {latest.response.headers} matches "(?i)x-cache" 
    then
		report issue:
            severity: info
            confidence: firm
            detail: `Azure Front Door WAF detected. If using RemoteAddr (default) for IP restrictions, try X-Forwarded-For bypass:
            - 127.0.0.1
            - 10.0.0.0/8
            - 172.16.0.0/12
            - 192.168.0.0/16
            - ...
            
            If bypass works, ALL WAF protections are disabled.
            
            References: 
https://trustedsec.com/blog/azures-front-door-waf-wtf-ip-restriction-bypass`
            remediation: "Use SocketAddr instead of RemoteAddr or make a compound condition including both SocketAddr and RemoteAddr in WAF configuration."
		    
    end if

Now, I’ll have a nice reminder in Burp Suite ensuring I don’t miss this in the future.

Usage

Drop this into Burp’s BCheck editor. Every 403 response gets checked automatically.

Why this approach

I’ve collected 40+ bypass headers over the years (X-Forwarded-For, X-Real-IP, X-Client-IP, etc.). You can’t blast all of them at every 403 on a client engagement - that’s how you hit rate limits and get noticed.

This check identifies exactly when X-Forwarded-For will work (Front Door WAF with RemoteAddr). No spray and pray needed.

Between all the cloud providers and their quirks, I won’t remember that x-azure-ref + x-cache = Front Door WAF six months from now. But my BCheck will.

Last week I hit 4 WAF-protected endpoints. If any had been vulnerable Front Door configurations, this would’ve caught it automatically.

ccusage shows what I would have spent on API tokens:

Even in June (lighter usage), API tokens would have cost more than the subscription. July shows why I’ll keep paying - I’m already at 6x the subscription cost.

The numbers

• Claude Max 5x: $100/month
• Claude Max 20x: $200/month
• My June API usage: $246
• My July API usage: $1,362 (and counting)

Check your own usage

npx ccusage@latest monthly

Context

I run a side business and bill clients for development work, which makes a $200/month tool easier to justify. With a fixed monthly cost, I never think “is this prompt worth it?” or “should I try a different approach?” I just build. No mental math on whether refactoring this feature will cost $0.50 or $5.00 in tokens.

That cognitive overhead disappeared with the subscription. The code ships faster when you’re not rationing your tool usage.

For hobbyists, these numbers might not make sense. But if you’re doing paid work, run ccusage and see where you land.

But this prediction caught my attention:

“I think there’s a good chance that by the end of the year, people aren’t using IDEs anymore”

That’s a bold timeline.

When I’m not doing security consulting, I’m building software and Claude Code has transformed my workflow. Whether it’s Python, Swift, TypeScript, C#, or Go, I can prototype ideas faster than I could ever code them manually. The ability to rapidly prototype and discard has fundamentally changed how I develop.

But replacing IDEs entirely? By December 2025?

Will we see dramatic shifts in how we code? Absolutely. Are IDEs dead in 11 months? I’ll take that bet.

The video is still worth your 30 minutes though. Boris gives a great demo of what Claude Code can do today.

The main reason: professional contexts. Sharing a GitHub profile or email with “fatzombi” in client communications always felt off. The zombie avatar looked especially out of place in client Slack channels next to everyone’s professional headshots. That disconnect matters when you’re building trust as a security consultant.

fz42 solves this. It’s short, professional, and easy to communicate verbally. The “42” is a Hitchhiker’s Guide reference, because why not.

Technical details

• Both fatzombi.com and fz42.net point to the same CloudFront distribution
• Same S3 bucket serves both domains
• RSS feeds work from either domain
• No redirects needed—pick whichever URL you prefer

The content remains the same—technical notes, tooling experiments, and whatever problems I’m solving this week. Just with a handle that fits in a corporate Slack without raising eyebrows.

This is the traditional approach to accessing AWS resources, but we’re going to look at migrating to OpenID Connect (OIDC) to reduce our risk of credential exposure and simplify credential management.

Setting up OIDC in AWS

Create an OIDC provider for GitHub

After navigating to the IAM dashboard in the AWS Console, click on Identity providers, then click Add provider.

We want to create an OpenID Connect provider with the following details:

• Provider URL: https://token.actions.githubusercontent.com
• Audience: sts.amazonaws.com

Once redirected to the Identity Providers page, select your newly created provider and make note of its ARN.

Create an IAM role

At this point, we’ll create an IAM role that leverages this new identity provider using a trust policy and assign the minimum level of permissions to the role that we need.

Clicking the Assign role button under our identity provider will automatically populate the identity information in the dialog.

We want to create a new role.

At this screen, Web Identity and Identity Provider should automatically be selected. Ensure you select your Audience from the dropdown.

At the very least, you’ll need to enter the GitHub organization. If you have an individual account, the “organization” will be the name of your individual account. Additionally, if you want, you can limit the access of the identity to a specific repository and branch. I would recommend at least restricting to a specific repository.

Click Next on the Add permissions step as we’ll create our own policy in a later step.

Scope the trust policy

We can name our role and click the Create role button. The Trust policy should automatically be populated with the Identity Provider and GitHub organization/repo/branch information that was entered previously.

Assign permissions

Navigate to your newly created IAM role.

Make note of the ARN, as that’s what we’ll need to provide to our GitHub Action.

Select Create inline policy under the Add permissions dropdown in the Permissions policies section.

Clicking JSON, will bring us to the policy editor, where we can paste in the following policy that will limit our access to a specific S3 bucket and CloudFront distribution.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Resource": [
                "arn:aws:s3:::fatzombi.com",
                "arn:aws:s3:::fatzombi.com/*"
            ],
            "Action": [
                "s3:PutObject",
                "s3:GetObject",
                "s3:DeleteObject",
                "s3:ListBucket"
            ]
        },
        {
            "Effect": "Allow",
            "Resource": "arn:aws:cloudfront::ACCOUNTID:distribution/DISTRIBUTION_ID",
            "Action": [
                "cloudfront:CreateInvalidation",
                "cloudfront:GetDistribution"
                ]
        }
    ]
}

Click Next, provide a name for our policy, then click Create policy.

We now have a role with only the minimum level of access needed to deploy our files to S3 and invalidate the CloudFront cache.

Modifying GitHub Actions Workflow

For reference, our original GitHub Action file consists of the following:

name: Deploy Website

on:
  workflow_dispatch:
  push:
    branches:
      - main

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
    - uses: actions/checkout@v3
    - name: Build the site in the jekyll/builder container
      run: |
        docker run \
        -v ${{ github.workspace }}:/srv/jekyll -v ${{ github.workspace }}/_site:/srv/jekyll/_site \
        jekyll/builder:latest /bin/bash -c "chmod -R 777 /srv/jekyll && jekyll build --future"

    - name: Configure AWS Credentials
      uses: aws-actions/configure-aws-credentials@v1
      with:
        aws-access-key-id: ${{ secrets.AWS_ACCESS_KEY }}
        aws-secret-access-key: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
        aws-region: us-east-1

    - name: Deploy to S3
      run: |
        aws s3 sync _site s3://fatzombi.com --acl public-read --delete

    - name: Invalidate CloudFront Cache
      run: |
        aws cloudfront create-invalidation --distribution-id ${{ secrets.CLOUDFRONT_DISTRIBUTION }} --paths "/*"

The bulk of the changes with our new setup will be to the Configure AWS Credentials step, however we also need to add an additional block to our job so that it’s able to request an OIDC token and read our repository.

- name: Configure AWS Credentials
        uses: aws-actions/configure-aws-credentials@v2
        with:
          role-to-assume: ${{ secrets.AWS_IAM_ROLE_ARN }}
          role-session-name: github-fatzombi-action
          aws-region: us-east-1

To summarize the changes of this step, we have:

• Upgraded to the @v2 library.
• Removed the aws-access-key-id and aws-secret-access-key properties.
• Added two new properties
  • role-to-assume: which is the ARN of our IAM role we created previously.
  • role-session-name: which is a unique identifier for the OIDC session that is created.

Lastly, we need to add a permissions block to our job, which grants the job permission to request an OIDC token and read our repository.

 permissions:
      id-token: write
      contents: read

This bring our entire GitHub Action contents to the following:

name: Deploy Website

on:
  workflow_dispatch:
  push:
    branches:
      - main

jobs:
  build:
    runs-on: ubuntu-latest
    
    permissions:
      id-token: write
      contents: read
      
    steps:
    - uses: actions/checkout@v3
    - name: Build the site in the jekyll/builder container
      run: |
        docker run \
        -v ${{ github.workspace }}:/srv/jekyll -v ${{ github.workspace }}/_site:/srv/jekyll/_site \
        jekyll/builder:latest /bin/bash -c "chmod -R 777 /srv/jekyll && jekyll build --future"
    
    - name: Configure AWS Credentials
      uses: aws-actions/configure-aws-credentials@v2
      with:
       role-to-assume: ${{ vars.AWS_IAM_ROLE_ARN }}
       role-session-name: github-fatzombi-action
       aws-region: us-east-1
    
    - name: Deploy to S3
      run: |
        aws s3 sync _site s3://fatzombi --acl public-read --delete
    
    - name: Invalidate CloudFront Cache
      run: |
        aws cloudfront create-invalidation --distribution-id ${{ vars.CLOUDFRONT_DISTRIBUTION }} --paths "/*"

Testing the new setup

Commit the changes and we should see a successful deployment.

Now, you can go ahead and delete the AWS_ACCESS_KEY and AWS_SECRET_ACCESS_KEY repository secrets and delete the associated user in AWS, if it was solely used to deploy your blog.

Conclusion

Migrating from IAM secret and access keys to OpenID Connect (OIDC) for our GitHub Actions workflow helps enhance the security and management of our deployment.

By leveraging OIDC over the traditional IAM methods, we reduce the risk of credential exposure and simplify the process of managing access permissions.

I hope this guide has been helpful in your journey to modernize your AWS deployment practices. If you have any questions or feedback, feel free to reach out. Happy deploying!

What I want to walk through today is removing the public access to our S3 bucket which hosts our static site. We will configure an Origin Access Control to allow only CloudFront to access the S3 bucket. There’s one caveat to our use case, but we can resolve that using CloudFront Functions.

We’ll be performing these steps through the AWS Console, but you could likely tweak the CloudFormation template that we created in the previous article.

Disclaimer

The method we are implementing requires the use of a CloudFront function. The Always Free Tier includes 2 million function invocations per month. You should be able to determine cost based on the number of requests you are receiving per month, as each request will invoke our function.

Adding an Origin Access Control policy to the CloudFront distribution

Navigate to your Distribution and click Edit under the Settings. Now go to Origins and click Edit on your existing origin. Scroll down and change Origin access from Public to Origin access control settings (recommended). Now click Create new OAC. Leave all the values as their defaults and click Create.

Make sure your newly created Origin access control is selected in the dropdown.

Click the Copy policy button.

Clicking the conveniently placed Go to S3 bucket permissions link will open a new tab, so don’t forgot to go back and click Save changes on this page.

Updating S3 Bucket Policy

Scroll down to the Bucket Policy and click the Edit button. Paste in the policy you copied from the previous step and click Save changes At this point, we’ll be disabling both the static website hosting feature and public access on our S3 bucket.

Disabling static website hosting

Navigate to Properties of your S3 bucket and scroll down to Static website hosting, then click Edit. Go ahead and Disable the feature and click Save changes.

Disabling public access

Navigate to the Permissions of your S3 bucket and scroll down to the Block public access (bucket settings), then click Edit. Check Block all public access and click Save changes. Type confirm in the confirmation popup and click Confirm.

Now there’s one caveat to this method. With static website hosting, if we had subdirectories on our website, they would be served properly. Unfortunately with this method, we receive an Access Denied page.

Let’s fix that…

Setting up a CloudFront Function

Navigate to the CloudFront dashboard and click Functions, then click Create function.

Name your function, then leave the defaults selected, and click Create function.

Scroll down to Function code and paste the following code in the editor. This code will append index.html to URIs, which will give us the desired behavior.

function handler(event) {
    var request = event.request;
    var uri = request.uri;

    if (uri.endsWith('/')) {
        request.uri += 'index.html';
    } else if (!uri.includes('.')) {
        request.uri += '/index.html';
    }

    return request;
}

Click Save changes. Once you do this, you’ll see a gray pill labeled “Unpublished” next to the Publish tab. Click on Publish, then click Publish function.

Attach the CloudFront Function to a Distribution

Now, if you scroll down, you should see an Associated distributions section. Click the Add association button so that we can associate the function with our distribution.

Pick your distribution from the Distribution dropdown list.

Select Viewer request from the Event type dropdown list.

Choose Default(*) as your cache behavior.

Now click Add association.

That’s all there is to this. We’ve locked down our S3 bucket so that only CloudFront can access it.

An alternative to CloudFront functions would be to implement Lambda@Edge, however it would be more expensive (and overkill for our case) as you would pay for both the number of requests and the duration that your function runs.

As application security testers, we encounter scenarios where clients blacklist the default Burp Collaborator domains due to security and privacy concerns. Frequent enough that it warrants the configuration of a private Burp Collaborator server.

In this article, I will guide you through the process of configuring a private Burp Collaborator instance on an AWS Elastic Compute Cloud (EC2) instance while integrating Let’s Encrypt for SSL certificate security. I’ll conclude by validating the environment with a test in Burp Suite.

Let’s proceed!

Prerequisites

Before I begin, ensure you have the following prerequisites in place:

• AWS Account: You need an active Amazon Web Services (AWS) account.
• Hosted Zone in AWS Route 53: Your domain doesn’t need to be registered through AWS, but you need to manage DNS for the domain through Route 53.
• Burp Suite Professional: You’ll need the professional or enterprise version to run a collaborator instance.

Overview

For this tutorial, we will configure Burp Collaborator to run on a subdomain:

Domain: fatzombi.com

Subdomain: burp.fatzombi.com

To maintain transparency, redacted screenshots won’t be featured, except for masking my home IP address. The subdomain and EC2 instance will be terminated after publishing.

Disclaimer: Please be aware that using AWS Route 53 and EC2 services may result in charges. AWS pricing is usage-based, and data transfer costs, resource usage, and data storage can all contribute to your expenses. It is essential to monitor and manage your usage to avoid unexpected costs.

Launching an EC2 instance

This section guides you through setting up a new Amazon Elastic Compute Cloud (EC2) instance. This instance will serve as the foundation for your private Burp Collaborator setup.

1. Log in to the AWS Management Console
2. Search for EC2 under the compute section of the AWS services search bar.
3. Click on Instances in the EC2 dashboard.
4. Click on the Launch Instances button in the top-right corner of the Instances page.

Now you can define options for the EC2 VM.

Name: Burp Collaborator

Application and OS Images: Ubuntu 22.04 LTS 64-bit (x86)

Instance Type: t2.micro for the sake of this tutorial

Key pair (login): Select an existing key pair or click the Create new key pair button to upload the SSH key you’ll use to access the VM.

Network Settings, Storage, and Advanced Details: Defaults are fine for the sake of this tutorial.

Click on Launch Instance, and within a few seconds, you can access the instance by clicking on the instance ID.

Make note of the Public IPv4 address and Private IPv4 addresses for Burp Collaborator and DNS configurations.

Since the configuration happens over SSH, confirm access to the VM via its Public IPv4 address.

ssh ubuntu@54.82.28.144

Configuring Inbound Ports to EC2

Burp Collaborator requires specific ports to be open on your EC2 VM. In the EC2 instance summary, navigate to the Security tab and click on the Security group.

Clicking on the Edit inbound rules button will allow us to enter more rules than the default configuration. Add the following nine rules with a source of Anywhere-IPv4.

• TCP/80
• TCP/443
• TCP/25
• TCP/587
• TCP/465
• TCP/9090
• TCP/9443
• TCP/53
• UDP/53

Configuring DNS records with Route 53

As previously mentioned, we’re configuring Burp Collaborator to run on a subdomain.

Domain: fatzombi.com

Subdomain: burp.fatzombi.com

Access the Hosted Zone in the AWS Management Console for the domain.

Create an A record for burp.fatzombi.com pointing to the Public IPv4 address of your EC2 VM.

Click the Create record button under the hosted zone.

For now, that’s all the DNS records we need to add. We’ll add a TXT record in the next step, then an NS and A record in the following step; otherwise Let’s Encrypt won’t successfully generate the certificate.

To confirm DNS propagation, access your EC2 via its subdomain, bearing in mind that DNS propagation may take time. You can use a website such as WhatsMyDns.net to monitor the progress.

Configuring Let’s Encrypt SSL Certificate

To generate the Let’s Encrypt certificate, install certbot via snapd.

sudo apt update
sudo apt install snapd
sudo snap install certbot --classic
sudo ln -s /snap/bin/certbot /usr/bin/certbot

Generate a certificate, customizing the -m and -d parameters with your email address and domain respectively.

sudo certbot certonly -m phil@fatzombi.com \
-d "burp.fatzombi.com,*.burp.fatzombi.com" \
--server https://acme-v02.api.letsencrypt.org/directory \
--manual --agree-tos --no-eff-email --preferred-challenges dns-01

This command’s output will instruct you to create a DNS TXT record with a specific name and value.

Update Route 53 with this record. Set a low Time to Live (TTL) since you’ll be modifying this value.

You’ll note that you don’t want to copy and paste the record name verbatim, or it will duplicate your domain suffix and Let’s Encrypt won’t detect the record.

Wait a few minutes or use a tool such as Dig under the Google Admin Toolbox to validate the TXT record, which returns the value you just created.

At this point, click Enter in your terminal, where you’ll be prompted to enter another DNS TXT record.

However, it’ll have the same record name, but we can’t add two records with the same name.

What you need to do is edit the existing TXT record and add the additional value on a new line. Make sure the values are separated by a line break, or the validation will fail.

Confirm both values are present using a tool like the Google Admin Toolbox.

With these steps complete, you should have a certificate and key file saved to your system.

Allow Collaborator to be Authoritative for your subdomain

Burp Collaborator will generate random subdomains under your domain. To enable this, set the Collaborator server as authoritative for the subdomain.

Add two records to your hosted zone in Route 53:

NS record: Ensures that queries for the subdomain are resolved by your collaborator server.

A record: Resolves your name server to the Public IPv4 address of your collaborator server.

The next record will ensure that ns1.burp.fatzombi.com resolves to your EC2 server.

Install, Configure, and Run Burp Collaborator

At this stage, with all your DNS records configured, it’s time to install, configure, and run Burp Collaborator.

Installing Burp Suite Professional

Log in to your PortSwigger dashboard and download the Linux version of Burp Suite.

Transfer the file to your EC2:

scp burpsuite_pro_linux_v2023_10_2_2.sh ubuntu@54.82.28.144:/home/ubuntu/

Return to your EC2 VM and make the file executable:

sudo chmod u+x burpsuite_pro_linux_v2023_10_2_2.sh

Now, proceed to install Burp Suite, which mainly involves accepting the default prompts:

sudo ./burpsuite_pro_linux_v2023_10_2_2.sh

Configuring Collaborator

For storing your configuration and miscellaneous files, create a directory under /usr/local/collaborator.

sudo mkdir /usr/local/collaborator
cd /usr/local/collaborator

Contents of collaborator.config

I won’t delve into the details of the configuration, as PortSwigger provides the collaborator.config example with comprehensive property explanations. However, the values you need to modify are as follows:

• serverDomain
• eventCapture.localAddress
• eventCapture.publicAddress
• eventCapture.ssl.certificateFiles
• poling.localAddress
• polling.publicAddress
• polling.ssl.certificateFiles
• dns.interfaces.name
• dns.interfaces.localAddress
• dns.interfaces.publicAddress

Save the file with the contents under /usr/local/collaborator/collaborator.config.

{
    "serverDomain": "burp.fatzombi.com",
    "workerThreads": 10,
    "eventCapture": {
        "localAddress": "172.31.8.236",
        "publicAddress": "54.82.28.144",
        "http": {
            "ports": 80
        },
        "https": {
            "ports": 443
        },
        "smtp": {
            "ports": [
                25,
                587
            ]
        },
        "smtps": {
            "ports": 465
        },
        "ssl": {
            "certificateFiles": [
                "/etc/letsencrypt/live/burp.fatzombi.com/privkey.pem",
                "/etc/letsencrypt/live/burp.fatzombi.com/cert.pem",
                "/etc/letsencrypt/live/burp.fatzombi.com/fullchain.pem"
            ]
        }
    },
    "polling": {
        "localAddress": "172.31.8.236",
        "publicAddress": "54.82.28.144",
        "http": {
            "port": 9090
        },
        "https": {
            "port": 9443
        },
        "ssl": {
            "certificateFiles": [
                "/etc/letsencrypt/live/burp.fatzombi.com/privkey.pem",
                "/etc/letsencrypt/live/burp.fatzombi.com/cert.pem",
                "/etc/letsencrypt/live/burp.fatzombi.com/fullchain.pem"
            ]
        }
    },
    "metrics": {
        "path": "metrics-ss",
    },
    "dns": {
        "interfaces": [
            {
            "name": "ns1.burp.fatzombi.com",
            "localAddress": "172.31.8.236",
            "publicAddress": "54.82.28.144"
            }
        ],
        "ports": 53
    },
    "logLevel": "INFO"
}

Running Collaborator

With a working configuration, you can now launch Collaborator.

/usr/local/BurpSuitePro/BurpSuitePro -Xmx200m --collaborator-server --collaborator-config=/usr/local/collaborator/collaborator.config

Testing with Burp Suite

Return to your desktop, launch Burp Suite Professional, and navigate to the Collaborator tab under Settings -> Project. Modify the Server Location and Polling location, noting that the latter includes port 9443.

Click the Run health check… button to verify your setup, you should observe a series of green successes.

Send a payload containing the Collaborator-generated URL, and we can see the HTTP and DNS requests in the Collaborator tab.

Taking it further

As of now, your Burp Collaborator is operational, but you can take additional steps:

• Create a service file for systemd to ensure Burp Collaborator starts on boot.
• Set up an Elastic IP on the EC2 VM to prevent changes in your Public IPv4 address during reboots.
• Configure a cronjob for Let’s Encrypt certificate renewal.
• Run Collaborator as a lower-privileged user instead of root.

Conclusion

In the world of application security testing, the ability to adapt to the unique requirements and constraints of your clients is a hallmark of a skilled tester. Often, this means dealing with clients who have stringent security policies that necessitate bypassing default settings, such as the use of the standard Burp Collaborator domains.

Through this tutorial, I’ve equipped you with the knowledge to overcome such challenges and create a private and secure Burp Collaborator on an Amazon Elastic Compute Cloud (EC2) instance within AWS.

Now, it’s your turn to strengthen your cybersecurity arsenal and enhance the security posture of the web applications you assess. Embrace the power of a private Burp Collaborator, and lead the charge in securing the digital world, one application at a time.

Happy testing!

Overview of Ansible

Ansible is an open source infrastructure as code tool that allows you to provision software, perform configuration management, and handle application deployments. Similar to Terraform, it uses a declarative language that is simple to write. Additionally, there are thousands of modules, most can be found at https://docs.ansible.com/ansible/latest/collections/index_module.html. In this article, we will explore how to use Ansible to automate the configuration of our VMs.

If you want to skip ahead, you can find the Ansible playbook over at https://github.com/fatzombi/ansible-homelab.

Our Current VM setup

If you’re following along through all the parts of this series, there is one modification that I made since the previous article. This change replaces the HomeBridge VM with a new host with the sole purpose of running docker contains, since that is very popular inside homelabs. You can either browse the repository listed above or copy the pihole.tf file and save it as docker.tf and make the necessary modifications todocker.tf and vars.tf file.

Additionally, if you’re following along with this article, you may see a 10.0.5.x network referenced in screenshots, due to a collision on my production network. Wherever you see this, assume the network is 192.168.1.x per our configuration.

Configuring Ansible on Proxmox

Proxmox doesn’t ship with Ansible, but it is in the Debian repositories. We can quickly install it by running the following:

apt install ansible

Now, let’s create a directory that will contain our Ansible playbook and configuration, ensuring we create it as a git repository so that we can track changes over time.

mkdir ansible-homelab
cd ansible-homelab
git init

OR, if you like, you can clone the entire playbook.

git clone https://github.com/fatzombi/ansible-homelab
cd ansible-homelab

Creating an Ansible playbook

1. Define our inventory. This is the collection and grouping of hosts which we want to execute our playbook against.
2. Configure settings for how Ansible will talk to each of the hosts.
3. Create a playbook that defines the relationships between our hosts and the roles we will define in the next step.
4. Create roles for our servers. a. Debian role, this is our base role that we want applied to all our servers. b. PiHole role, this is a service specific role that will configure our PiHole server. c. Docker role, this is a service specific role that will configure our Docker host.

The Inventory

First off, we need to define the inventory of our hosts that Ansible will run tasks against. While there are modules which allow a dynamic inventory to be provided by Terraform, we will be statically defining our inventory for this article.

echo -e "[pihole]\n192.168.1.210\n" >> hosts
echo -e "[docker]\n192.168.1.212\n" >> hosts

Ansible Configuration

Based on our setup, we need to modify a couple of settings that Ansible will use to communicate with our servers.

Ansible will read files from a group_vars directory. These files are where we can define variables which can be used throughout our playbook. The variables can be applied to all hosts, or we can associate the variables with specific roles. For example, we can define DNS_SERVER_1 for all hosts, and we could define SQL_DEFAULT_PASSWORD specifically for hosts that inherit the database role of database.

For this article, we will apply a minimal configuration, such that Ansible uses Python3 and SSH.

mkdir group_vars
echo "ansible_connection: ssh" >> group_vars/all
echo "ansible_python_interpreter: /usr/bin/python3" >> group_vars/all

Defining our Playbook

For simplicity, we will have a Debian role, which is applied to all of our servers, then we will define individual roles for each additional server. Notice, we can make use of the all value for the hosts definition in our first task.

To achieve this, we need to create the following contents in a playbook.yml file.

---

- name: Ansible playbook for all our hosts
  hosts: all
  roles:
    - debian
  remote_user: debian
  become: yes

- name: Ansible playbook for configuring pihole
  hosts: pihole
  roles:
    - pihole
  remote_user: debian
  become: yes

- name: Ansible playbook for configuring homebridge
  hosts: homebridge
  roles:
    - homebridge
  remote_user: debian
  become: yes
  
- name: Ansible playbook for configuring docker
  hosts: docker
  roles:
    - docker
  remote_user: debian
  become: yes

Configuring tasks

Debian tasks

Often there is software which you’d like installed on all your hosts. While this could have been handled inside the base cloud-init image, it isn’t always the best option for several potential reasons.

Therefore, this will be the core function of our debian role. We want to update apt and install a few packages across all our hosts.

mkdir -p roles/debian/tasks

Now we can place the following contents inside roles/debian/tasks/main.yml.

---
- name: 'Update APT package cache'
  apt:
    update_cache: yes
    upgrade: safe
  
- name: Install packages
  apt:
    package:
      - git
      - apt-transport-https
      - ca-certificates
      - wget
      - software-properties-common
      - gnupg2
      - curl
      - python3-pip
    state: present

Pihole tasks

Whether you’re familiar with the PiHole installation process, there are several steps that we must take.

1. Cron must be installed on our host.
2. We need to clone the PiHole repo.
3. Create a setupVars.conf configuration file.
4. Install PiHole.
5. Reboot PiHole.
6. Then we’d go ahead and configure our DNS to use PiHole.

mkdir -p roles/pihole/tasks/

Now we can place the following contents inside roles/pihole/tasks/main.yml.

---

- name: Install packages
  apt:
    package: 
      - cron
      - git
    state: present
  tags: pihole

- name: 'Clone pihole repo'
  ansible.builtin.git:
    repo: 'https://github.com/pi-hole/pi-hole'
    dest: /home/debian/pi-hole
  tags: pihole

- name: 'Create pihole config directory'
  file: path=/etc/pihole/ state=directory
  tags: pihole

- name: 'Copy setupVars.conf'
  copy: src=templates/setupVars.conf.j2 dest=/etc/pihole/setupVars.conf
  tags: pihole

- name: 'Install pi-hole'
  ansible.builtin.shell: ./basic-install.sh --unattended
  args:
    chdir: "/home/debian/pi-hole/automated install"
  tags: pihole

- name: 'Reboot'
  shell: sleep 2 && reboot
  async: 1
  poll: 0
  ignore_errors: true
  tags: pihole

- name: "Wait for server to come back"
  local_action: wait_for host={{ ansible_host }} port=22 state=started delay=10
  become: false

But, as you can see, we referenced a templates/setupVars.conf.j2 file. In our ansible-homelab directory, we’ll create a new directory called templates to house this file.

mkdir templates/
touch templates/setupVars.conf.j2

This file should contain your own configuration for PiHole. For this article, you can use the following basic configuration. The password encrypted here is pihole.

QUERY_LOGGING=true
INSTALL_WEB=true
WEBPASSWORD=5536c470d038c11793b535e8c1176817c001d6f20a4704fa7908939be82e2922

Docker tasks

Now with our Docker host, we will need to install the Docker engine, setup a docker-compose.yml to configure our containers, then run docker-compose to start the containers.

mkdir -p roles/docker/tasks/
mkdir -p roles/docker/templates/docker_data
touch roles/docker/tasks/main.yml

The contents of main.yml are as follows:

---

- name: Add Apt signing key from official docker repo
  apt_key:
    url: https://download.docker.com/linux/debian/gpg
    state: present

- name: add docker official repository for Debian Bullseye
  apt_repository:
    repo: deb [arch=amd64] https://download.docker.com/linux/debian bullseye stable
    state: present

- name: Index new repo into the cache
  become: yes
  apt:
    name: "*"
    state: latest
    update_cache: yes
    force_apt_get: yes

- name: actually install docker
  apt:
    name: "docker-ce"
    state: latest

- name: Install docker-compose
  get_url: 
    url: https://github.com/docker/compose/releases/download/v2.2.3/docker-compose-linux-x86_64
    dest: /usr/local/bin/docker-compose
    mode: 'u+x,g+x'

- name: install docker pip package
  pip:
    name:
      - docker
      - docker-compose
  tags: docker

- name: create directory to house our docker-compose
  file: 
    path: /home/debian/docker/ 
    state: directory
    owner: debian
    group: debian
  tags: docker

- name: copy docker-compose.yml
  copy: 
    src: templates/docker.conf.j2 
    dest: /home/debian/docker/docker-compose.yml
    owner: debian
    group: debian
  tags: docker

- name: create docker_data directory
  file: 
    path: /home/debian/docker/docker_data/ 
    state: directory
    owner: debian
    group: debian
  tags: docker

- name: copy supporting files
  copy: 
    src: roles/docker/templates/docker_data/ 
    dest: /home/debian/docker/docker_data/
    owner: debian
    group: debian
  tags: docker

- name: Run docker-compose
  docker_compose:
    project_src: /home/debian/docker/
    build: no
  tags: docker

The docker_data subdirectory can contain whatever files you want to bring over for your docker configuration. This could contain additional configuration files for containers you have defined in your docker.conf.j2 template.

version: "3.7"

services:
    portainer:
      container_name: portainer
      image: portainer/portainer-ce:latest
      restart: unless-stopped
      ports:
        - 8000:8000
        - 9000:9000
      volumes:
        - /var/run/docker.sock:/var/run/docker.sock
        - /home/debian/docker/docker_data/:/data

Running our playbook

All of that hard work will pay off as soon as we execute the following command. Again, ignore any 10.0.5.x addresses in the screenshots or command output. For this article, that is equivalent to 192.168.1.x.

ansible-playbook -i hosts --become -c debian playbook.yml

If you receive any errors, you can add -vvv to the previous command for verbose output.

Once the command has completed, we’ll receive a play recap. This is an aggregated summary of the status of our tasks executed.

If we navigate to http://192.168.1.210/admin, we will be presented with the pihole login page. Again, pihole was the encrypted password

Additionally, if we navigate to http://192.168.1.212:9000/, we will be presented with Portainer’s initial password setup screen, from there we can access our containers inside Portainer.

Future developments

• Make use of Ansible Secrets. While the pihole password was encrypted, its value is still stored in version control.
• Explore more modules for specific uses. For example, the ssh_config and user_module modules.
• Implement more containers under docker-compose. For example, implement a reverse proxy such as traefic to access all your services by subdomain.
• Implement a CI/CD pipeline.
• Look into Ansible Tower

Conclusion

In conclusion, I hope you have seen the value of using automation to build our homelab up with infrastructure as code. This three-part series hopefully has provided you with a solid foundation for building and managing your homelab environment. With Ansible as a powerful tool in your arsenal, you can now automate repetitive tasks, ensure consistent configurations, and scale your homelab with ease. Embrace the possibilities and continue to enhance (or break) your homelab!

Overview of Terraform

Terraform is an open-source infrastructure as code tool that allows you to define and manage your infrastructure as code. This code is a declarative language that is simple to write. In this article, we will explore how to use Terraform to automate the creation of VMs in Proxmox, using the previously generated cloud-init image. But before we can do that, we need to set up Proxmox to allow Terraform to authenticate and interact with the API.

Configuring API Users, Permissions, and Tokens in Proxmox

After logging into Proxmox, under the Datacenter menu, click on Users under the Permissions menu. Here, we will click the Add button to configure a new user. Create a PAM standard user with a username and ensure that it’s enabled.

Now, under the same Permissions menu, we want to click on API Tokens. Create a new API Token by selecting the user we just created, ensure that Privilege Separation is enabled, and name the Token ID: terraform_token_id. As you’ll be warned, make sure you copy down the Token Secret, as it will only be displayed once.

Now go back up to the Permissions menu, and we’ll add new user permissions by clicking the User Permission menu item from the Add button dropdown.

We’re going to add three, one for the path of /, /storage/local, and /storage/local-lvm. Your paths may vary depending on how your storage is configured. The roles and paths are below.

/                    terraform@pam   PVEVMAdmin
/storage/local       terraform@pam   Administrator
/storage/local-lvm   terraform@pam   Administrator

Now, Terraform will have access to Proxmox’s API to create the VMs based on our configuration file.

The last thing we need to do on Proxmox’s end is install terraform. It’s not in the official repos for Debian, so we’ll add a new repository and install it onto Proxmox.

# Install terraform
apt install lsb-release
curl -fsSL https://apt.releases.hashicorp.com/gpg | apt-key add -
echo "deb [arch=$(dpkg --print-architecture)] https://apt.releases.hashicorp.com $(lsb_release -cs) main" >> /etc/apt/sources.list.d/terraform.list
apt update && apt install terraform

Creating a Terraform Configuration

For brevity, we’ll only be configuring two virtual machines, but the process is repeatable based on however many VMs you want to host.

If you don’t want to work through these steps manually, you can clone the repository located at https://github.com/fatzombi/terraform-homelab.

We’ll be creating the following directory structure and files:

~/terraform-homelab
    - main.tf
    - vars.tf
    - pihole.tf
    - homebridge.tf

main.tf

This file contains a provider, in this case we’re using the telmate/proxmox provider to interact with the Proxmox API. You won’t have to change anything within this file unless you wish to enable TLS verification.

terraform {
  required_providers {
    proxmox = {
      source = "telmate/proxmox"
      version = "2.7.4"
    }
  }
}

provider "proxmox" {
  pm_api_url = vars.api_url
  pm_api_token_id = var.token_id
  pm_api_token_secret = var.token_secret
  pm_tls_insecure = true # Change to false if you have your 
}

vars.tf

This file contains all the variables that are used in main.tf and the respective .tf files for each VM we define. The last variables are for configuring static IP addresses on our VMs, but this step is optional.

variable "ssh_key" {
    default = "ssh-rsa ....."
}
variable "api_url" {
    # The Proxmox Web UI address, with /api2/json added to it.
    default = "https://192.168.1.15:8006/api2/json" 
}
variable "proxmox_host" {
    # The name of the Proxmox server listed under Datacenter
    default = "..." 
}
variable "template_name" {
  default = "debian-11-cloudinit-template"
}
variable "token_id" {
  default = "terraform@pam!terraform_token_id"
}
variable "token_secret" {
  default = "..." # Enter your API Secret here
}
variable "ipconfig_pihole" {
  default = "ip=192.168.1.16/24,gw=192.168.1.1"
}
variable "ipconfig_homebridge" {
  default = "ip=192.168.1.17/24,gw=192.168.1.1"
}

pihole.tf

Now we can define the resources allocated to our pihole vm. The primary areas of interest will be cores, sockets, memory, and disk.size.

resource "proxmox_vm_qemu" "pihole" {
  count = 1
  name = "pihole"
  target_node = var.proxmox_host

  clone = var.template_name
  agent = 1
  os_type = "cloud-init"
  cores = 1
  sockets = 1
  cpu = "host"
  memory = 1024
  scsihw = "virtio-scsi-pci"
  bootdisk = "scsi0"
  disk {
    slot = 0
    size = "8G"
    type = "scsi"
    storage = "local-lvm"
    iothread = 1
  }
  
  network {
    model = "virtio"
    bridge = "vmbr0"
  }
  
  lifecycle {
    ignore_changes = [
      network,
    ]
  }
  
  ipconfig0 = var.ipconfig_pihole
  
  sshkeys = <<EOF
  ${var.ssh_key}
  EOF
}

homebridge.tf

This file will be similar to our pihole.tf; however, there’s an additional section where we pass through a USB device from the host to the VM.

resource "proxmox_vm_qemu" "homebridge" {
  count = 1
  name = "homebridge"
  target_node = var.proxmox_host

  clone = var.template_name
  agent = 1
  os_type = "cloud-init"
  cores = 2
  sockets = 1
  cpu = "host"
  memory = 8192
  scsihw = "virtio-scsi-pci"
  bootdisk = "scsi0"
  disk {
    slot = 0
    size = "50G"
    type = "scsi"
    storage = "local-lvm"
    iothread = 1
  }
  
  network {
    model = "virtio"
    bridge = "vmbr0"
  }
  
  lifecycle {
    ignore_changes = [
      network,
    ]
  }
  
  serial {
    id = 0
    type = "/dev/tty0"
  }
  
  ipconfig0 = var.ipconfig_homebridge
  
  sshkeys = <<EOF
  ${var.ssh_key}
  EOF
}

Deploying VMs with Terraform

Now that we have our Terraform configuration, there are only a few more steps we need to take.

• terraform init
• terraform plan
• terraform apply

⠀If everything was successful, you should be able to see your newly created virtual machines in Proxmox. For example, here are the details of our pihole VM.

Conclusion

In this article, we have covered how to configure Proxmox to enable Terraform to automatically create virtual machines based on our previously generated cloud-init image. We started by creating a new user and generating an API token with the appropriate permissions to allow Terraform to interact with our Proxmox instance. We then installed and configured the Proxmox Terraform provider, which allowed us to define our virtual machines as infrastructure-as-code using Terraform. We created a basic Terraform configuration that defined our VMs, its resources, and attached our cloud-init image to it. Finally, we ran the terraform apply command, which created our new virtual machines with the defined specifications.

By using Terraform, we can automate the process of creating virtual machines and ensure consistent configurations across all of our instances. With the Proxmox Terraform provider, we can easily manage our infrastructure as code and make changes in a repeatable, predictable way. In the next article, we will cover how to use Ansible to perform software-related tasks such as installing dependencies for a particular role the VM will offer.

For this process, we will perform these actions from our Proxmox instance.

Creating a base image with Cloud-init

First, we need to download and extract a cloud-init image, in my case, I want to use Debian as my base.

cd /var/lib/vz/template/iso/
wget https://cloud.debian.org/images/cloud/bullseye/latest/debian-11-generic-amd64.tar.xz 
tar -xf debian-11-generic-amd64.tar.xz

Let’s go ahead and rename the raw disk, and delete the original archive we downloaded.

mv disk.raw debian-11-generic-amd64.img
rm debian-11-generic-amd64.tar.xz

There are a few dependencies that we’ll need installed in our Proxmox instance.

echo "deb http://download.proxmox.com/debian bullseye pve-no-subscription" >> /etc/apt/sources.list.d/pve-enterprise.list
apt update -y && apt install libguestfs-tools -y

At this time, you could perform additional actions against the VM. See virt-customize for more options. However, in our case, we will handle additional configurations with Ansible.

Now we can create a template from this Cloud-init disk.

qm create 9001 --name "debian-11-cloudinit-template" --memory 2048 --cores 2 --net0 virtio,bridge=vmbr0
qm importdisk 9001 debian-11-generic-amd64.img local-lvm
qm set 9001 --scsihw virtio-scsi-pci --scsi0 local-lvm:vm-9001-disk-0
qm set 9001 --boot c --bootdisk scsi0
qm set 9001 --ide2 local-lvm:cloudinit
qm set 9001 --serial0 socket --vga serial0
qm set 9001 –-agent 1
qm template 9001

Manually using the base image to create a Virtual Machine

At this point, we can click on More -> Clone under this template in Proxmox.

If all is successful, the newly created VM will appear in our Virtual Machine list and it should boot successfully.

Conclusion

In conclusion, configuring a base image with Cloud-init is a crucial step in automating your homelab using Proxmox, Terraform, and Ansible. With Cloud-init, we can automate the initial setup and configuration of virtual machines, ensuring consistent configurations across all instances. By following the steps outlined in this article, you can easily create a Cloud-init base image from a Debian distribution and customize it to suit your needs. Additionally, you can create a template from this Cloud-init disk and use it to create multiple virtual machines. With this base image, you can save time and effort when deploying new virtual machines. In the next article, we will cover how to deploy virtual machines using Terraform.

Before we dive into the details, it’s assumed that you are familiar what a homelab is, if you don’t, I recommend you checkout the following resources:

• Stumbled into /r/homelab? Start Here!
• An Introduction to Homelabs

Additionally, it’s important to note that this series won’t cover the installation and configuration of Proxmox itself. Proxmox is a powerful and versatile hypervisor that allows you to run multiple virtual machines or containers on a single physical host. It’s widely used in both home and enterprise settings (not as much as VMWare), and offers a wide range of features and capabilities. However, setting up Proxmox can be a complex process that requires a solid understanding of virtualization, networking, and system administration.

Assuming you have Proxmox up and running, the rest of this series will focus on using Cloud-init, Terraform, and Ansible to create a base image/template, deploy virtual machines, and perform software-related tasks such as installing dependencies and configuring software to run on each virtual machine. By automating these tasks, you’ll be able to quickly and easily set up a homelab that meets your specific needs, without having to manually configure each virtual machine. An added benefit is we can easily recreate the environment if something were to break. So, let’s get started!

Part 1: Configuring a base image with Cloud-Init

Part 2: Deploying VMs with Terraform

Part 3: Automating with Ansible

To begin, we’ll highlight the main technologies being used and the role they play in our solution.

Next, I’ll dive into the roles of each AWS offering used in this architecture, including how CloudFormation is used to create and manage the infrastructure for our website, how Route 53 and Certificate Manager are used to manage our domain, DNS records, and TLS certificates, and how CloudFront will be used for content delivery and caching.

Lastly, I’ll discuss how GitHub Actions are used to trigger the workflows in AWS that deploy updates to our website.

Solution Overview

Setting up AWS CloudFormation

AWS CloudFormation is a powerful service that allows you to create and manage your infrastructure as code. Using CloudFormation, we can define our infrastructure using templates written in either JSON or YAML, then we can create and update those resources using awscli or AWS Management Console. If you are familiar with docker-compose, this may be familiar to you.

In our solution, we are using AWS S3, Route 53, CloudFront, and Certificate Manager. These are all the resources that we will define in our YAML template, which our stack will be composed of.

CloudFormation Stack Template

# website-stack.yml 
Parameters:
  DomainName:
    Description: The domain of the website
    Type: String

Resources:
  HostedZone:
    Type: AWS::Route53::HostedZone
    Properties:
      Name: !Ref DomainName
      HostedZoneConfig:
        Comment: Managed by CloudFormation
 
  WebsiteBucket:
    Type: AWS::S3::Bucket
    Properties:
      BucketName: !Ref DomainName
      WebsiteConfiguration:
        IndexDocument: index.html
        ErrorDocument: error.html
  
  Certificate:
    Type: AWS::CertificateManager::Certificate
    DependsOn: HostedZone
    Properties:
      DomainName: !Ref DomainName
      SubjectAlternativeNames:
      - !Sub 'www.${DomainName}'
      ValidationMethod: DNS
      DomainValidationOptions:
        - DomainName: !Ref DomainName
          HostedZoneId: !Ref HostedZone
        - DomainName: !Sub 'www.${DomainName}'
          HostedZoneId: !Ref HostedZone
  
  Distribution:
    Type: AWS::CloudFront::Distribution
    Properties:
      DistributionConfig:
        Aliases:
        - !Ref DomainName
        - www.!Ref DomainName
        Origins:
        - DomainName: !Sub '${WebsiteBucket}.s3.amazonaws.com'
          Id: S3Origin
          S3OriginConfig:
            OriginAccessIdentity: !Sub 'origin-access-identity/cloudfront/${WebsiteBucket}'
        DefaultCacheBehavior:
          TargetOriginId: S3Origin
          ViewerProtocolPolicy: redirect-to-https
          Compress: true
          ForwardedValues:
            QueryString: false
        ViewerCertificate:
          AcmCertificateArn: !Ref Certificate
          SslSupportMethod: sni-only
  
  RecordSetGroup:
    Type: AWS::Route53::RecordSetGroup
    Properties:
      HostedZoneId: !Ref HostedZone
      RecordSets:
      - Name: !Ref DomainName
        Type: A
        AliasTarget:
          HostedZoneId: Z2FDTNDATAQYW2
          DNSName: !GetAtt Distribution.DomainName
      - Name: !Sub 'www.${DomainName}'
        Type: CNAME
        ResourceRecords:
        - !GetAtt Distribution.DomainName

The CloudFormation template creates the five resources we mentioned above:

1. A Route53 Hosted Zone, which will be used to store the DNS records for our domain.
2. A S3 bucket called example.com that will contain the files for our Jekyll site. We are configuring the bucket as a static website, with an IndexDocument of index.html and an ErrorDocument of error.html.
3. A Certificate Manager certificate that will be used to secure our website with TLS. This certificate will be valid whether a user enters example.com or www.example.com to access our website.
4. A CloudFront distribution that points to our S3 bucket and supports both example.com and www.example.com.
5. A RecordSetGroup which creates the DNS A and CNAME records required to map our domain to the CloudFront distribution, which in turn points to our S3 bucket which contains our static website.

Now that we have the contents of our CloudFormation stack, save it to your file system. Go over to AWS Management Console and search for the CloudFormation product.

Deploying the stack

Click on Create stack and upload the YAML file as our template.

Click on Next, name our stack however you’d like and enter your domain name. Then click Next, Next, then Submit.

Now we can monitor the Events tab to check the progress of the resources CloudFormation is creating. The majority of the resources should be created within 5 minutes. However, the certificate will likely remain in CREATE_IN_PROGRESS status for up to an hour. At this time, you can visit each of the resources in AWS Management Console. If we navigate to the Certificate Manager, we will likely see that our domains are Pending validation.

After a couple of minutes, we should see the CNAME records created under our Route 53 Hosted Zone.

Unfortunately, Certificate Manager can take a few hours to validate our domain.

At this point, we can continue with the tutorial. If your DNS servers haven’t updated, you can navigate to your S3 bucket in AWS Management Console, click the Properties tab, scroll to the bottom and copy the Bucket website endpoint URL under the *Static website hosting section. If you navigate to that URL, you’ll receive a 403 Forbidden response. This is expected, as we haven’t deployed our Jekyll files to the bucket yet.

To test, you can upload a file to your S3 bucket. You’ll need to select the file and click on Make public using ACL, under the Actions dropdown. Then click on the Copy URL button and navigate to that page, you should see the contents of your file.

Setting up GitHub Secrets and Actions

In this tutorial, I am assuming you have an IAM user created that will be used for GitHub Actions. In that case, you’ll need to have your AWS Access Key ID and Secret Access Key values. If you don’t, you’ll want to check out one of the following articles to obtain this:

• https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users_create.html
• https://vasko.io/jekyll/aws/2017/08/03/jekyll-s3-cloudfront.html
• https://betterprogramming.pub/build-a-static-website-with-jekyll-and-automatically-deploy-it-to-aws-s3-using-circle-ci-26c1b266e91f

Create GitHub Secrets

Our GitHub Action will need permission to deploy to our S3 bucket and CloudFront distribution. We leverage the AWS Access Key ID and AWS Secret Access Key values to perform this. However, this is not data that we want to commit directly into our git repository or GitHub Actions file.

Navigate to your git repository on GitHub, then the Settings tab, and click on the New repository secret under the Secrets -> Actions option.

You will need to create three secrets.

• Access Key ID
  • Name = ‌AWS_ACCESS_KEY_ID
  • Value = Insert your value here.
• Secret Access Key
  • Name = ‌AWS_SECRET_ACCESS_KEY
  • Value = Insert your value here.
• CloudFront Distribution ID
  • Name = CLOUDFRONT_DISTRIBUTION_ID
  • Value = Insert your value here.

The ‌CLOUDFRONT_DISTRIBUTION_ID can be found directly under the CloudFront Distributions page in AWS Management Console.

We will refer to the names of both secrets in the next step.

Create GitHub Actions

There are three main steps that we’ll need our GitHub Action to perform:

1. Build the Jekyll website.
2. Sync the files to our S3 bucket.
3. Invalidate the cache of our CloudFront distribution.

You likely can find a third-party action in the GitHub Action Marketplace to merge these actions, but I don’t want to introduce another dependency.

Navigate to your git repository on GitHub and click the New Workflow button under the Actions tab.

Go ahead and click the set up a workflow yourself link and paste the following into the file:

name: Deploy Website

on:
  push:
    branches:
      - main

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
    - uses: actions/checkout@v2
    - uses: ruby/setup-ruby@v1
      with:
        ruby-version: '2.7'
    - run: gem install bundler
    - run: bundle install
    - run: bundle exec jekyll build
    - name: Configure AWS Credentials
      uses: aws-actions/configure-aws-credentials@v1
      with:
        aws-access-key-id: ${{ secrets.AWS_ACCESS_KEY_ID }}
        aws-secret-access-key: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
        aws-region: us-east-1
    - name: Deploy to S3
      run: |
        aws s3 sync _site s3://example.com --acl public-read --delete
    - name: Invalidate CloudFront Cache
      run: |
        aws cloudfront create-invalidation --distribution-id ${{ secrets.CLOUDFRONT_DISTRIBUTION_ID }} --paths "/*"

Under the Deploy to S3 task, ensure you update example.com to reflect your domain. Also, update aws-region if you are running in a different region than I am.

Click the Start commit button.

If all was successful, you should see a successful build under the workflow we defined. If a step failed, you can click on the workflow run to find a build log with more details for troubleshooting.

Conclusion

In conclusion, setting up a static website using Jekyll, GitHub Actions, AWS S3, AWS Route 53, AWS Certificate Manager, AWS CloudFront, and AWS CloudFormation can be complex. However, by leveraging AWS CloudFormation to manage the required resources makes it much easier.

At this point, you should have a build pipeline that builds your Jekyll site and deploys it to AWS S3 each time you commit to the main branch. The committed changes to your website should be reflected as the build process completes successfully.

While I didn’t include it in this article, it’s worth noting that we could automate the creation of the IAM users, roles, and policies that are required for the GitHub Action to perform its steps. Additionally, you can modify the GitHub Action to only perform the build and deployment when a pull request is approved.

Lastly, don’t limit yourself to the solution I provided. There are many ways to perform the same outcome, as I’ve demonstrated here. For instance, on one of my client’s projects, I find the build process to be slower than I’d like. Rather than setting up ruby, installing bundler and installing bundles, I found that running a docker container was much quicker for me. This is because the majority of the steps defined in our original GitHub Action are cached in the jekyll/builder image.

steps:
    - uses: actions/checkout@v3
    - name: Build the site in the jekyll/builder container
      run: |
        docker run \
        -v ${{ github.workspace }}:/srv/jekyll -v ${{ github.workspace }}/_site:/srv/jekyll/_site \
        jekyll/builder:latest /bin/bash -c "chmod -R 777 /srv/jekyll && jekyll build --future"
    # ...

My problem

Having been an InfoSec practitioner for several years, I wouldn’t say that I’m set in my ways, but I’ve certainly developed a workflow for security assessments that I’ve grown used to. When I sat down to prepare for the Offensive Security Certified Professional (OSCP) certification, I found their prebuilt VM was greatly hindering that workflow.

Not only were key-bindings problematic between macOS and VMWare Fusion or VirtualBox, but I had no desire to run yet another desktop environment when macOS was perfectly capable. Furthermore, I would have to store a ~60 GB disk image on my MacBook Pro and Time Machine backups, and worry about shared drives and clipboard to make for a seamless experience. Lastly, my documentation process at the time was relying on an application that wasn’t compatible with Linux, which meant I couldn’t do everything inside the Kali VM without changing tools.

At first, I was going to use cloud-init, Terraform, and Ansible for this solution, but that would make more sense if I was creating a VM in my opinion. I use docker, primarily with docker-compose, in my homelab, and recalled X11 Forwarding from my old days of running Gentoo Linux as a daily driver. After some experimentation, I found this solution to be the best for my needs.

Brief roles of products in my solution

Docker

We will use Docker to create an image of Kali Linux which includes any additional tools and configurations that we want.

Docker-Compose

We will use Docker Compose to build our container and configure X11 Forwarding.

XQuartz

We will use XQuartz as an X Window System to display the GUIs running on Kali Linux under our macOS desktop.

Putting it all together

Building our image

First we need to build a docker image containing Kali Linux and additional tools we want, we can create the following Dockerfile to handle that.

# We need to start from somewhere
FROM kalilinux/kali-rolling:latest
ENV DEBIAN_FRONTEND noninteractive

# Bring everything up to date
RUN apt update; apt -y dist-upgrade

# Install whatever we desire
RUN apt-get -y install \
x11-tools \
zsh

# Here you can run additional commands to configure the box
# Create our new user and add it to some groups
RUN useradd -G sudo,video fatzombi -shell /bin/zsh -m
# Create a default password so we can login
RUN echo "fatzombi:fatzombi" | chpasswd

# Clean up packages
RUN apt-get -y autoremove

# Jump to the shell
ENTRYPOINT zsh $@

Running docker build . will create the image for us. If the build fails, you may need to explicitly include additional dependencies for the applications you are installing.

Building a container from our image

Now we could run docker create with arguments, but in my case, I want the configuration to be stored in a docker-compose.yml file that I can commit to version control.

version: "3.7"

services:
  kali:
    build: .
    stdin_open: true # docker run -i
    tty: true        # docker run -t
    container_name: kali
    restart: unless-stopped
    hostname: kali-oscp
    environment:
      - DISPLAY=host.docker.internal:0
      - TERM=xterm-256color
    cap_add:
      - NET_ADMIN
      - SYS_ADMIN

Running docker-compose up -d will attempt to create the container. If successful, you should have a container called kali listed in the output of docker ps.

Don’t mind if your COMMAND and PORTS are different than mine, the important thing is that the container is running.

Entering our new container

Now that our container has been started, we can enter it by running docker exec --user fatzombi --workdir /home/fatzombi/ -it kali /bin/zsh. Don’t forget to use passwd to change the default password that was defined in the Dockerfile.

Displaying GUIs on macOS

All that’s left to do is start XQuartz on macOS and run the following command in the terminal to inform macOS which display should be used for X11 Forwarding. DISPLAY=:0 /opt/X11/bin/xhost + Displaying GUI applications from Kali Linux is now as simple as typing the command of the application in the terminal of the container.

Concluding Thoughts

There are several benefits to this solution:

• Everything I care about can be included in source control, and I don’t need to back up a ~60 GB binary disk image.
• We can streamline our process with Makefiles and shell scripts to increase the efficiency, see further below.
• This solution can be applied to operating systems other than macOS. Additionally, it doesn’t require the Kali container to run locally on macOS, in case you need it to have additional resources.

What else can we do?

Using Makefile to get into the container quicker

Add the following contents into a Makefile:

shell run: open -g /Applications/Utilities/Xquartz.app sleep 2 DISPLAY=:0 /opt/X11/bin/xhost + || TRUE sleep 2 docker start kali docker exec --user fatzombi --workdir /home/fatzombi/ -it kali /bin/zsh

You can now type make in the directory to bring yourself to the container’s shell, or you could place those commands in a shell script and create an alias to quickly enter the environment.

A helpful script might be to perform the image build process, handle the docker-compose and X11 Forwarding steps, and enter the container’s shell.

Mounting volumes from macOS to Kali Linux

By adding the following lines to the docker-compose.yml file, it allows for you to share files between macOS and the Kali container.

volumes:
  - "/Users/fatzombi/Documents:/home/fatzombi/Documents"

Using this technique, you could also share specific dotfiles between macOS and Kali Linux.

Exposing ports

Depending on the assessment, I may find myself forwarding ports from one box to the other. In those situations, it’s helpful to expose ports on the container, which is just as simple as mounting volumes.

ports:
  - 4445:4445:
  - 16001:16001