2

On my CentOS machine, all my ports are filtered with the Iptables rule:

DROP       all  --  *      *       0.0.0.0/0            0.0.0.0/0

So from the Internet, every port timeouts.

The only way to ssh into the machine, is to do a Port Knock sequence as follow:

6        x   x LOG        tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            tcp dpt:example 53853 recent: SET name: KNOCK1 side: source mask: 255.255.255.255 limit: avg 5/min burst 5 LOG flags 0 level 7 prefix "ssh port knocking 1 "
7        x   x LOG        tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            tcp dpt:example 6663 recent: CHECK seconds: 15 name: KNOCK1 side: source mask: 255.255.255.255 recent: SET name: KNOCK2 side: source mask: 255.255.255.255 limit: avg 5/min burst 5 LOG flags 0 level 6 prefix "ssh port knocking 2 "
8        x   x LOG        tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            tcp dpt:example 96563 recent: CHECK seconds: 15 name: KNOCK2 side: source mask: 255.255.255.255 recent: SET name: KNOCK3 side: source mask: 255.255.255.255 limit: avg 5/min burst 5 LOG flags 0 level 6 prefix "ssh port knocking 3 "
9        x   x LOG        tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            tcp dpt:example 77799 recent: CHECK seconds: 15 name: KNOCK3 side: source mask: 255.255.255.255 recent: SET name: KNOCK4 side: source mask: 255.255.255.255 limit: avg 5/min burst 5 LOG flags 0 level 6 prefix "ssh port knocking 4 "
10       x   x LOG        tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            tcp dpt:example 12263 recent: CHECK seconds: 15 name: KNOCK4 side: source mask: 255.255.255.255 recent: SET name: OPEN_SESAME side: source mask: 255.255.255.255 limit: avg 5/min burst 5 LOG flags 0 level 6 prefix "ssh port knocking 5 "
11       x   x ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            tcp dpt:example SSH REAL PORT state NEW,RELATED,ESTABLISHED recent: CHECK seconds: 15 name: OPEN_SESAME side: source mask: 255.255.255.255 
12       x   x ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0            state RELATED,ESTABLISHED

Now checking at the logs, everytime I change the port sequence, I find in journalctl log that an attempt to those specific example port knock 1, knock 2...etc has been made.

kernel: ssh port knocking 1 IN=eth0 OUT= MAC=example MAC SRC=Attacker IP, always the same DST=My IP LEN=60 TOS=0x00 PREC=0x00 TTL=48 ID=xxxx DF PROTO=TCP SPT=source DPT=**ANY SEQUENCE I CHOOSE** WINDOW=29200 RES=0x00 SYN

There are no logs for any other port, nor any other probe whatsoever.

It's as if the attacker knows the sequence every time I change it.

Since there is absolutely no other log for any other attempt, and monitoring tcpdump shows no probes being done, is it safe to assume the attacker knows the sequence because the machine is compromised and he gets the information everytime I change it?

  • 2
    Assuming you're using the sequence above, why would you create a sequential port knocking mechanism? All someone has to do is nmap -p- and they can access the locked ports... it'll start at 1, and go all the way to 65535. You basically created a port knocking sequence that doesn't work, and is defeated by default port scans. Assuming you're not doing that, if the machine was already compromised, or any machine which contains the sequence, it will be easy to unlock. – Mark Buffalo Jul 7 '18 at 23:52
  • You obviously didn't read the --seconds attribute. Your scan might take more than 15 seconds, after which the port would not show open anymore. You only have a limited time window to guess the sequence, defeating your 1-65535 scan. – Jonas Jul 8 '18 at 0:36
1

Your port knocking idea basically works by advancing from one port knocking stage to the next whenever the same client IP sends a TCP packet to the secret port of the new stage within 15 seconds of moving into the last stage.

Note that there is no penalty for wrong guesses and there is no rate limiting for guesses (the limit of avg 5/min only applies to correct guesses). This means all an attacker has to do in order to advance from one stage to the next is to scan all ports on your machine within 15 seconds, a task which can be easily achieved when using raw sockets (i.e. not waiting for the TCP handshake to complete).

is it safe to assume the attacker knows the sequence because the machine is compromised and he gets the information everytime I change it?

Based on the information you've provided so far, one cannot claim this. I suggest that you look for failed or successful authentication attempts from this specific IP address to see if somebody actually tried to login (and maybe succeeded) instead of only doing port scanning and just accidentally triggered your port knocking rules. Also note that if the machine is really and deeply compromised you should not trust your local logs since the attacker might have changed these.

Apart from that:

There are no logs for any other port, nor any other probe whatsoever

Based on the rules you show you log only if the port matches, i.e. there are no other logs expected.

  • That last line. Ouch. You actually took the time to pick apart the whole thing he was trying to do, secure his server with a port knock, before showing him how he actually wasn't failing at what he was wrongly doing. God I love stackexchange. – J.A.K. Jul 8 '18 at 7:13
  • Yeah I did mention there is a tcpdump log which shows no scan probes. The tcpdump logs everything 24/day, and shows nothing relevant except the consistent with journalctl port knock sequence, at exactly a few hours after I change the sequence. No previous scans, no SYN attempts, nothing. Could it be a MitM between the router and the machine.. which is inspecting the new sequence I made from my client, and then attempting the exact sequence? – Jonas Jul 8 '18 at 10:08
  • @Jonas: you just said something about tcpdump monitoring (not log writing) and also after you've said there are no log entries - that's why I assumed that "log entries" refers to the logs from iptables which you talked about before. But, if you see exactly the same port knocking sequence and only this it maybe is some MITM sniffing your sequence. Have you've checked whom the specific IP belongs to? Have you also checked your logs for authentication attempts, successful or failed? – Steffen Ullrich Jul 8 '18 at 10:36
  • Yea, I meant monitoring tcpdump as a combination of real time and checking the written tcpdumps logs. Also, there are no failed ssh attempts. last command show only my client logins. IP is from China. – Jonas Jul 8 '18 at 10:59
  • @Jonas: based on this information I would consider someone in the path between your and your server is sniffing the traffic. Apart from that I consider the way you do port knocking still vulnerable as I've shown in my answer. – Steffen Ullrich Jul 8 '18 at 11:06

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.