From bc66c030d5c96d91fe6f888358131ea06b0de9d6 Mon Sep 17 00:00:00 2001 From: Erik Grafendorfer Date: Mon, 22 Dec 2025 12:47:05 +0100 Subject: [PATCH] added initial description of DNS in AttackBed --- docs/source/development/dns.rst | 21 +++++++++++++++++++++ docs/source/index.rst | 1 + 2 files changed, 22 insertions(+) create mode 100644 docs/source/development/dns.rst diff --git a/docs/source/development/dns.rst b/docs/source/development/dns.rst new file mode 100644 index 00000000..83a757b2 --- /dev/null +++ b/docs/source/development/dns.rst @@ -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. + diff --git a/docs/source/index.rst b/docs/source/index.rst index d5a03d18..891956cd 100644 --- a/docs/source/index.rst +++ b/docs/source/index.rst @@ -51,3 +51,4 @@ AttackBed Documentation development/overview development/attacker development/firewall + development/dns