Hi guys,

I'm a newbie, so any help is appreciated.
Running chkrootkit on one of my CP server gives me this result... What should i do? Is this really a security flaw? Please help...!!!

Checking `bindshell'... INFECTED (PORTS: 114 145 465)

Here is my netstat result

# netstat -lpn
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name
tcp 0 0 0.0.0.0:993 0.0.0.0:* LISTEN 24047/stunnel-4.04l
tcp 0 0 0.0.0.0:1 0.0.0.0:* LISTEN 10080/portsentry
tcp 0 0 0.0.0.0:2082 0.0.0.0:* LISTEN 24062/cpsrvd - wait
tcp 0 0 0.0.0.0:5666 0.0.0.0:* LISTEN 9872/xinetd
tcp 0 0 0.0.0.0:2083 0.0.0.0:* LISTEN 24047/stunnel-4.04l
tcp 0 0 0.0.0.0:995 0.0.0.0:* LISTEN 24047/stunnel-4.04l
tcp 0 0 0.0.0.0:2086 0.0.0.0:* LISTEN 24062/cpsrvd - wait
tcp 0 0 0.0.0.0:2087 0.0.0.0:* LISTEN 24047/stunnel-4.04l
tcp 0 0 0.0.0.0:3306 0.0.0.0:* LISTEN 8278/mysqld
tcp 0 0 0.0.0.0:6666 0.0.0.0:* LISTEN 10018/startmelange
tcp 0 0 0.0.0.0:110 0.0.0.0:* LISTEN 5767/cppop - accept
tcp 0 0 0.0.0.0:2095 0.0.0.0:* LISTEN 24062/cpsrvd - wait
tcp 0 0 127.0.0.1:783 0.0.0.0:* LISTEN 17157/spamd.pid --m
tcp 0 0 0.0.0.0:143 0.0.0.0:* LISTEN 9872/xinetd
tcp 0 0 0.0.0.0:111 0.0.0.0:* LISTEN 10080/portsentry
tcp 0 0 0.0.0.0:2096 0.0.0.0:* LISTEN 24047/stunnel-4.04l
tcp 0 0 0.0.0.0:80 0.0.0.0:* LISTEN 31860/httpd
tcp 0 0 0.0.0.0:465 0.0.0.0:* LISTEN 592/exim
tcp 0 0 0.0.0.0:21 0.0.0.0:* LISTEN 8035/pure-ftpd (SER
tcp 0 0 0.0.0.0:23 0.0.0.0:* LISTEN 5622/sshd
tcp 0 0 0.0.0.0:25 0.0.0.0:* LISTEN 586/exim

Thankyou.

Those aren't "normal" ports, so, if you've got something listening on them, then I'd say there's a pretty strong chance that yes, your server has been infected and hacked. Find a systems administrator and have them clean the server out if at all possible, or reload the OS, after backing all of your accounts up.

Hi,

Thank you Linux-tech, but is there any other option to sort out this issue. The server has more than about 540 accounts and i don't really prefer an OS reload.

Will closing all these ports help the situation...?

Port 465 seems to be used by Exim. Should i close this also?

I googled for the solutions but could hardly find one... WHT is only the hand i see for a help.

Thank you.

Try rkhunter.

Can you verify using nc or telnet that those ports are actually open and whats on them?

check your udp ports

Hi,

Classic <- The rkhunter output was OK and there were no errors and no vulnerabilities. Telnet to these ports were timed out but nc is listening.

Linuxguy <- I think the UDP is working there but how can i confirm..? I have blocked UDP also but still not sure about that.

Is there any way to check the vulnerability of these ports...?

Thank you.

netstat -lnupe

"WHT is only the hand i see for a help."
If you don't know what you're doing, you're going to end up screwing your own server up anyways. Not only YOUR own server, but the accounts on it.

WHT isn't here to take the place of experience, or to supply you with skilled administration experience. Unfortunately, that's the mistake that most make, assuming they can just open up a server, without the proper experience, come here when something like this happens, thusly putting their own clients at risk.

As for the hack itself, it depends on the severity of it, whether or not I'd recommend formatting. In this case, given the common description of a bindshell:

This utility allows users to open an interactive shell over a port, bypassing all system logging, thus making it possible for users to stealthy administer a machine.


Because of the mere definition of this, and the function of this, you can't trust ANY of the system binaries at this point. Bindshell does just what it's supposed to do, it provides a shell for users to do whatever they want with your system, INCLUDING replacing system binaries and the like.

The not so good part to this is this also can be run as a perl script, which means it doesn't ALWAYS have to listen to the port, it can simply listen to the port when the end user calls this.

One thing you can do to prevent this is have a decent ruleset for mod_security, adding bindshell to the list, adding bash, rsh, etc to the list as well, but that may end up causing problems as well as preventing them.

To get rid of this, you're going to have to find out WHERE it came from, and what kind of damage it has done, before making a full assessment. That's not something that the group here @ WHT can help you with, as that can only be done by someone with a good few years of experience in the field :)

I am not saying anything, just there is something about it here:
http://www.webhostgear.com/25.html

Originally posted by linux-tech
Because of the mere definition of this, and the function of this, you can't trust ANY of the system binaries at this point. Bindshell does just what it's supposed to do, it provides a shell for users to do whatever they want with your system, INCLUDING replacing system binaries and the like.

Only if it's running as root.

If it's really listening on the ports mentioned, then yes, the server has been rooted (those are ports below 1024). It seems possible that it's a false alarm from the script not recognizing exim, though.

I agree, the OP needs an experienced server admin to actually work with the server directly, as soon as possible. WHT is no substitute for that.

Kevin

Hmm I can see portsentry.. If it was not there .. I could have confirm that its a hack..

Originally posted by zma229
Hmm I can see portsentry.. If it was not there .. I could have confirm that its a hack..
Portsentry's only as good as the configuration. By default on CPanel servers, the only ports that are monitored are 1,111, and NO udp ports are enabled.

I think you have ips in the server ending with 145 and 114, becuase chkrootkit uses something like this to check the bindshell

netstat -an |grep "[.:]${P}[^0-9.]"

where P is the ports listed in this variable

PORT="114|145|465|511|600|1008|1524|1999|1978|2881|3049|3133|3879
|4000|4369|5190|5665|10008|12321|23132|27374|29364|30999|31336|
31337|45454|47017|47889|60001"

I think this code will assume

192.168.1.114:80 ( 80 can be any other usual ports) as bindshell infected rather than 192.168.1.114:114

Regarding the 465 port it will be exim