Some services run really good behind a reverse proxy on 443, but some others can really become an hassle… And sometimes just opening other ports would be easier than to try configuring everything to work through 443.

An example that comes to my mind is SSH, yeah you can use SSLH to forward requests coming from 443 to 22, but it’s so much easier to just leave 22 open…

Now, for SSH, if you have certificate authentication or a strong password, I think you can feel quite safe, but what about other random ports? What risks I’m exposing my server to if I open some of them when needed for a service? Is the effort of trying to pass everything through 443/80 worth it?

  • ryannathans@aussie.zone
    link
    fedilink
    English
    arrow-up
    16
    arrow-down
    3
    ·
    1 day ago

    Exposing SSH is not recommended, it’s a hot attack target. Expose a VPN and use that to SSH in.

      • sfjvvssss@lemmy.world
        link
        fedilink
        English
        arrow-up
        4
        ·
        1 day ago

        While this helps getting volume down it just adds a layer of obscurity and the service behind should still be treated and maintained as if it was fully public-facing.

        • ganymede@lemmy.ml
          link
          fedilink
          English
          arrow-up
          1
          arrow-down
          1
          ·
          edit-2
          5 hours ago

          while the most bare bones knocking implementation may be classed as obscurity, there’s certainly plenty of implementations which i wouldn’t class as obscurity.

          • sfjvvssss@lemmy.world
            link
            fedilink
            English
            arrow-up
            2
            ·
            4 hours ago

            Does this method use a cryptographically secure secret which is transmitted encrypted? If not, it is obscurity. If yes, just use normal secure authentication if your goal is security. If you want to get volume down and maybe reduce your risk, feel free to use such things but you should not apply the security label to it.

            • ganymede@lemmy.ml
              link
              fedilink
              English
              arrow-up
              1
              ·
              edit-2
              3 hours ago

              would you classify out of band whitelisting by IP (or other session characteristic[s]) as having no security merit whatsoever?

              would you classify it as purely a decision regarding network congestion & optimisation?

              you’re ofc free to define these things however you wish, but in a form which is helpful to OP’s question i’m not sure i follow you.

              • sfjvvssss@lemmy.world
                link
                fedilink
                English
                arrow-up
                1
                ·
                3 hours ago

                I just wanted to make clear that port knocking is obscurity and maintaining and configuring your still public facing services in a secure manner is essential. There are best practices which I did not define and are applicable here.

                If you whitelist your IP that of course helps but I am not sure what that has to do with port knocking. Whitelisting an IP after it knocked right, that would be obscurity. Whitelisting an IP after it authenticated through a secure connection with secure credentials? Why not just use VPN?

                I am also not directly commenting on OPs question, as I try to tackle missconceptions in the comments.

                • ganymede@lemmy.ml
                  link
                  fedilink
                  English
                  arrow-up
                  1
                  ·
                  edit-2
                  3 hours ago

                  if you can’t work out what knocking might have to do with whitelisting then i’m not sure what you hoped to contribute towards reducing misconceptions in the conversation

                  • sfjvvssss@lemmy.world
                    link
                    fedilink
                    English
                    arrow-up
                    1
                    ·
                    3 hours ago

                    You wrote:

                    there’s certainly plenty of implementations which i wouldn’t class as obscurity.

                    without specifying further. How am I supposed to work out what you mean? I did a guess in my last answer and you seem not to care about a discussion on the topic but instead now question me. I

        • JackbyDev@programming.dev
          link
          fedilink
          English
          arrow-up
          5
          ·
          17 hours ago

          I think people get too defensive about security by obscurity not being security. It’s still better for things to be obscure, it’s just not sufficient. A hidden lock to open a door is marginally better than a lock on the door. A hidden button to open a door isn’t secure though, of course.

          But at the same time, I fully understand why it’s stressed so much. People tend to make analogies in their mind to the physical world. The digital world is so different though. An example I use often is you can’t jiggle every doorknob in the world to see if it’s unlocked, but it’s (relatively) easy to check every IPv4 address for an open port to some database with default credentials.

          • 4am@lemmy.zip
            link
            fedilink
            English
            arrow-up
            3
            ·
            16 hours ago

            Security through obscurity is hammered into newbies as being bad because it’s often a “quicker and easier” solution and we don’t want anyone thinking they could just do that and be done with it.

            You have to learn the proper way to do it; obscurity only buys you time. Maybe.