As I consult with clients on security incidents in large organizations, they always puzzled by an incident that shows all their web attacks as originating from either Akamai or Amazon. This is typically due to some reconfiguration of application services to be distributed using a CDN (Content Delivery Network). It is not surprising for organizations like Target after a large breach incident to sift through millions of logs only to find attacks appear to have come either through a trusted service provider (like Akamai) or through a partner.
If your organization has been "akamaied" to deliver content / services, it is wise for your security operations to be aware of this to provide a better data stored in your logs. This is to enable your better understanding of network data flow and also enable future investigation after an incident.
I found most of these service providers to help provide information about the source of traffic as it was routed through their globally distributed infrastructure. They either X-{Headers} of various sorts to provide this information to you. The most common X-Header is the standard proxy X-Header called "X-Forwarded-For". Note some provider also provider their own custom X-Header like "X-RemoteIP" or "X-CloudFlare."
Here is a simple configuration change to your standard apache http server to start logging not only the remote IP address as observed by the server but also these X-Forwarded for headers so one can track the real remote IP address used by some when accessing your content distributed resource.
Assuming you are using a standard httpd.conf or apache2.conf configuration on a linux system, you can just add this configuration to the current runtime configuration, reload the server and Viola you can see better now!
Wait for someone to access now your content served via CDN, look at the logs.
Hmm.. what does this mean? The output shows you that network communications came from 66.249.66.144 (Google's earch bot), however it was proxied via our CDN provider, in this case CloudFlare from IP address 173.245.56.202. This works even if you saw a user access this resource via multiple X-Forwarded IP address (typically comma delimited IP addresses). It also works for IPv6 addresses being proxied to either an IPv4 or to an IPv6 address.
More example log data below to illustrate how this works.
[IPv6 address proxied through an IPv4 cloudflare address]
[IPv6 address proxied through an IPv6 cloudflare address]
Of course the vendors themselves like Akamai, Level3 provide their own plugin to do similar things on your web or application server. This solution is if you choose to make it less dependent on their modules and simplified using your managed runtime configuration of your web and app servers.
If your organization has been "akamaied" to deliver content / services, it is wise for your security operations to be aware of this to provide a better data stored in your logs. This is to enable your better understanding of network data flow and also enable future investigation after an incident.
I found most of these service providers to help provide information about the source of traffic as it was routed through their globally distributed infrastructure. They either X-{Headers} of various sorts to provide this information to you. The most common X-Header is the standard proxy X-Header called "X-Forwarded-For". Note some provider also provider their own custom X-Header like "X-RemoteIP" or "X-CloudFlare."
Here is a simple configuration change to your standard apache http server to start logging not only the remote IP address as observed by the server but also these X-Forwarded for headers so one can track the real remote IP address used by some when accessing your content distributed resource.
Assuming you are using a standard httpd.conf or apache2.conf configuration on a linux system, you can just add this configuration to the current runtime configuration, reload the server and Viola you can see better now!
|
#Support logging of appropriate x-forwarded-for address due to akamai SetEnvIf X-Forwarded-For "([^\,]+)$" XFFCLIENTIP=$1 LogFormat "%{XFFCLIENTIP}e %l %u %t \"%r\" %>s %O \"%{Referer}i\" \"%{User-Agent}i\" \"Proxy:%{X-Forwarded-For}i\" \"Remoteip:%h\"" proxycdnlog CustomLog "/stats/logs/access_log" proxycdnlog env=XFFCLIENTIP |
| 66.249.66.144 - - [13/Oct/2013:03:44:17 +0000] "GET /docs/prd1.do HTTP/1.1" 200 15341 "-" "Googlebot-Image/1.0" "Proxy:66.249.66.144" "Remoteip:173.245.56.202" |
More example log data below to illustrate how this works.
[IPv6 address proxied through an IPv4 cloudflare address]
| 2a02:200:3:1::103 - - [04/Feb/2014:00:41:23 +0000] "GET / HTTP/1.1" 200 768 "-" "sixy.ch/1.0" "Proxy:2a02:200:3:1::103" "Remoteip:173.245.49.135" |
| 2a02:200:3:1::103 - - [04/Feb/2014:00:41:23 +0000] "GET / HTTP/1.1" 200 768 "-" "sixy.ch/1.0" "Proxy:2a02:200:3:1::103" "Remoteip:2400:cb00:2049:1::adf5:3b67" |
Of course the vendors themselves like Akamai, Level3 provide their own plugin to do similar things on your web or application server. This solution is if you choose to make it less dependent on their modules and simplified using your managed runtime configuration of your web and app servers.
No comments:
Post a Comment