Последствия DDos атаки при уязвимом bash

Недавно ко мне обратились люди за помощью, в панике сказали проблемы якобы с сервером Linux.
Я бы не сказал, что я фанатик unix систем, но отношусь к ним с уважением и конечно же использую их для различных задач.
По словам проблема заключалось в том, что идет disconnect юзеров с игрового сервера.
Подключился к системе, начал копаться…
Стоит CentOS 6.4 с архитектурой x86_64. Настроена система как гипервизор по средствам qemu и libvirt, одна виртуальная машина на платформе win2008, также крутятся вэб сервер.
Смотрю dmesg и вижу кучу сообщений nf_conntrack: table full, dropping packet, ага уже понятно почему происходит disconnect. Увеличиваем значение

net.netfilter.nf_conntrack_max

net.nf_conntrack_max

и тут доступ извне к win2008 пропадает во все…

При просмотре интерфейса замечаю, что объем трафика растет не по дням, а по минутам Гигабайты трафика просто забивают канал.
top показал подозрительный процесс
32655 root 20 0 195m 5116 204 S 655.8 0.0 0:52.45 bvuzgoilxt
Файл запускался из /usr/bin/
Убиваю процесс и перемещаю файл для исследования.
Доступ к Win2008 появился ровно 4 сек, смотрю опять top и вижу снова
31931 root 20 0 195m 4984 208 S 546.2 0.0 1:10.80 gcwwbifuxb
Значит команда запускается из планировщика, смотрю планировщик
/3 * root /etc/cron.hourly/cron.sh
Содержимое
#!/bin/sh
PATH=/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/sbin:/usr/X11R6/bin
for i in `cat /proc/net/dev|grep :|awk -F: print $1`; do ifconfig $i up& done
cp /lib/libgcc.so /lib/libgcc.so.bak
Тут уже сомнений не было, что это взлом.

Начал исследовать файл bvuzgoilxt и libgcc.so.
Нашел в коде вот такую часть
esac
^@/etc/init.d/%s^@/etc/cron.hourly/cron.sh^@/etc/rc%d.d/S90%s^@/etc/rc.d/rc%d.d/S90%s^@--add^@chkconfig^@defaults^@update-rc.d^@sed -i$
Accept-Language: zh-cn

Оказывается, удаление и завершения процессов были бесполезны, он заново запускал файл с рандомным именем и прописывал в планировщик задание.
Исследуя процесс я понял, что файл запускает каждый раз разные и с разными командами, выглядело это так

5715 root 20 0 195m 5088 204 S 58.1 0.0 0:01.75 aoholnwldy
ps aux | grep 5715

root 5715 26.6 0.0 199976 5064 ? Ssl 15:49 0:08 cat resolv.conf

3447 root 20 0 73256 1240 208 S 21.9 0.0 0:12.40 tszlbheqtf

ps aux | grep 3447
root 3447 31.6 0.0 95308 2708 ? Ssl 15:40 0:25 ls –la

Так же было обнаружено, что он пытался сканировать другие ip

COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
tszlbheqt 3447 root cwd DIR 9,2 4096 2 /
tszlbheqt 3447 root rtd DIR 9,2 4096 2 /
tszlbheqt 3447 root txt REG 9,2 625633 9438788 /usr/bin/tszlbheqtf
tszlbheqt 3447 root 0u CHR 1,3 0t0 3698 /dev/null
tszlbheqt 3447 root 1u CHR 1,3 0t0 3698 /dev/null
tszlbheqt 3447 root 2u CHR 1,3 0t0 3698 /dev/null
tszlbheqt 3447 root 3u raw 0t0 689188 00000000:00FF->00000000:0000 st=07
tszlbheqt 3447 root 4u raw 0t0 689189 00000000:00FF->00000000:0000 st=07
tszlbheqt 3447 root 5u raw 0t0 689248 00000000:00FF->00000000:0000 st=07
tszlbheqt 3447 root 6u IPv4 688268 0t0 TCP p196220.ihc.ru:56645->103.240.141.50:ccmcomm (ESTABLISHED)
tszlbheqt 3447 root 7u raw 0t0 689251 00000000:00FF->00000000:0000 st=07
tszlbheqt 3447 root 8u raw 0t0 689196 00000000:00FF->00000000:0000 st=07
tszlbheqt 3447 root 9u raw 0t0 689221 00000000:00FF->00000000:0000 st=07
tszlbheqt 3447 root 10u raw 0t0 689252 00000000:00FF->00000000:0000 st=07
tszlbheqt 3447 root 11u raw 0t0 689255 00000000:00FF->00000000:0000 st=07
tszlbheqt 3447 root 12u raw 0t0 689258 00000000:00FF->00000000:0000 st=07
tszlbheqt 3447 root 13u raw 0t0 689259 00000000:00FF->00000000:0000 st=07
tszlbheqt 3447 root 14u raw 0t0 689263 00000000:00FF->00000000:0000 st=07
tszlbheqt 3447 root 15u raw 0t0 689266 00000000:00FF->00000000:0000 st=07
tszlbheqt 3447 root 16u raw 0t0 689267 00000000:00FF->00000000:0000 st=07
tszlbheqt 3447 root 17u raw 0t0 689268 00000000:00FF->00000000:0000 st=07
tszlbheqt 3447 root 18u raw 0t0 689279 00000000:00FF->00000000:0000 st=07
tszlbheqt 3447 root 19u raw 0t0 689281 00000000:00FF->00000000:0000 st=07

Ни каких подозрительных файлов системе не было, поиски в интернете говорили о том, что подобный файл находится в директории /boot/ и после удаления должно было все исчезнуть.
В голове появлялась мысль о переустановке системы, но оставалось пару идей, которые все-таки дали плоды.
Запустив команду chattr -R +i /usr/bin тем самым остановил создание и изменение в папке, где как раз у нас появлялся данный файл. На конец появления новых процессов в системе остановилось. В голове промелькнуло маленькое воспоминание о том, что пару месяцев назад, была найдена уязвимость в bash, которые можно было проверить командой
env X="() { :;} ; echo vulnerable" bash -c "echo hello"
Результат выполнения этой команды был следующим
vulnerable
hello
Это говорит о том что bash уязвим. Решается эта проблема обновлением самого bash.
После обновления bash проблема ушла, вернул разрешение за запись и создание файлов командой chattr -R -i /usr/bin и все заработало в штатном режиме.