Бага выявлена: похоже вся беда в обновлённом glibc на сервере ) народ не обновляйтесь из sid репозиториев ) Я обновлял proftpd (закрывал багу касаемую mod copy)и не обратил внимания и попал )
В качестве примитивной защиты можно использовать скрипт DDoS-Deflate https://github.com/Amet13/ddos-deflate
От серьёзных ddos атак с множества серверов не спасёт конечно, но от школоты поможет.
по сути если что-то и исполняется то только от рута, так что для меня можно смело их рубить.
==============
В целях безопасности от долбёжек ботов убрал isp панельку на отдельный поддомен, а порт 1500 (встроенного ihttpd) переместил на локальный айпишник 127.0.0.1:
0) Создаём поддомен
к примеру cp.mydomen.ru, для создания достаточно в редакторе DNS добавить запись А на ваш ip:1.2.3.4 (через панель поддомен создавать не нужно)
1) в /usr/local/ispmgr/etc/nginx.domain у меня
2) в /usr/local/ispmgr/etc/nginx.inc нужно закомментировать всё что есть или просто удалить
3) а в /etc/rc.local сменить внешний ip на локальный
после всего вышепроделанного грохаем
и перазапускаем
или рестартим систему
теперь панель стала доступной исключительно и только на поддомене + для которого подрублены access логи, так что проще будет искать )
Пробовал стандартными способами, через "Адрес панели" повесить её на отдельный поддомен, но что-то там всё глухо, не работает, так что при использовании способа делаем простое проксирование средствами nginx на ihttpd и забываем про эту вкладку навсегда.
P.S. постю это суда чтобы самому не забыть, и авось кому пригодится.
В общем отрубил у всех юзеров без пасса шелл и вам советую
и через /etc/ftpusers закрыл им доступ по ftp
будем следить далее за ситуацией )
Ничего не покажет права на папку /var/www 751, а владелец root :) зато командами в шеле может пользоваться всеми.
А вообще странная хренотень в Debian
у всех юзеров с пустым пассом * стоит шелл /bin/sh
Через крон, в логах была бы приписка что это крон, а тут идёт GET запрос причём с IP адреса самого сервера, это значит, что запрос обрабатывается напрямую апачем. Поверх апача у меня nginx, порт апача во внешку закрыт.
Т.е. запрос может быть выполнен только через php скрипт имеющийся на сервере, к которому можно обратится, передать данный запрос и чтобы этот скрипт его отправил. Оба этих запроса идут с реферами моих сайтов на вордпрессе, а в вордпрессе это можно сделать только через XML-RPC, т.е. обратившись и передав сценарию xmlrpc.php
Вот и оно http://habrahabr.ru/post/215543/ (Pingback) так скорее всего и был отправлен запрос. В логах обоих сайтов кстати в 07:48 как раз идут обращения к xmlrpc.php (срубил нафиг его со всех сайтов)
Но хр*ен с ним с rpc не понятно как всё таки пасс уставился, видимо isp пропустил, а пропустить он мог только тогда когда его "положили", больше я не вижу путей.
Возможно, но похоже баг именно в isp
логи nginx
Как раз в 07:48 были изменения в shadow и passwd
в message лог такая штука
В моменты этих ошибок происходит перезапуск ispmanager, возможно в момент перегруза, и возникновения ошибки прокатил такой GET запрос:
31.*.*.* Это айпишник моего сервака.
А чего фиксить...., все логи обрыл,толком откуда дыра не нашёл. Скорее всего в ISP дыра и сидит.
В shadow есть хэшь пасса, так что пасс действительно поставили! Сам шелл /bin/sh но он вроде как по умолчанию у этого юзера.
В общем вернул пока пасс в пустоту, командой passwd -S www-data (из ISP юзер сразу убрался), копаем дальше.
Заметил такую особенность, при вводе в качестве логина в форме авторизации ISP manager например www-data или любого юзера без пасса: games, proxy, man и т.д. получаю ошибку "Request timeout to panel reached. Panel has not started yet."
Причём по логам ISP видно что панель после этого автоматом перегружается. Это у меня только так?---------- Добавлено 30.07.2015 в 21:29 ----------
так так так, а поподробнее? знаком с багой видимо?
Уже три случая, мне тоже 26-го числа на www-data установили пасс.
кусок лога
Кто-нибудь разобрался где дыра?
