CC BY
53
ЗАЩИЩЕННЫЙ ФОРУМ
В.О. Доскач, И.М. Инюшин, Р.В. Леонтьев Научный руководитель - доктор технических наук, профессор Л.Г. Осовецкий
В статье обсуждается проблема защиты информационных систем от несанкционированного воздействия злоумышленников. На примере форума рассматриваются основные угрозы информационной безопасности, а также методы противодействия им. Предлагаются новые системы защиты от несанкционированного воздействия, рассматривается вопрос создания защищенного форума.
Введение
Защита конфиденциальной информации в Интернете приобретает в последнее время большую актуальность. На примере ведения защищенного форума можно наглядно показать, какие угрозы информационной безопасности на сегодняшний день наиболее опасны.
Опасность угрозы можно оценить, исходя из следующих показателей:
• частота активации угрозы;
• ущерб, который может нанести активация угрозы.
Ущерб условно можно ранжировать так:
• большой - кража всей информации, в том числе имен пользователей и паролей, или же уничтожение всей информации;
• средний - уничтожение или кража части информации, но не паролей и имен пользователей;
• незначительный - так называемый «spam». В случае форума это реклама, которую размещают на открытой части форума компьютеры-роботы или пользователи, которым нечего делать. При этом не происходит кражи или уничтожения информации.
Распространенные форумы
Распространенным явлением на сегодняшний день является использование так называемых готовых «движков» для создания форума. Этот подход позволяет сэкономить огромное количество времени, так как установка такого «движка» занимает считанные минуты, да и дальнейшая настройка и подстройка под общий дизайн сайта не занимает много времени. Но данный подход имеет и ряд очень серьезных недостатков, особенно с точки зрения обеспечения защищенности информации.
Чтобы обеспечить достойную защиту информации на форуме, можно пойти двумя путями - либо создавать свой собственный форум, либо писать дополнительные модули защиты для готового «движка».
Ясно, что первый подход предпочтительнее, так как в этом случае вы будете точно знать, как функционирует форум, все его варианты использования и возможные состояния. Соответственно можно определить набор угроз и предпринять меры для их нейтрализации. Если же пойти по пути создания дополнительных модулей защиты, то всегда возникает вопрос - а все ли защитили, все ли ситуации предусмотрели, так как в этом случае невозможно знать все варианты использования и возможные состояния системы.
На данный момент существует множество «движков» для построения форума. Наиболее распространенными из них являются PHPbb (PHP), Invision Power Board (PHP), VBulletin и др.
Виды угроз
Если посмотреть на все существующие платные и бесплатные форумы, то можно увидеть, что каждый из них имеет хотя бы самый низкий уровень защиты. Но нельзя не упомянуть о том, что они совершенно не справляются с более серьезными нападениями. Существует несколько видов атак, перечисленных ниже.
• Несанкционированная реклама, оставляемая программами-роботами. Иначе эту проблему можно назвать спамом.
• Похищение идентификатора сессии при помощи JavaScript или любого другого скрипта с последующим несанкционированным входом от имени атакуемого. Данный вид атаки называется XSS.
• SQL-инъекции. Данный вид атаки подразумевает получение доступа к базе данных или получение/модификацию части данных посредством ошибок серверного скрипта.
• Флуд - очень частое оставление сообщений на форуме одним и тем же пользователем (чаще всего они не несут в себе смыслового содержания).
• Получение повышенных прав или понижение работоспособности посредством использования ошибок в программном коде.
• Внедрение произвольного кода.
Обзор методов защиты
Большинство существующих форумов не реализуют в полной мере защиту. Также большим недостатком многих форумов является их открытость. Открытый исходный код позволяет любому человеку изучать его и находить ошибки в коде раньше самих разработчиков. Через эти ошибки в коде несанкционированный пользователь может нарушить работоспособность форума. Даже если ошибки были устранены, то все равно остается вероятность того, что не все пользователи вовремя обновляют свой экземпляр форума, вследствие чего форум может быть подвержен атаке через ошибку, которая была разглашена и исправлена в новых версиях форума.
Все форумы имеют базовый уровень защиты как на этапе регистрации, так и на этапе использования форума. Каждый пользователь для получения определенных прав должен быть зарегистрирован. При регистрации, помимо его настроек и имени, указывается контактный адрес электронной почты. Пользователь не может указать подложный адрес, так как необходимо перейти по специальной ссылке, указанной в письме. Это обходится разными способами, но самым простым является открытие временного электронного адреса на бесплатном почтовом сервере. Хоть этот уровень защиты очень легко обходится, но все же это является первым рубежом. Также при регистрации ограничиваются все программы-роботы, так как требуется ввести код на изображении, который был сгенерирован программой, и его весьма сложно считать автоматически, поскольку на текст накладываются помехи.
В большинстве форумов присутствует защита от подмены сессии. Если пользователь вдруг поменял свой IP-адрес, что бывает при работе через прокси-сервер, а также при получении доступа в Интернет через модем IP-адрес назначается пользователю автоматически и может быть изменен во время использования Интернет (но, по правде, случается это не очень часто).
Также присутствует защита и от флуда. Существует интервал времени, чаще которого сообщения от пользователя не принимаются. Чаще всего период блокировки невелик, но этого времени хватает, чтобы прочесть сообщение, а потом на него ответить. Кстати говоря, на всех форумах есть такая вещь, как цензура: недопустимые слова заменяются другими, чтобы оградить пользователей от ненормативной лексики.
В некоторых форумах присутствует частичная защита от SQL-инъекций. Суть защиты состоит в том, чтобы в форму не позволять вводить недопустимых символов. Иногда это опрометчиво реализуется через JavaScript, а иногда в самих серверных скриптах.
На этом чаще всего защита заканчивается. Даже вышеперечисленные методы защиты реализованы не на всех форумах. На форум также может быть осуществлена атака посредством получения доступа к серверу через уязвимости в программном обеспечении (Web-сервере, сервере баз данных, а также некорректной настройке операционной системы). Но это выходит за рамки данной статьи.
Обзор платформ
Языки, на которых написаны форумы - самые разные, начиная от PHP и заканчивая Java. Но ни один из известных форумов не может похвастаться стопроцентной защищенностью. В чем же связь такой «незащищенности» форумов и языка их реализации?
Рассмотрим поэтапно некоторые платформы и их слабые места.
PERL. Один из самых ранних языков, применявшихся при написании форумов -это Perl. На данном языке написан один из известнейших форумов - Ikonboard. Он также чаще остальных применялся и при написании гостевых книг. Какие самые частые ошибки встречаются при использовании данного языка?
Во-первых, это недостаточность проверки входных данных при подключении какого-либо файла, так как злоумышленник может вместо предполагаемого вами файла встроить свой собственный - это достигается при помощи использования внешних URL'ob. К примеру, http://yoursite.com/cgi-bin/some.pl?file=http://attacker.com/file.txt . В данном случае необходимо фильтровать переменные на наличие http:// или ftp://.
Либо, если ваш скрипт читает какой-либо файл с сервера, злоумышленник может прочитать другой файл, содержащий конфиденциальную информацию. Достигается это с использованием и ../ - переход в папки высшего уровня (зависит от операционной системы). Например, http://yoursite.com/cgi-bin/some.pl?file=../../../../../etc/passwd. В данном случае необходимо фильтровать переменные на наличие ../ ..\.
Кроме того, в Perl высока опасность того, что злоумышленник сможет встроить в переменную системные команды, которые будут выполняться от имени вашего скрипта. Это достигается использованием «пайпа» - вертикальной черты. Например, http://yoursite.com/cgi-bin/some.pl?some=|id; ls -la|. В данном случае необходимо фильтровать пайпы. Это уникальная уязвимость, относящаяся только к данному языку.
Еще в Perl есть уязвимость под названием «нулевой байт» %00 (\n в Си). Если встроить этот байт в переменную, то она оборвется там, где этот байт встроен, что может привести, опять таки, к чтению конфиденциальных файлов. Например, http://yoursite.com/cgi-bin/some.pl?file=../../../../../etc/passwd%00.
Встречаются и SQL инъекции, однако реже, чем в PHP, потому что многие форумы на Perl используют только текстовые базы данных.
PHP. Самый популярный на данный момент язык написания форумов, PHP, подвержен более всего двум видам уязвимостей.
Первая - SQL-инъекции, когда злоумышленник может встроить в ваш SQL-запрос свою команду. Это одна из самых частых и опасных уязвимостей, которая позволяет злоумышленнику читать и изменять вашу БД. Во многом это происходит из-за автоприведения типов в PHP (удобство в ущерб безопасности).
Вторая - это подключение «внешних файлов» функцией include или require аналогично Perl. Кроме того, возможна запись в PHP-файл вредоносного кода (редко встречающаяся в профессиональных разработках ошибка).
Можно отметить, что ни в PHP, ни в PERL нет встроенных функций защиты.
СИ. Возможно написание форумов на Си, но так как этот язык не приспособлен для работы в Интернете, практически нет форумов на этом языке. Поэтому рассматривать защищенность данной платформы нет особого смысла.
JAVA. Уязвимость форумов на JAVA исследована не слишком хорошо, но, как показывает практика, такие форумы гораздо лучше защищены за счет имеющихся встроенных средств защиты (например, от SQL-инъекции), а также благодаря более четкой структурированности языка и его строгости (отсутствию автоприведения переменных, что не позволяет злоумышленнику встроить, например, строковую переменную в числовую ячейку).
Все форумы также подвержены уязвимости под названием XSS (Cross-Site Scripting), основанной на использовании языков «скриптования» (в основном Java Script), которые встраиваются в сообщения форума и позволяют злоумышленнику красть конфиденциальные данные (Cookie или сессии).
Созданная нами защита
В качестве примера можно привести то, что было реализовано для защиты форума, созданного на кафедре безопасных информационных технологий СПбГУ ИТМО, от несанкционированного доступа. Мы столкнулись с проблемой использования открытого форума - большое количество общеизвестных уязвимостей. Самая насущная из них - межсайтовый скриптинг (иначе XSS). Она реализуется через ошибку в реализации обработки BB-тегов (это специальные теги для форматирования введенного текста как альтернатива HTML). Они были отключены вплоть до исправления ошибок в коде.
Также присутствовала проблема SQL-инъекций. В скрипты PHP очень легко встроить свой код, и при неправильной настройке интерпретатора он готов заменить любую переменную в скрипте на переменную из POST/GET данных. На этом форуме, как и на многих других, на протяжении всех версий появлялась информация о новых найденных ошибках. Казалось бы, им нет конца. Но нашелся один простой способ решения. К ядру форума был встроен скрипт, который проверяет все полученные от пользователя данные и ищет в нем ключевые слова языка SQL. Это не позволяет пользователям использовать эти слова в сообщениях, но зато делает форум неуязвимым от такого рода атак. Также в категорию запрещенных слов были введены HTML-символы и ключевые слова JavaScript, что позволяет отгородиться также и от XSS.
Хотя подобная защита не делает форум полностью защищенным, но это дает небольшие гарантии того, что он не будет «повержен» стандартными способами.
Также следует отметить, что на уровне программного обеспечения кафедральный WEB-сервер защищен от внешних атак, так как большинство портов закрыты, поэтому злоумышленник не может войти в прямой контакт с сервером баз данных.
Новые рубежи защиты
Но мы не останавливаемся на достигнутом уровне и придумываем новые рубежи защиты. С некоторыми из них мы вас сейчас познакомим.
Помимо методов пассивной защиты, необходимо упомянуть активную защиту. Будем отталкиваться от того, что форум может быть взломан в течение получаса посредством анализа и реализации уязвимости в коде сайта. Пусть его взломали и стерли всю информацию. Но разве это является проблемой, если у нас будут создаваться резервные копии базы данных параллельно работе форума каждые 5 минут. Естественно, для таких операций нужен мощный сервер. Поскольку сервер с PHP-сайтом настроен
обычно плохо и скрипт может перезаписывать себя другим, т.е. смысл - проверять время модификации файла или контрольную сумму. В случае малейшего изменения все возвращается назад. Допустим, что пользователь смог аварийно завершить работу программы (например, HTTP-сервера). Мы можем также создать процесс, который будет запускать программу заново. Естественно, пользователь, который совершил атаку, должен быть заблокирован файерволом или форумом для исключения повтора реализации уязвимости. После того, как система смогла восстановить рабочее состояние, администратор должен быть уведомлен по электронной почте о проблемах с сервером. При таком раскладе вероятность вывода из строя форума на длительное время уменьшается.
Но в этой системе не хватает еще одного элемента (механизма вычисления нарушителя). Естественно, нужно получить максимальную информацию о нарушителе. Во-первых, необходимо узнать все об IP-адресе: по какому маршруту он проходит, где находятся сервера из цепочки, используются ли прокси-сервер и так далее. Если нам повезет, то мы выйдем на провайдера в нашем государстве. В этом случае можно обратиться в компетентные органы. Но, чаще всего, этого не случается. Скорее всего, пользователь сидит через прокси-сервер, а то и через несколько, да еще и в разных частях планеты. А потом может оказаться, что он сидел за соседним компьютером. В случае анонимных прокси-серверов, да еще и в другой стране, мы вряд ли сможем найти пользователя. Но почему бы не проверять всех пользователей и не допускать к форуму тех, кто заходит на сервер по подобной схеме? Процесс анализа цепочки IP-адреса - долгий, а потому он должен выполняться в фоновом режиме. Тогда у нарушителя, в лучшем случае, при первом заходе с такого IP будет всего несколько десятков секунд на попытку взлома. После этого он будет заблокирован полностью.
Таким образом, предлагается ввести схему анализа источника угрозы и последующего блокирования всех пакетов с данного адреса на некоторое время. Но данный механизм можно упростить, если воспользоваться ошибками атакующего. Во-первых, можно встроить в страницу Java-апплет и JavaScript. Оба они будут заниматься сбором дополнительной информации о пользователе. С помощью JavaScript нельзя много узнать (только версию браузера, название ОС, а также разрешение экрана), а с помощью апплета можно узнать имя компьютера, язык системы, регион, а также реальный IP-адрес. Это поможет вычислить нарушителя.
Распространенной ошибкой хакеров является недосмотр за COOKIES. Можно помечать пользователя, и, если он потом зайдет через прокси-сервер для реализации уязвимости, то будет моментально опознан и заблокирован. Но такое бывает крайне редко.
Второй решаемой проблемой является флуд - публикация пользователями бессмысленных сообщений. На форумах имеется базовый вид защиты от таковых при помощи введения задержки публикации.
Нами предлагается развитие метода борьбы с флудом. Это, прежде всего, автоматическое и ручное соотнесение с пользователям уровня доверия, чтобы исключить излишние проверки. Во-вторых, подобные сообщения зачастую содержат специфическую лексику, на основе которой можно блокировать сообщение. Это не решает всех проблем, однако упрощает жизнь модераторам. В принципе, в целях борьбы с флудом установлена вполне устойчивая система назначения на каждый раздел модератора, который следил бы за выполнением установленных правил.
Также следует отметить, что техника фильтрации по ключевым словам и шаблонам сообщений дала положительные результаты при защите от роботов, которые оставляют информацию рекламного характера на форуме. Блокируются все 100% роботов. Если говорить обо всем объеме спама (в том числе и опубликованного вручную),
то фильтруется 99% всех сообщений. Удалением одного - двух сообщений в месяц занимается модератор.
Важность аудита
Во многих информационных системах ведется тщательная слежка за событиями, которые исходят от пользователя. Так почему бы не применить подобную политику и к форуму?
На большинстве готовых форумов существуют базовые события, такие как вход в систему, выход из нее, добавление/удаление/модификация сообщений (как общедоступных, так и личных), смена ГР-адреса, изменение личных параметров и так далее. В принципе можно хранить даже все переменные, передаваемые скрипту от пользователя.
При наличии журнала есть возможность анализа действий пользователя. Любое отклонение от стандартного протокола работы должно быть зафиксировано и обработано. Это должно производиться исключительно автоматически, лишь в редких случаях эта информация должна быть проанализирована пользователем.
На основе получе нной информации программа может управлять правами пользователей на допуск к определенному виду информации, а также на выполнение каких-либо операций.
К сожалению, не все форумы обладают средствами аудита, что значительно усложняет работу администратора.
Заключение
В статье были рассмотрены основные методы защиты форума от несанкционированных действий со стороны пользователя. Обобщив все вышесказанное, можно говорить об эффективности новых уровней защиты, таких как:
• фильтрация ключевых слов (для защиты от ХББ и БОЬ-инъекций);
• использования средств контроля целостности и работоспособности;
• использование средств анализа ГР-адреса и последующего блокирования несанкционированных пользователей;
• автоматической пометки подозрительных пользователей;
• фильтров рекламы и флуда;
• ведение аудита.
Задействовав данные уровни защиты, можно получить возможность в большей мере контролировать действия пользователей и защитить форум от попыток нарушения работоспособности и чистоты информационной среды.
В планах авторов - разработка адаптивной системы защиты с использованием интеллектуальных технологий, таких как нейро-нечеткие сети и система экспертных оценок. Эти технологии должны значительно увеличить функциональность и «выживаемость» информационной системы кафедры.
