The Datacenter Block List enables security products to block (or alert on) all communications associated with all known data center IP addresses, including IP addresses related to malicious or compromised devices at the data center level.
Data Center Block List Details
Update Interval: Once per week (estimated availability Fridays 12:00 PM UTC)
File Format: CSV
Naming convention in FTP folder: DatacenterSubnetsWeek[WeekNum]. With every new year, the week number in the naming convention will restart from week1. It means that from weeks 1-9, the week number will be a single-digit, and from week 10 and onwards, it will be two digits.
Examples: DatacenterSubnetsWeek1, DatacenterSubnetsWeek2, DatacenterSubnetsWeek10, DatacenterSubnetsWeek11
Schema: CIDR Range (no header)
Data Center List Example
159.8.15.48/28 |
31.3.242.48/28 |
5.153.35.128/25 |
31.3.234.160/29 |
148.251.136.0/22 |
80.243.179.58/31 |
199.167.42.152/31 |
199.38.116.243/32 |
Data Center Block List Best Practices
Below is a list of best practices specific to implementing the Data Center block list.
Blocking X-Forwarded-For IP Addresses
Most effective against proxy, datacenterProxy, IPObfuscation, MaskedIP IVT Types
Proxying internet traffic through a server, gateway or peer to peer connection has become an increasingly common phenomenon on the web. However, when the internet protocol was initially designed, no standard method was implemented to capture all the IP addresses involved in proxied transactions. As a result, a de facto standard has emerged known as “X-Forwarded-For.” The term “X-Forwarded-For” is added to an internet transaction to display the list of all IP Addresses involved in a given transaction.
In the example web transaction below, this browser is using a proxy to reach its destination (www.pixalate.com). It is using the de facto X-Forwarded-For standard to send both the originating client IP address and the proxy IP address to the destination.
Source: 87.143.57.85 |
Below is a list of cases on what to do for each scenario
Case #1 - When the X-Forwarded-For header exists
Always use the furthest left IP Address in the X-Forwarded-For header (98.37.87.163) as the client IP address in your subsequent transactions. If this IP Address is present on the IP Blocklist, filter the transaction according to your thresholds. When the X-Forwarded-For header is present, you should check all other IP values for inclusion on the IP Blocklist and filter the transaction according to your thresholds - even if the client IP address is “clean”. When flagged for IVT, these proxy IP addresses will most commonly match the proxy IVT type but can be found in other IVT types as well, such as datacenterProxy, IPObfuscation and MaskedIP.
Case #2 - When the X-Forwarded-For Header is absent
The source IP Address (87.143.57.85) from the transaction should be used in the transaction, matched against the IP Blocklist and filtered according to your thresholds.
Case #3 - No access to the HTTP Header
If you are not a direct party to the transaction and do not have access to HTTP header info, you should ensure that your partners are making this information available to you for every transaction in order to make your IP filtration more effective.