3 ms·

I always install fail2ban on publicly exposed machines, especially if ssh is enabled. It won't block new malicious IPs but at least it will stop bruteforce atta

I always install fail2ban on publicly exposed machines, especially if ssh is enabled. It won't block new malicious IPs but at least it will stop bruteforce attacks coming from each IP

Joel_Mckay 2y ago
Sure, but most people have had do the walk of shame to a local coffee shop when someone inevitably trips the ban on your own network. A proper firewall port-knock set interleaved with 5 day ban tripwire port rules is effective at mitigating distributed brute-forcing. However, a ssh route whitelist rule set with SSL or iodine tunnel traffic priority is probably more important (when someone saturates the bandwidth trying to starve your session off the server). Have a great day =)
- mr_mitm 2y ago
  Port knocking is one of those things that sound like a good idea, but there are many possible footguns. And why is it that there is no one consensus (or "blessed") implementation? The implementation by Moxie seems interesting, but needless to say that Python 2 is an instant no-go: https://github.com/moxie0/knockknock https://github.com/moxie0/knockknock It hasn't been updated in 12 years, so why is it that there seems almost no real interest in a solid port knocking implementation?
  - teddyh 2y ago
    Because port knocking is fundamentally a stupid idea: <https://news.ycombinator.com/item?id=39898061 https://news.ycombinator.com/item?id=39898061>
    - mr_mitm 2y ago
      Two of your three points don't apply to Moxie's and some other implementations, for example Singe Packet Authentication. You can have sufficient bits, and it doesn't have to be cleartext. Maybe it's technically not port knocking anymore, but it's the same idea. And it's not about adding more bits to your authentication, it's about vulnerabilities that can be exploited without authentication, like the recent xz backdoor debacle. Port knocking would defend against that, longer keys would not. This has all been pointed out to you in the thread you linked.
      - teddyh 2y ago
        > Maybe it's technically not port knocking anymore, but it's the same idea. At that point, it’s equivalent to a point-to-point VPN, which is the same as IPSec transport mode. Which is what you ought to be using instead of port knocking, if your threat model includes 0-day vulnerabilities in public-facing services like SSH.
  - Joel_Mckay 2y ago
    If your hobby firewall rule-set compiler is perl based than custom trigger rules are rather trivial. For a random example, most of these ports will just bind to the default web-server (mitigates loopback attacks etc.): 2021 //tripwire 5 day ban, delay 30s 2022 //SSL tunnel for SSH port on VM, with client source-port range restriction. 2023 //tripwire 5 day ban 2024 //tripwire 5 day ban, delay 130s 2025 //tripwire 5 day ban 2026 //trigger 1: enable trigger 2 for specific IP, 5 second delay to open 2027 //tripwire 5 day ban 2028 //trigger 2: enable trigger 3 for specific IP, 4 second delay to open 2029 //tripwire 5 day ban, delay 19s 2030 //tripwire 5 day ban 2031 //trigger 3: close trigger 2, enable SSL tunnel port for specific IP in 1 second 2032 //tripwire 5 day ban 2033 //close all ports for this client IP, and reset trigger states in 1 second 2034 //tripwire 5 day ban I think the lack of popularity comes from the ease of locking oneself out (initially manual starting a firewall during configuration without rule caching is wise), and lack of client-side automated handshaking scripts on non-*nix systems. Someone should put together a little tutorial given many people seem to have lost this simple skill-set. Most people tend to ignore fail2ban integration options like banning game cheats. Have a wonderful day, =)
- AndroTux 2y ago
  > Sure, but most people have had do the walk of shame to a local coffee shop when someone inevitably trips the ban on your own network. VPN, other server, mobile hotspot... No need to leave the house.
  - Joel_Mckay 2y ago
    In theory, remember some firewall policies ban most Tor, Proxy and cloud providers. There is always a way. ;)

I always install fail2ban on publicly exposed machines, especially if ssh is enabled. It won't block new malicious IPs but at least it will stop bruteforce attacks coming from each IP

Joel_Mckay 2y ago

Sure, but most people have had do the walk of shame to a local coffee shop when someone inevitably trips the ban on your own network. A proper firewall port-knock set interleaved with 5 day ban tripwire port rules is effective at mitigating distributed brute-forcing. However, a ssh route whitelist rule set with SSL or iodine tunnel traffic priority is probably more important (when someone saturates the bandwidth trying to starve your session off the server). Have a great day =)

mr_mitm 2y ago
Port knocking is one of those things that sound like a good idea, but there are many possible footguns. And why is it that there is no one consensus (or "blessed") implementation? The implementation by Moxie seems interesting, but needless to say that Python 2 is an instant no-go: https://github.com/moxie0/knockknock https://github.com/moxie0/knockknock It hasn't been updated in 12 years, so why is it that there seems almost no real interest in a solid port knocking implementation?
- teddyh 2y ago
  Because port knocking is fundamentally a stupid idea: <https://news.ycombinator.com/item?id=39898061 https://news.ycombinator.com/item?id=39898061>
  - mr_mitm 2y ago
    Two of your three points don't apply to Moxie's and some other implementations, for example Singe Packet Authentication. You can have sufficient bits, and it doesn't have to be cleartext. Maybe it's technically not port knocking anymore, but it's the same idea. And it's not about adding more bits to your authentication, it's about vulnerabilities that can be exploited without authentication, like the recent xz backdoor debacle. Port knocking would defend against that, longer keys would not. This has all been pointed out to you in the thread you linked.
    - teddyh 2y ago
      > Maybe it's technically not port knocking anymore, but it's the same idea. At that point, it’s equivalent to a point-to-point VPN, which is the same as IPSec transport mode. Which is what you ought to be using instead of port knocking, if your threat model includes 0-day vulnerabilities in public-facing services like SSH.
- Joel_Mckay 2y ago
  If your hobby firewall rule-set compiler is perl based than custom trigger rules are rather trivial. For a random example, most of these ports will just bind to the default web-server (mitigates loopback attacks etc.): 2021 //tripwire 5 day ban, delay 30s 2022 //SSL tunnel for SSH port on VM, with client source-port range restriction. 2023 //tripwire 5 day ban 2024 //tripwire 5 day ban, delay 130s 2025 //tripwire 5 day ban 2026 //trigger 1: enable trigger 2 for specific IP, 5 second delay to open 2027 //tripwire 5 day ban 2028 //trigger 2: enable trigger 3 for specific IP, 4 second delay to open 2029 //tripwire 5 day ban, delay 19s 2030 //tripwire 5 day ban 2031 //trigger 3: close trigger 2, enable SSL tunnel port for specific IP in 1 second 2032 //tripwire 5 day ban 2033 //close all ports for this client IP, and reset trigger states in 1 second 2034 //tripwire 5 day ban I think the lack of popularity comes from the ease of locking oneself out (initially manual starting a firewall during configuration without rule caching is wise), and lack of client-side automated handshaking scripts on non-*nix systems. Someone should put together a little tutorial given many people seem to have lost this simple skill-set. Most people tend to ignore fail2ban integration options like banning game cheats. Have a wonderful day, =)
AndroTux 2y ago
> Sure, but most people have had do the walk of shame to a local coffee shop when someone inevitably trips the ban on your own network. VPN, other server, mobile hotspot... No need to leave the house.
- Joel_Mckay 2y ago
  In theory, remember some firewall policies ban most Tor, Proxy and cloud providers. There is always a way. ;)