NeuralWall Rules Kit
reviewed expose_public_https_web_service

Exposing a public HTTPS web service from the Internet to the DMZ

This scenario covers exposing an HTTPS web server hosted in the DMZ and reachable from the Internet. It includes inbound SSL decryption (ssl_inbound_inspection) to enable L7 inspection of encrypted traffic, along with the DNS dependency rules required for the service to function. This scenario is particularly sensitive: the exposed server is a direct target for public-facing application exploitation, payload injection, and use of the service as a C2 relay. Full security profiles (antivirus, IPS, c2_protection, url_filtering, file_control, sandboxing) are mandatory on the main allow rule.

Schema:
1.0.0
Version:
1.0.0
Authors:
NeuralWall Rules Team (NeuralWall)

Trust & attestations

Trust tierreviewed
Loading trust info…
community
reviewed
verified

Next tier: verified

Threat model

Summary
A web service directly exposed to the Internet represents the widest attack surface of a perimeter. The attacker attempts to exploit an application vulnerability (public CVE, injection, misconfiguration) to gain initial access on the DMZ, then move laterally toward the internal network. Without inbound SSL decryption, L7 inspection is blind: antivirus, IPS, and sandboxing see only an opaque stream. With ssl_inbound_inspection, the stream is re-encrypted toward the server after inspection — the server certificate must be imported into the firewall.
Attacker goal
Gain initial access on the DMZ server by exploiting the public HTTPS service, drop a payload or implant, then establish an outbound C2 channel or pivot into the internal network (privilege escalation, lateral movement).
Key controls
ssl_inbound_inspectionipsantivirussandboxingc2_protectionfile_controldns_security

MITRE ATT&CK

Technique Name Tactic
T1190 Exploit Public-Facing Application initial-access
T1071.001 Application Layer Protocol: Web Protocols command-and-control
T1105 Ingress Tool Transfer command-and-control
T1059 Command and Scripting Interpreter execution

Rules

# App ID Action Direction Zones Risk Security profiles Decryption
0 web_browsing allow inbound internet → dmz 4 antivirus, c2_protection, file_control, ips, sandboxing, url_filtering ssl_inbound_inspection
1 dns allow internal dmz → internal 2 dns_security none
2 any_application drop outbound dmz → internet 5

Rule details

Rule 0 — web_browsing (allow)

Rationale

This rule allows inbound HTTPS traffic from the Internet to the DMZ web server. The ssl_inbound_inspection decryption mode is enabled to allow L7 inspection: without it, antivirus, IPS, and sandboxing see an opaque stream and cannot detect exploits or payloads. Security profiles are all set to blocking mode (not just alert) because the attack surface is maximal on a public-facing service. Port 80 is included for HTTP→HTTPS redirection; a server-side redirect rule is recommended in addition.

Application

app_id:
web_browsing
category:
general_internet
risk:
4
depends_on:
dns, ssl

Zones

internet → dmz

direction: inbound

Security profiles

antivirus: action=block c2_protection: action=block, min_severity=low file_control: block_types=pe+elf+script+encrypted_archive, direction=inbound ips: action=block, min_severity=medium sandboxing: enabled=true, file_types=pe+pdf+office+jar+script url_filtering: block_categories=malware+phishing+c2+newly_registered_domain+proxy_avoidance+hacking+compromised, uncategorized_action=block

Decryption

mode=ssl_inbound_inspection

Logging

log_start: false
log_end: true
forwarding → siem_high_priority

Rule 1 — dns (allow)

Rationale

DNS resolution is required for the DMZ web service to function properly (OCSP/CRL resolution for certificate validation, upstream dependencies, updates). The flow is restricted to a trusted internal resolver (not directly to the Internet) to prevent DNS rebinding and limit the exfiltration surface. The dns_security profile with sinkhole blocks DNS tunneling that could be used as a covert C2 channel from a compromised server. Decryption not applicable: standard DNS over UDP is not encrypted.

Application

app_id:
dns
category:
networking
risk:
2

Zones

dmz → internal

direction: internal

Security profiles

dns_security: action=block, sinkhole=true

Decryption

mode=none

Logging

log_end: true
forwarding → siem_default

Rule 2 — any_application (drop)

Rationale

Deny-by-default rule: any traffic initiated from the DMZ toward the Internet that is not explicitly covered by an allow rule above is silently dropped. This rule is critical to contain a compromised DMZ server and prevent the establishment of an outbound C2 channel (T1071.001) or data exfiltration. The 'any_application' app_id with 'unknown' category is justified here: this is a catch-all blocking rule, not an allow rule.

Application

app_id:
any_application
category:
unknown
risk:
5

Zones

dmz → internet

direction: outbound

Logging

log_start: true
log_end: true
forwarding → siem_high_priority