• tetris11@lemmy.ml
    link
    fedilink
    arrow-up
    0
    ·
    edit-2
    1 year ago

    I have a small PC I use for exposing a private PC to the wider web via nginx proxy. It had two accounts on it: mine, and one I called “remote” with some basic password I set up to forward the proxy connection.

    One day, this machine started making 100% CPU noises, for several hours. Wtf? I check the processes and a Tor node had been setup and was transmitting gigabytes to some Russian IP.

    My brain goes into panic mode, I kill the process, wipe the remote user, and eventually pull the Ethernet plug.

    I wish I hadn’t wiped the user directory as I wanted to know what was being sent and where. Nonetheless the logs showed that several Russian IPs had been attempting an SSH brute force for literally months and one finally guessed “remote” and weak password I set for it.

    I have decades of experience on Unix system, and I cringe having made such a rookie mistake.

    Lesson learned: change the default SSH port to a transient port, have one dedicated SSH user with a non-standard username, and use auth-key entry only.

    I still wonder what was being sent over that Tor node, and why it required all the CPU cores. My best guess is crypto mining, or it was used for a DDOS attack net somewhere.

      • boatswain@infosec.pub
        link
        fedilink
        arrow-up
        0
        ·
        1 year ago

        I see this claim all the time, and it bugs me every time. Obfuscation is a perfectly reasonable part of a defense in depth solution. That’s why you configure your error messages on production systems to give very generic error messages instead of the dev-centric messages with stack traces on lower environments, for example.

        The problem comes when obscurity is your only defense. It’s not a full remediation on its own, but it has a part in defense in depth.

        • dan@upvote.au
          link
          fedilink
          arrow-up
          0
          ·
          1 year ago

          Changing the port isn’t really much obfuscation though. It doesn’t take long to scan all ports for the entire IPv4 range (see masscan)

          • lud@lemm.ee
            link
            fedilink
            arrow-up
            0
            ·
            1 year ago

            It helps against stupid automated attacks though.

            If someone has changed the port it’s likely that they have set up a great password or disabled password auth all together.

            It’s worth it for just having cleaner logs and fewer attempts.

  • Pons_Aelius@kbin.social
    link
    fedilink
    arrow-up
    0
    ·
    1 year ago

    I spent a decade working in insolvency.

    When we were going into a business that had failed the question was “Are the idiots, criminals or both?”

    One highlight:

    A boat sales / marine business goes bust. When we arrive with the paper work and seize the place there are about a dozen new boats on the lot worth several million. We change the locks on the gates.

    Arrive the next day, the gates have been busted open and several million in boats are now missing. We look up the addresses of the owners (one of them lives on acreage) and drive to their property…from the road we can see the boats stashed there. Really smart guys.

    So we call the police. Someone inside notices use there and decides to flee with one of the boats, it is huge but they think they can get away.

    We then have the slowest car chase in history as we calmly follow this guy towing a boat on a trailer down the road while talking to the cops to meet us.

  • bookcrawler@lemmy.world
    link
    fedilink
    arrow-up
    0
    ·
    1 year ago

    Not my oh shit moment but certainly someone’s. Working in a call centre they sent out an example of a fraud email that was being sent out with our logo. It asked for all your personal information and credit card information.

    Several individuals replied with all their details filled in. 3 of them replied all (entire call centre) with their details filled in.