Load Balancer Access Log Files – Logging and Monitoring – SCS-C02 Study Guide

Load Balancer Access Log Files

Even if a request never reaches the intended target, it is captured in an access log. This includes malformed requests and is especially helpful in the context of security since malformed requests can sometimes be attempts at things such as directory transversal attacks.

A sample of what is contained in the load balancer log files is shown here:

https 2018-07-02T22:23:00.186641Z app/packt-loadbalancer/50dc6c495c0c9188

192.168.131.39:2817 10.0.0.1:80 0.086 0.048 0.037 200 200 0 57

“GET https://www.example.com:443/

HTTP/1.1″ “curl/7.46.0” ECDHE-RSA-AES128-GCM-SHA256 TLSv1.2

arn:aws:elasticloadbalancing:us-east-2:123456789012:targetgroup/sec-targets/73e2d6bc24d8a067

“Root=1-58337281-1d84f3d73c47ec4e58577259” “packt.example.com” “arn:aws:acm:us-east-2:123456789012:certificate/12345678-1234-1234-1234-123456789012”

1 2018-07-02T22:22:48.364000Z “authenticate,forward” “-” “-” “10.0.0.1:80” “200” “-” “-“

The following points discuss the first few fields of the log files and describe what they contain:

  • Type: This shows the type of connection or request. It can be one of several types of values to start the log entry: http, https, ht (for HTTP/2 over TLS), grpcs (for gRPC over TLS), ws (for WebSockets), or wss (for WebSockets over TLS).
  • Time: This is the time when the load balancer generated a response to the client. For WebSockets clients, it is the time when the connection was closed. Times are in ISO 8601 format.
  • Elb: This field identifies the resource ID of the load balancer that took the response.
  • Client:port: This is the requesting client’s IP address and port.
  • Target:port: This is the target’s IP address and port that processed the request. If the request were a Lambda function, you would see – instead of an IP address.
  • Request_processing_time: This is the total time in sections that it took the target to process the request. This is shown in millisecond precision.
  • Elb_status_code: This is the load balancer’s response status code.
  • Target_status_code: This is the target’s response status code.

Note

You can find the complete list of all the fields and their descriptions on the Elastic Load Balancing Documentation pages: https://packt.link/f5Sfs

ELBs are one entry point to your applications and workloads. Web Application Firewalls (WAFs) can be a primary entry point that filters requests before they hit the ELB, especially Application Load Balancers. You are now ready to explore the types of logs that they produce.

Web Application Firewall Visibility and Analytics

When requests come to your WAF, they are logged via the CloudWatch service. Using CloudWatch gives you real-time metrics on how many requests hit your AWS WAF and how many match a particular rule. Metrics are published for every rule you set in the WAF. This includes both managed rules from AWS and custom rules that you write yourself. Even if you put your WAF on a blocked or count mode, the metrics still pass on to the CloudWatch service.

Using the CloudWatch service and its ingestion of the metrics produced by AWS WAF, you can set specific alarms for the different metrics, such as if the number of blocked requests is too high for a particular period. Along with tracking the metrics in the CloudWatch service, you can also get sampled web requests.

The following subsections will take you through the different types of logs that can be collected with the WAF service from AWS.