Network-Guides

main

DNS

Repo

---

DNS

| Knowledge Base| Install | Test&Debug | Dynamic Updates & RNDC | Attack Vectors & Scenario | Protection |

Protection

Preventing DNS Cache Poisoning and DNS Spoofing

• Use of TSIG Authentication: Transaction SIGnature (TSIG) authentication adds a layer of security to DNS transactions by ensuring that DNS messages are authenticated and integrity-checked. This prevents attackers from injecting false DNS records into a DNS server’s cache.
• Implement DNSSEC: DNS Security Extensions (DNSSEC) signs DNS data with digital signatures, ensuring that DNS responses cannot be tampered with. DNSSEC verifies the authenticity of DNS data, preventing attackers from successfully poisoning DNS caches.
• Limit Zone Transfers: Limiting zone transfer requests can prevent attackers from obtaining copies of a DNS zone file, which they could then use to poison DNS caches.
• Regularly Monitor and Audit DNS Servers: Regular monitoring and auditing of DNS servers can help identify suspicious activities, such as unexpected changes to DNS records or unusual patterns of DNS queries.
• Update DNS Software: Keeping DNS software up-to-date ensures that any known vulnerabilities are patched, reducing the risk of DNS cache poisoning attacks.

---

Practical Example of DNS Cache Poisoning Prevention Let’s consider a scenario where you’re setting up a DNS server using BIND9. To mitigate the risk of DNS cache poisoning, you should implement TSIG authentication for DNS transactions. Here’s how you can configure TSIG authentication in BIND9:

• Generate a Key: First, generate a shared secret key for TSIG authentication.
• This can be done using the dnssec-keygen tool:

$ dnssec-keygen -a HMAC-SHA512 -b 128 -n HOST mykey

This command generates a pair of keys (mykey.+165+000001.private, mykey.+165+000001.key) and a key file (Kmykey.+165+000001.key) that you’ll use for TSIG authentication.

Configure TSIG Authentication in BIND9:

Edit your named.conf file to include the generated key and configure TSIG authentication for your zone transfers and dynamic updates.

key "mykey" {
    algorithm hmac-sha512;
    secret "your_generated_key_here";
};

zone "example.com" {
    type master;
    file "/etc/bind/db.example.com";
    allow-update { key "mykey"; };
};

Replace “your_generated_key_here” with the content of the .key file generated by dnssec-keygen.

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)

  Firewall

• 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:

block in proto { tcp, udp } on egress port domain

This rule blocks outgoing traffic on ports typically associated with DNS (domain name system) queries, reducing the risk of DNS amplification attacks.

2. Restrict DNS Queries to Trusted Sources

• PF/OpenSense Configuration:

pass in on em0 proto udp to port domain from any to <trusted-dns-server-ip> keep state

Replace 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. 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

• Best Practice: Periodically review and update your PF/OpenSense firewall rules to reflect changes in your network topology, threat landscape, and security requirements.

---

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:

$ sudo nano /etc/bind/named.conf

• try to fetch it:

  $ dig @localhost badsite
  

  ;; ANSWER SECTION:
  badsite.                86400    IN      CNAME   .
  

---

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.

 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

---

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 by the National Security Agency (NSA) and the Cybersecurity & Infrastructure Security Agency (CISA), published in May 2021 by defense.gov, provides comprehensive information on selecting a protective DNS service (PDNS).

Provider	Akamai®	BlueCat®	Cisco®	Cloudflare®	EfficientIP™	HYAS™	Infoblox®	Neustar®	Nominet®
PDNS	ETP	Networks DNS Edge®	Umbrella DNS SE	Gateway	DNS Guardian	Protect	BloxOne® Threat Defense Cloud	UltraDNS	Protective DNS

---

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

cloudflare alternative:

• with cloudflare DNS you basically have two options:
  • 1. use a providers PDNS as your secondary DNS / use forwarding
  • 1. 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

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

DDOS-Protection

• cloudflare DDOS-Protection thanks to loadbalancing and overcapacity infrastructure

---

Enhanced Security and Performance Strategies for Web Applications in Kubernetes

1. Container Security:

• Regularly update container images to patch vulnerabilities.
• Use security policies (e.g., PodSecurityPolicies) to restrict container capabilities.
• Implement automated scanning tools for detecting vulnerabilities in container images.

2. Network Segmentation:

• Isolate containers from critical network components.
• Limit communication between containers and host systems.
• Utilize micro-segmentation technologies for fine-grained control over network traffic.

3. Monitoring and Auditing:

• Monitor network traffic for anomalies using advanced analytics tools.
• Regularly audit container configurations and network settings.
• Set up alerting mechanisms for unusual activity that could indicate a security breach.

4. Rate Limiting:

• Implement rate limiting on API endpoints to protect against DDoS attacks and ensure fair usage.
• Configure ingress controllers or service meshes like Istio or Linkerd to enforce rate limits based on request rates and sizes.

5. Data Pipeline Management with Apache Kafka:

• Deploy Apache Kafka as a StatefulSet for high availability and scalability in processing large volumes of real-time data.
• Ensure data encryption both in transit and at rest within Kafka clusters.
• Implement client authentication and authorization mechanisms to secure access to Kafka topics.

6. Additional Considerations:

• Regularly review and update security policies and configurations to address new threats and vulnerabilities.
• Conduct periodic penetration testing and red team exercises to identify and mitigate potential weaknesses.
• Invest in training and awareness programs for development and operations teams to promote a culture of security.

---

Knowledge Base

Install

Test&Debug

Dynamic Updates & RNDC

Attack Vectors & Scenario

Protection