Назад | Перейти на главную страницу

Странные записи в журнале и безумное использование полосы пропускания

У меня есть облачный сервер CentOS, который я использую для тестирования, и заметил, что за последние 30 дней пропускная способность резко выросла (16000 ГБ точнее)

Когда я изначально пытался проверить сервер, он был полностью недоступен (нет ответа на SSH, в Интернете, даже консоль (консоль только что показала кучу ошибок, без приглашения на вход)

Я отскочил от сервера и начал просматривать логи и логины. Никаких SSH-логинов в возрасте, ничего странного в логах кроме этого каждую минуту:

Jan 17 02:20:01 wwwdev crond[21971]: (apache) CMD (/tmp/.../.shy/update >/dev/null 2>&1)
Jan 17 02:21:01 wwwdev crond[21976]: (apache) CMD (/tmp/.../.shy/update >/dev/null 2>&1)
Jan 17 02:22:01 wwwdev crond[21985]: (apache) CMD (/tmp/.../.shy/update >/dev/null 2>&1)
Jan 17 02:23:01 wwwdev crond[21990]: (apache) CMD (/tmp/.../.shy/update >/dev/null 2>&1)
Jan 17 02:24:01 wwwdev crond[22000]: (apache) CMD (/tmp/.../.shy/update >/dev/null 2>&1)
Jan 17 02:25:01 wwwdev crond[22006]: (apache) CMD (/tmp/.../.shy/update >/dev/null 2>&1)
Jan 17 02:26:01 wwwdev crond[22015]: (apache) CMD (/tmp/.../.shy/update >/dev/null 2>&1)
Jan 17 02:27:01 wwwdev crond[22024]: (apache) CMD (/tmp/.../.shy/update >/dev/null 2>&1)
Jan 17 02:28:01 wwwdev crond[22029]: (apache) CMD (/tmp/.../.shy/update >/dev/null 2>&1)
Jan 17 02:29:01 wwwdev crond[22034]: (apache) CMD (/tmp/.../.shy/update >/dev/null 2>&1)

Все, что на самом деле было в / tmp, давно исчезло, так как мне пришлось перезагружаться, но я действительно хотел бы знать, что, черт возьми, произошло.

Я не знать конечно, но это описание очень сильно пахнет сервером, рассылающим спам по электронной почте. Это также мог быть червь, ищущий другие хосты для компрометации, но спам по электронной почте кажется более вероятным.

Если вы посмотрите IP-адрес своего сервера на веб-сайте репутации электронной почты, например SenderScore или SenderBase или просто поищите его в Google, вы можете найти доказательства этого и даже примеры спама. Вы также можете зарегистрироваться Черные списки DNS чтобы узнать, находится ли ваш сервер в черном списке.

Имя пользователя, под которым выполнялось задание cron, предполагает, что компрометация (если это так) произошла через ваш веб-сайт. Доступ к вашему веб-серверу и журналы ошибок за несколько дней до запуска заданий cron были бы лучшим местом для начала поиска.

Чуть не забыл обязательную ссылку на Мой сервер был взломан в АВАРИИ. Там много хороших советов о том, что делать и как убираться. Не забудьте удалить или ограничить phpMyAdmin.