Data Center Data Intelligence Feed
Overview
The Data Center Data Intelligence Feed enables security products to block (or alert on) all communications associated with known data center IPv4 ranges, including IP addresses related to malicious or compromised devices at the data center level.
The Data Center Data Intelligence Feed consists of the IPv4 ranges published by the three largest hosting providers — Amazon AWS, Google, and Microsoft — as required by the Media Rating Council (MRC) for filtration of invalid data center traffic. Coverage also extends to externally published lists as well as ranges curated internally by Pixalate covering major and smaller cloud and hosting providers.
File Format and Delivery
|
File Format |
CSV |
|
Delivery Method |
FTP, S3, AWS RTB Fabric, APIs |
|
Naming Convention |
DatacenterSubnetsWeek[WeekNum].
Examples: DatacenterSubnetsWeek1, DatacenterSubnetsWeek2, DatacenterSubnetsWeek10, DatacenterSubnetsWeek11 |
|
Update Frequency |
Weekly (estimated availability Fridays 12:00 AM UTC)
|
Schema
A list of IPv4 CIDR Ranges (no header).
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
Integration Best Practices
- Check once every hour on Friday
- Download only when a new file is available
- Stop pinging once the new file is found
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.