Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 18 Next »


Pre-Deployment Considerations


AMP Permissions

  • Write Virtual Machine
  • Delete Log Management
  • Read Log Endpoints
  • Read Log Relays
  • Write Log Relays
  • Delete Log Relays

To learn more about permissions in AMP, see Roles and Permissions.


Log Relay


AWS Account Permissions (Policies)

  • AWS WAF
  • AWS Lambda
  • AWS CloudWatch
  • AWS CloudFormation


Web ACL

Armor does not provide support for using AWS CloudFormation to set up AWS WAF resources in AWS GovCloud (US).


Configure the AWS WAF CloudFormation Stack Template

  1. Login into the AWS console.
  2. Go to the CloudFormation service.
  3. Click Create stack.

 Instructions

AWS is in the process of updating the screens in their AWS console. As a result, there are two versions of the AWS CloudFormation screen.

Review the following table to understand your particular view, and then review the appropriate option.

ViewSample image
Old View

New View


Option 1: Old View

  1. In the AWS console, in the top menu, on the right side, select the desired region.

    The CloudFormation template must be executed in the same region as the Web ACL.

  2. In Specify an Amazon S3 template URL, input the following link: https://s3-us-west-2.amazonaws.com/logs.armor.com/log-relay-aws-waf/log-relay-aws-waf.yaml.

  3. Click Next.
  4. In Stack name, enter a descriptive name.
    • This name must begin with a letter, and can only contain letters, numbers, and hyphens.
  5. In ArmorLogEndpoint, enter the URL (including protocol and port number) of the endpoint to which logs will be sent.
    • This is the IP address or DNS name of the log relay instance, using the https protocol and port 5443.
  6. In ArmorTenantId, enter your Armor account number.
    1. This can be found in the Account Overview section of your AMP account.
  7. In BucketName, enter your S3 bucket name. This must be globally unique.
    • This is the S3 bucket (name) created by the CloudFormation template.
  8. In BucketRetentionInDays, enter the number of days logs are retained in the S3 bucket.
    1. By default, Armor has configured 3 days; set to 0 to keep logs until manually removed.
  9. In
    • This is the Kinesis stream created by the CloudFormation template.

  10. In StrictSsl, indicate whether or not strict SSL checks should be enforced on the destination log URL (True or False).

    Armor recommends that StrictSsl be set to True. Afterwards, you must complete the steps to enable SSL to utilize the CloudFormation template. If these steps are not performed, when you attempt to launch the newly created CloudFormation template, the process will fail.

    Steps to enable SSL

     Click here to expand ...

    SSL/TLS Secured Communications

    In most cases, we assume network isolation using subneting and/or firewalls are in place to secure communication between a log source and your Log Relay. There are a few exceptions to this assumption:

    In scenarios where it is typical to have data traverse the Internet, or in scenarios where a device only supports TLS-secured transport, the Log Relay config supports TLS ingestion.

    Certificates

    When you install the Log Relay software, a self-signed certificate and its corresponding private key are generated and placed in /opt/armor/logrelay.pem and /opt/armor/logrelay.key respectively. If the device sending logs requires strict SSL checks, you have a few options to satisfy this requirement:

    Exporting the Self-Signed Certificate

    You may export the certificate and add it to the trust store of the log source device (if supported). You copy the PEM certificate from the Log Relay server and then consult the vendor-supplied documentation to install a new trusted certificate.

    Using a Certificate from a Valid CA

    You can also generate a CSR and request a certificate from a CA the log source device already trusts. Using openssl you can generate a new CSR. We recommend using a configuration file to supply Subject Alternate Names (SANs) for the various DNS hostnames pointed at your Log Relay in addition to its IP address.

    logrealy.cnf

    [ req ]
default_bits       = 2048
distinguished_name = req_distinguished_name
req_extensions     = req_ext

[ req_distinguished_name ]
countryName                = <COUNTRY>
stateOrProvinceName        = <STATE>
localityName               = <CITY>
organizationName           = <COMPANY_NAME>
commonName                 = <LOG_RELAY_IP_ADDRESS>

[ req_ext ]
subjectAltName = @alt_names

[alt_names]
DNS.1   = <DNS_NAME_1>
DNS.2   = <DNS_NAME_2>
DNS.3   = <DNS_NAME_3>

    Fill in the values in angle brackets above with applicable values. For <COUNTRY> us the 2-digit ISO country code. For <STATE>. you can use the 2-digit abbreviation or the full name of your state or province.

    If the IP address of the Log Relay changes frequently or you already use a DNS hostname as the default means of addressing the Log Relay, use the DNS hostname instead of the IP address in <LOG_RELAY_IP_ADDRESS>.

    Add any DNS hostnames that resolve to this Log Relay using the alt_names section of the config. If you're not using any SANs, remove the [alt_names] and [req_ext] sections and remove the
    reference under the [req] section.

    Then use openssl to request the certificate:

    openssl req -new rsa:2048 -key /opt/armor/logrelay.key -nodes -out logrelay.csr -config logrelay.cnf

    Note that you may need to run this command as root as the key is owned by the Log Relay service account.

    After you've generated your CSR and received the certificate from the CA, ensure that it is in PEM format and upload it to your Log Relay machine. Ensure that is accessible to the Log Relay service account.

    Once the file is uploaded and has the correct permissions, update the override environment file to point at the path of the new certificate. Create a file at /etc/sysconfig/armor-logstash.override with the following contents:

    ARMOR_LOGSTASH_SSL_CERT='/path/to/cert.pem'

    If you used a key other than the one included with the Log Relay, you can specify it in this file as well:

    ARMOR_LOGSTASH_SSL_KEY='/path/to/private.key'

    Note that this key must not have a password and be in PKCS8 format. You can use file permissions and/or selinux policies to protect the key.

    After creating or updating these configuration files, restart the Log Relay service:

    sudo systemctl restart armor-logstash.service

  11. In

  12. Click Next.
  13. (Optional) If required by your organization, under Tags, add your organization's tags to the CloudFormation deployment.

  14. (Optional) If required by your organization, under Permissions, in the drop-down menu, select IAM role ARN, and then in the corresponding field, enter AWSCloudFormationStackSetExecutionRole.

  15. Click Next.
  16. At the bottom of the screen, mark the box to accept the terms, and then click Create.


Option 2: New View

  1. In the AWS console, in the top menu, on the right side, select the desired region for log collection.

    The CloudFormation template must be executed in the same region as the Web ACL.

  2. In Amazon S3 URL, input the following link: https://s3-us-west-2.amazonaws.com/logs.armor.com/log-relay-aws-waf/log-relay-aws-waf.yaml.

  3. Click Next.
  4. In Stack name, enter a descriptive name.
    • This name must begin with a letter, and can only contain letters, numbers, and hyphens.
  5. In ArmorLogEndpoint, enter the URL (including protocol and port number) of the endpoint to which logs will be sent.
    • This is the IP address or DNS name of the log relay instance, using the https protocol and port 5443.
  6. In ArmorTenantId, enter your Armor account number.
    1. This can be found in the Account Overview section of your AMP account.
  7. In BucketName, enter your S3 bucket name. This must be globally unique.
    • This is the S3 bucket (name) created by the CloudFormation template.
  8. In BucketRetentionInDays, enter the number of days logs are retained in the S3 bucket.
    1. By default, Armor has configured 3 days; set to 0 to keep logs until manually removed.
  9. In
    • This is the Kinesis stream created by the CloudFormation template.

  10. In StrictSsl, indicate whether or not strict SSL checks should be enforced on the destination log URL (True or False).

    Armor recommends that StrictSsl be set to True. Afterwards, you must complete the steps to enable SSL to utilize the CloudFormation template. If these steps are not performed, when you attempt to launch the newly created CloudFormation template, the process will fail.

    Steps to enable SSL

     Click here to expand ...

    SSL/TLS Secured Communications

    In most cases, we assume network isolation using subneting and/or firewalls are in place to secure communication between a log source and your Log Relay. There are a few exceptions to this assumption:

    In scenarios where it is typical to have data traverse the Internet, or in scenarios where a device only supports TLS-secured transport, the Log Relay config supports TLS ingestion.

    Certificates

    When you install the Log Relay software, a self-signed certificate and its corresponding private key are generated and placed in /opt/armor/logrelay.pem and /opt/armor/logrelay.key respectively. If the device sending logs requires strict SSL checks, you have a few options to satisfy this requirement:

    Exporting the Self-Signed Certificate

    You may export the certificate and add it to the trust store of the log source device (if supported). You copy the PEM certificate from the Log Relay server and then consult the vendor-supplied documentation to install a new trusted certificate.

    Using a Certificate from a Valid CA

    You can also generate a CSR and request a certificate from a CA the log source device already trusts. Using openssl you can generate a new CSR. We recommend using a configuration file to supply Subject Alternate Names (SANs) for the various DNS hostnames pointed at your Log Relay in addition to its IP address.

    logrealy.cnf

    [ req ]
default_bits       = 2048
distinguished_name = req_distinguished_name
req_extensions     = req_ext

[ req_distinguished_name ]
countryName                = <COUNTRY>
stateOrProvinceName        = <STATE>
localityName               = <CITY>
organizationName           = <COMPANY_NAME>
commonName                 = <LOG_RELAY_IP_ADDRESS>

[ req_ext ]
subjectAltName = @alt_names

[alt_names]
DNS.1   = <DNS_NAME_1>
DNS.2   = <DNS_NAME_2>
DNS.3   = <DNS_NAME_3>

    Fill in the values in angle brackets above with applicable values. For <COUNTRY> us the 2-digit ISO country code. For <STATE>. you can use the 2-digit abbreviation or the full name of your state or province.

    If the IP address of the Log Relay changes frequently or you already use a DNS hostname as the default means of addressing the Log Relay, use the DNS hostname instead of the IP address in <LOG_RELAY_IP_ADDRESS>.

    Add any DNS hostnames that resolve to this Log Relay using the alt_names section of the config. If you're not using any SANs, remove the [alt_names] and [req_ext] sections and remove the
    reference under the [req] section.

    Then use openssl to request the certificate:

    openssl req -new rsa:2048 -key /opt/armor/logrelay.key -nodes -out logrelay.csr -config logrelay.cnf

    Note that you may need to run this command as root as the key is owned by the Log Relay service account.

    After you've generated your CSR and received the certificate from the CA, ensure that it is in PEM format and upload it to your Log Relay machine. Ensure that is accessible to the Log Relay service account.

    Once the file is uploaded and has the correct permissions, update the override environment file to point at the path of the new certificate. Create a file at /etc/sysconfig/armor-logstash.override with the following contents:

    ARMOR_LOGSTASH_SSL_CERT='/path/to/cert.pem'

    If you used a key other than the one included with the Log Relay, you can specify it in this file as well:

    ARMOR_LOGSTASH_SSL_KEY='/path/to/private.key'

    Note that this key must not have a password and be in PKCS8 format. You can use file permissions and/or selinux policies to protect the key.

    After creating or updating these configuration files, restart the Log Relay service:

    sudo systemctl restart armor-logstash.service

  11. In

  12. Click Next.
  13. (Optional) If required by your organization, under Tags, add your organization's tags to the CloudFormation deployment.

  14. (Optional) If required by your organization, under Permissions, in the drop-down menu, select IAM role ARN, and then in the corresponding field, enter AWSCloudFormationStackSetExecutionRole.

  15. Review the information for the stack.

  16. At the bottom of the screen, mark the box to accept the terms, and then click Create stack.

    After a few minutes, the stack status should change from CREATE_IN_PROGRESS to CREATE_COMPLETE.


Verify Connection in AMP

  1. In the Armor Management Portal (AMP), in the left-side navigation, click Security.
  2. Click Log & Data Management, and then select Search.
  3. In the Source column, review the source name to locate the newly created AWS WAF remote log source.
    1. In the search field, you can also enter "webaclid" to locate AWS WAF messages.

Troubleshooting

If you are having issues adding a remote collector to an AWS WAF remote device, consider that:

  • You do not have proper permissions in AWS.
  • You entered the AWS account information for an incorrect AWS service account.
    • If you have multiple AWS accounts, especially child or organization accounts, you must verify that you added the service account information for the correct service account


Edit a Stack

This section only applies to single stacks, not stack sets.




Was this helpful?

Benefits

Agile protection against web attacks

AWS WAF rule propagation and updates take under a minute, enabling you to quickly update security across your environment when issues arise. WAF supports hundreds of rules that can inspect any part of the web request with minimal latency impact to incoming traffic. AWS WAF protects web applications from attacks by filtering traffic based on rules that you create. For example, you can filter any part of the web request, such as IP addresses, HTTP headers, HTTP body, or URI strings. This allows you to block common attack patterns, such as SQL injection or cross-site scripting.

Save time with managed rules

With Managed Rules for AWS WAF, you can quickly get started and protect your web application or APIs against common threats. You can select from many rule types, such as ones that address issues like the Open Web Application Security Project (OWASP) Top 10 security risks, threats specific to Content Management Systems (CMS), or emerging Common Vulnerabilities and Exposures (CVE). Managed rules are automatically updated as new issues emerge, so that you can spend more time building applications.

Improved web traffic visibility

AWS WAF gives near real-time visibility into your web traffic, which you can use to create new rules or alerts in Amazon CloudWatch. You have granular control over how the metrics are emitted, allowing you to monitor from the rule level to the entire inbound traffic. In addition, AWS WAF offers comprehensive logging by capturing each inspected web request's full header data for use in security automation, analytics, or auditing purposes.

Ease of deployment & maintenance

AWS WAF is easy to deploy and protect applications deployed on either Amazon CloudFront as part of your CDN solution, the Application Load Balancer that fronts all your origin servers, Amazon API Gateway for your REST APIs, or AWS AppSync for your GraphQL APIs. There is no additional software to deploy, DNS configuration, SSL/TLS certificate to manage, or need for a reverse proxy setup. With AWS Firewall Manager integration, you can centrally define and manage your rules, and reuse them across all the web applications that you need to protect.

Cost effective web application protection

With AWS WAF you pay only for what you use. AWS WAF provides a customizable, self-service offering, and pricing is based on how many rules you deploy and how many web requests your web application receives. There are no minimum fees and no upfront commitments.

Security integrated with how you develop applications

Every feature in AWS WAF can be configured using either the AWS WAF API or the AWS Management Console. This allows your DevOps team to define application-specific rules that increase web security as they develop applications. This lets you put web security at multiple points in the development process chain, from the hands of the developer initially writing code, to the DevOps engineer deploying software, to the security administrators enforcing a set of rules across the organization.

Topics Discussed

  • No labels