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.
Comments
thanks guys. After filtered out some info from access.log. I got this part. does it show something useful?
Nov 3 14:46:26 WLS-CAT sshd[1351]: Invalid user nan from 222.43.200.55 Nov 3 14:46:26 WLS-CAT sshd[1351]: input_userauth_request: invalid user nan [preauth] Nov 3 14:46:29 WLS-CAT sshd[1351]: pam_unix(sshd:auth): check pass; user unknown Nov 3 14:46:29 WLS-CAT sshd[1351]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=222.43.200.55 Nov 3 14:46:31 WLS-CAT sshd[1351]: Failed password for invalid user nan from 222.43.200.55 port 3323 ssh2 Nov 3 14:46:50 WLS-CAT sshd[1353]: error: Could not load host key: /etc/ssh/ssh_host_ecdsa_key Nov 3 14:46:55 WLS-CAT sshd[1353]: Accepted password for root from 222.43.200.55 port 3325 ssh2 Nov 3 14:46:55 WLS-CAT sshd[1353]: pam_env(sshd:setcred): Unable to open env file: /etc/default/locale: No such file or directory Nov 3 14:46:55 WLS-CAT sshd[1353]: pam_unix(sshd:session): session opened for user root by (uid=0) Nov 3 14:46:57 WLS-CAT sshd[1367]: error: lastlog_get_entry: Error reading from /var/log/lastlog: Expecting 292, got 1 Nov 3 14:46:57 WLS-CAT sshd[1367]: pam_env(sshd:setcred): Unable to open env file: /etc/default/locale: No such file or directory Nov 3 14:47:19 WLS-CAT useradd[1380]: new user: name=nan, UID=0, GID=0, home=/bin, shell=/bin/sh Nov 3 14:47:19 WLS-CAT useradd[1380]: add 'nan' to group 'root' Nov 3 14:47:19 WLS-CAT useradd[1380]: add 'nan' to shadow group 'root' Nov 3 14:47:20 WLS-CAT useradd[1385]: new user: name=porasd, UID=0, GID=0, home=/bin, shell=/bin/sh Nov 3 14:47:20 WLS-CAT useradd[1385]: add 'porasd' to group 'root' Nov 3 14:47:20 WLS-CAT useradd[1385]: add 'porasd' to shadow group 'root' Nov 3 14:47:25 WLS-CAT passwd[1390]: pam_unix(passwd:chauthtok): password changed for nan Nov 3 14:47:31 WLS-CAT passwd[1391]: pam_unix(passwd:chauthtok): password changed for porasd Nov 3 14:47:32 WLS-CAT sshd[1353]: pam_unix(sshd:session): session closed for user rootinvalid user and [preauth]? Does this log mean anything?
this is the part, user 'nan' got the root pass and add himself to root group.
If root was broken into by bruteforce, I will have nothing to say. complex 10 digits are not secured to some extend. But if it's not bruteforce the password, what could be possible for a fresh OS in a VPS installed by VPS povider technician and got compromised.
Indeed, nothing is emailed upon reinstallation but that doesn't matter. Since the OP doesn't even log into his box he won't know whether the root password is changed or not.
10 digits is quite secure over the wire. If the provider has their database compromised then fine, those passwords could be brute forced pretty quickly, but to suggest that a 10 digit password can be compromised over the net, and allowed to... seems unrealistic.
That date, someone trying to login, and using the host.key and created the user 'nan'.
'nan' user, also having root privileges, that's why your server keep sending ddos. Someone having access to your vps.
If, this is fresh install, then how can this happen if the os template not compromised?
Try to reinstall it again, list all user by using # cat /etc/passwd
Delete the one you not recognize, and run Minstall to minimalize the system
Because his VPS was not reinstalled again this time around, we unsuspended it and left the VPS intact to allow him to investigate the logs...
Ah.. That's a very nice help there
Maybe the vps should be isolated from the network/internet for a while, and only can be accessed via vnc/console, to prevent another ddos attempt.
sounds like a plan, lend me one of yours~ xD
Hehehe... Which one?
Login via solus, use the console and do "ifconfig down eth0/venet0"
Now the vps can be access via console only.
Why not look through your access logs to see if anyone else has logged in? or set a root forwarder with
echo [email protected] > /root/.forwardThen you will get notified when anyone logs into ssh via email.
rather than a DDoS, it could be a DNSAmplification attack, if you had an improperly configured bind running on your server earlier.
you can gain access to your vps by requesting the password from your host and then follow this
http://www.cyberciti.biz/faq/dnstop-monitor-bind-dns-server-dns-network-traffic-from-a-shell-prompt/
if its a DDoS attack, you need to setup IPTables or some other firewall.
do let me know the proceeds
I have had an issue like this with a customer, after 3 weeks of signing up, outbound DDOS.
Customer had never logged in so did not feel responsible, however:
This is a self managed service so you have a duty of care to secure the server
Customer signed up with a stupid password like 'changme' which is probably 3rd on any dictionary attack list after password and root and then left port 22 with root login enabled by act of making no effort to secure the server.
So in my eyes this was completely their fault, never the less I explained the situation reinstalled the OS and shut the server down right after, only to find that 2 days later the same thing had happened, they had booted the server ran apt-get update and nothing else.
Some people simply should not have self managed servers as they become gateways for hacking other servers and you in turn give 50 other people a very bad day
Perhaps none of that rings true in this case, I dont know, it is possible because for absolutley NO GOOD REASON some hosts deploy templates pretending to be minimal with an un secured bind install on them along with apache/samba etc and the server gets used in an amplification attack as said above, if this is the case then sorry but it is your hosts fault for making Zero effort with initial setup.
I always said that VPS should be provision in shutdown state.
It's unrealistically to expect that everyone will start to work with vps immediately after recieving vps login mail. People don't just sit at home waiting to recieve this mail sometimes.
There could be some "hey, my vps is down" unnecessary ticketing but that's mainly because bad industry standards to provision vps in booted up state.
Jarland suggested this previously but DNS amplification is not the case. This was a script that sends outbound D(D)oS that was found running on his server.
@Spirit Yep that is a fair point, I might put that feature request in or work out if I can script something myself.
Never seen that b26 process before. Nothing on google. Maybe random file name. Either way yeah, undeniably comp'd.
than you need to do change the password and then do a fresh install and then immediately setup root or ssh login to send you a mail, and then setup iptables to secure
any progress?
could you resolve the issue...
Way too many hosts do this, I don't get. I think its pure laziness on there part.
simple solution: Give him a new ip, same problem accrues then there's been a breach on the host's part or he's just lying.
The other VPS I have from WLS got ddos attacked 2 days ago. the customer support said it was attacked internally. I don't know if another guy in the same subnet got the same problem but now I've got all 2 VPss from them upgraded. All password has been reset. I left them still on running state to wait to see if it's going to be ok.
beside the problem I met, it seems OpenVZ templates always have apache2 installed by default. I always uninstall apache2 and other components that I don't use when I get a VPS. xD
did you check the traffic and the running processes