AWS CloudWatch — Signature Expired

(Strange post, so hopefully this won't be as strange a reply).

On the subject of security flaws: it is considered general bad practice to store cgi-bin scripts within the document root of the web server. Even the W3C eludes to it under "Are compiled languages such as C safer ..." in their World Wide Web Security FAQ:

Consider the following scenario. For convenience's sake, you've decided to identify CGI scripts to the server using the .cgi extension. Later on, you need to make a small change to an interpreted CGI script. You open it up with the Emacs text editor and modify the script. Unfortunately the edit leaves a backup copy of the script source code lying around in the document tree. Although the remote user can't obtain the source code by fetching the script itself, he can now obtain the backup copy by blindly requesting the URL:

    http://your-site/a/path/your_script.cgi~

(This is another good reason to limit CGI scripts to cgi-bin and to make sure that cgi-bin is separate from the document root.)

This is not as significant a threat as the ability to write a file within the document root. However, an attacker could obtain the source code of the cgi, devise a directed attack against it, and use it as a stepping stone into the server.

To mitigate this, you can add the following lines to the lighttpd.conf (or some variation therein) to direct cgi-bin to a directory separate from the /var/www/lighttpd document root.

$HTTP["url"] =~ "/cgi-bin/" { cgi.assign = ( "" => "" ) }
alias.url = ( "/cgi-bin/" => "/usr/lib/cgi-bin/" )

This requires both the cgi and alias modules for lighttpd.

In your email it clearly states that your alarm is set to trigger after 3600 seconds.

Threshold: The alarm is in the ALARM state when the metric is LessThanThreshold 2.0 for 3600 seconds.

There should be an option to set "EvaluationPeriods". What this does is it tells the alarm how many times to evaluate the specific metric you wish to check. So in your case you would set this to 3 and the alarm would check once every hour to see if the metric is LessThanThreshold 2.0. The alarm will trigger if for 3 consecutive hours the average of the 3 points taken is LessThanThreshold 2.0.

Another thing to note is that your alarm state went from INSUFFICIENT_DATA -> ALARM. I have noticed this activity with some alarms I am working on.

In my case:

• I have an alarm that stops an instance when LessThanThreshold 5.0 for CPUUtilization for 1 hour with 6 evaluation periods, one every 10 minutes.
• When an alarm gets new data after there being INSUFFICIENT_DATA it seems to trigger my alarm to the ALARM state as I think it treats INSUFFICIENT_DATA as 0.0 (don't quote me on this, this is just what I am assuming based off some tests I am running).
• Even though the first point being taken could be 25.6% the last 5 points were INSUFFICIENT_DATA (possibly 0.0?) so the average is around 4.2ish which is LessThanThreshold 5.0.
• Then my alarm is triggered even though its technically only been 10 minutes with "real" data.

To mitigate this I have set up a script so that whenever an instance is started the alarm is created with it and when ever an alarm is triggered it deletes itself after stopping the instance it is assigned to.