• MystikIncarnate@lemmy.ca
    link
    fedilink
    English
    arrow-up
    0
    ·
    9 hours ago

    As IT/network/security, using a well known port for something that’s not what is supposed to run on that port, is inviting all kinds of problems.

    Especially the very well known ones, like ftp, ssh, SMTP, http, HTTPS, etc (to name a few). People make it their mission to find and exploit open FTP systems. I opened up FTP on a system once to the internet as kind of a honeypot, and within a week or so, there was someone uploading data to it.

    No bueno. Don’t use well known ports for things unless the thing that well known port is known for, is what you want to do.

    • Randelung@lemmy.world
      link
      fedilink
      arrow-up
      0
      ·
      5 hours ago

      All of that is fine, and they mentioned the management perspective, which I get. It was a field test and our original choice of 4001 - which is what other serial to TCP servers like us use, also in their network - was unavailable.

      What irks me is the “technical impossibility” of raw TCP and “I must be wrong” when filling out their firewall change form.

      They’ve since given us a different port “close to others that we use”, for whatever reason that matters, and based their choice on some list of common protocols outside the reserved range. But not 4001.

      That by itself is just one thing and I wouldn’t give it a second thought, but it’s all part of a larger picture of ineptitude. They opened a ticket because an arrow at the border of our UI vanished when they screen shared on Teams. Because of the red border. And they blamed our application for it.

      They didn’t set up their PKI correctly and opening our webpage on specific hosts gave the typical “go back” warning. But it was our fault somehow, even though the certificate was the one they supplied us and it was valid.