root@ubuntu:~# lsof -lMnP -i tcp:27665
COMMAND PID USER FD TYPE DEVICE SIZE NODE NAME
portsentr 8590 0 17u IPv4 12862 TCP *:27665 (LISTEN)
PID 8590 says its argv[0] is portsentr, Portsentry. because it's trivial to change the name of the running process, in case of doubt, you should verify the location of the binary by listing the contents of the PID dir: "ls -l /proc/8590/exe" or "stat -c %N /proc/8590/exe". It should point to the regular directory you've installed Portsentry in. This doesn't give you onehundred percent surety. If you have a filesystem integrity checker like Aide, Samhain or even tripwire installed you should use that to verify next. If you haven't, but your distro has a package manager that can validate package contents by checksum that would be your second choice.
Does this look normal to you?
Yes, it looks normal. Except you shouldn't run Portsentry but Snort. Portsentry, IMNSHO, is a piece of cr*p. Check out any of my threads here where I've made a comparison.
(..) but I really want to know IF I have a trojan, THEN how can I remove it.
Malicious code can for instance be introduced into the system because source code gets infected (OpenSSH, TCP Wrappers, Sendmail, Debian, NonGNU), because the system has a vulnerability or because someone asks them to.
Mass infection, the first case, usually doesn't live long if there are enough developers or users checking it. If any gets through then developers and distro maintainers are to blame for not checking the integrity of their systems and code timely enough. As user about the only thing you can do is to not use unofficial packages, check package GPG-sums before installing and check source package contents. From the users perspective this basically is a question of trusting upstream chains to "do it right". Given the fact we all have the tools for verifying source code, maybe we shouldn't. (Lack of time kills this)
In the second case users are to blame for not hardening or upgrading the system. Period. The third case again is a question of trust: do you really know someone's intentions well enough to accept a binary over IM/DCC/whatever else and run it? Most likely not.
In the second case the trojan was put there for a distinct reason, usually is to hide one's activities on the system or learn more, and we can assert it's not standalone but part of a rootkit which eases installing and configuring. We can also assert a rootkit to have defensive capabilities to "protect" the cracker in case something goes wrong.
Take the fact a box was compromised using an exploit and not knowing for how long the system was not owned by you and not knowing what the cracker has learnt, simply removing one trojan doesn't equal damage control. Unfortunately there is no single "best" way to deal with compromises, so we usually default to having people list processes and network connections (untrusted output) and then powering off the box fast and only ever powering it on using a bootable LiveCD, like for instance KNOPPIX, to start investigation (in colo this aint gonna work ofcourse). Now the system is "dead" it is easier to find anomalies in the system and work from there. In most cases unfortunately trust can only be restored onehundred percent by repartitioning, reformatting and reinstalling from scratch, changing all passwords and properly hardening the box. Wanna know more? Check out the
LQ FAQ: Security references.
HTH
