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.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
Need immediate help, got this email from OVH
I received this:
Dear Customer,
As your server nsxxxxxxx.ip-91-xxx-xxx.eu is presenting too great a threat to our network,
we had no choice but to place it in 'rescue FTP' mode. An email
containing a username and password has been sent to you so that so you can
easily retrieve any data still located in the storage space.
Please do not hesitate to contact our technical support so that this
situation does not become critical.
You can find the logs brought up by our system below which led to this alert.
- START OF ADDITIONAL INFORMATION -
Attack detail : 123Kpps/45Mbps
dateTime srcIp:srcPort dstIp:dstPort protocol flags bytes reason
2017.10.26 06:01:46 CEST 91.xxx.xxx.xxx:23609 91.1.66.121:22 TCP SYN 48 ATTACK:TCP_SYN
2017.10.26 06:01:46 CEST 91.xxx.xxx.xxx:23609 91.1.66.164:22 TCP SYN 48 ATTACK:TCP_SYN
2017.10.26 06:01:46 CEST 91.xxx.xxx.xxx:23609 91.1.66.174:22 TCP SYN 48 ATTACK:TCP_SYN
2017.10.26 06:01:46 CEST 91.xxx.xxx.xxx:23609 91.1.66.180:22 TCP SYN 48 ATTACK:TCP_SYN
2017.10.26 06:01:46 CEST 91.xxx.xxx.xxx:23609 91.1.66.190:22 TCP SYN 48 ATTACK:TCP_SYN
2017.10.26 06:01:46 CEST 91.xxx.xxx.xxx:23609 91.1.66.194:22 TCP SYN 48 ATTACK:TCP_SYN
2017.10.26 06:01:46 CEST 91.xxx.xxx.xxx:23609 91.1.66.200:22 TCP SYN 48 ATTACK:TCP_SYN
2017.10.26 06:01:46 CEST 91.xxx.xxx.xxx:23609 91.1.66.210:22 TCP SYN 48 ATTACK:TCP_SYN
2017.10.26 06:01:46 CEST 91.xxx.xxx.xxx:23609 91.1.66.216:22 TCP SYN 48 ATTACK:TCP_SYN
2017.10.26 06:01:46 CEST 91.xxx.xxx.xxx:23609 91.1.67.36:22 TCP SYN 48 ATTACK:TCP_SYN
2017.10.26 06:01:46 CEST 91.xxx.xxx.xxx:23609 91.1.67.46:22 TCP SYN 48 ATTACK:TCP_SYN
2017.10.26 06:01:46 CEST 91.xxx.xxx.xxx:23609 91.1.67.52:22 TCP SYN 48 ATTACK:TCP_SYN
2017.10.26 06:01:46 CEST 91.xxx.xxx.xxx:23609 91.1.67.62:22 TCP SYN 48 ATTACK:TCP_SYN
2017.10.26 06:01:46 CEST 91.xxx.xxx.xxx:23609 91.1.67.66:22 TCP SYN 48 ATTACK:TCP_SYN
2017.10.26 06:01:46 CEST 91.xxx.xxx.xxx:23609 91.1.67.72:22 TCP SYN 48 ATTACK:TCP_SYN
2017.10.26 06:01:46 CEST 91.xxx.xxx.xxx:23609 91.1.67.82:22 TCP SYN 48 ATTACK:TCP_SYN
2017.10.26 06:01:46 CEST 91.xxx.xxx.xxx:23609 91.1.67.88:22 TCP SYN 48 ATTACK:TCP_SYN
2017.10.26 06:01:46 CEST 91.xxx.xxx.xxx:23609 91.1.67.133:22 TCP SYN 48 ATTACK:TCP_SYN
2017.10.26 06:01:46 CEST 91.xxx.xxx.xxx:23609 91.1.67.143:22 TCP SYN 48 ATTACK:TCP_SYN
2017.10.26 06:01:46 CEST 91.xxx.xxx.xxx:23609 91.1.67.149:22 TCP SYN 48 ATTACK:TCP_SYN
- END OF ADDITIONAL INFORMATION -
Kind regards,
OVH Customer Support
Best regards,
I checked my kimsufi control panel and the status of that server is Hacked
.
Can someone tell me what to do so I can recover? I never experince this situation. Thanks
Thanked by 166ccff
Comments
SYNs. How..1996. You can download your data off the machine using the username and password they gave you. Download it, and reinstall from the OS level, if given the option.
So, reinstalling is the only way. Can I somehow boot that server up and stop those flooding (or whatever it is called) ?.
bad luck (((
@psycholyzern If they've put you into "Hacked" mode, it means the machine compromised is too much of a liability to let it run.
You can but since you ask that question I assume you are not a Linux adminstrator with enough knowledge to succeed.
To avoid this happening again, download your important data and reinstall. Secure your server before adding your data back.
.
Okay I understand. I already made a backup yesterday. What I can't afford to lose is my MySQL data for today. I am following some tutorial on the net to backup my database via ftp. Hope all data is intact.
Btw, can someone tell me what happened to my server? I saw
SYN
word before and it is some type of flood or DDOS? I opened port 22 a few days back after having problem connecting to SFTP via other port. Forgot to close it back. It is the cause? Port 22 is listed in those logsDownload your /var/lib/mysql or compatible data they've given you access to in FTP. Your database may already be corrupt, in which case you will need to pay to have someone recover anything since your last backup.
Google SYN Flood.
Did you ignore multiple notices from them about this? I've never heard of them placing a server into their rescue/FTP mode without giving an alert first, mostly since it's almost certainly going to be an automated block/notice. Did you unblock the IP if it got blocked multiple times?
Yeah, I guess. Luckily I learnt from the past and make frequent backup.now I just need to worry about my database T_T
Thanks. I never knew that SYN thing can make this situation happen. I'm crossing my finger hoping I can get my latest data in database working.
Filthy subconscious.
Because your system was flooding other machine SSH ports. Your machine was being used to DDoS Deutsche Telekom hosts.
Much like his userland.
If you can't secure your server properly, better hire someone to do it. And who the hell host important data on a KS anyway?
Lol you made me laugh in this worrisome situation
Doesn't look like ddos to me. Looks like a ssh scan/bruteforce
Oh. So it is really got hacked. Sigh.
I'll take your comment as an advice so I can improve. I am in no money-making business, so hire someone is not an option.
My type of important data might not be important to you. I'm doing stuff for fun, but consider the data as important because I put my hardwork into it and many users using my service. It is important, but not sensitive mostly.
When I read the excerpt, I assumed it was rolling through x.x.y.y, but seeing only a set of hosts above, rather than sequentially? Looks kind of targeted to me; I assume there wouldn't be huge holes in the IP space.
From my experience it is rare for these to be exactly sequential. I presume it comes down to spawning a bunch of threads - not processing in order.
Also - these logs are likely samples rather than a whole flow, so we can expect some missing data.
Well, storage VPS are usually cheap. Get two of them in separate locations and replicate your data here.
I do frequent backup and last one was yesterday. But I need to save the data in database for today. I'm not worry about the files at all. But now I am backing up stuff from /etc /var and some files in /home/user, not because I am worry, but just to double check I have everything before doing reinstallation (yes I always forgetting something).
If you are talking about having several point of live backup so it can takeover when the main server is down, that part is too advance for me. Anyway, thanks.
Sometimes I forget that it isn't 1996 anymore.
This is why managed services exist, there is no such thing as "immediate help" with OVH.
Some people expectation is too much about OVH, as they are unmanaged service and it’s mean don’t expect any help with running your server as it’s your problem and issue with luck of skills!
That not that hard to do, even i can do it, and i am green as hell..
Google "tcp three way handshake". A SYN packet is how two hosts open a session with TCP. A SYN initiates the connection and expects an SYN,ACK response. The traffic above is simply scanning for SSH hosts (per that evidence, it might be attempting to login if it finds a host, but that isn't in the data above.
That is called live replication and the mysql manual explains how to do it. In your case it would be best to keep the replica server firewalled so it has no connection to the internet at all, but only to the primary server.
In fact usually it's preferable to not have the primary db server on the internet either: firewall it completely so it has just a 10.* address, so it can only be accessed from inside the OVH network. Then use an OVH-hosted VPS connected to the db, to run any public-facing services.
You should consider some of the managed server options offered here. To be frank i don't believe you understand the steps required to secure and maintain a server long term. Additionally downtime is expensive. Get a personal vps for testing and learning. Lock it down on the firewall then tunnel what you need via ssh and change the default ssh ports. Install nethog and play with locking the server down more. Once your comfortable there your can consider managing your own server
"Additionally downtime is expensive."
No one gives a shit, if a server goes down, except when something kinda critical like Lowendtalk is running on it. And then, you do not buy a Kimsufi or you setup failover.
You buy a KS, a WSI and a DO in singapore and setup failover. Cloudflare and the like are an option on top of that too.
What do you do when all three are down at once, though?
Make your client aware that such downtime CAN happen before he signs the contract. Atleast that's what I tell them face to face everytime (talking about my webhosting clients).