Информационная безопасность в веб - основы

2,258 views

Published on

0 Comments
4 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
2,258
On SlideShare
0
From Embeds
0
Number of Embeds
41
Actions
Shares
0
Downloads
25
Comments
0
Likes
4
Embeds 0
No embeds

No notes for slide

Информационная безопасность в веб - основы

  1. 1. Информационная безопасность в веб - основы
  2. 2. Представляюсь на всякий случай• Странствующий рыцарь• root@.....com, root@......ru, root@......kz, … .• Когда-то давно занимался битхаком• Когда-то давно работал экспертом по инфобезопасности• Меня можно нанять для добрых дел
  3. 3. Аудитория доклада• IT-бизнесмены• Архитекторы приложений• Инженеры-разработчики• Инженеры-эксплуатационщики• Системные администраторы• Просто хорошие люди
  4. 4. Disclaimer• Все, о чем я расскажу, может оказаться ложью• Ни один из приведенных примеров не имел места в действительности• Если после моего доклада от вас ушла девушка, я не при чем• Цель этой презентации не состоит в возбуждении ненависти или вражды к социальной группе «идиоты» либо иным
  5. 5. Предметная область• Защита информации• (Кстати, это очень скучно, кто не будет спать к концу доклада – тот security expert)• Какой еще информации?• В веб мы обрабатываем пользовательскую информацию, ее и будем защищать• Чтобы защищать инфраструктуру, нужно ее сначала нарисовать
  6. 6. Театр начинается с вешалки,• А защита информации – с построения модели угроз (threat modeling)• Кто-то сказал «Microsoft»?• Нет, Microsoft это не угроза, а создатель модели классификации угроз STRIDE• И надстройки над Visio, которая позволяет не только считать ее падения, но и нарисовать модель угроз
  7. 7. STRIDE• Spoofing – маскировка под другого субъекта• Tampering – порча (подделка) данных• Repudiation – отказ от авторства• Information disclosure – раскрытие (сенситивной) информации• Denial of service – отказ в обслуживании• Elevation of privilege – повышение уровня привилегий
  8. 8. Информационная система (сайт)• LAMP• Хранилище пользовательских данных (M)• Сервисы обработки и представления данных (A,P)• Системные и инфраструктурные сервисы, платформа (L)• С точки зрения информационной безопасности можно выделить субъекты и объекты безопасности• Субъекты доступаются к объектам
  9. 9. Модели разграничения доступа• DAC – discretionary access control, классическая модель Unix r/w/x bits• MAC – mandatory access control, что-то военное• RBAC – role-based access control, кто-то опять сказал «Microsoft»?• Да, реализацию RBAC можно наблюдать в линейке MS Win NT (а старички скажут «Netware»)• RBAC – очень популярная модель
  10. 10. Люди любят котиков• Хватит теории, жги давай!
  11. 11. Еще немного теории• Люди любят сокращения, вот еще одно• POLP – principle of least privilege• Каждый субъект безопасности должен иметь доступ только к тем объектам безопасности, которые необходимы ему для легитимного исполнения своих обязанностей
  12. 12. Хранилище данных (M) – S• Spoofing?• Внешние пользователи вообще не должны иметь доступа к хранилищу данных• Если кто-то проник в сеть, то ему придется подделывать TCP-сессию, так как обмен информацией с базой данных обычно происходит неразрывно• Можем считать, что это не проблема
  13. 13. Хранилище данных (M) – T,R• Little Bobby Tables (http://xkcd.com/327)• We will learn how to sanitize to sanitize our database inputs a bit l8r • Но это все еще не проблема хранилища данных• С точки зрения хранилища данных все изменения «подписаны» пользователем, который их произвел• Но это системный пользователь• Да, это компромисс
  14. 14. Хранилище данных (M) – I• Информацию можно разделить на сенситивную и не очень• Зачем разделять, давайте зашифруем всё?• …WHERE name LIKE ‘%ash%’…• Зашифруем раздел на диске (минус – теперь для старта системы нужен человек)• Зашифруем в базе то, что действительно сенситивно:• Пароли• Номера кредитных карт?• Вы храните в базе номера кредитных карт???
  15. 15. Шифруем пароли• Где-то нужно держать ключ?• Сделаем лучше необратимое хэширование• md5($password)• vasya: 698d51a19d8a121ce581499d7b701668 petya: 698d51a19d8a121ce581499d7b701668• Чему равно md5(‘111’)?• Rainbow tables• md5($salt . $password)• $salt – случайное число, сопоставляется пользователю и хранится где-то (в той же базе?)
  16. 16. Хэшируем пароли• “MD5 GPU brute force speed exceed 200 millions MD5 hash/second (default charset [a- z,0-9])”• “As of 2011, commercial products are available that claim the ability to test up to 2,800,000,000 passwords per second on a standard desktop computer using a high-end graphics processor” (NTLM hash)• Используйте МЕДЛЕННЫЙ алгоритм (в настоящее время – SHA-512, Whirlpool)• Key stretching, PBKDF2
  17. 17. Хранилище данных (M) – D• Наблюдается в веб сплошь и рядом• Практически всегда, первое, что отказывает при увеличении нагрузки на сайт – это хранилище• Занимайтесь оптимизацией производительности• Кэшируйте• Кстати, про все это я читаю доклады
  18. 18. Хранилище данных (M) – E• Если вы администрируете базу данных при помощи PHPMyAdmin – убейте себя• Если вы администрируете базу данных по незащищенному удаленному соединению – убейте себя (или сделайте VPN)• Если вы не умеете работать в локальной консоли сервера – убейте себя• Не забывайте про POLP – системный пользователь приложения должен иметь доступ только к базе приложения
  19. 19. Хранилище данных (M) – E• Создатели протокола MySQL уже немного позаботились о вас – пароль невозможно узнать, имея дапм протокола• Пароль можно подсмотреть в конфигурационном файле вашего приложения• Но это не проблема хранилища данных
  20. 20. Сервер приложений (A,P) – S• Плохой пользователь может украсть cookie у хорошего и подделать его сессию• Используйте SSL для шифрования канала, тогда плохой пользователь не сможет украсть cookie путем прослушивания канала• Все еще можно украсть cookie из браузера• Трекайте пользовательскую активность, чтобы по поведенческим шаблонам отличать плохого пользователя от хорошего («обычные» и «необычные» IP-адреса)
  21. 21. Сервер приложений (A,P) – T• Сервер приложений хранит пользовательские данные – файлы, сессии, и ничего с этим мы поделать не можем• Сервер приложений использует один системный аккаунт на все приложение• Если приложений несколько – дайте им разные системные аккаунты!• А лучше – разные виртуальные окружения!• Не забывайте про POLP• Вы уже делаете бэкапы?• А контрольные суммы важных файлов вы считаете?
  22. 22. Сервер приложений (A,P) – R• Сервер приложений – та часть системы, которая непосредственно взаимодействует с пользователем• Перед тем, как изменить сенситивные данные по запросу пользователя, еще раз убедитесь, что он – это он (спросите пароль?)• Хороший способ убедиться, что автор изменений это действительно автор изменений – выдать пользователю сертификат• Всегда ведите логи важных изменений
  23. 23. Сервер приложений (A,P) – I• Отключите вывод отладочной информации на продакшн системе (!!!)• Хотите скрыть число реальных пользователей на проекте и все еще подставляете суррогатный ID пользователя в URL?• Убрать версию софта из HTTP headers может быть не такой плохой идеей• Обязательно защищайтесь от SQL injection, пока у вас не украли базу прямо через ваше приложение
  24. 24. SQL injection• Little Bobby Tables is back again!• Как защититься?• В PHP есть миллион функций, которые, вроде бы, делают string escaping• У OWASP есть библиотека, в которой есть функция...• Используйте prepared statements и вообще забудьте про injection!• Но не будьте наивны и не делайте prepared statement из строки, которая уже содержит переданные пользователем значения!• Такая магия не работает!
  25. 25. Сервер приложений (A,P) – D• На одном слайде рассказать обо всем невозможно• Учитесь отличать мусорные запросы от настоящих• Заведите систему автоматической классификации трафика («нарисуйте сову»)• Кстати, такая система есть у московской компании Highload Lab• Не используйте для блокирования мусорных запросов стоковый iptables• Используйте ipset или аналоги
  26. 26. Сервер приложений (A,P) – E• Никогда не запускайте сервер приложений с правами пользователя root• Если в приложении существуют различные уровни доступа, потратьте время на создание внутреннего security framework и обязательно покройте его unit тестами• Интегрируйте в систему этот security framework таким образом, чтобы его было трудно обойти• Перед выполнением какой-то операции проверяйте роли и права пользователя
  27. 27. Сервер приложений (A,P) – E• Защищайтесь от подбора пароля – CAPTCHA, блокирование IP после нескольких неудачных попыток• Требуйте от пользователя соответствия password policy• Умейте выделять неожиданное поведение пользователя – для этого трекайте его ожидаемое поведение (IP адреса, UA)• Введите двухфакторную аутентификацию (например, через SMS)• Но сделайте ее удобной
  28. 28. Платформа (L) – S• Всю служебную коммуникацию с системой (деплоймент, обслуживание) проводите по шифрованным каналам• Для установления шифрованного соединения применяйте двухфакторную аутентификацию (IP-адрес + ключ, IP-адрес + пароль)
  29. 29. Платформа (L) – T• Используйте AIDE, Tripwire или аналоги для отслеживания целостности компонентов платформы (конфигурационных файлов, etc)• Вы уже делаете бэкапы?• Создайте централизованный лог-сервер и ведите логи на него (syslog это позволяет)• Lennart Poettering знает, как правильно вести логи и скоро научит нас всех (лог-файлы будут криптографически подписаны)
  30. 30. Платформа (L) – R• Про логи на отдельный сервер я уже говорил?• Раздайте пользователям ssh ключи с паролями и пусть ходят по ключам – ключ невозможно подобрать подбором• Не давайте никому заходить удаленно под пользователем root, пусть ходят под именными логинами и делают su или sudo• Регулярно проверяйте, что эти правила выполняются
  31. 31. Платформа (L) – I• Установите и настройте Grsecurity, SELinux, RSBAC, AppArmor или Tomoyo – будет не очень легко, но вы справитесь, если захотите• Используя POLP и permissive mode указанных выше систем, раздайте системным пользователям нужное количество прав• Включите enforcing mode• Можно использовать POSIX ACLs для более точной раздачи прав
  32. 32. Платформа (L) – D• Используйте систему сбора статистики и оповещения (NAGIOS, Icinga, Zabbix, etc)• Используйте возможности системы по ограничению количества потребляемых сервисами/системными пользователями ресурсов• Используйте виртуализацию и ограничивайте виртуальные машины в ресурсах• Не держите важные и второстепенные сервисы на одном физическом хосте
  33. 33. Платформа (L) – E• Защищайтесь от подбора пароля (используйте демоны DenyHosts, fail2ban или аналоги)• Перенести сервисы на другие порты?• Думаете, атакующий их не узнает? • Port knocking• Организация VPN для доступа к внутренним инфраструктурным сервисам• Обязательно применение security updates для используемых сервисов – регулярно находятся и устраняются remote vulnerabilities
  34. 34. Все?• Сервер мы защитили• Но остался еще пользователь• А у пользователя есть браузер• Который тоже представляет из себя информационную систему
  35. 35. Браузер – S• Сплошь и рядом – браузер не может отличить JavaScript-приложение, попавшее в него в результате срабатывания XSS-уязвимости на сайте от легальных действий пользователя• А ведь есть еще и CSRF-атаки
  36. 36. XSS• <script>alert(“Hello, I’m a hacker!”)</script>• А разгадка одна – слишком высокий уровень доверия к введенным пользователем данным• Безжалостно режьте или экранируйте все, что браузер мог бы интерпретировать как JS• В библиотеке OWASP есть одна функция...• А в PHP их миллион• Общий принцип: доверие к пользовательским данным должно быть минимальным
  37. 37. CSRF• Cross Site Request Forgery• Хороший пользователь залогинен на сайте a.com• Сайт a.com позволяет менять состояние через GET-запрос• Пользователь идет на сайт злоумышленника, где ему формируют GET- запрос, меняющий состояние на сайте a.com• Защититься легко – различайте GET и POST и ставьте one-time challenges в формы
  38. 38. Браузер – T,R,D• Раньше браузер не хранил ничего, кроме cookies, теперь есть еще local file storage• Наверняка появится много новых интересных проблем, связанных с его безопасностью• Ваш браузер – это вы, на серверной стороне небезосновательно считают, что с той стороны вашего браузера вы, и никто другой• Особенно, если вы прошли аутентификацию• И сложно будет доказать обратное• DoS браузера? Нет, не слышал
  39. 39. Браузер – I,E• Раскрытие информации происходит сплошь и рядом благодаря XSS уязвимостям• Как ни странно, в браузере возможно и повышение привилегий: http://habrahabr.ru/company/dsec/blog/14168 4/• Подобные уязвимости находят и исправляют постоянно, всегда следите за апдейтами ваших браузеров
  40. 40. Литература• Rainbow series (good luck!)• OWASP Guide• Security mailing lists используемых вами дистрибутива, сервера приложений, etc• http://security.stackexchange.com• Журнал «Хакер»
  41. 41. Вопросы?••••••
  42. 42. Контакты• alexclear@gmail.com• http://alexclear.livejournal.com• http://github.com/alexclear• skype://demeliorator

×