DEV Community: YounesZn

The Speakeasy Door to Your Network - Port Knocking (2)

YounesZn — Thu, 09 Jan 2025 18:55:45 +0000

Introduction

In the first part of this series, we explored the fascinating technique of port knocking—a method to secure services by making them accessible only after a specific sequence of requests, and I mentioned some of the basic attacks and vulnerabilities of this technique. However, theory is just the beginning.

In this part, we’ll delve deeper into the practical side. We’ll discuss some real-world vulnerabilities of port knocking, including insights from a seasoned industry professional who implemented this technique and uncovered its limitations. Finally, we’ll deploy a fully functional port-knocking setup on AWS, transforming the concept into a working solution.

Knock, Knock… Who’s Exploiting?

Without much thought, the first approach that comes to mind when facing a port-knocking setup during a pentest is brute-forcing the sequence. Well, that’s exactly what I’d think of too.

From 1 to 65535, you can perform a scan of open ports in the network, but we will get a huge number of combinations to test, except if we can somehow exclude some ports and keep only a subset of ports.
This impractical and noisy attack can be mitigated by banning the attacker’s IP from accessing the network after a certain number of failed attempts within a specific time frame.

Moreover, if an attacker manages to send forged packets with random source network addresses, overwhelming the parser process and consuming excessive resources, this can lead to a DoS attack.

Not only that, but port knocking is also vulnerable to replay attacks, which occur when an attacker intercepts the knock sequence using a packet sniffer and replays the exact same sequence to the target server. If the port-knocking system doesn’t validate the freshness of the sequence (e.g., through timestamps or one-time sequences), the attacker could open the port and gain unauthorized access.
All of the above attacks can be mitigated, but let’s focus on the replay attack and explore how we can solve it and even detect it in the process.

I agree with you that port knocking seems very vulnerable, but in a defense-in-depth strategy, it’s another layer of security, because why make their job easy?

One-Time Knocking

There are several security approaches that can be implemented to mitigate the common vulnerabilities of port knocking. These mitigations ensure that while attackers may knock, they’ll never get the door to open. 🛡️

One-Time Passwords (OTPs) are effective in our case. We generate a series of n one-time passwords by repeatedly applying a cryptographic hash function, f(x), to the result of the previous step. Each password in the sequence is unique and can only be used once.

For instance, starting with an initial password p, we compute the cryptographic hash function f(x) repeatedly, as follows:

f(p) generates the first OTP.
f(f(p)) generates the second OTP.
This process continues, producing a chain of n passwords.

As a result, detection of attempted replay becomes easy. Simply maintain a list of previously used valid one-time passwords and when you receive an invalid one, compare it to this list. If it’s present, it means someone is attempting to replay a previous password. Congratulations, you’re now one step ahead of the attacker.

Limitations of Port Knocking: A Professional Perspective

Let’s get out of my localhost bubble and noob-level testing, I’m still figuring things out and probably missing some big points along the way.

After publishing the first part of this series, I was fortunate to hear from a seasoned DevOps engineer who shared his experience with port knocking in a real production environment. He pointed out exactly what I was missing and highlighted the real-world challenges of using port knocking. A huge thanks to him for taking the time to share his expertise. Now, I’d like to share those insights with you.

Reliability Issues : On certain platforms, particularly Windows, port knocking can be unreliable. Even when the user provides the correct sequence, connection issues may still occur, causing delays in accessing the system.
Lack of Configurability : In enterprise environments, users are often granted specific access levels, such as read-only or write-only permissions, with ACLs applied. With port knocking, once a user knows the sequence, they are granted full access without any control, posing a significant security risk, this unrestricted access also needs a robust mechanisms to trace and log user activities.

Exploring Alternatives

sshportal : simple, fun and transparent SSH (and telnet) bastion server
Teleport : The easiest and most secure way to access and protect all your infrastructure
the-bastion by OVH : Authentication, authorization, traceability and auditability for SSH accesses.

Infrastructure for Future Labs

You can find the GitHub repository for the infrastructure I’ve set up on AWS here :

Port Knocking Infra

This will serve as the base for the upcoming labs, where I’ll expand the setup, scale it, and implement new features.

The Speakeasy Door to Your Network - Port Knocking (1)

YounesZn — Thu, 09 Jan 2025 18:54:33 +0000

Introduction

It's undeniable that the only truly secure system is one that's powered off. But let me tell you, you might as well throw that system away, because from the birth of the internet, every system has been created for a purpose—and that purpose forces it to be exposed publicly and made available to external users, whether it’s for patching, transmitting data, or enhancing functionality. This exposure may be selective, or it may not be, because some systems must be accessible to anyone, from anywhere.

The dilemma that comes to mind now is: if anyone can access such systems, then where on earth is privacy and security?

Well, humans, being smart, standardized the terms authentication and authorization. These are the key concepts that safeguard our data, preventing unauthorized access and keeping it from being compromised. These concepts are primarily managed by the service or system itself, ensuring that before any access is granted, the user must authenticate in one way or another (passwords, two-factor authentication, security questions ...) .

It seems like a good approach, but sadly, it’s not that simple. Let's imagine a network with thousands of services, placing trust in devices that may not be secure by design to handle authentication is a significant risk.

Firewalls Are Life Savers

Here come Firewalls: Instead of allowing every user the possibility to access our network and authenticate, why not restrict access to only trusted users? By applying a set of rules on the first device accessible in the network, the firewall, we can selectively accept or deny connections based on criteria such as the source IP address, port numbers, and protocols used.
So, finally, we can say our infrastructure is now safer than ever.

However, never be naive, there are several attacks that attackers can use to bypass firewall rules. Once a rule authorizes a certain type of access, attackers can potentially exploit that opening, and—hoopla!—here's the initial foothold they’ve been waiting for.

So, the hero of our story is already defeated before the battle even begins, thanks, firewalls! -_-

Come on, firewalls aren’t that fragile! We can take advantage of the fact that they are often the first accessible devices in our network and cleverly play with firewall logic to build a more secure infrastructure.

For that, there are many innovative ways to implement logical solutions that guarantee a secure network. One of them is the Port Knocking method.

Port Knocking - The concept

Long story short, imagine an infrastructure where certain services are completely inaccessible to everyone—except the users we choose to authorize. To gain access, these users must demonstrate a specific behavior or follow a unique pattern that we can detect. So, we say, "Ah, that's our guy—let them in!".

In general, the concept is to give the user we want to authorize a secret series of steps to execute in order to gain access to a service.

As an example, consider an infrastructure that includes an SSH server. The firewall blocks all access to the SSH server on port 22. However, if a user sends packets to a specific sequence of server ports—such as (1234, 5678, 3456) in our case—and in the exact order, it triggers actions on the firewall.

The firewall, which is always listening for such a sequence, then temporarily opens port 22 for a limited time. If no connection is made during that window, the port automatically closes again, maintaining security.

Inside the mind of an attacker, this security approach still has its weaknesses. All it takes is to sniff the secret sequence from the network and mimic it to gain access. Worse yet, imagine if the trusted user's IP address belongs to a shared resource, like a public WiFi hotspot. The external IP, which acts as the source address from the NAT provider, would need to be opened. At that point, any user of the hotspot could access the same service without needing to replay the sequence.

Stay tuned for the next part, where we’ll explore how to defend our port knocking logic with secure implementation techniques and a Go-based server as an example. You won't want to miss it!

Dev/prod parity : Spring Boot Testcontainers

YounesZn — Thu, 09 Jan 2025 18:47:57 +0000

Introduction

Dev/prod parity aims to reduce the gap between development and production environments. This article targets the tools gap, especially in integration testing with Spring Testcontainers, as a way to make development and production as similar as possible.
When conducting integration tests involving databases, we must manage all CRUD operations carefully. This is crucial in a centralized database environment where a Test, such as TestDeleteUserByID_ShouldReturnOk(), might ‘accidentally’ decide to wipe out the account of our most faithful client who’s been with us since 2015 🤦‍♂️
To mitigate such risks, we can consider solutions like database transactions to isolate test data. For example, a test could start a transaction to modify data and then roll back at the end, thereby leaving the database in its original state.
However, this raises a critical issue: WHAT TESTS THE TEST ?

What if the isolation fails and the code executes changes that are somehow not rolled back, leading to data leaks into the production environment? The potential damage in such scenarios is significant.

Alternatively, self-contained testing with an in-memory database like H2DB presents also some challenges. even if it's easy to set up, H2DB differs from RDBMS so there is a high probability that tests might have different results between development and production environments, so we can't trust those results.

https://stackoverflow.com/questions/62778900/syntax-error-h2-database-in-postgresql-compatibility

The next less problematic solution is to clone the database, providing a less risky approach with a production-like environment. However, this method comes with its limits. Given that ORMs automate the creation and setup of the production database schema, we need to think about how to keep the cloned development database in sync.

Test Anything You Can Containerize: Database, Message Broker, And More

"Testcontainers is a Java library that supports JUnit tests, providing lightweight, throwaway instances of common databases, Selenium web browsers, or anything else that can run in a Docker container."

Originally developed for Java, it has since been expanded to support other languages like Go, Rust, and .NET.

The main idea of Testcontainers is to provide an on-demand infrastructure, runnable from the IDE, where tests can be conducted without the need for mocking or using in-memory services, and with automatic cleanup.

We can achieve this in three steps :

Start the required services and prepare the infrastructure by setting up Docker containers and configure your application to use this setup as the testing infrastructure.
Run your tests on the dockerized infrastructure.
Automatically clean up the dockerized infrastructure once the tests have concluded

Testcontainers library documentation

Spring Boot Testcontainers Implementation

In ApplicationIntegrationTests, which is the base class for integration testing, we define a static PostgreSQLContainer. This container is used across all test instances derived from this class.

The @Testcontainers annotation enables the discovery of all fields annotated with @Container, managing their container lifecycle methods, and starting the containers.

Containers declared as static fields are shared between test methods. They are started only once before any test method is executed and stopped after the last test method has executed.
Containers declared as instance fields are started and stopped for every test method.

The @DynamicPropertySource annotation allows us to dynamically inject properties into our test environment.

@Testcontainers
@ActiveProfiles("test")
public abstract class ApplicationIntegrationTests {
    @Container
    protected static PostgreSQLContainer<?> postgres=new PostgreSQLContainer<>("postgres:17.2-alpine")
            .withDatabaseName("testcontainersproject")
            .withUsername("root")
            .withPassword("root");

    @DynamicPropertySource
    static void initialize(DynamicPropertyRegistry registry)
    {
        registry.add("spring.datasource.url",postgres::getJdbcUrl);
        registry.add("spring.datasource.username",postgres::getUsername);
        registry.add("spring.datasource.password",postgres::getPassword);
    }


}

Alternatively, we can skip the use of @Testcontainers and @Container and instead manage the container lifecycle directly using @BeforeAll and @AfterAll. This approach allows more control over when and how containers are started and stopped

@BeforeAll
public static void runContainer(){
        postgres.start();
}
@AfterAll
static void stopContainers() {
    postgres.stop();
}

In the @AfterAll callback method, we explicitly stop the Postgres container. However, even if we don't explicitly stop the container, Testcontainers will automatically clean up and shut down the containers at the end of the test run.

Now we can create integration tests by extending ApplicationIntegrationTests as follows.

@SpringBootTest(webEnvironment = SpringBootTest.WebEnvironment.RANDOM_PORT)
@AutoConfigureMockMvc
public class CategoryControllerTest extends ApplicationIntegrationTests {
    private static final String CATEGORY_ENDPOINT="/categories";
   @Autowired
    private MockMvc mockMvc;
    @Autowired
    private CategoryRepository categoryRepository;

    @Test
    void TestGetAllCategories_ShouldReturnOk() throws Exception {

        List<Category> categories = List.of(
                new Category("Electronics", "All kinds of electronic gadgets from smartphones to laptops"),
                new Category("Books", "A wide range of books from novels to educational textbooks")
        );
        categoryRepository.saveAll(categories);
        MvcResult mvcResult=mockMvc.perform(
                get(CATEGORY_ENDPOINT).
                        contentType(MediaType.APPLICATION_JSON)
        )
                .andExpect(status().isOk())
                .andReturn();
        var response=mvcResult.getResponse().getContentAsString();
        assertNotNull(response);
        assertFalse(response.isEmpty());
    }
}