29

Option 4 - stop controlling the access through Security Groups and instead implement some decent authentication mechanism. For example put an Application Load Balancer in front of the web app and configure the ALB to require Cognito authentication. Only authenticated users will make it through the ALB to your web app - problem solved. The Cognito can have ...


13

So you're setting up some cluster on AWS and need SSH access between the nodes, correct? You have 2 options: The naive one is to add each instance IP to the Security Group Inbound list - but that means you'll need to update the SG every time you add a new instance in the cluster. (If you ever do). Don't do this, I only mentioned it for completeness. Far ...


13

Your thoughts are essentially what I do, and I've had a lot of success in managing things that way in complicated environments. The solution to both of the question is that you create resource groups that are tied to the folders/shares. You don't delete the empty groups at all, the groups exist for as long as the folder or share exists, not for as long as ...


11

The way security works is not binary. Your instances are never "safe". There are hundreds/thousands of attack vectors, and you make a cost-benefit decisions to put defenses against some of these vectors. It's prohibitively expensive to be fully defended from all of them. In your situation, your system can have a vulnerability in any service/app ...


10

The 2 different classes are about different levels of abstraction. Client classes are low level wrappers around each API action. ie. AuthorizeSecurityGroupIngress Resource classes are object oriented, you instantiate an object to represent the group and interact with it that way. It provides a higher level of abstraction that decouples you from the ...


10

As Tim told in comment, UFW is the frontend to iptables, so you should really compare iptables capabilities with Amazon Security Groups. For me main SG advantage is integration to AWS infrastructure. It allows you to build entire stack using Amazon CloudFormation, get details about opened/closed ports/addresses via API etc. Disadvantages - it's vendor-...


9

AWS security groups is like a firewall for EC2 instance, and AFAIK (and tested) 2 machines within the same VPC cannot see ports in their internal network unless you change your security groups policy. e.g. EC2 www.abc.com with private IP 10.10.10.5/24 EC2 www.hello.com with private IP 10.10.10.6/24 They are in the same network, although, they cannot see ...


9

Allowing ICMP Echo Request as well in the security groups fixed it.


8

The change applies immediately, but security group rules control establisment of new traffic flows (identified by source and destination address, protocol, and port numbers for protocols that use port numbers). Depending on the specific rule in question, flows may or may not be actively tracked by the network, but ICMP flows are always tracked. Once a ...


8

Security is like an onion - its all about layers, stinky ogre-like layers. By allowing SSH connections from everywhere you've removed one layer of protection and are now depending solely on the SSH key, which is thought to be secure at this time, but in the future a flaw could be discovered reducing or removing that layer. And when there are no more layers, ...


7

I'm afraid that as soon as you go out to the Public IPs you no longer can use the Security Group ID as the Source in the target SG. That only works for Private IPs. However if you create the Instance 1 through Ansible you can then use the Ansible facts for the instance to obtain its Public IP and set it as a source in the Instance 2 SG. Something like this ...


6

If software was perfect you could leave your server completely open to the internet as you have, but in practice there are bugs and other ways to compromise a server. Best practice is to open specific ports to only the minimum IPs to achieve your goals. For example: Open up port 22 (SSH) to only the IPs that require it, such as your home or work IPs. Open ...


6

Option 5 - stop managing Security Groups (essentially IP-based firewalls) and use TLS Client Certificates. If you're using modern user management systems like Azure AD or LDAP, you already have the right tool to issue and distribute the certificates. You'll setup a private CA and configure the HTTP server (Nginx, Apache2 or AWS ALB) to authenticate by ...


5

iptables has various features that simply aren't available in EC2 security groups. So if you need certain features of iptables, there's your answer. There's no technical limitation to prevent you from running both. From a security perspective, it's as if you had a locked door, then another locked door, with both locks requiring the same key. It would ...


4

If you are using legacy password policies, those apply to the entire domain. You may want to research fine-grained password policies. (Note: Fine-grained password policies were originally introduced in Windows Server 2008.)


4

Here's a Powershell function you should be able to use. I only tested it on Windows 10, but I don't think it's using anything that wasn't available in Windows 7. Function Get-LocalGroupMembers { [Cmdletbinding()] Param( [Parameter(Mandatory=$true)] [string]$GroupName ) [adsi]$adsiGroup = "WinNT://$($env:COMPUTERNAME)/$GroupName,group" $...


4

It appears that the Security Groups are not transferred over when an AMI spins up. (This is logical and actually somewhat comforting.) So after initializing a new instance from an AMI, it is necessary to edit the Security Group to allow inbound http and https connections. A response in this article describes how.


4

It's always a good idea to setup iptables, especially if the rules do not change. The AWS firewall may give you the protection you need, but there is always a chance for a failure. There could be a service failure, or a configuration issue. It is better to have a second line of defense. With iptables you don't depend as much on the AWS firewall, and you ...


4

In the configuration for your security group you want to use to allow SSH between the instances: Go to the Inbound tab Click Edit Click Add Rule For Type select SSH For Source enter the Security Group ID Save Go to the Oubound tab Click Edit Click Add Rule For Type select SSH For Destination enter the Security Group ID Save


4

Requests from an instance's public IP address are not treated as if they are coming from the instance's Security Groups. That only works from requests using private IP addresses. I recommend that the source instance use a DNS address for the target instance that resolves to the target instance's private IP. For example: you create a CNAME record my-service....


4

Either: The Security Group is misconfigured and actually allows this traffic, or The Security Group attached to your instance is not the one you think it should be. Fix one or the other and the problem will go away. If you need more help with that update your question with a screenshot of the inbound rules of your SG and with a screenshot of your instance ...


3

When you say you "whitelisting that SG in other SGs" what exactly do you mean? I would simply create a single security group with these rules and assign that security group to all instances. An instance can have multiple security group, and rules are additive in a permissive sense. ie default deny, unless any rule in any security group allows access. You ...


3

You can setup a config file to attach existing security groups in .ebextensions FILE: ./.ebextensions/ec2-securitygroup.config option_settings: aws:autoscaling:launchconfiguration: SecurityGroups: name-of-security-group-1, name-of-security-group-2 NOTE: Do not use the Group Name or Group ID, its the Name field/column DOCS: https://docs.aws.amazon....


3

Typically you'd create a named security group, attach it to those instances, and add a rule which references this security group as a source and allow the needed destination ports. Final picture: All instances needed to communicate with each other have the created security group attached. The created security group contains rules which state inbound from ...


3

While it might be implied that AWS instances have security groups, in practice network interfaces have security groups. Each interface (provided with the instance or an ENI) can have its own security groups. Any security group can be applied to as many network interfaces as you need.


3

It's really a matter of the "defense in depth" concept. With public addresses, you're relying solely on the security group configuration to protect your servers -- that you've done it right, that no one accidentally modifies it, etc. You could turn the question around and ask yourself why you want public addresses when private ones will suffice?


3

The more restrictive you can be with your rules, the better. Worth noting, some home ISPs will use dynamic addresses, if you find yourself unable to connect to your instance at some point, check that first.


3

AWS config at $0.003 per change is a trivial cost. It is likely to cost you FAR more to do this any other way. If you really want to do it the hard way you can use the AWS ClI to export json, parse that using some custom written software, and add the parsed data to some kind of data store. A better way to approach this would be to define all your security ...


3

The need to log out is due to AD group memberships only updating when a Kerberos ticket is created, which occurs during login. You can refresh a computer's Kerberos ticket by running klist -li 0:0x3e7 purge on an elevated command line, followed by gpupdate /force if you need to update the group policy. Referece: http://woshub.com/how-to-refresh-ad-groups-...


2

No, but you can connect more than one security group to an instance. We create a security group for each employee with access, so an EC2 instance might have the Webserver, ChrisSSH, BobSSH, and JaneSSH SGs all assigned to it. Breaks down if you have hundreds of employees, but effective in small orgs.


Only top voted, non community-wiki answers of a minimum length are eligible