Hi Edwin
Sorry I forget to reply-all. thanks a lot for the detailed
information.
chkrootkit/rkhunter seems ok, only three of them not ok:
shopping:/proc# chkrootkit
shopping:/proc# rkhunter --checkall --skip-keypress
* Application version scan
- Exim MTA 3.36 [ OK ]
- GnuPG 1.2.4 [ Old or
patched version ]
- OpenSSL 0.9.7e [ Old or
patched version ]
- PHP 4.4.4 [ Unknown ]
the ping22 came after I reboot the machine, enabled SELinux. I only
enable apache.pp mysql.pp, my locale.pp at this time.
shopping:/proc# semodule -l
apache 1.4.0
local 1.0
mysql 1.3.0
my locale.te may not be good, I rushed to enable SELinux only at
yesterday. I guess with a good SELinux rules it should be able to constrain
the ping22 even to run.
allow fsadm_t self:process execmem;
allow hostname_t var_run_t:dir search;
allow httpd_t dict_port_t:tcp_socket name_connect;
allow httpd_t http_cache_port_t:tcp_socket name_connect;
allow httpd_t http_port_t:tcp_socket name_connect;
allow httpd_t httpd_sys_content_t:file { setattr write };
allow httpd_t httpd_sys_script_exec_t:dir { getattr read search };
allow httpd_t httpd_sys_script_exec_t:file { execute execute_no_trans
getattr ioctl read };
allow httpd_t self:process { execmem execstack };
allow httpd_t lib_t:file execute_no_trans;
allow httpd_t man_t:dir { getattr search };
allow httpd_t man_t:file { getattr lock read };
allow httpd_t man_t:lnk_file read;
allow httpd_t port_t:tcp_socket { name_bind name_connect };
allow httpd_t proc_net_t:dir search;
allow httpd_t proc_net_t:file { getattr read };
allow httpd_t shell_exec_t:file { execute execute_no_trans getattr read };
allow httpd_t smtp_port_t:tcp_socket name_connect;
allow httpd_t unlabeled_t:dir { getattr search };
allow httpd_t unlabeled_t:file { getattr read };
allow httpd_t var_lib_t:dir setattr;
allow httpd_t var_log_t:file { append getattr };
allow httpd_t var_spool_t:dir { add_name remove_name write };
allow httpd_t var_spool_t:file { append create getattr lock read rename
setattr unlink write };
allow httpd_t var_t:dir read;
allow httpd_t var_t:file { getattr read };
allow hwclock_t tmpfs_t:dir search;
allow iptables_t self:process { execmem execstack };
allow iptables_t var_lib_t:dir search;
allow mount_t initrc_var_run_t:dir { getattr mounton };
allow mysqld_t default_t:dir { add_name getattr read search write };
allow mysqld_t default_t:file { create getattr read write };
allow mysqld_t httpd_sys_script_exec_t:dir { getattr search };
allow syslogd_t device_t:fifo_file { ioctl read write };
allow syslogd_t self:process { execmem execstack };
allow syslogd_t var_lib_t:dir search;
68.87.64.146 is not my ip.
since I killed that ping22, I can not do the coredump at this time. I
remembered I check the proc/<PID>/fd, there is nothing ping22, and also did
lsof, could not find ping22.
For now I will keep the SELinux locale.t as it is, hope ping22 will exploit
my machine again, then I will try to get something as you suggested, and
keep it posted on the mailing list.
regards.
Mike
On Dec 30, 2007 3:54 PM, Török Edwin <[EMAIL PROTECTED]> wrote:
> Mike Wang wrote:
> > Hi edwin
>
> Hi Mike,
> [btw did you mean to cc the debian-security mailing list, or you want to
> keep this conversation private?]
>
> >
> > the pstree and ps showed the parent is 1 ( init)
> >
> > tried kill -9 again, this time is got killed. strange!
>
> Maybe because you rebooted and enabled selinux?
> Try running chkrootkit, and rkhunter, maybe you'll find something.
>
> > I tried to kill it serveral times before. here is the previous
> > screen capture.
>
> I believe you tried ;)
>
> > shopping:/# ps -ef | grep ping
> > www-data 16430 1 12 13:56 ? 00:00:00 ping22
> > root 16522 30331 0 13:56 pts/0 00:00:00 grep ping
> > shopping:/# kill -9 16430
> > shopping:/# ps -ef | grep ping
> > www-data 16848 1 16 14:01 ? 00:00:00 ping22
> > root 16851 30331 0 14:01 pts/0 00:00:00 grep ping
> >
> > the ping22 may be come back in the future. I'm recently
> > troubled by this ping22. when it was there, I even could not login
> > from the console except I reboot the machine.
> >
> > And After I put the SELinux there ( put some rules there), the
> > harm is mitigated, since SElinux do not allow it to do {
> > name_connect } .
> >
> > Dec 30 15:12:00 shopping kernel: audit(1199045520.032:629753): avc:
> > denied { name_connect } for pid=16848 comm="perl" dest=6667
> > scontext=system_u:system_r:httpd_t:s0
> > tcontext=system_u:object_r:ircd_port_t:s0 tclass=tcp_socket
> >
> > The better way seems need to find how this ping22 get started
> > in the first place.
>
> Yes.
>
> > from the apache2 access.log I seems could not find it.( I am
> > not an expert on this) , and I could not find the ping22 file.
> >
> >
> > Also I did the strace for this before, not sure if it can help
> > to find what is ping22.
> >
> > sin_addr=inet_addr(" 68.87.64.146 <http://68.87.64.146>")}, [16]) = 49
>
> Assuming this is your DNS.
> > connect(20, {sa_family=AF_INET, sin_port=htons(6667),
> > sin_addr=inet_addr("217.141.180.221 <http://217.141.180.221>")}, 16) =
> > -1 EACCES (Permission denied)
> > send(20, "M+\1\0\0\1\0\0\0\0\0\0\3irc\7ircgate\3net\0\0\1\0"..., 33,
> > 0) = 33
>
> It seems to be connecting to irc.ircgate.net, maybe some irc bot. You
> could temporarely add it to your hosts file, and set up netcat on a
> machine in your LAN.
> Then see what it is sending.
>
> While it is running, try to see what filedescriptors it has open in
> /proc/<PID>/fd, maybe it still has the original file (ping22), and you
> can dump it to see what it does.
>
> Another possibility would be to attach to the running ping22 (perl), and
> tell it to core-dump (after enabling ulimit -c unlimited).
> Then open the core dump with a hexeditor (or vi), and look for a perl
> file inside.
>
> Best regards,
> --Edwin
>
>
>
>
>
