Взломали сервер

Как доказать популярно :) ему и его шефу, что сервер не взломан, а сломали именно сайт?

Можно потратить время, найти дыру в сайте, после чего показать её поргаммисту и его начальнику.

Сломать сайт самому?

Лорчую. Найди и покажи заказчику программиста.
Можно и в суд за клевету подать.

В своей практике ни разу ещё не сталкивался со взломов сайта через уязвимости сервера. На ботнет, влезший через дырку в старом не обновлённом пакете нарывался лет 9 назад. А вот чтобы сайт — ни разу. Всегда лезут через уязвимости. Или готового продукта или одного из стоящих рядом.

Как доказать популярно :) ему и его шефу, что сервер не взломан, а сломали именно сайт?

Этого:

новые левые файлы созданы из под юзера www-data

недостаточно?

Найди и покажи заказчику программиста.

Поиск уязвимостей, платная услуга.

Если есть исходники, то найти дыру - полчаса максимум.

А логи проверить, не? :)

для меня - достаточно, для них - хз...

какие? взлом через дыры сайта не логируется практически. единственное, что нашел - обращения с украинского ИП на залитые php-страницы.

в своем коде - может быть, в чужом - очень сомневаюсь.

Ну например посмотреть, куда именно этот IP обращался перед этим :)
Если ломают через SQL INJ то весьма вероятно, что в логах будет вообще все.

В общем смотри по дате создания подозрительных файлов.

Собственно если на той стороне не техники а дизайнеры и менеджеры, то в качестве аргументов нужна бумага с печатью.

access логи сайта же. на предмет всяких странных POST-запросов.

Попробуйте просканировать Acunetix-ом, вдруг уязвимость довольно простая

Даю пол часа на поиск дыры в linux kernel.

Отпишись тут.

Ежели взлом через сайт не логгируется, а серверного ПО логгируется, то тут всё итак ясно.

Да и посмотри, какое обращение на сайт - может даже ссылка специально сформированная была использована, которая уязвимость делает. А может сами клиенты за паролями своими не следят. Если в CMS нет дыр - то ясен пень, что они сами свои пароли по неосторожности отправили в свободное плавание. А что за CMS?

Основной мой аргумент - «Сервер не имеет уязвимостей»

как минимум небезопасная точка зрения. Скажем, проломав рутовый шелл легко выкладывать файлы от имени www-data, оставляя логи чистыми.

В данном случае доказать наличие дыры в сайте можно повторив взлом. А на будущее - включать аудит, и гнать его на внешний сервер.

Подай в суд, адвокат закажет экспертизу, проигравшая сторона выплатит все расходы.

В своей практике ни разу ещё не сталкивался со взломов сайта через уязвимости сервера

Скудная же у тебя практика :)

Ну, что-то под 20 машинолет.

А что, у тебя сайты чаще ломают через дыры системы, чем через дыры сайта?

Т.е. фактически, хакеры нашли в сайте дыру

Настройки дефолтные небось. Попса хостинговая всякая дефейсится арабскими кулхацкерами^Wскрипткиддисами только в путь из-за такой ерунды.

К чему эта клоунада? Я имел ввиду конкретный сайт, а не любой программный продукт.

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

Не чаще, но бывали неоднократные случаи

Акцент же был именно на вероятность.

только там, где есть что-то важное, таких детских уязвимостей нет.

Ой, не факт. Случаи разные бывают.

Случаи разные бывают.

Это совсем уж маловероятные случаи.

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

Может быть вы меня не так поняли, но я имел ввиду, что ТС'у найти дыру будет гораздо проще и быстрее, чем злоумышленникам.

Как доказать популярно :) ему и его шефу, что сервер не взломан, а сломали именно сайт?

По хорошему нужно сделать несколько вещей:

1. Нужно составить письмо типа «По заключению технических специалистов и специалистов по компьютерной безопасности компании (ваша компания) взлом сайта был осуществлен через уязвимости в CMS.» Подпись, печать.

Для директора этого достаточно, ибо если это не так, то он сможет с этим документом идти в суд.

2. Конечно, хорошо бы аргументировать это заключение. Это лучше сделать отдельным документом. В нем надо отметить: 2.1. регулярность работ проводимых по поддержанию безопасности сервера 2.2. квалификацию исполнителей этих работ 2.3. твои соображение по поводу юзера www-data 2.4. полезно привести ссылки на вебресурсы где обсуждаются уязвимости этой CMS (можно даже этой версии), если она распространенная, то ссылки найдутся легко.

Это все косвенные подтверждения твоей правоты, но их много и они основаны на конкретных фактах. И фактов этих много.

PS: можно, конечно, найти дыру, но это не ваша работа и все равно это не докажет, что взлом был именно через эту дыру.

Если есть исходники, то найти дыру - полчаса максимум.

тебе уже говорили что ты идиот и клоун?

Может быть вы меня не так поняли, но я имел ввиду, что ТС'у найти дыру будет гораздо проще и быстрее, чем злоумышленникам.

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

Это при условии, что злоумышленник делал все через вебсервер. Без доступа к консоли. Но может быть у них просто сперли пароль? Это установить будет невозможно.

Знакомый сюжет :)

Как правило какие-нибудь следы при таких взломах да остаются. Часто помогает тупо сравнить текущее состояние сайта с незараженным бэкапом — могут просто обнаружиться лишние скрипты во всяких неприметных местах. Можно у клиента запросить «девственную» версию сайта — ту, которую он заливал. Но не факт, что она у него есть...

Дыры же как правило расположены не в самописных движках (они там несомненно есть, но никто из взломщиков просто не будет заморачиваться их поиском), а в готовых компонентах типа всяких голосовалок и гестбуков, которые, разумеется, никто никогда не обновляет. Если обнаружатся такие компоненты, потенциальные дыры в них легко нагуглить.

Ну и косвенным доказательством того, что взломан не сервер целиком, а именно сайт, как раз и является то, что файлы созданы www-data, а не root'ом (в случае с suexec/suphp они создаются от имени взломанного пользователя, что еще убедительнее).

Как тут уже посоветовали, посмотреть логи вебсервера на предмет запросов, логи БД.
Если не лень, то можно слить нексус/иксспайдер/в идеале макспатрол(но его нет в доступе) и натравить на сервак.
Акунетикс тоже может помочь.

А аудит в системе не ведется?
Именно аудит, если я не путаю, логирует все-все-все действия, вплоть до создания/обращения к файлу.

А аудит в системе не ведется?

Подозреваю, что если бы у ТС все велось как надо, то этой темы тут бы не было.

логи есть, есть так же большой опыт подобных изысканий(успешный) - все чисто.

нечаянно перепутал Вас с ТС.

Что насчет аудита и не могли ли товарищи часом почистить и логи?

проверил - чисто.

нет не ведется. как реализовать?

логи впорядке, чтобы их почистить нужен рут :)

И конечно же виноват дебиан стейбл, да?

Честно говоря, сам еще не разбирался, собирался заняться этим после 20х чисел, тк стоит такая задача.
Но вот, что дало быстрое гугление.
Кажется, то, что нужно.

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

Охтыжбин. ты в каком мире живешь? Мне вот как-то доводилось видеть на железной дороге тру-ынтырпрайзную софтину, в которой сессия пользователя идентифицировалась по IP-адресу.

Бауманский электронный университет(штуку, куда заносят все данные о сданных экзаменах и по которой смотрят долги) поломали через sql-inj.
Но студенты оказались не слишком вумными и их быстренько нашли.

Нет, можете смело писать «первонах». Кстати, не аргументируете ли свою точку зрения?

Можно и в суд за клевету подать.

+1, пусть они что-то ТС-у доказывают.

У нас в компании на площадке хостятся сайты нескольких комм. клиентов.
новые левые файлы созданы из под юзера www-data

Что все виртуальные хосты под одним www-data?!
Поздравляю! Я думаю что виноват в этом случае все таки ты!

может там контейнеры, и на каждый виртуалхост по контейнеру?