Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!


Doesn't Hetzner wipe cloud servers when deleted??
New on LowEndTalk? Please Register and read our Community Rules.

All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.

Doesn't Hetzner wipe cloud servers when deleted??

Well this is a bit worrying for me now. Recently I had a cloud server I was using with dokku so the hostname of the server was dokku.botta.me, where botta.me is my personal domain.

On this server I had configured Fail2ban to send me email notifications using Postfix, which itself was configured to use OhMySMTP as SMTP relay.

That server was deleted weeks ago perhaps, can't remember when for sure.

A hour ago I received an email notification from Fail2ban from dokku.botta.me AND checking the email headers I can see it was sent using OhMySMTP.

How the hell is this possible? I would assume the cloud servers are destroyed/wiped automatically upon deletion but this doesn't seem to be the case because otherwise I wouldn't have another explanation.

It's extremely unlikely that someone would use my personal domain with that exact hostname AND have Postfix configured to use the exact same SMTP service at the same time.

Now I am worried that the server might still contain sensitive data like passwords and other, because I probably didn't delete anything there assuming that the cloud server and its storage would be destroyed automatically.

I contacted Hetzner support and am waiting for a reply.

Has anything like this happened to others before?

Comments

  • It just occurred to me that I was using pub key auth for SSH and of course I had changed the password of the root user, so I guess they wouldn't be able to actually access the server via SSH or VNC console. What do you think?

  • That's what disk encryption is for, especially for rented servers you are not colocating.
    Double that for virtual cloud servers. At least you could run dd if=/dev/urandom of=/dev/sda
    before letting the server go.

    Anyway, it's probably a delayed envelope or you configured another instance and didn't check
    the originating IP. The amount of fuckery you need to go thru in order to recover someone else's
    server (booting in rescue, resetting root password) just to get trapped by fail2ban later doesn't
    sound like a very likely scenario.

  • The notification was that Fail2ban had started on that server, so somehow the same server got boot up by someone. I created new cloud servers yesterday that I am still using for this but they have nothing to do with that old setup. How do you enable disk encryption with cloud servers?

  • Doesn’t OhMySMTP have some kind of logs? You might want to check the actual time that the email was generated. Also, I do believe there was one time with SolusVM where the instance won’t delete properly. This might be the case with hetzner as well. Might want to try logging in with your old IP/creds?

  • @sanvit said:
    Doesn’t OhMySMTP have some kind of logs? You might want to check the actual time that the email was generated. Also, I do believe there was one time with SolusVM where the instance won’t delete properly. This might be the case with hetzner as well. Might want to try logging in with your old IP/creds?

    I just tried logging in to Mailpace (the new name of OhMySMTP) and I can't log in because I think I actually deleted my account some time ago because I switched to something else.

    So this is weird also now: how come delivery from my domain still work with OhMySMTP after deleting the account? If instead it's a delayed envelope like @luckypenguin suggested how is it possible it was delayed for so long?

  • @vitobotta said: How do you enable disk encryption with cloud servers?

    Installing from custom ISO, or something like https://netboot.xyz method, or by downloading ISO to the RAM disk, there are virtually endless ways to do the same.

  • sanvitsanvit Member
    edited August 2022

    @vitobotta said:

    @sanvit said:
    Doesn’t OhMySMTP have some kind of logs? You might want to check the actual time that the email was generated. Also, I do believe there was one time with SolusVM where the instance won’t delete properly. This might be the case with hetzner as well. Might want to try logging in with your old IP/creds?

    I just tried logging in to Mailpace (the new name of OhMySMTP) and I can't log in because I think I actually deleted my account some time ago because I switched to something else.

    So this is weird also now: how come delivery from my domain still work with OhMySMTP after deleting the account? If instead it's a delayed envelope like @luckypenguin suggested how is it possible it was delayed for so long?

    iirc emails can be queued up to 5 ~ 14 days

    Edit : if you could copy+paste the header (redacting any personal info), you might be able to find the real sending time

  • @luckypenguin said:

    @vitobotta said: How do you enable disk encryption with cloud servers?

    Installing from custom ISO, or something like https://netboot.xyz method, or by downloading ISO to the RAM disk, there are virtually endless ways to do the same.

    That makes a lot of automation impossible :(

  • @sanvit said:

    @vitobotta said:

    @sanvit said:
    Doesn’t OhMySMTP have some kind of logs? You might want to check the actual time that the email was generated. Also, I do believe there was one time with SolusVM where the instance won’t delete properly. This might be the case with hetzner as well. Might want to try logging in with your old IP/creds?

    I just tried logging in to Mailpace (the new name of OhMySMTP) and I can't log in because I think I actually deleted my account some time ago because I switched to something else.

    So this is weird also now: how come delivery from my domain still work with OhMySMTP after deleting the account? If instead it's a delayed envelope like @luckypenguin suggested how is it possible it was delayed for so long?

    iirc emails can be queued up to 5 ~ 14 days

    Edit : if you could copy+paste the header (redacting any personal info), you might be able to find the real sending time

    The headers show only August 10 as date, which is today.

    I contacted Mailpace about it, I hope they can check their logs.

  • ralfralf Member

    @sanvit said:
    Edit : if you could copy+paste the header (redacting any personal info), you might be able to find the real sending time

    Only the Received: headers are particularly useful (bear in mind they are probably multi-line). Just look at the first one (which will be the most recent) and last one (which will be when it was sent). They should both have timestamps.

  • @ralf said:

    @sanvit said:
    Edit : if you could copy+paste the header (redacting any personal info), you might be able to find the real sending time

    Only the Received: headers are particularly useful (bear in mind they are probably multi-line). Just look at the first one (which will be the most recent) and last one (which will be when it was sent). They should both have timestamps.

    There's three of them, all August 10

  • ralfralf Member

    @ralf said:

    @sanvit said:
    Edit : if you could copy+paste the header (redacting any personal info), you might be able to find the real sending time

    Only the Received: headers are particularly useful (bear in mind they are probably multi-line). Just look at the first one (which will be the most recent) and last one (which will be when it was sent). They should both have timestamps.

    Also if your server is in fact up, you should be able to figure out its IP address from the received headers, and ssh in and start a disk erase (dd urandom as above).

  • @ralf said:

    @ralf said:

    @sanvit said:
    Edit : if you could copy+paste the header (redacting any personal info), you might be able to find the real sending time

    Only the Received: headers are particularly useful (bear in mind they are probably multi-line). Just look at the first one (which will be the most recent) and last one (which will be when it was sent). They should both have timestamps.

    Also if your server is in fact up, you should be able to figure out its IP address from the received headers, and ssh in and start a disk erase (dd urandom as above).

    I don't think I can see the address of the server because I used OhMySMTP for the delivery of the email. The originating IP is 46.252.181.46 which according to Maxmind is in France, owned by Squark Sarl

  • RickBakkrRickBakkr Member, Patron Provider, LIR

    Perhaps it is just the PTR, I think they do not wipe those. If some server gets your IP recycled, perhaps that environment is bruteforcing, with its PTR - your old hostname - attached to it.

    Thanked by 1ericls
  • jarjar Patron Provider, Top Host, Veteran
    edited August 2022

    @vitobotta said:

    @ralf said:

    @ralf said:

    @sanvit said:
    Edit : if you could copy+paste the header (redacting any personal info), you might be able to find the real sending time

    Only the Received: headers are particularly useful (bear in mind they are probably multi-line). Just look at the first one (which will be the most recent) and last one (which will be when it was sent). They should both have timestamps.

    Also if your server is in fact up, you should be able to figure out its IP address from the received headers, and ssh in and start a disk erase (dd urandom as above).

    I don't think I can see the address of the server because I used OhMySMTP for the delivery of the email. The originating IP is 46.252.181.46 which according to Maxmind is in France, owned by Squark Sarl

    I'm betting on this having been held in a queue for some reason. If the server IP isn't in the headers that means you don't have a Received header showing the actual datetime of that, it's usually all in one header but it's written by the next server in line, or in this case not written.

  • emgemg Veteran

    The lesson learned here is that whenever you are done with anything that held any of your data on it, you should personally wipe it, destroy it, or otherwise deal with it appropriately before you return or dispose it. I never trust someone else to take care of that detail, and you should not either.

    Example:
    I bought a "Certified Pre-Owned" Honda about three years ago. Despite the fact that Honda officially cleared, wiped, and reset everything to new condition, I was able to uncover residual personal information about the previous driver and their family. It did not require "leet haxor skilz" to find that data. Just a very thorough persistence.

    Thanked by 1Arkas
  • @emg said: I bought a "Certified Pre-Owned" Honda about three years ago. Despite the fact that Honda officially cleared, wiped, and reset everything to new condition, I was able to uncover residual personal information about the previous driver and their family. It did not require "leet haxor skilz" to find that data. Just a very thorough persistence

    Try to examine the back seat of your Honda with a UV light. Chances are you will find some more
    residual personal information about the previous driver :wink:

Sign In or Register to comment.