Skip to main content
Version: 2.8.1

🌐 Network Policy

Monitor and control network traffic at the application level with Jibril's network policy engine. Block suspicious connections, alert on unauthorized access, and enforce network security rules for domains and IP addresses.

📍 Default Location​

/etc/jibril/netpolicy.yaml

🚀 Quick Start​

1️⃣ Create Policy File​

# Create network policy file
sudo vi /etc/jibril/netpolicy.yaml

2️⃣ Enable in Configuration​

# In config.yaml
features:
  - netpolicy

feature_options:
  netpolicy:
    file: /etc/jibril/netpolicy.yaml

events:
  - dropip

🎯 Configuration Structure​

The network policy uses a simple allow/deny model with explicit rule lists:

network_policy:
  # Default action: allow | deny
  policy: allow

  # Always allow these (optional)
  allow:
    - 127.0.0.0/8           # CIDR blocks
    - 8.8.8.8               # IP addresses
    - google.com            # Domain names

  # Always deny these (optional)
  deny:
    - 192.168.100.0/24      # CIDR blocks
    - example.com           # Domain names

🔓 policy: allow​

Allow by default, deny specific rules

  • Allow all traffic by default
  • Explicitly block known threats
  • Best for most environments

🔒 policy: deny​

Deny by default, allow specific rules

  • Block all traffic by default
  • Explicitly allow trusted destinations
  • Zero-trust network model

📋 Rule Types​

Network policy rules support three formats in the same list:

🔢 CIDR Blocks​

allow:
  - 127.0.0.0/8       # Localhost
  - 192.168.0.0/16    # Private networks
  - 10.0.0.0/8        # Private networks
  - ::1/128           # IPv6 localhost

📍 IP Addresses​

deny:
  - 203.0.113.5       # Specific IPv4
  - 8.8.8.8           # DNS servers
  - 2001:db8::1       # Specific IPv6

🌐 Domain Names​

deny:
  - malware-site.com
  - phishing-domain.net
  - suspicious-tracker.org

Note: Domain rules block the resolved IPs, not DNS resolution itself.

🛡️ Common Configurations​

🔓 Standard Protection (Recommended)​

Allow by default, block known threats:

network_policy:
  policy: allow

  allow:
    # Internal networks (always allow)
    - 127.0.0.0/8
    - 192.168.0.0/16
    - 10.0.0.0/8
    - 172.16.0.0/12

    # DNS servers
    - 8.8.8.8
    - 1.1.1.1

  deny:
    # Block malicious domains
    - malware-domain.com
    - phishing-site.net
    - cryptominer-pool.org

Use case: Production environments with threat intelligence feeds

🏰 Zero-Trust Mode​

Deny by default, allow only trusted destinations:

network_policy:
  policy: deny

  allow:
    # Localhost
    - 127.0.0.0/8

    # Internal infrastructure
    - 10.0.1.0/24
    - 10.0.2.0/24

    # Trusted external services
    - trusted-api.company.com
    - cdn.example.com
    - github.com

Use case: High-security environments, sensitive workloads, compliance requirements

🔍 Understanding Rule Precedence​

Rules Override Default​

Explicit rules always take precedence over the default policy:

network_policy:
  policy: allow  # Default: allow all

  deny:
    - 8.8.8.8    # Blocked (explicit)

8.8.8.8 is blocked despite default allow

CIDR Specificity​

More specific CIDR rules override broader ones:

allow:
  - 192.168.0.0/16   # Allow entire range

deny:
  - 192.168.1.100    # Block specific IP

192.168.1.100 is blocked (more specific)

📝 Complete Example​

View production-ready configuration
network_policy:
  # Default action: allow most traffic
  policy: allow

  # Always allow these (whitelist)
  allow:
    # Loopback
    - 127.0.0.0/8
    - ::1/128

    # Private networks
    - 192.168.0.0/16
    - 172.16.0.0/12
    - 10.0.0.0/8

    # Link-local
    - 169.254.0.0/16
    - fe80::/10

    # DNS servers
    - 8.8.8.8           # Google DNS
    - 8.8.4.4           # Google DNS
    - 1.1.1.1           # Cloudflare DNS
    - 9.9.9.9           # Quad9 DNS

    # Trusted services (if needed)
    - github.com
    - docker.io

  # Always deny these (blacklist)
  deny:
    # Known malicious domains
    - malware-c2-server.com
    - phishing-campaign.net
    - cryptominer-pool.org

    # Known malicious IPs
    - 203.0.113.0/24    # Documentation range (example)

    # Suspicious services
    - torrent-tracker.com
    - piracy-site.org

🎓 Best Practices​

✅ Recommended​

  • 📊 Start with policy: allow to understand traffic
  • 🔄 Use threat intelligence feeds for deny lists
  • 📝 Always allow localhost and internal networks
  • 📝 Remember to allow your own IP address(es)
  • 🌐 Allow necessary DNS servers
  • 🧪 Test policy changes in staging first
  • 📋 Document each rule's purpose
  • 🔍 Monitor dropip events regularly

⚠️ Avoid​

  • ❌ Using policy: deny without thorough testing
  • ❌ Blocking internal networks accidentally
  • ❌ Forgetting to allow DNS servers
  • ❌ No documentation of deny rules
  • ❌ Overly restrictive rules breaking apps
  • ❌ Deploying to production without staging tests
  • ❌ Ignoring dropip event patterns

📊 Monitoring Policy Events​

Network policy violations generate dropip events. Enable them in the configuration file to track blocked connections:

# View policy events in real-time
sudo tail -f /var/log/jibril.out | jq 'select(.metadata.kind == "dropip")'

# Count blocked connections
sudo cat /var/log/jibril.out | jq 'select(.metadata.kind == "dropip")' | wc -l

🔧 Typical Workflow​

  1. Start permissive: Deploy with policy: allow and minimal deny rules
  2. Observe: Monitor dropip events and network behavior
  3. Refine: Add known threats to deny list
  4. Test: Validate in staging environment
  5. Deploy: Roll out to production
  6. Iterate: Continuously update based on threat intelligence

🚀 Next Steps​