ТС,
Можете ознакомиться со статьей "Методики борьбы с простейшими атаками" а так же будет полезна статья "Многофункциональность и гибкость fail2ban"
Вся соль аналогичных вопросов заключается в том, что далеко не всегда есть возможность выяснить где находится дыра, сейчас попытаюсь пояснить почему:
Выяснить конечно можно но представьте себе путь которым придется это сделать, ведь что получается по сути, вы видите только конечный результат, вам залили какие-то страницы, и вот они лежат, стало быть уязвимость может находится например в одной из функций одного из ваших сайтов, а так же может находится в демоне apache или mysql а еще например может находится в ядре (kernel) вашей системы, каким методом или алгоритмом вы собираетесь проверить все эти точки? Ведь проблемы бывают на столько разные.... К примеру помню баг в драйвере реалтек сетевых карт, при отправке определенного запроса сервер просто отключал сетевую карту.... а может сейчас уже новый баг в одном из драйверов который дает доступ к системе? В общем подход нужен обратно пропорциональный, искать дыры после того как взлом случился.... задача очень сложная и практически не реальная, куда проще искать взломы в момент самих взломов, а именно подготовится к проникновению в вашу систему заранее, что это значит:
1. Ни в коем случае не экономить место под логи, причем любые логи, это могут быть логи веб сервера (причем как access так и error) это могут быть логи mysql query (да их может быть много, однако они отражают все SQL запросы в базу и легко могут быть подвержены ротации). Так же могут быть включены логи PHP.
2. Отдельно стоит поговорить об окружениях в которых работают ваши сайты, если у вас есть возможность!! каждый сайт должен быть изолирован от других, основная проблема виртуальных хостингов заключается в том, что злоумышленники взломав всего 1 сайт получают доступ ко ВСЕМ остальным сайтам на акаунте... базам, настройкам и.т.п По этому если вы владелец VPS или Выделенного Сервера не исключайте изоляцию из настроек, выдавайте каждому сайту свое окружение, создавайте своего пользователя как системного так и для доступа к базам данных.
3. По моему личному наблюдению + небольшому 10 летнему опыту работы в хостинг индустрии, 90% всех взломов происходит с использованием известных уязвимостей в известных движках, ведь согласитесь если вы создали движок сами , поставили его себе на сайт и пользуетесь им исключительно ВЫ, каким бы крутым атакующим не был наш злоумышленник у него нет ни малейшего представления какие функции вы используете, как они построены и какие из них содержат погрешности программирования, это значительно усложняет методики поиска уязвимостей, другое дело когда можно скачать свежую Joomla или WP с оф. сайта и командным орбазом придать жесткому анализу все её функции... найдя уязвимость - под атакуемые машины сразу попадают тысячи, сотни тысяч пользователей сети..... и утекают гигабайты персональных данных и.т.п По этому если у вас есть материальная возможность разработки своего движка для своих сайтов - это огромный бонус!!!
4. Аналитика или с чего начинать: Если вы хотя бы раз смотрели в лог веб сервера , вас должен заинтересовать вопрос, чем же нам помогает этот самый лог, ведь там кроме обращения к конкретному файлу и наверняка подмененному ИП атакующего ничего нет, и от части вы совершенно правы, одним из важных на мой взгляд принципов изучения атак, заключается полное хранение развернутых POST запросов к вашему ресурсу, сделать такой механизм очень не сложно, я покажу самый простой пример, но можно наколдовать и куда поинтересней:
file trace.php:
<?if (!empty($_POST)) {$data = var_export($_POST,true);file_put_contents("/home/user/post.log", $data, FILE_APPEND | LOCK_EX);}?>
После чего в php.ini для вашего окружения можно прописать следующее:
Данная конструкция будет записывать в указанный лог файл ВСЕ данные всех POST запросов которые прийдут на ваш виртуальный хост, как правило этот файл дает около 90% результативной информации при выявлении уязвимости, к примеру если через кривой редактор в вашем движке был залит файл то скорее всего в POST логе вы обнаружите содержимое того самого файла, а так же сможете понять куда было произведено обращение и какие параметры передавались в этот момент в POST запросе. Следом эти данные может будет сравнить с данными из sql query log , если были модификации в базе данных - то аналогично будет ясно какие запросы были инициаторами этих самых изменений...
На самом деле это только начало, но без него и говорить не о чем, когда у вас нет логов, когда у вас нет информации по запросам к вашей системе, по переданным в неё данным - искать уязвимость это тыканье пальцем в небо.... Увы, и ах, но это именно так. Обычно в таких случаях "умники" сразу смотрят версии продуктов и если они не актуальны то все лечение заключается в установке последней версии вашего движка, однако по прежнему нет никакой ясности в том, являлось ли это причиной проблемы....
С радостью проконсультирую или отвечу на доп. вопросы лично.
Проблема еще ночью устранена, сервер введен в эксплуатацию в полном объеме.
Приносим свои извинения за неудобства.
🙅🙅🙅
andypolak, не ведитесь на всякие "приколы" и очередные плагины, которые только добавят вам дырок в ваши сайты, безопасность вашего ресурса в большей мере зависит от вас и вашего хостера, по этому как сказал выше kgtu5 стоит искать причины и проблемные места и устранять их, а не писать \ качать софт который будет определять где залит новый файл.... Вы не забывайте о том, что сегодня на хостинг залит файл, а завтра с него удалены все файлы, а через неделю файлы удаляются раз в час, потом раз в минуту.... вы будете раз в минуту заливать копию данных? Это даже звучит бредово , не говоря уже о случае когда это надо будет делать :D Изначально я не скажу ничего нового, но все же:
1. Вам надо быть уверенным в том, что ваши пароли не знает ни кто другой, по этому после каждого взлома \ заливки новых файлов они должны быть изменены вами. В противном случае последующее заливание уже может происходить вполне себе официальным путем.
2. Вы должны постоянно актуализировать программное обеспечение на вашем сайте.. Стало быть если у вас стоит Joomla 5 годичной давности, потому что для переезда на новую нет денег на перенос шаблона и функционала - то вы обречены. Весь софт должен быть обновлен до последних официальных версий, должны быть исключены неиспользуемые плагины, а так же плагины которые не являются официальными и не поставляются в поставке движка сайта.
3. вам требуются аналитические алгоритмы которые помогут вам выяснить уязвимое место, к таким штукам я лично отношу анализ лог файлов FTP сервера, а так же веб сервера, анализ GET / POST запросов их логирование и анализ. Последующий анализ и репродукция подозрительных запросов с целью получения методики взлома.
Это начало, т.е то , на что надо обратить внимание и начать делать уже сейчас, что бы потом появились данные на которые можно будет опираться, идти вашим путем я бы вам не советовал в принципе.... надо не латать латки латками, надо устранять причины...
Если нужна дополнительная консультация с радостью отвечу на ваши вопросы в ICQ или Skype.
[ Срочное сообщение ]
Уважаемые клиенты, в связи с техническими проблемами сегодня около 23:00 по Киеву вышел из строя сервер Core16 на котором так же расположен и наш основной сайт. Наши специалисты уже направили все силы на решение данной проблемы, в настоящий момент идет восстановление данных с raid массива, а так же восстановление самого массива, ситуация нашими специалистами не оценена как критическая и пока что нет угрозы потери данных, однако ситуация требует не малого времени и терпения.
Полная реконструкция массива с данными займет по предварительным расчетам от 5 до 10 часов. Остальные сегменты проекта данная проблема не затрагивает. Мы будем держать вас в курсе по основным аспектам данной проблемы. Состоянием на момент поста реконструкция идет без ошибок и пройдена на 3.5%.
Приносим свои извинения за причиненные неудобства.
Стало быть, ничего общего у Cloud-ов нет и быть не может, каждый делает что-то свое... в итоге любые извращения в которых участвует более одного физического сервера в праве называться сложной инфраструктурой и в полной мере могут называться Cloud-ами. :) Мои радужные представления о мире рушатся... ;(
Обратил внимание на то, что в вашей подписе написано. Не могли бы вы мне пояснить что именно вы предлагаете как Cloud Hosting ? Если это не OpenStack / SloudStack то что? Я начинался немного и совершенно однозначно понял, что под словом Cloud сейчас может находится что угодно, да да именно так... кто-то может сделать 2 сервера в DRBD+heartbeat и назвать это Cloud, кто-то может используя libvirt переносить ноды с ВПС на ВПС и называть это Cloud, кто-то как я может пытаться использовать нечто в роде CloudStack.... а кто-то я полагаю может и обычный Single сервер поставить и тоже назвать услугу *Cloud*, собственно что в системе говорит о том , что это Cloud? как я понимаю вообще ничего... стало быть как понять, покупаете вы обычный хостинг на отдельно стоящем сервере ,а в вам "парят" его как облачное мега-что-то.... или же вы покупаете действительно некую распределенную систему.....
Расскажите (без раскрытия коммерческих тайн) что именно вы продаете как Cloud?
Рады сообщить Вам, что с сегодняшнего дня введена поддержка через Jabber, теперь используя любой Jabber клиент , вы так же можете контактировать нас.
Наш контакт: onyxhosting@jabber.ru
zeko, готовы предоставить любой тариф виртуального хостинга в течении 5 минут после регистрации если постучитесь к нам в ICQ или Skype. Тестовый период 1 неделя. cPanel.
Так то оно так.... но с другой стороны, если надо, это не цена...
Я вообще молчу о том, что за 2$ надо поискать еще ИП, а так они около 4$...
Но как бы не ясно, какой смысл содержать шаренные ИП на которых мало сайтов.... Кто следит вообще за количеством доменов на Shared IP ? :)---------- Добавлено 02.07.2014 в 22:39 ----------
Держите на разных, вопрос то в чем?
Взяли сколько надо ИП , разместили сколько надо сайтов на каждом из них...
Какой вообще смысл в том, сколько еще других доменов на том или ином ИП?
