All: I have SuSE 8.1 Profesional running on a machine that appears to have port 33270 open. I found this as a result of running "saint". Saint reports this to be a possible problem. Description: Trinity is a Distributed Denial of Service tool that is controlled by IRC. In the version that the X-Force has been analyzing, the agent binary is installed on a Linux system at /usr/lib/idle.so. When idle.so is started, it connects to an Undernet IRC server on port 6667 What to do: Scan all systems for port 33270 connections. If any connections are found, telnet to that port and type "!@#". A system has been compromised if there is a root shell present after a successful connection to port 33270 In doing the above from another SuSE linux machine I get: #telnet linuxmachine 33270 Trying 172.20.1.99... Connected to linuxmachine. Escape character is '^]'. and then typing the "!@#" I get: Connection closed by foreign host. While this is good. I don't know what on my system is responding to this port. An "lsof -i TCP:33270" returns nothing. netstat -ea shows tcp 0 0 *:33270 *:* LISTEN root 31464 Can anybody tell me if I should start to panic! Or what this could be. Thanks - Paul
Hi Paul !
While this is good. I don't know what on my system is responding to this port. An "lsof -i TCP:33270" returns nothing.
netstat -ea shows tcp 0 0 *:33270 *:* LISTEN root 31464
Can anybody tell me if I should start to panic! Or what this could be.
--> If you use "netstat -pat", it will show you process ID and program name. So you might get a clue as to which program is listening on port 33270. Try to find the corresponding binary with "find / -name ProgramName". HTH, Armin -- Am Hasenberg 26 office: Institut für Atmosphärenphysik D-18209 Bad Doberan Schloss-Straße 6 Tel. ++49-(0)38203/42137 D-18225 Kühlungsborn / GERMANY Email: schoech@iap-kborn.de Tel. +49-(0)38293-68-102 WWW: http://armins.cjb.net/ Fax. +49-(0)38293-68-50
Amin, Thanks for the info but, I think no luck. The output to the netstat -pat is; # netstat -pat|grep 33 tcp 0 0 *:33270 *:* LISTEN - No program name and no PID. Thanks again - Paul On Wednesday 07 May 2003 03:34, Armin Schoech wrote:
Hi Paul !
While this is good. I don't know what on my system is responding to this port. An "lsof -i TCP:33270" returns nothing.
netstat -ea shows tcp 0 0 *:33270 *:* LISTEN root 31464
Can anybody tell me if I should start to panic! Or what this could be.
--> If you use "netstat -pat", it will show you process ID and program name. So you might get a clue as to which program is listening on port 33270.
Try to find the corresponding binary with "find / -name ProgramName".
HTH, Armin -- Am Hasenberg 26 office: Institut für Atmosphärenphysik D-18209 Bad Doberan Schloss-Straße 6 Tel. ++49-(0)38203/42137 D-18225 Kühlungsborn / GERMANY Email: schoech@iap-kborn.de Tel. +49-(0)38293-68-102 WWW: http://armins.cjb.net/ Fax. +49-(0)38293-68-50
Hi Paul!
# netstat -pat|grep 33 tcp 0 0 *:33270 *:* LISTEN -
No program name and no PID.
This might be a silly question, but did you do this as root? Netstat doesn't show other users' processes when not executed as root. Bye, Stefan --
Hi Paul,
Thanks for the info but, I think no luck. The output to the netstat -pat is;
# netstat -pat|grep 33 tcp 0 0 *:33270 *:* LISTEN -
No program name and no PID.
That's strange. Didn't you already have a PID in your output:
netstat -ea shows tcp 0 0 *:33270 *:* LISTEN root 31464
--> I guess "31464" is the PID ? Someone pointed already out you need to run netstat as root. Or try (as root) "ps -ax | grep 31464". Armin -- Am Hasenberg 26 office: Institut für Atmosphärenphysik D-18209 Bad Doberan Schloss-Straße 6 Tel. ++49-(0)38203/42137 D-18225 Kühlungsborn / GERMANY Email: schoech@iap-kborn.de Tel. +49-(0)38293-68-102 WWW: http://armins.cjb.net/ Fax. +49-(0)38293-68-50
Armin, The number 31464 corresponds to the Inode column when using netstat -ea Thanks - Paul Hi Paul,
Thanks for the info but, I think no luck. The output to the netstat -pat is;
# netstat -pat|grep 33 tcp 0 0 *:33270 *:* LISTEN -
No program name and no PID.
That's strange. Didn't you already have a PID in your output:
netstat -ea shows tcp 0 0 *:33270 *:* LISTEN root 31464
--> I guess "31464" is the PID ? Someone pointed already out you need to run netstat as root. Or try (as root) "ps -ax | grep 31464". Armin -- Am Hasenberg 26 office: Institut für Atmosphärenphysik D-18209 Bad Doberan Schloss-Straße 6 Tel. ++49-(0)38203/42137 D-18225 Kühlungsborn / GERMANY Email: schoech@iap-kborn.de Tel. +49-(0)38293-68-102 WWW: http://armins.cjb.net/ Fax. +49-(0)38293-68-50
FWIW netstat -patn|grep 33270 gives me: Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name tcp 0 0 0.0.0.0:33270 0.0.0.0:* LISTEN - (I added the headers in for clarity) Thanks Again - Paul Hi Paul,
Thanks for the info but, I think no luck. The output to the netstat -pat is;
# netstat -pat|grep 33 tcp 0 0 *:33270 *:* LISTEN -
No program name and no PID.
That's strange. Didn't you already have a PID in your output:
netstat -ea shows tcp 0 0 *:33270 *:* LISTEN root 31464
--> I guess "31464" is the PID ? Someone pointed already out you need to run netstat as root. Or try (as root) "ps -ax | grep 31464". Armin -- Am Hasenberg 26 office: Institut für Atmosphärenphysik D-18209 Bad Doberan Schloss-Straße 6 Tel. ++49-(0)38203/42137 D-18225 Kühlungsborn / GERMANY Email: schoech@iap-kborn.de Tel. +49-(0)38293-68-102 WWW: http://armins.cjb.net/ Fax. +49-(0)38293-68-50 -- Check the headers for your unsubscription address For additional commands, e-mail: suse-security-help@suse.com Security-related bug reports go to security@suse.de, not here
On Thursday 08 May 2003 00:12, Paul Kozlenko wrote:
FWIW netstat -patn|grep 33270 gives me:
Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name tcp 0 0 0.0.0.0:33270 0.0.0.0:* LISTEN - (I added the headers in for clarity)
You're probably running a kernel which has the fix for the ptrace hole. The downside of that fix was that even root doesn't seem to have the right to show the information for all processes anymore, for example if I look at nfs which uses port 2049 I see the same, there is no PID or Program name shown for that port. On my systems I also see such lines for high ports, I don't know which process uses them, but you should be able to find that out by shutting them down one by one and watch when that port disappears. -- GertJan Email address is invalid, so don't reply directly, I'm on the list.
On Wednesday 07 May 2003 18:58, GertJan Spoelman wrote:
On Thursday 08 May 2003 00:12, Paul Kozlenko wrote:
FWIW netstat -patn|grep 33270 gives me:
Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name tcp 0 0 0.0.0.0:33270 0.0.0.0:* LISTEN - (I added the headers in for clarity)
You're probably running a kernel which has the fix for the ptrace hole. The downside of that fix was that even root doesn't seem to have the right to show the information for all processes anymore, for example if I look at nfs which uses port 2049 I see the same, there is no PID or Program name shown for that port. On my systems I also see such lines for high ports, I don't know which process uses them, but you should be able to find that out by shutting them down one by one and watch when that port disappears. --
GertJan
Email address is invalid, so don't reply directly, I'm on the list.
My kernel version is Linux version 2.4.19-4GB (SuSE 8.1 Professional) How do I find out if this has the "ptrace hole" fix? - Paul
On Wednesday 07 May 2003 22:31, Paul Kozlenko wrote:
On Wednesday 07 May 2003 18:58, GertJan Spoelman wrote:
On Thursday 08 May 2003 00:12, Paul Kozlenko wrote:
FWIW netstat -patn|grep 33270 gives me:
Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name tcp 0 0 0.0.0.0:33270 0.0.0.0:* LISTEN - (I added the headers in for clarity)
You're probably running a kernel which has the fix for the ptrace hole. The downside of that fix was that even root doesn't seem to have the right to show the information for all processes anymore, for example if I look at nfs which uses port 2049 I see the same, there is no PID or Program name shown for that port. On my systems I also see such lines for high ports, I don't know which process uses them, but you should be able to find that out by shutting them down one by one and watch when that port disappears. --
GertJan
Email address is invalid, so don't reply directly, I'm on the list.
My kernel version is Linux version 2.4.19-4GB (SuSE 8.1 Professional) How do I find out if this has the "ptrace hole" fix?
- Paul
More info (... reminder to self, always check log files ....) /var/log/warn contains a line: May 7 22:00:07 machinename kernel: lockd: connect from unprivileged port: 172.20.43.21:52353 For each attempted connect. This is a good thing that this is detected. YES? Does it mean that I am safe though? - Paul
On Thursday 08 May 2003 04:31, Paul Kozlenko wrote:
On Wednesday 07 May 2003 18:58, GertJan Spoelman wrote:
On Thursday 08 May 2003 00:12, Paul Kozlenko wrote:
FWIW netstat -patn|grep 33270 gives me:
Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name tcp 0 0 0.0.0.0:33270 0.0.0.0:* LISTEN - (I added the headers in for clarity)
You're probably running a kernel which has the fix for the ptrace hole. The downside of that fix was that even root doesn't seem to have the right to show the information for all processes anymore, for example if I look at nfs which uses port 2049 I see the same, there is no PID or Program name shown for that port. On my systems I also see such lines for high ports, I don't know which process uses them, but you should be able to find that out by shutting them down one by one and watch when that port disappears.
My kernel version is Linux version 2.4.19-4GB (SuSE 8.1 Professional) How do I find out if this has the "ptrace hole" fix?
Check the changelog of your kernel package, the first entry here says: - fix ptrace security hole you can extract the changelog by doing: rpm -q --changelog <name_of_installed_kernel_package> You probably have a k_deflt kernel rpm package installed, the exact name and version you can find by: rpm -qa | grep k_deflt The latest which I have is k_deflt-2.4.19-274 and that has the fix. On Thursday 08 May 2003 04:41, Paul Kozlenko wrote:
More info (... reminder to self, always check log files ....)
/var/log/warn contains a line: May 7 22:00:07 machinename kernel: lockd: connect from unprivileged port: 172.20.43.21:52353
For each attempted connect. This is a good thing that this is detected. YES? Does it mean that I am safe though?
I don't think so, it's only detected and logged. -- GertJan Email address is invalid, so don't reply directly, I'm on the list.
On Thursday 08 May 2003 02:55, GertJan Spoelman wrote:
On Thursday 08 May 2003 04:31, Paul Kozlenko wrote:
On Wednesday 07 May 2003 18:58, GertJan Spoelman wrote:
On Thursday 08 May 2003 00:12, Paul Kozlenko wrote:
FWIW netstat -patn|grep 33270 gives me:
Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name tcp 0 0 0.0.0.0:33270 0.0.0.0:* LISTEN - (I added the headers in for clarity)
You're probably running a kernel which has the fix for the ptrace hole. The downside of that fix was that even root doesn't seem to have the right to show the information for all processes anymore, for example if I look at nfs which uses port 2049 I see the same, there is no PID or Program name shown for that port. On my systems I also see such lines for high ports, I don't know which process uses them, but you should be able to find that out by shutting them down one by one and watch when that port disappears.
My kernel version is Linux version 2.4.19-4GB (SuSE 8.1 Professional) How do I find out if this has the "ptrace hole" fix?
Check the changelog of your kernel package, the first entry here says: - fix ptrace security hole you can extract the changelog by doing: rpm -q --changelog <name_of_installed_kernel_package>
You probably have a k_deflt kernel rpm package installed, the exact name and version you can find by: rpm -qa | grep k_deflt The latest which I have is k_deflt-2.4.19-274 and that has the fix.
On Thursday 08 May 2003 04:41, Paul Kozlenko wrote:
More info (... reminder to self, always check log files ....)
/var/log/warn contains a line: May 7 22:00:07 machinename kernel: lockd: connect from unprivileged port: 172.20.43.21:52353
For each attempted connect. This is a good thing that this is detected. YES? Does it mean that I am safe though?
I don't think so, it's only detected and logged. --
GertJan
Email address is invalid, so don't reply directly, I'm on the list. The kernel patch level on this machine is 74 not 274. Am I that far behind? Anyhow. No reference to "ptrace" when I do an rpm -q --chnagelog k_deflt.
A netstat -ean shows one piece of info - the inode is "31464". Does this equal the inode for a file. If so 31464 is the inode for a directory. In my case "/usr/libexec/webmin/mscstyle3/acl/images". I haven't rebooted the machine yet. I don't want to unless this is a threat. Thanks Again - Paul
On Friday 09 May 2003 04:57, Paul Kozlenko wrote:
The kernel patch level on this machine is 74 not 274. Am I that far behind? Anyhow. No reference to "ptrace" when I do an rpm -q --chnagelog k_deflt.
Well, then it's not a ptrace problem.
A netstat -ean shows one piece of info - the inode is "31464". Does this equal the inode for a file. If so 31464 is the inode for a directory. In my case "/usr/libexec/webmin/mscstyle3/acl/images".
I think that's not the inode from your disk filesystem but probably from the procfs, but I'm only guessing here.
I haven't rebooted the machine yet. I don't want to unless this is a threat.
Can't you, like I suggested earlier, just shutdown one process at the time and see if and when that port disappears, I would start with nfs and rpc or if you're running X shut that down first. That way you don't have to reboot (what's wrong with that anyway), you can just start the processes again later. -- GertJan Email address is invalid, so don't reply directly, I'm on the list.
On Wed, 2003-05-07 at 07:52, Paul Kozlenko wrote:
Amin, Thanks for the info but, I think no luck. The output to the netstat -pat is;
# netstat -pat|grep 33 tcp 0 0 *:33270 *:* LISTEN -
No program name and no PID.
Thanks again - Paul
Try again WITHOUT grep. The program name is listed on the line below and grep will aviod the information you are looking for. -- Ken Schneider linux user since 1994 SuSE user since 1998
On Wed, May 07, 2003 at 08:57:28AM -0400, Ken Schneider wrote:
# netstat -pat|grep 33 tcp 0 0 *:33270 *:* LISTEN -
No program name and no PID. Try again WITHOUT grep. The program name is listed on the line below and grep will aviod the information you are looking for.
nope. it may apear so on your console (wrap around), but it is one single line. and if there is no program listed, you are either not privileged enough to see it, or it is no program, but a kernel module :( congrats, you might have one of those kernel module root kits... Lars
participants (6)
-
Armin Schoech -
GertJan Spoelman -
Ken Schneider -
Lars Ellenberg -
Paul Kozlenko -
Stefan Fritsch