mlevit/aws-auto-remediate

Open source application to instantly remediate common security issues through the use of AWS Config

aws-auto-remediate's Issues

pytest workaround for hardcoded directories

Because of some hardcoded directories like the example below, pytests cannot be created for those functions.

https://github.com/servian/aws-auto-remediate/blob/32bc4a500943b01031086390c42b8bae416f6180/auto_remediate_setup/lambda_handler.py#L61

Need to understand the best way to handle these situations.

Prevent CloudFormation Stacks from being deployed if they're set to False in the Settings

Prevent CloudFormation Stacks from being deployed if they're set to False in the Settings

https://github.com/servian/aws-auto-remediate/blob/c1239a6bbf0e1c386970d2dcd4106cb77f6456b6/auto-remediate-setup/lambda_handler.py#L35-L40

---

This comment was generated by todo based on a TODO comment in c1239a6 in #1. cc @servian.

Originally posted by @todo in #1 (comment)

serverless plugin install --name serverless-python-requirements failed

Describe the bug
A clear and concise description of what the bug is.
serverless plugin install --name serverless-python-requirements failed with the following errors:

Fetch Error --------------------------------------------

FetchError: request to https://raw.githubusercontent.com/serverless/plugins/master/plugins.json failed, reason: getaddrinfo ENOTFOUND 8080 8080:80
at ClientRequest. (C:\Users\p1jxc01\AppData\Roaming\npm\node_modules\serverless\node_modules\node-fetch\index.js:133:11)
at ClientRequest.emit (events.js:198:13)
at ClientRequest.EventEmitter.emit (domain.js:448:20)
at onerror (C:\Users\p1jxc01\AppData\Roaming\npm\node_modules\serverless\node_modules\https-proxy-agent\node_modules\agent-base\src\index.ts:214:9)
at callbackError (C:\Users\p1jxc01\AppData\Roaming\npm\node_modules\serverless\node_modules\https-proxy-agent\node_modules\agent-base\src\index.ts:236:5)
at process._tickCallback (internal/process/next_tick.js:68:7)
From previous event:
at PluginInstall.install (C:\Users\p1jxc01\AppData\Roaming\npm\node_modules\serverless\lib\plugins\plugin\install\install.js:53:8)
From previous event:
at Object.plugin:install:install [as hook] (C:\Users\p1jxc01\AppData\Roaming\npm\node_modules\serverless\lib\plugins\plugin\install\install.js:41:12)
at BbPromise.reduce (C:\Users\p1jxc01\AppData\Roaming\npm\node_modules\serverless\lib\classes\PluginManager.js:490:55)
From previous event:
at PluginManager.invoke (C:\Users\p1jxc01\AppData\Roaming\npm\node_modules\serverless\lib\classes\PluginManager.js:490:22)
at getHooks.reduce.then (C:\Users\p1jxc01\AppData\Roaming\npm\node_modules\serverless\lib\classes\PluginManager.js:525:24)
From previous event:
at PluginManager.run (C:\Users\p1jxc01\AppData\Roaming\npm\node_modules\serverless\lib\classes\PluginManager.js:525:8)
at variables.populateService.then (C:\Users\p1jxc01\AppData\Roaming\npm\node_modules\serverless\lib\Serverless.js:133:33)
at runCallback (timers.js:705:18)
at tryOnImmediate (timers.js:676:5)
at processImmediate (timers.js:658:5)
at process.topLevelDomainCallback (domain.js:126:23)
From previous event:
at Serverless.run (C:\Users\p1jxc01\AppData\Roaming\npm\node_modules\serverless\lib\Serverless.js:120:74)
at serverless.init.then (C:\Users\p1jxc01\AppData\Roaming\npm\node_modules\serverless\bin\serverless.js:82:30)
at C:\Users\p1jxc01\AppData\Roaming\npm\node_modules\serverless\node_modules\graceful-fs\graceful-fs.js:136:16
at C:\Users\p1jxc01\AppData\Roaming\npm\node_modules\serverless\node_modules\graceful-fs\graceful-fs.js:57:14
at FSReqWrap.args [as oncomplete] (fs.js:140:20)
From previous event:
at initializeErrorReporter.then (C:\Users\p1jxc01\AppData\Roaming\npm\node_modules\serverless\bin\serverless.js:82:8)
at runCallback (timers.js:705:18)
at tryOnImmediate (timers.js:676:5)
at processImmediate (timers.js:658:5)
at process.topLevelDomainCallback (domain.js:126:23)
From previous event:
at Object. (C:\Users\p1jxc01\AppData\Roaming\npm\node_modules\serverless\bin\serverless.js:71:4)
at Module._compile (internal/modules/cjs/loader.js:776:30)
at Object.Module._extensions..js (internal/modules/cjs/loader.js:787:10)
at Module.load (internal/modules/cjs/loader.js:653:32)
at tryModuleLoad (internal/modules/cjs/loader.js:593:12)
at Function.Module._load (internal/modules/cjs/loader.js:585:3)
at Function.Module.runMain (internal/modules/cjs/loader.js:829:12)
at startup (internal/bootstrap/node.js:283:19)
at bootstrapNodeJSCore (internal/bootstrap/node.js:622:3)

Get Support --------------------------------------------
Docs: docs.serverless.com
Bugs: github.com/serverless/serverless/issues
Issues: forum.serverless.com

To Reproduce
Steps to reproduce the behavior:

1. Go to '...'
2. Click on '....'
3. Scroll down to '....'
4. See error

Expected behavior
A clear and concise description of what you expected to happen.

Screenshots
If applicable, add screenshots to help explain your problem.

Stacktrace
If applicable, add stacktraces to help explain your problem.

Versions (please complete the following information):

• Serverless Framework: [e.g. 1.42.3]
• boto3: [e.g. 1.9.156]
• botocore: [e.g. 1.12.156]
• moto: [e.g. 1.3.8]
• pytest: [e.g. 4.4.1]

AWS (please complete the following information):

• Region: [e.g. ap-southeast-2]

Additional context
Add any other context about the problem here.

Proxy has been setup, can you help to fix it

Access Keys Rotated rule needs testing

https://github.com/servian/aws-auto-remediate/blob/eeef1b417417594a3b2d0af261991d19c9db949e/auto-remediate/config_rules.py#L13-L18

---

This issue was generated by todo based on a TODO comment in eeef1b4 when #1 was merged. cc @servian.

iam_user_no_policies_check does not cover all scenarios

As it currently stands the newly implemented pull request #26 for iam_user_no_policies_check remediation only removes IAM managed policies attached to the user however users can also have inline policies.

The current paginator used list_attached_user_policies will not capture inline policies which can only be captured using list_user_policies and deleted using delete_user_policy.

Prevent infinite loops from occurring

When a remediation fails and is sent to the DLQ, it will be resent to for remediate and the loop will continue.

To prevent this from happening a counter SQS message attribute needs to be added. Once that attribute reaches n the messages should no longer be sent to DLQ.

If Stack deployment has been set to False, delete stack

https://github.com/servian/aws-auto-remediate/blob/eeef1b417417594a3b2d0af261991d19c9db949e/auto-remediate-setup/lambda_handler.py#L49-L54

---

This issue was generated by todo based on a TODO comment in eeef1b4 when #1 was merged. cc @servian.

SNS logging seems to interfere with console logging

Extending the Python logging interface and allowing all logs to be pushed to an SNS Topic seems to sometimes cause the console logs to not show up. For now, SNS logging has been disabled inside the lambda_handler function within auto-remediate.

More investigation/testing needs to occur to understand the problem (if any).

Check if Stack deployment has been set to False

https://github.com/servian/aws-auto-remediate/blob/eeef1b417417594a3b2d0af261991d19c9db949e/auto-remediate-setup/lambda_handler.py#L35-L40

---

This issue was generated by todo based on a TODO comment in eeef1b4 when #1 was merged. cc @servian.

Add s3-bucket-public-write-prohibited support

https://docs.aws.amazon.com/config/latest/developerguide/s3-bucket-public-write-prohibited.html

Exception handling refactor

I think this gives a clue for how we should refactor the error handling - it should raise the NoSuchBucket exception (or whatever) directly and we should assert that that exception is raised and caught here.

That means we should have the try except in the lambda_handler remediate() function, I think

Originally posted by @jihygk in #30

More permissive license

Hi,

What are the chances of moving the project to a more permissive license structure like MIT? The current license is incompatible for use with some...let's say more "restrictive" organisations.

Thanks for your consideration,
Ian.

Refactor remediation function selection

I think this section is getting too messy. Can we try to refactor the core of this function (routing of the remediation based on rule name) like this

Class Remediate:
    def __init__ ...

        self.remediations = {
            "securityhub-restricted-rdp": self.security_hub.restricted_rdp,
            ...
        }

    def remediate(remediation_rule):
        return self.remediations.get(remediation_rule, rem_not_found_function)()

Originally posted by @jihygk in #20

Use exc_info kwarg for logging.log()

https://docs.python.org/3/library/logging.html#logging.Logger.debug

Instead of, for example,

https://github.com/servian/aws-auto-remediate/blob/b4ea0b0938d358b607716285b0ba641127d954ed/auto_remediate/lambda_handler.py#L163-L167

The following achieves the same:

self.logging.error( 
         f"Could not read DynamoDB table '{os.environ['SETTINGSTABLE']}'.",
         exc_info=True
     ) 

Check how many times this message was retried, if 3 times then stop sending to D...

https://github.com/servian/aws-auto-remediate/blob/eeef1b417417594a3b2d0af261991d19c9db949e/auto-remediate/lambda_handler.py#L87-L92

---

This issue was generated by todo based on a TODO comment in eeef1b4 when #1 was merged. cc @servian.

Use Boto3 paginator for list_users

There could be an issue in running client.list_users() for accounts with potentially a very large number of users. To ensure the function doesn't run out of memory, we can use Boto3's paginator:

paginator = iam.get_paginator('list_users')
for response in paginator.paginate():
    print(response)

Impact function: iam_user_unused_credentials_check

Use RDS client's paginators

https://boto3.amazonaws.com/v1/documentation/api/latest/reference/services/rds.html#RDS.Paginator.DescribeDBInstances

Use RDS client's paginators like we did with the user search.

Originally posted by @jihygk in #33

If Stack deployment has been set to False delete the Stack from CloudFormation

If Stack deployment has been set to False, delete stack

https://github.com/servian/aws-auto-remediate/blob/c1239a6bbf0e1c386970d2dcd4106cb77f6456b6/auto-remediate-setup/lambda_handler.py#L49-L54

---

This comment was generated by todo based on a TODO comment in c1239a6 in #1. cc @servian.

Originally posted by @todo in #1 (comment)

Add access-keys-rotated support

https://docs.aws.amazon.com/config/latest/developerguide/access-keys-rotated.html