DEV Community: Carlos

Network ACL vs Security Groups

Carlos — Tue, 13 Feb 2024 12:20:01 +0000

Hi net!

In my day-to-day, AWS represents over 90% of the time I spend working. That's why there are concepts that I have deeply internalized but I believe many people are unaware of or not entirely clear on, especially those who don't use the cloud on a daily basis.
AWS cloud infrastructure, security is paramount to safeguarding users' resources and data. Two primary tools for managing security in AWS are Security Groups and Network ACLs (Access Control Lists). While both serve a similar function in controlling inbound and outbound traffic, there are fundamental differences in their operation and applications. In this article, we will explore the key differences between Security Groups and Network ACLs.

Now, let's delve into a detailed table to analysis of each of these AWS cloud security components.

Feature	Security Groups	Network ACLs
Location	Associated with ENIs	Associated with subnets
OSI Layer Level	Layer 4 (Stateful firewall)	Layer 3 (Rule-based firewall)
Control Rules	Based on allow rules	Based on allow or deny rules
Connection State	Controls both inbound and outbound traffic	Controls both inbound and outbound traffic
Implicit Rules	None	Implicit rules allow all traffic
Rule Priority	Unspecified priority	Rules are evaluated sequentially
Number of Rules	Up to 60 rules per group	Up to 20 rules per list
Rules by IP Address	Yes (can filter by IP address)	Yes (can filter by IP address)
Rules by Protocol and Port	Yes (can specify protocols and ports)	Yes (can specify protocols and ports)
Network Impact	More secure as rules can be specific to individual instances	Less secure as they apply to all instances in the subnet
Common Use Cases	Specific applications, microsegmentation	Filtering traffic across the entire subnet

Security Groups: Security Groups are security rules associated with individual instances in a network. They operate at Layer 4 (transport layer) and are stateful firewalls, meaning they keep track of the connection state. They can allow or deny traffic based on specific rules, such as protocol, port, and IP address. Security Groups provide a high level of security and allow for precise microsegmentation, making them ideal for specific applications.

Network ACLs: Network ACLs are security rules applied at Layer 3 (network layer) and are associated with subnets rather than individual instances. They operate based on allow or deny rules and are applied sequentially. Network ACLs are less secure than Security Groups because they affect all instances in a subnet. They are useful for filtering traffic across the entire subnet but do not allow for as precise segmentation as Security Groups.

In summary, the primary difference lies in the network layer they operate at, the granularity of rules, and the location to which they are applied. Security Groups are ideal when a high level of security and instance-level control is needed, while Network ACLs are useful for applying rules at the subnet level and filtering traffic on that scale.

I hope this article has provided clarity and differentiated the usage of these two crucial components in AWS cloud security. It's important to note that while Security Groups and Network ACLs have their distinct roles, they are complementary in creating comprehensive security strategies within the AWS environment.

For audit or consultancy needs, feel free to reach out to me for assistance with your infrastructure.

Happy Hacking
Bye!

Sync Repos beetwen Github & Gitlab

Carlos — Mon, 17 Apr 2023 18:21:56 +0000

I'm been using Gitlab since January 17, 2016 and I'm very happy with this tool for years was my main repository of code. But now I have some of repositories in Github and I want to sync them with Gitlab, because I want that Gitlab to be a source of truth

I research a little bit and I found this repo that show me how I can do it.

First, we need to look at process of sync:

We need to start creating workflow file into your repo in Github, you can find the file in this link

name: GitlabSync

on:
  - push
  - delete

jobs:
  sync:
    runs-on: ubuntu-latest
    name: Git Repo Sync
    steps:
    - uses: actions/checkout@v3
      with:
        fetch-depth: 0
    - uses: wangchucheng/git-repo-sync@v0.1.0
      with:
        # Such as https://github.com/wangchucheng/git-repo-sync.git
        target-url: ${{ secrets.TARGET_URL }}
        # Such as wangchucheng
        target-username: ${{ secrets.TARGET_USERNAME }}
          # You can store token in your project's 'Setting > Secrets' and reference the name here. Such as ${{ secrets.ACCESS\_TOKEN }}
        target-token: ${{ secrets.TARGET_TOKEN }}

As you can see we need to create 3 secrets to use this workflow:

TARGET_URL => https://gitlab.com/username/test.git
TARGET_USERNAME => your username in Gitlab
TARGET_TOKEN => Access token of your repo settings in Gitlab

Once you create the Token into Gitlab you need to add secrets into Github repository. To do these you need to go to Settings > Secrets and add the secrets.

These not it's the best way to do it, but it's a good way to start and simple way to do it and little maintenance.

Proof Keyoxide Dev.to

Carlos — Wed, 21 Oct 2020 13:43:52 +0000

This is an OpenPGP proof that connects my OpenPGP key to this dev.to account. For details check out https://keyoxide.org/guides/openpgp-proofs

[Verifying my OpenPGP key: openpgp4fpr:694B7227D97974AD8345EBA53C9ABB5CFEBFED5D]

Hugo Submodules

Carlos — Sun, 27 Sep 2020 16:50:41 +0000

Hello!!

This blog it's made with Hugo, and today I'm going to give you some tips for sync content and git project across different machines.

It's important know that when you pull your repo the submodules not pull with it. If you want to pull all include submodules you need to type this:

git clone --recursive url

If you have already cloned a repository and want to load it's submodules you need to type this:

git submodule update --init

Here I'm give you some links to explore and understading the submodules on git.

Hello New World

Carlos — Fri, 21 Aug 2020 11:19:12 +0000

Hello! This is my first post in Hugo. In the past, I had a blog in the same domain that used WordPress and it had some posts that I don't want to migrate here because it's a good opportunity to start a new blog.

I choose Hugo because I don't want to maintain WordPress and I don't want to do an update every week. I don't feel comfortable right now with WordPress. I prefer the freedom of Hugo and I can practice the new cloud methodology that I learned in the last months.

In this new stage, I will try to write posts in English, (don't forget that my native language it's Spanish) , and I will try that the topic is going related to cloud and networking.

Thanks for reading me and we'll see you in the next post.