Update readme.md

ji-podhead · Jun 8, 2024 · 31d5c1e · 31d5c1e
1 parent 28a9038
commit 31d5c1e
Showing 1 changed file with 146 additions and 17 deletions.
diff --git a/docs/DNS/protection/readme.md b/docs/DNS/protection/readme.md
@@ -1,5 +1,6 @@
 
 
+
  | [main](https://ji-podhead.github.io/Network-Guides) | [DNS](https://ji-podhead.github.io/Network-Guides/DNS) | [Repo](https://github.com/ji-podhead/Network-Guides/) |
 
 ---
@@ -50,11 +51,12 @@ Replace "your_generated_key_here" with the content of the .key file generated by
 
 By implementing TSIG authentication and regularly updating your DNS software, you can significantly reduce the risk of DNS cache poisoning and DNS spoofing attacks. 
 Remember, the effectiveness of these measures depends on the overall security posture of your DNS infrastructure, including secure network configurations and regular monitoring.
-
+- complete german guide: [Sicherer Zonen Transfer mit BIND9 (TSIG Zone Transfer)](https://www.twilight-networks.com/wiki/Sicherer_Zonen_Transfer_mit_BIND9_%28TSIG_Zone_Transfer%29)
 ---
 ### Firewall
-These recommendations are tailored to work with PF (Packet Filter), a popular open-source firewall for BSD-based systems, and OpenSense, a comprehensive security suite designed for OPNsense, an open-source network security platform.
-Firewall Configuration for DNS Security
+
+- Configuring your firewall correctly is a crucial step in securing your network against DNS-related attacks.
+
 **1. Block Unnecessary Ports and Protocols**
 
 - PF/OpenSense Configuration:
@@ -74,37 +76,164 @@ pass in on em0 proto udp to port domain from any to <trusted-dns-server-ip> keep
 
 > Replace <trusted-dns-server-ip> with the IP address of your trusted DNS server(s). This rule allows DNS queries only to specified, trusted DNS servers, blocking queries to any other destination.
 
-**3. Enable DNSSEC Validation**
 
-- General Recommendation: While PF/OpenSense does not directly handle DNSSEC validation, enabling DNSSEC on your DNS resolver configuration ensures that DNS responses are validated against signed records, providing protection against DNS spoofing.
 
-**4. Monitor and Log DNS Traffic**
+
+**3. Monitor and Log DNS Traffic**
 
  - PF/OpenSense Configuration:
 
 ```
 pass in on em0 proto udp to port domain flags S/SA synproxy state
 ```
 > This rule enables SYN proxying for DNS traffic, logging attempts to perform DNS amplification attacks without actually forwarding the traffic. Combine this with log analysis tools to monitor for suspicious activity.
+> 
+**4. Regularly Update Your Firewall Rules**
 
-**5. Use TSIG Authentication for DNS Transactions**
+- Best Practice: Periodically review and update your PF/OpenSense firewall rules to reflect changes in your network topology, threat landscape, and security requirements.
 
-- General Recommendation: Although PF/OpenSense does not natively support TSIG authentication, configuring your DNS server (e.g., BIND9) to require TSIG for zone transfers and dynamic updates provides an additional layer of security against DNS cache poisoning.
+---
+## Response Policy Zone (RPZ)
+***scenario***
+The DNS service recognizes the destination of the domain `badsite` as dangerous. 
+> - Instead of providing the unmodified response leading to the dangerous location, the service modifies the response.
+
+Depending on the configuration, the modified response could lead to a safe location, display a warning page, return a DNS error code like NXDOMAIN or NODATA, or provide no response at all.
+
+***how to***
+- create a file called `blocked.domains.db`
+>```
+>$TTL    86400
+>@       IN      SOA     ns.example.com. admin.example.com. (
+ >                     2024060801 ; Serial
+ >                     3600         ; Refresh
+ >                     1800         ; Retry
+ >                     604800        ; Expire
+ >                     86400 )       ; Minimum TTL
+>;
+>@       IN      NS      ns.example.com.
+>ns      IN      A       192.0.2.1 ; IP of your nameserver
+>badsite IN      CNAME .
+>```
+
+- add the following line to `/etc/bind/named.conf`:
+> - `include "/etc/bind/rpz/blocked.domains.db";`
+
+- restart the server:
+
+>  ```Bash 
+>sudo nano /etc/bind/named.conf
+>``` 
+
+- try to fetch it:
+>```Bash
+>dig @localhost badsite
+>```
+>  >```
+>  >;; ANSWER SECTION:
+>  >badsite.                86400    IN      CNAME   .
+>  >```
 
-**6. Regularly Update Your Firewall Rules**
+---
+### PDNS (protective DNS)
+- PDNS complements and enhances the functionality of standard DNS by adding an extra layer of security. Traditional DNS primarily translates human-readable domain names into IP addresses, facilitating communication over the internet.
+
+- PDNS operates by intercepting DNS queries and checking them against a database of known malicious sites. This process involves comparing every DNS request with threat intelligence data, which includes information gathered from various sources such as security research findings, artificial intelligence, and machine learning applications that monitor the dark web and other sources for the latest cyber threats. If a DNS query matches an entry in the database of blacklisted sites, the PDNS service can block the request, preventing users from accessing the malicious site 
+
+- In essence, PDNS does not replace the traditional DNS but rather builds upon it by providing an additional layer of security. It does not merely remove bad addresses from being cached; instead, it actively prevents access to those addresses by intercepting DNS queries and applying filters based on threat intelligence. 
+
+ ```mermaid
+ sequenceDiagram
+    participant User as User
+    participant Browser as Browser
+    participant PDNS as Protective DNS
+    participant DNSResolver as DNS Resolver
+    participant MaliciousSite as Malicious Site
+
+    User->>Browser: Wants to visit a website
+    Browser->>PDNS: Sends DNS query for the domain
+    Note right of PDNS: Checks against Threat Intelligence Database
+    PDNS->>DNSResolver: Queries DNS for the domain
+    DNSResolver-->>PDNS: Returns IP address if exists
+    Note right of PDNS: Domain not in TI Database
+    PDNS->>User/Browser: Returns NXDOMAIN (Domain does not exist)
+    Note right of PDNS: Domain matches TI Database
+    PDNS->>User/Browser: Blocks access (NXDOMAIN)
+    Note right of PDNS: Domain is malicious
+```
 
-- Best Practice: Periodically review and update your PF/OpenSense firewall rules to reflect changes in your network topology, threat landscape, and security requirements.
+---
 
-***Integrating with OpenSense***
+### Understanding RPZ in PDNS
+
+-   **RPZ Zones**: In PDNS, RPZ zones are defined similarly to regular DNS zones but contain special instructions for handling matching queries. These zones can be loaded from local files or fetched from remote servers, depending on the administrator's configuration.
+
+-   **Policy Actions**: Within an RPZ zone, you can specify what action to take when a DNS query matches a pattern defined in the zone. Common actions include returning an NXDOMAIN response (indicating the domain does not exist), rewriting the response to redirect the user, or simply logging the incident.
+
+-   **Dynamic Updates**: One of the key advantages of using PDNS for RPZ is the ability to dynamically update these zones. This means that as new threats emerge or existing ones are resolved, the RPZ can be updated in real-time to reflect the current state of internet security.
+
+
+***Providers***
+
+- The document [Selecting a Protective DNS Service](https://media.defense.gov/2021/Mar/03/2002593055/-1/-1/0/CSI_Selecting-Protective-DNS_UOO11765221.PDF) by the National Security Agency (NSA) and the Cybersecurity & Infrastructure Security Agency (CISA), [published in May 2021](https://www.defense.gov/), provides comprehensive information on selecting a protective DNS service (PDNS). 
+<div>
+<table border="1">
+    <tr>
+        <th style="text-align:left; width:150px;">Provider</th>
+        <th style="text-align:center; width:100px;">Akamai®</th>
+        <th style="text-align:center; width:100px;">BlueCat®</th>
+        <th style="text-align:center; width:100px;">Cisco®</th>
+        <th style="text-align:center; width:100px;">Cloudflare®</th>
+        <th style="text-align:center; width:100px;">EfficientIP™</th>
+        <th style="text-align:center; width:100px;">HYAS™</th>
+        <th style="text-align:center; width:100px;">Infoblox®</th>
+        <th style="text-align:center; width:100px;">Neustar®</th>
+        <th style="text-align:center; width:100px;">Nominet®</th>
+    </tr>
+    <tr>
+        <td style="text-align:left; width:150px;">PDNS</td>
+        <td style="text-align:center; width:100px;">ETP</td>
+        <td style="text-align:center; width:100px;">Networks DNS Edge®</td>
+        <td style="text-align:center; width:100px;">Umbrella DNS SE</td>
+        <td style="text-align:center; width:100px;">Gateway</td>
+        <td style="text-align:center; width:100px;">DNS Guardian</td>
+        <td style="text-align:center; width:100px;">Protect</td>
+        <td style="text-align:center; width:100px;">BloxOne® Threat Defense Cloud</td>
+        <td style="text-align:center; width:100px;">UltraDNS</td>
+        <td style="text-align:center; width:100px;">Protective DNS</td>
+    </tr>
+</table>
+</div>
+
+---
+### Secure DNS in private homelab scenario
+
+***PDNS***
+- cloudflare it self is no PDNS but it comes with a variety of protection layers: `DNSSEC, DDoS-Protection and Load Balancing `
+
+**alternatives:**
+
+- you basically have two options here:
+	- 1. use a providers PDNS as your secondary DNS / use forwarding
+	- 2. use a providers DNS as your primary DNS 
+		- **Isolate Private DNS Traffic**: Ensure that your private DNS queries do not pass through Cloudflare's public DNS resolver unless explicitly required. This can be achieved by configuring your network or firewall rules to route private DNS queries directly to your PowerDNS Recursor.  
+
+***DNS-Firewall for DDOS-Protection***
+
+- cloudflare: [DNS-Firewall](https://developers.cloudflare.com/dns/dns-firewall/)
 
-- OpenSense offers a graphical interface and additional features that complement PF's capabilities, making it easier to manage complex firewall rules and monitor network traffic.
- - Utilizing OpenSense alongside PF can enhance your ability to detect and respond to DNS-related threats effectively.
-Conclusion
-- Configuring your firewall correctly is a crucial step in securing your network against DNS-related attacks.
-- By following these guidelines and leveraging tools like PF and OpenSense, you can create a robust defense strategy that protects your DNS infrastructure and broader network from common vulnerabilities.
-- Remember, security is an ongoing process; regularly reviewing and adjusting your configurations in response to emerging threats is essential for maintaining a secure environment.
+
+***Enable DNSSEC Validation***
+
+- General Recommendation: While PF/OpenSense does not directly handle DNSSEC validation, enabling DNSSEC on your DNS resolver configuration ensures that DNS responses are validated against signed records, providing protection against DNS spoofing.
+- cloudflare: [cloudflare DNSSEC](https://www.cloudflare.com/de-de/dns/dns-firewall/) 
+
+***DDOS-Protection***
+- [cloudflare DDOS-Protection](https://www.cloudflare.com/de-de/ddos/) thanks to loadbalancing and overcapacity infrastructure
 
 ---
+
+
 ### Enhanced Security and Performance Strategies for Web Applications in Kubernetes