1

I have been running at high CPU loads 45 45 45 ish for a while, updated cpanel / apache so far but tracing PID's that are running I find the following all with the same IP..

[code]
select(8, [3], NULL, NULL, {0, 0})      = 0 (Timeout)
select(8, [3], NULL, NULL, {0, 0})      = 0 (Timeout)
select(8, [3], NULL, NULL, {0, 0})      = 0 (Timeout)
select(8, [3], NULL, NULL, {0, 0})      = 0 (Timeout)
select(8, [3], NULL, NULL, {0, 0})      = 0 (Timeout)
select(8, [3], NULL, NULL, {0, 0})      = 1 (in [3], left {0, 0})
read(3, "Disconnected\r\n", 4096)       = 14
select(8, [3], NULL, NULL, {0, 0})      = 1 (in [3], left {0, 0})
read(3, "", 4096)                       = 0
close(3)                                = 0
open("/etc/protocols", O_RDONLY)        = 3
fcntl(3, F_GETFD)                       = 0
fcntl(3, F_SETFD, FD_CLOEXEC)           = 0
fstat(3, {st_mode=S_IFREG|0644, st_size=6108, ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x2b31b555a000
read(3, "# /etc/protocols:\n# $Id: protoco"..., 4096) = 4096
close(3)                                = 0
munmap(0x2b31b555a000, 4096)            = 0
open("/etc/protocols", O_RDONLY)        = 3
fcntl(3, F_GETFD)                       = 0
fcntl(3, F_SETFD, FD_CLOEXEC)           = 0
fstat(3, {st_mode=S_IFREG|0644, st_size=6108, ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x2b31b555a000
read(3, "# /etc/protocols:\n# $Id: protoco"..., 4096) = 4096
close(3)                                = 0
munmap(0x2b31b555a000, 4096)            = 0
socket(PF_INET, SOCK_STREAM, IPPROTO_TCP) = 3
ioctl(3, SNDCTL_TMR_TIMEBASE or TCGETS, 0x7fff47b56000) = -1 EINVAL (Invalid argument)
lseek(3, 0, SEEK_CUR)                   = -1 ESPIPE (Illegal seek)
ioctl(3, SNDCTL_TMR_TIMEBASE or TCGETS, 0x7fff47b56000) = -1 EINVAL (Invalid argument)
lseek(3, 0, SEEK_CUR)                   = -1 ESPIPE (Illegal seek)
fcntl(3, F_SETFD, FD_CLOEXEC)           = 0
connect(3, {sa_family=AF_INET, sin_port=htons(443), sin_addr=inet_addr("50.57.187.242")}, 16) = 0
getsockname(3, {sa_family=AF_INET, sin_port=htons(34587), sin_addr=inet_addr("xx.xx.33.135")}, [1337692303350824976]) = 0
write(3, "NICK Linux\n", 11)            = 11
getsockname(3, {sa_family=AF_INET, sin_port=htons(34587), sin_addr=inet_addr("xx.xx.33.135")}, [1337692303350824976]) = 0
write(3, "USER g xx.xx.33.135 50.57.187.24"..., 37) = 37
time([1417021715])                      = 1417021715
rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) = 0
rt_sigaction(SIGCHLD, NULL, {0x1, [], SA_RESTORER|SA_NOCLDWAIT, 0x32a2c0eca0}, 8) = 0
nanosleep({1, 0},  <unfinished ...>
Process 15711 detached
[/code]

I am assuming I have an exploit that is either attempting a DOS on 50.57.187.242 or I am connecting an awful lot as there are 40 pearl scripts running with this same outpu for 800 plus minutes

more info

ls -al /proc/15711/
/bin/ls: unrecognized prefix: do
/bin/ls: unparsable value for LS_COLORS environment variable
total 0
dr-xr-xr-x   5 nobody   nobody          0 Nov 26 02:18 ./
dr-xr-xr-x 258 root     root            0 Nov 12  2013 ../
dr-xr-xr-x   2 nobody   nobody          0 Nov 26 11:14 attr/
-r--------   1 nobody   nobody          0 Nov 26 11:14 auxv
-r--r--r--   1 nobody   nobody          0 Nov 26 10:15 cmdline
-rw-r--r--   1 nobody   nobody          0 Nov 26 11:14 coredump_filter
-r--r--r--   1 nobody   nobody          0 Nov 26 11:14 cpuset
lrwxrwxrwx   1 nobody   nobody          0 Nov 26 11:14 cwd -> /tmp/
-r--------   1 nobody   nobody          0 Nov 26 10:16 environ
lrwxrwxrwx   1 nobody   nobody          0 Nov 26 11:14 exe -> /usr/bin/perl*
dr-x------   2 nobody   nobody          0 Nov 26 11:14 fd/
-r--r--r--   1 nobody   nobody          0 Nov 26 11:14 io
-r--------   1 nobody   nobody          0 Nov 26 11:14 limits
-rw-r--r--   1 nobody   nobody          0 Nov 26 11:14 loginuid
-r--r--r--   1 nobody   nobody          0 Nov 26 11:14 maps
-rw-------   1 nobody   nobody          0 Nov 26 11:14 mem
-r--r--r--   1 nobody   nobody          0 Nov 26 11:14 mounts
-r--------   1 nobody   nobody          0 Nov 26 11:14 mountstats
-r--r--r--   1 nobody   nobody          0 Nov 26 11:14 numa_maps
-rw-r--r--   1 nobody   nobody          0 Nov 26 11:14 oom_adj
-r--r--r--   1 nobody   nobody          0 Nov 26 11:14 oom_score
lrwxrwxrwx   1 nobody   nobody          0 Nov 26 11:14 root -> //
-r--r--r--   1 nobody   nobody          0 Nov 26 11:14 schedstat
-r--r--r--   1 nobody   nobody          0 Nov 26 11:14 smaps
-r--r--r--   1 nobody   nobody          0 Nov 26 10:15 stat
-r--r--r--   1 nobody   nobody          0 Nov 26 10:15 statm
-r--r--r--   1 nobody   nobody          0 Nov 26 10:16 status
dr-xr-xr-x   3 nobody   nobody          0 Nov 26 11:14 task/
-r--r--r--   1 nobody   nobody          0 Nov 26 11:14 wchan

I searched the /boot directory for the iptables but did not see them there (know exploit)

Thanks for any assistance.

HBruijn
  • 72,524
  • 21
  • 127
  • 192
ctrenks
  • 11
  • 1
  • That looks like perl scripts running from somewhere, possibly in `/tmp/` from the `cwd`symlink. The contents of /proc/15711/cmdline will most likely give you the name of the script, which is with a bit of luck more useful than you strace output. – HBruijn Nov 26 '14 at 17:24
  • root@server1 [/tmp]# /proc/15711/cmdline bash: /proc/15711/cmdline: Permission denied – ctrenks Nov 26 '14 at 17:32
  • `cat /proc/15711/cmdline` or just look for files owned by nobody that are obviously in hidden directories i.e. `/tmp/ /` and `/tmp/. /` are always favourites of mine – HBruijn Nov 26 '14 at 17:35
  • This is returned root@server1 [/tmp]# cat /proc/15711/cmdline [sync_supers]root@server1 [/tmp]# cat /proc/15711/cmdline I have a lot of [Sync_supers] in server staus (Cent OS) – ctrenks Nov 26 '14 at 17:37
  • 2
    Based on the trace info, it looks like an IRC zombie ("NICK" and "USER" are typical IRC protocol keywords). Nuke the box from orbit and reinstall. – Nathan C Nov 26 '14 at 17:51
  • Thats my plan at this point, move to another box all together. Thanks for the assistance, I will look into the attack and try to locate where it was added. – ctrenks Nov 26 '14 at 17:54

0 Answers0