Спасибо за ответ, попробую ответить также по кейсам:
Кейс #1. Админ должен быть в курсе зиродеев. Как обезопасить - иметь при себе человека, который будет мониторить сервер на постоянной основе. Человек должен разбираться в безопасности, а иначе толку мало. Этот человек должен быть в курсе последних новостей по ИБ, в т.ч. 0day, чтобы своевременно реагировать на них. Если смотреть приватные зиродеи, то тут никто не застрахован и может засечь вторжение только бдительный админ.
Кейс #2. Знание элементарных правил по информационной безопасности. Это как минимум :). По сабжу, есть варианты, например, двухфакторная авторизация для людей с правами редактора и выше. Кука ничего не даст, если не знать связку логин-пароль для .htaccess или basic-auth. Это как пример.
Кейс #3. Давайте разделять аудит безопасности сайта и сервера :) У меня, например, эти услуги отделены. Аудит кода позволяет закрыть дырки в коде, аудит сервера - на сервере, грамотная настройка прав доступа, проверка на рутабильность и т.д. Вкупе, образуется синергия, которая дает неплохие результаты.
Отдельное спасибо за кейсы из реальной жизни :).
На вторую часть отвечу из своего реального опыта. Ко мне чаще всего обращаются, когда сайт уже был взломан, к сожалению. Есть те, кто заказывает аудит непосредственно перед запуском в продакшн, есть те, кто делает профилактику, предполагая, что с безопасностью могут быть проблемы. Самым лучшим решением считаю - одновременный аудит кода и сервера до запуска сайта в продакшн. Это самый идеальный вариант :).
Как потенциальному клиенту сообщаю - мы не занимаемся сканом типа метасплоита, если на этом нет необходимости. Чаще всего, аудит скриптов, кода. Вручную + вспомогательные тулзы. Анализаторы кода работают по шаблону и могут выявить какие-то самые примитивные уязвимости.
В моей практике обучения персонала "как-лучше-не-делать" не было. Обычно был контакт с разработчиками, которым объяснялась суть уязвимости, как её можно проэксплуатировать, как лучше закрывать дырку, рекомендации. Выполнить их или нет решает уже сам клиент. Вот как-то так.
Cthulchu, верно, но скорее всего вы о разных типах аудита безопасности говорите :).
Коллеги, давайте активнее :)
Вас правда чтоль не взламывают или этот вопрос несущественен?
Проверь логи сервера. Возможно, где-то помимо шелла есть бекдор и вредонос через определенное время детектится есть код или нет, если нет, то дописывается заново.
Если нет доступа к логам, напиши хостеру. Смени все пароли на фтп, ssh, MySQL, адм.аккаунты.
Попробуй выставить права доступа только на чтение этому файлу.
Вы все в целом верно написали.
Но вначале разберитесь что Вам надо протестировать - функционал, нагрузку, позитивные тесты, негативные, интеграцию, интерфейс, конфигурацию, что-то ещё? Исходя из видов тестирования и объема функционала следует прикинуть сколько часов уйдет на это.
Не сочтите за рекламу, есть конторы, которые аутсорсингом тестирования занимаются, я думаю, они могут Вам прикинуть стоимость тестирования.
http://quality-lab.ru/outsource/price
http://www.testlab2.com/en/pricing
Попробуйте поработать с SVN.
http://ru.wikipedia.org/wiki/SVN
Каждый программер пишет код, затем мержит его в общую ветку.
Мы поможем найти "откуда" :)
Всё просто. На одном ip у хостера находятся 10 сайтов и криво настроены права юзеров. Взломав 1 сайт можно через него смотреть файлы соседнего сайта и, если там есть доступ на запись, залить шелл и туда. В итоге мы имеем шеллы у всего хостера, т.е. если первоначально взломанный сайт найдет и пофиксит багу, взломщик все равно уже закреплен в системе. Ещё хуже вариант, когда взломщик получает root-доступ у хостера, тогда уже неважно как настроены права, доступ есть на всё.
Да вот смотрел. Один модуль "Переходы" чего стоит :)
PS Естественно я говорю про лицензионную версию, а не NULLED, где без бекдоров и прочих пасхальных яиц вряд ли обходится.
Скорее дрявые плагины, которые устанавливаются вместе с дле. Сам чистый дле чаще уязвим разве что для XSS.
В явном виде tds-001.dyndns.biz, скорее всего, не найти, он наверняка зашифрованый в js лежит.
