A DDoS attack on a newly activated VPS.

Time flies, and we've already stepped into April. The holy month of Ramadan, a time of blessings and spiritual victory, has passed us by this year (2025).

With full awareness and sincerity, whether we know each other well or only in passing by, if I have ever wronged you in any way, through words or actions, I sincerely apologize. May all our deeds during Ramadan be accepted, and may we continue to grow into better individuals with open hearts and good intentions.

In short story.

This is the first time such an incident has happened on a VPS that I purchased and personally manage. That doesn’t mean I’ve never encountered a DDoS attack—in fact, with over 9 years of experience in the hosting provider industry, I’ve faced this many times. And I truly understand the impact it can have on a hosting provider.

This is the second VPS I’ve purchased. I just activated this VPS on April 5th, 2025 at 06:37. The reason I bought this VPS is because I plan to move all the applications from my first VPS to this newly purchased one.

After the VPS was activated, I immediately proceeded with the setup until all main applications were running normally, following the same standards that had been implemented on the previous VPS.

Setup VPS.

Since the VPS was newly purchased, there were many things that needed to be set up. One of them was creating multiple users to separate the ownership of the running applications. I also had to set up CI/CD to ensure that the development and release processes for the applications could run smoothly.

And once everything was ready, I proceeded to point the domain DNS for each application. Almost everything went smoothly, but there was one case I temporarily forgot how to set up — configuring Node.js for multiple users. This was because I used NVM (Node Version Manager) for installing Node.js.

In general, NVM can be installed per user. However, this becomes an issue when a deployment is running through the CI/CD pipeline, because Node.js is not detected under the user being used for deployment. The root cause was that the Node.js binary was not recognized in the system’s PATH.

Because I felt it would be very complicated to register the binary file to the PATH for every user, I decided to install Node.js under the root user and place the binary files in a directory accessible to all users.

The oddness began.

Because this website([ www.okumaru.my.id ]) has traffic tracking and the data is stored on the new VPS, I intended to check the traffic. However, I couldn’t access the data, and I also couldn’t open SSH. Eventually, I found out that the VPS was suspended due to a suspected DDoS attack.

I received this information via email on April 7th, 2025, at 14:22. I then requested to have the VPS unsuspended so that I could perform a cleanup on it.

It’s cleanup time.

When I first checked the running processes, there were immediately some strange processes running that didn’t belong to all my application.

After logging into that user and checking the running processes under it, I found even more strange processes that seemed suspicious.

This means that the newly activated VPS has already been accessed by unauthorized parties. And I need to pay attention to that.

Cleaning up unknown processes.

This step needs to be repeated several times. Because when we find processes that don’t belong to the OS or applications, and delete them, sometimes those processes will reappear automatically. So, it’s necessary to remove the processes completely, down to their root.

Cleaning up files/folders that don’t belong to your OS or applications.

Here lies the confusion about where these files and folders are located. There will definitely be many files and folders, and it’s not always clear which ones are needed by the OS. We might recognize the files and folders belonging to our applications since we created them ourselves. Therefore, it’s important to be very careful when cleaning up these files and folders.

Sometimes, what I usually do is check the details of the strange processes first. Then, I investigate those processes further. That way, we can find out where the related files or folders are located.

Ensuring correct access permissions to the VPS.

At this stage, what needs to be done is to reset all passwords (especially the SSH passwords). You also need to check the SSH keys registered for each user, because those keys can still allow access to the VPS even after the passwords have been changed.

Ensuring no automation is running.

Automation sometimes runs in various ways and can take many forms. From what I understand, there are two main types,

1. Idle proses.
2. Crontab.

Both have different ways of being used, but their functions are similar. Idle processes are suspended processes, mostly used to trigger new processes. Crontab is an OS service used to schedule and trigger specific tasks.

This part is the most dangerous and needs to be checked multiple times. Because if automation that doesn’t belong to the OS or our applications is running, the processes, files/folders, and access permissions that we’ve cleaned up will reappear..

Is that enought?

Of course not, this checking needs to be done multiple times and the more regularly, the better.

Root Cause DDoS Attack.

The cause of the DDoS attack on this new VPS was that I once used a very easy-to-guess password for one of the Linux users I created. Previously, I had already limited which Linux users could access SSH, but due to lack of attention, this vulnerability occurred.

Conclusion

I once underestimated simple passwords. Especially when using them on a public internet server that anyone can access. It’s like leaving your house key under the doormat right in front of your door.

Get used to using a password manager, which can generate, store, and autofill strong and unique passwords for your accounts.

1. generate password.
2. password encryption.
3. copy/paste password easly.

And finally, I am currently using passwordstore.org as my password manager.