Hacker News new | ask | show | jobs
by Nokinside 3669 days ago
>I can copy your knock and get access,

Replay attacks don't work against proper port knocking.

Take for example, knockknock-daemon. It sends just one SYN packet where packets IP and TCP headers are encrypted request to open a specified port. Port is closed after connection.

https://github.com/moxie0/knockknock/blob/master/knockknock-...

1 comments

Entirely possible, as I said this is the first time I read about this, so the port knocking I refer to is the kind described, which is using a sequence of ports as a key.

I don't know python but this implementation seems broken in the same way (or more precisely, under the same circumstances). I just realized, you don't even need to copy the knock. If you have access to the network traffic (which you would need to copy the knock in the first place), you also have access to the TCP sequence numbers. You can just connect from the user's IP after he performs the knock, or even let him connect and inject packets at some later point. This program seems to rely on the TCP authentication of IP address which is completely negated if the attacker can monitor traffic.

Am I misunderstanding how this program works?

The goal of knocking is to expose running services as little as possible and do it in a stealthy way.

An observer watching packets has no way to know that the SYN packet transmitted is a port knocking request. Even if they know, there is no way to determine which port was requested to open.

I don't understand what you mean. How would you prevent the attacker from knowing the port, except by only sending the port knock, and then never actually connecting?

Let's say the attacker has no idea you're using port knocking and even somehow missed your port knock packet completely, but after that captures subsequent traffic. He will still see the sequence numbers in the SYN/ACK from the server which is all he needs. Once he has that, he is an equal party to you (the legitimate client) in that connection.

Ah. I get your point.

Tell me what percentage of attackers on the net have full access to the network traffic and can do full MITM attack?

If the goal is layered defense and minimizing exposure, worst case scenario is not good counterargument.

You don't need to be able to do a full MITM attack. You just need to be able to read the traffic, not modify it.

And if you believe this is an unreasonable assumption, why did you link me a program which says in its description "The problem with the original concept was that if your port sequence was observed by passive eavesdropping, it was easily replayable." ? It tries to solve this exact problem - a sniffing attacker.

I am just explaining why this program fails to solve the problem you claimed it solved in your original reply. Surely you can understand that.

Tell me if I understood something wrong:

Without knocking:

Service is listening and accepting new connections in well known port. When client makes connection attempt, attacker can replay the connection attempt and server starts handshake. Even without sniffing attacker can initiate handshake by just requesting connection.

With knocking:

Server/firewall opens requested port for client who knocks. That port is _not_ open for subsequent connection attempts. Simple replay is not going to initiate handshake. You need to block client from sending.