Port knocking is a security mechanism that creates a hidden gateway into services like SSH by requiring a specific sequence of network requests—called “knocks”—to predetermined ports before access is granted. In the context of CSF (ConfigServer Security & Firewall), this technique is implemented natively without the need for external daemons like knockd. The firewall itself detects the knock sequence and temporarily lifts access restrictions, enhancing server security by effectively concealing the SSH port.
1. Overview of CSF Port Knocking Mechanism
When port knocking is enabled in CSF, the system is configured to listen for TCP connection attempts across a series of user-defined ports. These ports are typically not assigned to active services and are selected based on obscurity and randomness. The CSF daemon interprets these attempts as a knock pattern and, when matched correctly and in order, modifies firewall rules in real time to allow the knocking client temporary access to a restricted port—commonly port 22 or a custom SSH port such as 2200.
This is implemented through the PORTKNOCKING directive in CSF’s configuration file (/etc/csf/csf.conf). The syntax generally follows:
PORTKNOCKING = "22;TCP;20;31;313;3133;31337"
Breaking this down:
- 22: Target port that will be opened (in this case, SSH)
- TCP: Protocol expected for the knocks
- 20: Time window (in seconds) during which access remains open after a successful knock sequence
- 31, 313, 3133, 31337: Ordered list of port numbers that represent the knock sequence
The system matches the sequence by monitoring inbound TCP SYN packets to these ports and storing knock history on a per-IP basis. The sequence must be completed in order and within a configured time window, otherwise the attempt is ignored.
2. Client-Side Considerations: Generating Knock Sequences
Unlike some dedicated port knocking daemons, SSH clients like PuTTY and Bitvise SSH Client do not have built-in functionality to transmit raw TCP knock sequences. Therefore, the client host must trigger the knock sequence manually via external tools prior to opening the SSH session.
2.1. Using Nmap
One of the most versatile and accessible utilities for generating TCP packets is nmap. It can be used as follows:
nmap -Pn -p T:31,313,3133,31337 <server_ip>
This command sends TCP connection attempts (SYN packets) to the listed ports in the specified order. The -Pn flag bypasses host discovery, allowing the scan to proceed even if the host does not respond to ICMP echo requests.
To increase reliability, you may add delays between knock packets using shell scripts or insert pauses manually to ensure the firewall registers them in sequence.
2.2. Netcat and Telnet
netcat and telnet are other viable tools for generating port knocks:
nc -z <server_ip> 31
nc -z <server_ip> 313
nc -z <server_ip> 3133
nc -z <server_ip> 31337
Each of these commands initiates a zero-I/O connection attempt (-z) to the respective knock port. It’s crucial to adhere to the knock order and timing to ensure that CSF registers the full sequence.
2.3. Knock Scripts and Automation
For consistent execution, users often bundle knock sequences into scripts. A shell script might appear as:
bash
#!/bin/bash
for port in 31 313 3133 31337
do
nc -z <server_ip> $port
sleep 1
done
In Windows environments, a PowerShell script or batch file performing similar tasks via a compatible utility is commonly used.
3. Logging into SSH After Knocking
Upon successful knock detection, CSF modifies its iptables rule set dynamically by temporarily inserting a rule to allow access from the source IP address to the designated SSH port. The duration for which access is granted is dictated by the configured time window (20 seconds in the earlier example).
Once this temporal gateway is open, the client must initiate the SSH session before access is revoked. This is where the SSH client of choice comes into play.
3.1. Using PuTTY
To connect via PuTTY after knocking:
- Launch PuTTY immediately following the knock sequence.
- Enter the target server’s IP address.
- Set the correct SSH port (22 in this context).
- Proceed with authentication as usual.
Ensure the connection occurs well within the port’s open time window; otherwise, it will be silently dropped by the firewall.
3.2. Using Bitvise
For Bitvise SSH Client:
- Start the application.
- Enter the hostname or IP address in the “Host” field.
- Specify the custom SSH port in the “Port” field.
- Provide username and authentication credentials.
- Connect within the allowed time window.
Bitvise will initiate the connection without any awareness of the knock system, relying entirely on the user’s external knock routine to enable the SSH port beforehand.
4. Considerations for Reliable Port Knocking
Several variables can influence the effectiveness of CSF port knocking:
- Timing precision: Delays or mistimed knocks can result in failure. Use sleep intervals consistently in scripts.
- Firewall interference: Local firewalls or NAT rules on the client side may alter or block outbound SYN packets. Ensure nothing impedes raw TCP packets from being transmitted.
- CSF performance: High load on the server could result in delays in rule processing. Monitor syslogs (
/var/log/lfd.log) for troubleshooting. - IP consistency: Knock requests and subsequent SSH connection must originate from the same public IP address. NAT or VPN services can cause inconsistencies.
5. Security Implications
While port knocking enhances stealth by obfuscating open ports, it is not immune to risk:
- Replay attacks: Without encryption or authentication, a captured knock sequence could be replayed by malicious actors. This is mitigated by ephemeral IP matching and short-lived rules.
- Port scanning detection: Repeated knock attempts may resemble a scan. Avoid using easily identifiable sequences (e.g., 21, 22, 23).
- Logging overhead: Excessive or malicious knock attempts could clutter system logs or exhaust connection tracking resources.
To enhance security, consider implementing additional protections such as:
- Changing knock sequences periodically
- Using time-based one-time sequences
- Supplementing with IP whitelisting or 2FA authentication on SSH
In summary, CSF’s native port knocking mechanism provides a lightweight and effective means of securing SSH access without installing additional daemons. While clients such as PuTTY or Bitvise don’t support port knocking natively, pairing them with external knock scripts or utilities enables seamless, secure server access. The key lies in precisely timed sequence execution, consistent source IP usage, and immediate connection to the exposed port within the configured access window. This layered approach significantly reduces the attack surface of commonly targeted services like SSH.
Note:
If you don’t connect within that time frame, CSF automatically re-closes the port, and you’d have to repeat the knock.
If 20 seconds feels tight for your use case, especially when switching from your knock utility to PuTTY or Bitvise, updating that directive like this is a smart move:
PORTKNOCKING = "2200;TCP;60;31;313;3133;31337"
This gives you a full minute to open your SSH session after the knock succeeds—much more forgiving and practical if you need to toggle tools or deal with UI delays. Just be sure to reload CSF afterward with:
csf -ra
One word of caution: while extending the window improves usability, it also slightly increases the time that your SSH port is exposed per authorized attempt. It’s a trade-off between security strictness and user convenience.