Category Uncategorized

Our SaaS runs a Laravel PHP web application on AWS ECS (Elastic Container Service) behind an AWS ALB (Application Load Balancer). Manually configuring the AWS WAF (Web Application Firewall) to protect our web application was very easy.

This guide will walk you through manually configuring AWS WAF to protect your Laravel PHP web application running behind an AWS ALB. Keep in mind that best practice is to write all of your AWS infrastructure as code so that your infrastructure can be easily rebuilt or duplicated. You should write a CloudFormation template that can build your WAF after you become more familiar with AWS WAF.

Pricing

Like any other AWS service, AWS WAF pricing was not clear at first. We created an ACL ($5/mo), then added several AWS Managed Groups ($1/mo each), then manually created a rule of our own to allow certain traffic that was being blocked by the AWS Managed Groups ($1/mo). Our total cost to enable WAF on our application was $11/mo.

TIP: Once the ACL has been created and configured, the same ACL and associated rules can be applied to multiple resources in your account (e.g. one or more ALB plus one or more CloudFront distributions, etc) meaning we only pay the $11/mo once even if we use this WAF configuration on multiple resources. You can only configure an ALB to use one WAF ACL at one time.

Terminology

ACL ($5/mo)

The ACL contains all of the rules you want to apply to your web application. Your web application will only need one ACL. If you have multiple web applications and you need different WAF rules for each application, plan on creating a separate ACL for each application.

Rules ($1/mo each)

You can manually create a variety of rules to block or allow certain situations. For example, we might choose to always allow traffic from a specific IP with a request header for a specific target hostname. This is helpful when fine-tuning the managed rules provided by AWS, we have had to create very few of our own rules.

You can place one or more rules into a rule group. This step is optional.

Marketplace Rule Groups ($/mo price varies)

You can purchase managed rule groups from various security vendors through the AWS marketplace. Pricing for a managed rule groups is typically $10-20/month regardless of how many rules the vendor places in their rule group. Vendors offered these managed rule groups before AWS began offering their own managed rule groups (below). We do not currently use any marketplace rule groups.

Some customers complain that the AWS managed rules generate too many false-positives (e.g. blocking legitimate users) for their applications, so they prefer the marketplace rules. You will have to do your own research and decide if the marketplace rules are worth the additional cost compared to the AWS managed rules for your application.

AWS Managed Rule Groups ($1/mo each)

When AWS released WAF v2, AWS announced AWS Managed Rules. Like marketplace rule groups (above), AWS managed rule groups cost a flat fee ($1/mo per group) regardless of how many rules the group may actually contain. If you are new to WAF, I would recommend starting with these rule groups!

Configuring WAF for Laravel

Each ACL has a capacity for up to 1500 compute units. Each individual rule requires a few units. Each AWS managed rule group requires a pre-defined number of compute units. If you are just getting started with AWS WAF and you are wanting to protect a Laravel PHP application on Linux servers, you might consider adding the following AWS managed rule groups to your ACL:

1. Core rule set (700 units)
2. Known bad inputs (200 units)
3. Linux operating system (200 units)
4. PHP application (100 units)
5. POSIX operating system (100 units)

Pricing: If you add these 5 rule groups to a single WAF ACL, your total cost would be $10/mo. We calculate this by adding $5/mo for the ACL plus $5/mo for these 5 rule groups ($1/mo per rule group).

Capacity: These 5 rule groups would consume a total of 1300 units of your WAF’s total capacity of 1500 units, leaving some headroom for an additional managed ruleset or your own manual rules.

Instructions

1. Create your first WAF ACL (e.g. “application-name-waf”)
2. Go to the ACL “Rules” tab, choose “Add Rules”, then choose “Add managed rule groups”
   1. Expand “AWS managed rule groups”
   2. Toggle “Add to web ACL” next to each AWS managed rule group you would like to use
   3. IMPORTANT: Click the “Edit” button below each toggle, then enable “Set all rule actions to count” for the rule group. When we first enable WAF on our application, this option will prevent the rule from actually blocking any traffic and will allow us to figure out of legitimate traffic will be blocked BEFORE we enable blocking (see below).
   4. Repeat prior 2 steps for each AWS managed rule group you would like to use.
3. Go to the ACL “Associated AWS Resources” tab, then choose “Add AWS resources”
   1. Assuming your application is running behind an AWS ALB, you would choose “Application Load Balancer”, then you would choose your application’s ALB (e.g. “application-name-alb”), then you would click “Add”. You could also configure an API Gateway or AppSync on this page.
4. Go to the ACL “Logging and Metrics” tab, click “Edit” next to logging.
   1. Configure your “Logging destination” as “CloudWatch Logs log group”. You will need to create a new Log Group with a name that begins with “aws-waf-logs-“.
      1. Log Group TIP: I suggest the full Log Group name use the required prefix plus your WAF ACL name (e.g. “aws-waf-logs-application-name-waf”) so that your WAF ACL name corresponds with your Log Group name.
      2. Log Group TIP: When creating your log group in CloudWatch under Log Groups, be sure to configure a Retention Period for the group. 30 days is probably fine for most people. We have a longer retention period so we can go back further to look at trends, but please be aware that you have to pay a small amount for CloudWatch log storage ($0.03/mo per GB). If your web application receives a LOT of traffic, keep an eye on the “Stored bytes” value on your Log Group page in CloudWatch and adjust retention as necessary.
      3. Redacted fields are optional. Skip for now.
      4. Filter logs are optional. Skip for now.
      5. Click “Save”
      6. Note: If you are prompted for the names of your CloudWatch metrics, you can accept the default names (e.g. “AWS-AWSManagedRulesCommonRuleSet”, etc)

Congrats! At this point, your new AWS WAF is filtering traffic for your Laravel PHP web application running behind AWS ALB.

Monitoring WAF Logs for Blocked Traffic

You have configured your first WAF ACL with a few AWS managed rules with each rule action set to count (instead of block) and you have applied the WAF ACL to your ALB. At this point, you should log a few days or weeks of usage, then review all of the traffic that would have been blocked by your new WAF ACL.

Viewing WAF Activity Graph in the WAF Console

Open the AWS WAF console and drill-down to your new WAF ACL. The “Overview” tab for the ACL will show a graph of all requests for the selected period (e.g. 1 hour, 3 hours, 12 hours, 1 day, etc).

If the “ALL AllowedRequests” metric and the “application-name-waf AllowedRequests” metric always show the exact same count, your WAF ACL is not detecting any requests that need to be blocked. Make sure you added one or more AWS managed log groups in the Rules section of your WAF ACL. Otherwise, we may need to wait for more traffic before analyzing your logs.

If you see any “Blocked” metrics, we need to make sure “count” setting is enabled for each rule group. Go to your WAF ACL, go to WAF Rules, click “Add Rules”, click “Add managed rule groups”, expand “AWS Managed Rule Groups”, find each group where “Add to web ACL” is enabled, and click “Edit”, then make sure “Set all rule actions to count” is enabled.

If the “ALL CountedRequests” metric ever shows a non-zero count, we will need to investigate further. At this point, we use the CloudWatch console to find/review the individual WAF ACL requests that were counted.

Viewing WAF Activity Logs in the CloudWatch Console

Open the AWS CloudWatch console, go to Log Groups, and drill-down to your new WAF log group (e.g. “aws-waf-logs-application-name-waf”), go to Log Streams, click Search all Log Streams. This will allow you to search individual requests for specific activity. If you leave the search input blank and choose a time filter option (e.g. 30 minutes), you will see all individual requests processed by WAF during that time period.

While you may not normally need to look at the individual requests, you should open/expand at least one log entry and become familiar with the payload of the logged request before you begin reviewing the “counted” requests that your new WAF ACL would have normally blocked.

Reviewing WAF Counted Requests in the CloudWatch Console

Open the AWS CloudWatch console, go to Logs Insights, select a Log Period (e.g. 12 hours), select your Log Group (e.g. “aws-waf-logs-application-name-waf”), then run the following query:

fields @timestamp
| filter (@message like 'excludedRules":[{"exclusionType":"EXCLUDED_AS_COUNT","ruleId":' and @message like 'terminatingRuleId":"Default_Action"')
| parse @message '"name":"Host","value":""' as headersHost 
| parse @message '"name":"host","value":""' as headersHostLower
| fields coalesce(headersHost, headersHostLower) as targetHost
| parse @message '"ruleId":"*"' as ruleName
| display @timestamp, httpRequest.clientIp, httpRequest.country, httpRequest.httpVersion, targetHost, httpRequest.uri, ruleName, httpRequest.requestId
|limit 100

This query will filter all requests for rules that were excluded as a count action (e.g. “exclusionType” equals “EXCLUDED_AS_COUNT”) and where the terminating rule was the default action (e.g. “terminatingRuleId” equals “Default_Action”).

This query will parse the host value from the HTTP request headers (as “targetHost”) and will also parse the Rule ID that was counted (as “ruleName”)

Your query should look similar to this:

Your query results should look similar to this:

False Positives

Each query result above would have been a blocked request if you had not enabled the “count” action on each of your AWS managed rule groups. You should review all of your query results and determine if any counted requests were legitimate traffic.

If the AWS managed rules are blocking legitimate traffic, you will have to do one of the following:

1. Create a manual rule that allows the specific traffic condition that is being blocked
2. Modify your application so that the path or variable or content that is being blocked no longer triggers the rule. For example, you may be able to rename a variable name that is triggering a rule.
3. Disable a portion of the AWS managed rule group or the entire AWS managed rule group.

In our case, a 3rd party integration uses XML payloads to transmit data to an older API so we created a custom rule that allowed that specific traffic. This one custom rule increased our AWS WAF cost by $1/mo. After saving the rule, WAF allowed us to configure the priority of the rule so that our custom rule was applied before any of the AWS managed rule groups.

Blocking Requests

After you have reviewed your counted requests and have eliminated false positives, you are ready to configure AWS WAF to begin blocking requests!

1. Open the AWS WAF Console
2. Go to your WAF ACL
3. Go to WAF Rules
4. Click “Add Rules”
5. Click “Add managed rule groups”
6. Expand “AWS Managed Rule Groups”
   1. Find each group where “Add to web ACL” is enabled
   2. Click “Edit”
   3. Disable “Set all rule actions to count”
   4. Repeat steps above for each group where “Add to web ACL” is enabled

Congrats! Your new WAF ACL is now protecting your Laravel PHP web application.

Did you find this helpful? Let me know by sending me a comment. I tend to update and maintain posts more frequently if I know others find them helpful. Thanks for visiting!

I recently moved some of our PHP code from PhpSpreadsheet (phpoffice/phpspreadsheet) to Spout (box/spout) to address memory consumption issues while generating XLSX-formatted Spreadsheets. I have experience writing Excel Spreadsheets using several other PHP packages, so I was able to dive into the Spout source code and figure out how to access number and date formatting features.

Format Numbers

If you cast a PHP value to an (int) or a (float), Spout will save the value as a number, but your spreadsheet application will display an unformatted number. For example, the number “12,345,678.90” would be displayed in your spreadsheet application as “12345678.9”.

You can use setFormat() to format any (int) or (float) value. Find Excel number formatting examples here. See Sample Code below.

Format Dates

If you save a Date to Spout as a (string) value (e.g. “12/31/1999”), your spreadsheet application will display the pre-formatted Date, BUT the date cannot be re-formatted or used for calculations because it is being stored as a String value instead of a Date value.

You can use setFormat() to format a date, ONLY IF the date is passed as an Excel numeric (int) or (float) date value. Several PHP libraries can convert a PHP date to an Excel numeric date value. Since our project uses both Spout and PhpSpreadsheet, we use PhpSpreadsheet’s Date::PHPToExcel() to convert a Carbon value to an Excel numeric value. Find Excel date and time formatting examples here and here. See Sample Code below.

Sample Code

The following sample code produces this output in my spreadsheet application (Numbers):

    use Carbon\Carbon;
    use PhpOffice\PhpSpreadsheet\Shared\Date;
    use Box\Spout\Writer\Common\Creator\Style\StyleBuilder;
    use Box\Spout\Writer\Common\Creator\WriterEntityFactory;

    // Open Spreadsheet
    $writer = WriterEntityFactory::createXLSXWriter();
    $writer->openToFile('example.xlsx');

    // Build Header Row
    $styleBold = (new StyleBuilder())->setFontBold()->build();
    $writer->addRow(
        WriterEntityFactory::createRow([
            WriterEntityFactory::createCell('Num1'),
            WriterEntityFactory::createCell('Num2'),
            WriterEntityFactory::createCell('Num3'),
            WriterEntityFactory::createCell('Date1'),
            WriterEntityFactory::createCell('Date2'),
        ], $styleBold)
    );

    // Define Number and Date Formats
    $styleNum1 = (new StyleBuilder())->setFormat('#,##0.00')->build();
    $styleNum2 = (new StyleBuilder())->setFormat('0.0')->build();
    $styleNum3 = (new StyleBuilder())->setFormat('00000')->build();
    $styleDate1 = (new StyleBuilder())->setFormat('mm/dd/yy')->build();
    $styleDate2 = (new StyleBuilder())->setFormat('mm/dd/yyyy')->build();

    // Define Number and Date Values
    $num1 = 12345678.9;
    $num2 = 1234;
    $date = Date::PHPToExcel(Carbon::parse('03/14/2000'));

    // Build Row of Formatted Numbers and Dates
    $writer->addRow(
        WriterEntityFactory::createRow([
            // Output 12,345,678.90
            WriterEntityFactory::createCell($num1, $styleNum1),
            // Output 1234.0
            WriterEntityFactory::createCell($num2, $styleNum2),
            // Output 01234
            WriterEntityFactory::createCell($num2, $styleNum3),
            // Output 03/14/00
            WriterEntityFactory::createCell($date, $styleDate1),
            // Output 03/14/2000
            WriterEntityFactory::createCell($date, $styleDate2),
        ])
    );

    // Close Spreadsheet
    $writer->close();

Bonus: Custom Column Widths

The box/spout project has an open Pull Request (PR#715) that adds Custom Column Width support. I forked the contributor’s repository (aphofstede/spout) to my own repo (e.g. “example/spout-custom-column-widths”) and added the following snippet to the “repositories” section of our composer.json file, which instructs composer to use the “custom-column-widths” branch in my forked copy of the repository.

When I run “composer require box/spout” in our project, composer uses the “custom-column-widths” branch from my forked copy of the contributor’s repository. Replace “example/spout-custom-column-widths” with the actual path to your forked copy of the contributor’s repository.

  {
      "type": "package",
      "package": {
          "name": "box/spout",
          "version": "3.2",
          "source": {
              "url": "https://github.com/example/spout-custom-column-widths",
              "type": "git",
              "reference": "custom-column-widths"
          },
          "type": "library",
          "autoload": {
              "psr-4": {
                  "Box\\Spout\\": "src/Spout"
              }
          }
      }
  }

Sample Code

You can use the setDefaultColumnWidth() method to set default column width for all of the worksheets in your spreadsheet.

TIP: Use method_exists() to make sure the custom method exists in case you need to temporarily deploy your project without the custom PR.

    // XLS Worksheet Default Column Width
    // NOTE: setDefaultColumnWidth() may only be called BEFORE openToFile()
    if (method_exists($writer, 'setDefaultColumnWidth')) {
        // NOTE: setDefaultColumnWidth() provided by PR#715
        $writer->setDefaultColumnWidth(12);
    }

You can use the setColumnWidth() method to set specific column widths for individual columns. In the example below, we set widths for Column A to Column H.

TIP: Use method_exists() to make sure the custom method exists in case you need to temporarily deploy your project without the custom PR.

    // XLS Worksheet Column Widths
    // NOTE: setColumnWidth() may only be called AFTER openToFile()
    if (method_exists($writer, 'setColumnWidth')) {
        // NOTE: setColumnWidth() provided by PR#715
        $writer->setColumnWidth(8, 1); // Column A
        $writer->setColumnWidth(12, 2); // Column B
        $writer->setColumnWidth(12, 3); // Column C
        $writer->setColumnWidth(12, 4); // Column D
        $writer->setColumnWidth(12, 5); // Column E
        $writer->setColumnWidth(50, 6); // Column F
        $writer->setColumnWidth(12, 7); // Column G
        $writer->setColumnWidth(12, 8); // Column H
    }

The Custom Column Width PR may also provide these setColumnWidthForRange() and setDefaultRowHeight() methods? I have not tested these methods, but thought others may appreciate knowing they exist.

    // Set Column Width to 12 for Columns A-F (1-6)
    $writer->setColumnWidthForRange(12, 1, 6);

    // Set Default Row Height to 3 for all rows
    $writer->setDefaultRowHeight(3);

Did you find this helpful? Let me know by sending me a comment. I tend to update and maintain posts more frequently if I know others find them helpful. Thanks for visiting!

I spent quite a bit of time attempting to implement PhpSpreadsheet Cell Caching as described in their Memory Saving documentation page. I also read numerous related articles including Stack Overflow “Building very large spreadsheet with PHPSpreadsheet” where @andrewtweber claimed the Cell Caching was too slow and instead recommended “box/spout” XLSX/ODS/CSV writer.

Attempt to use the box/sprout Package

We are generating ~1MB Excel spreadsheets with ~25K rows and a total of ~197K cells. I confirmed box/spout claims of being VERY fast and VERY memory efficient, using ~94MB *less* memory than PhpSpreadsheet when generating these particular XLSX sheets. Unfortunately, I learned box/spout can NOT set column widths as of April 2021. I am tempted to deploy a custom box/spout with PR 715 “Not just another custom column widths PR”

Cell Caching Summary

I attempted to implement PhpSpreadsheet Cell Caching in a Laravel app using a few different methods. I agree that each method I attempted was too slow to be useful, primarily due to the fact that PhpSpreadsheet must make a separate call to the cache for EVERY CELL. In our case, that meant ~197,000 calls for ~197K cells. Regardless, I am sharing the examples I used so other devs can quickly determine whether or not Cell Caching is too slow for their use case.

Attempt 1: Use native Laravel Cache

I am not sure this is the best way to acquire a Simple Cache interface from Laravel, but PhpSpreadsheet seemed to be interacting with our Redis cache. However, 197K round trips over the network was going to take far too long. I gave up after waiting 5 minutes.

$cache = new Cache();
$cacheStore = $cache::getStore();
$cacheInterface = new Repository($cacheStore);
Settings::setCache($cacheInterface);

$spreadsheet = new Spreadsheet();

Attempt 2: Use Shieldon Simple Cache with File Backend

I installed the “shieldon/simple-cache” package and attempted to use the File backend. Unfortunately, this had to create 197K temporary files (1 file for each of the ~197K spreadsheet cells). This took too long, even on an SSD. I gave up after waiting 5 minutes.

$path = 'cache/php-spreadsheet/';
if (!Storage::exists($path)) {
Storage::makeDirectory($path);
}
$storagePath = Storage::path($path);
$cacheInterface = new \Shieldon\SimpleCache\Driver\File([
'storage' => $storagePath,
]);
Settings::setCache($cacheInterface);

$spreadsheet = new Spreadsheet();

Attempt 3: Use Shieldon Simple Cache with SQLite Backend

I used the “shieldon/simple-cache” package again, only this time I attempted to use the Sqlite backend. My hope was that writing each of the ~197K cells to a single SQLite file might be faster. I was wrong. This took too long. I gave up after waiting 5 minutes. NOTE: Although the SQLite file contained 0 rows afterwards, the file was NOT truncated and remained at its peak size of 127MB. If you choose this method, be careful to truncate or delete your SQLite file to prevent a disk full situation.

$rebuildCache = false;
$path = 'cache/php-spreadsheet/';
if (!Storage::exists($path)) {
Storage::makeDirectory($path);
$rebuildCache = true;
}
$storagePath = Storage::path($path);
$cacheInterface = new \Shieldon\SimpleCache\Driver\File([
'storage' => $storagePath,
]);
$cacheInterface = new \Shieldon\SimpleCache\Driver\Sqlite([
'storage' => $storagePath,
]);
if ($rebuildCache) {
$cacheInterface->rebuild();
}
Settings::setCache($cacheInterface);

$spreadsheet = new Spreadsheet();

Other Options

I saw at least one other person mention that they built their own custom Simple Cache interface and that they were writing 500 cells (or 500 rows?) to each file. I’d like to try this since it would reduce the number of files created from ~197K to only 394 files (or 50 files?), but could not find a code sample. Since OP said their attempts were too slow, I abandoned this option.

A User Script is a locally installed script in your web browser that applies JavaScript and CSS customizations to a specific website while you are visiting the website. Here are a few example use cases:

1. Add Functionality, such as a “Download List to CSV” button that loops through a list on the web page and generates a CSV file.
2. Remove Functionality, such as hiding links or buttons you never intend to use to help de-clutter a web interface.
3. Fix Design Issues, such as the position or color of an element on the page that might be bothering you.

User Scripts can be run in any web browser by installing a User Script browser extension. Here are a few example User Script extensions for some of the more popular web browsers:

1. Safari – Userscripts
2. Firefox – Violentmonkey
3. Brave – Violentmonkey
4. Chrome – Violentmonkey
5. Edge – Violentmonkey

PRO TIP: If you have access to a WebDAV file sharing folder that supports BASIC authentication, Violentmonkey can sync your User Scripts settings across multiple browsers. Unfortunately, Violentmonkey does not currently support WebDAV DIGEST authentication.

Getting Started with Userscripts Extension on Safari

I’ve provided a few example scripts you can use to suppress extra menus and buttons on several financial websites. Here are step-by-step instructions to install these scripts.

1. Install the Userscripts browser extension for Safari
2. Enable the extension
   1. Go to the Safari drop-down menu and select Preferences
   2. When the Preferences window appears, go to the Extensions tab
   3. Make sure the “Userscripts” extension is enabled. The check box next to the extension name should be checked.
3. Click the “Userscripts” icon on your Safari browser bar. The icon will look similar to this: “</>“
4. You should see a window with a “Search and Filter” text box, Gear icon, and Plus icon in the upper-left corner
5. Click the Plus icon and choose “New Javascript”. You should see a new JS User Script in the left-hand list and a new User Script template in the right-hand content area.
6. Download a Sample Script, open the text file, and copy/paste the code into the right-hand content area, replacing the sample template code. Repeat for each User Script you’d like to try. You can install multiple User Scripts.
   1. Minimal QBO – Minimal interface for Intuit QuickBooks Online
   2. Minimal Mint – Minimal interface for Intuit Mint
7. Use the toggle in the left-hand list to enable/disable individual User Scripts
8. Browse to the website and enjoy the User Script customizations!

Each time I use the Viscosity VPN client on macOS 11.1 (Big Sur) to establish an OpenVPN connection, the hostname displayed in new macOS terminal session would change from my computer name (e.g. “user@trogdor“) to the reverse lookup hostname of my VPN IP address (e.g. “user@ip-10-2-3-4”).

Suppose I always wanted my hostname to be “trogdor“. I ran the following command in a Terminal session to set a permanent hostname that does NOT seem to change when I connect to the VPN.

scutil --set HostName trogdor

Huge thank you to Chris Searle for posting this same solution for OSX Lion and Mountain Lion! I assume that means this solution would also work for all macOS versions between 10.7 and 11.1:

• OSX 10.7: “Lion”
• OSX 10.8: “Mountain Lion”
• OSX 10.9: “Mavericks”
• OSX 10.10: “Yosemite”
• OSX 10.11: “El Capitan”
• macOS 10.12: “Sierra”
• macOS 10.13: “High Sierra”
• macOS 10.14: “Mojave”
• macOS 10.15: “Catalina”
• macOS 11.0: “Big Sur”
• macOS 11.1: “Big Sur”

Did this help you out? Do you have more info to share? Please reply below! I’d love to hear from you.