Linux - SecurityThis forum is for all security related questions.
Questions, tips, system compromises, firewalls, etc. are all included here.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
Hi!
My machine is trying to communicate with another computer. Iīve blocked the traffic with this machine with iptables (input and output traffic), but I want to find the origin of this traffic. Thereīre 90% of probabilities itīs a trojan, and I want to find it.
I have logged the packets with iptables (and then dropped), but with this I donīt know the proccess source.
Iīve tried with netstat -o, but I donīt get nothing.
How can I see the Process source (i.e. the PID) of this traffic?
The traffic are TCP packets, with SYN flagged active (my machine is trying to establish a connection with that IP).
...or as root run 'lsof -Pwlni tcp'. If nothing works and the process doesn't appear to be in the process table (beware of processes changing their argv[0] to something seemingly innocuous) then I suggest you shut down the machine and boot a Live CD. That won't get you the traffic but it does give you a better chance to find out what's wrong. If you reply details about the machine (distro, release, kernel, accessible services, applications in the web stack if any) would be welcome.
I think I've a problem. My apache is trying to establish a connection with this IP (and is the only one).
I've done a google of this ip, reverse lookup (dig -x), and nothing. Maybe one of my CMS is infected. I suspect of zen photo, because it appears in apache log, connections between this IP and setup.php of zen photo.
Does 'readlink -f /proc/3838/exe' show the process to be your regular Apache binary? If not then what? If it is Apache, what anomalies do your access and error log show?
Quote:
Originally Posted by darkxer0x
I think I've a problem. My apache is trying to establish a connection with this IP (and is the only one). I've done a google of this ip, reverse lookup (dig -x), and nothing.
It's registered as being in the Republica Moldova?
Quote:
Originally Posted by darkxer0x
Maybe one of my CMS is infected. I suspect of zen photo, because it appears in apache log, connections between this IP and setup.php of zen photo.
Please don't talk about issues but instead post exact error messages, log lines, your exact version of Zenphoto, if you protected the setup directory through mod_security or .htaccess files, et cetera.
This thread is marked as solved? I see no solution or remediation. :/
I asked "Find process which generates TCP packets", and this is solved. I marked the post as solved because if one person search "find process generate TCP packet", can see this post, and that question is solved.
Quote:
Originally Posted by unSpawn
Does 'readlink -f /proc/3838/exe' show the process to be your regular Apache binary? If not then what? If it is Apache, what anomalies do your access and error log show?
Yes, it's the binary of apache:
Code:
readlink -f /proc/30411/exe
/usr/sbin/apache2
The same apache as others web process. And /usr/sbin/apache2 is OK, because I've run debsums:
Code:
debsums -a apache2-mpm-prefork
/usr/sbin/apache2 OK
About the anomalies, I have this in access.log:
Code:
./error.log.1:[Tue Dec 07 21:31:28 2010] [error] [client 89.187.53.226] File does not exist: /var/www/zp-core
./error.log:[Fri Dec 17 03:48:52 2010] [error] [client 89.187.53.226] File does not exist: /var/www/zp-core
./access.log:89.187.53.226 - - [17/Dec/2010:03:48:52 +0100] "GET /zp-core/setup.php HTTP/1.0" 404 215 "-" "Wget/1.11.4 Red Hat modified"
./access.log:89.187.53.226 - - [17/Dec/2010:03:48:52 +0100] "GET /fotos/zp-core/setup.php HTTP/1.0" 200 5929 "-" "Wget/1.11.4 Red Hat modified"
./access.log:89.187.53.226 - - [17/Dec/2010:03:48:53 +0100] "POST /fotos/zp-core/setup.php HTTP/1.0" 200 6367 "-" "Wget/1.11.4 Red Hat modified"
./access.log:89.187.53.226 - - [17/Dec/2010:03:48:54 +0100] "POST /fotos/zp-core/setup.php HTTP/1.0" 200 5929 "-" "Wget/1.11.4 Red Hat modified"
./access.log:89.187.53.226 - - [17/Dec/2010:03:48:54 +0100] "POST /fotos/ HTTP/1.0" 200 9865 "-" "Wget/1.11.4 Red Hat modified"
./access.log.1:89.187.53.226 - - [07/Dec/2010:21:31:27 +0100] "POST / HTTP/1.0" 200 175 "-" "Wget/1.11.4 Red Hat modified"
./access.log.1:89.187.53.226 - - [07/Dec/2010:21:31:27 +0100] "POST /fotos/ HTTP/1.0" 200 9859 "-" "Wget/1.11.4 Red Hat modified"
./access.log.1:89.187.53.226 - - [07/Dec/2010:21:31:28 +0100] "GET /zp-core/setup.php HTTP/1.0" 404 215 "-" "Wget/1.11.4 Red Hat modified"
I'm not the maintainer of the web, so I didn't know that setup.php of the CMS zen photo was not deleted. When I saw this, I deleted. If you run setup.php, you can see all the version details os the machine (OS version, apache and php version...). Although you can't execute because is password protected.
Quote:
Originally Posted by unSpawn
It's registered as being in the Republica Moldova?
Yes. The reputation of the IP-range is not very good. See this post
Quote:
Originally Posted by unSpawn
Please don't talk about issues but instead post exact error messages, log lines, your exact version of Zenphoto, if you protected the setup directory through mod_security or .htaccess files, et cetera.
I've post above the acces.log with the lines of that IP. About zen photo, the version is 1.2.2 [2983]. Setup directory is not protected, but if you want to install, you have to enter a password in setup.php. It's as zen photo "worked" by default.
I'm going to talk to the web maintaner to update all the web software's versions of the machine. This version of zen photo is from 2008...
I'm going to talk to the web maintaner to update all the web software's versions of the machine. This version of zen photo is from 2008...
Remember you started this thread because Apache was making connections (instead of just answering) it should not. Depending on (apparent lack of) maintenance and (mis-)configuration of the system and how low this has been gone undetected it would be better to first investigate and ensure integrity of the system before removing and installing software. Also please note that while deleting things is an understandable reflex it is not automagically the good one (think then act) because deleting things also wipes out any traces. Basically that would only benefit the miscreants.
Remember you started this thread because Apache was making connections (instead of just answering) it should not.
I started this thread beacause an unknown process was making connections. Now, I know itīs apache.
Quote:
Originally Posted by unSpawn
Depending on (apparent lack of) maintenance and (mis-)configuration of the system and how low this has been gone undetected it would be better to first investigate and ensure integrity of the system before removing and installing software. Also please note that while deleting things is an understandable reflex it is not automagically the good one (think then act) because deleting things also wipes out any traces. Basically that would only benefit the miscreants.
The file I deleted, setup.php, was only moved out of the web directory. And the first thing I did was see what it contained. And it contained nothing stranged. And the modification time was the same as the others files in setup directory.
As you said, it would be better to first investigate and ensure integrity of the system. Iīm investating the source, but I have to ensure the integrity of the system. Thatīs why Iīm going to update all the software. Iīll make a backup of all the current files, but having old software itīs not good for the integrity of the system.
The first thing I did was search the IP in all the web files, but it didnīt appear anything.
Iīve got the backtrace of the process, and I get:
Code:
#0 0x00007fa747889b9f in poll () from /lib/libc.so.6
#1 0x00007fa741095871 in php_network_connect_socket ()
from /usr/lib/apache2/modules/libphp5.so
#2 0x00007fa741095b5d in php_network_connect_socket_to_host ()
from /usr/lib/apache2/modules/libphp5.so
#3 0x00007fa7410a4e6f in ?? () from /usr/lib/apache2/modules/libphp5.so
#4 0x00007fa740ec962f in ?? () from /usr/lib/apache2/modules/libphp5.so
#5 0x00007fa741098d99 in ?? () from /usr/lib/apache2/modules/libphp5.so
#6 0x00000000025a8c98 in ?? ()
#7 0x0000000000000012 in ?? ()
#8 0x0000000000000000 in ?? ()
Zen photo is under /var/www/fotos, the same CWD (current working directory) as process 3838. What a coincidence!! xDD
Of course port 8086 is open in 89.187.53.226...
The file I deleted, setup.php, was only moved out of the web directory. And the first thing I did was see what it contained. And it contained nothing stranged. And the modification time was the same as the others files in setup directory.
All good then.
Quote:
Originally Posted by darkxer0x
Iīll make a backup of all the current files, but having old software itīs not good for the integrity of the system.
I see no reason for doing that unless you have somehow established the machine was compromised, and then making backups would be done solely for investigative purposes. Certainly not for restoring the machine to a certain (compromised) state later on...
Quote:
Originally Posted by darkxer0x
but I have to ensure the integrity of the system. Thatīs why Iīm going to update all the software.
What I mean is that you have to make certainbefore you update. Updating itself does not ensure there are no issues and that integrity is intact.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.