LINUX.ORG.RU

ИБ в web (направьте на путь истинный)

 


1

1

Привет, Лор. Прочитал много инфы в инете, но чего-то запутался. Есть несколько видов ИБ (не будем рассматривать сторону закона, интересует техническая сторона). Как именно защищают сайты, латают дыры, что надо знать (кроме технологии, на которой сам сайт писали), что надо знать о серверах и на сколько сильно? В общем подскажите мне, очень заинтересовало.

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

Всем спасибо.

похапе обнови для начала.

anonymous
()

Если говорить про ИБ - первым делом надо уходить от Ruby. У них периодически появляются критические уязвимости, которые далеко не сразу латаются.

А в общем случае:
iptables - закрыть все кроме нужного (22, 80, 443).
FTP - убрать как класс.
fail2ban - но грамотно, чтобы себя не подставить (читайте, граблей много).
WAF - к примеру, nginx-naxsi.

Для www используй chroot, как минимум (а еще лучше - vz контейнер), ограничь www юзеру все что только можно, php - аналогично, вплоть до open base dir и блокировки функций eval, system и т.д.

Для обновления используй какой-нибудь деплой, к примеру через git. Это позволит проверить изменившиеся файлы. Само их появление должно вызвать подозрения.
Туда же конфиги всех сервисов. Я раньше делал md5sums всех файлов сервера, спасало пару раз. Многие руткиты подменяют стандартные утилиты ls, attr, top так, чтобы те их не показывали.

Против DDOS довольно эффективны услуги на базе CDN (айри, cloudflare, qrator)

Ну и далее, смотри логи, реагируй, регулярно проверяйся aibolit

BaBL ★★★★★
()
Последнее исправление: BaBL (всего исправлений: 1)

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

anonymous
()

В первую очередь это качество кода и уровень глубины реализации.

Типичные моменты:

- SQL-инъекции: отсутствие в SQL-запросах биндингов входных данных через prepare. Детектируется отсутствие в коде prepare и «нативных плейсхолдеров»

- Регулярки с участием входных данных - извечная проблема с переполнением буфера, старые (непропатченные) библиотеки

- Нешифрованные каналы связи и отсутствие шифрования на клиенте очевидно

- Бинарщина

- Возможность изменить содержимое страницы извне (через javascript-например). Простейший тест: если на вашей странице можно разместить исполняемый фрагмент js-кода (alert(1);), то есть над чем еще поработать. Например угон кук.

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

- Сервер: права, слабые пароли, дополнительные сведения, порты, обновления, бэкдоры. Самое простое: upload на сервер исполняемого скрипта и его выполнение через веб интерфейс в простейшем случае - echo system('cat /etc/passwd');

- изучение структуры каталогов сервера. «Пробиваемость» через поисковые системы, включая дампы ошибок приложения

- скрытые и заброшенные каталоги и файлы сервера: CVS, .git, .svn, phpinfo

ну и еще много чего

anonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.