SecurityTips

Материал из OpenWiki
Перейти к: навигация, поиск

Заметки по безопасности

  • Ежедневное слежение за отчетами с описанием новых проблем с безопасностью в рассылках и на специализированных сайтах.
  • Не дожидаться обнаружения ошибок, попытаться предотвратить их проявление. Всегда считать, что в программе есть ошибки, обдумать что можно сделать чтобы система не пострадала от их проявления. Система должна быть неприступна, невзирая на вероятные проблемы с безопасностью в программах.
    • Избыточные, параноидальные проверки в своем коде. Проверки на каждом этапе использования полученных от пользователя или иного внешнего источника данных.
    • Понижение привилегий и запуск в chroot или на виртуальном сервере. Но не нужно забывать, что уязвимость в ядре или коде монитора виртуальной машины вполне могут быть использованы злоумышленником для выхода из chroot или виртуального окружения.
    • Использование библиотек-врапперов подменяющих потенциально опасные библиотечные вызовы или сборка спец компиляторами с средствами защиты от переполнения буфера.

Сниффинг

Особое внимание следует уделить внутренней безопасности, для предотвращения появления злоумышленника в доверительной сети. Сниффер в доверительной сети, не меньшая угроза, чем открытая брешь в ПО. Средства защиты от злоумышленника в локальной сети:

  • Шифрование трафика, особенно актуально для сервисов в которых присутствует передача паролей в открытом виде. Но, на одно шифрование тоже нельзя полагаться, об этом ярко говорят ошибки в реализации ssh1, openssl, mod_ssl приводящие к возможности анализа перехваченного шифрованного трафика. (Примеры, замены: http => SSL+http, ftp => sftp, telnet, ssh1 => ssh2, pop3 => apop или pop over TLS/SSL).
  • Жесткая политика доступа к ресурсам управления (ssh, snmp).
    • Разграничение доступа внутренними средствами: ACL программы или tcp wrapper (/etc/hosts.allow). Желательно, чтобы доступ разграничивался как по имени пользователя совместно с ограничением по IP (каким пользователям какие действия можно производить с каких IP).
    • Дублирующее ограничение средствами фаервола, можно как на локальном сервере, так и на пограничном маршрутизаторе.
  • Мониторинг переполнения ARP таблиц. Использование коммутаторов (свичей), не избавляет от возможности сниффинга. Проброс каждого клиента используя VLAN через маршрутизатор или привязка MAC адреса к порту коммутатора - дорогое удовольствие, особенно в больших сетях. Частично проблему помогают решить программные средства слежения за изменением MAC адресов (чтобы пользователи самовольно не меняли IP адреса и не выставляли IP соседа) и мониторинга за переполнением ARP таблиц. Другой способ борьбы с arp-спуффингом - использование специальных патчей на шлюзовой машине или жесткая привязка MAC адресов к IP.
  • Использование временных паролей (One-Time Passwords - OTP, opie, s/key). Например, генерируется список паролей и при каждом входе используется следующий пароль из списка, использованные пароли блокируются.
  • Применение средств автоматического обнаружения вторжения (IDS) под вопросом, так как в таких средствах часто находят критичные ошибки способствующие взлому (пример: snort, tcpdump).

Социальная инженерия

Не следует игнорировать человеческий фактор. Примеры преступной халатности (реальные случаи):

  • Забытый полный бэкап директории /etc, доступный для чтения другим пользователям;
  • Пароли с номером автомобиля или знаменательной датой;
  • Запись паролей на клочке бумаги, который лежит в ящике стола;
  • Сообщение своего пароля коллеге по работе;
  • Оставление открытого десктопа при отлучении от компьютера.

В идеале, даже перехваченный злоумышленником пароль или SSL ключ не должен дать злоумышленнику зайти в систему. Например, следует допускать вход каждого сотрудника только с IP его рабочей машины. Для частичной защиты от управление машиной пользователя через установку троянскоих программ, необходимо запретить входящие соединение на машину пользователя (троянское ПО без проблем может само инициировать соединение, например, создав туннель поверх http-проски, но это немного усложняет работу злоумышленника).

Методы защиты

Закрытая система для решения спец. задач, без публичных сервисов (например, рутер, фаервол)

  • Полное отсутствие сетевых сервисов.
  • SSH доступ только с IP администратора и резервного trusted сервера.
  • Закрытые сервисы доступны только непосредственным потребителям.
  • Двойное или тройное блокирование, пакетный фильтр, libwrap/tcpwrapper и настройки самой программы.
  • Если система не в trusted сети - шифрование всех потоков данных.

Закрытая система с сетевыми сервисами

  • SSH доступ только с IP администратора и резервного trusted сервера
  • Открыты только реально необходимые сервисы.
  • Для открытых сервисов используется только доверительное ПО, в котором ранее не замечали проблем безопасности и прошедшее беглый аудит.
  • Все остальное, если невозможно обойтись без него или заменить в CHROOT.
  • Доверяю ПО: postfix, qmail, popa3d, vsftpd (практика прецедента - не доверять ПО в котором хоть раз найдена критическая ошибка безопасности или программа разработана без использования жесткой политики безопасности (в документации и коде это сразу заметно)).
  • Запускаю в CHROOT: bind/named, apache, ftpd (BSD), inn. Доступ к OpenSSH только с доверительных хостов.
  • Не запускаю в public никогда: все реализации IMAP, samba, sendmail, proftpd, wuftpd, mysql, postgresql, dhcpd, ntpd. Пример особенно безграмотных с точки зрения безопасности систем - proftpd, qpopper, fetchmail.
  • Внимально использовать антивирусы для проверки почты, как правило это закрытые проекты в которых не проводится аудит исходного кода (запуск только в chroot). В дополнение к антивирусам, можно практиковать полную блокировку пересылки выполняемых файлов, или отключить проверку в архивах и запускать в chroot. Подобному решению способствуют прецеденты DoS атак (переполнение диска) через вложенные, специально скомпонованные, сжатые файлы или возможность выполнения кода на сервере через специальным образом скомпонованные заголовки письма.

Открытая система с локальными пользователями (например пользователи могут запускать CGI-скрипты)

  • Разделение привилегий, запретить доступ к другим пользователям и системным файлам по возможности
  • Желательно noexec /tmp и патч для noexec stack.
  • Если можно то в chroot.
  • Не давать исходящих коннектов, если не требуют условия.
  • Убрать все suid программы которые можно убрать, использовать TCB для хранения паролей, вместо /etc/shadow
  • Не оставлять бэкапы в открытом месте, иногда злоумышленник может взломать систему используя старую suid программу из бэкапа или обнаружив общедоступный файл с паролями.
  • Вести подробные логи, включая аккаунтинг выполняемых процессов. syslog логи дублировать по сети на соседнюю машину.
  • Применять программное обеспечения для слежения за целостностью участков файловой системы и поиска root-китов.
  • Дополнительные ограничения для скриптов пользователей системы хостинга (apache в chroot):
    • Запрещение connect(2), невозможность установки исходящих соединений пользовательскими скриптами (используя библиотеку враппер, подгружаемую через LD_PRELOAD в suexec, принудительно меняем для listen и connect IP на 127.0.0.1).
    • Запрещение listen(2), предотвращение приема соединений на сетевой порт. Борьба с процессами демонами, через мониторинг.
    • Ограничение возможности использования группы exec вызовов, предусмотреть использование относительных путей и список исключений (текущая cgi-bin, /bin и т.д.);
    • Запретить для cgi-скриптов возможность создания и перезаписи файлов в директориях с исполняемыми скриптами (cgi-bin).
    • Квоты на дисковое пространство, время выполнения скрипта и объем используемой одним скрптом памяти.
    • Права доступа к диреткории пользователя "drwx--x--- user hosting", где user - id пользователя, hosting - группа из под которой запущен apache (для раздачи статики). Таким образом скрипт пользователя не имеет доступа к диреториям других пользователей.
    • Использование mod_php в режиме safe_mode (php_admin_flag safe_mode on, не забывать, что в php регулярно находят способы обхода open_basedir), запретить использование URL в open (php_admin_flag allow_url_fopen off), ограничить обем ОЗУ (php_admin_value memory_limit 2M), ограничить время выполнения (php_admin_value max_execution_time 10).
    • Мониторинг in/out трафика через mod_watch. Раньше получал полные данные о трафике используя "per user ip accounting", но он учитывал также mysql и прочий локальный трафик, после введения блокировки на listen() и connect(), использование mod_watch вполне оправдано. Предотвращение использование ftp аккаунта для файлового обмена, через дополнительный мониторинг.
  • Аспекты безопасности при написании CGI-скриптов
    • Применение suexec и жесткое разграничение прав доступа (пользователь не должен видеть системных файлов и логов, не должен иметь возможность получить доступ к данным другого пользователя)
    • Полностью исключить использование типовых бесплатных скриптов. Лучше все писать самостоятельно, если написание затруднено - обязателен полный аудит кода чужих скриптов.
    • Паранойя при написании кода - дублирующие проверки всех параметров получаемых в диалоге скрипта с пользователем (как минимум проверка валидности с выводом сообщения об ошибке на этапе инициализации переменных с данными пользователя и жесткое вырезание недопустимых символов (s/[^\w\d_\-.]//g) перед опасными функциями (open, system)), обязательное экранирование переменных при использование в regex выражении (/\Q$var\E/, иначе $var может содержать "?{код}").
    • Perl скрипты пишем на Perl: никаких `` и вызовов shell функций, скрипт с perl -w и в strict режиме;
    • Перед написанием кода - обязательное планирование, перед кодированием скрипт должен уже иметь четкую структуру.
    • После написание - отладка и crash тест.
      • Доступ к системе web-управления, только с "trusted" хостов, желательно по HTTPS.


Защита обслуживаемой сети c пользователями

  • Оборудование и рабочее место администратора не должны быть подключены в рамках одной физической сети (см. выше пункт "сниффинг"). Желательно разделить сеть по отделам (директора и бухгалтерию подключить отдельно).
  • Не допустить доступ к оборудованию посторонним (охрана, дети сотрудников). Обязательная парольная аутентификация на каждой машине и жесткие административные правила пользования сетью.
  • Машины сети снабдить IP адресами из интранет блока. Выход во вне только через прокси или транслятор адресов. Фаерволом закрыть все кроме необходимых сервисов.
  • Установка локального ПО для борьбы с вирусами, постоянное обновление пользовательских систем (установка service pack) и программ для работы в сети (IE, Opera, The Bat, Outlook).
  • Повышение грамотности пользователей.
  • Мониторинг уязвимостей в локальной сети, средства сканирования пользовательских машин на предмет известных уязвимостей.

Защита от DoS и DDoS

  • Тюнинг системы и установка лимитов, недопускающих полного исчерпания системных буферов и уход в своппинг, при исчерпании ОЗУ. Лимиты httpd и скриптов должны быть всегда чуть ниже реальных возможностей системы.
  • На готове должен быть скрипт для составления черных списков IP, на основе выявленной аномалии, присущей текущей атаке (запрос одинаковой страницы; запрос только контентообразующих страниц, без сопутствующих css, js и картинок; аномально высокое число запросв с одного IP; невыполнение javascript вставок; невосприятие cookie).
  • Списки IP адресов подключаем не через отдельные правила пакетного фильтра, а через функциональность работы с таблицами адресов. В особо тяжелых случаях можно блокировать на вышестоящем маршрутизаторе блоки адресов, оставив только адреса стран, составляющих костяк посетителей сайта.
  • Если бот не умеет парсить JavaScript, хорошо помогает использование промежуточной javascript страницы минимального размера. На все запросы отдаем сперва простейшую страницу (только скрипт с document.location='http://www.site.ru/real/page.html') с редиректом на реальную страницу (определяем через rewrite и if в nginx). Плюсы: страница отдается из кэша, без обращения к диску; страница минимизирует трафик, влазит в 1 tcp пакет; если был запрос фиктивной страницы, но не было последующего запроса реальной, можно помещать IP в список блокировки.
  • Расчет лимитов предусматривающих возможность удаленного входа администратора при любой нагрузке. Например, каков бы ни был лимит на число соединений, ограничение пропускной способности сети и ограничение числа запросов через пакетный фильтр, администратор всегда должен иметь возможность удаленно попасть на машину. Для IP администратора делаем отдельные разрешающие правила и выделяем небольшую гарантированную полосу пропускания.
  • При приемке скрипта не экономить времени на стресс-тестирвоание. Например, на тестовом сервере сгенерировать несколько сотен тысяч записей в БД и исследовать как поведет себя система при непрерывном потоке в сотню одновременных запросов к скрипту. Запросы лучше взять реальные из лога http-сервера
Источник — «https://wiki.opennet.ru/?title=SecurityTips&oldid=627»