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.

1. 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.
2. 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.