We like fwknop a lot for its cryptography implementation which can prevent MITM attacks. However, we don't like it for relatively complex client setup. (For example, there is no official iOS client).
So we built our own cheap version of port-knocking and called it "doormand". It's just a HTTP server (behind nginx) listening for a POST request from clients. If the request is valid, a new iptables rule is added for the knocking IP for 30 seconds.
It supports users with secret key (think API token) so we can knock from our workstation easily. It also supports Timebased-OTP (we can even setup so user is required to enter 2 different TOTP's when knocking) so we can knock from mobile devices.
All messages are hash'ed with timestamp making it harder to re-play attack.
It works great for us (a small team) because now we can knock over HTTPS on our phone/ipad and then SSH-connect to servers.
Port knocking
101–110 of 185 posts
Re: Port knocking
#102I've been in this business for a long, long time and have come across all manner of innovations regarding network security. Port knocking (which I think I learned about first at defcon ... perhaps 18 years ago ?) stands out as one of the very few things that made my network(s) substantially safer at nearly zero cost. I love, and continue to love, both the idea and the implementation. Pay no attention to the nay-sayer…
Expanding on that substantive critique, i.e. complexity. Port knocking strips you of the benefits you get from session protocols like TCP.
- Fails when packet loss is high.
- Fails when lags make the attempts arrive in changed order
- Fails when multiple people try to execute the sequence at the same time (yes, you can track source IPs, but then it doesn't work from behind a NAT)
Agreed, none of this is a problem on a small scale. Agreed, you can work around that but it's a PITA.
Re: Port knocking
#103Earlier quoted context omitted.
I wonder if it would be interesting to load a ssh honeypot that would feed from the logs so it would add the logins and then just dump the ip + input to a file. Honeypot could basically run in a some sort of isolation layer (like Sandboxie or jails) and then self-destruct after the automated script is gone... and then you slam the door on that user/ip combo for good. I can't help but think this would be interesting..…
Fail2ban [0] bans ip addresses based on failed login attempts (works for more than ssh), minus the isolation layer. [0]: https://www.fail2ban.org/wiki/index.php/Main_Page
fail2ban should be avoided. It does not support IPv6, so should be considered legacy software.
EDIT: Source: https://github.com/fail2ban/fail2ban/issues/1123
It appears they have moved forward a little in supporting IPv6, but it's still incomplete. It's unacceptable to not support it fully in 2020.
Re: Port knocking
#104Port knocking is stupid. The only possible real reason anyone should have for actually using it is if they really don’t want their logs to be flooded with the normal internet attacks. Logs which the SSH daemon really shouldn’t (by default) be creating in the first place, since what’s the use? It’s like having a weather station on your roof which always says “it’s raining”, since you live on the ocean floor. It’s the internet, SSH will be attacked; there’s (by default) no purpose to logging this.
For actual security, though, it’s also woefully inadequate:
1. It adds very little security. How many bits are in a “secret knock”?
2. The security it does add is bad: It’s sent in cleartext, and easily brute-forced.
3. It complicates access, since it’s non-standard.
Re: Port knocking
#105I've been in this business for a long, long time and have come across all manner of innovations regarding network security. Port knocking (which I think I learned about first at defcon ... perhaps 18 years ago ?) stands out as one of the very few things that made my network(s) substantially safer at nearly zero cost. I love, and continue to love, both the idea and the implementation. Pay no attention to the nay-sayer…
There's a similar , very sneaky tool: sslh. Practically no automated tools will attempt to SSH into the HTTPS port...
I presume this connects SSH clients, and serves a fake web page to browsers?
Sounds pretty cool, but do SSH clients (e.g. PuTTY need special support for it)
Re: Port knocking
#106Earlier quoted context omitted.
I wonder if it would be interesting to load a ssh honeypot that would feed from the logs so it would add the logins and then just dump the ip + input to a file. Honeypot could basically run in a some sort of isolation layer (like Sandboxie or jails) and then self-destruct after the automated script is gone... and then you slam the door on that user/ip combo for good. I can't help but think this would be interesting..…
You don't even need a honeypot, simply ban ip addresses for some time after X failed login attempts.
The point of the honeypot is that there's no heuristic causing any delay or elusive attacker being missed (e.g botnet trying once per IP). You don't even need any processing time, nor even complete syn/synack/ack: any TCP connection attempt to that port triggers an instaban.
Re: Port knocking
#107Earlier quoted context omitted.
What happens when the attacker modifies /etc/resolv.conf, disables or does not use DNS while on the network. What if the attacker does not use software that automatically loads images, like the "canary token" tracking pixels? What is the attacker opens the files offline? Canary tokens still work? How? Why would anyone advise using canary token instead of port knocking? Makes no sense. Why not use both?
To defend Canarytokens here (and I’m totally biased because we make it) some tokens can’t be easily avoided. Ie. If the token is a Slack/AWS/something API key, then the only way for the attacker to profit is to use it, and the moment they do, they tip their hand. The joy of Canarytokens is not having to set up infrastructure to get the alerting win, with very little effort.
Not "knocking" the idea but to be honest using someone else's API key and expecting that no one is going to notice sounds really dumb. I guess if that is the level of intelligence you are up against, then "winning" can indeed be quite easy. Although I would argue if the goal is to restrict access and they managed to gain access then regardless of what they do next, whether it is smart or stupid, they have "won".
Re: Port knocking
#108Earlier quoted context omitted.
Fail2ban [0] bans ip addresses based on failed login attempts (works for more than ssh), minus the isolation layer. [0]: https://www.fail2ban.org/wiki/index.php/Main_Page
fail2ban should be avoided. It does not support IPv6, so should be considered legacy software. EDIT: Source: https://github.com/fail2ban/fail2ban/issues/1123 It appears they have moved forward a little in supporting IPv6, but it's still incomplete. It's unacceptable to not support it fully in 2020.
It looks like ipv6 matching is supported since late 2017 (version 10.0 [0]), although the changelog states that "not all ban actions are IPv6-capable now". As for IPv6 capabilities, I don't have any recent experience with the software.
[0]: https://github.com/fail2ban/fail2ban/blob/0.11.1/ChangeLog
Re: Port knocking
#109Earlier quoted context omitted.
Fail2ban [0] bans ip addresses based on failed login attempts (works for more than ssh), minus the isolation layer. [0]: https://www.fail2ban.org/wiki/index.php/Main_Page
fail2ban should be avoided. It does not support IPv6, so should be considered legacy software. EDIT: Source: https://github.com/fail2ban/fail2ban/issues/1123 It appears they have moved forward a little in supporting IPv6, but it's still incomplete. It's unacceptable to not support it fully in 2020.
it does more than just scanning iptables logs..
Re: Port knocking
#110Port knocking was somewhat silly when it was introduced ~20 years ago --- at most, on a reasonably designed network, it was saving you from your own misconfigurations, but at least in 2005 it was reasonable to imagine a highly diverse network of machines that people logged into using multiple protocols, where those misconfigurations were likely. In 2020, it's gone past "silly" and is now a design smell, in the same w…
Would you mind explaining why fail2ban is bad?