Cybersecurity

@Neo

Yes it's a web server, here's the details server spec:

- OS: Centos 5
- Web server technology: Apache PHP 5.3.19 & MySQL 5
- Mail: Exim with SMTP & PHP Mailer enabled


About 10 domains hosted in it.

Sorry, I'm not too expert on Linux system, thats why I need to ask the best way on how to deal with server that has been turned on to be botnet, rather than just build or re-install the whole system from zero.

Do anyone of you never deal with case like this before??

OK, it is more than likely the hacker got into your site based on a weakness in your web server file system. Of course, we can't be sure from what we know, but that is normally the case.

So, now we need to know about the web app. Is it written in PHP? PERL? Something else? Is there a database?

In other words, you more than likely need to rebuild your OS from scratch and install your web app again; but from what you are telling me, you are not even sure if your web file system in clean or not.

And, if you don't know much about this technology, it is going to be very difficult for you to secure the filesystem so it does not happen again.

So, there you have it. I've given you the basic answer. But if you insist you don't "really know what you are doing", then the best advice I can give you is to go out and find someone who does and pay them to do it if it is a business app.

Is it a critical business app? Or just a personal "for fun" web app?

@ Neo

It's only serve for PHP, no Perl. But there are Perl & Python installed also. Database only in MySQL.

I only know the little thing about Linux, but I do know what I'm doing. Don't you read what I have did on my procedural above? Do you think what I have done with my server has no effect at all?

So, what should I do, what should I type in terminal prompt to clean and get rid of this rat??

It's not a critical bussiness app, it's my company server to host portfolio webs for advertisement.

Why not start by enumerating what actually runs on top of the web server? Get the exact names and versions of whatever web log, forum, shopping cart, photo gallery, statistics, web-based management panel, homebrewn scripts and plugins the system runs. Then verify those against what the vendor accepts as "current". Together with user login information and a report of anomalies or "odd" requests from daemon log files you have a pretty good idea if that is the avenue to explore further or not.

It's not that simple as "what should I type in the terminal to get rid of the rat", as many have tried to explain to you; it is a detailed process of understanding your application, your filesystem and what has been compromised, etc.

There is no "short cut' or "easy way" as every person who have replied has generously mentioned to you.

Well, in that case, just rebuild from scratch and make sure your run something like tripwire on your baseline install so you can see what exactly was changed if it happens again.

There are no short cuts to insuring filesystem integrity; the work has to be done as we have been telling you.

You are seemingly looking for an "easy way out" of a situation that has no "easy way out" since you don't have backups and you don't manage your file system integrity; you must rebuild from scratch to be secure and safe.

And then, do it right the next time with backups and file system integrity checking, and make sure your permissions and filesystem is secure against web-based attacks.

It is a lot of work! There are no short cuts!

@ Unspawn
I dont use any additional 3rd party applications at all other than just Java application for chat.

@ Neo
Yes, I come here to look for easy way for quick response.

I have got your answer, you suggest me to use that tripwire to secure my /tmp. But, that's just a long term action, I need "short quick response actions" for this. Anything like blocking port 6667 & 7000 effectively, prevent IRC script from running, etc.


Talking about the web vulnerabilities:

# If it's about SQL injection attack, when someone got the credential login like Cpanel/FTP or Admin login, what can he do other than just playing around with C99/R57 shell??

# If he playing with C99/R57 shell, how can he runs exploit coded in C, where GCC is disabled for user?

# If he runs exploit not coded in C, but coded in Perl, then successfully rooting my server, then I think this is a big security hole in Centos 5!

# If he got MySQL login from particular user, how can he write files in /root, where particular user (MySQL) only has USAGE privileges? If it has nothing to do with MySQL privileges, then how he wrote files in /root other than exploited the server?

# Result from RKHunter & ClamAV shows that /dev and /tmp are the only directories which are suspicious. I have tried to look for any information on the net but no luck.

I think I have explain all things what I know about the main web server vulnerabilities. So what else to check other than that?

If there's no satisfy answers from ppl in this forum, I think this will be my last post. I'm tired. I think I'm just asking for simple question, but none answered my question at all. Wonder if in this big UNIX forum, no one ever dealt with IRC botnet. Huft..

Thanks all.

Do you understand that your server has been deeply compromised?

Do you understand that, if you've been rooted, you cannot trust the operating system anymore?

Do you understand that this may be why the quick fixes you've tried have had no effect? And even the sophisticated ones.

If you cannot trust this system to do what you tell it to, you cannot trust any of the quick fixes. They don't need gcc to upload C commands, just somewhere to write files and chmod. He doesn't need your compiler, he can use his own, and just upload the binary. All he needs is a way to set it executable.

If you deny him chmod, he can still just cp /bin/sh /path/to/my/executable ; cat my_binary_code > /path/to/my/executable. Perl, a C/C++ program, is neither more secure, nor less secure, than C/C++ itself. In any case it's not the language that grants things permissions to do things, it's the operating system itself.

Locking them to a specific language is not security. Denying them the permissions they need to do anything untoward in any language is security. There is no rubber chicken we can wave that will make your infestation go away. If you haven't been rooted, you might be able to hunt down the files with find /tmp/ and picking through them by hand. It is vital for finding and dealing with filenames that cannot be typed in the terminal, since you can refer to files by inode.

Check /proc/pid/ for the rogue processes in question. If they don't show at all, you've been rooted. If they do, /proc/pid/fd might reveal what files they're running from.

There might be a firewall rule to drop those outgoing ports, but how to do so depends on what your firewall is already and what your network setup is.

And if you have been rooted, then your OS itself, the thing which you're using to try and track down and fight this problem, is the thing that's been infected. Catch-22. Many of us have. This is how we know it's not as easy as you'd like. You know the saying, an ounce of prevention is worth a pound of cure?

You say you have no backups, too. This may be a good time to back up your customer data, but check it carefully when you restore.