Comments 30
Если бы не картинка, то я может быть и не зашёл бы сюда.
Спасибо за интересную статью.
Спасибо за интересную статью.
+18
Какая картинка…
/me пошел устанавливать Fallout 3.
/me пошел устанавливать Fallout 3.
+5
С нетерпением жду статьи по белому ящику :-)
0
Спасибо за статью!
Сейчас пишу такой скрипт: запускатся по крону, пишет отчет в html. В конфиге servers.cfg указываются сервера, которые подвергаются аудиту, в конфиге packages.cfg указываются службы, которые надо проверять (mysql-server, php5, openssh, nginx и т.д.). Скрипт заходит на каждый сервер, проверяет текущую версию пакета, и версию в репозитории. После чего, выводит отчет с указанием версий, где подсвечены сервисы, которые нужно обновить.
Кому-нибудь такое нужно, кроме меня? )
Сейчас пишу такой скрипт: запускатся по крону, пишет отчет в html. В конфиге servers.cfg указываются сервера, которые подвергаются аудиту, в конфиге packages.cfg указываются службы, которые надо проверять (mysql-server, php5, openssh, nginx и т.д.). Скрипт заходит на каждый сервер, проверяет текущую версию пакета, и версию в репозитории. После чего, выводит отчет с указанием версий, где подсвечены сервисы, которые нужно обновить.
Кому-нибудь такое нужно, кроме меня? )
0
Может все-таки на серверах настроить автоматическое накатывание security updates, не?.. Зачем лишняя ручная работа?
+1
Да просто чтобы видеть где какие версии стоят.
Security updates это не отменяет.
Security updates это не отменяет.
0
Когда автообновление включено — смысл отчета с подсвеченными сервисами, которые нужно обновить — как-то пропадает…
А так — я так понимаю, все сводится к чему-то типа:
А так — я так понимаю, все сводится к чему-то типа:
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 и т.п.0
Забыл сказать: у меня целый зоопарк из FreeBSD и Ubuntu серверов. А мой скрипт проверяет универсально все сервера, не зависимо от типа (пока поддерживается только Ubuntu/Debian и FreeBSD).
А автообновление — вещь не всегда уместная. Например, я только что накатил Security-апдейты на убунту-сервер и получил нерабочую VMware Server — она весьма чувствительна к ядру.
А автообновление — вещь не всегда уместная. Например, я только что накатил Security-апдейты на убунту-сервер и получил нерабочую VMware Server — она весьма чувствительна к ядру.
+2
Практика показывает, что зверинцы надо уничтожать.
0
Ага. А если у вас есть молоток и отвертка, то отвертку можно выкинуть — шурупы ведь и молотком неплохо забиваются.
+1
неудачное сравнение. На текущий момент лично я не вижу причину держать freebsd. Все задачи прекрасно выполняются и в linux. Если вы используете ubuntu, смысл держать debian? Стабильность? Тогда смысл держать ubuntu. В общем если все искоренить нельзя, то как минимум надо минимизировать.
0
>> скрипт проверяет универсально все сервера, не зависимо от типа
>> пока поддерживается только Ubuntu/Debian и FreeBSD
улыбнуло.
>> пока поддерживается только Ubuntu/Debian и FreeBSD
улыбнуло.
0
>Более профессиональный аудит подразумевает использование специальных локальных прокси серверов, которые будут подменять нужные нам данные
Можно поподробнее?
Можно поподробнее?
0
Мое глубокое убеждение, что в команде аудиторов должен быть хоть один программист для прстой скриптовой автоматизации, на выбор, кому что по душе Perl, PHP, Python, JavaScript… А вот C++, C#, Java для таких скриптов плохо подходят, на них сложнее писать оперативно, подход более основательный нужен, а для тестирования это не обязательно.
Для разработчиков же (я имею в виду именно тех, кто пишет новые системы, а не прикручивает взятые из интернета готовые решения), вся защита сводится к очень короткому списку:
Для разработчиков же (я имею в виду именно тех, кто пишет новые системы, а не прикручивает взятые из интернета готовые решения), вся защита сводится к очень короткому списку:
- Валидируйте все входящие и исходящие данные по структуре и типам;
- Не клейте SQL конкатенацией строк никогда, кроме случаев фреймворков (но во фреймворках можно и код более качественно писать, сделав дополнительную валидацию всех склеиваемых фрагментов);
- Как можно чаще делайте кеширование чтобы избежать повторяющихся запросов и лишних нагрузок (кеш на диске, в памяти в специальных хеш-СУБД и т.д.);
- Разделяйте систему для разработки (закрытую от внешнего мира) и продакшен систему (из которой нужно удалить половину, а оставшееся минифицировать и «утоптать» по максимуму);
- Всегда предусматривайте блокировку запросов по IP, если с них идет странная активность (пользователь не сгенерирует 100 запросов в минуту и не будет долбить сервер 24 часа напролет, пользователи — люди, они едят и спят)
- Определяйте попытки SQL-инъекций и XSS-инъекций, не просто их фильтруйте, а блокируйте IP
+4
Я сошлюсь на ваш комментарий в одной из моих следующих статей, после аудита «белого ящика»
0
так как поддерживаю написанное Вами :-)
0
Люди, сидящие за NAT-ом (жители студенческих общежитий, например) будут вам невероятно благодарны за блокировку по IP.
+2
Убираем из статьи воду:
Анализ типа «черный ящик»:
1. По прямым и косвенным признакам стараемся идентифицировать содержимое ящика
2. Применяем перебор всех возможно шибочных входов
3. Пытаемся придумать новый набор входных данных, которые могут вызвать ошибку.
Анализ типа «черный ящик»:
1. По прямым и косвенным признакам стараемся идентифицировать содержимое ящика
2. Применяем перебор всех возможно шибочных входов
3. Пытаемся придумать новый набор входных данных, которые могут вызвать ошибку.
+3
Скоро я планирую написать статью про сервис websitedefender от Acunetix. Детали работы сервиса поддержка раскрывать отказалась, поэтому немного поправил их скрипт и пополняю логи. Анализ будет чуть позже ;)
От себя замечу, что очень многие забывают про контроль самих файлов веб-приложения, концентрируясь на атаках извне через веб. Но есть же и шеллы, и вирусы, крадущие пароли от ftp из клиентов и пишущие потом iframe. А все это очень просто обнаруживается простейшим файловым монитором.
В дипломе как раз такой прикручивал к phpids, чтобы получить phpips ;)
Кстати, буду рад если кто подскажет, как можно повысить карму, чтобы статью потом можно было добавить в этот блог. Я на хабре пока только читаю в основном.
От себя замечу, что очень многие забывают про контроль самих файлов веб-приложения, концентрируясь на атаках извне через веб. Но есть же и шеллы, и вирусы, крадущие пароли от ftp из клиентов и пишущие потом iframe. А все это очень просто обнаруживается простейшим файловым монитором.
В дипломе как раз такой прикручивал к phpids, чтобы получить phpips ;)
Кстати, буду рад если кто подскажет, как можно повысить карму, чтобы статью потом можно было добавить в этот блог. Я на хабре пока только читаю в основном.
+1
Nessus вроде как сам использует nmap для сканирования открытых портов.
0
Sign up to leave a comment.
Аудит. «Черный ящик»