I have some servers that I connect to that utilize port knocking to access specific areas. I've seen some reports from a few firewalls of what looks like pinging of specific ports on some servers, but I don't think it is pinging unless somehow someone can change the port number that pining effects. I also see activity across some random ports on the firewall in patterns with the report stating "activity" or "attempted access" in the report I looked at which weren't very detailed.

I know the idea behind using port knocking for securing some ports but I'm not sure how it is done/initiated. What is the "tool" or command that does the knocking. Is this similar to the same command that port scanners use to look for vulnerabilities?

Does anyone know if there are tools that will port knock a machine to see if they win a prize (find hidden port/gain access)?

I'd like to try knocking on these servers to see if it returns the same report I saw so I can tell if that is what was happening on those servers. Does anyone know what I would do to test this?

Finally is there any software that will record all port knocking attempts such as an IDS (Snort??) and will it identify it as such or will/can it just blend with other traffic that sites generate.

sounds like the sort of thing kali linux (and the tools contained therein) is there for.

Some things to keep in mind before spending resources on port knocking:

http://bsdly.blogspot.com/2012/04/wh...-knocking.html

As far as looking for attempted intrusions, those will just show up as random noise until one succeeds in getting through.

If you are looking to secure SSH use SSH Keys to login and then use Fail2ban to block anyone who fails a login.
If you are looking to use Knock services on other ports THIS will guide you in how to set it up.

Much better, IMHO, is to use OpenVPN with tls-auth and then to have every internal server process listen only to the OpenVPN virtual addresses. You can throw away silliness like "port knocking." Instead, to the Internet at large, your certificate-protected server isn't there: there are no "open ports," and even the presence of OpenVPN cannot be detected.

Users who have successfully opened the tunnel find that all of the services they need – ssh, mysql, and so forth – are "right there." But it is impossible for anyone in the outside world to reach them or even to see that they exist.

The only thing that your servers now present to the Internet is: "a smooth, featureless wall." There's nothing to discover, and no possible way to get in unless you possess a one-of-a-kind, 4096-bit, un-revoked, digital certificate.

• Need for silly games like "port knocking?" None.
• Number of unauthorized access attempts? None.

I think you are missing a small detail about port-knocking. There are no ports open to discover.

You OpenVPN has a port that it listen on and needs to be open to the public in order to connect to it. So anyone can find that port and begin their attacks. If they get in or not is another question and also depends on any bugs in the software.

With port knocking all ports are closed and only opened if the right sequence is given and then only open for the IP Address of the system that gave the proper sequence. So still no one can find the port and begin any sort of attack against it even if there are bugs in the software.

"Nope! Bzzzt! Sorry!!" This assumption, intuitively appealing though it might be, is not correct.

By design, and by a default that you should not override, OpenVPN communicates using the UDP protocol – a "datagram-oriented" protocol that is the "IP" lower-half of the more well-known "TCP/IP."

Operating at the IP level, OpenVPN is able to support secure TCP/IP (as well as UDP) communications on behalf of its clients. But, by operating at this level, it avoids exposing itself.

At this level of "the stack," there is no concept of an "open port" (really, an "open socket") in the TCP/IP sense, because, at this level, there is no concept of a "conversation."

At this level, "UDP," there are only datagrams. When you send a datagram, you have no certainty that they will be received at all, let alone of the order in which they will arrive. (Whereas, both of these are things that are specifically guaranteed by TCP/IP, which is built on top of IP.)

Thus, at the UDP level where OpenVPN customarily operates, there is no "open port socket" to detect. All that you can do is to send a UDP packet, addressed to some IP-address and to some port-number at that address, and "hope that you hear something soon." If you do, it will not be "a reply," in the TCP/IP sense of the word: it will simply be a datagram that (maybe) shows up at somewhere you are expecting. (And, the two of you must somehow agree as to just what sort of thing that might be ... knowing in advance that, even if the other party does hear you, his reply to you might not arrive. C'est la guerre.)

Therefore, if you instead "receive no response at all," then any(!) one of three things might have gone wrong, and, unlike TCP/IP, you cannot distinguish which one it is:

1. "Your datagram didn't make it to its destination." (The UDP protocol has no obligation to make sure that it did.)
2. "It made it, but there was no one listening."
3. "It made it, and someone was listening, but they decided not to answer you."
4. (Irrelevant in this case ...) They tried to reply, but their response never arrived.

Especially(!), you cannot distinguish between alternatives #2 and #3.

If you use the tls-auth feature of OpenVPN, the server will not answer – it will simply "drop the packet" – unless in that initial packet the client shows evidence of being in possession of a digital certificate that is also known to the server. Only if it does so will the server respond and begin the initial handshaking.

• Thus, the server will never reveal(!) itself(!!) unless there is already an extremely-high probability that the supplicant is going to turn out to be authorized.
• And ... most critically ... unless(!) the server does elect to reveal itself, you have no way (other than third-party traffic analysis that hello, yes we are listening to you ... your tax dollars at work might do ...) to know that exists(!) (This in complete and utter contradiction to the socket-oriented world of TCP/IP.)

- - -

So, go ahead. "Put OpenVPN on your front line, properly secured by both types of certificates." Use OpenVPN in precisely the capacity that it was made for: to be "a secure router between two subnets." Prevent your services from listening to any "outside" address: have them listen only to the OpenVPN tunnel. (Use firewalls to keep 'em honest.)

Watch your "unauthorized access attempts" count drop down to zero, and stay there ... forever. Your authorized users will pass swiftly and surely through a secret door that no one else can even detect.

(And, should anyone be so crass as to steal a laptop, or otherwise steal a key, you can revoke their(!) key in a matter of seconds ... thus forever denying access to them while affecting no one else.)

- - -

You have no need for "port knocking," because your server no longer exposes any ports to the public. If you are authorized to enter the tunnel, the ports can simply be there, without "knocking." To the outside world, there are no open ports.

The "attack-robots" that have been so vexing you until now will ... cease entirely(!). They have no choice but to pass you by, because, so far as they can perceive, your public TCP/IP address is now featureless. (And, even if they're clever enough to know that "there might be an OpenVPN server out there somewhere," they are unable to detect it.)

Case Closed.™

There is a problem with port-knocking from my perspective is that if your ssh machine is behind a firewall you also need to configure rules on the firewall, and sometimes this is imposible in terms for management of the rules. We have ssh expose on the internet with no issues just by using failban and vpns, so port-knocking is good for a research paper but I dont see it on a real world.

That's the secret: put up (Open)VPN as your outer wall, then arrange for everything (such as "ssh") to listen only to the inside, using firewalls to prevent them from accidentally being reached from (or reaching) the outside.

As soon as "the VPN tunnel is open," you can SSH and anything-else and there's no reason to bother with nonsense like "port knocking." Why? Because the ports that are so-easily accessible to a VPN-tunnel user cannot be reached, or even detected, from the outside world.

On all of my public-facing sites and servers, we get the usual junk Apache error-log messages from script-kiddies sniffing (fruitlessly, of course) for WordPress and for MySQLAdmin and such. But there is never an "unauthorized access attempt" in the syslogs, because such a thing is quite-literally impossible. What authorized users bearing non-revoked certificates can do easily, the outside world cannot do at all. Neither can they find a chink in the armor, because OpenVPN, operating beneath the TCP/IP layer, does not reveal itself. "Over and Out!™"