Skip to content

Commit 1421137

Browse files
Maddy-CloudflareMaddy-Cloudflare
committed
Add remaining pages
1 parent bdbed63 commit 1421137

File tree

8 files changed

+332
-2
lines changed

8 files changed

+332
-2
lines changed

‎src/content/docs/cloudflare-one/reusable-components/list-types.mdx‎

Lines changed: 18 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,18 @@
1+
---
2+
title: List types
3+
pcx_content_type: concept
4+
---
5+
6+
## Threat intelligence
7+
8+
Cloudflare handles millions of HTTP requests each second and blocks billions of cyber threats each day. Cloudflare uses that data to detect malicious actors on the Internet and turns that information into a list of known malicious IP addresses. Cloudflare also integrates with a number of third-party vendors to augment the coverage.
9+
10+
The threat intelligence feed categories are described in [Managed IP Lists](/waf/tools/lists/managed-lists/#managed-ip-lists). All of these lists are compatible with Magic Firewall.
11+
12+
## IP lists
13+
14+
Use [IP lists](/waf/tools/lists/custom-lists/#ip-lists) to group services in networks, like web servers, or for lists of known bad IP addresses to make managing good network endpoints easier. IP lists are helpful for users with very expansive firewall rules with many IP lists. By default, you can add up to 10,000 IPs across all lists. Refer to [Use an IP list](/cloudflare-one/traffic-policies/packet-filtering/add-rules/#use-an-ip-list) to check an example of how to use an IP list.
15+
16+
## Geo-blocking
17+
18+
Geo-blocking enables you to selectively allow or block traffic to any country. Refer to [Block a country](/cloudflare-one/traffic-policies/packet-filtering/add-rules/#block-a-country) to check an example of how to block a country.

‎src/content/docs/cloudflare-one/reusable-components/magic-firewall-fields.mdx‎ renamed to ‎src/content/docs/cloudflare-one/reusable-components/packet-filtering-fields.mdx‎

Lines changed: 2 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -1,9 +1,9 @@
11
---
2-
title: Magic Firewall fields
2+
title: Packet filtering (Magic Firewall) fields
33
pcx_content_type: reference
44
head:
55
- tag: title
6-
content: Magic Firewall fields
6+
content: Packet filtering fields
77
---
88

99
import { Type } from "~/components";

‎src/content/docs/cloudflare-one/traffic-policies/packet-filtering/best-practices/extended-ruleset.mdx‎

Lines changed: 148 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,148 @@
1+
---
2+
title: Extended ruleset
3+
pcx_content_type: configuration
4+
sidebar:
5+
order: 3
6+
head:
7+
- tag: title
8+
content: Extended suggested ruleset
9+
---
10+
11+
If you are unable to export your current perimeter firewall rules, consider identifying categories of systems or user groups that reside on your Magic Transit prefixes. For example:
12+
13+
- [Endpoints (user devices)](#endpoints-user-devices)
14+
- [Internal routers](#internal-routerfirewall-ip-addresses)
15+
- [Web servers](#web-servers)
16+
- [Non-web servers](#non-web-servers)
17+
18+
For each item above, consider the requirements in terms of their permitted Internet access. For example, permit what is required for legitimate traffic and block the rest.
19+
20+
## Create lists for using Magic Firewall rules
21+
22+
For more information on lists, refer to [Use rule lists](/cloudflare-one/reusable-components/use-rules-list/).
23+
24+
You can also create a list from the dashboard from **Configurations** > **Lists** on your **Account Home**.
25+
26+
## Endpoints (User devices)
27+
28+
Endpoint devices do not operate as servers, which means:
29+
30+
- They receive traffic from standard common ports — for example `80` or `443` — towards their ephemeral ports, above `32768` in modern operating systems (above `1025` in older Windows Server 2003 and Windows XP).
31+
- Connections flow outwards, not inwards, and therefore do not receive TCP SYN or ACK packets.
32+
- They typically only need client TCP and UDP, with no requirement for ingress ICMP.
33+
34+
For example, you can create a list for the combination of generic client TCP and client UDP that allows external pings or traceroutes and a catchall rule for all other protocols and traffic.
35+
36+
Create a list named **Endpoints** and specify the list of endpoints or user IP addresses to reference within the rules.
37+
38+
:::note
39+
Rule 10 in the example ruleset below is acting as a catch-all to block all traffic not permitted in rules 1-3 towards your list of Endpoint IP addresses. If you want to permit other traffic to these destination IP addresses, the new rule must be added before rule 10.
40+
41+
:::
42+
43+
### Suggested rules
44+
45+
**Rule ID**: 1
46+
**Description**: Endpoints (clients) will receive traffic destined for ephemeral ports. Blocks inbound SYN-only traffic. (meaning SYN-ACKs are permitted)
47+
**Match**: `ip.proto eq "tcp" and ip.dst in $endpoints and tcp.dstport in {32768..60999} and not (tcp.flags.syn and not tcp.flags.ack)`
48+
**Action**: Allow
49+
50+
**Rule ID**: 2
51+
**Description**: Endpoints (clients) will receive traffic destined for ephemeral ports
52+
**Match**: `ip.proto eq "udp" and ip.dst in $endpoints and udp.dstport in {32768..60999}`
53+
**Action**: Allow
54+
55+
**Rule ID**: 3
56+
**Description**: Permits ICMP traffic to destination IP addresses in `$endpoints` list with ICMP Types:
57+
58+
- Type 0 = Echo Reply
59+
- Type 3 = Destination Unreachable
60+
- Type 11 = Time Exceeded
61+
62+
**Match**: `ip.proto eq "icmp" and ip.dst in $endpoints and (icmp.type eq 0 or icmp.type eq 3 or icmp.type eq 11)`
63+
**Action**: Allow
64+
65+
**Rule ID**: 10
66+
**Description**: Otherwise deny all traffic to IP’s in `$endpoints` list
67+
**Match**: `ip.dst in $endpoints`
68+
**Action**: Block
69+
70+
## Internal router/Firewall IP addresses
71+
72+
Follow the best practices for internal routers or firewall interface IP addresses on your MT prefixes below.
73+
74+
1. Create [an IP list](/waf/tools/lists/custom-lists/#ip-lists), **Internal routers** for example, with your IP addresses.
75+
2. Block ICMP if it is not needed.
76+
3. Permit GRE/ESP as needed if the devices have GRE/IPsec tunnels via the Internet.
77+
78+
### Suggested rules
79+
80+
**Rule ID**: 1
81+
**Description**: Permit limited ICMP traffic inbound, including:
82+
83+
- Type 0 - Echo Reply
84+
- Type 3 - Destination Unreachable
85+
- Type 8 - Echo
86+
- Type 11 - Time Exceeded
87+
88+
**Match**: `ip.proto eq "icmp" and ip.dst in $internal_routers and ( (icmp.type eq 0 or icmp.type eq 3) or (icmp.type eq 11) or (icmp.type eq 8) )`
89+
**Action**: Allow
90+
91+
**Rule ID**: 2
92+
**Description**: Block all other traffic destined to these IP addresses
93+
**Match**: `ip.dst in $internal_routers`
94+
**Action**: Block
95+
96+
## Web Servers
97+
98+
Web servers require careful consideration of necessary traffic flows. Traffic for the **web server** functionality is required in addition to traffic flows where the web server is acting as a client.
99+
100+
Where possible, permit the required destination IP addresses and ports for web servers and block everything else. Additional services, for example NTP/DNS, may be required along with the ports for the web traffic.
101+
102+
The following is an example of suggested rules, but you should only make changes based on your specific requirements. For example, if you are not proxied by Cloudflare Layer 7 protection and you expect traffic sourced from the web towards your web servers:
103+
104+
1. Create [an IP list](/waf/tools/lists/custom-lists/#ip-lists), **web servers** for example, to list IP addresses for your web servers.
105+
2. Permit traffic for the web server traffic inbound from the Internet.
106+
3. Permit traffic for the infrastructure or client traffic flows from the Internet, for example DNS and NTP.
107+
4. Block all other traffic destined for the web server IP addresses.
108+
109+
### Suggested rules
110+
111+
**Rule ID**: 1
112+
**Description**: Allows inbound HTTP/S traffic from the Internet with SYN-only or ACK-only flag (not SYN/ACKs)
113+
**Match**: `ip.proto eq "tcp" and tcp.srcport in {32768..60999} and ip.dst in $web_servers and tcp.dstport in {80 443} and not (tcp.flags.syn and tcp.flags.ack)`
114+
**Action**: Allow
115+
116+
**Rule ID**: 2
117+
**Description**: Allows UDP replies for DNS and NTP to web servers
118+
**Match**: `ip.dst in $web_servers and ip.proto eq "udp" and udp.srcport in {53 123} and udp.dstport in {1024..65535}`
119+
**Action**: Allow if necessary but Disable if under attack
120+
121+
**Rule ID**: 3
122+
**Description**: Catch-all to block all other traffic destined for web server IP addresses
123+
**Match**: `ip.dst in $web_servers`
124+
**Action**: Block
125+
126+
Alternatively, if you have Cloudflare Layer 7 protection, the Cloudflare Public IP addresses can be permitted as the source IP addresses to the destination IP addresses for the HTTP/HTTPS inbound traffic. This recommendation effectively replaces Rule 1 in the example above.
127+
128+
For a list of Cloudflare's IP addresses, refer to [Cloudflare's IP addresses](https://www.cloudflare.com/ips/).
129+
130+
### Suggested rules for Cloudflare proxied traffic
131+
132+
**Description**: Allow inbound HTTP/S traffic from Cloudflare with SYN or ACK
133+
**Match**: `ip.proto eq "tcp" and ip.dst in $web_servers and tcp.dstport in {80 443} and not (tcp.flags.syn and tcp.flags.ack) and ip.src in {173.245.48.0/20 103.21.244.0/22 103.22.200.0/22 103.31.4.0/22 141.101.64.0/18 108.162.192.0/18 190.93.240.0/20 188.114.96.0/20 197.234.240.0/22 198.41.128.0/17 162.158.0.0/15 104.16.0.0/13 104.24.0.0/14 172.64.0.0/13 131.0.72.0/22}`
134+
**Action**: Allow
135+
136+
## Non-web servers
137+
138+
Restrict the source based on whether the server is expecting traffic from the general Internet or from only specific users.
139+
140+
1. Apply rules based on source IP or ports if possible.
141+
2. Restrict permitted destination ports to only those that are required.
142+
3. Block incoming SYN to the closed ports.
143+
144+
### Suggested rules
145+
146+
- `IP Destination Address { non-web server } and TCP dst port in \<valid ports> — Permit`
147+
- `IP Destination Address { non-web server } and UDP dst port in \<valid ports> — Permit`
148+
- `IP Destination Address { web server } — Block`

‎src/content/docs/cloudflare-one/traffic-policies/packet-filtering/best-practices/index.mdx‎

Lines changed: 15 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,15 @@
1+
---
2+
title: Best practices
3+
pcx_content_type: concept
4+
sidebar:
5+
order: 6
6+
7+
---
8+
9+
import { DirectoryListing } from "~/components"
10+
11+
By default, Magic Firewall permits all ingress traffic that has passed through Cloudflare's core DDoS mitigations. To proactively mitigate attacks and minimize your attack surface and leakage of attack traffic into your environment, we recommend implementing your Magic Firewall rules using the following guidelines.
12+
13+
The best approach is to replicate your current ingress perimeter firewall rules in Magic Firewall. If you are unable to export your current perimeter firewall rules, contact your Implementation Manager for help translating the rules into Magic Firewall rules.
14+
15+
<DirectoryListing />

‎src/content/docs/cloudflare-one/traffic-policies/packet-filtering/best-practices/magic-transit-egress.mdx‎

Lines changed: 16 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,16 @@
1+
---
2+
pcx_content_type: concept
3+
title: Magic Transit egress
4+
sidebar:
5+
order: 4
6+
7+
---
8+
9+
The suggestions in the [Minimal ruleset](/cloudflare-one/traffic-policies/packet-filtering/best-practices/minimal-ruleset) and [Extended ruleset](/cloudflare-one/traffic-policies/packet-filtering/best-practices/extended-ruleset) are recommendations for ingress traffic.
10+
11+
For Magic Transit egress traffic, consider the following information:
12+
13+
* The Magic Firewall rules will apply to both Magic Transit ingress and egress traffic passing via Cloudflare.
14+
* Magic Firewall is not stateful for your Magic Transit egress traffic.
15+
* Magic Firewall is not stateful in both directions after DDoS mitigations.
16+
* If you have a Magic Firewall "default drop" catchall rule for ingress traffic, you will need to add an earlier rule to permit traffic sourced from your Magic Transit prefix with the destination as **any** to allow outbound egress traffic.

‎src/content/docs/cloudflare-one/traffic-policies/packet-filtering/best-practices/minimal-ruleset.mdx‎

Lines changed: 74 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,74 @@
1+
---
2+
title: Minimal ruleset
3+
pcx_content_type: configuration
4+
sidebar:
5+
order: 2
6+
head:
7+
- tag: title
8+
content: Minimal suggested ruleset
9+
---
10+
11+
The suggested minimal ruleset blocks some known common vectors for DDoS attacks and permits all other ESP, TCP, UDP, GRE and ICMP traffic.
12+
13+
This is a suggested list and not an exhaustive list. Review your environment and add more rules as necessary.
14+
15+
## Recommended rules
16+
17+
**Rule ID**: 1 <br/>
18+
**Description**: Single rule that blocks all traffic with UDP source ports which are used in attacks or invalid in Magic Transit ingress. <br/>
19+
**Match**: `(udp.srcport in {1900 11211 389 111 19 1194 3702 10001 20800 161 162 137 27005 520 0})` <br/>
20+
**Action**: Block <br/>
21+
22+
**Rule ID**: 2 <br/>
23+
**Description**: Blocks TCP traffic with source port `0` and common ports used in TCP SYN/ACK reflection attacks. <br/>
24+
**Match**: `(tcp.srcport in {21 0 3306})` <br/>
25+
**Action**: Block <br/>
26+
27+
**Rule ID**: 3 <br/>
28+
**Description**: Blocks HOPOPT (protocol 0) or else blocks if protocol not in `{ESP, TCP, UDP, GRE, ICMP}`. Note that this is only an example. Permit the relevant protocols for your environment.<br/>
29+
**Match**: `(ip.proto eq "hopopt") or (not ip.proto in {"esp" "tcp" "udp" "gre" "icmp"})` <br/>
30+
**Action**: Block <br/>
31+
32+
## Traffic and port types
33+
34+
The information below covers traffic type, how the port is used, and reasons for blocking the port.
35+
36+
| Traffic | Port use | Reason to block |
37+
| -------------------------------- | ----------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------- |
38+
| UDP source port `0` | Reserved port. Should not be used by applications. | Invalid as a legitimate traffic source port. Commonly used in DDoS attacks. |
39+
| UDP source port `1900` | Simple Service Discovery Protocol (SSDP). Allows universal plug and play devices to send and receive information. | [SSDP DDoS attacks](https://www.cloudflare.com/learning/ddos/ssdp-ddos-attack/) exploit Universal Plug and Play protocols. |
40+
| UDP source port `11211` | Memcached. A database caching system designed to speed up websites and networks. | [Memcached DDoS Attacks](https://www.cloudflare.com/learning/ddos/memcached-ddos-attack/). |
41+
| UDP source port `389` | Connection-less Lightweight Directory Access Protocol (CLDAP). | [Used in reflection attacks](https://blog.cloudflare.com/reflections-on-reflections/). |
42+
| UDP source port `111` | SunRPC | Common attack vector. [Used in reflection attacks](https://blog.cloudflare.com/reflections-on-reflections/). |
43+
| UDP source port `19` | CHARGEN | [Amplification attack vector](https://blog.cloudflare.com/memcrashed-major-amplification-attacks-from-port-11211/). |
44+
| UDP source port `1194` | OpenVPN | Unless this is an authorized VPN in your environment, this common VPN should be blocked. |
45+
| UDP source port `3702` | Web Services Dynamic Discovery Multicast discovery protocol (WS-Discovery) | Vulnerable to exploiting for DDoS attacks. |
46+
| UDP source port `10001` | Ubiquiti UniFi discovery protocol | Ubiquiti devices were exploited and used to conduct DDoS attacks on this port. |
47+
| UDP source port `20800` | Call of Duty | [Commonly used in attacks](https://blog.cloudflare.com/reflections-on-reflections/). |
48+
| UDP source ports `161` and `162` | SNMP | Vulnerable to exploiting for DDoS attacks. |
49+
| UDP source port `137` | NetBIOS | NetBIOS allows file sharing over networks. If configured improperly, can expose file systems. |
50+
| UDP source port `27005` | SRCDS | Used in [amplication attacks](https://blog.cloudflare.com/reflections-on-reflections/). |
51+
| UDP source port `520` | Routing Information Protocol (RIP) | Internal routing protocol. Not required on Internet WAN access. |
52+
| TCP source port `0` | Reserved port. Should not be used by applications. | Commonly used in DDoS attacks. Invalid as a legitimate traffic source port. |
53+
| TCP source port `0` | FTP | Commonly used for attacks. |
54+
| TCP source port `3306` | MYSQL open source database | Used as attack vector in DDoS attacks. |
55+
56+
## Other common traffic to consider
57+
58+
The list below is a common list of traffic types you should also consider blocking or restricting inbound.
59+
60+
* SFTP, TFTP
61+
* SSH, Telnet
62+
* RDP
63+
* RCP
64+
* SMCP
65+
* NTP
66+
* Common vector for reflection attacks. Consider using [Cloudflare Gateway](/web3/), [1.1.1.1's DNS over HTTPS (DoH)](/1.1.1.1/), or an internal DNS service if possible. Consider restricting your firewall rules to only allow the source and destination of DNS traffic.
67+
* MS-SQL
68+
* Common vector and [increasingly used as vector for DDoS attacks](https://blog.cloudflare.com/ddos-attack-trends-for-2021-q4/). Block if unused or consider restricting only to the required source IP addresses.
69+
* HTTP and HTTPS
70+
* If you only have servers on your Magic Transit prefixes, consider blocking ingress traffic on TCP source ports 80 and 443 from outside. If you have endpoints on your Magic Transit prefixes, you can allow traffic on the source ports but consider creating a disabled rule you can activate to respond to reflection attacks as needed.
71+
72+
If relevant to your environment, consider blocking based on geolocation data, which blocks traffic based on the country or user when an end user's IP address is registered in the geolocation database.
73+
74+
If you are interested in participating in the beta for [Session Initiation Protocol (SIP) Validation](https://blog.cloudflare.com/programmable-packet-filtering-with-magic-firewall/), contact your Implementation Manager.

‎src/content/docs/cloudflare-one/traffic-policies/packet-filtering/protocol-validation-rules.mdx‎

Lines changed: 11 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,11 @@
1+
---
2+
title: Protocol validation rules
3+
pcx_content_type: concept
4+
5+
---
6+
7+
Magic Firewall supports [Session Initiation Protocol (SIP)](https://datatracker.ietf.org/doc/html/rfc2543) to inspect traffic validity and enforce a positive security model.
8+
9+
You can use the `sip` field when creating a rule to determine if packets are valid SIP Layer 7 (L7) protocol. Refer to [Magic Firewall fields](/cloudflare-one/reusable-components/magic-firewall-fields/), specifically the `sip` field, for more information on this topic.
10+
11+
Contact your account manager if you need Magic Firewall to support additional protocols.

0 commit comments

Comments
 (0)