11 ms·

I'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 lear

• acl777 6y ago
  any tips or where one would get best practice for configuring/setting up/using knockd? I wrote up how having a server on the internet is scary now (http://redgreenrepeat.com/2020/03/20/why-you-should-secure-your-server-1/ http://redgreenrepeat.com/2020/03/20/why-you-should-secure-y...) and how to protect it (http://redgreenrepeat.com/2020/04/10/how-to-secure-your-server-2/ http://redgreenrepeat.com/2020/04/10/how-to-secure-your-serv...) One thing I didn't get into more was port knocking/knockd as there were not many resources for it. I'd love to learn more about how you have used knockd.
  • coronadisaster 6y ago
    vpn + port knocking should be good enough but I am not sure how to implement it in an efficient way (I currently only use a VPN) https://www.howtogeek.com/105693/how-to-knock-into-your-network-part-2-protect-your-vpn-dd-wrt/ https://www.howtogeek.com/105693/how-to-knock-into-your-netw...
    • yjftsjthsd-h 6y ago
      Does this have any advantages over using plain wireguard? WG operates purely over UDP and doesn't respond unless you send it packets with an authorized key, so it's essentially the VPN and port knocking all in one.
      • coronadisaster 6y ago
        I guess if you only have the key, you would still need to figure out how to use it
        • yjftsjthsd-h 6y ago
          I think "attacker has a private key" is an unreasonable threat model to protect against, not least because the key is so much harder to crack than port knocking. The benefit to port knocking is against information disclosure ("this server is running Apache httpd version x.y and sshd version z"), brute force, noisy logs, and pre-auth vulnerabilities (things like heartbleed and shellshock). While in theory I suppose wireguard could be affected by pre-auth vulnerabilities and maybe a completely blind bruteforce attack, it's a listening UDP port that doesn't respond until it sees valid credentials, so it's completely invisible to an attacker.
  • dugite-code 6y ago
    Personally I avoid knockd and instead use something like fwknop https://github.com/mrash/fwknop https://github.com/mrash/fwknop. You get the advantage of port kocking while protecting yourself from re-play attacks. The main dis-advantage is it is a more complicated procedure so it may limit you a bit. How I set it up specifically: https://peekread.info/tech/20190513-fwknop/ https://peekread.info/tech/20190513-fwknop/
  • rsync 6y ago
    My default ipfw ruleset is very restrictive - no ports open. The command that gets run when the (correct) knock comes in is an ipfw command: /sbin/ipfw add 01021 allow tcp from %IP% to 10.0.0.10 22,443 setup ... so now the knocking IP can see TCP 22 and 443 (and nothing else). I then have a cron job that runs every night at midnight that deletes those rules: 0 0 * * * /sbin/ipfw delete 01021 ... so I am required to knock daily. The following is a little lame, but I want to see who has knocked so far today (should just be me and my own IPs) so I do this every minute: * * * * * /sbin/ipfw show|/usr/bin/grep ^01021 | awk '{print $7}' > /tmp/.knock_list ... and then cat that list to myself every time I log in ...
    • polishdude20 6y ago
      So with poet knocking, if I only have an ssh port open and a couple of ports my servers server content on like an http and https server, I'm assuming id use port knocking to get inside my ssh port right? I don't need to do port knocking for my http and https ports because they're open but not as an ssh service?
      • TedDoesntTalk 6y ago
        > So with poet knocking Knocking a poet is bound to get you into trouble. Poets fight back, and hard. Just don't do it.
        • polishdude20 6y ago
          But they're just so damn eloquent all the time. It drives me nuts.
      • rsync 6y ago
        Yes, that's right - you'd leave your public services open by default and the knock would simply open up tcp22 ...
  • rmrfstar 6y ago
    Moxie actually published a nice lighweight port knocking daemon that: * Does not bind to sockets * Is not written in C * Prevents replay attacks * The only code that runs as root is just tailing kern.log and is like 15 lines It probably needs to roll from SHA1 to SHA256 and Python2 to Python3, but otherwise seems sound. [1] https://moxie.org/software/knockknock/ https://moxie.org/software/knockknock/
    • Forbo 6y ago
      Looks like there is a pull request to change it from authenticate-then-encrypt to encrypt-then-authenticate that hasn't been merged for over five years. Thinking this project might be abandoned, unfortunately. :-( Edit: It appears there may be an active fork here: https://github.com/indyprime/knockknock https://github.com/indyprime/knockknock Still digging through to see if the encrypt-then-authenticate change made it into this version. Edit 2: It looks like it still uses authenticate-then-encrypt. I sent an email to the maintainer of that fork, we'll see what happens. ^__^
    • demosito666 6y ago
      This is freaking genius!
• cortesoft 6y ago
  What is your conclusion that port knocking has made your network substantially safer based on? Just curious how you measure the effectiveness of something like this.
  • leeoniya 6y ago
    from personal experience, simply moving ssh off of port 22 cuts your drive-by log noise by 99.9%, which makes auditing clean logs much much easier. failed login attempts with ssh on 22: hundreds per week, after: 0. i imagine with knockd it would go negative.
    • peterwwillis 6y ago
      > moving ssh off of port 22 cuts your drive-by log noise I didn't know logs made me unsafe! I'm turning off all logging immediately.
      • femiagbabiaka 6y ago
        The point is that 99% of all access attempts are done by simple skiddies or people simply crawling the internet with masscan or similar.
      • shoeffner 6y ago
        The quote is not about logs making you unsafe. The quote is about ssh login and connection attempts on port 22 which clutter your log files. Assume you move ssh to another port, say 23. In that case, anyone trying to connect to port 22 would find a closed port and the connection would fail, on a layer before login attempts get logged.
      • kelnos 6y ago
        The point is that most login attempts are automated, and the automated scripts just try port 22 and move on if they fail. If you run ssh on port 22, you see in your logs all the failed attempts from the giant sea of automated scanners, and will probably miss the one or two humans who might know something about you specifically (like your username) and are trying a targeted attack. If you put ssh on another port, all of those automated login attempts disappear from your logs. The determined human attacker probably has port-scanned you and found ssh on another port, so you'll see just that attacker and can look into it more deeply if you feel the need. On port 22, you probably never bother to look at your failed-attempt log, because there's so much noise.
• matheusmoreira 6y ago
  What do you think about single packet authorization?
• chx 6y ago
  There's a similar , very sneaky tool: sslh. Practically no automated tools will attempt to SSH into the HTTPS port...
  • GordonS 6y ago
    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)
    • exrook 6y ago
      Nope, no support needed. SSLH will proxy SSL traffic to whatever other SSL service you have running (nginx, openvpn, etc.), and send the SSH traffic to openssh. It look like it even supports recognizing plain HTTP traffic as well and proxying it accordingly.
• steerablesafe 6y ago
  I would argue that port knocking doesn't implement cryptography, but it implements steganography. It's purpose is not to cryptographically secure your service but to conceal its existence.
  • heftig 6y ago
    Can't we do both? Like, the content of the UDP packet is the output of `date -uIs | gpg --sign`.
    • cheweh 6y ago
      From knockknock: > When you want to open a port from a client, you run 'knockknock', which sends a single SYN packet to the server. The packet's IP and TCP headers are encoded to represent an IND-CCA secure encrypted request to open a specified port from the source IP address. https://moxie.org/software/knockknock/ https://moxie.org/software/knockknock/
      • cutemonster 6y ago
        That page links to a http insecure download script, weird. (Not https, no signature) This link: wget http://www.thoughtcrime.org/software/knockknock/knockknock-0.6.tar.gz http://www.thoughtcrime.org/software/knockknock/knockknock-0...
        • Forbo 6y ago
          Yeah, the documentation is dated. Not only does it point to an old version, but it would probably be best to get it from the GitHub page he links to. Even then, there are more active forks, so they may be worth checking out to see which would be best to get on board with.
          • cutemonster 6y ago
            Thanks, seems this is the (also outdated) repo: https://github.com/moxie0/knockknock https://github.com/moxie0/knockknock Yes I suppose one of the forks is better nowadays
• praptak 6y ago
  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.
  • tinus_hn 6y ago
    You could of course just try again if it fails due to these excessively rare cases. There are a lot of things that fail if packets arrive out of order and with random packet loss your experience is going to be awful, so both of these are rare.
  • rsync 6y ago
    "Expanding on that substantive critique, i.e. complexity. Port knocking strips you of the benefits you get from session protocols like TCP." This is correct and worth considering. In actual practice (again, over 15 years, all over the world, etc.) I have found that the only place I ever run into this is on airplane (in-air) wifi. I don't know if they are specifically blocking random fragments or if they are just too laggy to make this scheme work. A quick workaround is to ssh to some other host that you control that isn't behind a knock, but does have 'knock' installed and then jump through it.
• simias 6y ago
  For me changing the default port for SSH achieved much of the same result at an even lower cost IMO. That is, unless you're high profile enough that attackers might want to target your server specifically and you're not just randomly scanned by botnets which won't generally bother looking beyond port 22.
  • ape4 6y ago
    Put ssh on port 80 and http on port 22 - perfect security ;)
    • metalliqaz 6y ago
      for my internet-facing machines I black-hole everything below 1024 and move SSH to something high but easy enough to remember like 22222
      • snazz 6y ago
        My latest trick for deciding on external ports to forward is to combine the service port and the device's internal IP address. If my desktop was 10.0.1.36 and the service was SSH on port 22, the external port would be 22136. So far it's worked well, but it only really works if you force your router to only give out 10.0.1.2 through 10.0.1.99.
      • ape4 6y ago
        If I was an evil hacker I would look at that port and other variants of 22 like 2200, 2222, etc for people's ssh.
        • metalliqaz 6y ago
          and then all you'd have to do is compromise SSH on my fully patched system of course the point is not to be able to withstand an attack by a persistent attacker. it prevents my logs from filling up with the constant scans from scripts
  • hylaride 6y ago
• igetspam 6y ago
  I've been wanting to implement knockd on something for years but people always push back. I don't actually think it's incredibly useful but I love the cool factor. Good for you for actually doing it.
• koheripbal 6y ago
  There is this idiotic notion that any security measure that cannot stand on its own is "security by obscurity", and therefore useless. That principle is taught in school and echoed by every junior netsec professional out there. After almost 20 years of work, I can say that these layered techniques, are invaluable. OF COURSE, the core security has to be bulletproof. But once you've covered that base, there is an enormous value in keeping your assets under the radar. At the very least, it reduces the number of alerts you need to review by several orders of magnitude. Logs become READABLE.