Skip to content

added initial description of DNS in AttackBed #81

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
erik-graf wants to merge 1 commit into
base: main
Choose a base branch
from
Open

added initial description of DNS in AttackBed #81

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
21 changes: 21 additions & 0 deletions docs/source/development/dns.rst
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,21 @@
.. _development_dns:

========
DNS
========

DNS is an important part of some attacks of the scenarios. For that reason there is a server named ``corpdns``, which plays the role of the authoritative DNS server for the public domain attackbed.com of the corporate network and which is targeted by the attacker.

There also is a server named ``inetdns`` (called 'Public DNS' in the diagrams) which plays the analogue of e.g. the Google DNS server 8.8.8.8 in the real world. This server is used by all machines in the AttackBed for actual communication with the Internet and therefore is not manipulated by the attacker. It redirects queries regarding the domain attackbed.com to ``corpdns``.

``corpdns`` holds the records for the domain attackbed.com, and hostnames like fw.attackbed.com. These records point to 192.42.0.254, which is the 'fake internet' address of ``inetfw``, the firewall that is part of the attack scenarios - ``inetfw`` also runs dnsmasq and resolves all queries for the zone attackbed.local. Other DNS queries ``inetfw`` forwards to ``inetdns``.

So for most machines in the scenario ``inetfw`` will be the first DNS server address, which then either resolves the queries (if they're in attackbed.local), or it will forward them to ``inetdns`` - and ``inetdns`` in turn forwards them to ``corpdns``, if they concern attackbed.com, or on to 8.8.8.8.

``inetfw``, ``inetdns`` and ``corpdns`` have IP addresses in the public range 192.42.0.0/16, which is not connected to the actual internet directly, to allow a 'fake' internet to be established - so that the attacks can simulate a real world scenario with public IP addresses more realistically. Traffic in this subnet does NOT get routed over the actual internet, and it is not accessible from the internet.

Example query:

Host puppet wants to know attackbed.com:
The DNS query goes to ``inetfw``, ``inetfw`` forwards it to ``inetdns``, which forwards the query for attackbed.com to ``corpdns``. This returns the IP address back through the chain to host puppet.

1 change: 1 addition & 0 deletions docs/source/index.rst
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -51,3 +51,4 @@ AttackBed Documentation
development/overview
development/attacker
development/firewall
development/dns