将EC2安全组源从0.0.0.0/0恢复为172.16.0.0/16,用于SSH和RDP的协议/端口。

huangapple go评论64阅读模式
英文:

Revert the EC2 security group source 0.0.0.0/0 to 172.16.0.0/16 for the protocols/ports of SSH and RDP

问题

当有人打开SSH和RDP的端口/协议的0.0.0.0/0时,它应该自动恢复为172.16.0.0/16并附带通知。

我在这里尝试的是,对于SSH和RDP,SG不应该对0.0.0.0/0开放。

即使有人这样做,它也应该恢复为内部网络172.16.0.0/0,并附带通知。请建议一种实现这一目标的方法。

英文:

When someone opens 0.0.0.0/0 for the ports/protocols of SSH and RDP,
it should automatically revert back to 172.16.0.0/16 with a Notification..

What I am trying to do here is, for SSH and RDP the SG shouldn't be opened for 0.0.0.0/0..

Even is someone does it, it should be reverted back to internal network 172.16.0.0/0 with a Notification.
Please suggest a way to implement this.

答案1

得分: 1

我建议使用AWS Config(https://aws.amazon.com/config/)服务来实现这个。AWS Config允许您创建审核规则,这些规则将被检查。如果违反了规则,它将自动生成SNS通知,您可以使用它来触发一个Lambda函数来纠正错误(或类似的操作)。

检查安全组中特定IP地址的规则是默认规则选项的一部分,因此无需自己创建。

*编辑:*您可以使用“AWS-DisablePublicAccessForSecurityGroup”补救操作来实现自动修复。这应该能够满足您的需求。

英文:

I would suggest using the AWS Config (https://aws.amazon.com/config/) service for this. AWS Config allows you to create audit rules which will be checked. It will automatically generate SNS notification if a rules is violated, which you could use to trigger a lambda to correct the mistake (or something like that).

Rules which check for specific IP-addresses in a SG are part of the default rule options, so there's no need to create any yourself.

Edit: You can use auto-remediation with the 'AWS-DisablePublicAccessForSecurityGroup' remediation action. This should allow you to achieve what you want

答案2

得分: 0

没有人可以修改安全组,除非他们已被授予权限这样做,所以正确的解决方案是不要将此权限授予不应该拥有它的用户。在AWS中,您不授予的权限默认都被拒绝。

简单地恢复不安全的配置更改并不足够,这取决于时间。

TCP的安全组规则控制允许最初创建哪些连接,而不是允许保持哪些连接。

  • 如果我将规则更改为允许0.0.0.0/0;然后
  • 我从一个您意外允许的地址(例如203.0.113.1)建立连接;然后
  • 您移除规则或恢复允许0.0.0.0/0的更改

...您的更改不会使我的连接断开。如果我在规则生效的情况下建立了连接,那么即使根据您的安全组设置现在说的,我仍然可以保持与不再经过授权的地址203.0.113.1的连接,直到我断开连接或超时。

请确保您没有解决错误的问题。

英文:

Nobody can modify security groups without having been given permission to do so, so the correct solution is that you don't give this permission to users who shouldn't have it. Everything in AWS that you don't grant is denied by default.

Simply reverting an insecure configuration change like this is not sufficient, depending on timing.

Security group rules for TCP control what connections are allowed to be initially created -- not what connections are allowed to stand. If...

  • I change the rule to one that allows 0.0.0.0/0; then
  • I establish a connection from an unintentially (to you) allowed (by me) address (e.g. 203.0.113.1); then
  • you remove the rule or revert the change that allows 0.0.0.0/0

...your change does not disconnect me. If I connected while the rule was in place, then I can remain connected from the no-longer-authorized address 203.0.113.1 until I disconnect or time out despite what your security group setting now say.

Be sure you are not solving the wrong problem.

huangapple
  • 本文由 发表于 2020年1月3日 18:19:26
  • 转载请务必保留本文链接:https://go.coder-hub.com/59576793.html
匿名

发表评论

匿名网友

:?: :razz: :sad: :evil: :!: :smile: :oops: :grin: :eek: :shock: :???: :cool: :lol: :mad: :twisted: :roll: :wink: :idea: :arrow: :neutral: :cry: :mrgreen:

确定