mirror of
https://github.com/prowler-cloud/prowler.git
synced 2025-12-19 05:17:47 +00:00
docs(tutorials): improve quality redrive (#7915)
Co-authored-by: Daniel Barranquero <danielbo2001@gmail.com> Co-authored-by: Andoni Alonso <14891798+andoniaf@users.noreply.github.com>
This commit is contained in:
committed by
GitHub
parent
1bdcf2c7f1
commit
9ca1899ebf
Binary file not shown.
|
Before Width: | Height: | Size: 328 KiB After Width: | Height: | Size: 289 KiB |
@@ -1,6 +1,10 @@
|
||||
# AWS Authentication
|
||||
# AWS Authentication in Prowler
|
||||
|
||||
Make sure you have properly configured your AWS-CLI with a valid Access Key and Region or declare AWS variables properly (or instance profile/role):
|
||||
Proper authentication is required for Prowler to perform security checks across AWS resources. Ensure that AWS-CLI is correctly configured or manually declare AWS credentials before running scans.
|
||||
|
||||
## Configure AWS Credentials
|
||||
|
||||
Use one of the following methods to authenticate:
|
||||
|
||||
```console
|
||||
aws configure
|
||||
@@ -14,25 +18,32 @@ export AWS_SECRET_ACCESS_KEY="XXXXXXXXX"
|
||||
export AWS_SESSION_TOKEN="XXXXXXXXX"
|
||||
```
|
||||
|
||||
Those credentials must be associated to a user or role with proper permissions to do all checks. To make sure, add the following AWS managed policies to the user or role being used:
|
||||
These credentials must be associated with a user or role with the necessary permissions to perform security checks.
|
||||
|
||||
- `arn:aws:iam::aws:policy/SecurityAudit`
|
||||
- `arn:aws:iam::aws:policy/job-function/ViewOnlyAccess`
|
||||
## Assign Required AWS Permissions
|
||||
To ensure full functionality, attach the following AWS managed policies to the designated user or role:
|
||||
|
||||
- `arn:aws:iam::aws:policy/SecurityAudit`
|
||||
- `arn:aws:iam::aws:policy/job-function/ViewOnlyAccess`
|
||||
|
||||
???+ note
|
||||
Moreover, some read-only additional permissions are needed for several checks, make sure you attach also the custom policy [prowler-additions-policy.json](https://github.com/prowler-cloud/prowler/blob/master/permissions/prowler-additions-policy.json) to the role you are using. If you want Prowler to send findings to [AWS Security Hub](https://aws.amazon.com/security-hub), make sure you also attach the custom policy [prowler-security-hub.json](https://github.com/prowler-cloud/prowler/blob/master/permissions/prowler-security-hub.json).
|
||||
Some security checks require read-only additional permissions. Attach the following custom policies to the role: [prowler-additions-policy.json](https://github.com/prowler-cloud/prowler/blob/master/permissions/prowler-additions-policy.json). If you want Prowler to send findings to [AWS Security Hub](https://aws.amazon.com/security-hub), make sure to also attach the custom policy: [prowler-security-hub.json](https://github.com/prowler-cloud/prowler/blob/master/permissions/prowler-security-hub.json).
|
||||
|
||||
## AWS Profiles and Service Scanning in Prowler
|
||||
|
||||
## Profiles
|
||||
Prowler supports authentication and security assessments using custom AWS profiles and can optionally scan unused services.
|
||||
|
||||
**Using Custom AWS Profiles**
|
||||
|
||||
Prowler allows you to specify a custom AWS profile using the following command:
|
||||
|
||||
Prowler can use your custom AWS Profile with:
|
||||
```console
|
||||
prowler aws -p/--profile <profile_name>
|
||||
```
|
||||
|
||||
## Multi-Factor Authentication
|
||||
## Multi-Factor Authentication (MFA)
|
||||
|
||||
If your IAM entity enforces MFA you can use `--mfa` and Prowler will ask you to input the following values to get a new session:
|
||||
If MFA enforcement is required for your IAM entity, you can use `--mfa`. Prowler will prompt you to enter the following in order to get a new session:
|
||||
|
||||
- ARN of your MFA device
|
||||
- TOTP (Time-Based One-Time Password)
|
||||
|
||||
@@ -1,45 +1,52 @@
|
||||
# Boto3 Retrier Configuration
|
||||
# Boto3 Retrier Configuration in Prowler
|
||||
|
||||
Prowler's AWS Provider uses the Boto3 [Standard](https://boto3.amazonaws.com/v1/documentation/api/latest/guide/retries.html) retry mode to assist in retrying client calls to AWS services when these kinds of errors or exceptions are experienced. This mode includes the following behaviours:
|
||||
Prowler's AWS Provider leverages Boto3's [Standard](https://boto3.amazonaws.com/v1/documentation/api/latest/guide/retries.html) retry mode to automatically retry client calls to AWS services when encountering errors or exceptions.
|
||||
|
||||
- A default value of 3 for maximum retry attempts. This can be overwritten with the `--aws-retries-max-attempts 5` argument.
|
||||
## Retry Behavior Overview
|
||||
|
||||
- Retry attempts for an expanded list of errors/exceptions:
|
||||
```
|
||||
# Transient errors/exceptions
|
||||
RequestTimeout
|
||||
RequestTimeoutException
|
||||
PriorRequestNotComplete
|
||||
ConnectionError
|
||||
HTTPClientError
|
||||
Boto3's Standard retry mode includes the following mechanisms:
|
||||
|
||||
# Service-side throttling/limit errors and exceptions
|
||||
Throttling
|
||||
ThrottlingException
|
||||
ThrottledException
|
||||
RequestThrottledException
|
||||
TooManyRequestsException
|
||||
ProvisionedThroughputExceededException
|
||||
TransactionInProgressException
|
||||
RequestLimitExceeded
|
||||
BandwidthLimitExceeded
|
||||
LimitExceededException
|
||||
RequestThrottled
|
||||
SlowDown
|
||||
EC2ThrottledException
|
||||
```
|
||||
- Maximum Retry Attempts: Default value set to 3, configurable via the `--aws-retries-max-attempts 5` argument.
|
||||
|
||||
- Retry attempts on nondescriptive, transient error codes. Specifically, these HTTP status codes: 500, 502, 503, 504.
|
||||
- Expanded Error Handling: Retries occur for a comprehensive set of errors.
|
||||
|
||||
- Any retry attempt will include an exponential backoff by a base factor of 2 for a maximum backoff time of 20 seconds.
|
||||
```
|
||||
# *Transient Errors/Exceptions*
|
||||
The retrier handles various temporary failures:
|
||||
RequestTimeout
|
||||
RequestTimeoutException
|
||||
PriorRequestNotComplete
|
||||
ConnectionError
|
||||
HTTPClientError
|
||||
|
||||
## Notes for validating retry attempts
|
||||
# *Service-Side Throttling and Limit Errors*
|
||||
Retries occur for service-imposed rate limits and resource constraints:
|
||||
Throttling
|
||||
ThrottlingException
|
||||
ThrottledException
|
||||
RequestThrottledException
|
||||
TooManyRequestsException
|
||||
ProvisionedThroughputExceededException
|
||||
TransactionInProgressException
|
||||
RequestLimitExceeded
|
||||
BandwidthLimitExceeded
|
||||
LimitExceededException
|
||||
RequestThrottled
|
||||
SlowDown
|
||||
EC2ThrottledException
|
||||
```
|
||||
|
||||
If you are making changes to Prowler, and want to validate if requests are being retried or given up on, you can take the following approach
|
||||
- Nondescriptive Transient Error Codes: The retrier applies retry logic to standard HTTP status codes signaling transient errors: 500, 502, 503, 504.
|
||||
|
||||
- Exponential Backoff Strategy: Each retry attempt follows exponential backoff with a base factor of 2, ensuring progressive delay between retries. Maximum backoff time: 20 seconds
|
||||
|
||||
## Validating Retry Attempts
|
||||
|
||||
For testing or modifying Prowler's behavior, use the following steps to confirm whether requests are being retried or abandoned:
|
||||
|
||||
* Run prowler with `--log-level DEBUG` and `--log-file debuglogs.txt`
|
||||
* Search for retry attempts using `grep -i 'Retry needed' debuglogs.txt`
|
||||
|
||||
This is based off of the [AWS documentation](https://boto3.amazonaws.com/v1/documentation/api/latest/guide/retries.html#checking-retry-attempts-in-your-client-logs), which states that if a retry is performed, you will see a message starting with "Retry needed".
|
||||
This approach follows the [AWS documentation](https://boto3.amazonaws.com/v1/documentation/api/latest/guide/retries.html#checking-retry-attempts-in-your-client-logs), which states that if a retry is performed, a message starting with "Retry needed” will be prompted.
|
||||
|
||||
You can determine the total number of calls made using `grep -i 'Sending http request' debuglogs.txt | wc -l`
|
||||
It is possible to determine the total number of calls made using `grep -i 'Sending http request' debuglogs.txt | wc -l`
|
||||
|
||||
@@ -1,7 +1,11 @@
|
||||
# AWS CloudShell
|
||||
# Installing Prowler in AWS CloudShell
|
||||
|
||||
## Following the migration of AWS CloudShell from Amazon Linux 2 to Amazon Linux 2023
|
||||
|
||||
AWS CloudShell has migrated from Amazon Linux 2 to Amazon Linux 2023 [[1]](https://aws.amazon.com/about-aws/whats-new/2023/12/aws-cloudshell-migrated-al2023/) [[2]](https://docs.aws.amazon.com/cloudshell/latest/userguide/cloudshell-AL2023-migration.html). With this transition, Python 3.9 is now included by default in AL2023, eliminating the need for manual compilation.
|
||||
|
||||
To install Prowler v4 in AWS CloudShell, follow the standard installation method using pip:
|
||||
|
||||
## Installation
|
||||
After the migration of AWS CloudShell from Amazon Linux 2 to Amazon Linux 2023 [[1]](https://aws.amazon.com/about-aws/whats-new/2023/12/aws-cloudshell-migrated-al2023/) [[2]](https://docs.aws.amazon.com/cloudshell/latest/userguide/cloudshell-AL2023-migration.html), there is no longer a need to manually compile Python 3.9 as it's already included in AL2023. Prowler can thus be easily installed following the Generic method of installation via pip. Follow the steps below to successfully execute Prowler v4 in AWS CloudShell:
|
||||
```shell
|
||||
sudo bash
|
||||
adduser prowler
|
||||
@@ -11,13 +15,20 @@ cd /tmp
|
||||
prowler aws
|
||||
```
|
||||
|
||||
## Download Files
|
||||
## Downloading Files from AWS CloudShell
|
||||
|
||||
To download the results from AWS CloudShell, select Actions -> Download File and add the full path of each file. For the CSV file it will be something like `/home/cloudshell-user/output/prowler-output-123456789012-20221220191331.csv`
|
||||
To download results from AWS CloudShell:
|
||||
|
||||
## Clone Prowler from Github
|
||||
- Select Actions → Download File.
|
||||
|
||||
- Specify the full file path of each file you wish to download. For example, downloading a CSV file would require providing its complete path, as in: `/home/cloudshell-user/output/prowler-output-123456789012-20221220191331.csv`
|
||||
|
||||
## Cloning Prowler from GitHub
|
||||
|
||||
Due to the limited storage in AWS CloudShell's home directory, installing Poetry dependencies for running Prowler from GitHub can be problematic.
|
||||
|
||||
The following workaround ensures successful installation:
|
||||
|
||||
The limited storage that AWS CloudShell provides for the user's home directory causes issues when installing the poetry dependencies to run Prowler from GitHub. Here is a workaround:
|
||||
```shell
|
||||
sudo bash
|
||||
adduser prowler
|
||||
@@ -31,8 +42,8 @@ eval $(poetry env activate)
|
||||
poetry install
|
||||
python prowler-cli.py -v
|
||||
```
|
||||
> [!IMPORTANT]
|
||||
> Starting from Poetry v2.0.0, `poetry shell` has been deprecated in favor of `poetry env activate`.
|
||||
>
|
||||
> If your poetry version is below 2.0.0 you must keep using `poetry shell` to activate your environment.
|
||||
> In case you have any doubts, consult the Poetry environment activation guide: https://python-poetry.org/docs/managing-environments/#activating-the-environment
|
||||
|
||||
???+ important
|
||||
Starting from Poetry v2.0.0, `poetry shell` has been deprecated in favor of `poetry env activate`.
|
||||
|
||||
If your Poetry version is below v2.0.0, continue using `poetry shell` to activate your environment. For further guidance, refer to the Poetry Environment Activation Guide https://python-poetry.org/docs/managing-environments/#activating-the-environment.
|
||||
|
||||
@@ -1,34 +1,39 @@
|
||||
# Scan Multiple AWS Accounts
|
||||
# Scanning Multiple AWS Accounts with Prowler
|
||||
|
||||
Prowler can scan multiple accounts when it is executed from one account that can assume a role in those given accounts to scan using [Assume Role feature](role-assumption.md) and [AWS Organizations integration feature](organizations.md).
|
||||
Prowler enables security scanning across multiple AWS accounts by utilizing the [Assume Role feature](role-assumption.md) and [integration with AWS Organizations feature](organizations.md).
|
||||
|
||||
This approach allows execution from a single account with permissions to assume roles in the target accounts.
|
||||
|
||||
## Scan multiple specific accounts sequentially
|
||||
## Scanning Multiple Accounts Sequentially
|
||||
|
||||
- Declare a variable with all the accounts to scan:
|
||||
To scan specific accounts one at a time:
|
||||
|
||||
- Define a variable containing the AWS account IDs to be scanned:
|
||||
|
||||
```
|
||||
ACCOUNTS_LIST='11111111111 2222222222 333333333'
|
||||
```
|
||||
|
||||
- Then run Prowler to assume a role (change `<role_name>` below to yours, that must be the same in all accounts):
|
||||
- Run Prowler with an IAM role that exists in all target accounts: (replace the `<role_name>` with to yours, that is to be consistent throughout all accounts):
|
||||
|
||||
```
|
||||
ROLE_TO_ASSUME=<role_name>
|
||||
for accountId in $ACCOUNTS_LIST; do
|
||||
prowler aws --role arn:aws:iam::$accountId:role/$ROLE_TO_ASSUME
|
||||
for accountId in $ACCOUNTS_LIST; do
|
||||
prowler aws --role arn:aws:iam::$accountId:role/$ROLE_TO_ASSUME
|
||||
done
|
||||
```
|
||||
|
||||
## Scan multiple specific accounts in parallel
|
||||
## Scanning Multiple Accounts in Parallel
|
||||
|
||||
- Declare a variable with all the accounts to scan:
|
||||
- To scan multiple accounts simultaneously:
|
||||
|
||||
Define the AWS accounts to be scanned with a variable:
|
||||
|
||||
```
|
||||
ACCOUNTS_LIST='11111111111 2222222222 333333333'
|
||||
```
|
||||
|
||||
- Then run Prowler to assume a role (change `<role_name>` below to yours, that must be the same in all accounts), in this example it will scan 3 accounts in parallel:
|
||||
- Run Prowler with an IAM role that exists in all target accounts: (replace the `<role_name>` with to yours, that is to be consistent throughout all accounts). The following example executes scanning across three accounts in parallel:
|
||||
|
||||
```
|
||||
ROLE_TO_ASSUME=<role_name>
|
||||
@@ -41,25 +46,35 @@ for accountId in $ACCOUNTS_LIST; do
|
||||
done
|
||||
```
|
||||
|
||||
## Scan multiple accounts from AWS Organizations in parallel
|
||||
## Scanning Multiple AWS Organization Accounts in Parallel
|
||||
|
||||
- Declare a variable with all the accounts to scan. To do so, get the list of your AWS accounts in your AWS Organization by running the following command (will create a variable with all your ACTIVE accounts). Remember to run that command with the permissions needed to get that information in your AWS Organizations Management account.
|
||||
Prowler enables parallel security scans across multiple AWS accounts within an AWS Organization.
|
||||
|
||||
### Retrieve Active AWS Accounts
|
||||
|
||||
To efficiently scan multiple accounts within an AWS Organization, follow these steps:
|
||||
|
||||
- Step 1: Retrieve a List of Active Accounts
|
||||
|
||||
First, declare a variable containing all active accounts in your AWS Organization. Run the following command in your AWS Organizations Management account, ensuring that you have the necessary permissions:
|
||||
|
||||
```
|
||||
ACCOUNTS_IN_ORG=$(aws organizations list-accounts --query Accounts[?Status==`ACTIVE`].Id --output text)
|
||||
```
|
||||
|
||||
- Then run Prowler to assume a role (change `<role_name>` that must be the same in all accounts and `<management_organizations_account_id>` that must be your AWS Organizations management account ID):
|
||||
- Step 2: Run Prowler with Assumed Roles
|
||||
|
||||
Use Prowler to assume roles across accounts in parallel. Modify <role_name> to match the role that exists in all accounts and <management_organizations_account_id> to your AWS Organizations Management account ID.
|
||||
|
||||
```
|
||||
ROLE_TO_ASSUME=<role_name>
|
||||
MGMT_ACCOUNT_ID=<management_organizations_account_id>
|
||||
PARALLEL_ACCOUNTS="3"
|
||||
for accountId in $ACCOUNTS_IN_ORG; do
|
||||
test "$(jobs | wc -l)" -ge $PARALLEL_ACCOUNTS && wait || true
|
||||
{
|
||||
prowler aws --role arn:aws:iam::$accountId:role/$ROLE_TO_ASSUME \
|
||||
--organizations-role arn:aws:iam::$MGMT_ACCOUNT_ID:role/$ROLE_TO_ASSUME
|
||||
} &
|
||||
test "$(jobs | wc -l)" -ge $PARALLEL_ACCOUNTS && wait || true
|
||||
{
|
||||
prowler aws --role arn:aws:iam::$accountId:role/$ROLE_TO_ASSUME \
|
||||
--organizations-role arn:aws:iam::$MGMT_ACCOUNT_ID:role/$ROLE_TO_ASSUME
|
||||
} &
|
||||
done
|
||||
```
|
||||
|
||||
@@ -1,28 +1,39 @@
|
||||
# AWS Organizations
|
||||
# AWS Organizations in Prowler
|
||||
|
||||
## Get AWS Account details from your AWS Organization
|
||||
## Retrieving AWS Account Details
|
||||
|
||||
Prowler allows you to get additional information of the scanned account from AWS Organizations.
|
||||
If AWS Organizations is enabled, Prowler can fetch detailed account information during scans, including:
|
||||
|
||||
If you have AWS Organizations enabled, Prowler can get your account details like account name, email, ARN, organization id and tags and you will have them next to every finding's output.
|
||||
- Account Name
|
||||
- Email Address
|
||||
- ARN
|
||||
- Organization ID
|
||||
- Tags
|
||||
|
||||
In order to do that you can use the argument `-O`/`--organizations-role <organizations_role_arn>`. If this argument is not present Prowler will try to fetch that information automatically if the AWS account is a delegated administrator for the AWS Organization.
|
||||
These details will be included alongside each security finding in the output.
|
||||
|
||||
### Enabling AWS Organizations Data Retrieval
|
||||
|
||||
To retrieve AWS Organizations account details, use the `-O`/`--organizations-role <organizations_role_arn>` argument. If this argument is not provided, Prowler will attempt to fetch the data automatically—provided the AWS account is a delegated administrator for the AWS Organization.
|
||||
|
||||
???+ note
|
||||
Refer [here](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_delegate_policies.html) for more information about AWS Organizations delegated administrator.
|
||||
For more information on AWS Organizations delegated administrator, refer to the official documentation [here](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_delegate_policies.html).
|
||||
|
||||
See the following sample command:
|
||||
The following command is an example:
|
||||
|
||||
```shell
|
||||
prowler aws \
|
||||
-O arn:aws:iam::<management_organizations_account_id>:role/<role_name>
|
||||
```
|
||||
|
||||
???+ note
|
||||
Make sure the role in your AWS Organizations management account has the permissions `organizations:DescribeAccount` and `organizations:ListTagsForResource`.
|
||||
Ensure the IAM role used in your AWS Organizations management account has the following permissions:`organizations:DescribeAccount` and `organizations:ListTagsForResource`.
|
||||
|
||||
Prowler will scan the AWS account and get the account details from AWS Organizations.
|
||||
|
||||
In the JSON output below you can see tags coded in base64 to prevent breaking CSV or JSON due to its format:
|
||||
### Handling JSON Output
|
||||
|
||||
In Prowler’s JSON output, tags are encoded in Base64 to prevent formatting errors in CSV or JSON outputs. This ensures compatibility when exporting findings.
|
||||
|
||||
```json
|
||||
"Account Email": "my-prod-account@domain.com",
|
||||
@@ -34,17 +45,17 @@ In the JSON output below you can see tags coded in base64 to prevent breaking CS
|
||||
|
||||
The additional fields in CSV header output are as follows:
|
||||
|
||||
- ACCOUNT_DETAILS_EMAIL
|
||||
- ACCOUNT_DETAILS_NAME
|
||||
- ACCOUNT_DETAILS_ARN
|
||||
- ACCOUNT_DETAILS_ORG
|
||||
- ACCOUNT_DETAILS_TAGS
|
||||
- ACCOUNT\_DETAILS\_EMAIL
|
||||
- ACCOUNT\_DETAILS\_NAME
|
||||
- ACCOUNT\_DETAILS\_ARN
|
||||
- ACCOUNT\_DETAILS\_ORG
|
||||
- ACCOUNT\_DETAILS\_TAGS
|
||||
|
||||
## Extra: Run Prowler across all accounts in AWS Organizations by assuming roles
|
||||
|
||||
If you want to run Prowler across all accounts of AWS Organizations you can do this:
|
||||
### Running Prowler Across All AWS Organization Accounts
|
||||
|
||||
1. First get a list of accounts that are not suspended:
|
||||
1. To run Prowler across all accounts in AWS Organizations, first retrieve a list of accounts that are not suspended:
|
||||
|
||||
```shell
|
||||
ACCOUNTS_IN_ORGS=$(aws organizations list-accounts \
|
||||
@@ -65,5 +76,4 @@ If you want to run Prowler across all accounts of AWS Organizations you can do t
|
||||
```
|
||||
|
||||
???+ note
|
||||
Using the same for loop it can be scanned a list of accounts with a variable like:
|
||||
</br>`ACCOUNTS_LIST='11111111111 2222222222 333333333'`
|
||||
This same loop structure can be adapted to scan a predefined list of accounts using a variable like the following: </br>`ACCOUNTS_LIST='11111111111 2222222222 333333333'`
|
||||
|
||||
@@ -7,62 +7,81 @@ By default Prowler is able to scan the following AWS partitions:
|
||||
- GovCloud (US): `aws-us-gov`
|
||||
|
||||
???+ note
|
||||
To check the available regions for each partition and service please refer to the following document [aws_regions_by_service.json](https://github.com/prowler-cloud/prowler/blob/master/prowler/providers/aws/aws_regions_by_service.json)
|
||||
To check the available regions for each partition and service, refer to: [aws\_regions\_by\_service.json](https://github.com/prowler-cloud/prowler/blob/master/prowler/providers/aws/aws_regions_by_service.json)
|
||||
|
||||
It is important to take into consideration that to scan the China (`aws-cn`) or GovCloud (`aws-us-gov`) partitions it is either required to have a valid region for that partition in your AWS credentials or to specify the regions you want to audit for that partition using the `-f/--region` flag.
|
||||
## Scanning AWS China and GovCloud Partitions in Prowler
|
||||
|
||||
When scanning the China (`aws-cn`) or GovCloud (`aws-us-gov`), ensure one of the following:
|
||||
|
||||
- Your AWS credentials include a valid region within the desired partition.
|
||||
|
||||
- Specify the regions to audit within that partition using the `-f/--region` flag.
|
||||
|
||||
???+ note
|
||||
Please, refer to https://boto3.amazonaws.com/v1/documentation/api/latest/guide/credentials.html#configuring-credentials for more information about the AWS credentials configuration.
|
||||
Refer to: https://boto3.amazonaws.com/v1/documentation/api/latest/guide/credentials.html#configuring-credentials for more information about the AWS credential configuration.
|
||||
|
||||
### Scanning Specific Regions
|
||||
|
||||
To scan a particular AWS region with Prowler, use:
|
||||
|
||||
Prowler can scan specific region(s) with:
|
||||
```console
|
||||
prowler aws -f/--region eu-west-1 us-east-1
|
||||
```
|
||||
|
||||
You can get more information about the available partitions and regions in the following [Botocore](https://github.com/boto/botocore) [file](https://github.com/boto/botocore/blob/22a19ea7c4c2c4dd7df4ab8c32733cba0c7597a4/botocore/data/partitions.json).
|
||||
### AWS Credentials Configuration
|
||||
|
||||
For details on configuring AWS credentials, refer to the following [Botocore](https://github.com/boto/botocore) [file](https://github.com/boto/botocore/blob/22a19ea7c4c2c4dd7df4ab8c32733cba0c7597a4/botocore/data/partitions.json).
|
||||
|
||||
## AWS China
|
||||
## Scanning AWS Partitions in Prowler
|
||||
|
||||
To scan your AWS account in the China partition (`aws-cn`):
|
||||
### AWS China
|
||||
|
||||
To scan an account in the AWS China partition (`aws-cn`):
|
||||
|
||||
- By using the `-f/--region` flag:
|
||||
|
||||
```
|
||||
prowler aws --region cn-north-1 cn-northwest-1
|
||||
```
|
||||
|
||||
- By using the region configured in your AWS profile at `~/.aws/credentials` or `~/.aws/config`:
|
||||
|
||||
```
|
||||
[default]
|
||||
aws_access_key_id = XXXXXXXXXXXXXXXXXXX
|
||||
aws_secret_access_key = XXXXXXXXXXXXXXXXXXX
|
||||
region = cn-north-1
|
||||
```
|
||||
|
||||
- Using the `-f/--region` flag:
|
||||
```
|
||||
prowler aws --region cn-north-1 cn-northwest-1
|
||||
```
|
||||
- Using the region configured in your AWS profile at `~/.aws/credentials` or `~/.aws/config`:
|
||||
```
|
||||
[default]
|
||||
aws_access_key_id = XXXXXXXXXXXXXXXXXXX
|
||||
aws_secret_access_key = XXXXXXXXXXXXXXXXXXX
|
||||
region = cn-north-1
|
||||
```
|
||||
???+ note
|
||||
With this option all the partition regions will be scanned without the need of use the `-f/--region` flag
|
||||
With this configuration, all partition regions will be scanned without needing the `-f/--region` flag
|
||||
|
||||
### AWS GovCloud (US)
|
||||
|
||||
## AWS GovCloud (US)
|
||||
To scan an account in the AWS GovCloud (US) partition (`aws-us-gov`):
|
||||
|
||||
To scan your AWS account in the GovCloud (US) partition (`aws-us-gov`):
|
||||
- By using the `-f/--region` flag:
|
||||
|
||||
```
|
||||
prowler aws --region us-gov-east-1 us-gov-west-1
|
||||
```
|
||||
|
||||
- By using the region configured in your AWS profile at `~/.aws/credentials` or `~/.aws/config`:
|
||||
|
||||
```
|
||||
[default]
|
||||
aws_access_key_id = XXXXXXXXXXXXXXXXXXX
|
||||
aws_secret_access_key = XXXXXXXXXXXXXXXXXXX
|
||||
region = us-gov-east-1
|
||||
```
|
||||
|
||||
- Using the `-f/--region` flag:
|
||||
```
|
||||
prowler aws --region us-gov-east-1 us-gov-west-1
|
||||
```
|
||||
- Using the region configured in your AWS profile at `~/.aws/credentials` or `~/.aws/config`:
|
||||
```
|
||||
[default]
|
||||
aws_access_key_id = XXXXXXXXXXXXXXXXXXX
|
||||
aws_secret_access_key = XXXXXXXXXXXXXXXXXXX
|
||||
region = us-gov-east-1
|
||||
```
|
||||
???+ note
|
||||
With this option all the partition regions will be scanned without the need of use the `-f/--region` flag
|
||||
With this configuration, all partition regions will be scanned without needing the `-f/--region` flag
|
||||
|
||||
### AWS ISO (US \& Europe)
|
||||
|
||||
## AWS ISO (US & Europe)
|
||||
The AWS ISO partitions—commonly referred to as "secret partitions"—are air-gapped from the Internet, and Prowler does not have a built-in way to scan them. To audit an AWS ISO partition, manually update [aws\_regions\_by\_service.json](https://github.com/prowler-cloud/prowler/blob/master/prowler/providers/aws/aws_regions_by_service.json) to include the partition, region, and services. For example:
|
||||
|
||||
For the AWS ISO partitions, which are known as "secret partitions" and are air-gapped from the Internet, there is no builtin way to scan it. If you want to audit an AWS account in one of the AWS ISO partitions you should manually update the [aws_regions_by_service.json](https://github.com/prowler-cloud/prowler/blob/master/prowler/providers/aws/aws_regions_by_service.json) and include the partition, region and services, e.g.:
|
||||
```json
|
||||
"iam": {
|
||||
"regions": {
|
||||
|
||||
@@ -1,9 +1,13 @@
|
||||
# Resource ARNs based Scan
|
||||
# Resource ARN-based Scanning
|
||||
|
||||
Prowler allows you to scan only the resources with specific AWS Resource ARNs. This can be done with the flag `--resource-arn` followed by one or more [Amazon Resource Names (ARNs)](https://docs.aws.amazon.com/general/latest/gr/aws-arns-and-namespaces.html) separated by space:
|
||||
Prowler enables scanning of resources based on specific AWS Resource ARNs.
|
||||
|
||||
## Resource ARN-Based Scanning
|
||||
|
||||
Prowler enables scanning of resources based on specific AWS Resource [Amazon Resource Names (ARNs)](https://docs.aws.amazon.com/general/latest/gr/aws-arns-and-namespaces.html). To perform this scan, use the designated flag `--resource-arn` followed by one or more ARNs, separated by spaces.
|
||||
|
||||
```
|
||||
prowler aws --resource-arn arn:aws:iam::012345678910:user/test arn:aws:ec2:us-east-1:123456789012:vpc/vpc-12345678
|
||||
```
|
||||
|
||||
This example will only scan the two resources with those ARNs.
|
||||
Example: This configuration scans only the specified two resources using their ARNs.
|
||||
|
||||
@@ -1,50 +1,74 @@
|
||||
# AWS Assume Role
|
||||
# AWS Assume Role in Prowler
|
||||
|
||||
Prowler uses the AWS SDK (Boto3) underneath so it uses the same authentication methods.
|
||||
## Authentication Overview
|
||||
|
||||
However, there are few ways to run Prowler against multiple accounts using IAM Assume Role feature depending on each use case:
|
||||
Prowler leverages the AWS SDK (Boto3) for authentication, following standard AWS authentication methods.
|
||||
|
||||
1. You can just set up your custom profile inside `~/.aws/config` with all needed information about the role to assume then call it with `prowler aws -p/--profile your-custom-profile`.
|
||||
- An example profile that performs role-chaining is given below. The `credential_source` can either be set to `Environment`, `Ec2InstanceMetadata`, or `EcsContainer`.
|
||||
- Alternatively, you could use the `source_profile` instead of `credential_source` to specify a separate named profile that contains IAM user credentials with permission to assume the target the role. More information can be found [here](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-role.html).
|
||||
```
|
||||
[profile crossaccountrole]
|
||||
role_arn = arn:aws:iam::234567890123:role/SomeRole
|
||||
credential_source = EcsContainer
|
||||
```
|
||||
### Running Prowler Against Multiple Accounts
|
||||
|
||||
2. You can use `-R`/`--role <role_arn>` and Prowler will get those temporary credentials using `Boto3` and run against that given account.
|
||||
```sh
|
||||
prowler aws -R arn:aws:iam::<account_id>:role/<role_name>
|
||||
```
|
||||
- Optionally, the session duration (in seconds, by default 3600) and the external ID of this role assumption can be defined:
|
||||
To execute Prowler across multiple AWS accounts using IAM Assume Role, choose one of the following approaches:
|
||||
|
||||
```sh
|
||||
prowler aws -T/--session-duration <seconds> -I/--external-id <external_id> -R arn:aws:iam::<account_id>:role/<role_name>
|
||||
```
|
||||
1. Custom Profile Configuration
|
||||
|
||||
## Custom Role Session Name
|
||||
Set up a custom profile inside `~/.aws/config` with the necessary role information.
|
||||
|
||||
Then call the profile using `prowler aws -p/--profile your-custom-profile`.
|
||||
|
||||
- Role-Chaining Example Profile The `credential_source` parameter can be set to `Environment`, `Ec2InstanceMetadata`, or `EcsContainer`.
|
||||
|
||||
- Using an Alternative Named Profile
|
||||
|
||||
Instead of the `credential_source` parameter, `source_profile` can be used to specify a separate named profile.
|
||||
|
||||
This profile must contain IAM user credentials with permissions to assume the target role. For additional details, refer to the AWS Assume Role documentation: [here](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-role.html).
|
||||
|
||||
```
|
||||
[profile crossaccountrole]
|
||||
role_arn = arn:aws:iam::234567890123:role/SomeRole
|
||||
credential_source = EcsContainer
|
||||
```
|
||||
|
||||
2. Using IAM Role Assumption in Prowler
|
||||
|
||||
To allow Prowler to retrieve temporary credentials by using `Boto3` and run assessments on the specified account, use the `-R`/`--role <role_arn>` flag.
|
||||
|
||||
```sh
|
||||
prowler aws -R arn:aws:iam::<account_id>:role/<role_name>
|
||||
```
|
||||
|
||||
**Defining Session Duration and External ID**
|
||||
|
||||
Optionally, specify the session duration (in seconds, default: 3600) and the external ID for role assumption:
|
||||
|
||||
```sh
|
||||
prowler aws -T/--session-duration <seconds> -I/--external-id <external_id> -R arn:aws:iam::<account_id>:role/<role_name>
|
||||
```
|
||||
|
||||
## Custom Role Session Name in Prowler
|
||||
|
||||
### Setting a Custom Session Name
|
||||
|
||||
Prowler allows you to specify a custom Role Session name using the following flag:
|
||||
|
||||
Prowler can use your custom Role Session name with:
|
||||
```console
|
||||
prowler aws --role-session-name <role_session_name>
|
||||
```
|
||||
|
||||
???+ note
|
||||
It defaults to `ProwlerAssessmentSession`.
|
||||
If not specified, it defaults to `ProwlerAssessmentSession`.
|
||||
|
||||
## Role MFA
|
||||
## Role MFA Authentication
|
||||
|
||||
If your IAM Role has MFA configured you can use `--mfa` along with `-R`/`--role <role_arn>` and Prowler will ask you to input the following values to get a new temporary session for the IAM Role provided:
|
||||
If your IAM Role is configured with Multi-Factor Authentication (MFA), use `--mfa` along with `-R`/`--role <role_arn>`. Prowler will prompt you to input the following values to obtain a temporary session for the IAM Role provided:
|
||||
|
||||
- ARN of your MFA device
|
||||
- TOTP (Time-Based One-Time Password)
|
||||
|
||||
## Create Role
|
||||
## Creating a Role for One or Multiple Accounts
|
||||
|
||||
To create a role to be assumed in one or multiple accounts you can use either as CloudFormation Stack or StackSet the following [template](https://github.com/prowler-cloud/prowler/blob/master/permissions/create_role_to_assume_cfn.yaml) and adapt it.
|
||||
To create an IAM role that can be assumed in one or multiple AWS accounts, use either a CloudFormation Stack or StackSet and adapt the provided [template](https://github.com/prowler-cloud/prowler/blob/master/permissions/create_role_to_assume_cfn.yaml).
|
||||
|
||||
???+ note "About Session Duration"
|
||||
Depending on the amount of checks you run and the size of your infrastructure, Prowler may require more than 1 hour to finish. Use option `-T <seconds>` to allow up to 12h (43200 seconds). To allow more than 1h you need to modify _"Maximum CLI/API session duration"_ for that particular role, read more [here](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use.html#id_roles_use_view-role-max-session).
|
||||
???+ note
|
||||
**Session Duration Considerations**: Depending on the number of checks performed and the size of your infrastructure, Prowler may require more than 1 hour to complete. Use the `-T <seconds>` option to allow up to 12 hours (43,200 seconds). If you need more than 1 hour, modify the _“Maximum CLI/API session duration”_ setting for the role. Learn more [here](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use.html#id_roles_use_view-role-max-session).
|
||||
|
||||
Bear in mind that if you are using roles assumed by role chaining there is a hard limit of 1 hour so consider not using role chaining if possible, read more about that, in foot note 1 below the table [here](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use.html).
|
||||
⚠️ Important: If assuming roles via role chaining, there is a hard limit of 1 hour. Whenever possible, avoid role chaining to prevent session expiration issues. More details are available in footnote 1 below the table in the [AWS IAM guide](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use.html).
|
||||
|
||||
@@ -1,12 +1,14 @@
|
||||
# Send report to AWS S3 Bucket
|
||||
# Sending Reports to an AWS S3 Bucket
|
||||
|
||||
To save your report in an S3 bucket, use `-B`/`--output-bucket`.
|
||||
To save reports directly in an S3 bucket, use: `-B`/`--output-bucket`.
|
||||
|
||||
```sh
|
||||
prowler aws -B my-bucket
|
||||
```
|
||||
|
||||
If you can use a custom folder and/or filename, use `-o`/`--output-directory` and/or `-F`/`--output-filename`.
|
||||
### Custom Folder and Filename
|
||||
|
||||
For a custom folder and/or filename, specify: `-o`/`--output-directory` and/or `-F`/`--output-filename`.
|
||||
|
||||
```sh
|
||||
prowler aws \
|
||||
@@ -15,14 +17,16 @@ prowler aws \
|
||||
--output-filename output-filename
|
||||
```
|
||||
|
||||
By default Prowler sends HTML, JSON and CSV output formats, if you want to send a custom output format or a single one of the defaults you can specify it with the `-M`/`--output-modes` flag.
|
||||
### Custom Output Formats
|
||||
|
||||
By default, Prowler sends HTML, JSON, and CSV output formats. To specify a single output format, use the `-M`/`--output-modes` flag.
|
||||
|
||||
```sh
|
||||
prowler aws -M csv -B my-bucket
|
||||
```
|
||||
|
||||
|
||||
???+ note
|
||||
In the case you do not want to use the assumed role credentials but the initial credentials to put the reports into the S3 bucket, use `-D`/`--output-bucket-no-assume` instead of `-B`/`--output-bucket`.
|
||||
If you prefer using the initial credentials instead of the assumed role credentials for uploading reports, use `-D`/`--output-bucket-no-assume` instead of `-B`/`--output-bucket`.
|
||||
|
||||
???+ warning
|
||||
Make sure that the used credentials have `s3:PutObject` permissions in the S3 path where the reports are going to be uploaded.
|
||||
Ensure the credentials used have write permissions for the `s3:PutObject` where reports will be uploaded.
|
||||
|
||||
@@ -1,84 +1,92 @@
|
||||
# AWS Security Hub Integration
|
||||
# AWS Security Hub Integration with Prowler
|
||||
|
||||
Prowler supports natively and as **official integration** sending findings to [AWS Security Hub](https://aws.amazon.com/security-hub). This integration allows **Prowler** to import its findings to AWS Security Hub.
|
||||
Prowler natively supports **official integration** with [AWS Security Hub](https://aws.amazon.com/security-hub), allowing security findings to be sent directly. This integration enables **Prowler** to import its findings into AWS Security Hub.
|
||||
|
||||
To activate the integration, follow these steps in at least one AWS region within your AWS account:
|
||||
|
||||
Before sending findings, you will need to enable AWS Security Hub and the **Prowler** integration.
|
||||
## Enabling AWS Security Hub for Prowler Integration
|
||||
|
||||
## Enable AWS Security Hub
|
||||
To enable the integration, follow these steps in **at least** one AWS region within your AWS account.
|
||||
|
||||
To enable the integration you have to perform the following steps, in _at least_ one AWS region of a given AWS account, to enable **AWS Security Hub** and **Prowler** as a partner integration.
|
||||
Since **AWS Security Hub** is a region-based service, it must be activated in each region where security findings need to be collected.
|
||||
|
||||
Since **AWS Security Hub** is a region based service, you will need to enable it in the region or regions you require. You can configure it using the AWS Management Console or the AWS CLI.
|
||||
**Configuration Options**
|
||||
|
||||
AWS Security Hub can be enabled using either of the following methods:
|
||||
|
||||
???+ note
|
||||
Take into account that enabling this integration will incur in costs in AWS Security Hub, please refer to its pricing [here](https://aws.amazon.com/security-hub/pricing/) for more information.
|
||||
Enabling this integration incurs costs in AWS Security Hub. Refer to [this information](https://aws.amazon.com/security-hub/pricing/) for details.
|
||||
|
||||
### Using the AWS Management Console
|
||||
|
||||
#### Enable AWS Security Hub
|
||||
#### Enabling AWS Security Hub for Prowler Integration
|
||||
|
||||
If you have currently AWS Security Hub enabled you can skip to the [next section](#enable-prowler-integration).
|
||||
If AWS Security Hub is already enabled, you can proceed to the [next section](#enable-prowler-integration).
|
||||
|
||||
1. Open the **AWS Security Hub** console at https://console.aws.amazon.com/securityhub/.
|
||||
1. Enable AWS Security Hub via Console: Open the **AWS Security Hub** console: https://console.aws.amazon.com/securityhub/.
|
||||
|
||||
2. When you open the Security Hub console for the first time make sure that you are in the region you want to enable, then choose **Go to Security Hub**.
|
||||

|
||||
2. Ensure you are in the correct AWS region, then select “**Go to Security Hub**”. 
|
||||
|
||||
3. On the next page, the Security standards section lists the security standards that Security Hub supports. Select the check box for a standard to enable it, and clear the check box to disable it.
|
||||
3. In the “Security Standards” section, review the supported security standards. Select the checkbox for each standard you want to enable, or clear it to disable a standard.
|
||||
|
||||
4. Choose **Enable Security Hub**.
|
||||

|
||||
4. Choose “**Enable Security Hub**”. 
|
||||
|
||||
#### Enable Prowler Integration
|
||||
#### Enabling Prowler Integration in AWS Security Hub
|
||||
|
||||
If you have currently the Prowler integration enabled in AWS Security Hub you can skip to the [next section](#send-findings) and start sending findings.
|
||||
If the Prowler integration is already enabled in AWS Security Hub, you can proceed to the [next section](#send-findings) and begin sending findings.
|
||||
|
||||
Once **AWS Security Hub** is enabled you will need to enable **Prowler** as partner integration to allow **Prowler** to send findings to your **AWS Security Hub**.
|
||||
Once **AWS Security Hub** is activated, **Prowler** must be enabled as partner integration to allow security findings to be sent to it.
|
||||
|
||||
1. Open the **AWS Security Hub** console at https://console.aws.amazon.com/securityhub/.
|
||||
1. Enabling AWS Security Hub via Console
|
||||
Open the **AWS Security Hub** console: https://console.aws.amazon.com/securityhub/.
|
||||
|
||||
2. Select the **Integrations** tab in the right-side menu bar.
|
||||

|
||||
2. Select the “**Integrations**” tab from the right-side menu bar. 
|
||||
|
||||
3. Search for _Prowler_ in the text search box and the **Prowler** integration will appear.
|
||||
3. Search for “_Prowler_” in the text search box and the **Prowler** integration will appear.
|
||||
|
||||
4. Once there, click on **Accept Findings** to allow **AWS Security Hub** to receive findings from **Prowler**.
|
||||

|
||||
4. Click “**Accept Findings**” to authorize **AWS Security Hub** to receive findings from **Prowler**. 
|
||||
|
||||
5. A new modal will appear to confirm that you are enabling the **Prowler** integration.
|
||||

|
||||
5. A new modal will appear to confirm that the integration with **Prowler** is being enabled. 
|
||||
|
||||
6. Right after click on **Accept Findings**, you will see that the integration is enabled in **AWS Security Hub**.
|
||||

|
||||
6. Click “**Accept Findings**”, to authorize **AWS Security Hub** to receive findings from Prowler. 
|
||||
|
||||
### Using the AWS CLI
|
||||
### Using AWS CLI
|
||||
|
||||
To enable **AWS Security Hub** and the **Prowler** integration you have to run the following commands using the AWS CLI:
|
||||
To enable **AWS Security Hub** and integrate **Prowler**, execute the following AWS CLI commands:
|
||||
|
||||
**Step 1: Enable AWS Security Hub**
|
||||
|
||||
Run the following command to activate AWS Security Hub in the desired region:
|
||||
|
||||
```shell
|
||||
aws securityhub enable-security-hub --region <region>
|
||||
```
|
||||
???+ note
|
||||
For this command to work you will need the `securityhub:EnableSecurityHub` permission. You will need to set the AWS region where you want to enable AWS Security Hub.
|
||||
|
||||
Once **AWS Security Hub** is enabled you will need to enable **Prowler** as partner integration to allow **Prowler** to send findings to your AWS Security Hub. You have to run the following commands using the AWS CLI:
|
||||
???+ note
|
||||
This command requires the `securityhub:EnableSecurityHub` permission. Ensure you set the correct AWS region where you want to enable AWS Security Hub.
|
||||
|
||||
**Step 2: Enable Prowler Integration**
|
||||
|
||||
Once **AWS Security Hub** is activated, **Prowler** must be enabled as partner integration to allow security findings to be sent to it. Run the following AWS CLI commands:
|
||||
|
||||
```shell
|
||||
aws securityhub enable-import-findings-for-product --region eu-west-1 --product-arn arn:aws:securityhub:<region>::product/prowler/prowler
|
||||
```
|
||||
|
||||
???+ note
|
||||
You will need to set the AWS region where you want to enable the integration and also the AWS region also within the ARN. For this command to work you will need the `securityhub:securityhub:EnableImportFindingsForProduct` permission.
|
||||
Specify the AWS region where you want to enable the integration. Ensure the region is correctly set within the ARN value. This command requires the`securityhub:securityhub:EnableImportFindingsForProduct` permission.
|
||||
|
||||
## Sending Findings to AWS Security Hub
|
||||
|
||||
## Send Findings
|
||||
Once it is enabled, it is as simple as running the command below (for all regions):
|
||||
Once AWS Security Hub is enabled, findings can be sent using the following commands:
|
||||
|
||||
For all regions:
|
||||
|
||||
```sh
|
||||
prowler aws --security-hub
|
||||
```
|
||||
|
||||
or for only one filtered region like eu-west-1:
|
||||
For a specific region (e.g., eu-west-1):
|
||||
|
||||
```sh
|
||||
prowler --security-hub --region eu-west-1
|
||||
@@ -91,52 +99,60 @@ prowler --security-hub --region eu-west-1
|
||||
|
||||
To have updated findings in Security Hub you have to run Prowler periodically. Once a day or every certain amount of hours.
|
||||
|
||||
### See you Prowler findings in AWS Security Hub
|
||||
### Viewing Prowler Findings in AWS Security Hub
|
||||
|
||||
Once configured the **AWS Security Hub** in your next scan you will receive the **Prowler** findings in the AWS regions configured. To review those findings in **AWS Security Hub**:
|
||||
After enabling **AWS Security Hub**, findings from **Prowler** will be available in the configured AWS regions. Reviewing Prowler Findings in **AWS Security Hub**:
|
||||
|
||||
1. Open the **AWS Security Hub** console at https://console.aws.amazon.com/securityhub/.
|
||||
1. Enabling AWS Security Hub via Console
|
||||
|
||||
2. Select the **Findings** tab in the right-side menu bar.
|
||||

|
||||
Open the **AWS Security Hub** console: https://console.aws.amazon.com/securityhub/.
|
||||
|
||||
3. Use the search box filters and use the **Product Name** filter with the value _Prowler_ to see the findings sent from **Prowler**.
|
||||
2. Select the “**Findings**” tab from the right-side menu bar. 
|
||||
|
||||
4. Then, you can click on the check **Title** to see the details and the history of a finding.
|
||||

|
||||
3. Use the search box filters and apply the “**Product Name**” filter with the value _Prowler_ to display findings sent by **Prowler**.
|
||||
|
||||
As you can see in the related requirements section, in the detailed view of the findings, **Prowler** also sends compliance information related to every finding.
|
||||
4. Click the check “**Title**” to access its detailed view, including its history and status. 
|
||||
|
||||
## Send findings to Security Hub assuming an IAM Role
|
||||
#### Compliance Information
|
||||
|
||||
When you are auditing a multi-account AWS environment, you can send findings to a Security Hub of another account by assuming an IAM role from that account using the `-R` flag in the Prowler command:
|
||||
As outlined in the Requirements section, the detailed view includes compliance details for each finding reported by **Prowler**.
|
||||
|
||||
## Sending Findings to Security Hub with IAM Role Assumption
|
||||
|
||||
### Multi-Account AWS Auditing
|
||||
|
||||
When auditing a multi-account AWS environment, Prowler allows you to send findings to a Security Hub in another account by assuming an IAM role from that target account.
|
||||
|
||||
#### Using an IAM Role to Send Findings
|
||||
|
||||
To send findings to Security Hub, use the `-R` flag in the Prowler command:
|
||||
|
||||
```sh
|
||||
prowler --security-hub --role arn:aws:iam::123456789012:role/ProwlerExecutionRole
|
||||
```
|
||||
|
||||
???+ note
|
||||
Remember that the used role needs to have permissions to send findings to Security Hub. To get more information about the permissions required, please refer to the following IAM policy [prowler-security-hub.json](https://github.com/prowler-cloud/prowler/blob/master/permissions/prowler-security-hub.json)
|
||||
The specified IAM role must have the necessary permissions to send findings to Security Hub. For details on the required permissions, refer to the IAM policy: [prowler-security-hub.json](https://github.com/prowler-cloud/prowler/blob/master/permissions/prowler-security-hub.json)
|
||||
|
||||
## Sending Only Failed Findings to AWS Security Hub
|
||||
|
||||
## Send only failed findings to Security Hub
|
||||
|
||||
When using the **AWS Security Hub** integration you can send only the `FAIL` findings generated by **Prowler**. Therefore, the **AWS Security Hub** usage costs eventually would be lower. To follow that recommendation you could add the `--status FAIL` flag to the Prowler command:
|
||||
When using **AWS Security Hub** integration, **Prowler** allows sending only failed findings (`FAIL`), helping reduce **AWS Security Hub** usage costs. To enable this, add the `--status FAIL` flag to the Prowler command:
|
||||
|
||||
```sh
|
||||
prowler --security-hub --status FAIL
|
||||
```
|
||||
|
||||
You can use, instead of the `--status FAIL` argument, the `--send-sh-only-fails` argument to save all the findings in the Prowler outputs but just to send FAIL findings to AWS Security Hub:
|
||||
**Configuring Findings Output**
|
||||
|
||||
Instead of using `--status FAIL`, the `--send-sh-only-fails` argument to store all findings in Prowler outputs while sending only FAIL findings to AWS Security:
|
||||
|
||||
```sh
|
||||
prowler --security-hub --send-sh-only-fails
|
||||
```
|
||||
|
||||
## Skip sending updates of findings to Security Hub
|
||||
## Skipping Updates for Findings in Security Hub
|
||||
|
||||
By default, Prowler archives all its findings in Security Hub that have not appeared in the last scan.
|
||||
You can skip this logic by using the option `--skip-sh-update` so Prowler will not archive older findings:
|
||||
By default, Prowler archives any findings in Security Hub that were not detected in the latest scan. To prevent older findings from being archived, use the `--skip-sh-update` option:
|
||||
|
||||
```sh
|
||||
prowler --security-hub --skip-sh-update
|
||||
|
||||
@@ -1,9 +1,9 @@
|
||||
# Tags-based Scan
|
||||
# Tag-based scan
|
||||
|
||||
Prowler allows you to scan only the resources that contain specific tags. This can be done with the flag `--resource-tags` followed by the tags `Key=Value` separated by space:
|
||||
Prowler provides the capability to scan only resources containing specific tags. To execute this, use the designated flag `--resource-tags` followed by the tags `Key=Value`, separated by spaces.
|
||||
|
||||
```
|
||||
prowler aws --resource-tags Environment=dev Project=prowler
|
||||
```
|
||||
|
||||
This example will only scan the resources that contains both tags.
|
||||
This configuration scans only resources that contain both specified tags.
|
||||
|
||||
@@ -1,28 +1,32 @@
|
||||
# Threat Detection
|
||||
# Threat Detection in AWS with Prowler
|
||||
|
||||
Prowler enables threat detection in AWS by analyzing CloudTrail log records. To execute threat detection checks, use the following command:
|
||||
|
||||
Prowler allows you to do threat detection in AWS based on the CloudTrail log records. To run checks related with threat detection use:
|
||||
```
|
||||
prowler aws --category threat-detection
|
||||
```
|
||||
This command will run these checks:
|
||||
|
||||
* `cloudtrail_threat_detection_privilege_escalation` -> Detects privilege escalation attacks.
|
||||
* `cloudtrail_threat_detection_enumeration` -> Detects enumeration attacks.
|
||||
* `cloudtrail_threat_detection_llm_jacking` -> Detects LLM Jacking attacks.
|
||||
This command runs checks to detect:
|
||||
|
||||
* `cloudtrail_threat_detection_privilege_escalation`: Privilege escalation attacks
|
||||
* `cloudtrail_threat_detection_enumeration`: Enumeration attacks
|
||||
* `cloudtrail_threat_detection_llm_jacking`: LLM Jacking attacks
|
||||
|
||||
???+ note
|
||||
Threat Detection checks will be only executed using `--category threat-detection` flag due to performance.
|
||||
Threat detection checks are executed only when the `--category threat-detection` flag is used, due to performance considerations.
|
||||
|
||||
## Config File
|
||||
## Config File for Threat Detection
|
||||
|
||||
If you want to manage the behavior of the Threat Detection checks you can edit `config.yaml` file from `/prowler/config`. In this file you can edit the following attributes related with Threat Detection:
|
||||
To manage the behavior of threat detection checks, edit the configuration file located in `config.yaml` file from `/prowler/config`. The following attributes can be modified, all related to threat detection:
|
||||
|
||||
* `threat_detection_privilege_escalation_threshold`: determines the percentage of actions found to decide if it is an privilege_scalation attack event, by default is 0.2 (20%)
|
||||
* `threat_detection_privilege_escalation_minutes`: it is the past minutes to search from now for privilege_escalation attacks, by default is 1440 minutes (24 hours)
|
||||
* `threat_detection_privilege_escalation_actions`: these are the default actions related with privilege escalation.
|
||||
* `threat_detection_enumeration_threshold`: determines the percentage of actions found to decide if it is an enumeration attack event, by default is 0.3 (30%)
|
||||
* `threat_detection_enumeration_minutes`: it is the past minutes to search from now for enumeration attacks, by default is 1440 minutes (24 hours)
|
||||
* `threat_detection_enumeration_actions`: these are the default actions related with enumeration attacks.
|
||||
* `threat_detection_llm_jacking_threshold`: determines the percentage of actions found to decide if it is an LLM Jacking attack event, by default is 0.4 (40%)
|
||||
* `threat_detection_llm_jacking_minutes`: it is the past minutes to search from now for LLM Jacking attacks, by default is 1440 minutes (24 hours)
|
||||
* `threat_detection_llm_jacking_actions`: these are the default actions related with LLM Jacking attacks.
|
||||
* `threat_detection_privilege_escalation_threshold`: Defines the percentage of actions required to classify an event as a privilege escalation attack. Default: 0.2 (20%)
|
||||
* `threat_detection_privilege_escalation_minutes`: Specifies the time window (in minutes) to search for privilege escalation attack patterns. Default: 1440 minutes (24 hours).
|
||||
* `threat_detection_privilege_escalation_actions`: Lists the default actions associated with privilege escalation attacks.
|
||||
* `threat_detection_enumeration_threshold`: Defines the percentage of actions required to classify an event as an enumeration attack. Default: 0.3 (30%)
|
||||
* `threat_detection_enumeration_minutes`: Specifies the time window (in minutes) to search for enumeration attack patterns. Default: 1440 minutes (24 hours).
|
||||
* `threat_detection_enumeration_actions`: Lists the default actions associated with enumeration attacks.
|
||||
* `threat_detection_llm_jacking_threshold`: Defines the percentage of actions required to classify an event as LLM jacking attack. Default: 0.4 (40%)
|
||||
* `threat_detection_llm_jacking_minutes`: Specifies the time window (in minutes) to search for LLM jacking attack patterns. Default: 1440 minutes (24 hours).
|
||||
* `threat_detection_llm_jacking_actions`: Lists the default actions associated with LLM jacking attacks.
|
||||
|
||||
Modify these attributes in the configuration file to fine-tune threat detection checks based on your security requirements.
|
||||
|
||||
@@ -1,8 +1,8 @@
|
||||
# Check mapping between Prowler v4/v3 and v2
|
||||
# Check Mapping Prowler v4/v3 to v2
|
||||
|
||||
Prowler v3 and v4 comes with different identifiers but we maintained the same checks that were implemented in v2. The reason for this change is because in previous versions of Prowler, check names were mostly based on CIS Benchmark for AWS. In v4 and v3 all checks are independent from any security framework and they have its own name and ID.
|
||||
Prowler v3 and v4 introduce distinct identifiers while preserving the checks originally implemented in v2. This change was made because, in previous versions, check names were primarily derived from the CIS Benchmark for AWS. Starting with v3 and v4, all checks are independent of any security framework and have unique names and IDs.
|
||||
|
||||
If you need more information about how new compliance implementation works in Prowler v4 and v3 see [Compliance](../compliance.md) section.
|
||||
For more details on the updated compliance implementation in Prowler v4 and v3, refer to the [Compliance](../compliance.md) section.
|
||||
|
||||
```
|
||||
checks_v4_v3_to_v2_mapping = {
|
||||
@@ -17,7 +17,7 @@ checks_v4_v3_to_v2_mapping = {
|
||||
"apigateway_restapi_public": "extra745",
|
||||
"apigateway_restapi_logging_enabled": "extra722",
|
||||
"apigateway_restapi_waf_acl_attached": "extra744",
|
||||
"apigatewayv2_api_access_logging_enabled": "extra7156",
|
||||
“apigatewayv2_api_access_logging_enabled": "extra7156",
|
||||
"apigatewayv2_api_authorizers_enabled": "extra7157",
|
||||
"appstream_fleet_default_internet_access_disabled": "extra7193",
|
||||
"appstream_fleet_maximum_session_duration": "extra7190",
|
||||
|
||||
@@ -1,27 +1,28 @@
|
||||
# Azure authentication
|
||||
# Azure Authentication in Prowler
|
||||
|
||||
By default Prowler uses Azure Python SDK identity package authentication methods using the classes `DefaultAzureCredential` and `InteractiveBrowserCredential`.
|
||||
This allows Prowler to authenticate against azure using the following methods:
|
||||
By default, Prowler utilizes the Azure Python SDK identity package for authentication, leveraging the classes `DefaultAzureCredential` and `InteractiveBrowserCredential`. This enables authentication against Azure using the following approaches:
|
||||
|
||||
- Service principal authentication by environment variables (Enterprise Application)
|
||||
- Current AZ CLI credentials stored
|
||||
- Service principal authentication via environment variables (Enterprise Application)
|
||||
- Currently stored AZ CLI credentials
|
||||
- Interactive browser authentication
|
||||
- Managed identity authentication
|
||||
|
||||
To launch the tool it is required to specify which method is used through the following flags:
|
||||
Before launching the tool, specify the desired method using the following flags:
|
||||
|
||||
```console
|
||||
# To use service principal authentication
|
||||
# Service principal authentication:
|
||||
prowler azure --sp-env-auth
|
||||
|
||||
# To use az cli authentication
|
||||
# AZ CLI authentication
|
||||
prowler azure --az-cli-auth
|
||||
|
||||
# To use browser authentication
|
||||
# Browser authentication
|
||||
prowler azure --browser-auth --tenant-id "XXXXXXXX"
|
||||
|
||||
# To use managed identity auth
|
||||
# Managed identity authentication
|
||||
prowler azure --managed-identity-auth
|
||||
```
|
||||
|
||||
To use Prowler you need to set up also the permissions required to access your resources in your Azure account, to more details refer to [Requirements](../../getting-started/requirements.md)
|
||||
## Permission Configuration
|
||||
|
||||
To ensure Prowler can access the required resources within your Azure account, proper permissions must be configured. Refer to the [Requirements](../../getting-started/requirements.md) section for details on setting up necessary privileges.
|
||||
|
||||
@@ -1,79 +1,100 @@
|
||||
# How to create Prowler Service Principal Application
|
||||
# Creating a Prowler Service Principal Application
|
||||
|
||||
To allow Prowler assume an identity to start the scan with the required privileges is necesary to create a Service Principal. This Service Principal is going to be used to authenticate against Azure and retrieve the metadata needed to perform the checks.
|
||||
To enable Prowler to assume an identity for scanning with the required privileges, a Service Principal must be created. This Service Principal authenticates against Azure and retrieves necessary metadata for checks.
|
||||
|
||||
To create a Service Principal Application you can use the Azure Portal or the Azure CLI.
|
||||
### Methods for Creating a Service Principal
|
||||
|
||||
## From Azure Portal / Entra Admin Center
|
||||
Service Principal Applications can be created using either the Azure Portal or the Azure CLI.
|
||||
|
||||
1. Access to Microsoft Entra ID
|
||||
2. In the left menu bar, go to "App registrations"
|
||||
3. Once there, in the menu bar click on "+ New registration" to register a new application
|
||||
4. Fill the "Name, select the "Supported account types" and click on "Register. You will be redirected to the applications page.
|
||||
5. Once in the application page, in the left menu bar, select "Certificates & secrets"
|
||||
6. In the "Certificates & secrets" view, click on "+ New client secret"
|
||||
7. Fill the "Description" and "Expires" fields and click on "Add"
|
||||
8. Copy the value of the secret, it is going to be used as `AZURE_CLIENT_SECRET` environment variable.
|
||||
## Creating a Service Principal via Azure Portal / Entra Admin Center
|
||||
|
||||

|
||||
1. Access Microsoft Entra ID.
|
||||
2. In the left menu bar, navigate to **"App registrations"**.
|
||||
3. Click **"+ New registration"** in the menu bar to register a new application
|
||||
4. Fill the **"Name"**, select the **"Supported account types"** and click **"Register"**. You will be redirected to the applications page.
|
||||
5. In the left menu bar, select **"Certificates & secrets"**.
|
||||
6. Under the **"Certificates & secrets"** view, click **"+ New client secret"**.
|
||||
7. Fill the **"Description"** and **"Expires"** fields, then click **"Add"**.
|
||||
8. Copy the secret value, as it will be used as `AZURE_CLIENT_SECRET` environment variable.
|
||||
|
||||

|
||||
|
||||
## From Azure CLI
|
||||
|
||||
To create a Service Principal using the Azure CLI, follow the next steps:
|
||||
### Creating a Service Principal
|
||||
|
||||
1. Open a terminal and execute the following command to create a new Service Principal application:
|
||||
```console
|
||||
az ad sp create-for-rbac --name "ProwlerApp"
|
||||
```
|
||||
2. The output of the command is going to be similar to the following:
|
||||
```json
|
||||
{
|
||||
"appId": "XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX",
|
||||
"displayName": "ProwlerApp",
|
||||
"password": "XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX",
|
||||
"tenant": "XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX"
|
||||
}
|
||||
```
|
||||
3. Save the values of `appId`, `password` and `tenant` to be used as credentials in Prowler.
|
||||
To create a Service Principal using the Azure CLI, follow these steps:
|
||||
|
||||
# Assigning the proper permissions
|
||||
1. Open a terminal and execute the following command:
|
||||
|
||||
To allow Prowler to retrieve metadata from the identity assumed and run specific Entra checks, it is needed to assign the following permissions:
|
||||
```console
|
||||
az ad sp create-for-rbac --name "ProwlerApp"
|
||||
```
|
||||
|
||||
- `Domain.Read.All`
|
||||
2. The output will be similar to:
|
||||
|
||||
```json
|
||||
{
|
||||
"appId": "XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX",
|
||||
"displayName": "ProwlerApp",
|
||||
"password": "XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX",
|
||||
"tenant": "XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX"
|
||||
}
|
||||
```
|
||||
|
||||
3. Save the values of `appId`, `password` and `tenant`, as they will be used as credentials in Prowler.
|
||||
|
||||
## Assigning Proper Permissions
|
||||
|
||||
To allow Prowler to retrieve metadata from the assumed identity and run Entra checks, assign the following permissions:
|
||||
|
||||
- `Directory.Read.All`
|
||||
- `Policy.Read.All`
|
||||
- `UserAuthenticationMethod.Read.All` (used only for the Entra checks related with multifactor authentication)
|
||||
|
||||
To assign the permissions you can make it from the Azure Portal or using the Azure CLI.
|
||||
Permissions can be assigned via the Azure Portal or the Azure CLI.
|
||||
|
||||
???+ note
|
||||
Once you have created and assigned the proper Entra permissions to the application, you can go to this [tutorial](../azure/subscriptions.md) to add the subscription permissions to the application and start scanning your resources.
|
||||
After creating and assigning the necessary Entra permissions, follow this [tutorial](../azure/subscriptions.md) to add subscription permissions to the application and start scanning your resources.
|
||||
|
||||
## From Azure Portal
|
||||
### Assigning the Reader Role in Azure Portal
|
||||
|
||||
1. Access Microsoft Entra ID.
|
||||
|
||||
2. In the left menu bar, navigate to “App registrations”.
|
||||
|
||||
3. Select the created application.
|
||||
|
||||
4. In the left menu bar, select “API permissions”.
|
||||
|
||||
5. Click “+ Add a permission” and select “Microsoft Graph”.
|
||||
|
||||
6. In the “Microsoft Graph” view, select “Application permissions”.
|
||||
|
||||
1. Access to Microsoft Entra ID
|
||||
2. In the left menu bar, go to "App registrations"
|
||||
3. Once there, select the application that you have created
|
||||
4. In the left menu bar, select "API permissions"
|
||||
5. Then click on "+ Add a permission" and select "Microsoft Graph"
|
||||
6. Once in the "Microsoft Graph" view, select "Application permissions"
|
||||
7. Finally, search for "Directory", "Policy" and "UserAuthenticationMethod" select the following permissions:
|
||||
|
||||
- `Domain.Read.All`
|
||||
|
||||
- `Policy.Read.All`
|
||||
|
||||
- `UserAuthenticationMethod.Read.All`
|
||||
8. Click on "Add permissions" to apply the new permissions.
|
||||
9. Finally, an admin should click on "Grant admin consent for [your tenant]" to apply the permissions.
|
||||
|
||||
8. Click “Add permissions” to apply the new permissions.
|
||||
|
||||

|
||||
9. Finally, an admin must click “Grant admin consent for \[your tenant]” to apply the permissions.
|
||||
|
||||
## From Azure CLI
|
||||

|
||||
|
||||
1. Open a terminal and execute the following command to assign the permissions to the Service Principal:
|
||||
```console
|
||||
az ad app permission add --id {appId} --api 00000003-0000-0000-c000-000000000000 --api-permissions 7ab1d382-f21e-4acd-a863-ba3e13f7da61=Role 246dd0d5-5bd0-4def-940b-0421030a5b68=Role 38d9df27-64da-44fd-b7c5-a6fbac20248f=Role
|
||||
```
|
||||
2. The admin consent is needed to apply the permissions, an admin should execute the following command:
|
||||
```console
|
||||
az ad app permission admin-consent --id {appId}
|
||||
```
|
||||
### From Azure CLI
|
||||
|
||||
1. To grant permissions to a Service Principal, execute the following command in a terminal:
|
||||
|
||||
```console
|
||||
az ad app permission add --id {appId} --api 00000003-0000-0000-c000-000000000000 --api-permissions 7ab1d382-f21e-4acd-a863-ba3e13f7da61=Role 246dd0d5-5bd0-4def-940b-0421030a5b68=Role 38d9df27-64da-44fd-b7c5-a6fbac20248f=Role
|
||||
```
|
||||
|
||||
2. Once the permissions are assigned, admin consent is required to finalize the changes. An administrator should run:
|
||||
|
||||
```console
|
||||
az ad app permission admin-consent --id {appId}
|
||||
```
|
||||
|
||||
@@ -1,134 +1,159 @@
|
||||
# Azure subscriptions scope
|
||||
# Azure Subscription Scope
|
||||
|
||||
The main target for performing the scans in Azure is the subscription scope. Prowler needs to have the proper permissions to access the subscription and retrieve the metadata needed to perform the checks.
|
||||
Prowler performs security scans within the subscription scope in Azure. To execute checks, it requires appropriate permissions to access the subscription and retrieve necessary metadata.
|
||||
|
||||
By default, Prowler is multi-subscription, which means that is going to scan all the subscriptions is able to list. If you only assign permissions to one subscription, it is going to scan a single one.
|
||||
Prowler also has the ability to limit the subscriptions to scan to a set passed as input argument, to do so:
|
||||
By default, Prowler operates multi-subscription, scanning all subscriptions it has permission to list. If permissions are granted for only a single subscription, Prowler will limit scans to that subscription.
|
||||
|
||||
## Configuring Specific Subscription Scans in Prowler
|
||||
|
||||
Additionally, Prowler supports restricting scans to specific subscriptions by passing a set of subscription IDs as an input argument. To configure this limitation, use the appropriate command options:
|
||||
|
||||
```console
|
||||
prowler azure --az-cli-auth --subscription-ids <subscription ID 1> <subscription ID 2> ... <subscription ID N>
|
||||
```
|
||||
|
||||
Where you can pass from 1 up to N subscriptions to be scanned.
|
||||
Prowler allows you to specify one or more subscriptions for scanning (up to N), enabling flexible audit configurations.
|
||||
|
||||
???+ warning
|
||||
The multi-subscription feature is only available for the CLI, in the case of Prowler App is only possible to scan one subscription per scan.
|
||||
The multi-subscription feature is available only in the CLI. In Prowler App, each scan is limited to a single subscription.
|
||||
|
||||
## Assign the appropriate permissions to the identity that is going to be assumed by Prowler
|
||||
## Assigning Permissions for Subscription Scans
|
||||
|
||||
To perform scans, ensure that the identity assumed by Prowler has the appropriate permissions.
|
||||
|
||||
Regarding the subscription scope, Prowler, by default, scans all subscriptions it can access. Therefore, it is necessary to add a `Reader` role assignment for each subscription you want to audit. To make it easier and less repetitive to assign roles in environments with multiple subscriptions check the [following section](#recommendation-for-multiple-subscriptions).
|
||||
By default, Prowler scans all accessible subscriptions. If you need to audit specific subscriptions, you must assign the necessary role `Reader` for each one. For streamlined and less repetitive role assignments in multi-subscription environments, refer to the [following section](#recommendation-for-multiple-subscriptions).
|
||||
|
||||
### From Azure Portal
|
||||
### Assigning the Reader Role in Azure Portal
|
||||
|
||||
1. Access to the subscription you want to scan with Prowler.
|
||||
2. Select "Access control (IAM)" in the left menu.
|
||||
3. Click on "+ Add" and select "Add role assignment".
|
||||
4. In the search bar, type `Reader`, select it and click on "Next".
|
||||
5. In the Members tab, click on "+ Select members" and add the members you want to assign this role.
|
||||
6. Click on "Review + assign" to apply the new role.
|
||||
1. To grant Prowler access to scan a specific Azure subscription, follow these steps in Azure Portal:
|
||||
Navigate to the subscription you want to audit with Prowler.
|
||||
|
||||

|
||||
2. In the left menu, select “Access control (IAM)”.
|
||||
|
||||
3. Click “+ Add” and select “Add role assignment”.
|
||||
|
||||
4. In the search bar, enter `Reader`, select it and click “Next”.
|
||||
|
||||
5. In the “Members” tab, click “+ Select members”, then add the accounts to assign this role.
|
||||
|
||||
6. Click “Review + assign” to finalize and apply the role assignment.
|
||||
|
||||

|
||||
|
||||
### From Azure CLI
|
||||
|
||||
1. Open a terminal and execute the following command to assign the `Reader` role to the identity that is going to be assumed by Prowler:
|
||||
```console
|
||||
az role assignment create --role "Reader" --assignee <user, group, or service principal> --scope /subscriptions/<subscription-id>
|
||||
```
|
||||
|
||||
```console
|
||||
az role assignment create --role "Reader" --assignee <user, group, or service principal> --scope /subscriptions/<subscription-id>
|
||||
```
|
||||
|
||||
2. If the command is executed successfully, the output is going to be similar to the following:
|
||||
```json
|
||||
{
|
||||
"condition": null,
|
||||
"conditionVersion": null,
|
||||
"createdBy": "XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX",
|
||||
"createdOn": "YYYY-MM-DDTHH:MM:SS.SSSSSS+00:00",
|
||||
"delegatedManagedIdentityResourceId": null,
|
||||
"description": null,
|
||||
"id": "/subscriptions/XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX/providers/Microsoft.Authorization/roleAssignments/XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX",
|
||||
"name": "XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX",
|
||||
"principalId": "XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX",
|
||||
"principalName": "XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX",
|
||||
"principalType": "ServicePrincipal",
|
||||
"roleDefinitionId": "/subscriptions/XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX/providers/Microsoft.Authorization/roleDefinitions/XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX",
|
||||
"roleDefinitionName": "Reader",
|
||||
"scope": "/subscriptions/XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX",
|
||||
"type": "Microsoft.Authorization/roleAssignments",
|
||||
"updatedBy": "XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX",
|
||||
"updatedOn": "YYYY-MM-DDTHH:MM:SS.SSSSSS+00:00"
|
||||
}
|
||||
```
|
||||
|
||||
```json
|
||||
{
|
||||
"condition": null,
|
||||
"conditionVersion": null,
|
||||
"createdBy": "XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX",
|
||||
"createdOn": "YYYY-MM-DDTHH:MM:SS.SSSSSS+00:00",
|
||||
"delegatedManagedIdentityResourceId": null,
|
||||
"description": null,
|
||||
"id": "/subscriptions/XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX/providers/Microsoft.Authorization/roleAssignments/XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX",
|
||||
"name": "XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX",
|
||||
"principalId": "XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX",
|
||||
"principalName": "XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX",
|
||||
"principalType": "ServicePrincipal",
|
||||
"roleDefinitionId": "/subscriptions/XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX/providers/Microsoft.Authorization/roleDefinitions/XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX",
|
||||
"roleDefinitionName": "Reader",
|
||||
"scope": "/subscriptions/XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX",
|
||||
"type": "Microsoft.Authorization/roleAssignments",
|
||||
"updatedBy": "XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX",
|
||||
"updatedOn": "YYYY-MM-DDTHH:MM:SS.SSSSSS+00:00"
|
||||
}
|
||||
```
|
||||
|
||||
### Prowler Custom Role
|
||||
|
||||
Moreover, some additional read-only permissions not included in the built-in reader role are needed for some checks, for this kind of checks we use a custom role. This role is defined in [prowler-azure-custom-role](https://github.com/prowler-cloud/prowler/blob/master/permissions/prowler-azure-custom-role.json). Once the custom role is created you can assign it in the same way as the `Reader` role.
|
||||
Some read-only permissions required for specific security checks are not included in the built-in Reader role. To support these checks, Prowler utilizes a custom role, defined in [prowler-azure-custom-role](https://github.com/prowler-cloud/prowler/blob/master/permissions/prowler-azure-custom-role.json). Once created, this role can be assigned following the same process as the `Reader` role.
|
||||
|
||||
The checks that needs the `ProwlerRole` can be consulted in the [requirements section](../../getting-started/requirements.md#checks-that-require-prowlerrole).
|
||||
The checks requiring this `ProwlerRole` can be found in the [requirements section](../../getting-started/requirements.md#checks-that-require-prowlerrole).
|
||||
|
||||
#### Create ProwlerRole from Azure Portal
|
||||
#### Create ProwlerRole via Azure Portal
|
||||
|
||||
1. Download the [prowler-azure-custom-role](https://github.com/prowler-cloud/prowler/blob/master/permissions/prowler-azure-custom-role.json) file and modify the `assignableScopes` field to be the subscription ID where the role assignment is going to be made, it should be shomething like `/subscriptions/XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX`.
|
||||
2. Access your subscription.
|
||||
3. Select "Access control (IAM)".
|
||||
4. Click on "+ Add" and select "Add custom role".
|
||||
5. In the "Baseline permissions" select "Start from JSON" and upload the file downloaded and modified in the step 1.
|
||||
7. Click on "Review + create" to create the new role.
|
||||
1. Download the [prowler-azure-custom-role](https://github.com/prowler-cloud/prowler/blob/master/permissions/prowler-azure-custom-role.json) file and modify the `assignableScopes` field to match the target subscription. Example format: `/subscriptions/XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX`.
|
||||
|
||||
#### Create ProwlerRole from Azure CLI
|
||||
2. Access your Azure subscription.
|
||||
|
||||
1. Open a terminal and execute the following command to create a new custom role:
|
||||
```console
|
||||
az role definition create --role-definition '{ 640ms lun 16 dic 17:04:17 2024
|
||||
"Name": "ProwlerRole",
|
||||
"IsCustom": true,
|
||||
"Description": "Role used for checks that require read-only access to Azure resources and are not covered by the Reader role.",
|
||||
"AssignableScopes": [
|
||||
"/subscriptions/XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX" // USE YOUR SUBSCRIPTION ID
|
||||
],
|
||||
"Actions": [
|
||||
"Microsoft.Web/sites/host/listkeys/action",
|
||||
"Microsoft.Web/sites/config/list/Action"
|
||||
]
|
||||
}'
|
||||
```
|
||||
3. If the command is executed successfully, the output is going to be similar to the following:
|
||||
```json
|
||||
{
|
||||
"assignableScopes": [
|
||||
"/subscriptions/XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX"
|
||||
],
|
||||
"createdBy": null,
|
||||
"createdOn": "YYYY-MM-DDTHH:MM:SS.SSSSSS+00:00",
|
||||
"description": "Role used for checks that require read-only access to Azure resources and are not covered by the Reader role.",
|
||||
"id": "/subscriptions/XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX/providers/Microsoft.Authorization/roleDefinitions/XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX",
|
||||
"name": "XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX",
|
||||
"permissions": [
|
||||
{
|
||||
"actions": [
|
||||
"Microsoft.Web/sites/host/listkeys/action",
|
||||
"Microsoft.Web/sites/config/list/Action"
|
||||
],
|
||||
"condition": null,
|
||||
"conditionVersion": null,
|
||||
"dataActions": [],
|
||||
"notActions": [],
|
||||
"notDataActions": []
|
||||
}
|
||||
],
|
||||
"roleName": "ProwlerRole",
|
||||
"roleType": "CustomRole",
|
||||
"type": "Microsoft.Authorization/roleDefinitions",
|
||||
"updatedBy": "XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX",
|
||||
"updatedOn": "YYYY-MM-DDTHH:MM:SS.SSSSSS+00:00"
|
||||
}
|
||||
```
|
||||
3. Select “Access control (IAM)”.
|
||||
|
||||
## Recommendation for multiple subscriptions
|
||||
4. Click “+ Add” and select “Add custom role”.
|
||||
|
||||
Scanning multiple subscriptions can be tedious due to the need to create and assign roles for each one. To simplify this process, we recommend using management groups to organize and audit subscriptions collectively with Prowler.
|
||||
5. Under “Baseline permissions”, select “Start from JSON” and upload the modified role file.
|
||||
|
||||
6. Click “Review + create” to finalize the role creation.
|
||||
|
||||
#### Create ProwlerRole via Azure CLI
|
||||
|
||||
1. To create a new custom role, open a terminal and execute the following command:
|
||||
|
||||
```console
|
||||
az role definition create --role-definition '{ 640ms lun 16 dic 17:04:17 2024
|
||||
"Name": "ProwlerRole",
|
||||
"IsCustom": true,
|
||||
"Description": "Role used for checks that require read-only access to Azure resources and are not covered by the Reader role.",
|
||||
"AssignableScopes": [
|
||||
"/subscriptions/XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX" // USE YOUR SUBSCRIPTION ID
|
||||
],
|
||||
"Actions": [
|
||||
"Microsoft.Web/sites/host/listkeys/action",
|
||||
"Microsoft.Web/sites/config/list/Action"
|
||||
]
|
||||
}'
|
||||
```
|
||||
|
||||
2. If the command is executed successfully, the output is going to be similar to the following:
|
||||
|
||||
```json
|
||||
{
|
||||
"assignableScopes": [
|
||||
"/subscriptions/XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX"
|
||||
],
|
||||
"createdBy": null,
|
||||
"createdOn": "YYYY-MM-DDTHH:MM:SS.SSSSSS+00:00",
|
||||
"description": "Role used for checks that require read-only access to Azure resources and are not covered by the Reader role.",
|
||||
"id": "/subscriptions/XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX/providers/Microsoft.Authorization/roleDefinitions/XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX",
|
||||
"name": "XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX",
|
||||
"permissions": [
|
||||
{
|
||||
"actions": [
|
||||
"Microsoft.Web/sites/host/listkeys/action",
|
||||
"Microsoft.Web/sites/config/list/Action"
|
||||
],
|
||||
"condition": null,
|
||||
"conditionVersion": null,
|
||||
"dataActions": [],
|
||||
"notActions": [],
|
||||
"notDataActions": []
|
||||
}
|
||||
],
|
||||
"roleName": "ProwlerRole",
|
||||
"roleType": "CustomRole",
|
||||
"type": "Microsoft.Authorization/roleDefinitions",
|
||||
"updatedBy": "XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX",
|
||||
"updatedOn": "YYYY-MM-DDTHH:MM:SS.SSSSSS+00:00"
|
||||
}
|
||||
```
|
||||
|
||||
## Recommendation for Managing Multiple Subscriptions
|
||||
|
||||
Scanning multiple subscriptions requires creating and assigning roles for each, which can be a time-consuming process. To streamline subscription management and auditing, use management groups in Azure. This approach allows Prowler to efficiently organize and audit multiple subscriptions collectively.
|
||||
|
||||
1. **Create a Management Group**: Follow the [official guide](https://learn.microsoft.com/en-us/azure/governance/management-groups/create-management-group-portal) to create a new management group.
|
||||

|
||||
2. **Add all roles**: Assign roles at to the new management group like in the [past section](#assign-the-appropriate-permissions-to-the-identity-that-is-going-to-be-assumed-by-prowler) but at the management group level instead of the subscription level.
|
||||
3. **Add subscriptions**: Add all the subscriptions you want to audit to the management group.
|
||||

|
||||
|
||||

|
||||
|
||||
2. **Assign Roles**: Assign necessary roles to the management group, similar to the [role assignment process](#assign-the-appropriate-permissions-to-the-identity-that-is-going-to-be-assumed-by-prowler).
|
||||
|
||||
Role assignment should be done at the management group level instead of per subscription.
|
||||
|
||||
3. **Add Subscriptions**: Add all subscriptions you want to audit to the newly created management group. 
|
||||
|
||||
@@ -1,14 +1,14 @@
|
||||
# Use non default Azure regions
|
||||
# Using Non-Default Azure Regions
|
||||
|
||||
Microsoft provides clouds for compliance with regional laws, which are available for your use.
|
||||
By default, Prowler uses `AzureCloud` cloud which is the comercial one. (you can list all the available with `az cloud list --output table`).
|
||||
Microsoft offers cloud environments that comply with regional regulations. These clouds are available for use based on your requirements. By default, Prowler utilizes the commercial `AzureCloud` environment. (To list all available Azure clouds, use `az cloud list --output table`).
|
||||
|
||||
As of this documentation's publication, the following Azure clouds are available:
|
||||
|
||||
At the time of writing this documentation the available Azure Clouds from different regions are the following:
|
||||
- AzureCloud
|
||||
- AzureChinaCloud
|
||||
- AzureUSGovernment
|
||||
|
||||
If you want to change the default one you must include the flag `--azure-region`, i.e.:
|
||||
To change the default cloud, include the flag `--azure-region`. For example:
|
||||
|
||||
```console
|
||||
prowler azure --az-cli-auth --azure-region AzureChinaCloud
|
||||
|
||||
@@ -1,6 +1,7 @@
|
||||
# Check Aliases
|
||||
|
||||
Prowler allows you to use aliases for the checks. You only have to add the `CheckAliases` key to the check's metadata with a list of the aliases:
|
||||
|
||||
```json title="check.metadata.json"
|
||||
"Provider": "<provider>",
|
||||
"CheckID": "<check_id>",
|
||||
@@ -12,7 +13,9 @@ Prowler allows you to use aliases for the checks. You only have to add the `Chec
|
||||
],
|
||||
...
|
||||
```
|
||||
Then, you can execute the check either with its check ID or with one of the previous aliases:
|
||||
|
||||
Then you can execute the check either with its check ID or with one of the previous aliases:
|
||||
|
||||
```shell
|
||||
prowler <provider> -c/--checks <check_alias_1>
|
||||
|
||||
|
||||
@@ -1,37 +1,126 @@
|
||||
# Compliance
|
||||
|
||||
Prowler allows you to execute checks based on requirements defined in compliance frameworks. By default, it will execute and give you an overview of the status of each compliance framework:
|
||||
|
||||
<img src="../img/compliance/compliance.png"/>
|
||||
|
||||
> You can find CSVs containing detailed compliance results inside the compliance folder within Prowler's output folder.
|
||||
You can find CSVs containing detailed compliance results in the compliance folder within Prowler's output folder.
|
||||
|
||||
## Execute Prowler based on Compliance Frameworks
|
||||
|
||||
Prowler can analyze your environment based on a specific compliance framework and get more details, to do it, you can use option `--compliance`:
|
||||
|
||||
```sh
|
||||
prowler <provider> --compliance <compliance_framework>
|
||||
```
|
||||
|
||||
Standard results will be shown and additionally the framework information as the sample below for CIS AWS 2.0. For details a CSV file has been generated as well.
|
||||
|
||||
<img src="../img/compliance/compliance-cis-sample1.png"/>
|
||||
|
||||
???+ note
|
||||
**If Prowler can't find a resource related with a check from a compliance requirement, this requirement won't appear on the output**
|
||||
**If Prowler can't find a resource related with a check from a compliance requirement, this requirement won't appear on the output**
|
||||
|
||||
## List Available Compliance Frameworks
|
||||
In order to see which compliance frameworks are cover by Prowler, you can use option `--list-compliance`:
|
||||
|
||||
In order to see which compliance frameworks are covered by Prowler, you can use option `--list-compliance`:
|
||||
|
||||
```sh
|
||||
prowler <provider> --list-compliance
|
||||
```
|
||||
|
||||
The full and updated list of supported compliance frameworks for each provider is available at [Prowler Hub](https://hub.prowler.com/compliance).
|
||||
### AWS (36 frameworks)
|
||||
|
||||
- `aws_account_security_onboarding_aws`
|
||||
- `aws_audit_manager_control_tower_guardrails_aws`
|
||||
- `aws_foundational_security_best_practices_aws`
|
||||
- `aws_foundational_technical_review_aws`
|
||||
- `aws_well_architected_framework_reliability_pillar_aws`
|
||||
- `aws_well_architected_framework_security_pillar_aws`
|
||||
- `cis_1.4_aws`
|
||||
- `cis_1.5_aws`
|
||||
- `cis_2.0_aws`
|
||||
- `cis_3.0_aws`
|
||||
- `cis_4.0_aws`
|
||||
- `cis_5.0_aws`
|
||||
- `cisa_aws`
|
||||
- `ens_rd2022_aws`
|
||||
- `fedramp_low_revision_4_aws`
|
||||
- `fedramp_moderate_revision_4_aws`
|
||||
- `ffiec_aws`
|
||||
- `gdpr_aws`
|
||||
- `gxp_21_cfr_part_11_aws`
|
||||
- `gxp_eu_annex_11_aws`
|
||||
- `hipaa_aws`
|
||||
- `iso27001_2013_aws`
|
||||
- `iso27001_2022_aws`
|
||||
- `kisa_isms_p_2023_aws`
|
||||
- `kisa_isms_p_2023_korean_aws`
|
||||
- `mitre_attack_aws`
|
||||
- `nis2_aws`
|
||||
- `nist_800_171_revision_2_aws`
|
||||
- `nist_800_53_revision_4_aws`
|
||||
- `nist_800_53_revision_5_aws`
|
||||
- `nist_csf_1.1_aws`
|
||||
- `pci_3.2.1_aws`
|
||||
- `pci_4.0_aws`
|
||||
- `prowler_threatscore_aws`
|
||||
- `rbi_cyber_security_framework_aws`
|
||||
- `soc2_aws`
|
||||
|
||||
### Azure (10 frameworks)
|
||||
|
||||
- `cis_2.0_azure`
|
||||
- `cis_2.1_azure`
|
||||
- `cis_3.0_azure`
|
||||
- `ens_rd2022_azure`
|
||||
- `iso27001_2022_azure`
|
||||
- `mitre_attack_azure`
|
||||
- `nis2_azure`
|
||||
- `pci_4.0_azure`
|
||||
- `prowler_threatscore_azure`
|
||||
- `soc2_azure`
|
||||
|
||||
### GCP (10 frameworks)
|
||||
|
||||
- `cis_2.0_gcp`
|
||||
- `cis_3.0_gcp`
|
||||
- `cis_4.0_gcp`
|
||||
- `ens_rd2022_gcp`
|
||||
- `iso27001_2022_gcp`
|
||||
- `mitre_attack_gcp`
|
||||
- `nis2_gcp`
|
||||
- `pci_4.0_gcp`
|
||||
- `prowler_threatscore_gcp`
|
||||
- `soc2_gcp`
|
||||
|
||||
### Kubernetes (5 frameworks)
|
||||
|
||||
- `cis_1.10_kubernetes`
|
||||
- `cis_1.11_kubernetes`
|
||||
- `cis_1.8_kubernetes`
|
||||
- `iso27001_2022_kubernetes`
|
||||
- `pci_4.0_kubernetes`
|
||||
|
||||
### M365 (3 frameworks)
|
||||
|
||||
- `cis_4.0_m365`
|
||||
- `iso27001_2022_m365`
|
||||
- `prowler_threatscore_m365`
|
||||
|
||||
### GitHub (1 framework)
|
||||
|
||||
- `cis_1.0_github`
|
||||
|
||||
## List Requirements of Compliance Frameworks
|
||||
For each compliance framework, you can use option `--list-compliance-requirements` to list its requirements:
|
||||
For each compliance framework, you can use the `--list-compliance-requirements` option to list its requirements:
|
||||
|
||||
```sh
|
||||
prowler <provider> --list-compliance-requirements <compliance_framework(s)>
|
||||
```
|
||||
|
||||
Example for the first requirements of CIS 1.5 for AWS:
|
||||
|
||||
```
|
||||
Listing CIS 1.5 AWS Compliance Requirements:
|
||||
|
||||
@@ -66,4 +155,4 @@ Requirement Id: 1.5
|
||||
|
||||
## Create and contribute adding other Security Frameworks
|
||||
|
||||
This information is part of the Developer Guide and can be found here: https://docs.prowler.cloud/en/latest/tutorials/developer-guide/.
|
||||
This information is part of the Developer Guide and can be found [here](../developer-guide/security-compliance-framework.md).
|
||||
|
||||
@@ -1,10 +1,12 @@
|
||||
# Configuration File
|
||||
|
||||
Several Prowler's checks have user configurable variables that can be modified in a common **configuration file**. This file can be found in the following [path](https://github.com/prowler-cloud/prowler/blob/master/prowler/config/config.yaml):
|
||||
|
||||
```
|
||||
prowler/config/config.yaml
|
||||
```
|
||||
|
||||
Also you can input a custom configuration file using the `--config-file` argument.
|
||||
Additionally, you can input a custom configuration file using the `--config-file` argument.
|
||||
|
||||
## AWS
|
||||
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
# Custom Checks Metadata
|
||||
|
||||
In certain organizations, the severity of specific checks might differ from the default values defined in the check's metadata. For instance, while `s3_bucket_level_public_access_block` could be deemed `critical` for some organizations, others might assign a different severity level.
|
||||
In certain organizations, the severity of specific checks might differ from the default values defined in the check's metadata. For instance, while `s3_bucket_level_public_access_block` could be deemed `critical` for some organizations, others might assign a different severity level to it.
|
||||
|
||||
The custom metadata option offers a means to override default metadata set by Prowler
|
||||
|
||||
@@ -15,18 +15,20 @@ The list of supported check's metadata fields that can be override are listed as
|
||||
- Risk
|
||||
- RelatedUrl
|
||||
- Remediation
|
||||
- Code
|
||||
- CLI
|
||||
- NativeIaC
|
||||
- Other
|
||||
- Terraform
|
||||
- Recommendation
|
||||
- Text
|
||||
- Url
|
||||
- Code
|
||||
- CLI
|
||||
- NativeIaC
|
||||
- Other
|
||||
- Terraform
|
||||
- Recommendation
|
||||
- Text
|
||||
- Url
|
||||
|
||||
|
||||
## File Syntax
|
||||
|
||||
This feature is available for all the providers supported in Prowler since the metadata format is common between all the providers. The following is the YAML format for the custom checks metadata file:
|
||||
This feature is available for all the providers supported in Prowler since the metadata format is common between all the providers. The YAML format for the custom checks metadata file is as follows:
|
||||
|
||||
```yaml title="custom_checks_metadata.yaml"
|
||||
CustomChecksMetadata:
|
||||
aws:
|
||||
@@ -117,6 +119,7 @@ CustomChecksMetadata:
|
||||
## Usage
|
||||
|
||||
Executing the following command will assess all checks and generate a report while overriding the metadata for those checks:
|
||||
|
||||
```sh
|
||||
prowler <provider> --custom-checks-metadata-file <path/to/custom/metadata>
|
||||
```
|
||||
|
||||
@@ -1,9 +1,11 @@
|
||||
# Dashboard
|
||||
|
||||
Prowler allows you to run your own local dashboards using the csv outputs provided by Prowler
|
||||
|
||||
```sh
|
||||
prowler dashboard
|
||||
```
|
||||
|
||||
???+ note
|
||||
You can expose the `dashboard` server in another address using the `HOST` environment variable.
|
||||
|
||||
@@ -16,10 +18,9 @@ docker run -v /your/local/dir/prowler-output:/home/prowler/output --env HOST=0.0
|
||||
Make sure you update the `/your/local/dir/prowler-output` to match the path that contains your prowler output.
|
||||
|
||||
???+ note
|
||||
**Remember that the `dashboard` server is not authenticated, if you expose it to the internet, you are running it at your own risk.**
|
||||
**Remember that the `dashboard` server is not authenticated. If you expose it to the Internet, do it at your own risk.**
|
||||
|
||||
The banner and additional info about the dashboard will be shown on your console:
|
||||
<img src="../img/dashboard/dashboard-banner.png">
|
||||
The banner and additional info about the dashboard will be shown on your console: <img src="../img/dashboard/dashboard-banner.png">
|
||||
|
||||
## Overview Page
|
||||
|
||||
@@ -27,32 +28,39 @@ The overview page provides a full impression of your findings obtained from Prow
|
||||
|
||||
<img src="../img/dashboard/dashboard-overview.png">
|
||||
|
||||
In this page you can do multiple functions:
|
||||
This page allows for multiple functions:
|
||||
|
||||
* Apply filters:
|
||||
|
||||
* Assesment Date
|
||||
* Account
|
||||
* Region
|
||||
* Severity
|
||||
* Service
|
||||
* Status
|
||||
* See which files has been scanned to generate the dashboard placing your mouse on the `?` icon:
|
||||
<img src="../img/dashboard/dashboard-files-scanned.png">
|
||||
* Download the `Top Findings by Severity` table using the button `DOWNLOAD THIS TABLE AS CSV` or `DOWNLOAD THIS TABLE AS XLSX`
|
||||
* Click on the provider cards to filter by provider.
|
||||
* On the dropdowns under `Top Findings by Severity` you can apply multiple sorts to see the information, also you will get a detailed view of each finding using the dropdowns:
|
||||
<img src="../img/dashboard/dropdown.png">
|
||||
|
||||
* See which files has been scanned to generate the dashboard by placing your mouse on the `?` icon:
|
||||
|
||||
<img src="../img/dashboard/dashboard-files-scanned.png">
|
||||
|
||||
* Download the `Top Findings by Severity` table using the button `DOWNLOAD THIS TABLE AS CSV` or `DOWNLOAD THIS TABLE AS XLSX`
|
||||
|
||||
* Click the provider cards to filter by provider.
|
||||
|
||||
* On the dropdowns under `Top Findings by Severity` you can apply multiple sorts to see the information, also you will get a detailed view of each finding using the dropdowns:
|
||||
|
||||
<img src="../img/dashboard/dropdown.png">
|
||||
|
||||
## Compliance Page
|
||||
|
||||
This page shows all the info related to the compliance selected, you can apply multiple filters depending on your preferences.
|
||||
This page shows all the info related to the compliance selected. Multiple filters can be selected as per your preferences.
|
||||
|
||||
<img src="../img/dashboard/dashboard-compliance.png">
|
||||
|
||||
To add your own compliance to compliance page, add a file with the compliance name (using `_` instead of `.`) to the path `/dashboard/compliance`.
|
||||
|
||||
In this file use the format present in the others compliance files to create the table. Example for CIS 2.0:
|
||||
|
||||
```python
|
||||
import warnings
|
||||
|
||||
@@ -83,29 +91,31 @@ def get_table(data):
|
||||
|
||||
## S3 Integration
|
||||
|
||||
If you are using Prowler SaaS with the S3 integration or that integration from Prowler Open Source and you want to use your data from your S3 bucket, you can run:
|
||||
If you are using Prowler SaaS with the S3 integration or that integration from Prowler Open Source and you want to use your data from your S3 bucket, you can run the following command in order to load the dashboard with the new files:
|
||||
|
||||
```sh
|
||||
aws s3 cp s3://<your-bucket>/output/csv ./output --recursive
|
||||
```
|
||||
to load the dashboard with the new files.
|
||||
|
||||
## Output Path
|
||||
|
||||
Prowler will use the outputs from the folder `/output` (for common prowler outputs) and `/output/compliance` (for prowler compliance outputs) to generate the dashboard.
|
||||
|
||||
To change the path modify the values `folder_path_overview` or `folder_path_compliance` from `/dashboard/config.py`
|
||||
To change the path, modify the values `folder_path_overview` or `folder_path_compliance` from `/dashboard/config.py`
|
||||
|
||||
???+ note
|
||||
If you have any issue related with dashboards, check that the output path where the dashboard is getting the outputs is correct.
|
||||
|
||||
|
||||
## Output Support
|
||||
|
||||
Prowler dashboard supports the detailed outputs:
|
||||
|
||||
| Provider | V3 | V4 | COMPLIANCE-V3 | COMPLIANCE-V4|
|
||||
|---|---|---|---|---|
|
||||
| AWS | ✅ | ✅ | ✅ | ✅ |
|
||||
| Azure | ❌ | ✅ | ❌ | ✅ |
|
||||
| Kubernetes | ❌ | ✅ | ❌ | ✅ |
|
||||
| GCP | ❌ | ✅ | ❌ | ✅ |
|
||||
| Provider| V3| V4| COMPLIANCE-V3| COMPLIANCE-V4
|
||||
|----------|----------|----------|----------|----------
|
||||
| AWS| ✅| ✅| ✅| ✅
|
||||
| Azure| ❌| ✅| ❌| ✅
|
||||
| Kubernetes| ❌| ✅| ❌| ✅
|
||||
| GCP| ❌| ✅| ❌| ✅
|
||||
| M365| ❌| ✅| ❌| ✅
|
||||
| GitHub| ❌| ✅| ❌| ✅
|
||||
|
||||
@@ -1,4 +1,5 @@
|
||||
# Prowler Fixer (remediation)
|
||||
|
||||
Prowler allows you to fix some of the failed findings it identifies. You can use the `--fixer` flag to run the fixes that are available for the checks that failed.
|
||||
|
||||
```sh
|
||||
@@ -8,16 +9,20 @@ prowler <provider> -c <check_to_fix_1> <check_to_fix_2> ... --fixer
|
||||
<img src="../img/fixer.png">
|
||||
|
||||
???+ note
|
||||
You can see all the available fixes for each provider with the `--list-remediations` or `--list-fixers flag.
|
||||
You can see all the available fixes for each provider with the `--list-remediations` or `--list-fixers` flag.
|
||||
|
||||
```sh
|
||||
prowler <provider> --list-fixers
|
||||
```
|
||||
|
||||
It's important to note that using the fixers for `Access Analyzer`, `GuardDuty`, and `SecurityHub` may incur additional costs. These AWS services might trigger actions or deploy resources that can lead to charges on your AWS account.
|
||||
|
||||
## Writing a Fixer
|
||||
|
||||
To write a fixer, you need to create a file called `<check_id>_fixer.py` inside the check folder, with a function called `fixer` that receives either the region or the resource to be fixed as a parameter, and returns a boolean value indicating if the fix was successful or not.
|
||||
|
||||
For example, the regional fixer for the `ec2_ebs_default_encryption` check, which enables EBS encryption by default in a region, would look like this:
|
||||
|
||||
```python
|
||||
from prowler.lib.logger import logger
|
||||
from prowler.providers.aws.services.ec2.ec2_client import ec2_client
|
||||
@@ -25,8 +30,8 @@ from prowler.providers.aws.services.ec2.ec2_client import ec2_client
|
||||
|
||||
def fixer(region):
|
||||
"""
|
||||
Enable EBS encryption by default in a region. NOTE: Custom KMS keys for EBS Default Encryption may be overwritten.
|
||||
Requires the ec2:EnableEbsEncryptionByDefault permission:
|
||||
Enable EBS encryption by default in a region. ???+ note Custom KMS keys for EBS Default Encryption may be overwritten. Requires the ec2:EnableEbsEncryptionByDefault permission.
|
||||
It can be set as follows:
|
||||
{
|
||||
"Version": "2012-10-17",
|
||||
"Statement": [
|
||||
@@ -53,7 +58,9 @@ def fixer(region):
|
||||
)
|
||||
return False
|
||||
```
|
||||
|
||||
On the other hand, the fixer for the `s3_account_level_public_access_blocks` check, which enables the account-level public access blocks for S3, would look like this:
|
||||
|
||||
```python
|
||||
from prowler.lib.logger import logger
|
||||
from prowler.providers.aws.services.s3.s3control_client import s3control_client
|
||||
@@ -61,7 +68,7 @@ from prowler.providers.aws.services.s3.s3control_client import s3control_client
|
||||
|
||||
def fixer(resource_id: str) -> bool:
|
||||
"""
|
||||
Enable S3 Block Public Access for the account. NOTE: By blocking all S3 public access you may break public S3 buckets.
|
||||
Enable S3 Block Public Access for the account. ???+ note Custom KMS keys for EBS Default Encryption may be overwritten. By blocking all S3 public access you may break public S3 buckets.
|
||||
Requires the s3:PutAccountPublicAccessBlock permission:
|
||||
{
|
||||
"Version": "2012-10-17",
|
||||
@@ -96,7 +103,9 @@ def fixer(resource_id: str) -> bool:
|
||||
```
|
||||
|
||||
## Fixer Config file
|
||||
|
||||
For some fixers, you can have configurable parameters depending on your use case. You can either use the default config file in `prowler/config/fixer_config.yaml` or create a custom config file and pass it to the fixer with the `--fixer-config` flag. The config file should be a YAML file with the following structure:
|
||||
|
||||
```yaml
|
||||
# Fixer configuration file
|
||||
aws:
|
||||
|
||||
@@ -1,18 +1,17 @@
|
||||
# GCP authentication
|
||||
# GCP Authentication in Prowler
|
||||
|
||||
Prowler will use by default your User Account credentials, you can configure it using:
|
||||
## Default Authentication
|
||||
|
||||
- `gcloud init` to use a new account
|
||||
- `gcloud config set account <account>` to use an existing account
|
||||
- `gcloud auth application-default login`
|
||||
By default, Prowler uses your User Account credentials. You can configure authentication as follows:
|
||||
|
||||
This will generate Application Default Credentials (ADC) that Prowler will use automatically.
|
||||
- `gcloud init` to use a new account, or
|
||||
- `gcloud config set account <account>` to use an existing account.
|
||||
|
||||
---
|
||||
Then, obtain your access credentials using: `gcloud auth application-default login`.
|
||||
|
||||
## Using a Service Account key file
|
||||
## Using Service Account Keys
|
||||
|
||||
Otherwise, you can generate and download Service Account keys in JSON format (refer to https://cloud.google.com/iam/docs/creating-managing-service-account-keys) and provide the location of the file with the following argument:
|
||||
Alternatively, Service Account keys can be generated and downloaded in JSON format. Follow the steps in the Google Cloud IAM guide (https://cloud.google.com/iam/docs/creating-managing-service-account-keys) to create and manage service account keys. Provide the path to the key file using:
|
||||
|
||||
```console
|
||||
prowler gcp --credentials-file path
|
||||
@@ -21,8 +20,6 @@ prowler gcp --credentials-file path
|
||||
???+ note
|
||||
`prowler` will scan the GCP project associated with the credentials.
|
||||
|
||||
---
|
||||
|
||||
## Using an access token
|
||||
|
||||
If you already have an access token (e.g., generated with `gcloud auth print-access-token`), you can run Prowler with:
|
||||
@@ -38,11 +35,9 @@ prowler gcp --project-ids <project-id>
|
||||
export GOOGLE_CLOUD_PROJECT=<project-id>
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Credentials lookup order
|
||||
|
||||
Prowler follows the same search order as [Google authentication libraries](https://cloud.google.com/docs/authentication/application-default-credentials#search_order):
|
||||
Prowler follows the same credential search process as [Google authentication libraries](https://cloud.google.com/docs/authentication/application-default-credentials#search_order), checking credentials in this order:
|
||||
|
||||
1. [`GOOGLE_APPLICATION_CREDENTIALS` environment variable](https://cloud.google.com/docs/authentication/application-default-credentials#GAC)
|
||||
2. [`CLOUDSDK_AUTH_ACCESS_TOKEN` + optional `GOOGLE_CLOUD_PROJECT`](https://cloud.google.com/sdk/gcloud/reference/auth/print-access-token)
|
||||
@@ -56,12 +51,10 @@ Prowler follows the same search order as [Google authentication libraries](https
|
||||
???+ note
|
||||
Prowler will use the enabled Google Cloud APIs to get the information needed to perform the checks.
|
||||
|
||||
---
|
||||
|
||||
## Required Permissions
|
||||
|
||||
## Needed permissions
|
||||
|
||||
Prowler for Google Cloud needs the following permissions to be set:
|
||||
To ensure full functionality, Prowler for Google Cloud needs the following permissions to be set:
|
||||
|
||||
- **Reader (`roles/reader`) IAM role**: granted at the project / folder / org level in order to scan the target projects
|
||||
|
||||
@@ -78,12 +71,12 @@ The above settings must be associated to a user or service account.
|
||||
???+ note
|
||||
Prowler will use the enabled Google Cloud APIs to get the information needed to perform the checks.
|
||||
|
||||
## Impersonate Service Account
|
||||
## Impersonating a GCP Service Account in Prowler
|
||||
|
||||
If you want to impersonate a GCP service account, you can use the `--impersonate-service-account` argument:
|
||||
To impersonate a GCP service account, use the `--impersonate-service-account` argument followed by the service account email:
|
||||
|
||||
```console
|
||||
prowler gcp --impersonate-service-account <service-account-email>
|
||||
```
|
||||
|
||||
This argument will use the default credentials to impersonate the service account provided.
|
||||
This command leverages the default credentials to impersonate the specified service account.
|
||||
|
||||
@@ -1,21 +1,22 @@
|
||||
# GCP Organization
|
||||
# Scanning a Specific GCP Organization
|
||||
|
||||
By default, Prowler scans all Google Cloud projects accessible to the authenticated user.
|
||||
|
||||
To limit the scan to projects within a specific Google Cloud organization, use the `--organization-id` option with the GCP organization ID:
|
||||
To limit the scan to projects within a specific Google Cloud organization, use the `--organization-id` option with the GCP organization’s ID:
|
||||
|
||||
```console
|
||||
prowler gcp --organization-id organization-id
|
||||
```
|
||||
|
||||
???+ warning
|
||||
Make sure that the used credentials have a role with the `cloudasset.assets.listResource` permission on the organization level like `roles/cloudasset.viewer` (Cloud Asset Viewer) or `roles/cloudasset.owner` (Cloud Asset Owner).
|
||||
Ensure the credentials used have one of the following roles at the organization level:
|
||||
Cloud Asset Viewer (`roles/cloudasset.viewer`), or Cloud Asset Owner (`roles/cloudasset.owner`).
|
||||
|
||||
???+ note
|
||||
With this option, Prowler retrieves all projects within the specified organization, including those organized in folders and nested subfolders. This ensures that every project under the organization’s hierarchy is scanned, providing full visibility across the entire organization.
|
||||
With this option, Prowler retrieves all projects under the specified Google Cloud organization, including those organized within folders and nested subfolders. This ensures full visibility across the entire organization’s hierarchy.
|
||||
|
||||
???+ note
|
||||
To find the organization ID, use the following command:
|
||||
To obtain the Google Cloud organization ID, use:
|
||||
|
||||
```console
|
||||
gcloud organizations list
|
||||
|
||||
@@ -1,28 +1,37 @@
|
||||
# GCP Projects
|
||||
# GCP Project Scanning in Prowler
|
||||
|
||||
By default, Prowler is multi-project, which means that is going to scan all the Google Cloud projects that the authenticated user has access to. If you want to scan a specific project(s), you can use the `--project-ids` argument.
|
||||
By default, Prowler operates in a multi-project mode, scanning all Google Cloud projects accessible to the authenticated user.
|
||||
|
||||
## Specifying Projects
|
||||
|
||||
To limit the scan to specific projects, use the `--project-ids` argument followed by the desired project ID(s).
|
||||
|
||||
```console
|
||||
prowler gcp --project-ids project-id1 project-id2
|
||||
```
|
||||
|
||||
???+ note
|
||||
You can use asterisk `*` to scan projects that match a pattern. For example, `prowler gcp --project-ids "prowler*"` will scan all the projects that start with `prowler`.
|
||||
### Pattern-Based Project Selection
|
||||
|
||||
???+ note
|
||||
If you want to know the projects that you have access to, you can use the following command:
|
||||
Use an asterisk `*` to scan projects that match a pattern. For example, `prowler gcp --project-ids "prowler*"` will scan all the projects that start with `prowler`.
|
||||
|
||||
```console
|
||||
prowler gcp --list-project-ids
|
||||
```
|
||||
### Listing Accessible Projects
|
||||
|
||||
### Exclude Projects
|
||||
To view a list of projects the user has access to, run:
|
||||
|
||||
If you want to exclude some projects from the scan, you can use the `--excluded-project-ids` argument.
|
||||
```console
|
||||
prowler gcp --list-project-ids
|
||||
```
|
||||
|
||||
### Excluding Projects in Prowler
|
||||
|
||||
#### Project Exclusion
|
||||
|
||||
To exclude specific Google Cloud projects from the scan, use the `--excluded-project-ids` argument followed by the project ID(s):
|
||||
|
||||
```console
|
||||
prowler gcp --excluded-project-ids project-id1 project-id2
|
||||
```
|
||||
|
||||
???+ note
|
||||
You can use asterisk `*` to exclude projects that match a pattern. For example, `prowler gcp --excluded-project-ids "sys*"` will exclude all the projects that start with `sys`.
|
||||
#### Pattern-Based Project Exclusion
|
||||
|
||||
Use an asterisk `*` to exclude projects that match a pattern. For example, `prowler gcp --excluded-project-ids "sys*"` will exclude all the projects that start with `sys`.
|
||||
|
||||
@@ -13,6 +13,7 @@ This flexibility allows you to scan and analyze your GitHub account, including r
|
||||
Here are the available login methods and their respective flags:
|
||||
|
||||
### Personal Access Token (PAT)
|
||||
|
||||
Use this method by providing your personal access token directly.
|
||||
|
||||
```console
|
||||
@@ -20,6 +21,7 @@ prowler github --personal-access-token pat
|
||||
```
|
||||
|
||||
### OAuth App Token
|
||||
|
||||
Authenticate using an OAuth app token.
|
||||
|
||||
```console
|
||||
@@ -34,6 +36,7 @@ prowler github --github-app-id app_id --github-app-key-path app_key_path
|
||||
```
|
||||
|
||||
### Automatic Login Method Detection
|
||||
|
||||
If no login method is explicitly provided, Prowler will automatically attempt to authenticate using environment variables in the following order of precedence:
|
||||
|
||||
1. `GITHUB_PERSONAL_ACCESS_TOKEN`
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
# Integrations
|
||||
|
||||
## Slack
|
||||
## Integration with Slack
|
||||
|
||||
Prowler can be integrated with [Slack](https://slack.com/) to send a summary of the execution having configured a Slack APP in your channel with the following command:
|
||||
|
||||
@@ -11,9 +11,9 @@ prowler <provider> --slack
|
||||

|
||||
|
||||
???+ note
|
||||
Slack integration needs SLACK_API_TOKEN and SLACK_CHANNEL_NAME environment variables.
|
||||
Slack integration needs `SLACK_API_TOKEN` and `SLACK_CHANNEL_NAME` environment variables.
|
||||
|
||||
### Configuration
|
||||
### Configuration of the Integration with Slack
|
||||
|
||||
To configure the Slack Integration, follow the next steps:
|
||||
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
# In-Cluster Execution
|
||||
|
||||
For in-cluster execution, you can use the supplied yaml files inside `/kubernetes`:
|
||||
For in-cluster execution, use the supplied yaml files inside `/kubernetes`:
|
||||
|
||||
* [prowler-sa.yaml](https://github.com/prowler-cloud/prowler/blob/master/kubernetes/prowler-sa.yaml)
|
||||
* [job.yaml](https://github.com/prowler-cloud/prowler/blob/master/kubernetes/job.yaml)
|
||||
|
||||
@@ -1,22 +1,22 @@
|
||||
# Miscellaneous
|
||||
|
||||
## Context Filtering
|
||||
## Context Filtering in Prowler
|
||||
|
||||
Prowler will scan the active Kubernetes context by default.
|
||||
|
||||
To specify the Kubernetes context to be scanned, use the `--context` flag followed by the desired context name. For example:
|
||||
To specify a different Kubernetes context for scanning, use the `--context` flag followed by the desired context name, for example:
|
||||
|
||||
```console
|
||||
prowler --context my-context
|
||||
```
|
||||
|
||||
This will ensure that Prowler scans the specified context/cluster for vulnerabilities and misconfigurations.
|
||||
This ensures that Prowler analyzes the selected context or cluster for vulnerabilities and misconfigurations.
|
||||
|
||||
## Namespace Filtering
|
||||
|
||||
By default, `prowler` will scan all namespaces in the context you specify.
|
||||
By default, `prowler` scans all namespaces within the specified context.
|
||||
|
||||
To specify the namespace(s) to be scanned, use the `--namespace` flag followed by the desired namespace(s) separated by spaces. For example:
|
||||
To limit the scan to specific namespaces, use the `--namespace` flag followed by the desired namespace names, separated by spaces: for example:
|
||||
|
||||
```console
|
||||
prowler --namespace namespace1 namespace2
|
||||
|
||||
@@ -1,10 +1,11 @@
|
||||
# Non in-cluster execution
|
||||
# Non In-Cluster Execution
|
||||
|
||||
For non in-cluster execution, you can provide the location of the [kubeconfig](https://kubernetes.io/docs/concepts/configuration/organize-cluster-access-kubeconfig/) file with the following argument:
|
||||
For execution outside the cluster environment, specify the location of the [kubeconfig](https://kubernetes.io/docs/concepts/configuration/organize-cluster-access-kubeconfig/) file using the following argument:
|
||||
|
||||
```console
|
||||
prowler kubernetes --kubeconfig-file /path/to/kubeconfig
|
||||
```
|
||||
|
||||
???+ note
|
||||
If no `--kubeconfig-file` is provided, Prowler will use the default KubeConfig file location (`~/.kube/config`).
|
||||
|
||||
|
||||
@@ -1,7 +1,6 @@
|
||||
# Microsoft 365 authentication
|
||||
# Microsoft 365 Authentication for Prowler
|
||||
|
||||
By default Prowler uses MsGraph Python SDK identity package authentication methods using the class `ClientSecretCredential`.
|
||||
This allows Prowler to authenticate against Microsoft 365 using the following methods:
|
||||
By default, Prowler utilizes the MsGraph Python SDK identity package for authentication, leveraging the class `ClientSecretCredential`. This enables authentication against Microsoft 365 using the following approaches:
|
||||
|
||||
- Service principal authentication by environment variables (Enterprise Application)
|
||||
- Service principal and Microsoft user credentials by environment variabled (using PowerShell requires this authentication method)
|
||||
@@ -25,4 +24,6 @@ prowler m365 --az-cli-auth
|
||||
prowler m365 --browser-auth --tenant-id "XXXXXXXX"
|
||||
```
|
||||
|
||||
To use Prowler you need to set up also the permissions required to access your resources in your Microsoft 365 account, to more details refer to [Requirements](../../getting-started/requirements.md#needed-permissions-2)
|
||||
## Permission Configuration
|
||||
|
||||
To ensure Prowler can access the required resources within your Microsoft 365 account, proper permissions must be configured. Refer to the [Requirements](../../getting-started/requirements.md#needed-permissions_2) section for details on setting up necessary privileges.
|
||||
|
||||
@@ -257,7 +257,7 @@ This method is not recommended because it requires a user with MFA enabled and M
|
||||
- `AZURE_CLIENT_SECRET` from earlier
|
||||
|
||||
If you are using user authentication, also add:
|
||||
- `M365_USER` the user using the correct assigned domain, more info [here](../../getting-started/requirements.md#service-principal-and-user-credentials-authentication-recommended)
|
||||
- `M365_USER` the user using the correct assigned domain, more info [here](../../getting-started/requirements.md#service-principal-and-user-credentials-authentication)
|
||||
- `M365_PASSWORD` the password of the user
|
||||
|
||||

|
||||
|
||||
@@ -1,50 +1,81 @@
|
||||
# Miscellaneous
|
||||
|
||||
## Prowler Version
|
||||
Show Prowler version:
|
||||
|
||||
### Showing the Prowler version:
|
||||
|
||||
```console
|
||||
prowler <provider> -V/-v/--version
|
||||
```
|
||||
## Verbose
|
||||
Execute Prowler in verbose mode (like in Version 2):
|
||||
|
||||
## Prowler Execution Options
|
||||
|
||||
Prowler provides various execution settings.
|
||||
|
||||
### Verbose Execution
|
||||
|
||||
To enable verbose mode in Prowler, similar to Version 2, use:
|
||||
|
||||
```console
|
||||
prowler <provider> --verbose
|
||||
```
|
||||
## Filter findings by status
|
||||
Prowler can filter the findings by their status, so you can see only in the CLI and in the reports the findings with a specific status:
|
||||
|
||||
### Filter findings by status
|
||||
|
||||
Prowler allows filtering findings based on their status, ensuring reports and CLI display only relevant findings:
|
||||
|
||||
```console
|
||||
prowler <provider> --status [PASS, FAIL, MANUAL]
|
||||
```
|
||||
## Disable Exit Code 3
|
||||
Prowler does not trigger exit code 3 with failed checks:
|
||||
|
||||
### Disable Exit Code 3
|
||||
|
||||
By default, Prowler triggers exit code 3 for failed checks. To disable this behavior:
|
||||
|
||||
```console
|
||||
prowler <provider> -z/--ignore-exit-code-3
|
||||
```
|
||||
## Hide Prowler Banner
|
||||
Prowler can run without showing its banner:
|
||||
|
||||
### Hide Prowler Banner
|
||||
|
||||
To run Prowler without displaying the banner:
|
||||
|
||||
```console
|
||||
prowler <provider> -b/--no-banner
|
||||
```
|
||||
## Disable Colors
|
||||
Prowler can run without showing colors:
|
||||
|
||||
### Disable Colors in Output
|
||||
|
||||
To run Prowler without color formatting:
|
||||
|
||||
```console
|
||||
prowler <provider> --no-color
|
||||
```
|
||||
## Checks
|
||||
Prowler has checks per provider, there are options related with them:
|
||||
|
||||
- List the available checks in the provider:
|
||||
### Checks in Prowler
|
||||
|
||||
Prowler provides various security checks per cloud provider. Use the following options to list, execute, or exclude specific checks:
|
||||
|
||||
- **List Available Checks**: To display all available checks for the chosen provider:
|
||||
|
||||
```console
|
||||
prowler <provider> --list-checks
|
||||
```
|
||||
- Execute specific check(s):
|
||||
|
||||
- **Execute Specific Checks**: Run one or more specific security checks using:
|
||||
|
||||
```console
|
||||
prowler <provider> -c/--checks s3_bucket_public_access iam_root_mfa_enabled
|
||||
prowler <provider> -c/--checks s3_bucket_public_access
|
||||
```
|
||||
- Exclude specific check(s):
|
||||
|
||||
- **Exclude Specific Checks**: Exclude checks from execution with:
|
||||
|
||||
```console
|
||||
prowler <provider> -e/--excluded-checks s3_bucket_public_access iam_root_mfa_enabled
|
||||
prowler <provider> -e/--excluded-checks ec2 rds
|
||||
```
|
||||
- Execute checks that appears in a json file:
|
||||
|
||||
- **Execute Checks from a JSON File**: To run checks defined in a JSON file, structure the file as follows:
|
||||
|
||||
```json
|
||||
<checks_list>.json
|
||||
|
||||
@@ -58,37 +89,42 @@ prowler <provider> -e/--excluded-checks s3_bucket_public_access iam_root_mfa_ena
|
||||
...
|
||||
}
|
||||
```
|
||||
|
||||
```console
|
||||
prowler <provider> -C/--checks-file <checks_list>.json
|
||||
```
|
||||
## Custom Checks
|
||||
Prowler allows you to include your custom checks with the flag:
|
||||
|
||||
## Custom Checks in Prowler
|
||||
|
||||
Prowler supports custom security checks, allowing users to define their own logic.
|
||||
|
||||
```console
|
||||
prowler <provider> -x/--checks-folder <custom_checks_folder>
|
||||
```
|
||||
|
||||
???+ note
|
||||
S3 URIs are also supported as folders for custom checks, e.g. `s3://bucket/prefix/checks_folder/`. Make sure that the used credentials have `s3:GetObject` permissions in the S3 path where the custom checks are located.
|
||||
S3 URIs are also supported for custom check folders (e.g., `s3://bucket/prefix/checks_folder/`). Ensure the credentials used have `s3:GetObject` permissions in the specified S3 path.
|
||||
|
||||
The custom checks folder must contain one subfolder per check, each subfolder must be named as the check and must contain:
|
||||
**Folder Structure for Custom Checks**
|
||||
|
||||
- An empty `__init__.py`: to make Python treat this check folder as a package.
|
||||
- A `check_name.py` containing the check's logic.
|
||||
- A `check_name.metadata.json` containing the check's metadata.
|
||||
Each check must reside in a dedicated subfolder, following this structure:
|
||||
|
||||
- `__init__.py` (empty file) – Ensures Python treats the check folder as a package.
|
||||
- `check_name.py` (name file) – Defines the check’s logic for contextual information.
|
||||
- `check_name.metadata.json` (metadata file) – Defines the check’s metadata for contextual information.
|
||||
|
||||
???+ note
|
||||
The check name must start with the service name followed by an underscore (e.g., ec2_instance_public_ip).
|
||||
The check name must start with the service name followed by an underscore (e.g., ec2\_instance\_public\_ip).
|
||||
|
||||
To see more information about how to write checks see the [Developer Guide](../developer-guide/checks.md#create-a-new-check-for-a-provider).
|
||||
To see more information about how to write checks, refer to the [Developer Guide](../developer-guide/checks.md#create-a-new-check-for-a-provider).
|
||||
|
||||
???+ note
|
||||
If you want to run ONLY your custom check(s), import it with -x (--checks-folder) and then run it with -c (--checks), e.g.:
|
||||
```console
|
||||
prowler aws -x s3://bucket/prowler/providers/aws/services/s3/s3_bucket_policy/ -c s3_bucket_policy
|
||||
```
|
||||
If you want to run ONLY your custom check(s), import it with -x (--checks-folder) and then run it with -c (--checks), e.g.: `console prowler aws -x s3://bucket/prowler/providers/aws/services/s3/s3_bucket_policy/ -c s3_bucket_policy`
|
||||
|
||||
## Severities
|
||||
Each of Prowler's checks has a severity, which can be:
|
||||
|
||||
Each of Prowler's checks has a severity, which can be one of the following:
|
||||
|
||||
- informational
|
||||
- low
|
||||
- medium
|
||||
@@ -96,34 +132,45 @@ Each of Prowler's checks has a severity, which can be:
|
||||
- critical
|
||||
|
||||
To execute specific severity(s):
|
||||
|
||||
```console
|
||||
prowler <provider> --severity critical high
|
||||
```
|
||||
|
||||
## Service
|
||||
|
||||
Prowler has services per provider, there are options related with them:
|
||||
|
||||
- List the available services in the provider:
|
||||
|
||||
```console
|
||||
prowler <provider> --list-services
|
||||
```
|
||||
|
||||
- Execute specific service(s):
|
||||
|
||||
```console
|
||||
prowler <provider> -s/--services s3 iam
|
||||
```
|
||||
|
||||
- Exclude specific service(s):
|
||||
|
||||
```console
|
||||
prowler <provider> --excluded-services ec2 rds
|
||||
```
|
||||
|
||||
## Categories
|
||||
Prowler groups checks in different categories, there are options related with them:
|
||||
|
||||
Prowler groups checks in different categories. There are options related with said categories:
|
||||
|
||||
- List the available categories in the provider:
|
||||
|
||||
```console
|
||||
prowler <provider> --list-categories
|
||||
```
|
||||
|
||||
- Execute specific category(s):
|
||||
|
||||
```console
|
||||
prowler <provider> --categories secrets
|
||||
```
|
||||
|
||||
@@ -1,12 +1,20 @@
|
||||
# Mutelisting
|
||||
Sometimes you may find resources that are intentionally configured in a certain way that may be a bad practice but it is all right with it, for example an AWS S3 Bucket open to the internet hosting a web site, or an AWS Security Group with an open port needed in your use case.
|
||||
|
||||
Mutelist option works along with other options and will modify the output in the following way if the finding is muted:
|
||||
**Muting Findings for Intentional Configurations**
|
||||
|
||||
In some cases, certain AWS resources may be intentionally configured in a way that deviates from security best practices but serves a valid use case. Examples include:
|
||||
|
||||
An AWS S3 bucket open to the Internet, used for hosting a public website.
|
||||
|
||||
An AWS security group with an open port necessary for a specific application.
|
||||
|
||||
**Mutelist Option Behavior**
|
||||
|
||||
The Mutelist option works in combination with other filtering mechanisms and modifies the output in the following way when a finding is muted:
|
||||
|
||||
- JSON-OCSF: `status_id` is `Suppressed`.
|
||||
- CSV: `muted` is `True`. The field `status` will keep the original status, `MANUAL`, `PASS` or `FAIL`, of the finding.
|
||||
|
||||
|
||||
## How the Mutelist Works
|
||||
|
||||
The **Mutelist** uses both "AND" and "OR" logic to determine which resources, checks, regions, and tags should be muted. For each check, the Mutelist evaluates whether the account, region, and resource match the specified criteria using "AND" logic. If tags are specified, the Mutelist can apply either "AND" or "OR" logic.
|
||||
@@ -131,15 +139,16 @@ Mutelist:
|
||||
- "test-resource" # Will mute the resource "test-resource" in all accounts and regions for whatever check from the EC2 service
|
||||
```
|
||||
|
||||
|
||||
### Account, Check, Region, Resource, and Tag
|
||||
|
||||
| Field | Description | Logic |
|
||||
|----------|----------|----------|
|
||||
| `account_id` | Use `*` to apply the mutelist to all accounts. | `ANDed` |
|
||||
| `check_name` | The name of the Prowler check. Use `*` to apply the mutelist to all checks, or `service_*` to apply it to all service's checks. | `ANDed` |
|
||||
| `region` | The region identifier. Use `*` to apply the mutelist to all regions. | `ANDed` |
|
||||
| `resource` | The resource identifier. Use `*` to apply the mutelist to all resources. | `ANDed` |
|
||||
| `tag` | The tag value. | `ORed` |
|
||||
| Field| Description| Logic
|
||||
|----------|----------|----------
|
||||
| `account_id`| Use `*` to apply the mutelist to all accounts.| `ANDed`
|
||||
| `check_name`| The name of the Prowler check. Use `*` to apply the mutelist to all checks, or `service_*` to apply it to all service's checks.| `ANDed`
|
||||
| `region`| The region identifier. Use `*` to apply the mutelist to all regions.| `ANDed`
|
||||
| `resource`| The resource identifier. Use `*` to apply the mutelist to all resources.| `ANDed`
|
||||
| `tag`| The tag value.| `ORed`
|
||||
|
||||
### Description
|
||||
|
||||
@@ -160,9 +169,10 @@ Replace `<provider>` with the appropriate provider name.
|
||||
- The Mutelist can be used in combination with other Prowler options, such as the `--service` or `--checks` option, to further customize the scanning process.
|
||||
- Make sure to review and update the Mutelist regularly to ensure it reflects the desired exclusions and remains up to date with your infrastructure.
|
||||
|
||||
|
||||
## AWS Mutelist
|
||||
### Mute specific AWS regions
|
||||
|
||||
### Muting specific AWS regions
|
||||
|
||||
If you want to mute failed findings only in specific regions, create a file with the following syntax and run it with `prowler aws -w mutelist.yaml`:
|
||||
|
||||
Mutelist:
|
||||
@@ -178,18 +188,21 @@ If you want to mute failed findings only in specific regions, create a file with
|
||||
Description: "Description related with the muted findings for the check"
|
||||
|
||||
### Default Mutelist
|
||||
For the AWS Provider, Prowler is executed with a default AWS Mutelist with the AWS Resources that should be muted such as all resources created by AWS Control Tower when setting up a landing zone that can be found in [AWS Documentation](https://docs.aws.amazon.com/controltower/latest/userguide/shared-account-resources.html).
|
||||
You can see this Mutelist file in [`prowler/config/aws_mutelist.yaml`](https://github.com/prowler-cloud/prowler/blob/master/prowler/config/aws_mutelist.yaml).
|
||||
|
||||
For the AWS Provider, Prowler is executed with a default AWS Mutelist with the AWS Resources that should be muted such as all resources created by AWS Control Tower when setting up a landing zone that can be found in [AWS Documentation](https://docs.aws.amazon.com/controltower/latest/userguide/shared-account-resources.html). You can see this Mutelist file in [`prowler/config/aws_mutelist.yaml`](https://github.com/prowler-cloud/prowler/blob/master/prowler/config/aws_mutelist.yaml).
|
||||
|
||||
### Supported Mutelist Locations
|
||||
|
||||
The mutelisting flag supports the following AWS locations when using the AWS Provider:
|
||||
|
||||
#### AWS S3 URI
|
||||
|
||||
You will need to pass the S3 URI where your Mutelist YAML file was uploaded to your bucket:
|
||||
|
||||
```
|
||||
prowler aws -w s3://<bucket>/<prefix>/mutelist.yaml
|
||||
```
|
||||
|
||||
???+ note
|
||||
Make sure that the used AWS credentials have `s3:GetObject` permissions in the S3 path where the mutelist file is located.
|
||||
|
||||
@@ -201,16 +214,23 @@ You will need to pass the DynamoDB Mutelist Table ARN:
|
||||
prowler aws -w arn:aws:dynamodb:<region_name>:<account_id>:table/<table_name>
|
||||
```
|
||||
|
||||
1. The DynamoDB Table must have the following String keys:
|
||||
<img src="../img/mutelist-keys.png"/>
|
||||
The DynamoDB Table must have the following String keys:
|
||||
|
||||
- The Mutelist Table must have the following columns:
|
||||
- Accounts (String): This field can contain either an Account ID or an `*` (which applies to all the accounts that use this table as an mutelist).
|
||||
- Checks (String): This field can contain either a Prowler Check Name or an `*` (which applies to all the scanned checks).
|
||||
- Regions (List): This field contains a list of regions where this mutelist rule is applied (it can also contains an `*` to apply all scanned regions).
|
||||
- Resources (List): This field contains a list of regex expressions that applies to the resources that are wanted to be muted.
|
||||
- Tags (List): -Optional- This field contains a list of tuples in the form of 'key=value' that applies to the resources tags that are wanted to be muted.
|
||||
- Exceptions (Map): -Optional- This field contains a map of lists of accounts/regions/resources/tags that are wanted to be excepted in the mutelist.
|
||||
<img src="../img/mutelist-keys.png"/>
|
||||
|
||||
The Mutelist Table must have the following columns:
|
||||
|
||||
- Accounts (String): This field can contain either an Account ID or an `*` (which applies to all the accounts that use this table as an mutelist).
|
||||
|
||||
- Checks (String): This field can contain either a Prowler Check Name or an `*` (which applies to all the scanned checks).
|
||||
|
||||
- Regions (List): This field contains a list of regions where this mutelist rule is applied (it can also contains an `*` to apply all scanned regions).
|
||||
|
||||
- Resources (List): This field contains a list of regular expressions (regex) that applies to the resources that are wanted to be muted.
|
||||
|
||||
- Tags (List): -Optional- This field contains a list of tuples in the form of 'key=value' that applies to the resources tags that are wanted to be muted.
|
||||
|
||||
- Exceptions (Map): -Optional- This field contains a map of lists of accounts/regions/resources/tags that are wanted to be excepted in the mutelist.
|
||||
|
||||
The following example will mute all resources in all accounts for the EC2 checks in the regions `eu-west-1` and `us-east-1` with the tags `environment=dev` and `environment=prod`, except the resources containing the string `test` in the account `012345678912` and region `eu-west-1` with the tag `environment=prod`:
|
||||
|
||||
@@ -239,8 +259,7 @@ Make sure that the credentials that Prowler uses can invoke the Lambda Function:
|
||||
Resource: arn:aws:lambda:REGION:ACCOUNT_ID:function:FUNCTION_NAME
|
||||
```
|
||||
|
||||
The Lambda Function can then generate an Mutelist dynamically. Here is the code an example Python Lambda Function that
|
||||
generates an Mutelist:
|
||||
The Lambda Function can then generate an Mutelist dynamically. Here is the code an example Python Lambda Function that generates an Mutelist:
|
||||
|
||||
```
|
||||
def handler(event, context):
|
||||
|
||||
@@ -76,9 +76,9 @@ prowler aws --list-services | ForEach-Object {
|
||||
|
||||
Make any modifications for services you would like to skip scanning by modifying this file.
|
||||
|
||||
Then create a new PowerShell script file `parallel-prowler.ps1` and add the following contents. Update the `$profile` variable to the AWS CLI profile you want to run prowler with.
|
||||
Then create a new PowerShell script file `parallel-prowler.ps1` and add the following contents. Update the `$profile` variable to the AWS CLI profile you want to run Prowler with.
|
||||
|
||||
Change any parameters you would like when calling prowler in the `Start-Job -ScriptBlock` section. Note that you need to keep the `--only-logs` parameter, else some encoding issue occurs when trying to render the progress-bar and prowler won't successfully execute.
|
||||
Change any parameters you would like when calling Prowler in the `Start-Job -ScriptBlock` section. Note that you need to keep the `--only-logs` parameter, else some encoding issue occurs when trying to render the progress-bar and Prowler won't successfully execute.
|
||||
|
||||
```powershell
|
||||
$profile = "your_profile"
|
||||
|
||||
@@ -1,62 +1,62 @@
|
||||
# Pentesting
|
||||
|
||||
Prowler has some checks that analyse pentesting risks (Secrets, Internet Exposed, AuthN, AuthZ and more).
|
||||
Prowler has some checks that analyse pentesting risks (Secrets, Internet Exposed, AuthN, AuthZ, and more).
|
||||
|
||||
## Detect Secrets
|
||||
|
||||
Prowler uses `detect-secrets` library to search for any secrets that are stores in plaintext within your environment.
|
||||
|
||||
The actual checks that have this functionality are:
|
||||
The actual checks that have this functionality are the following:
|
||||
|
||||
- autoscaling_find_secrets_ec2_launch_configuration
|
||||
- awslambda_function_no_secrets_in_code
|
||||
- awslambda_function_no_secrets_in_variables
|
||||
- cloudformation_stack_outputs_find_secrets
|
||||
- ec2_instance_secrets_user_data
|
||||
- ec2_launch_template_no_secrets
|
||||
- ecs_task_definitions_no_environment_secrets
|
||||
- ssm_document_secrets
|
||||
- autoscaling\_find\_secrets\_ec2\_launch\_configuration
|
||||
- awslambda\_function\_no\_secrets\_in\_code
|
||||
- awslambda\_function\_no\_secrets\_in\_variables
|
||||
- cloudformation\_stack\_outputs\_find\_secrets
|
||||
- ec2\_instance\_secrets\_user\_data
|
||||
- ec2\_launch\_template\_no\_secrets
|
||||
- ecs\_task\_definitions\_no\_environment\_secrets
|
||||
- ssm\_document\_secrets
|
||||
|
||||
To execute detect-secrets related checks, you can run the following command:
|
||||
|
||||
```console
|
||||
prowler <provider> --categories secrets
|
||||
```
|
||||
|
||||
## Internet Exposed Resources
|
||||
|
||||
Several checks analyse resources that are exposed to the Internet, these are:
|
||||
|
||||
1. apigateway_restapi_public
|
||||
- appstream_fleet_default_internet_access_disabled
|
||||
- awslambda_function_not_publicly_accessible
|
||||
- ec2_ami_public
|
||||
- ec2_ebs_public_snapshot
|
||||
- ec2_instance_internet_facing_with_instance_profile
|
||||
- ec2_instance_port_X_exposed_to_internet (where X is the port number)
|
||||
- ec2_instance_public_ip
|
||||
- ec2_networkacl_allow_ingress_any_port
|
||||
- ec2_securitygroup_allow_wide_open_public_ipv4
|
||||
- ec2_securitygroup_allow_ingress_from_internet_to_any_port
|
||||
- ecr_repositories_not_publicly_accessible
|
||||
- eks_control_plane_endpoint_access_restricted
|
||||
- eks_endpoints_not_publicly_accessible
|
||||
- eks_control_plane_endpoint_access_restricted
|
||||
- eks_endpoints_not_publicly_accessible
|
||||
- elbv2_internet_facing
|
||||
- kms_key_not_publicly_accessible
|
||||
- opensearch_service_domains_not_publicly_accessible
|
||||
- rds_instance_no_public_access
|
||||
- rds_snapshots_public_access
|
||||
- s3_bucket_policy_public_write_access
|
||||
- s3_bucket_public_access
|
||||
- sagemaker_notebook_instance_without_direct_internet_access_configured
|
||||
- sns_topics_not_publicly_accessible
|
||||
- sqs_queues_not_publicly_accessible
|
||||
- network_public_ip_shodan
|
||||
1. apigateway\_restapi\_public
|
||||
|
||||
...
|
||||
- appstream\_fleet\_default\_internet\_access\_disabled
|
||||
- awslambda\_function\_not\_publicly\_accessible
|
||||
- ec2\_ami\_public
|
||||
- ec2\_ebs\_public\_snapshot
|
||||
- ec2\_instance\_internet\_facing\_with\_instance\_profile
|
||||
- ec2\_instance\_port\_X\_exposed\_to\_internet (where X is the port number)
|
||||
- ec2\_instance\_public\_ip
|
||||
- ec2\_networkacl\_allow\_ingress\_any\_port
|
||||
- ec2\_securitygroup\_allow\_wide\_open\_public\_ipv4
|
||||
- ec2\_securitygroup\_allow\_ingress\_from\_internet\_to\_any\_port
|
||||
- ecr\_repositories\_not\_publicly\_accessible
|
||||
- eks\_control\_plane\_endpoint\_access\_restricted
|
||||
- eks\_endpoints\_not\_publicly\_accessible
|
||||
- eks\_control\_plane\_endpoint\_access\_restricted
|
||||
- eks\_endpoints\_not\_publicly\_accessible
|
||||
- elbv2\_internet\_facing
|
||||
- kms\_key\_not\_publicly\_accessible
|
||||
- opensearch\_service\_domains\_not\_publicly\_accessible
|
||||
- rds\_instance\_no\_public\_access
|
||||
- rds\_snapshots\_public\_access
|
||||
- s3\_bucket\_policy\_public\_write\_access
|
||||
- s3\_bucket\_public\_access
|
||||
- sagemaker\_notebook\_instance\_without\_direct\_internet\_access\_configured
|
||||
- sns\_topics\_not\_publicly\_accessible
|
||||
- sqs\_queues\_not\_publicly\_accessible
|
||||
- network\_public\_ip\_shodan
|
||||
|
||||
To execute internet-exposed related checks, you can run the following command:
|
||||
To execute Internet-exposed related checks, you can run the following command:
|
||||
|
||||
```console
|
||||
prowler <provider> --categories internet-exposed
|
||||
@@ -64,17 +64,22 @@ prowler <provider> --categories internet-exposed
|
||||
|
||||
### Shodan
|
||||
|
||||
Prowler allows you check if any public IPs in your Cloud environments are exposed in Shodan with `-N`/`--shodan <shodan_api_key>` option:
|
||||
Prowler allows you check if any public IPs in your Cloud environments are exposed in Shodan with the `-N`/`--shodan <shodan_api_key>` option:
|
||||
|
||||
For example, you can check if any of your AWS Elastic Compute Cloud (EC2) instances has an elastic IP exposed in Shodan:
|
||||
|
||||
For example, you can check if any of your AWS EC2 instances has an elastic IP exposed in shodan:
|
||||
```console
|
||||
prowler aws -N/--shodan <shodan_api_key> -c ec2_elastic_ip_shodan
|
||||
```
|
||||
Also, you can check if any of your Azure Subscription has an public IP exposed in shodan:
|
||||
|
||||
Also, you can check if any of your Azure Subscription has an public IP exposed in Shodan:
|
||||
|
||||
```console
|
||||
prowler azure -N/--shodan <shodan_api_key> -c network_public_ip_shodan
|
||||
```
|
||||
And finally, you can check if any of your GCP projects has an public IP address exposed in shodan:
|
||||
|
||||
And finally, you can check if any of your GCP projects has an public IP address exposed in Shodan:
|
||||
|
||||
```console
|
||||
prowler gcp -N/--shodan <shodan_api_key> -c compute_public_address_shodan
|
||||
```
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
# Managing Users and Roles
|
||||
|
||||
The **Prowler App** supports multiple users within a single tenant, enabling seamless collaboration by allowing team members to easily share insights and manage security findings.
|
||||
**Prowler App** supports multiple users within a single tenant, enabling seamless collaboration by allowing team members to easily share insights and manage security findings.
|
||||
|
||||
[Roles](#roles) help you control user permissions, determining what actions each user can perform and the data they can access within Prowler. By default, each account includes an immutable **admin** role, ensuring that your account always retains administrative access.
|
||||
|
||||
@@ -23,7 +23,8 @@ To get to User-Invitation Management we will focus on the Membership section.
|
||||
Follow these steps to edit a user of your account:
|
||||
|
||||
1. Navigate to **Users** from the side menu.
|
||||
2. Click on the edit button of the user you want to modify.
|
||||
|
||||
2. Click the edit button of the user you want to modify.
|
||||
|
||||
<img src="../img/rbac/user_edit.png" alt="Edit User" width="700"/>
|
||||
|
||||
@@ -36,31 +37,35 @@ Follow these steps to edit a user of your account:
|
||||
Follow these steps to remove a user of your account:
|
||||
|
||||
1. Navigate to **Users** from the side menu.
|
||||
2. Click on the delete button of your current user.
|
||||
2. Click the delete button of your current user.
|
||||
|
||||
> **Note: Each user will be able to delete himself and not others, regardless of his permissions.**
|
||||
|
||||
<img src="../img/rbac/user_remove.png" alt="Remove User" width="700"/>
|
||||
<img src="../img/rbac/user_remove.png" alt="Remove User" width="700"/>
|
||||
|
||||
### Invitations
|
||||
|
||||
#### Inviting Users
|
||||
|
||||
???+note
|
||||
_Please be aware that at this time, an email address can only be associated with a single Prowler account._
|
||||
Please be aware that at this time, an email address can only be associated with a single Prowler account_.
|
||||
|
||||
Follow these steps to invite a user to your account:
|
||||
|
||||
1. Navigate to **Users** from the side menu.
|
||||
2. Click on the **Invite User** button on the top right-hand corner of the screen.
|
||||
|
||||
2. Click the **Invite User** button on the top right-hand corner of the screen.
|
||||
|
||||
<img src="../img/rbac/invite.png" alt="Invite User" width="700"/>
|
||||
|
||||
3. In the Invite User screen, enter the email address of the user you want to invite.
|
||||
|
||||
4. Pick a Role for the user. You can also change the roles for users and pending invites later. To learn more about the roles and what they can do, see [Roles](#roles).
|
||||
|
||||
<img src="../img/rbac/invitation_info.png" alt="Invitation info" width="700"/>
|
||||
|
||||
5. Click on the **Send Invitation** button to send the invitation to the user.
|
||||
5. Click the **Send Invitation** button to send the invitation to the user.
|
||||
|
||||
6. After clicking you will see a summary of the status of the invitation. You could access this view again from the invitation menu.
|
||||
|
||||
<img src="../img/rbac/invitation_details.png" alt="Invitation details" width="700"/>
|
||||
@@ -78,7 +83,8 @@ Follow these steps to invite a user to your account:
|
||||
Follow these steps to edit an invitation:
|
||||
|
||||
1. Navigate to **Invitations** from the side menu.
|
||||
2. Click on the edit button of the invitation and modify the email, the role or both. **Note: Editing an invitation will not reset its expiration time.**
|
||||
|
||||
2. Click the edit button of the invitation and modify the email, the role or both. **Note: Editing an invitation will not reset its expiration time.**
|
||||
|
||||
<img src="../img/rbac/invitation_edit.png" alt="Invitation edit" width="700"/>
|
||||
<img src="../img/rbac/invitation_edit_1.png" alt="Invitation edit details" width="700"/>
|
||||
@@ -88,13 +94,14 @@ Follow these steps to edit an invitation:
|
||||
Follow these steps to cancel an invitation:
|
||||
|
||||
1. Navigate to **Invitations** from the side menu.
|
||||
2. Click on the revoke button of the invitation.
|
||||
|
||||
2. Click the revoke button of the invitation.
|
||||
|
||||
<img src="../img/rbac/invitation_revoke.png" alt="Invitation revoke" width="700"/>
|
||||
|
||||
#### Sending Invitation Again
|
||||
#### Sending an Invitation Again
|
||||
|
||||
To resend the invitation to the user it is necessary to explicitly **delete the previous invitation and create a new invitation**.
|
||||
To resend the invitation to the user, it is necessary to explicitly **delete the previous invitation and create a new one**.
|
||||
|
||||
## Managing Groups and Roles
|
||||
|
||||
@@ -115,9 +122,11 @@ Alternatively, to grant the role unlimited visibility across all providers, chec
|
||||
|
||||
Follow these steps to create a provider group in your account:
|
||||
|
||||
1. 1. Navigate to **Provider Groups** from the side menu..
|
||||
1. Navigate to **Provider Groups** from the side menu..
|
||||
|
||||
2. In this view you can select the provider groups you want to assign to one or more roles.
|
||||
3. Click on the **Create Group** button on the center of the screen.
|
||||
|
||||
3. Click the **Create Group** button on the center of the screen.
|
||||
|
||||
<img src="../img/rbac/provider_group.png" alt="Create Provider Group" width="700"/>
|
||||
|
||||
@@ -125,8 +134,9 @@ Follow these steps to create a provider group in your account:
|
||||
|
||||
Follow these steps to edit a provider group on your account:
|
||||
|
||||
1. 1. Navigate to **Provider Groups** from the side menu..
|
||||
2. Click on the edit button of the provider group you want to modify.
|
||||
1. Navigate to **Provider Groups** from the side menu.
|
||||
|
||||
2. Click the edit button of the provider group you want to modify.
|
||||
|
||||
<img src="../img/rbac/provider_group_edit.png" alt="Edit Provider Group" width="700"/>
|
||||
|
||||
@@ -138,7 +148,8 @@ Follow these steps to edit a provider group on your account:
|
||||
|
||||
Follow these steps to remove a provider group of your account:
|
||||
|
||||
1. 1. Navigate to **Provider Groups** from the side menu..
|
||||
1. Navigate to **Provider Groups** from the side menu.
|
||||
|
||||
2. Click on the delete button of the provider group you want to remove.
|
||||
|
||||
<img src="../img/rbac/provider_group_remove.png" alt="Remove Provider Group" width="700"/>
|
||||
@@ -150,15 +161,18 @@ Follow these steps to remove a provider group of your account:
|
||||
Follow these steps to create a role for your account:
|
||||
|
||||
1. Navigate to **Roles** from the side menu.
|
||||
|
||||
2. Click on the **Add Role** button on the top right-hand corner of the screen.
|
||||
|
||||
<img src="../img/rbac/role_create.png" alt="Create Role" width="700"/>
|
||||
|
||||
3. In the Add Role screen, enter the role name, the administration permissions and the groups of providers to which the Role will have access to.
|
||||
|
||||
4. In the Groups and Account Visibility section, you will see a list of available groups with checkboxes next to them. To assign a group to the user role, simply click the checkbox next to the group name. If you need to assign multiple groups, repeat the process for each group you wish to add.
|
||||
|
||||
<img src="../img/rbac/role_create_1.png" alt="Role parameters" width="700"/>
|
||||
|
||||
|
||||
???+ note
|
||||
To assign read-only access, select only the `Unlimited Visibility` permission when creating the role. Then, go to the Users page and assign this role to the appropriate user.
|
||||
|
||||
@@ -167,6 +181,7 @@ Follow these steps to create a role for your account:
|
||||
Follow these steps to edit a role on your account:
|
||||
|
||||
1. Navigate to **Roles** from the side menu.
|
||||
|
||||
2. Click on the edit button of the role you want to modify.
|
||||
|
||||
<img src="../img/rbac/role_edit.png" alt="Edit Role" width="700"/>
|
||||
@@ -175,15 +190,18 @@ Follow these steps to edit a role on your account:
|
||||
|
||||
<img src="../img/rbac/role_edit_details.png" alt="Edit Role Details" width="700"/>
|
||||
|
||||
|
||||
#### Removing a Role
|
||||
|
||||
Follow these steps to remove a role of your account:
|
||||
|
||||
1. Navigate to **Roles** from the side menu.
|
||||
|
||||
2. Click on the delete button of the role you want to remove.
|
||||
|
||||
<img src="../img/rbac/role_remove.png" alt="Remove Role" width="700"/>
|
||||
|
||||
|
||||
## RBAC Administrative Permissions
|
||||
|
||||
Assign administrative permissions by selecting from the following options:
|
||||
|
||||
@@ -1,9 +1,8 @@
|
||||
# Social Login Configuration
|
||||
|
||||
The **Prowler App** supports social login using Google and GitHub OAuth providers. This document guides you through configuring the required environment variables to enable social authentication.
|
||||
**Prowler App** supports social login using Google and GitHub OAuth providers. This document guides you through configuring the required environment variables to enable social authentication.
|
||||
|
||||
<img src="../img/social-login/social_login_buttons.png" alt="Social login buttons" width="700" />
|
||||
|
||||
## Configuring Social Login Credentials
|
||||
|
||||
To enable social login with Google and GitHub, you must define the following environment variables:
|
||||
@@ -31,9 +30,7 @@ SOCIAL_GITHUB_OAUTH_CLIENT_SECRET=""
|
||||
- If either `SOCIAL_GOOGLE_OAUTH_CLIENT_ID` or `SOCIAL_GOOGLE_OAUTH_CLIENT_SECRET` is empty or not defined, the Google login button will be disabled.
|
||||
- If either `SOCIAL_GITHUB_OAUTH_CLIENT_ID` or `SOCIAL_GITHUB_OAUTH_CLIENT_SECRET` is empty or not defined, the GitHub login button will be disabled.
|
||||
|
||||
|
||||
<img src="../img/social-login/social_login_buttons_disabled.png" alt="Social login buttons disabled" width="700" />
|
||||
|
||||
## Obtaining OAuth Credentials
|
||||
|
||||
To obtain `CLIENT_ID` and `CLIENT_SECRET` for each provider, follow their official documentation:
|
||||
@@ -41,7 +38,7 @@ To obtain `CLIENT_ID` and `CLIENT_SECRET` for each provider, follow their offici
|
||||
- **Google OAuth**: [Google OAuth Credentials Setup](https://developers.google.com/identity/protocols/oauth2)
|
||||
- **GitHub OAuth**: [GitHub OAuth App Setup](https://docs.github.com/en/apps/oauth-apps/building-oauth-apps/creating-an-oauth-app)
|
||||
|
||||
### Steps Overview
|
||||
### Overview of the Steps
|
||||
|
||||
For both providers, the process generally involves:
|
||||
|
||||
|
||||
@@ -1,71 +1,85 @@
|
||||
# Prowler App
|
||||
|
||||
The **Prowler App** is a user-friendly interface for the Prowler CLI, providing a visual dashboard to monitor your cloud security posture. This tutorial will guide you through setting up and using the Prowler App.
|
||||
**Prowler App** is a user-friendly interface for Prowler CLI, providing a visual dashboard to monitor your cloud security posture. This tutorial will guide you through setting up and using Prowler App.
|
||||
|
||||
After [installing](../index.md#prowler-app-installation) the **Prowler App**, access it at [http://localhost:3000](http://localhost:3000).
|
||||
You can also access to the auto-generated **Prowler API** documentation at [http://localhost:8080/api/v1/docs](http://localhost:8080/api/v1/docs) to see all the available endpoints, parameters and responses.
|
||||
## Accessing Prowler App and API Documentation
|
||||
|
||||
After [installing](../index.md#prowler-app-installation) **Prowler App**, access it at [http://localhost:3000](http://localhost:3000). To view the auto-generated **Prowler API** documentation, navigate to [http://localhost:8080/api/v1/docs](http://localhost:8080/api/v1/docs). This documentation provides details on available endpoints, parameters, and responses.
|
||||
|
||||
???+ note
|
||||
If you are a [Prowler Cloud](https://cloud.prowler.com/sign-in) user you can see API docs at [https://api.prowler.com/api/v1/docs](https://api.prowler.com/api/v1/docs)
|
||||
If you are a [Prowler Cloud](https://cloud.prowler.com/sign-in) user, you can access API docs at [https://api.prowler.com/api/v1/docs](https://api.prowler.com/api/v1/docs)
|
||||
|
||||
## **Step 1: Sign Up**
|
||||
### **Sign up with Email**
|
||||
|
||||
### **Sign Up with Email**
|
||||
|
||||
To get started, sign up using your email and password:
|
||||
|
||||
<img src="../../img/sign-up-button.png" alt="Sign Up Button" width="320"/>
|
||||
<img src="../../img/sign-up.png" alt="Sign Up" width="285"/>
|
||||
|
||||
### **Sign up with Social Login**
|
||||
### **Sign Up with Social Login**
|
||||
|
||||
If Social Login is enabled, you can sign up using your preferred provider (e.g., Google, GitHub).
|
||||
|
||||
???+ note "How Social Login Works"
|
||||
- If your email is already registered, you will be logged in, and your social account will be linked.
|
||||
- If your email is not registered, a new account will be created using your social account email.
|
||||
If your email is already registered, you will be logged in, and your social account will be linked.
|
||||
If your email is not registered, a new account will be created using your social account email.
|
||||
|
||||
???+ note "Enable Social Login"
|
||||
See [how to configure Social Login for Prowler](prowler-app-social-login.md) to enable this feature in your own deployments.
|
||||
|
||||
---
|
||||
|
||||
## **Step 2: Log In**
|
||||
Once you’ve signed up, log in with your email and password to start using the Prowler App.
|
||||
|
||||
Once registered, log in with your email and password to access Prowler App.
|
||||
|
||||
<img src="../../img/log-in.png" alt="Log In" width="350"/>
|
||||
|
||||
You will see the Overview page with no data yet, so let's start adding a provider to scan your cloud environment.
|
||||
|
||||
---
|
||||
Upon logging in, the Overview page will display. At this stage, no data is present: add a provider to begin scanning your cloud environment.
|
||||
|
||||
## **Step 3: Add a Provider**
|
||||
To run your first scan, you need to add a cloud provider account. Prowler App supports AWS, Azure, GCP, and Kubernetes.
|
||||
|
||||
To perform security scans, link a cloud provider account. Prowler supports the following providers:
|
||||
|
||||
- **AWS**
|
||||
|
||||
- **Azure**
|
||||
|
||||
- **Google Cloud Platform (GCP)**
|
||||
|
||||
- **Kubernetes**
|
||||
|
||||
- **M365**
|
||||
|
||||
Steps to add a provider:
|
||||
|
||||
1. Navigate to `Settings > Cloud Providers`.
|
||||
2. Click `Add Account` to set up a new provider and provide your credentials:
|
||||
2. Click `Add Account` to set up a new provider and provide your credentials.
|
||||
|
||||
<img src="../../img/add-provider.png" alt="Add Provider" width="700"/>
|
||||
|
||||
---
|
||||
|
||||
## **Step 4: Configure the Provider**
|
||||
Choose the provider you want to scan from the following options:
|
||||
|
||||
Select the cloud provider you want to scan.
|
||||
|
||||
<img src="../../img/select-provider.png" alt="Select a Provider" width="700"/>
|
||||
|
||||
Once you’ve selected a provider, you need to provide the Provider UID:
|
||||
Once chosen, enter the Provider UID for authentication:
|
||||
|
||||
- **AWS**: Enter your AWS Account ID.
|
||||
- **GCP**: Enter your GCP Project ID.
|
||||
- **Azure**: Enter your Azure Subscription ID.
|
||||
- **Kubernetes**: Enter your Kubernetes Cluster context of your kubeconfig file.
|
||||
- **M365**: Enter your M365 Domain ID.
|
||||
|
||||
Optionally, provide a **Provider Alias** for easier identification. Follow the instructions provided to add your credentials:
|
||||
|
||||
---
|
||||
### **Step 4.1: AWS Credentials**
|
||||
|
||||
For AWS, enter your `AWS Account ID` and choose one of the following methods to connect:
|
||||
|
||||
#### **Step 4.1.1: IAM Access Keys**
|
||||
|
||||
1. Select `Connect via Credentials`.
|
||||
|
||||
<img src="../../img/connect-aws-credentials.png" alt="AWS Credentials" width="350"/>
|
||||
@@ -75,6 +89,7 @@ For AWS, enter your `AWS Account ID` and choose one of the following methods to
|
||||
<img src="../../img/aws-credentials.png" alt="AWS Credentials" width="350"/>
|
||||
|
||||
#### **Step 4.1.2: IAM Role**
|
||||
|
||||
1. Select `Connect assuming IAM Role`.
|
||||
|
||||
<img src="../../img/connect-aws-role.png" alt="AWS Role" width="350"/>
|
||||
@@ -84,7 +99,7 @@ For AWS, enter your `AWS Account ID` and choose one of the following methods to
|
||||
<img src="../../img/aws-role.png" alt="AWS Role" width="700"/>
|
||||
|
||||
???+ note
|
||||
check if your AWS Security Token Service (STS) has the EU (Ireland) endpoint active. If not we will not be able to connect to your AWS account.
|
||||
Check if your AWS Security Token Service (STS) has the EU (Ireland) endpoint active. If not, we will not be able to connect to your AWS account.
|
||||
|
||||
If that is the case your STS configuration may look like this:
|
||||
|
||||
@@ -92,10 +107,9 @@ For AWS, enter your `AWS Account ID` and choose one of the following methods to
|
||||
|
||||
To solve this issue, please activate the EU (Ireland) STS endpoint.
|
||||
|
||||
---
|
||||
### **Step 4.2: Azure Credentials**:
|
||||
|
||||
### **Step 4.2: Azure Credentials**
|
||||
For Azure, Prowler App uses a service principal application to authenticate, for more information about the process of creating and adding permissions to a service principal check this [section](../getting-started/requirements.md#azure). When you finish creating and adding the [Entra](./azure/create-prowler-service-principal.md#assigning-the-proper-permissions) and [Subscription](./azure/subscriptions.md#assign-the-appropriate-permissions-to-the-identity-that-is-going-to-be-assumed-by-prowler) scope permissions to the service principal, enter the `Tenant ID`, `Client ID` and `Client Secret` of the service principal application.
|
||||
For Azure, Prowler App uses a service principal application to authenticate. For more information about the process of creating and adding permissions to a service principal refer to this [section](../getting-started/requirements.md#azure). When you finish creating and adding the [Entra](./azure/create-prowler-service-principal.md#assigning-the-proper-permissions) and [Subscription](./azure/subscriptions.md#assign-the-appropriate-permissions-to-the-identity-that-is-going-to-be-assumed-by-prowler) scope permissions to the service principal, enter the `Tenant ID`, `Client ID` and `Client Secret` of the service principal application.
|
||||
|
||||
<img src="../../img/azure-credentials.png" alt="Azure Credentials" width="700"/>
|
||||
|
||||
@@ -123,51 +137,56 @@ First of all, in the same project that you selected in the previous step, you ne
|
||||
#### **Step 4.3.2: Application Default Credentials**
|
||||
|
||||
1. Run the following command in your terminal to authenticate with GCP:
|
||||
```bash
|
||||
gcloud auth application-default login
|
||||
```
|
||||
|
||||
```bash
|
||||
gcloud auth application-default login
|
||||
```
|
||||
|
||||
2. Once authenticated, get the `Client ID`, `Client Secret` and `Refresh Token` from `~/.config/gcloud/application_default_credentials`.
|
||||
3. Paste the `Client ID`, `Client Secret` and `Refresh Token` into the Prowler App.
|
||||
|
||||
3. Paste the `Client ID`, `Client Secret` and `Refresh Token` into Prowler App.
|
||||
|
||||
<img src="../../img/gcp-credentials.png" alt="GCP Credentials" width="700"/>
|
||||
|
||||
---
|
||||
### **Step 4.4: Kubernetes Credentials**
|
||||
### **Step 4.4: Kubernetes Credentials**:
|
||||
|
||||
For Kubernetes, Prowler App uses a `kubeconfig` file to authenticate, paste the contents of your `kubeconfig` file into the `Kubeconfig content` field.
|
||||
|
||||
By default, the `kubeconfig` file is located at `~/.kube/config`.
|
||||
|
||||
<img src="../../img/kubernetes-credentials.png" alt="Kubernetes Credentials" width="700"/>
|
||||
|
||||
???+ note
|
||||
If you are adding an **EKS**, **GKE**, **AKS** or external cluster, follow these additional steps to ensure proper authentication:
|
||||
If you are adding an **EKS**, **GKE**, **AKS** or external cluster, follow these additional steps to ensure proper authentication:
|
||||
|
||||
** Make sure your cluster allow traffic from the Prowler Cloud IP address `52.48.254.174/32` **
|
||||
**Make sure your cluster allow traffic from the Prowler Cloud IP address `52.48.254.174/32`**
|
||||
|
||||
1. Apply the necessary Kubernetes resources to your EKS, GKE, AKS or external cluster (you can find the files in the [`kubernetes` directory of the Prowler repository](https://github.com/prowler-cloud/prowler/tree/master/kubernetes)):
|
||||
|
||||
1. Apply the necessary Kubernetes resources to your EKS, GKE, AKS or external cluster (you can find the files in the [`kubernetes` directory of the Prowler repository](https://github.com/prowler-cloud/prowler/tree/master/kubernetes)):
|
||||
```console
|
||||
kubectl apply -f kubernetes/prowler-sa.yaml
|
||||
kubectl apply -f kubernetes/prowler-role.yaml
|
||||
kubectl apply -f kubernetes/prowler-rolebinding.yaml
|
||||
```
|
||||
|
||||
2. Generate a long-lived token for authentication:
|
||||
2. Generate a long-lived token for authentication:
|
||||
|
||||
```console
|
||||
kubectl create token prowler-sa -n prowler-ns --duration=0
|
||||
```
|
||||
- **Security Note:** The `--duration=0` option generates a non-expiring token, which may pose a security risk if not managed properly. Users should decide on an appropriate expiration time based on their security policies. If a limited-time token is preferred, set `--duration=<TIME>` (e.g., `--duration=24h`).
|
||||
- **Important:** If the token expires, Prowler Cloud will no longer be able to authenticate with the cluster. In this case, you will need to generate a new token and **remove and re-add the provider in Prowler Cloud** with the updated `kubeconfig`.
|
||||
|
||||
3. Update your `kubeconfig` to use the ServiceAccount token:
|
||||
- **Security Note:** The `--duration=0` option generates a non-expiring token, which may pose a security risk if not managed properly. Users should decide on an appropriate expiration time based on their security policies. If a limited-time token is preferred, set `--duration=<TIME>` (e.g., `--duration=24h`).
|
||||
- **Important:** If the token expires, Prowler Cloud will no longer be able to authenticate with the cluster. In this case, you will need to generate a new token and **remove and re-add the provider in Prowler Cloud** with the updated `kubeconfig`.
|
||||
|
||||
3. Update your `kubeconfig` to use the ServiceAccount token:
|
||||
|
||||
```console
|
||||
kubectl config set-credentials prowler-sa --token=<SA_TOKEN>
|
||||
kubectl config set-context <CONTEXT_NAME> --user=prowler-sa
|
||||
```
|
||||
Replace <SA_TOKEN> with the generated token and <CONTEXT_NAME> with your KubeConfig Context Name of your EKS, GKE or AKS cluster.
|
||||
|
||||
4. Now you can add the modified `kubeconfig` in Prowler Cloud. Then simply test the connection.
|
||||
Replace `<SA_TOKEN>` with the generated token and `<CONTEXT_NAME>` with your KubeConfig Context Name of your EKS, GKE or AKS cluster.
|
||||
|
||||
---
|
||||
4. Now you can add the modified `kubeconfig` in Prowler Cloud. Then test the connection.
|
||||
|
||||
### **Step 4.5: M365 Credentials**
|
||||
For M365, you must enter your Domain ID and choose the authentication method you want to use:
|
||||
@@ -182,40 +201,47 @@ For full setup instructions and requirements, check the [Microsoft 365 provider
|
||||
|
||||
<img src="../../img/m365-credentials.png" alt="Prowler Cloud M365 Credentials" width="700"/>
|
||||
|
||||
---
|
||||
|
||||
## **Step 5: Test Connection**
|
||||
After adding your credentials of your cloud account, click the `Launch` button to verify that the Prowler App can successfully connect to your provider:
|
||||
|
||||
After adding your credentials of your cloud account, click the `Launch` button to verify that Prowler App can successfully connect to your provider:
|
||||
|
||||
<img src="../../img/test-connection-button.png" alt="Test Connection" width="700"/>
|
||||
|
||||
|
||||
## **Step 6: Scan started**
|
||||
After successfully adding and testing your credentials, Prowler will start scanning your cloud environment, click on the `Go to Scans` button to see the progress:
|
||||
|
||||
After successfully adding and testing your credentials, Prowler will start scanning your cloud environment, click the `Go to Scans` button to see the progress:
|
||||
|
||||
<img src="../../img/provider-added.png" alt="Start Now" width="700"/>
|
||||
|
||||
???+ note
|
||||
Prowler will automatically scan all configured providers every **24 hours**, ensuring your cloud environment stays continuously monitored.
|
||||
---
|
||||
|
||||
## **Step 7: Monitor Scan Progress**
|
||||
|
||||
Track the progress of your scan in the `Scans` section:
|
||||
|
||||
<img src="../../img/scan-progress.png" alt="Scan Progress" width="700"/>
|
||||
|
||||
---
|
||||
|
||||
## **Step 8: Analyze the Findings**
|
||||
|
||||
While the scan is running, start exploring the findings in these sections:
|
||||
|
||||
- **Overview**: High-level summary of the scans. <img src="../../img/overview.png" alt="Overview" width="700"/>
|
||||
- **Compliance**: Insights into compliance status. <img src="../../img/compliance.png" alt="Compliance" width="700"/>
|
||||
- **Overview**: High-level summary of the scans.
|
||||
|
||||
<img src="../../img/overview.png" alt="Overview" width="700"/>
|
||||
|
||||
- **Compliance**: Insights into compliance status.
|
||||
|
||||
<img src="../../img/compliance.png" alt="Compliance" width="700"/>
|
||||
|
||||
- **Issues**: Types of issues detected.
|
||||
|
||||
<img src="../../img/issues.png" alt="Issues" width="300" style="text-align: center;"/>
|
||||
<img src="../../img/issues.png" alt="Issues" width="300" style="text-align: center;"/>
|
||||
|
||||
- **Browse All Findings**: Detailed list of findings detected, where you can filter by severity, service, and more. <img src="../../img/findings.png" alt="Findings" width="700"/>
|
||||
- **Browse All Findings**: Detailed list of findings detected, where you can filter by severity, service, and more.
|
||||
|
||||
<img src="../../img/findings.png" alt="Findings" width="700"/>
|
||||
|
||||
To view all `new` findings that have not been seen prior to this scan, click the `Delta` filter and select `new`. To view all `changed` findings that have had a status change (from `PASS` to `FAIL` for example), click the `Delta` filter and select `changed`.
|
||||
|
||||
@@ -225,18 +251,9 @@ Once a scan is complete, navigate to the Scan Jobs section to download the outpu
|
||||
|
||||
<img src="../../img/scan_jobs_section.png" alt="Scan Jobs section" width="700"/>
|
||||
|
||||
These outputs are bundled into a single .zip archive containing:
|
||||
You can download the output files generated by Prowler as a single `zip` file. This archive contains the CSV, JSON-OSCF, and HTML reports detailing the findings.
|
||||
|
||||
- CSV report
|
||||
|
||||
- JSON-OSCF formatted results
|
||||
|
||||
- HTML report
|
||||
|
||||
- A folder with individual compliance reports
|
||||
|
||||
???+ note "Note"
|
||||
The Download button only becomes active after a scan completes successfully.
|
||||
To download these files, click the **Download** button. This button becomes available only after the scan has finished.
|
||||
|
||||
<img src="../../img/download_output.png" alt="Download output" width="700"/>
|
||||
|
||||
|
||||
@@ -1,9 +1,13 @@
|
||||
|
||||
# Prowler Check Kreator
|
||||
|
||||
???+ note
|
||||
Currently, this tool is only available for creating checks for the AWS provider.
|
||||
|
||||
???+ note
|
||||
If you are looking for a way to create new checks for all the supported providers, you can use [Prowler Studio](https://github.com/prowler-cloud/prowler-studio), it is an AI-powered toolkit for generating and managing security checks for Prowler (better version of the Check Kreator).
|
||||
|
||||
## Introduction
|
||||
|
||||
**Prowler Check Kreator** is a utility designed to streamline the creation of new checks for Prowler. This tool generates all necessary files required to add a new check to the Prowler repository. Specifically, it creates:
|
||||
|
||||
- A dedicated folder for the check.
|
||||
@@ -18,6 +22,7 @@ To use the tool, execute the main script with the following command:
|
||||
```bash
|
||||
python util/prowler_check_kreator/prowler_check_kreator.py <prowler_provider> <check_name>
|
||||
```
|
||||
|
||||
Parameters:
|
||||
|
||||
- `<prowler_provider>`: Currently only AWS is supported.
|
||||
|
||||
@@ -5,11 +5,11 @@ Prowler allows you to execute a quick inventory to extract the number of resourc
|
||||
???+ note
|
||||
Currently, it is only available for AWS provider.
|
||||
|
||||
|
||||
- You can use option `-i`/`--quick-inventory` to execute it:
|
||||
```sh
|
||||
prowler <provider> -i
|
||||
```
|
||||
|
||||
```sh
|
||||
prowler <provider> -i
|
||||
```
|
||||
|
||||
???+ note
|
||||
By default, it extracts resources from all the regions, you could use `-f`/`--filter-region` to specify the regions to execute the analysis.
|
||||
@@ -21,4 +21,5 @@ prowler <provider> -i
|
||||

|
||||
|
||||
## Objections
|
||||
The inventorying process is done with `resourcegroupstaggingapi` calls which means that only resources they have or have had tags will appear (except for the IAM and S3 resources which are done with Boto3 API calls).
|
||||
|
||||
The inventorying process is carried out with `resourcegroupstaggingapi` calls, which means that only resources they have or have had tags will appear (except for the IAM and S3 resources which are done with Boto3 API calls).
|
||||
|
||||
@@ -1,44 +1,58 @@
|
||||
# Reporting
|
||||
# Reporting in Prowler
|
||||
|
||||
By default, Prowler will generate the CSV and JSON-[OCSF](https://schema.ocsf.io/) report.
|
||||
Prowler generates security assessment reports in multiple formats, ensuring compatibility with various analysis tools and AWS integrations.
|
||||
|
||||
## Default Report Generation
|
||||
|
||||
By default, Prowler outputs reports in CSV and JSON-[OCSF](https://schema.ocsf.io/) formats:
|
||||
|
||||
```console
|
||||
prowler <provider> -M csv json-ocsf json-asff html
|
||||
```
|
||||
|
||||
If you want to generate the JSON-ASFF (used by AWS Security Hub) report you can set it using the `-M/--output-modes/--output-formats`, like:
|
||||
If you require reports in JSON-ASFF (used by AWS Security Hub), set it using the `-M/--output-modes/--output-formats` flag, as in the following example:
|
||||
|
||||
```console
|
||||
prowler <provider> --output-formats json-asff
|
||||
```
|
||||
|
||||
By default, all the compliance outputs will be generated when Prowler is executed. Compliance outputs will be placed inside the `/output/compliance` directory.
|
||||
## Compliance Reports
|
||||
|
||||
All compliance-related reports are automatically generated when Prowler is executed. These outputs are stored in the `/output/compliance` directory.
|
||||
|
||||
## Custom Output Flags
|
||||
|
||||
By default, Prowler creates a file inside the `output` directory named: `prowler-output-ACCOUNT_NUM-OUTPUT_DATE.format`.
|
||||
|
||||
However, both the output file name and directory can be personalised:
|
||||
|
||||
- Custom output report name: you can use the flag `-F`/`--output-filename`
|
||||
- Custom output report name:
|
||||
|
||||
You can use the flag `-F`/`--output-filename`
|
||||
|
||||
```console
|
||||
prowler <provider> -M csv json-ocsf json-asff -F <custom_report_name>
|
||||
```
|
||||
- Custom output directory: you can use the flag `-o`/`--output-directory`
|
||||
|
||||
|
||||
- Custom output directory:
|
||||
|
||||
You can use the flag `-o`/`--output-directory`
|
||||
|
||||
```console
|
||||
prowler <provider> -M csv json-ocsf json-asff -o <custom_report_directory>
|
||||
```
|
||||
|
||||
???+ note
|
||||
Both flags can be used simultaneously to provide a custom directory and filename.
|
||||
```console
|
||||
prowler <provider> -M csv json-ocsf json-asff \
|
||||
-F <custom_report_name> -o <custom_report_directory>
|
||||
```
|
||||
Both flags can be used simultaneously to provide a custom directory and filename. `console prowler <provider> -M csv json-ocsf json-asff \ -F <custom_report_name> -o <custom_report_directory>`
|
||||
|
||||
## Output timestamp format
|
||||
|
||||
By default, the timestamp format of the output files is ISO 8601. This can be changed with the flag `--unix-timestamp` generating the timestamp fields in pure unix timestamp format.
|
||||
|
||||
## Output Formats
|
||||
## Supported Output Formats
|
||||
|
||||
Prowler supports natively the following output formats:
|
||||
Prowler natively supports the following reporting output formats:
|
||||
|
||||
- CSV
|
||||
- JSON-OCSF
|
||||
@@ -49,70 +63,69 @@ Hereunder is the structure for each of the supported report formats by Prowler:
|
||||
|
||||
### CSV
|
||||
|
||||
The CSV format has a common format for all the providers. The following are the available columns:
|
||||
The CSV format follows a standardized structure across all providers. The following are the available columns:
|
||||
|
||||
- AUTH_METHOD
|
||||
- AUTH\_METHOD
|
||||
- TIMESTAMP
|
||||
- ACCOUNT_UID
|
||||
- ACCOUNT_NAME
|
||||
- ACCOUNT_EMAIL
|
||||
- ACCOUNT_ORGANIZATION_UID
|
||||
- ACCOUNT_ORGANIZATION_NAME
|
||||
- ACCOUNT_TAGS
|
||||
- FINDING_UID
|
||||
- ACCOUNT\_UID
|
||||
- ACCOUNT\_NAME
|
||||
- ACCOUNT\_EMAIL
|
||||
- ACCOUNT\_ORGANIZATION\_UID
|
||||
- ACCOUNT\_ORGANIZATION\_NAME
|
||||
- ACCOUNT\_TAGS
|
||||
- FINDING\_UID
|
||||
- PROVIDER
|
||||
- CHECK_ID
|
||||
- CHECK_TITLE
|
||||
- CHECK_TYPE
|
||||
- CHECK\_ID
|
||||
- CHECK\_TITLE
|
||||
- CHECK\_TYPE
|
||||
- STATUS
|
||||
- STATUS_EXTENDED
|
||||
- STATUS\_EXTENDED
|
||||
- MUTED
|
||||
- SERVICE_NAME
|
||||
- SUBSERVICE_NAME
|
||||
- SERVICE\_NAME
|
||||
- SUBSERVICE\_NAME
|
||||
- SEVERITY
|
||||
- RESOURCE_TYPE
|
||||
- RESOURCE_UID
|
||||
- RESOURCE_NAME
|
||||
- RESOURCE_DETAILS
|
||||
- RESOURCE_TAGS
|
||||
- RESOURCE\_TYPE
|
||||
- RESOURCE\_UID
|
||||
- RESOURCE\_NAME
|
||||
- RESOURCE\_DETAILS
|
||||
- RESOURCE\_TAGS
|
||||
- PARTITION
|
||||
- REGION
|
||||
- DESCRIPTION
|
||||
- RISK
|
||||
- RELATED_URL
|
||||
- REMEDIATION_RECOMMENDATION_TEXT
|
||||
- REMEDIATION_RECOMMENDATION_URL
|
||||
- REMEDIATION_CODE_NATIVEIAC
|
||||
- REMEDIATION_CODE_TERRAFORM
|
||||
- REMEDIATION_CODE_CLI
|
||||
- REMEDIATION_CODE_OTHER
|
||||
- RELATED\_URL
|
||||
- REMEDIATION\_RECOMMENDATION\_TEXT
|
||||
- REMEDIATION\_RECOMMENDATION\_URL
|
||||
- REMEDIATION\_CODE\_NATIVEIAC
|
||||
- REMEDIATION\_CODE\_TERRAFORM
|
||||
- REMEDIATION\_CODE\_CLI
|
||||
- REMEDIATION\_CODE\_OTHER
|
||||
- COMPLIANCE
|
||||
- CATEGORIES
|
||||
- DEPENDS_ON
|
||||
- RELATED_TO
|
||||
- DEPENDS\_ON
|
||||
- RELATED\_TO
|
||||
- NOTES
|
||||
- PROWLER_VERSION
|
||||
- PROWLER\_VERSION
|
||||
|
||||
#### CSV Headers Mapping
|
||||
|
||||
The following table shows the mapping between the CSV headers and the the providers fields:
|
||||
|
||||
| Open Source Consolidated | AWS | GCP | AZURE | KUBERNETES |
|
||||
|-----------------------------|-----------------------------|------------------------------|-----------------------------|----------------------------|
|
||||
| auth_method | profile | principal | identity_type : identity_id | in-cluster/kube-config |
|
||||
| provider | provider | provider | provider | provider |
|
||||
| account_uid | account_id / account_arn | project_id | subscription_id | cluster |
|
||||
| account_name | account_name | project_name | subscription_name | context:context |
|
||||
| account_email | account_email | N/A | N/A | N/A |
|
||||
| account_organization_uid | account_organizations_arn | project_organization_id | tenant_id | N/A |
|
||||
| account_organization_name | account_org | project_organization_display_name | tenant_domain | N/A |
|
||||
| account_tags | account_tags | project_labels | subscription_tags | N/A |
|
||||
| partition | partition | N/A | region_config.name | N/A |
|
||||
| region | region | location | location | namespace:namespace |
|
||||
| resource_name | resource_id | resource_name | resource_name | resource_name |
|
||||
| resource_uid | resource_arn | resource_id | resource_id | resource_id |
|
||||
| finding_uid | finding_unique_id | finding_unique_id | finding_unique_id | finding_unique_id |
|
||||
|
||||
| Open Source Consolidated| AWS| GCP| AZURE| KUBERNETES
|
||||
|----------|----------|----------|----------|----------
|
||||
| auth\_method| profile| principal| identity\_type : identity\_id| in-cluster/kube-config
|
||||
| provider| provider| provider| provider| provider
|
||||
| account\_uid| account\_id / account\_arn| project\_id| subscription\_id| cluster
|
||||
| account\_name| account\_name| project\_name| subscription\_name| context:context
|
||||
| account\_email| account\_email| N/A| N/A| N/A
|
||||
| account\_organization\_uid| account\_organizations\_arn| project\_organization\_id| tenant\_id| N/A
|
||||
| account\_organization\_name| account\_org| project\_organization\_display\_name| tenant\_domain| N/A
|
||||
| account\_tags| account\_tags| project\_labels| subscription\_tags| N/A
|
||||
| partition| partition| N/A| region\_config.name| N/A
|
||||
| region| region| location| location| namespace:namespace
|
||||
| resource\_name| resource\_id| resource\_name| resource\_name| resource\_name
|
||||
| resource\_uid| resource\_arn| resource\_id| resource\_id| resource\_id
|
||||
| finding\_uid| finding\_unique\_id| finding\_unique\_id| finding\_unique\_id| finding\_unique\_id
|
||||
|
||||
### JSON-OCSF
|
||||
|
||||
@@ -347,75 +360,72 @@ The following code is an example output of the [JSON-ASFF](https://docs.aws.amaz
|
||||
The following image is an example of the HTML output:
|
||||
|
||||
<img src="../img/reporting/html-output.png">
|
||||
|
||||
## V4 Deprecations
|
||||
|
||||
Some deprecations have been made to unify formats and improve outputs.
|
||||
|
||||
|
||||
### JSON
|
||||
|
||||
Native JSON format has been deprecated in favor of JSON [OCSF](https://schema.ocsf.io/) `v1.1.0`.
|
||||
|
||||
The following is the mapping between the native JSON and the Detection Finding from the JSON-OCSF:
|
||||
|
||||
| Native JSON Prowler v3 | JSON-OCSF v.1.1.0 |
|
||||
| --- |---|
|
||||
| AssessmentStartTime | time_dt |
|
||||
| FindingUniqueId | finding_info.uid |
|
||||
| Provider | cloud.provider |
|
||||
| CheckID | metadata.event_code |
|
||||
| CheckTitle | finding_info.title |
|
||||
| CheckType | finding_info.types |
|
||||
| ServiceName | resources.group.name |
|
||||
| SubServiceName | _Not mapped yet_ |
|
||||
| Status | status_code |
|
||||
| StatusExtended | status_detail |
|
||||
| Severity | severity |
|
||||
| ResourceType | resources.type |
|
||||
| ResourceDetails | resources.data.details |
|
||||
| Description | finding_info.desc |
|
||||
| Risk | risk_details |
|
||||
| RelatedUrl | unmapped.related_url |
|
||||
| Remediation.Recommendation.Text | remediation.desc |
|
||||
| Remediation.Recommendation.Url | remediation.references |
|
||||
| Remediation.Code.NativeIaC | remediation.references |
|
||||
| Remediation.Code.Terraform | remediation.references |
|
||||
| Remediation.Code.CLI | remediation.references |
|
||||
| Remediation.Code.Other | remediation.references |
|
||||
| Compliance | unmapped.compliance |
|
||||
| Categories | unmapped.categories |
|
||||
| DependsOn | unmapped.depends_on |
|
||||
| RelatedTo | unmapped.related_to |
|
||||
| Notes | unmapped.notes |
|
||||
| Profile | _Not mapped yet_ |
|
||||
| AccountId | cloud.account.uid |
|
||||
| OrganizationsInfo.account_name | cloud.account.name |
|
||||
| OrganizationsInfo.account_email | _Not mapped yet_ |
|
||||
| OrganizationsInfo.account_arn | _Not mapped yet_ |
|
||||
| OrganizationsInfo.account_org | cloud.org.name |
|
||||
| OrganizationsInfo.account_tags | cloud.account.labels |
|
||||
| Region | resources.region |
|
||||
| ResourceId | resources.name |
|
||||
| ResourceArn | resources.uid |
|
||||
| ResourceTags | resources.labels |
|
||||
|
||||
| Native JSON Prowler v3| JSON-OCSF v.1.1.0
|
||||
|----------|----------
|
||||
| AssessmentStartTime| time\_dt
|
||||
| FindingUniqueId| finding\_info.uid
|
||||
| Provider| cloud.provider
|
||||
| CheckID| metadata.event\_code
|
||||
| CheckTitle| finding\_info.title
|
||||
| CheckType| finding\_info.types
|
||||
| ServiceName| resources.group.name
|
||||
| SubServiceName| _Not mapped yet_
|
||||
| Status| status\_code
|
||||
| StatusExtended| status\_detail
|
||||
| Severity| severity
|
||||
| ResourceType| resources.type
|
||||
| ResourceDetails| resources.data.details
|
||||
| Description| finding\_info.desc
|
||||
| Risk| risk\_details
|
||||
| RelatedUrl| unmapped.related\_url
|
||||
| Remediation.Recommendation.Text| remediation.desc
|
||||
| Remediation.Recommendation.Url| remediation.references
|
||||
| Remediation.Code.NativeIaC| remediation.references
|
||||
| Remediation.Code.Terraform| remediation.references
|
||||
| Remediation.Code.CLI| remediation.references
|
||||
| Remediation.Code.Other| remediation.references
|
||||
| Compliance| unmapped.compliance
|
||||
| Categories| unmapped.categories
|
||||
| DependsOn| unmapped.depends\_on
|
||||
| RelatedTo| unmapped.related\_to
|
||||
| Notes| unmapped.notes
|
||||
| Profile| _Not mapped yet_
|
||||
| AccountId| cloud.account.uid
|
||||
| OrganizationsInfo.account\_name| cloud.account.name
|
||||
| OrganizationsInfo.account\_email| _Not mapped yet_
|
||||
| OrganizationsInfo.account\_arn| _Not mapped yet_
|
||||
| OrganizationsInfo.account\_org| cloud.org.name
|
||||
| OrganizationsInfo.account\_tags| cloud.account.labels
|
||||
| Region| resources.region
|
||||
| ResourceId| resources.name
|
||||
| ResourceArn| resources.uid
|
||||
| ResourceTags| resources.labels
|
||||
|
||||
### CSV Columns
|
||||
|
||||
In Prowler v3 each provider had some specific columns, different from the rest. These are the cases that have changed in Prowler v4:
|
||||
|
||||
| Provider | v3 | v4 |
|
||||
| --- |---|---|
|
||||
| AWS | PROFILE | AUTH_METHOD |
|
||||
| AWS | ACCOUNT_ID| ACCOUNT_UID |
|
||||
| AWS | ACCOUNT_ORGANIZATION_ARN | ACCOUNT_ORGANIZATION_UID |
|
||||
| AWS | ACCOUNT_ORG | ACCOUNT_ORGANIZATION_NAME |
|
||||
| AWS | FINDING_UNIQUE_ID | FINDING_UID |
|
||||
| AWS | ASSESSMENT_START_TIME | TIMESTAMP |
|
||||
| AZURE | TENANT_DOMAIN | ACCOUNT_ORGANIZATION_NAME |
|
||||
| AZURE | SUBSCRIPTION | ACCOUNT_UID |
|
||||
| GCP | PROJECT_ID | ACCOUNT_UID |
|
||||
| GCP | LOCATION | REGION |
|
||||
| AWS / AZURE / GCP | RESOURCE_ID | RESOURCE_NAME |
|
||||
| AWS / AZURE / GCP | RESOURCE_ARN | RESOURCE_UID |
|
||||
| Provider| v3| v4
|
||||
|----------|----------|----------
|
||||
| AWS| PROFILE| AUTH\_METHOD
|
||||
| AWS| ACCOUNT\_ID| ACCOUNT\_UID
|
||||
| AWS| ACCOUNT\_ORGANIZATION\_ARN| ACCOUNT\_ORGANIZATION\_UID
|
||||
| AWS| ACCOUNT\_ORG| ACCOUNT\_ORGANIZATION\_NAME
|
||||
| AWS| FINDING\_UNIQUE\_ID| FINDING\_UID
|
||||
| AWS| ASSESSMENT\_START\_TIME| TIMESTAMP
|
||||
| AZURE| TENANT\_DOMAIN| ACCOUNT\_ORGANIZATION\_NAME
|
||||
| AZURE| SUBSCRIPTION| ACCOUNT\_UID
|
||||
| GCP| PROJECT\_ID| ACCOUNT\_UID
|
||||
| GCP| LOCATION| REGION
|
||||
| AWS / AZURE / GCP| RESOURCE\_ID| RESOURCE\_NAME
|
||||
| AWS / AZURE / GCP| RESOURCE\_ARN| RESOURCE\_UID
|
||||
|
||||
@@ -1,91 +1,109 @@
|
||||
# Scan Unused Services
|
||||
# Scanning Unused Services
|
||||
|
||||
???+ note
|
||||
Currently only available on the AWS provider.
|
||||
This feature is currently available only for the AWS provider.
|
||||
|
||||
By default, Prowler only scans the cloud services that are used (where resources are created) to reduce the number of findings in Prowler's reports. If you want Prowler to also scan unused services, you can use the following command:
|
||||
By default, Prowler scans only actively used cloud services (services with resources deployed). This reduces unnecessary findings in reports. To include unused services in the scan, use the following command:
|
||||
|
||||
```console
|
||||
prowler <provider> --scan-unused-services
|
||||
```
|
||||
|
||||
## Services that are ignored
|
||||
## Services Ignored
|
||||
|
||||
### AWS
|
||||
#### ACM
|
||||
You can have certificates in ACM that are not in use by any AWS resource.
|
||||
Prowler will check if every certificate is going to expire soon, if this certificate is not in use by default it is not going to be check if it is expired, is going to expire soon or it is good.
|
||||
|
||||
#### ACM (AWS Certificate Manager)
|
||||
|
||||
Certificates stored in ACM without active usage in AWS resources are excluded. By default, Prowler only scans actively used certificates. Unused certificates will not be checked if they are expired, if their expiring date is near or if they are good.
|
||||
|
||||
- `acm_certificates_expiration_check`
|
||||
|
||||
#### Athena
|
||||
When you create an AWS Account, Athena will create a default primary workgroup for you.
|
||||
Prowler will check if that workgroup is enabled and if it is being used by checking if there were queries in the last 45 days.
|
||||
If not, the findings of the following checks will not appear:
|
||||
|
||||
- `athena_workgroup_encryption`
|
||||
- `athena_workgroup_enforce_configuration`
|
||||
Upon AWS account creation, Athena provisions a default primary workgroup for the user. Prowler verifies if this workgroup is enabled and used by checking for queries within the last 45 days. If Athena is unused, findings related to its checks will not appear.
|
||||
|
||||
#### CloudTrail
|
||||
AWS CloudTrail should have at least one trail with a data event to record all S3 object-level API operations, Prowler will check first if there are S3 buckets in your account before alerting this issue.
|
||||
- `athena_workgroup_encryption`
|
||||
- `athena_workgroup_enforce_configuration`
|
||||
|
||||
- `cloudtrail_s3_dataevents_read_enabled`
|
||||
- `cloudtrail_s3_dataevents_write_enabled`
|
||||
#### AWS CloudTrail
|
||||
|
||||
#### EC2
|
||||
If EBS default encyption is not enabled, sensitive information at rest is not protected in EC2. But Prowler will only create a finding if there are EBS Volumes where this default configuration could be enforced by default.
|
||||
AWS CloudTrail should have at least one trail with a data event to record all S3 object-level API operations. Before flagging this issue, Prowler verifies if S3 buckets exist in the account.
|
||||
|
||||
- `ec2_ebs_default_encryption`
|
||||
- `cloudtrail_s3_dataevents_read_enabled`
|
||||
- `cloudtrail_s3_dataevents_write_enabled`
|
||||
|
||||
If your Security groups are not properly configured the attack surface is increased, nonetheless, Prowler will detect those security groups that are being used (they are attached) to only notify those that are being used. This logic applies to the 15 checks related to open ports in security groups, the check for the default security group and for the security groups that allow ingress and egress traffic.
|
||||
#### AWS Elastic Compute Cloud (EC2)
|
||||
|
||||
- `ec2_securitygroup_allow_ingress_from_internet_to_port_X` (15 checks)
|
||||
- `ec2_securitygroup_default_restrict_traffic`
|
||||
- `ec2_securitygroup_allow_wide_open_public_ipv4`
|
||||
If Amazon Elastic Block Store (EBS) default encyption is not enabled, sensitive data at rest will remain unprotected in EC2. However, Prowler will only generate a finding if EBS volumes exist where default encryption could be enforced.
|
||||
|
||||
Prowler will also check for used Network ACLs to only alerts those with open ports that are being used.
|
||||
- `ec2_ebs_default_encryption`
|
||||
|
||||
- `ec2_networkacl_allow_ingress_X_port` (3 checks)
|
||||
**Security Groups**: Misconfigured security groups increase the attack surface.
|
||||
|
||||
Prowler scans only attached security groups to report vulnerabilities in actively used configurations. Applies to:
|
||||
|
||||
#### Glue
|
||||
It is a best practice to encrypt both metadata and connection passwords in AWS Glue Data Catalogs, however, Prowler will detect if the service is in use by checking if there are any Data Catalog tables.
|
||||
- 15 security group-related checks, including open ports and ingress/egress traffic rules.
|
||||
|
||||
- `glue_data_catalogs_connection_passwords_encryption_enabled`
|
||||
- `glue_data_catalogs_metadata_encryption_enabled`
|
||||
- `ec2_securitygroup_allow_ingress_from_internet_to_port_X`
|
||||
- `ec2_securitygroup_default_restrict_traffic`
|
||||
- `ec2_securitygroup_allow_wide_open_public_ipv4`
|
||||
|
||||
#### Inspector
|
||||
Amazon Inspector is a vulnerability discovery service that automates continuous scanning for security vulnerabilities within your Amazon EC2, Amazon ECR, and AWS Lambda environments. Prowler recommends to enable it and resolve all the Inspector's findings. Ignoring the unused services, Prowler will only notify you if there are any Lambda functions, EC2 instances or ECR repositories in the region where Amazon inspector should be enabled.
|
||||
- 3 network ACL-related checks, ensuring only active ACLs with open ports are flagged.
|
||||
|
||||
- `inspector2_is_enabled`
|
||||
- `ec2_networkacl_allow_ingress_X_port`
|
||||
|
||||
#### Macie
|
||||
Amazon Macie is a security service that uses machine learning to automatically discover, classify and protect sensitive data in S3 buckets. Prowler will only create a finding when Macie is not enabled if there are S3 buckets in your account.
|
||||
#### AWS Glue
|
||||
|
||||
- `macie_is_enabled`
|
||||
AWS Glue best practices recommend encrypting metadata and connection passwords in Data Catalogs.
|
||||
|
||||
Prowler verifies service usage by checking for existing Data Catalog tables before applying findings.
|
||||
|
||||
- `glue_data_catalogs_connection_passwords_encryption_enabled`
|
||||
- `glue_data_catalogs_metadata_encryption_enabled`
|
||||
|
||||
#### Amazon Inspector
|
||||
|
||||
Amazon Inspector is a vulnerability discovery service that automates continuous security scans for Amazon EC2, Amazon ECR, and AWS Lambda environments. Prowler recommends enabling Amazon Inspector and addressing all findings. By default, Prowler only triggers alerts if there are Lambda functions, EC2 instances, or ECR repositories in the region where Amazon Inspector should be enabled.
|
||||
|
||||
- `inspector2_is_enabled`
|
||||
|
||||
#### Amazon Macie
|
||||
|
||||
Amazon Macie leverages machine learning to automatically discover, classify, and protect sensitive data in S3 buckets. Prowler only generates findings if Macie is disabled and there are S3 buckets in the AWS account.
|
||||
|
||||
- `macie_is_enabled`
|
||||
|
||||
#### Network Firewall
|
||||
Without a network firewall, it can be difficult to monitor and control traffic within the VPC. However, Prowler will only alert you for those VPCs that are in use, in other words, only the VPCs where you have ENIs (network interfaces).
|
||||
|
||||
- `networkfirewall_in_all_vpc`
|
||||
A network firewall is essential for monitoring and controlling traffic within a Virtual Private Cloud (VPC). Prowler only alerts for VPCs in use, specifically those containing ENIs (Elastic Network Interfaces).
|
||||
|
||||
#### S3
|
||||
You should enable Public Access Block at the account level to prevent the exposure of your data stored in S3. Prowler though will only check this block configuration if you have S3 buckets in your AWS account.
|
||||
- `networkfirewall_in_all_vpc`
|
||||
|
||||
- `s3_account_level_public_access_blocks`
|
||||
#### Amazon S3
|
||||
|
||||
#### VPC
|
||||
VPC Flow Logs provide visibility into network traffic that traverses the VPC and can be used to detect anomalous traffic or insight during security workflows. Nevertheless, Prowler will only check if the Flow Logs are enabled for those VPCs that are in use, in other words, only the VPCs where you have ENIs (network interfaces).
|
||||
To prevent unintended data exposure:
|
||||
|
||||
- `vpc_flow_logs_enabled`
|
||||
Public Access Block should be enabled at the account level. Prowler only checks this setting if S3 buckets exist in the account.
|
||||
|
||||
VPC subnets must not have public IP addresses by default to prevent the exposure of your resources to the internet. Prowler will only check this configuration for those VPCs that are in use, in other words, only the VPCs where you have ENIs (network interfaces).
|
||||
- `s3_account_level_public_access_blocks`
|
||||
|
||||
- `vpc_subnet_no_public_ip_by_default`
|
||||
#### Virtual Private Cloud (VPC)
|
||||
|
||||
VPCs should have separate private and public subnets to prevent the exposure of your resources to the internet. Prowler will only check this configuration for those VPCs that are in use, in other words, only the VPCs where you have ENIs (network interfaces).
|
||||
VPC settings directly impact network security and availability.
|
||||
|
||||
- `vpc_subnet_separate_private_public`
|
||||
- VPC Flow Logs: Provide visibility into network traffic for security monitoring. Prowler only checks if Flow Logs are enabled for VPCs in use, i.e., those with active ENIs.
|
||||
|
||||
VPCs should have subnets in different availability zones to prevent a single point of failure. Prowler will only check this configuration for those VPCs that are in use, in other words, only the VPCs where you have ENIs (network interfaces).
|
||||
- `vpc_flow_logs_enabled`
|
||||
|
||||
- `vpc_subnet_different_az`
|
||||
- VPC Subnet Public IP Restrictions: Prevent unintended exposure of resources to the internet. Prowler only checks this configuration for VPCs in use, i.e., those with active ENIs.
|
||||
|
||||
- `vpc_subnet_no_public_ip_by_default`
|
||||
|
||||
- Separate Private and Public Subnets: Best practice to avoid exposure risks. Prowler only checks this configuration for VPCs in use, i.e., those with active ENIs.
|
||||
|
||||
- `vpc_subnet_separate_private_public`
|
||||
|
||||
- Multi-AZ Subnet Distribution: VPCs should have subnets in different availability zones to prevent a single point of failure. Prowler only checks this configuration for VPCs in use, i.e., those with active ENIs.
|
||||
|
||||
- `vpc_subnet_different_az`
|
||||
|
||||
Reference in New Issue
Block a user