After you’ve setup your environment, deploying BinaryAlert is as easy as:
$ ./manage.py deploy
deploy is equivalent to the following 4 operations executed in sequence:
$ ./manage.py unit_test # Unit tests ensure YARA rules compile correctly $ ./manage.py build # Build the Lambda ".zip" deployment packages $ ./manage.py apply # Runs "terraform apply" to update the infrastructure $ ./manage.py analyze_all # Starts a batch analysis of the entire S3 bucket
To ensure new YARA rules are applied ASAP, every
deploy starts a batch analysis. If a batch analysis is already running or if you are not updating any YARA rules, you can just
apply your changes.
Lambda Versions and Aliases¶
Each BinaryAlert Lambda function has a
Production alias which points to the most recent version of that function. Every time a deploy changes one of the Lambda deployment packages, a new version is published and the
Production alias is updated accordingly. For more information, see AWS Lambda Function Versioning and Aliases.
Add SNS Subscriptions¶
BinaryAlert sends YARA match alerts to an SNS topic. In order to receive these alerts, you must manually add a subscription to the generated
NAME_PREFIX_binaryalert_yara_match_alerts topic. SNS supports a variety of subscription endpoints, including email, SMS, and other Lambda functions. Email/SMS subscriptions must be confirmed by the destination, which is why this step can’t be automated with Terraform.
By default, Terraform will save the state of the infrastructure locally in
terraform/terraform.tfstate. If you are deploying BinaryAlert in an enterprise environment, we recommend configuring Terraform remote state. For example, you can store the Terraform state in a versioned S3 bucket.
We recommend using the
manage.py wrapper script for most BinaryAlert management because it provides additional validation. However, you can run
terraform commands directly from the
terraform/ directory. Examples:
$ cd terraform/ $ terraform plan # Show pending changes $ terraform show # Print the current state of the infrastructure
To teardown all of the BinaryAlert infrastructure:
$ ./manage.py destroy
By default, the BinaryAlert S3 buckets can’t be deleted until they are empty. You will be asked if you want to override this setting and delete all objects as well. If so, the new setting will be applied before building the destroy plan.
You can set
force_destroy = true in the
terraform/terraform.tfvars config file and
apply the change if you want to manually disable S3 delete protections.
Terraform will build a destroy plan which you must approve before the delete will proceed.