- Управление патчами
- Методология управления патчами
- Проблемы при установке патчей
- Лучшие практики
- Атаки
- Отказ в обслуживании
- Smurf
- Fraggle
- SYN-флуд
- Teardrop
- Распределенная атака отказ в обслуживании
- Резюме
Производители часто слишком торопятся выпустить продукт на рынок. Это приводит к тому, что в таком продукте обязательно остаются некоторые «дыры». Такие «продукты» могут привести к нарушению безопасности компании, прерыванию ее функционирования и нанести катастрофический ущерб. Для примера, выберите свою любимую СУБД и посмотрите на сайте ее производителя список исправлений (патчей), а затем патчей-для-патчей, которые были выпущены в течение последних пяти лет. Спросите у вашего администратора баз данных (DBA), как часто при установке обновлений перестают работать некоторые специфические(недокументированные) функции, необходимые для ваших приложений. Часто оказывается, что именно эти функции обожают разработчики приложения, и, конечно же, без них приложение работать не может.
Вы можете принять меры для снижения влияния патчей. Наилучший способ состоит в разработке, внедрении и повышении уровня зрелости процесса управления патчами (patch management process), целью которого является обеспечение внедрения патчей и обновлений в промышленную среду управляемым способом и наличие плана для их «отката». Эффективный процесс управления патчами структурирован и выполняется в соответствии со следующей методологией.
Шаг 1: Инфраструктура
Вам необходимо создать основу - инфраструктуру для процесса управления патчами. Это не просто физическая инфраструктура, состоящая из коммутаторов, маршрутизаторов, кабелей и всего остального, что позволяет распространять патчи, но также и всего того, что позволит выполняться самому этому процессу. Нужно разработать стратегию управления патчами, которая подойдет именно вашей компании, а затем сформировать команду, которая будет выполнять этот процесс и вести учет установки патчей в рамках всей компании. Кто должен быть включен в эту команду? Членами команды должны стать не только отдельные системные администраторы, но и представители разработчиков и/или специалисты технической поддержки систем, на которые предполагается устанавливать патчи, а также систем, работающих совместно с ними, и приложений, работающих на их основе. При этом речь идет о любом программном обеспечении, независимо от того, установлено ли оно на жесткий диск или записано в «прошивке». Любое программное обеспечение нуждается в установке патчей, а аппаратное обеспечение при необходимости заменяется или модернизируется. Независимо от того, что мы обновляем (программное или аппаратное обеспечение), необходимо следовать определенному процессу, который обеспечивает безопасное внесение изменений в среду.
Шаг 2: Изучение
Нередко случается, что на систему устанавливается неправильный патч. Администратор, в спешке пытаясь остановить атаки скрипт-кидди на уязвимый сервер, не читая последнюю часть имени патча, загружает патч от другой версии программного обеспечения и устанавливает его ... полностью выводя из строя приложение. Или, что еще хуже, администратор находит патч не на официальном сайте производителя, загружает его, и, не позаботившись о проверке аутентичности и целостности файла, устанавливает. Это прекрасный способ установить в систему троян или другую вредоносную программу.
Единственный способ предотвратить такие нежелательные происшествия – сначала изучить патч, убедиться, что источник его загрузки является подлинным, а файлы патча не повреждены, выполнив проверку целостности. Многие файлы публикуются вместе с цифровым отпечатком или цифровой подписью, созданной с помощью алгоритма хэширования, например, MD5 или SHA1. Такие подписи позволяют проверить целостность файлов путем перерасчета значения хэша и сравнения результатов.
Шаг 3: Тестирование
Перед установкой патча на системы, находящиеся в промышленной эксплуатации, важно проверить отсутствие любых неожиданных последствий, к которым может привести это. Такое тестирование лучше всего проводить в тестовой среде, которая как можно точнее отражает промышленную среду. Для проведения тестирования должен разрабатываться план тестирования, который работает как сценарий, предусматривающий последовательный проход по всем известным функциям и процедурам системы. План тестирования должен предуматривать выполнение действий, имитирующих стандартную работу в системе, работающей в промышленной среде. Кроме того, любой процесс управления патчами должен вписываться в Процесс управления изменениями, работающий в компании. Установка патчей, безусловно, измененяет промышленную среду, а Процесс управления изменениями осуществляет контроль за такими изменениями, снижая вероятность возникновения неожиданных проблем, и предусматривая стратегию «отката» на случай, если проблемы все же возникнут.
Шаг 4: Подготовка плана "отката"
Даже если вы внимательно изучили и протестировали патч, установили его в соответствии с практикой управления изменениями, вы все равно можете сталкнуться с проблемами, вызванными установкой этого патча. Единственным выходом из такой ситуации, позволяющим сохранить функционирование промышленных систем, является «откат» изменений, позволяющий отменить все произведенные при установке патча изменения и вернуть промышленную среду в состояние, в котором она находилась до установки патча. Лучшим способом минимизации последствий подобных проблем является предварительная подготовка к их возможному возникновению. Для этого целесообразно разработать план «отката», который будет описывать все шаги, необходимые для возврата системы (среды) в рабочее состояние, как перед установкой патча.
Шаг 5: Установка патча
Когда вы будете готовы к установке патча на системы, находящиеся в промышленной эксплуатации, лучшее, что вы можете сделать, это сразу установить его на самую критичную систему… не так ли? Конечно, нет! Большинство компаний по возможности применяют поэтапный подход к развертыванию патчей, начиная с экспериментальной группы, состоящей из наименее важных систем. По прошествии определенного периода времени, если на этих системах не возникло никаких проблем, патч применяется к следующей группе, состоящей из более критичных систем. И только в самом конце патч устанавливается на самые критичные системы. Часто при реализации стратегии развертывания патчей, особенно когда речь идет о большом количестве систем, применяются автоматизированные скрипты или инструменты для такого развертывания. Они помогают минимизировать вероятность возникновения проблем, связанных с человеческими ошибками, последовательно выполняя на каждой системе заранее определенную последовательность действий. Наилучшим подходом к развертыванию патчей является выполнение установки патчей по расписанию в пределах заранее определенного временного окна. Это временное окно должно выбираться таким образом, чтобы оно не пересекалось со временем пиковой нагрузки на системы, но совпадало с рабочим временем сотрудников, выполняющих установку патчей, и сотрудников, осуществляющих техническую поддержку систем, на которые они устанавливаются.
Шаг 6: Журналирование, Провека и Подготовка отчета
В заключение, нужно предусмотреть ту или иную форму журналирования событий, чтобы можно было отслеживать действия, выполнявшиеся в промышленной среде, а также собственно факты установки патчей, с указанием какие патчи, когда и где устанавливались. Вся эта информация должна записываться в журналы регистрации событий, должны быть разработаны необходимые для этого документы и стандарты, а конфигурации должны обновляться с учетом новых патчей. Для завершения процесса развертывания патча необходимо получить подтверждение, что на все системы, предназначенные для установки патча, патч действительно установлен. Соответсвующую проверку можно провести вручную, обойдя все системы, либо с помощью специализированного инструмента, выполняющего автоматическое сканирование систем. Такие инструменты могут работать с использованием агентов, локально устанавливаемых на все проверяемые системы, либо они могут удаленно обращаться к этим системам, чтобы узнать, установлен ли на них патч. После успешного завершения этой проверки и сбора всех необходимых данных, должен быть подготовлен отчет, который может потребоваться в дальнейшем (например, при проведении аудиторской проверки).
Наличие в вашей компании зрелого процесса установки патчей, вклющего в себя все шесть этапов, описанных выше, не гарантирует успеха. Проблемы при управлении патчами могут быть вызваны неисправностями в системах или инфраструктуре, участвующей в процессе установки патчей, или недостатками методов установки патчей. Часто сам процесс установки патча просто занимает больше времени, чем планировалось, и выходит за пределы окна времени установки патчей, в результате чего на некоторые системы патч не устанавливается и они остаются уязвимыми. Что еще хуже, обновленные системы могут оказаться несовместимыми с системами, на которые патч не был установлен, а другие системы могут полностью или частично выйти из строя после установки патча. Зачастую превышение запланированного времени установки патчей происходит из-за избыточной нагрузки на сеть, обладающую недостаточной пропускной способностью, необходимой для доставки файлов с патчами.
Хорошая практика управления патчами включает в себя определение наиболее правильного решения для конкретной компании и ее среды. Это может быть достаточно сложной задачей. Любая компания может купить самые современные средства управления патчами, но найти нужный инструмент, лучше всего подходящий именно вашей компании, и максимально эффективно использовать его – вот то, что часто вызывает проблемы.
Некоторые производители предлагают собственные подходы к организации процессов управления изменениями и контроля изменений. Многие публикуют документы, в которых рассказывают о методологии управления изменениями, тогда как другие просто выпускают патчи в соответствии с предсказуемым графиком, а также конкретные процедуры для развертывания этих патчей.
Насколько бы вы не были уверены в эффективности вашего процесса управления патчами и плана «отката», вы всегда должны предусматривать выполнение резервного копирования систем и данных до установки патчей. Это не значит, что вы должны выполнять резервное копирование только тогда, когда собираетесь устанавливать патчи. Конечно, нет! Резервное копирование должно быть частью ежедневных процедур эксплуатации и администрирования системам компании. Тем не менее, перед установкой патчей лучше сделать внеплановую резервную копию, чтобы иметь актуальную копию на случай возникновления проблем, что существенно упростит и ускорит процесс восстановления систем.
Кроме того, хорошей практикой является поддержка в актуальном состоянии перечня всего программного и аппаратного обеспечения, используемого в компании, а также конфигурационной информации, дистрибутивов и инструкций для него. Это сложнее, чем может показаться. Поддержка библиотеки, забитой инсталляционными компакт-дисками, всевозможными накопителями, документацией и файлами обновлений, может потребовать большого объема работы, не говоря уже о месте для хранения всего этого. Однако такая библиотека имеет огромное значение, и преимущества от ее наличия почти всегда покрывают издержки на ее поддержку.
Чтобы снизить риски компрометации систем, независимо от того, установлены на них актуальные патчи или нет, вокруг этих систем должны быть установлены компенсирующие защитные механизмы, которые позволят снизить риски эксплуатации уязвимостей системы. Для этих целей выполняется укрепление серверов, при котором блокируются ненужные сервисы, максимально ограничивается доступ, предоставляется минимум привилегий, необходимых пользователям и/или процессам. Помимо этого, системы могут быть защищены межсетевыми экранами и другими средствами обеспечения безопасности сетевого узла, которые ограничивают возможное влияние на систему различных атак, связанных с попытками эксплуатации ее уязвимостей. При этом никакие из перечисленных защитных мер не исключают необходимость выполнения процессов управления патчами, однако они повышают их эффективность и дают компании больше времени на установку патчей.
В этом разделе рассказывается, как недостатки (уязвимости) программного обеспечения и ошибки используются различными методиками проникновения в системы и/или сети. Такие недостатки могут находиться в приложениях, операционной системе, протоколах и сетевом стеке.
Сетевой стек является частью операционной системы, он позволяет устройствам обмениваться информацией по сети. Он позволяет создавать сетевые пакеты и отправлять их по проводам, а также принимать сетевые пакеты и обрабатывать их. Различные операционные системы и производители по-разному интерпретируют RFC (Request for Comments) сетевых протоколов, что приводит к несколько различающимся реализациям сетевых стеков в разных системах. Такие особенности могут иметь собственные недостатки, которыми могут воспользоваться хакеры для проведения атаки «отказ в обслуживании» (DoS – Denial-of-Service). Такие атаки осуществляются путем направления системе неправильно сформированных пакетов, при этом система не понимает их формата и не знает, как их обрабатывать. Это может привести к нарушению работы системы или прекращению обработки других сетевых пакетов (отказ в обслуживании).
DoS-атаки ежегодно приводят к многомиллионым убыткам компаний, вызванных простоем их систем, потерей доходов и производительности работы, ущербом репутации компании, а дополнительными затратами человеческих и финансовых ресурсов для выявления возникших проблем и их исправления. DoS-атаки могут привести к отключению отдельных сервисов, либо к полной потере возможности принимать запросы реальных пользователей на доступ к необходимым им ресурсам системы.
DoS-атаки могут заполнить всю ширину полосы пропускания сети жертвы. Для этого у злоумышленника должен быть канал с большей пропускной способностью, либо требуется совместная работа нескольких атакующих, вместе заполняющих каналы связи жертвы. Если атака выполняется с нескольких различных систем, каждая из них усиливает суммарный эффект, что позволяет подавить сегмент сети жертвы.
Другой вид DoS-атаки использует все ресурсы системы жертвы вместо пропускной способности сети. Такими ресурсами может быть процессорное время, свободное место на диске, оперативная память. В следующих разделах рассматриваются некоторые из возможных вариантов DoS-атак.
Протокол ICMP представляет собой мини IP-мессенджер, он используется для выяснения функционирования систем с помощью утилиты Ping. ICMP сообщает о текущем статусе и ошибках. Когда пользователь пингует другой компьютер с помощью утилиты Ping, фактически он посылает ему сообщение ICMP ECHO REQUEST. При этом, если этот компьютер включен и работает, он отвечает ему сообщением ECHO REPLY. Это представляет из себя примерно такой диалог: «Привет, компьютер 10.10.10.1! Ты включен и работаешь?», на что этот компьютер отвечает «да».
Smurf-атака требует участия трех игроков: атакующего, жертвы и усиливающей сети. Атакующий изменяет исходящий IP-адрес в заголовке пакета ICMP ECHO REQUEST, указывая в нем IP-адрес системы жертвы (это называется спуфингом). Измененный пакет ICMP ECHO REQUEST в виде широковещательного запроса передается в усиливающую сеть, которая направляет в ответ множество сообщений системе жертвы (т.к. в заголовке указан ее адрес и системы в усиливающей сети думают, что запрос пришел от нее). Такой мощный поток сообщений может перегрузить систему жертвы.
Функция ECHO в протоколе ICMP предназначена лишь для того, чтобы определить, работает ли определенный компьютер и принимает ли он запросы. Однако отсутствие в этом протоколе необхоимых мер безопасности позволяет злоумышленникам использовать его для проведения атак.
Контрмеры
- Отключите функции прямой широковещательной рассылки на пограничных маршрутизаторах, чтобы не позволить использовать расположенные за ними сети в качестве усиливающих сетей.
- Настройте правила на маршрутизаторах периметра таким образом, чтобы они отклоняли любые входящие пакеты, в которых в качестве IP-адреса источника указан внутренний IP-адрес сети компании. Это поддельные пакеты, измененные с помощью спуфинга.
- Разрешите только необходимые пакеты ICMP на входе и выходе из сети.
- Используйте IDS уровня сети для выявления подозрительной активности.
- Некоторые системы более чувствительны к определенным видам DoS-атак, но для большинства из них уже были выпущены патчи. Эти патчи должны быть установлены.
Fraggle – это атака, подобная Smurf, но вместо ICMP она использует протокол UDP. Злоумышленник передает подделанный пакет UDP в усиливающую сеть, которая, в свою очередь, направляет свои ответы на систему жертвы. Чем больше усиливающая сеть, тем больший объем трафика направляется на систему жертвы.
Для различных пакетов ICMP и UDP должны быть установлены ограничения по их пропуску во внутреннюю сеть. На это есть масса причин. Злоумышленники часто используют эти протоколы, чтобы узнать о топологии сети, найти в ней маршрутизаторы, узнать о типах используемых в сети систем. Поскольку мы хотим ограничить объем доступной для злоумышленников информации, на маршрутизаторах периметра сети должны быть выполнены указанные ниже настройки.
Контрмеры
- Отключите функции прямой широковещательной рассылки на маршрутизаторах периметра, чтобы не позволить использовать расположенные за ними сети в качестве усиливающих сетей.
- Настройте правила на маршрутизаторах периметра таким образом, чтобы они отклоняли любые входящие пакеты, в которых в качестве IP-адреса источника указан внутренний IP-адрес сети компании. Это поддельные пакеты, измененные с помощью спуфинга.
- Разрешите только необходимые пакеты UDP на входе и выходе из сети.
- Используйте IDS уровня сети для выявления подозрительной активности.
- Некоторые системы более чувствительны к определенным видам DoS-атак, но для большинства из них уже были выпущены патчи. Эти патчи должны быть установлены.
Поскольку TCP является протоколом с предварительным установлением соединения, он должен создавать виртуальное соединение между двумя компьютерами. Это виртуальное соединение используется как при «рукопожатии», так и при непосредственном использовании протокола TCP. Для этого требуется трехсторонний процесс. Если компьютеру Comp1 нужно взаимодействовать с компьютером Comp2, Comp1 направляет пакет синхронизации (SYN) на определенный порт Comp2, находящийся в состоянии LISTEN (прослушивание, ожидание приема входящих соединений). Если Comp2 включен, работает и принимает вызовы, он ответит Comp1 пакетом подтверждения SYN/ACK. После получения этого пакета, Comp1 отправит Comp2 пакет ACK, после чего соединение будет установлено.
Системы и их сетевые стеки готовы одновременно обслуживать только определенное ограниченное количество таких соединений, для чего они выделяют определенный объем ресурсов, необходимый для выполнения такого рода функций. Если система получает слишком большое количество запросов на подключение (пакетов SYN), системе становится недостаточно ресурсов для обработки новых запросов на подключение.
Злоумышленники могут воспользоваться этим недостатком, постоянно отправляя жертве сообщения SYN с использованием поддельных пакетов. Компьютер жертвы будет выделять для каждого из них необходимый для установления соединения объем ресурсов, направлять свои ответы о готовности к установлению соединений в пакетах SYN/ACK и ожидая получить пакеты ACK в ответ. Однако жертва так и не получит сообщений ACK, т.к. пакеты поддельные и система жертвы направляет свои пакеты SYN/ACK на несуществующий компьютер. Таким образом, система жертвы послушно выделяет необходимые ресурсы, получая пакеты SYN, означающие, что другая система хочет установить с ней соединение. Новое соединение ставится в очередь, ожидая получения пакета ACK, но вместо него злоумышленник направляет ей следующий пакет SYN. При этом система жертвы выделяет все больше и больше ресурсов, что в конечном итоге приводит к их недостатку для открытия следующего соединения. Для этого злоумышленнику нужно будет отправить десятки или сотни запросов SYN, прежде чем система жертвы перестанет реагировать на новые запросы. Это делает компьютер жертвы недоступным для подключения реальных пользователей, он отказывает им в обслуживании.
Производители различных систем выпустили патчи, которые увеличивают очередь соединений и/или уменьшают период времени ожидания установления соединения, что позволяет системе оперативно очищать свою очередь несостоявшихся подключений.
Контрмеры
- Уменьшите период времени ожидания установления соединений (это снижает воздействие от такой атаки).
- Увеличьте размер очереди соединений в стеке IP.
- Установите соответствующие патчи от производителя, на системах, в отношении которых возможно проведение такой атаки.
- Используйте IDS уровня сети, который будет отслеживать такие действия и предупреждать ответственных лиц в случае выявления атаки.
- Установите межсетевой экран, для контроя такого вида атак, оповещения о них администратора или сброса таких соединения.
При прохождении пакетов через различные сети, может потребоваться выполнение их фрагментации и пересборки в зависимости от сетевой технологии, используемой каждой конкретной сетью. Каждая сетевая технология имеет свое значение максимального размера передаваемого блока (MTU – maximum transmission unit), который указывает на максимальный размер пакета, который может быть в ней обработан. Некоторые системы проверяют, что пакеты не превышают этот размер, но не проверяют, что пакеты слишком малы. Система жертвы получает фрагменты пакетов и пытаться собрать из них целые пакеты, но эти фрагменты сделаны злоумышленником таким образом, что они не могут быть правильно собраны. Многие системы не знают, как бороться с такой ситуацией. Злоумышленники могут воспользоваться этим недостатком системы и отправить ей очень маленькие пакеты, что может вызвать приостановку работы системы или ее перезагрузку. Эти недостатки используются при проведении атаки Teardrop.
Контрмеры
- Установите необходимый патч или обновите операционную систему.
- Запретите вход в сеть неправильно сформированных фрагментов пакетов.
- Используйте маршрутизатор, который собирает все фрагменты в полный пакет перед тем, как отправить его системе получателя.
Распределенная атака отказ в обслуживании (DDoS – Distributed Denial-of-Service) является логическим продолжением DoS-атаки, которая в процессе проведения атаки использует больше компьютеров. Обычная DoS-атака подавляет компьютеры с помощью только одного атакующего компьютера, отправляя жертве «плохие» пакеты или постоянно отправляя запросы на подключение, пока ресурсы системы жертвы не закончатся и она не сможет отвечать на другие запросы. При проведении DDoS-атаки злоумышленник использует сотни или тысячи компьютеров, которые посылают запросы на обслуживание серверу (или ферме серверов), пока он не перестанет функционировать.
В процессе такой атаки могут использоваться компьютеры и тех, кто сознательно участвует в атаке, но чаще всего для этого используются зомби-компьютеры, владельцы которых даже не подозревают, что они участвуют в атаке. Злоумышленник создает Управляющие серверы (master controller), которые управляют зомби-компьютерами, входящими в ботсеть злоумышленника. Управляющие серверы – это системы, на которые у злоумышленника есть административные права доступа, которые он использует для установки на них специального программного обеспечения. Это программное обеспечение позволяет злоумышленнику удобно управлять всем множеством зомби-компьютров ботсети, оно ожидает инструкций злоумышленника, чтобы дать соответствующие команды зомби-компьютерам. Зомби-компьютеры занимают третий уровень в этой иерархии. На них установлено программное обеспечение бота, которое ожидает команд от управляющих серверов и исполняет их при получении. Когда атакующему требуется выполнить какое-либо действие с помощью своей ботсети, например, провести DDoS-атаку на веб-сайт, он передает его адрес управляющим серверам, а те дают соответствующую команду всем зомби-компьютерам ботсети, которые начинают все вместе одновременно атаковать указанный злоумышленником веб-сайт. Пример такой атаки показан на Рисунке 9-21.
Рисунок 9-21. Для проведения DDoS-атаки, злоумышленник использует управляющие серверы, чтобы передать команду зомби-компьютерам начать одновременно направлять запросы системе жертвы
Контрмеры
- Используйте маршрутизаторы периметра, чтобы ограничить ненужный трафик по протоколам UDP и ICMP.
- Используйте IDS уровня сети для мониторинга такого вида подозрительной деятельности.
- Отключите неиспользуемые подсистемы и сервисы на компьютерах.
- Переименуйте учетную запись администратора и организуйте строгое управление паролями, чтобы вашими системами не могли воспользоваться неизвестные.
- Настройте правила маршрутизаторов периметра таким образом, чтобы они отклоняли любые входящие сообщения с пакетами, содержащими IP-адреса внутренней сети в качестве адреса отправителя. Это поддельные пакеты.
Хотя при разработке программного обеспечения функциональность имеет первостепенное значение, было бы весьма полезным добавить безопасность в эту смесь еще до начала проекта и интегрировать ее в каждый этап процесса разработки. Многие компании пока не считают этот подход к разработке программного обеспечения выгодным, однако они меняют свое мнение при возникновении необходимости в разработке все большего количества патчей и исправлений, устраняющих проблемы безопасности в уже работающем у их покупателей программном обеспечении. У покупателей начинает появляться спрос на более безопасные продукты.
Разработка программного обеспечения представляет собой сложную задачу, особенно учитывая стремительное развитие технологий, измененяющихся со скоростью света, эволюционирующих сред, и возрастающих ожиданий производителей, каждый из которых хочет быть «царем горы» в рамках своего сегмента рынка программного обеспечения. Все это также усложняет внедрение в программные продукты эффективной безопасности. На протяжении многих лет, программистам и разработчикам не нужно было учитывать вопросы безопасности в своем коде, но эта тенденция меняется. Образование, опыт, осведомленность, требования, а также запросы потребителей – все это является необходимыми частями для применения более безопасных подходов и технологий в программном коде, которым мы все пользуемся.
Комментариев нет:
Отправить комментарий