I finally solved it, i should remark that the image attached in the question was showing outbound packets sent, not due to any ddos attack but because of the traffic generated when rebooting in "rescue mode".
These are the steps i took to solve it:
1- Start on rescue mode fron the online.net console.
2- ssh on "rescue mode" and mount the problematic file system, note that your device could differ from the following sample command:
$ mount /dev/sda2 /mnt
3- Check logs in the server:
$ cat /var/log/syslog
$ cat /var/log/dmesg
$ cat /var/log/messages
$ cat /var/log/fail2ban.log
$ cat /var/log/auth.log
Additionally your apache2 access.log, and/or any other critical logs in your system.
4- Search for any file modified a day or two before the attack:
$ find /mnt -mtime -3 -ls
5- Check the system for rootkits (rkhunter) or virus (clamav)
As I could not find anything suspicious I checked if there was any kind of remote access service in the online.net console ( i wish i had thought of this before) and so it was. Then i reboot in normal mode and i could check that the system was not booting due to errors in /dev/sda2. To solve it i rebooted in rescue mode and did a
$ fsck2 /dev/sda2
There were some corrupted inodes, i replied Yes to repair them all.
6- Then i rebooted the system again, but the boot process got stock at "cleaning temporary files". To solve it i changed TMPTIME to 60 in the following file:
/etc/default/rcS
Note: Remember to resolve this issue and put back this setting to 0 on successful login, leaving TMPTIME to remove tmp files older than 60 days is a security risk
7- After a few minor errors i could finally login, put the needed settings back to defaults, and rescan the entire system with rkhunter and clamav, apt-get update && apt-get upgrade and a last reboot.
The system now is clean and running again.