112 lines
4.3 KiB
Markdown
112 lines
4.3 KiB
Markdown
|
---
|
||
|
|
inclusion: manual
|
||
|
|
---
|
||
|
|
|
||
|
|
# Firewall Exception Request Template
|
||
|
|
|
||
|
|
When the user needs to generate a Red/Blue Firewall Exception Request (LNE > Lab Network Request ticket), use this template structure. Adapt the content based on the specific service requiring network access.
|
||
|
|
|
||
|
|
## Template Structure
|
||
|
|
|
||
|
|
Every firewall request document must include these sections in order:
|
||
|
|
|
||
|
|
### 1. Title and Purpose
|
||
|
|
|
||
|
|
```
|
||
|
|
# <Service Name> Firewall Exception Request — <Application Name>
|
||
|
|
|
||
|
|
Reference material for the LNE > Lab Network Request ticket required by
|
||
|
|
<reason for the block / policy reference>. All targets are <source of truth
|
||
|
|
for the destination list>.
|
||
|
|
```
|
||
|
|
|
||
|
|
### 2. Destinations Table
|
||
|
|
|
||
|
|
| Cluster/Service | Destination IP/Host | Port(s) | Protocol | Encryption |
|
||
|
|
|---|---|---|---|---|
|
||
|
|
| *Name of the service* | *IP or hostname* | *port(s)* | TCP/UDP | *TLS, PLAINTEXT, etc.* |
|
||
|
|
|
||
|
|
Include notes about connection type: stateful TCP, client-initiated outbound, ephemeral source port, etc.
|
||
|
|
|
||
|
|
### 3. Source
|
||
|
|
|
||
|
|
- Source host: `<hostname>`
|
||
|
|
- Source IP: `<IP address>`
|
||
|
|
- Source port: `ephemeral / 1024-65535`
|
||
|
|
|
||
|
|
### 4. Requested Firewall Rules
|
||
|
|
|
||
|
|
Provide both per-IP rules and summary rules (if LNE accepts them):
|
||
|
|
|
||
|
|
```
|
||
|
|
Rule N
|
||
|
|
Source: <source IP>/32 ephemeral
|
||
|
|
Destination: <dest IP>/32 tcp/<port>
|
||
|
|
Protocol: TCP
|
||
|
|
Action: allow
|
||
|
|
```
|
||
|
|
|
||
|
|
### 5. Suggested Ticket Text
|
||
|
|
|
||
|
|
Follow the LNE template fields exactly:
|
||
|
|
|
||
|
|
> **Summary:** Red/Blue FW Request: <Source App> → <Destination Service> (<brief description>)
|
||
|
|
>
|
||
|
|
> 1. **Reason:** What the application does and why it needs this access.
|
||
|
|
> 2. **Drivers:** Operational, compliance, or business justification. State explicitly: no PCI, no CPNI if applicable.
|
||
|
|
> 3. **Application purpose:** What the app does with the data it gets from the destination. Mention rate limits, compliance with API policies, etc.
|
||
|
|
> 4. **Source/destination IPs and ports:** Summary of flows (count, protocol, direction).
|
||
|
|
> 5. **Impact if denied:** What breaks, what the fallback is, and why the fallback is worse.
|
||
|
|
>
|
||
|
|
> **Environment Overview**
|
||
|
|
> 1. Data: What data flows over this connection. Explicitly state no PII/PCI/CPNI if true.
|
||
|
|
> 2. OS: Operating system on the source host.
|
||
|
|
> 3. OS compliance / risk acceptance: Fill in if applicable.
|
||
|
|
> 4. Architecture: Brief description of the application architecture.
|
||
|
|
>
|
||
|
|
> **External access:** State whether the source host is internet-exposed or internal-only.
|
||
|
|
>
|
||
|
|
> **Mitigation controls:** How access to the source host is controlled, how credentials are stored, what security measures are in place.
|
||
|
|
|
||
|
|
### 6. Evidence to Attach
|
||
|
|
|
||
|
|
Describe what test script to run and what log files to attach. The log should provide timestamped proof of the connection behavior (success or failure) from the source host.
|
||
|
|
|
||
|
|
### 7. Notes
|
||
|
|
|
||
|
|
Any additional context: auth methods, TLS settings, environment differences between UAT and production, etc.
|
||
|
|
|
||
|
|
---
|
||
|
|
|
||
|
|
## Key Principles
|
||
|
|
|
||
|
|
- Be specific about IPs, ports, and protocols. Avoid vague descriptions.
|
||
|
|
- Explicitly state what data does NOT flow (no PII, no PCI, no CPNI) to speed risk assessment.
|
||
|
|
- Reference test evidence that proves the current behavior without speculation.
|
||
|
|
- If a test script exists, reference it and describe its output format.
|
||
|
|
- Use `/32` for single-host rules. Only use CIDR aggregates if you explain what extra IPs are included.
|
||
|
|
- State whether TLS is used. If PLAINTEXT, explain why (e.g., internal Kafka brokers with no client auth).
|
||
|
|
- Mention rate limiting and compliance with any API usage policies if applicable.
|
||
|
|
|
||
|
|
---
|
||
|
|
|
||
|
|
## Existing Firewall Request Documents
|
||
|
|
|
||
|
|
Reference these for examples of completed requests:
|
||
|
|
|
||
|
|
- `docs/kafka-firewall-request.md` — ZBL Impairment Map → Charter Kafka telemetry feeds (STAMP + DAA RPHY Prod). TCP PLAINTEXT to specific broker IPs on non-standard ports.
|
||
|
|
- The Jira request (generated in chat) — STEAM Dashboard → jira.charter.com:443. Single HTTPS flow with Basic Auth service account.
|
||
|
|
|
||
|
|
---
|
||
|
|
|
||
|
|
## Checklist Before Submitting
|
||
|
|
|
||
|
|
- [ ] All destination IPs/hostnames and ports are listed
|
||
|
|
- [ ] Source host IP is filled in (not placeholder)
|
||
|
|
- [ ] Protocol and encryption are specified for each flow
|
||
|
|
- [ ] Ticket text follows the LNE template fields
|
||
|
|
- [ ] Data classification is stated (PII/PCI/CPNI or lack thereof)
|
||
|
|
- [ ] Test evidence is attached or referenced
|
||
|
|
- [ ] Impact-if-denied section explains the operational consequence
|
||
|
|
- [ ] Mitigation controls describe how the source host is secured
|