• If you are still using CentOS 7.9, it's time to convert to Alma 8 with the free centos2alma tool by Plesk or Plesk Migrator. Please let us know your experiences or concerns in this thread:
    CentOS2Alma discussion

May this be a trojan?

N

Nicochet

Guest
Hi everybody,

I have the following problem. Last days my recently new installed plesk, started to be extremely slow in serving pages, mails, etc. After login, and some investigation, i found trough "netstat" several connections to away servers on ports 6667 and 6669. I started to define a rule in the firewall, to stop communication to that ports.

The thing is that i have very few clients, and the firewall is setup from the beginnig. I am behind a router (the public IP), and the only ports open are 80, 21, 8443, and 53. All other ports are closed. So it seems the connections are made from inside. The OS is a Centos 4.4, and is a stand alone server, i mean, there is no local users, nor other aplications running on it.

After defining the new rule in plesk firewall, connections have dissapeared, except a "Syn Sent" to a foreign server throug port 6667. Obviously, connection never happen, because the rule is set to forbid outgoing connections to that ports (6667 and 6669), but i don´t know how to eliminate that trojan or whatever it is . The process which try to connect in that way, is ran by apache user, and the command is "httpd -DSSL". Even when i reboot, that process is always trying to connect to 194.68.45.50 and 149.9.1.16 port 6667. I tried to kill the process which tried the connection, but it doesn't work.

Here are the "suspicious" lines shown by netstat:

tcp 0 1 192.168.0.1:33028 194.68.45.50:6667 SYN_SENT 5186/httpd -DSSL on (81,02/5/0)
tcp 0 1 192.168.0.1:33068 149.9.1.16:6667 SYN_SENT 5186/httpd -DSSL on (14,59/5/0)

It seems that remote ip changes from time to time, but the procees is always the same (5186).

Any ideas? Please, any help will be very useful.

Thanks in advance.
 
Yeah, definitely something malicious. That is someone launching this process through an exploitable web application on your server.
 
Is there any way to find out which application is doing that? I installed one of each free application included in PLesk as a demo on my main site. If i disable the domain that hold all that, perhaps it'll stop?
 
Hi again,

Finally I found it. It was a file called y2kupdate, which was on the cron of the apache user. I don´t know how the hell has it arrives to my server, and even modified the apache's cron. Ayway, it seems to be solved now. i have deleted the entire application containing the file, disable the domain, and restored the apache's cron. I have checked out the log, that there aren't changes made in the passwd file, nor unauthorized access to the server. This time, i think i've been lucky. If you find a file called y2kupdate, please be careful.

Thanks Atomicturtle for your answer.
 
That y2kupdate cron is only part of the compromise, what is happening is that some application on the system is allowing the attackers to insert that job, and their malicious code on the system. So you've gotten rid of the immediate problem, the next part is to find out which application is responsible.

First thing I would do is look at the timestamp on the cron job to see when it was added. This will let you narrow down the date for the next step, which is to search your logs for malicious activity. Things like perl, uname, id, y2kupdate, etc. When you start these investigations before you start killing processes, or modifying anything, you want to collect as many pieces of data from the attack that would help narrow down your search.

Next step is making an inventory of all the versions of the applications on the system, and then looking those up in secunia.com or securityfocus.com for vulnerabilities. Odds are that you've got more than one app to worry about here.
 
hi,

Im afraid you're right. I've been away for the weekend, but now, i continue having problems with connections to the outside, and the apache cron is now clean. I'll keep trying to find all the pieces, and where is the open door. Thanks again.
 
Sounds like its an IRC botnet or something, Ive seen a lot of those attempts recently. Among other things, restrict access to programs like wget to root user - that may not solve your problem but that makes it harder for them to download files to your machine.

You should also look into mod security as that can also help mitigate any remote file include attacks which most botnets and defacing tool script kiddies use.
 
Hi,

After one week, the problem seems to be solved. I found several files in one of my domains, that create the task in the apache's cron. Curiously that domain did not host any application from plesk. Anyway it is very extrange, because the file that was called to be ran by cron was in a different domain than the origin of the problem. The logs shows that there are not changes in the password file. By revieqing the logs, it seems to have been a XSS atack, and that they introduces commands through the url. I still don't know how they uploaded those files, perhaps by ftp, i am still looking for it, but there was no extrange connections in the last week, and evrything is going well right now, so i think the problem is solved by the moment.

Thanks to all for your advices.
 
Either each one of those domains has something exploitable, or they've compromised the system and rootkitted it.

It wouldn't be unusual for multiple attackers to compromise the same vulnerable host either.
 
Make sure you limit access to GET, lwp-*, *cc*, *++*, lynxx, elinks, and all those types of apps that get from remote hosts and compile. Also look into mod_security :)

A simple example of what I have used in the past is:
Code:
chmod 711 /
chmod 711 /home
chmod 711 /etc
chmod 711 /var
chmod 711 /usr/etc
chmod 711 /usr/local/etc
chmod 711 /var/log
chmod 711 /sbin
chmod 711 /usr/sbin
chmod 711 /usr/local/sbin

chmod 644 /etc/motd

groupadd deva
chmod 750 /usr/bin/wget
chown root:deva /usr/bin/wget
chmod 750 /usr/bin/perlcc
chown root:deva /usr/bin/perlcc
chmod 750 /usr/bin/byacc
chown root:deva /usr/bin/byacc
chmod 750 /usr/bin/yacc
chown root:deva /usr/bin/yacc
chmod 750 /usr/bin/cc
chown root:deva /usr/bin/cc
chmod 750 /usr/bin/gcc
chown root:deva /usr/bin/gcc

chmod 700 /bin/dmesg
chmod 700 /bin/mount
chmod 700 /bin/rpm
chmod 700 /usr/bin/write
chmod 700 /usr/bin/talk
chmod 700 /usr/bin/ipcrm
chmod 700 /usr/bin/ipcs
chmod 700 /usr/bin/free
chmod 700 /usr/bin/locate
chmod 700 /usr/bin/wall
chmod 700 /usr/bin/finger
chmod 700 /sbin/arp
chmod 700 /sbin/ifconfig
chmod 700 /usr/sbin/repquota
chmod 700 /usr/sbin/tcpdump
chmod 700 /usr/bin/nmap
chmod 700 /usr/bin/wget
chmod 700 /usr/bin/perlcc
chmod 700 /usr/bin/byacc
chmod 700 /usr/bin/yacc
chmod 700 /usr/bin/cc
chmod 700 /usr/bin/gcc
chmod 700 /usr/bin/who
chmod 700 /usr/bin/w
chmod 700 /usr/bin/nc

chmod 1733 /tmp/.ICE-unix
chmod 1733 /tmp/.X11-unix
chmod 660 /var/run/utmp

chmod 000 /usr/bin/rcp
chmod 000 /usr/bin/links
chmod 000 /usr/bin/scp
chmod 000 /usr/bin/elinks
chmod 700 /usr/bin/lwp-*
chmod 000 /usr/bin/GET
chmod 700 /usr/bin/curl
chmod 700 /usr/bin/*++* 
chmod 700 /usr/bin/*cc*
chmod 700 /usr/bin/yum 
chmod 700 /usr/bin/up2date 
chmod 700 /usr/sbin/up2date


chmod u-s /usr/bin/at
chmod u-s /usr/bin/chage
chmod u-s /usr/bin/chfn
chmod u-s /usr/bin/chsh
chmod u-s /usr/bin/crontab
chmod u-s /usr/bin/expiry
chmod u-s /usr/bin/gpasswd
chmod u-s /usr/bin/lppasswd
chmod u-s /usr/bin/newgrp
chmod u-s /usr/bin/rcp
chmod u-s /usr/bin/rlogin
chmod u-s /usr/bin/rsh
chmod u-s /usr/libexec/ssh-keysign

I dug that out of one of my archives, it may be outdated and some of those files may not exist based on what packages you had installed. You should also try this out on a dev machine first so that if there are any problems running your system your not affecting anything production.

It wont stop the determined but it makes their jobs harder.
 
Back
Top