4 posts tagged with "ec2"

If you've ever worked with AWS EC2 instances, you know that keeping your instance secure is crucial. One way to do this is by managing your firewall, and in this blog post, well go over how to configure UFW (Uncomplicated Firewall) on your EC2 instance to allow specific ports—like SSH (port 22), MySQL (port 3306), and HTTP (port 80)—so you can connect to your instance and run services smoothly.

Why Use UFW?#

On Ubuntu and other Debian-based systems, UFW is a straightforward command-line interface for controlling firewall rules. Because it is easy to set up and still provides a high degree of security, it is ideal for EC2 instances. Allowing the traffic you require while keeping unnecessary ports open to the internet is the aim here.

Prerequisites#

Before diving in, make sure:

• Your EC2 instance is running Ubuntu or another Debian-based Linux distribution.
• You have SSH access to the instance.
• UFW is installed (well check and install it if necessary).

Step-by-Step Guide to Open Ports#

1. Check if UFW is Installed#

First, let's check if UFW is installed on your EC2 instance. Connect to your EC2 instance and run:

If UFW is not installed, the command will return:

In that case, install it with:

2. Allow Specific Ports#

Now, let's open the ports you need:

These commands let traffic through on the specified ports, ensuring smooth access to your instance.

3. Enable UFW#

If UFW is not already enabled, activate it by running:

To verify, check the status:

You should see:

4. Optional: Restrict Access to Specific IPs#

You may want to restrict access to particular IPs for extra security. For instance, to only permit SSH from your IP:

You can do the same for MySQL and HTTP:

This adds an extra layer of security by preventing unwanted access.

5. Verify Your Firewall Rules#

Run the following command to check active rules:

This confirms which ports are open and from which IPs they can be accessed.

Troubleshooting Common Issues#

Can't Connect via SSH?#

If you cant connect to your EC2 instance via SSH after enabling UFW, make sure port 22 is open:

Also, check your AWS Security Group settings and ensure SSH is allowed. You can review AWS security group rules here.

Can't Connect to MySQL?#

Ensure port 3306 is open and verify that your database allows remote connections.

Web Traffic Not Reaching the Instance?#

Check if port 80 is open and confirm that your EC2 security group allows inbound HTTP traffic.

Conclusion#

You now know how to use UFW to open particular ports on your EC2 instance, enabling HTTP, MySQL, and SSH communication while restricting access to unwanted ports. This keeps your server safe while guaranteeing that critical services run correctly.

Related Reads#

Want to dive deeper into AWS and cloud automation? Check out these blogs:

Automating Deployment and Scaling in Cloud Environments like AWS and GCP
Learn how to streamline your deployment processes and scale efficiently across cloud platforms like AWS and GCP.

Unleash the Power of AWS DevOps Tools to Supercharge Software Delivery
Explore the tools AWS offers to enhance your software delivery pipeline, improving efficiency and reliability.

Step-by-Step Guide to Multi-Cloud Automation with SkyPilot on AWS Step-by-Step Guide to Multi-Cloud Automation with SkyPilot on AWs

Have you ever been trying to do anything on AWS and been baffled by an error message that leaves you baffled? Often, the dreaded "not authorised to perform" error is the culprit. Usually, this occurs when a position or user lacks the authorisation needed to carry out a certain task. Have you ever witnessed anything similar to:

You're not alone, so don't worry! We'll explore the meaning of this error, its causes, and—above all—how to resolve it in this piece.

What's Happening Here?#

The problem message is rather simple: The role or user you are working with does not possess the necessary authorisation to establish a new IAM role. The issue indicates that there is no policy associated with the user or role that permits the action iam:CreateRole, which is strictly restricted.

One of AWS's most effective tools for managing access to AWS resources is Identity and Access Management (IAM). However, great power also comes with great responsibility, and if you're not cautious, controlling permissions can get a little complicated. There is obviously a missing component in your AWS setup, as shown by the error message you are viewing.

When Do You Run Into This Issue?#

You'll typically run into the "not authorized to perform iam:CreateRole" issue in the following scenarios:

Creating a New IAM Role for a Service or User#

Creating a new role could be necessary when configuring an AWS service (such as AWS CodeBuild, AWS Lambda, or Amazon EC2) that needs a particular IAM role for rights. This error occurs when a person or service tries to create that role without having the iam:CreateRole permissions.

Example: Trying to set up a CodeBuild project that requires a service role, but the user doesn't have permission to create that role.

Setting Up Automation or CI/CD Pipelines#

IAM roles may need to be created dynamically if you're automating infrastructure provisioning with a CI/CD pipeline (like Terraform or AWS CodePipeline). This error may occur if the pipeline's IAM role lacks the iam:CreateRole authorisation.

Example: Using a script that triggers AWS CloudFormation to create new resources but fails to create a role because the IAM role executing the script doesn't have iam:CreateRole.

Assigning or Modifying Service Roles#

If the user is unable to establish roles in IAM, a permission error may occur when you attempt to assign an existing role to the service or create a new role while working with services that must assume certain IAM roles, like AWS Lambda or Amazon ECS.

Example: Assigning a service role to a new EC2 instance but the user trying to do this doesn't have the iam:CreateRole permission.

Permissions Related to Infrastructure as Code (IaC) Tools#

IAM role generation is managed by a number of infrastructure tools, such as Terraform, CloudFormation, or AWS CDK. This error will appear if you use any of these tools to generate resources that need new IAM roles and the user isn't authorised to create roles.

Example: Running a terraform apply command that tries to create new IAM roles as part of an infrastructure change, but the user running the command doesn't have permission to create roles.

Cross-Account Role Creation#

You may attempt to create roles in one AWS account from another if you're dealing with multiple accounts (for instance, creating a cross-account role). The iam:CreateRole operation will be rejected if the second account's IAM user lacks the authority to create roles in the first account.

Example: Trying to create a role in Account A using a user from Account B, but the user doesn't have cross-account permissions to create roles in Account A.

The Fix: Adding the Right Permission#

To solve this, you'll need to make sure the user or role has the correct permissions attached to it. Here's how:

Locate the Role or User#

First, figure out which role or user is running into the issue. In this case, it's arn:aws:sts::123456789012:assumed-role/role-name/username. You can find this in your IAM dashboard on the AWS console.

Check the Policies#

Next, take a look at the IAM policies attached to that role or user. Policies define what actions are allowed or denied. In this case, you need to ensure that the policy allows the iam:CreateRole action.

Update the Policy#

If the permission is missing, you'll need to add a new policy or update an existing one. Here's an example of what the policy might look like to allow creating roles:

This policy gives permission to create roles for the specified resource (in this case, some-role). You can apply this to the user or role in question.

Things to Keep in Mind#

If you're still having trouble after adding the right policy, there are a few other things to check:

• Permission Boundaries: Strict permission boundaries can occasionally restrict the actions of AWS users or roles.
• Service Control Policies (SCPs): Check for SCPs that prevent iam:CreateRole from being used.
• Session Policies: Ensure no restrictive session policies are blocking the action.

Conclusion#

Managing IAM permissions in AWS can be tricky, but by following best practices, troubleshooting errors like iam:CreateRole becomes easier. Grant the least privilege necessary, use roles over users, and keep policies up to date.

Integrate Your Cluster & Deploy Applications Easily. Learn how to connect your cluster with Nife and deploy applications effortlessly.

Explore Nife.io. Discover how Nife simplifies cloud deployments.

Related Reads#

Want to dive deeper into AWS and cloud automation? Check out these blogs:

Automating Deployment and Scaling in Cloud Environments like AWS and GCP
Learn how to streamline your deployment processes and scale efficiently across cloud platforms like AWS and GCP.

Unleash the Power of AWS DevOps Tools to Supercharge Software Delivery
Explore the tools AWS offers to enhance your software delivery pipeline, improving efficiency and reliability.

Step-by-Step Guide to Multi-Cloud Automation with SkyPilot on AWS Step-by-Step Guide to Multi-Cloud Automation with SkyPilot on AWs

When it comes to administering cloud servers, there's nothing quite like trying to SSH into your EC2 instance and receiving the dreaded Connection rejected message. Prepare to panic! But take a deep breath—we've all been there, and the solution is frequently simpler than it appears. Let's troubleshoot this problem together, keeping it light but technical.

Why is My EC2 Ignoring Me?#

Before we get into the answer, let's quickly explore why your instance may be giving you the silent treatment:

• It's Alive... Right?
  • Perhaps the instance is turned off or failing its status checks. There is no machine and therefore no connection.

• Locked Door: Security Group Issues
  • Your security group ((EC2's way of saying firewall rules))[https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-security-groups.html] might not be letting you in.

• The Wrong Address
  • If you do not have an Elastic IP attached, your public IP address may vary. Are you knocking on the wrong door?

• Software Drama
  • SSH service might not be running, or the instance's firewall (hello, iptables) could be blocking port 22.

• Hardware Drama
  • Rare, but hardware issues or improper disk configurations can lead to this. Did you edit /etc/fstab recently?

Let's Fix It! (Step-by-Step)#

Step 1: Breathe.#

You're not locked out indefinitely. AWS gives us plenty of tools to recover access.

Step 2: Check if the Instance is Running#

Log into the AWS Management Console and head to the EC2 Dashboard:

• Is your instance in the Running state?
• Are the status checks green? If they're red, AWS may already be indicating a hardware or configuration issue.

Step 3: Review Security Group Rules#

Imagine going up to a party with the wrong invitation. Security groups are your EC2's bouncers, deciding who gets in.

• Go to Security Groups in the AWS Console.

Make sure there's an inbound rule allowing SSH (port 22) from your IP:

Type: SSH
Protocol: TCP
Port Range: 22
Source: Your IP (or 0.0.0.0/0 for testing—just don't leave it open forever!)

Step 4: Confirm the Public IP or DNS#

Every instance has an address, but it may vary unless you've configured an Elastic IP. Make sure you're using the right public IP/DNS name.

Run the SSH command:

Step 5: Test Your Key and Permissions#

Your private key file (.pem) is like a VIP pass. Without proper permissions, it won't work. Ensure it's secure:

Retry SSH.

Step 6: The Firewall's Watching Too#

Once inside the instance, check if the OS's internal firewall is behaving:

If you see rules blocking port 22, adjust them:

Step 7: Is SSH Even Running?#

If your EC2 is a house, the SSH daemon (sshd) is the butler answering the door. Make sure it's awake:

If it's not running:

But What if It's REALLY Bad?#

Sometimes the problem is deeper. Maybe you misconfigured /etc/fstab or the instance itself is inaccessible. Don't sweat it—AWS has your back: Use EC2 Instance Connect: A browser-based SSH client for emergencies. Attach the Volume to Another Instance: Detach the root volume, fix the configuration, and reattach it.

The Takeaway#

AWS EC2 instances are powerful, but they are not immune to minor issues. Whether it's a misconfigured firewall or a stopped SSH service, remedies are always available. And, hey, the next time Connection rejected appears, you'll know just how to convince your instance to open the door again. Enjoy cloud computing!

Related Reads#

Want to dive deeper into AWS and cloud automation? Check out these blogs:

Automating Deployment and Scaling in Cloud Environments like AWS and GCP
Learn how to streamline your deployment processes and scale efficiently across cloud platforms like AWS and GCP.

Unleash the Power of AWS DevOps Tools to Supercharge Software Delivery
Explore the tools AWS offers to enhance your software delivery pipeline, improving efficiency and reliability.

Step-by-Step Guide to Multi-Cloud Automation with SkyPilot on AWS Step-by-Step Guide to Multi-Cloud Automation with SkyPilot on AWs

You might eventually need to swap out an old Domain Controller (DC) for a new one when maintaining a network architecture. Decommissioning an outdated DC and installing a new one with DNS capability may be part of this procedure. The procedure is simple for those using AWS EC2 instances for this purpose, but it needs to be carefully planned and carried out. A high-level method to successfully managing this shift can be found below.

1. Install the New Domain Controller (DC) on a New EC2 Instance#

In order to host your new Domain Controller, you must first establish a new EC2 instance.

• EC2 Instance Setup: Begin by starting a fresh Windows Server-based EC2 instance. For ease of communication, make sure this instance is within the same VPC or subnet as your present DC and is the right size for your organization's needs.

• Install Active Directory Domain Services (AD DS): Use the Server Manager to install the AD DS role after starting the instance.

• Promote to Domain Controller: After the server has been promoted to a Domain Controller, the AD DS role must be installed. You will have the opportunity to install the DNS server as part of this promotion procedure. In order to manage the resolution of your domain name, this is essential.

2. Replicate Data from the Old DC to the New DC#

Making ensuring all of the data from the old DC is copied onto the new server is the next step once the new DC is promoted.

• Enable Replication: Active Directory will automatically replicate the directory objects, such as users, machines, and security policies, while the new Domain Controller is being set up. If DNS is set up on the old server, this will also include DNS records.

• Verify Replication: Ascertain whether replication was successful. Repadmin and dcdiag, two built-in Windows utilities, can be used to monitor and confirm that the data has been fully synchronized between both controllers.

3. Verify the Health of the New DC#

Before decommissioning the old Domain Controller, it is imperative to make sure the new one is completely functional.

• Use dcdiag: This utility examines the domain controller's condition. It will confirm that the DC is operating as it should.

• To make sure no data or DNS entries are missing, use the repadmin utility to verify Active Directory replication between the new and old DCs.

4. Update DNS Settings#

You must update the DNS settings throughout your network after making sure the new DC is stable and replicating correctly.

• Update VPC/DHCP DNS Settings: If you're using DHCP, make sure that the new DC's IP address is pointed to by updating the DNS settings in your AWS VPC or any other DHCP servers. This enables clients on your network to resolve domain names using the new DNS server.

• Update Manually Assigned DNS: Make sure that any computers or programs that have manually set up DNS are updated to resolve DNS using the new Domain Controller's IP address.

5. Decommission the Old Domain Controller#

It is safe to start decommissioning the old DC when the new Domain Controller has been validated and DNS settings have been changed.

• Demote the Old Domain Controller: To demote the old server, use the dcpromo command. With this command, the server no longer serves as a Domain Controller in the network and is removed from the domain.

• Verify Decommissioning: After demotion, examine the AD structure and replication status to make sure the previous server is no longer operating as a DC.

6. Clean Up and DNS Updates#

With the old DC decommissioned, there are some final cleanup tasks to ensure smooth operation.

• Tidy Up DNS and AD: Delete from both DNS and Active Directory any last traces of the previous Domain Controller. DNS entries and metadata are examples of this.

• Verify Client DNS Settings: Verify that every client computer is correctly referring to the updated DNS server.

Assigning IP Addresses to the New EC2 Instance#

You must make sure that your new DC has a stable IP address because your previous DC was probably linked to a particular one.

• Elastic IP Assignment: The new EC2 instance can be given an elastic IP address, which will guarantee that it stays the same IP throughout reboots and session restarts. By doing this, DNS resolution and domain service interruptions are prevented.

• Update Routing if Needed: Verify that the new Elastic IP is accessible and correctly routed both inside your VPC and on any other networks that communicate with your domain.

  Additional Considerations#

• Networking Configuration: Ascertain that your EC2 instances are correctly networked within the same VPC and that the security groups are set up to permit the traffic required for AD DS and DNS functions.

• DNS Propagation: The time it takes for DNS to propagate may vary depending on the size of your network. Maintain network monitoring and confirm that all DNS modifications have been properly distributed to clients and external dependencies.

Conclusion#

You can completely decommission your old Domain Controller located on an EC2 instance and install a new one with a DNS server by following these instructions. This procedure permits the replacement or enhancement of your underlying hardware and software infrastructure while guaranteeing little downtime and preserving the integrity of your Active Directory system. Your new EC2 instance can be given a static Elastic IP address, which will guarantee DNS resolution stability even when the server restarts.

For further reading and detailed guidance, explore these resources:

• Amazon EC2 Documentation
• AWS VPC Documentation
• Configuring DHCP Options in AWS
• Elastic IP Addresses in Amazon EC2
• Dcdiag Command Reference
• Networking and Security Groups in AWS