https://github.com/cimpress-mcp/red-x
Check for abandoned/misconfigured delegations in your Route53 hosted zones.
https://github.com/cimpress-mcp/red-x
aws dns lambda route53
Last synced: about 2 months ago
JSON representation
Check for abandoned/misconfigured delegations in your Route53 hosted zones.
- Host: GitHub
- URL: https://github.com/cimpress-mcp/red-x
- Owner: Cimpress-MCP
- License: other
- Created: 2017-08-17T15:30:14.000Z (about 8 years ago)
- Default Branch: master
- Last Pushed: 2023-03-04T02:35:40.000Z (over 2 years ago)
- Last Synced: 2025-04-14T06:37:54.419Z (6 months ago)
- Topics: aws, dns, lambda, route53
- Language: Python
- Size: 1.84 MB
- Stars: 4
- Watchers: 5
- Forks: 2
- Open Issues: 12
-
Metadata Files:
- Readme: README.md
- License: LICENSE
Awesome Lists containing this project
README
red-x
=====
>The Red X is a warning placard affixed to a vacant building structure
alerting first responders to the existence of structural or interior hazards
in the building that warrant extreme caution when conducting interior
firefighting or rescue operations with entry occurring only for known life
hazards.
In this case, Red-X alerts us of abandoned/misconfigured domain delegations
or records pointing at inactive domains from managed services (cloudfront.net or
elasticbeanstalk.com)
## Why?
Preventing misconfigured delegations should be pretty self-explanatory - you
need your customers to be able to quickly and reliably resolve your domain
names from anywhere in the world.
Preventing abandoned delegations is also very important. For one, to prevent
Cloud resource sprawl from draining your coffers and your operations time. But,
perhaps more importantly, to prevent DNS zone hijacking.
### What's zone hijacking?
Due to the shared infrastructure of Route53 (and other managed AWS services,
like CloudFront), it's surprisingly easy to take control of a misconfigured
or abandoned zone, CNAME, or A ALIAS.
The particular attack Red-X attempts to prevent is zone hijacking through
brute-forcing nameservers. Since Route53 assigns you four nameservers when you
create a hosted zone, an attacker that happens upon an abandoned zone can hijack
that zone by brute-force creating a hosted zone for that domain again and again
until they've matched one or more of the nameservers it was delegated to.
You can find a better explanation [here](https://thehackerblog.com/the-orphaned-internet-taking-over-120k-domains-via-a-dns-vulnerability-in-aws-google-cloud-rackspace-and-digital-ocean/index.html).
### What's record hijacking?
Similar to zone hijacking, records pointing to domains from managed services like
elasticbeanstalk.com or cloudfront.net can be abandoned and later used to hijack
the domain.
## What it does
* Fetches configuration from EC2 Parameter Store
* Gets a list of all records in the configured Route53 Hosted Zone
* Pulls out all delegations (NS records)
* Iterates over the delegations
* Checks each of the nameservers in the delegation.
* Ensures each nameserver returns the expected result for NS records.
* No response implies the delegation is abandoned.
* Mismatched results implies misconfiguration or zone hijacking.
* Pulls out all A and CNAME records pointing to beanstalk or cloudfront domains
* Warns about CNAMEs, since A ALIAS records are more correct
* Alerts if the elasticbeanstalk.com or cloudfront.net address doesn't resolve.
Then, it can notify you in two ways:
1. GitLab issues.
* Open an issue in the configured project for each delegation error.
* Close any open issues no longer associated with delegation errors.
2. SNS notifications.
* Send a summary of delegation errors to the configured SNS topic.
## Configuration
Configuration for this function is controlled by the EC2 Parameter Store.
Setting up your configuration (and updating it later) is simplified using
the [`configure.py`](./configure.py) script at the root of this repo.
Running `python configure.py` with credentials for your account will let you
create or update your Red-X configuration.
**NOTE**: If you intend to use the GitLab integration, you should only do
this _after_ you have deployed the function, as it will attempt to use the KMS
key created by CloudFormation to encrypt your API token.
## Setup/CloudFormation
Deploying this function will create the following resources (in addition to
the 'usual' Serverless resources):
* A KMS key to encrypt secret configuration info (i.e. GitLab API Token)
* Aliased as 'alias/red-x/settings'
* An SNS topic `Red-X-Reports` for publishing delegation error summaries
## Deployment
This is a Python3.6 Lambda function, since the DNS library for node isn't great.
So you're kind of straddling two worlds, here.
```
$ npm install
$ virtualenv env
$ source ./env/bin/activate
$ ./node_modules/.bin/sls deploy
```
Then, optionally, you can run `python configure.py` to set up the parameters in
the EC2 Parameter Store.
You can also invoke the function locally with `./node_modules/.bin/sls invoke local -f check_delegations`.