Pull to refresh

Comments 30

Если бы не картинка, то я может быть и не зашёл бы сюда.

Спасибо за интересную статью.
UFO just landed and posted this here
картинку я выбирал не случайно.
значит малый социальный инженеринг сработал)
спасибо за отзыв :)
Какая картинка…
/me пошел устанавливать Fallout 3.
С нетерпением жду статьи по белому ящику :-)
Спасибо за статью!

Сейчас пишу такой скрипт: запускатся по крону, пишет отчет в html. В конфиге servers.cfg указываются сервера, которые подвергаются аудиту, в конфиге packages.cfg указываются службы, которые надо проверять (mysql-server, php5, openssh, nginx и т.д.). Скрипт заходит на каждый сервер, проверяет текущую версию пакета, и версию в репозитории. После чего, выводит отчет с указанием версий, где подсвечены сервисы, которые нужно обновить.

Кому-нибудь такое нужно, кроме меня? )
Может все-таки на серверах настроить автоматическое накатывание security updates, не?.. Зачем лишняя ручная работа?
Да просто чтобы видеть где какие версии стоят.
Security updates это не отменяет.
Когда автообновление включено — смысл отчета с подсвеченными сервисами, которые нужно обновить — как-то пропадает…

А так — я так понимаю, все сводится к чему-то типа:

PACKAGES=$(cat packages.cfg)
for I in $(cat servers.cfg); do
    ssh $I rpm -q $PACKAGES | sed 's/^/$I /'
done

rpm -q при необходимости заменяется на аналогичный вызов dpkg, pacman, pkg_info и т.п.
Забыл сказать: у меня целый зоопарк из FreeBSD и Ubuntu серверов. А мой скрипт проверяет универсально все сервера, не зависимо от типа (пока поддерживается только Ubuntu/Debian и FreeBSD).

А автообновление — вещь не всегда уместная. Например, я только что накатил Security-апдейты на убунту-сервер и получил нерабочую VMware Server — она весьма чувствительна к ядру.
Практика показывает, что зверинцы надо уничтожать.
Ага. А если у вас есть молоток и отвертка, то отвертку можно выкинуть — шурупы ведь и молотком неплохо забиваются.
неудачное сравнение. На текущий момент лично я не вижу причину держать freebsd. Все задачи прекрасно выполняются и в linux. Если вы используете ubuntu, смысл держать debian? Стабильность? Тогда смысл держать ubuntu. В общем если все искоренить нельзя, то как минимум надо минимизировать.
Даже яндекс использует Linux и FreeBSD. Причем, фря в приоритете (поиск на ней).
Уже нет. И да, то, что там было от Freebsd, именно что было. Очень много всего переделанно, многие драйверы для сетевых устройств были написанны с 0. Ну и еще раз, от freebsd yandex избавляется по мере возможности.
>> скрипт проверяет универсально все сервера, не зависимо от типа
>> пока поддерживается только Ubuntu/Debian и FreeBSD
улыбнуло.
>Более профессиональный аудит подразумевает использование специальных локальных прокси серверов, которые будут подменять нужные нам данные

Можно поподробнее?
Да, конечно. ksavenkov упомянул об этомздесь
Ссылка на сам прокси.
Скажем так, упрощает работу, фильтрует (подменяет) нужные нам параметры при обмене с сервером.
Стоит посмотреть скрины и все станет понятным :)
Мое глубокое убеждение, что в команде аудиторов должен быть хоть один программист для прстой скриптовой автоматизации, на выбор, кому что по душе Perl, PHP, Python, JavaScript… А вот C++, C#, Java для таких скриптов плохо подходят, на них сложнее писать оперативно, подход более основательный нужен, а для тестирования это не обязательно.
Для разработчиков же (я имею в виду именно тех, кто пишет новые системы, а не прикручивает взятые из интернета готовые решения), вся защита сводится к очень короткому списку:
  • Валидируйте все входящие и исходящие данные по структуре и типам;
  • Не клейте SQL конкатенацией строк никогда, кроме случаев фреймворков (но во фреймворках можно и код более качественно писать, сделав дополнительную валидацию всех склеиваемых фрагментов);
  • Как можно чаще делайте кеширование чтобы избежать повторяющихся запросов и лишних нагрузок (кеш на диске, в памяти в специальных хеш-СУБД и т.д.);
  • Разделяйте систему для разработки (закрытую от внешнего мира) и продакшен систему (из которой нужно удалить половину, а оставшееся минифицировать и «утоптать» по максимуму);
  • Всегда предусматривайте блокировку запросов по IP, если с них идет странная активность (пользователь не сгенерирует 100 запросов в минуту и не будет долбить сервер 24 часа напролет, пользователи — люди, они едят и спят)
  • Определяйте попытки SQL-инъекций и XSS-инъекций, не просто их фильтруйте, а блокируйте IP
Я сошлюсь на ваш комментарий в одной из моих следующих статей, после аудита «белого ящика»
так как поддерживаю написанное Вами :-)
Люди, сидящие за NAT-ом (жители студенческих общежитий, например) будут вам невероятно благодарны за блокировку по IP.
Так задавайте для таких систем разумные лимиты на доступ. А для исключений еще и белый список можно иметь. Но вот на банковские платежные системы, например, такая защита даже в строгом виде имеет место быть.
Убираем из статьи воду:
Анализ типа «черный ящик»:
1. По прямым и косвенным признакам стараемся идентифицировать содержимое ящика
2. Применяем перебор всех возможно шибочных входов
3. Пытаемся придумать новый набор входных данных, которые могут вызвать ошибку.
Скоро я планирую написать статью про сервис websitedefender от Acunetix. Детали работы сервиса поддержка раскрывать отказалась, поэтому немного поправил их скрипт и пополняю логи. Анализ будет чуть позже ;)

От себя замечу, что очень многие забывают про контроль самих файлов веб-приложения, концентрируясь на атаках извне через веб. Но есть же и шеллы, и вирусы, крадущие пароли от ftp из клиентов и пишущие потом iframe. А все это очень просто обнаруживается простейшим файловым монитором.

В дипломе как раз такой прикручивал к phpids, чтобы получить phpips ;)

Кстати, буду рад если кто подскажет, как можно повысить карму, чтобы статью потом можно было добавить в этот блог. Я на хабре пока только читаю в основном.
Кстати, буду рад если кто подскажет, как можно повысить карму
В q&a упорно просить помогать людям и получать заслуженные плюсы.
Nessus вроде как сам использует nmap для сканирования открытых портов.
Sign up to leave a comment.

Articles