I've just been looking through the logs of a recent client who has SSH access to their account and found the following:

Thu Sep 12 18:19:04 2002 42 www.xxxxxxxxx.xxx 197255 /home/admin/profile/sniffit.0.3.5.tar.gz

This program, from what i can see from searching around on the net is a port sniffer. Would this work under Ensim's chrooted environment? The account is on the verge of being removed for this anyway due to the fairly obvious intentions of the client

This is exactly why it is dangerous to give shell access.

I do realise the danger of this, and actually insisted on a a reason for requiring access and a copy of his drivers license before giving access. His access has now been removed though. Would this type of application work under Ensim's chrooted environment though?

Normally a packet sniffer will have to put the eth0: interface into promiscuous mode to work. That requires root access.

However, your point is well taken. Giving SSH (or Telnet) opens your machine up to a whole new set of exploits including
SUID root programs such as SENDMAIL , etc...

In general, it's probably better not to allow interactive shell access.

However, if one of your clients asks to upload content with FTP (that uses clear text passwords) it leaves your client accounts more vulnerable, meaning a cracker might get a foothold in your server thru one of your clients


It may be better to allow SCP for this purpose, but set their shell to /bin/false so that can't use the account interactively....

In the end it's a matter of weighing the risks:

(1)Don't take on clients with questionable content (warez, cracks, etc.)

(2)Minimize the access you give to them

OK, I've been doing some more checking and his account has been removed. This was a definate hack attempt. I've run chkrootkit and it came up with bindshell as infected. I know that this can be reported incorrectly by port monitors, but I shut down psad and it still came up. PSAD also e-mailed me earlier with scan attempts from him on port 31337, which is the infected port that chkrootkit is reporting for bindshell. OK, I'm not a Unix expert by far, and would appreciate some advice on this as I don;t want to have to do a restore unless really necessary.

Firstly, I think I am right in thinking that for now I am fairly safe as IPTables / PSAD must be blocking the connection on that port to alert me of the fact? I appreciate that this needs to be fixed though. Netstat is showing something lsitening on that port, but I don't think that anyone can get to it past IPTables

Secondly, what exactly is Bindshell and how can I replace an infected copy of it with a good one? Would a reboot do any good?

I'm just about to add his IP address to deny in IPtables....

OK, to add to this I founb that netstat -l showed something listening on port 31337 - I ran TOP again and sorted the list and found two processes running under his admin number. I killed these PID's manually and re-ran chkrootkit and it's now showing as not infected. I'm feeling slightly relieved, but would still appreciate any information or advice on anything else to check. His account is now removed and I won't be giving SSH access to anyone else

Bindshell is not a legit Linux tool it is a cracker program (included in many rootkits) that is used to open a shell on a port. Most commonly it is used to exploit vulnerable wu-ftp anon-ftp servers to give the attacker ROOT telnet access after they attach to a port and type a password.

See this article:
http://www.iss.net/security_center/static/5179.php

Very Important:

(1)This tool cannot be successfully installed unless your server ALREADY HAD an exploitable service or SUID root program.

(2)There is a very high probability that your server has been ROOTED.

(3)If you haven't already, run CHKROOTKIT again using a trusted set of binaries. This is described in the CHKROOTKIT docs:

"chkrootkit uses the following commands to make its tests: awk, cut,
egrep, find, head, id, ls, netstat, ps, strings, sed, uname. It is
possible, with the `-p' option, to supply an alternate path to
chkrootkit so it won't use the system's (possibly) compromised
binaries to make its tests.

To use, for example, binaries in /cdrom/bin:

# ./chkrootkit -p /cdrom/bin

----- End quote ----

If you think you have a rootkit, you SHOULDN'T trust any of your
commands, since most rootkits mess with one or all of these cmds by replacing them with their own versions.
These new versions will then "hide" the presence of trojan processes
when you do a "ps" and even hide whole directories with "ls"

Create a trusted set of binaries (from a known clean system) from the required list above and invoke as:

# ./chkrootkit - p /root/trusted

where /root/trusted is where the trusted set resides


(4)If your system has been rooted, unfortunately you may not be able to track down everything that was done to it.
Your system had vulnerabilities that allowed this to take place.

Check your access logs, /etc/passwd and any other trails you can to try and verify (1)What was done (2)When it was done.

If you can, locate the source for the bindshell.c program. This should have the password required for root access on the port.
You might be able to verify that root access is possible by trying this password on the port.

Look other rootkits in hidden directories:
find / -type d -name ".*" -print

Run lastlog and verify all logins if possible


(5)After you have gathered as much information as possible I'm afraid that the best recourse is to have RH do a restore.

(6)After the restore :
(a)Make sure that every available patch for your box is installed
(b)Install Tripwire and Logsentry to keep track of these sort of incidents in the future and alert you of a compromise.

PSAD is great but in general won't protect you against a compromise unless it is done noisely. I like to think of PSAD as the lookout of a fort who tells the doorkeeper to shut the doors when it sees danger.

Tripwire and Logwatch are like the local police who detect crimes once they are inside the gates.