что считается ошибками при неправильном администрировании системы
IT: четыре недопустимых ошибки администратора
Пренебрежение администратора базы данных к некоторым рутинным задачам может повлечь за собой неприятности. В ряде случаев халатность оборачивается серьезными финансовыми потерями. А бывает, ненадлежащее выполнение повседневных обязанностей грозит потерей рабочего места.
Работа по выявлению и устранению неполадок отнимает у администратора баз данных массу времени. И пользователи, и разработчики совершают ошибки, доставляющие немало хлопот. Но несмотря на все эти отвлекающие факторы, как администратор базы данных, вы не можете снять с себя ответственность за выполнение важнейших повседневных процедур, которые позволяют обеспечивать защиту корпоративных данных и бесперебойное функционирование экземпляров SQL Server. Давайте подробнее рассмотрим четыре наиболее серьезных ошибки администратора баз данных. Итак, чего нельзя делать ни в коем случае:
1. Забывать о тестировании резервных копий. Все мы знаем, насколько важно выполнять резервное копирование баз данных. Даже при использовании самых современных технологий обеспечения высокой доступности и восстановления данных после аварийного сбоя резервные копии остаются основой стратегии защиты данных. Резервные копии баз данных — это наша последняя линия обороны. Представьте, что вы пытаетесь восстановить содержимое баз данных, а резервные копии не работают. Трудно вообразить ситуацию более катастрофическую. Чтобы гарантированно избежать такого положения, пользуйтесь командой BACKUP VERIFVONLY, и вы сможете убедиться, что интересующая вас резервная копия может быть восстановлена. В дополнение к проверке резервных копий полезно применять ко всем резервным и восстановленным копиям функцию CHECKSUM. Она выполняет дополнительные проверки и дает ответ на вопрос, повреждена ли та или иная база данных. Наконец, полезно регулярно выполнять операции по восстановлению баз данных на незащищенных системах. Так вы сможете убедиться в том, что ваши резервные копии функционируют нормально.
2. Не принимать меры по ограничению доступа в целях обеспечения безопасности. Безопасность — критический фактор всех систем
SQL Server уровня предприятия. Однако некоторые профессионалы
в области баз данных не уделяют этой стороне дела должного внимания. Результатом предоставления сотрудникам или приложениям более широких, чем положено, прав доступа, может стать потеря данных, брешь в защите или даже непреднамеренное повреждение базы данных. Часто встречается такая ошибка: разработчикам предоставляются привилегии администраторов, а также прямой доступ к данным, касающимся производства. Нередко такие решения обосновываются удобством разработки или необходимостью отладки, однако подобную практику нельзя считать приемлемой. Безопасность баз данных следует обеспечивать по принципу наименьших привилегий, в соответствии с которым пользователям, разработчикам и даже администраторам предоставляются разрешения самого низкого уровня.
3. Пренебрегать плановыми мероприятиями по обслуживанию баз данных. Система SQL Server обладает широкими возможностями автоматической настройки и множеством средств самовосстановления, однако не следует думать, что база данных будет выполняться сама по себе. Существует целый ряд важных мер по обслуживанию баз данных, которые администратор должен использовать регулярно. Во-первых, все имеющие отношение к производству базы данных необходимо подвергать проверкам на целостность с помощью команды DBCC CHECKDB. Во-вторых, следует регулярно проверять индексы на фрагментацию, а также обновлять статистику производственных баз данных. Эти процессы можно автоматизировать, например с помощью агента SQL или плана обслуживания, предусматривающего выполнение перечисленных действий. Кроме того, существует несколько сценариев и инструментов независимых поставщиков, способствующих эффективной работе баз данных. Разумеется, вам необходимо следить за тем, чтобы эти отличающиеся активным потреблением ресурсов средства не применялись в рабочие часы с пиковыми нагрузками.
4. Откладывать мониторинг использования сервера. Еще одна категория жизненно важных мероприятий, которые следует проводить регулярно, включает мониторинг систем и контрольное тестирование. Если администратор этого не делает, склонен выжидать и начинает отслеживать уровни функционирования базы данных, а также рабочие нагрузки лишь после того, как в системе возникают проблемы, он допускает грубую ошибку. Периодически проверяя статистику быстродействия системы, вы сможете получить представление о нормальной нагрузке и сформировать шаблоны, которые позднее помогут вам отмечать изменения и отклонения от нормы. Необходимо регулярно проверять данные об использовании процессоров, памяти, подсистемы ввода-вывода, блокировок, а также такие показатели, как объем свободного дискового пространства, выделяемого для данных и файлов регистрации.
Что считается ошибками при неправильном администрировании системы
Вам знакомо выражение: «Не чини, коли не поломано»? Если да, то вы знаете, что иногда лучше не вмешиваться в сложившуюся ситуацию. Но ни один настоящий сисадмин не в состоянии спокойно смотреть на новые «примочки» и удержаться от того, чтобы не «потыкать» их и попробовать применить на практике. Именно так мы вышли на тот уровень, где сейчас находимся, и теперь планируем перебраться на еще более высокий уровень. Однако тыкать острой палкой в незнакомый предмет — не всегда безопасное занятие.
Мы составили список из 21 распространенной ошибки, которая не раз даст о себе знать. Наш совет: пробуя что-то новое, не забывайте думать о последствиях! Они могут быть самыми разными.
1. Анонимный доступ и FTP
Каждый, кто хоть раз создавал веб-сайт с использованием FTP, разрешал анонимный доступ и выкладывал свой сайт в Интернет, получил несколько уроков. Если вы разрешаете анонимный доступ, будьте готовы к тому, что очень скоро ваш сайт превратится в хостинг для пиратских программ и фильмов. Никогда не разрешайте анонимный доступ, даже во внутренней сети. В противном случае, у вас быстро закончится пространство на диске и трафик.
2. «Всем — полный контроль»
Вплоть до последних версий Windows, каждый раз как вы создавали общую папку, по умолчанию в ее настройках была активирована опция «Всем — полный контроль». Многие из этих устаревших систем используются и по сей день. Хуже того, многие сисадмины до сих пор оставляют эту опцию включенной по умолчанию в современных операционных системах, полагая, что дать всем возможность полностью контролировать каталог — это правильно! Рекомендуем вам перестать раздавать подобные привилегии направо и налево!
3. «Ответить всем»
Да, иногда действительно бывает необходимо отправить письмо сразу всем пользователям из корпоративной группы. Но оставить эту кнопку, чтобы любой пользователь мог воспользоваться ею,- самый простой способ загрузить по максимуму вашу электронную почту и испытать ее на прочность. Кто-нибудь непременно случайно нажмет ее, и через минуту 30 человек будут одновременно отписываться от коллективного диалога, или просить всех перестать отвечать всем, или же, наоборот, вставлять свои пять копеек в беседу. Мне приходилось видеть, как серверы специально отключали, чтобы только прекратить это безумие. Ограничьте возможности использования функции «Ответить всем» и сделайте так, чтобы только авторизованные пользователи могли отправлять письма самым большим группам пользователей в вашей электронной почте.
4. Опция «Завершение работы» в удаленном доступе
Однажды мне пришлось совершить внеплановую поездку в другой город из-за того, что во время удаленного управления сервером я случайно нажал кнопку «Завершение работы» вместо кнопки «Выход из системы». Сейчас опция «Завершение работы» убирается из меню по умолчанию, но в миллионах серверов 2003 и 2008 годов выпуска она все еще есть. Уберите кнопку «Завершение работы» из меню удаленного доступа. Если вы действительно захотите выключить сервер, лучше воспользоваться командной строкой. Ну а если внеплановые визиты в центр обработки данных вам по душе, так уж и быть, можете ее оставить.
5. Хранение незашифрованных паролей на веб-страницах
Веб-мастера слишком часто хранят параметры соединения для базы данных в коде сценариев веб-сайтов в незашифрованном виде. При этом кто угодно может пробраться в систему, чтобы «ознакомиться с источником данных». Никогда не сохраняйте пароли в файлах, доступ к которым есть у конечных пользователей. Если же вам все-таки нужно где-то хранить эту информацию, пользуйтесь шифрованием.
6. Игнорирование проверок входных данных
Переполнение буфера, инъекция SQL, изменение цен в корзине онлайн-магазина — все это возможно, если не предусмотреть проверку входных данных в вашем программном обеспечении и на вашем веб-сайте. Всегда повторно проверяйте то, какие данные вам приходят от пользователей и отклоняйте все, что не проходит проверку, до того, как изменения (и их последствия) станут необратимыми.
7. Использование незашифрованных протоколов
Помимо запросов на DNS-серверы, скачивания общедоступных файлов и создания веб-страниц для широкого круга посетителей, нет никакого практического смысла в использовании незашифрованных протоколов. Но если вы выполняете какую-либо аутентификацию или предоставляете доступ к конфиденциальным данным, использовать криптографическую защиту просто обязательно. При этом дополнительно изучите, какие из протоколов на данный момент считаются наиболее защищенными и почему.
8. Отсутствие переадресации с незашифрованного протокола на зашифрованный
Справедливости ради, уточним: мы не предлагаем вам отключить незашифрованные протоколы как таковые. Слишком многие пользователи будут печатать адрес без протокола, и без переадресации с HTTP на HTTPS они не смогут попасть на ваш веб-сайт. Используйте HTTP и настройте переадресацию с него. При этом данные пользователей будут защищены, и у них не возникнет проблем с посещением вашего веб-сайта.
9. Проверка SSL-сертификатов
Каждый раз, как вы учите пользователя просто «прощелкивать» предупреждения, не читая их, вы делаете его потенциальной жертвой киберпреступников в будущем. Чаще всего подобное происходит на внутренних веб-сайтах, которые используют протокол HTTPS с SSL-сертификатом. Пользователи, не задумываясь, кликают там, где не следует. Конечные пользователи не могут отличить внутренний сайт от внешнего. Они просто увидят знакомый формат предупреждения и кликнут «ОК» — как вы им и говорили, когда учили пользоваться внутренним приложением. Создайте корпоративный CA или приобретите сертификат wildcard, но не учите пользователей бездумно кликать «ОК» на предупреждениях.
Промежуточные сборки приложений созданы для демонстрации того, как они работают на данный момент. Они часто не соответствуют должному уровню безопасности и надежности и, как правило, не обновляются при установке патчей на приложение. При создании или запуске сервера удалите все предыдущие образцы кода и приложений, чтобы в будущем их не могли использовать против вас.
11. Установка обновлений и патчей без тестирования
Если вы используете исключительно «ванильный код» от разработчика, установка обновлений и патчей без тестирования может обернуться проблемой. Разработчик не имеет возможности тестировать каждую отдельно взятую конфигурацию. Это означает, что и вашу конфигурацию он не тестировал. Это ваша задача, а не его. Вы хотите установить обновление? Устанавливайте, но только сначала убедитесь, что это не создаст других проблем в вашей системе.
Обычно, при обновлении большого парка компьютеров, перед распределением обновления по всем системам выбирается контрольная группа из нескольких машин, на которых проверяется работоспособность устанавливаемых патчей. В случае, если на них обновление пройдет без проблем — можно распространять его на всю сеть.
12. Автоматические IP (169.254.y.z) в DNS
Если у сервера есть два IP-адреса в DNS, он будет отвечать на запросы с обоих из них. Если один из этих адресов — фальшивка, то с вероятностью 50 на 50 клиент попадет на него, а не на настоящий адрес. Это сделает работу медленной, и, соответственно, клиент будет звонить в вашу техническую поддержку. Как минимум, снимите галочку с опции «регистрация соединения в DNS», чтобы фальшивые адреса не присваивались настоящим именам хоста.
13. Ссылки на DNS в ActiveDirectory
В AD контроллерам домена никогда не следует давать на себя ссылку в DNS; необходимо указывать ссылку на другой контроллер домена. Если контроллер домена делает ссылку на себя, он может потерять синхронизацию с другими, и вы даже не заметите этого. Он быстро устареет и не сможет проводить идентификацию пользователей.
Если он слишком долго будет не синхронизирован (60 дней по умолчанию), вам придется снести его и установить заново для устранения проблемы. Всегда проверяйте, что контроллер домена привязан к другому контроллеру домена в DNS, а не к самому себе. В противном случае вам придется использовать NTDSUTIL для очистки AD от вредоносных данных.
14. Недостаточный аудит
Регистрация системных событий — очень важный процесс, но его редко выполняют правильно. Стандартных настроек аудита, как правило, недостаточно для полноценного восстановления хода событий и выяснения причины возникновения проблемы. Кроме того, журналы событий занимают много пространства на диске, и могут пройти дни или даже недели, прежде чем кто-либо вообще поймет, что что-то случилось и надо проверить журналы регистрации. Убедитесь, что вы регистрируете достаточно информации для восстановления хода событий, и что регистрационные записи хранятся достаточно долго, чтобы вы могли с их помощью провести полноценное расследование любого сбоя.
15. Отсутствие централизованного журнала регистрации
По умолчанию, система использует для ведения журналов регистрации локальные диски. Это нормально — до тех пор, пока система не рухнет или не будет взломана хакером, который сотрет журналы регистрации. Ведение централизованного журнала регистрации требует больше времени, денег и пространства. Но при этом у вас точно будет журнал событий в случае краха системы, а злоумышленнику будет сложнее замаскировать следы своей деятельности.
GFI рекомендует использовать GFI EventsManager — решение для централизованного сбора и анализа журналов событий в сети. Продукт можно загрузить и использовать до 30 дней бесплатно с полным функционалом — этого достаточно, чтобы проанализировать гигабайты журналов данных и выявить проблемы в сети.
16. Разрешение на чтение
Многие дистрибутивы Linux позволяют пользователям получать доступ к домашним каталогам откуда угодно. Как правило, это не подразумевает «весь Интернет», но означает, что любой пользователь в сети может читать файлы из домашнего каталога, а в нем могут быть и файлы с паролями, и конфигурационные файлы, и масса другой ценной информации. Убедитесь в том, что для уровня доступа для каждого домашнего каталога пользователя установлено значение 600, так что пользователи могут читать и писать файлы только в домашних каталогах, но не могут выполнять программы из них. Если нужно разрешить выполнение программ, установите значение 700.
17. Использование изначальной установки строк сообщества на значения «public» и «private» в протоколе SNMP
В протоколе SNMP v1 и v2 безопасность обеспечивается только строкой сообщества, а по умолчанию в строке сообщества для записи указано значение «private». При этом злоумышленнику, получившему доступ к сети, ничего не стоит обрушить роутер или поменять местами порты. Передача данных в протоколе SNMP v1 и v2 осуществляется в незашифрованном виде, но если изменить значение по умолчанию в строке сообщества, то это хоть немного усложнит для хакера задачу создания проблем в вашей сети. Если возможно, используйте протокол SNMP v3 или же не используйте SNMP для записи вообще.
18. Игнорирование протокола ICMP
Документы RFC предусматривают, что хосты ОБЯЗАНЫ отвечать на запросы ICMP Echo, так что сисадмины, игнорирующие протокол ICMP, нарушают их требования, что не есть хорошо. Кроме того, поскольку сетевые атаки типа Ping of death не актуальны уже 15 лет, игнорирование протокола ICMP приведет только к тому, что пользователям будет сложнее исправить ситуацию при неудачной попытке доступа на ваш сайт, и они будут перегружать вашу службу поддержки звонками и сообщениями о невозможности воспользоваться VPN. По меньшей мере, разрешите пинговать ваш сайт и конечные точки VPN (в большинстве случаев проверка сводится именно к этому).
19. Удаление (вместо блокирования) чего-либо во внутренней сети
Если вы блокируете нежелательный трафик во внутренней сети, то хорошие сисадмины увидят RST ACK или ICMP Unreachable и будут знать, что брандмауэр блокирует нечто целенаправленно. Если же вы просто молча удалите что-то во внутренней сети, ваши коллеги могут потратить дни на попытки понять, почему что-то не работает, как раньше, начнут обвинять брандмауэр во всех возможных бедах и, в лучшем случае, будут звонить вам при любой поломке. (В худшем случае, они будут по умолчанию считать, что виноваты вы).
20. Включение опции автоматического обновления системы
Как и в случае с установкой обновлений без тестирования, разрешить автоматическое обновление системы — значит, позволить ей устанавливать на себя патчи без предварительной проверки и возможности проконтролировать процесс. Нет, серьезно, если вы позволяете серверам обновляться автоматически, то зачем вы им вообще нужны? Вы должны контролировать процесс управления обновлениями. Во-первых, вы сможете осуществлять тестирование, а во-вторых, вы сможете перезагружать серверы только в плановом порядке, когда вам это нужно.
Для управления обновлениями, а также проверки сети на наличие уязвимостей, GFI советует воспользоваться продуктом GFI LanGuard. Продукт можно использовать 30 дней бесплатно без ограничений по функциональности — проверьте свою сеть на «дыры» в безопасности и получите централизованный контроль над обновлениями и патчами.
21. Использование локальных аппаратных часов для синхронизации времени
Синхронизация времени очень важна. Журналы регистрации зависят от нее. Аутентификация зависит от нее. Ваши пользователи зависят от нее — а как иначе они узнают, что пора идти домой? Все сети должны использовать протокол NTP для синхронизации часов, а также использовать надежный внешний источник наподобие pool.ntp.org, чтобы убедиться, что часы не просто синхронизированы, но и показывают точное время.
Позаботьтесь об этих важных моментах, и ваша сеть будет в прекрасном состоянии и выдержит любые нагрузки.
ОШИБКИ В АДМИНИСТРИРОВАНИИ СИСТЕМЫ
Ошибки в администрировании системы сводят на нет самую хорошую модель безопасности и самое корректное ее внедрение. Самый простой пример — наличие пользователя с правами супервизора без пароля.
Наличие права на запись в системный каталог
Наличие возможности записи в один из каталогов, используемых в файле начальной загрузки (login script) приводит к тому, что злоумышленник может исправить одну из запускаемых программ (это могут быть различные драйверы, операционные оболочки и т.п.) так, чтобы она совершала некоторые несанкционированные действия (в частности, запоминала пароль, под которым пользователь вошел в систему). Здесь используется также тот факт, что Novell NetWare никоим образом не контролирует целостность своих системных компонент.
Например, способ с «обратным чтением пароля» (readback) использует тот факт, что все введенные с клавиатуры символы сохраняются некоторое время в буфере клавиатуры, и состоит в следующем.
Запускаемая программа меняется на другую, которая записывает на диск, в память, или тут же передает по сети буфер клавиатуры, который еще содержит только что набранный пароль, и затем запускает оригинальную программу.
Таким образом, в момент входа в систему в памяти нет никаких резидентных программ и программа login заведомо «чистая». Этот способ и называется «обратным чтением», т. к. удается получить уже вроде бы введенный и недоступный пароль.
Для уменьшения вероятности обнаружения этой «закладки» она может быть реализована не в виде отдельного файла, а дописана к нужной программе по вирусному принципу, т.к. ее размеры крайне невелики.
Наличие права на чтение SYS:SYSTEM
Наличие у пользователя права на чтение SYS:SYSTEM автоматически приводит к тому, что ему могут стать доступны копии файлов базы данных связок NET$*.OLD и он сможет прочитать оттуда хэш-значение пароля любого пользователя.
Вопросы 9-10.
МЕХАНИЗМЫ РЕАЛИЗАЦИИ ОСНОВНЫХ ТИПОВ УДАЛЕННЫХ АТАК
В настоящем пункте будут рассмотрены типовые удаленные атаки и предложены механизмы их реализации.
Анализ сетевого трафика.
Основной особенностью сетевой операционной системы является то, что ее компоненты распределены в пространстве, и связь между ними физически осуществляется при помощи сетевых соединений и программно — при помощи механизма сообщений. При этом, все управляющие сообщения и данные, пересылаемые одной компонентой сетевой ОС другой компоненте, передаются по сетевым соединениям в виде пакетов обмена. Эта особенность привела к появлению специфичного только для сетей ЭВМ (в общем случае для распределенных систем) типового удаленного воздействия, заключающегося в прослушивание канала в сети. Назовем данное воздействие — анализ сетевого трафика (или сокращенно, сетевой анализ).
Анализ сетевого трафика позволяет, во-первых, изучить логику работы сетевой ОС, то есть, получить взаимно однозначное соответствие событий, происходящих в ОС, и команд, пересылаемых друг другу ее компонентами, в момент появления этих событий. Это достигается путем перехвата и анализа пакетов обмена на канальном уровне. Знание логики работы сетевой ОС позволяет на практике моделировать и осуществлять типовые удаленные атаки.
Во-вторых, анализ сетевого трафика позволяет перехватить поток данных, которыми обмениваются компоненты сетевой ОС. То есть, удаленная атака данного типа заключается в получение на удаленном компьютере несанкционированного доступа к информации, которой обмениваются две сетевых ЭВМ. При этом, важно отметить, что при анализе сетевого трафика отсутствует возможность его модификации и сам анализ возможен только внутри одного сегмента сети. Примером перехваченной при помощи данной типовой атаки информации могут служить имя и пароль пользователя, пересылаемые в незашифрованном открытом виде по сети.
По характеру воздействия анализ сетевого трафика является пассивным воздействием. Осуществление данной атаки ведет к перехвату информации внутри одного сегмента сети на канальном уровне OSI. При этом начало осуществления атаки безусловно по отношению к цели атаки.
2. Навязывание хосту ложного маршрута.
Современные глобальные сети представляют собой совокупность сегментов сети, связанных между собой через сетевые узлы. При этом маршрутом называется последовательность узлов сети, по которой данные пересылаются от источника к приемнику, а маршрутизацией называется выбор маршрута. Узел, обеспечивающий маршрутизацию, называется маршрутизатором. Каждый маршрутизатор имеет специальную таблицу, называемую таблицей маршрутизации, в которой для каждого адресата указывается оптимальный маршрут. Отметим, что таблицы маршрутизации существуют не только у маршрутизаторов, но и у любых хостов в глобальной сети. Для обеспечения эффективной и оптимальной маршрутизации в сетях ЭВМ существуют специальные управляющие протоколы, позволяющие маршрутизаторам обмениваться информацией друг с другом (RIP (Routing Internet Protocol), OSPF (Open Shortest Path First)), уведомлять хосты о новом маршруте (ICMP (Internet Control Message Protocol)), удаленно управлять маршрутизаторами (SNMP (Simple Network Management Protocol)). Важно отметить, что все описанные выше протоколы позволяют изменять маршрутизацию в сети, то есть являются протоколами управления сетью.
Из всего вышесказанного очевидно, что маршрутизация в глобальных сетях играет важнейшую роль и, как следствие этого, может подвергаться атаке. Основная цель атаки, связанной с навязыванием хосту ложного маршрута, — изменить исходную доверенную маршрутизацию хоста, так, чтобы новый маршрут проходил через хост или сеть злоумышленника.
Реализация данной типовой атаки состоит в несанкционированном использовании протоколов управления сетью для изменения исходной маршрутизации. То есть, для изменения маршрутизации атакующему требуется послать по сети определенные данными протоколами управления сетью специальные служебные сообщения от имени сетевых управляющих устройств (например, маршрутизаторов).
В результате успешного изменения маршрута атакующий хост получит полный контроль над потоком информации, которой обмениваются два доверенных хоста и атака перейдет во вторую стадию, связанную с приемом, анализом и передачей пакетов, получаемых от обманутых хостов. Данная стадия атаки полностью совпадает со второй стадией типовой атаки ложный сервер.
Навязывание хосту ложного маршрута — активное воздействие, совершаемое с целью как перехвата, так и искажения информации безусловно, по отношению к цели атаки. Данная удаленная атака осуществляется внутри одного сегмента, на сетевом уровне модели OSI.
3. Подмена доверенного хоста.
Как подчеркивалось ранее, основной проблемой в безопасности сетевой ОС является недостаточная идентификация и аутентификация ее удаленных компонент. То есть, проблема заключается в однозначной идентификации получаемых станцией пакетов обмена. Обычно в сетевых ОС эта проблема решается следующим образом: в процессе создания виртуального канала хосты обмениваются определенной информацией, уникально идентифицирующей данный канал. Такой обмен обычно называется «рукопожатием» (handshake). Однако, важно отметить, что не всегда для связи двух удаленных компонент в сети создается виртуальный канал. Часто, особенно для служебных сообщений, (например, от маршрутизаторов) используется посылка одиночных пакетов, не требующих подтверждения.
Для адресации пакетов в компьютерных сетях используется сетевой адрес, который уникален для каждой станции (на канальном уровне модели OSI — это аппаратный адрес сетевого адаптера, на сетевом уровне — адрес определяется в зависимости от используемого протокола сетевого уровня (например, IP — адрес)). Сетевой адрес также может использоваться для идентификации пакетов обмена. Однако сетевой адрес довольно просто подделывается и поэтому использовать его в качестве единственного средства идентификации представляется неправильным.
В случае, если в сетевой ОС используются слабые средства идентификации ее удаленных компонент, то оказывается возможной типовая удаленная атака, которая заключается в передачи по сети сообщений от имени любого хоста. При этом существуют две разновидности данной типовой удаленной атаки:
— атака при установленном виртуальном канале
— атака без установленного виртуального канала
В случае установленного виртуального соединения атака будет заключаться в присвоении прав доверенного хоста, легально подключившегося к серверу, что позволит злоумышленнику вести сеанс работы с сервером от имени доверенного хоста. Реализация данного типа атак обычно состоит в посылке пакетов обмена с атакующей станции на сервер от имени доверенной станции и при этом посланные пакеты будут восприняты сервером как корректные. Для осуществления атаки данного типа необходимо преодолеть систему идентификации пакетов, которая, в принципе, может использовать контрольную сумму, вычисляемую с помощью открытого ключа, динамически выработанного при установлении канала, случайные многобитные счетчики пакетов и сетевые адреса станций. Однако на практике в ОС Novell NetWare 3.12 для идентификации пакетов обмена используются два 8-битных счетчика — номер канала и номер пакета; в протоколе TCP для идентификации используются два 32-битных счетчика.
Как было замечено выше, для служебных сообщений используется посылка одиночных пакетов, не требующих подтверждения, то есть не требуется обязательного создания виртуального соединения. Атака без установленного виртуального соединения заключается в посылке служебных сообщений от имени сетевых управляющих устройств, например, от имени маршрутизаторов. Очевидно, что в этом случае для идентификации пакетов возможно лишь использование статических ключей, определенных заранее, что довольно не удобно и требует сложной системы управления ключами, однако, в противном случае, идентификация таких пакетов без установленного виртуального канала будет возможна лишь по сетевому адресу отправителя, который, как отмечалось выше, легко подделать. Посылка ложных управляющих сообщений может привести к серьезным нарушениям работы сети, например, к изменению ее конфигурации.
Подмена доверенного хоста является активным воздействием, совершаемым с целью как перехвата, так и искажения информации по наступлению на атакуемом объекте определенного события. Данная удаленная атака является как внутрисегментной, так и межсегментной и осуществляется на сетевом, транспортном и сеансовом уровнях модели OSI.
4. Ложный сервер или использование недостатков алгоритма удаленного поиска.
В компьютерной сети часто оказывается, что удаленные компоненты сетевой ОС изначально не имеют достаточно информации, необходимой для адресации пакетов обмена. Обычно такой информацией являются аппаратные (адрес сетевого адаптера) и логические адреса (IP — адрес, например) сетевых компьютеров. Для получения подобной информации в сетевых ОС используются различные алгоритмы удаленного поиска, заключающиеся в передаче по сети специального вида запросов, и в ожидании ответов на полученный запрос с искомой информацией. Руководствуясь полученными из ответа сведениями об искомом хосте, запросивший хост начинает адресоваться к нему, то есть, после получения ответа на запрос он обладает всеми необходимыми данными для адресации. Примером подобных запросов, на которых базируются алгоритмы удаленного поиска, могут служить SAP-запрос в ОС Novell NetWare, ARP- и DNS-запрос в сети Internet.
В случае использования сетевой ОС механизмов удаленного поиска существует возможность на атакующей станции перехватить посланный хостом запрос и послать на него ложный ответ, в котором указать данные, использование которых приведет к адресации на атакующий хост — ложный сервер. То есть, в дальнейшем, весь поток обмена между хостом и настоящим сервером, информации о котором запрашивал хост в посланном запросе, будет проходить через ложный сервер.
Ложный сервер — активное воздействие, совершаемое с целью как перехвата, так и искажения информации, являющееся атакой по запросу от атакуемого объекта. Данная удаленная атака является как внутрисегментной, так и межсегментной и осуществляется на канальном, сетевом, транспортном, сеансовом и представительном уровнях модели OSI.
Использование ложного сервера для организации удаленной атаки на сетевую ОС
Получив контроль над проходящим потоком информации между хостами, ложный сервер может применять различные методы воздействия на перехваченную информацию. Рассмотрим их в следующих пунктах.
Селекция потока тнформации и сохранение ее на ложном сервере.
Одной из атак, которую может осуществлять ложный сервер, является перехват передаваемой между сервером и хостом информации. Важно отметить, что факт перехвата информации (файлов, например) возможен из-за того, что при выполнении некоторых операций над файлами (чтение, копирование и т.д.) содержимое этих файлов передается по сети, а значит, поступает на ложный сервер. Простейший способ реализации перехвата — это сохранение в файле всех получаемых ложным сервером пакетов обмена. Данный способ перехвата информации оказывается недостаточно информативным. Это происходит вследствие того, что в пакетах обмена кроме полей данных существуют служебные поля, в данный момент не представляющие интереса. Следовательно, для того, чтобы получить непосредственно передаваемый файл, необходимо проводить на ложном сервере динамический семантический анализ потока информации для его селекции.
Одной из особенностей любой системы воздействия, построенной по принципу ложного сервера, является то, что она способна модифицировать перехваченную информацию. Причем, важно отметить, что это один из двух способов программно модифицировать поток информации между сетевой станцией и сервером с третьей станции. Ведь для реализации перехвата информации в сети необязательно атаковать сетевую ОС по схеме ложный сервер. Эффективней будет атака, осуществляющая анализ сетевого трафика, способная получать все пакеты, проходящие по сети, но, в отличие от системы ложный сервер, она будет не способна к модификации информации.
Далее, рассмотрим два вида модификации информации:
— модификация передаваемых данных
— модификация передаваемого кода
1. Модификация передаваемых данных.
Одной из функцией, которой может обладать система воздействия, построенная по принципу ложный сервер, — модификация передаваемых данных. В результате селекции потока перехваченной информации и его анализа система может распознавать тип передаваемых файлов (исполняемый или текстовый). Соответственно, в случае обнаружения текстового файла или файла данных появляется возможность модифицировать проходящие через ложный сервер данные. Особую угрозу эта функция представляет для сетей обработки конфиденциальной информации.
2. Модификация передаваемого кода.
Другим видом модификации может быть модификация передаваемого кода. Ложный сервер, проводя семантический анализ проходящей через него информации, может выделять из потока данных исполняемый код. Известный принцип неймановской архитектуры гласит, что не существует различий между данными и командами. Следовательно, для того, чтобы определить, что передается по сети, код или данные, необходимо использовать определенные особенности, свойственные реализации сетевого обмена в конкретной сетевой ОС или некоторые особенности, присущие конкретным типам исполняемых файлов в данной локальной ОС.
Представляется возможным выделить два различных по цели вида модификации кода:
— изменение логики работы исполняемого файла
В первом случае, при внедрении РПС исполняемый файл модифицируется по вирусной технологии. То есть, к исполняемому файлу одним из известных способов дописывается тело РПС и, также, одним из известных способов изменяется точка входа так, чтобы она указывала на внедренный код РПС. Описанный способ, в принципе ни чем не отличается от стандартного заражения исполняемого файла вирусом за исключением того, что файл оказался поражен вирусом или РПС в момент передачи его по сети! Такое возможно лишь при использовании системы воздействия, построенной по принципу ложный сервер. Конкретный вид РПС, его цели и задачи в данном случае не имеют значения, но можно рассмотреть, например, вариант использования ложного сервера для создания сетевого червя — наиболее сложного на практике удаленного воздействия в сетях ЭВМ или в качестве РПС использовать сетевые шпионы.
Во втором случае происходит модификация исполняемого кода с целью изменения логики его работы. Данное воздействие требует предварительного исследования работы исполняемого файла и в случае его проведения может принести самые неожиданные результаты. Например, при запуске на сервере программы идентификации пользователей распределенной базы данных ложный сервер может так модифицировать код этой программы, что появится воз-
так модифицировать код этой программы, что появится возможность беспарольного входа с наивысшими привилегиями в базу данных.
Ложный сервер позволяет не только модифицировать, но подменять перехваченную им информацию. Если модификация информации приводит к ее частичному изменению, то подмена — к ее полному изменению. То есть, при возникновении в сети определенного контролируемого ложным сервером события одному из участников обмена посылается заранее подготовленная дезинформация. При этом эта дезинформация в зависимости от контролируемого события может быть воспринята либо как исполняемый код, либо как данные. Рассмотрим пример подобного рода дезинформации.
Предположим, что ложный сервер контролирует событие, которое заключается в подключении пользователя к серверу. В этом случае он ожидает, например, запуска соответствующей программы входа в систему. В случае, если эта программа находится на сервере, то при ее запуске исполняемый файл передается на рабочую станцию. Вместо того, чтобы выполнить данное действие ложный сервер передает на рабочую станцию код заранее написанной специальной программы — захватчика паролей. Эта программа выполняет визуально те же действия, что и настоящая программа входа в систему, например, спрашивается имя и пароль пользователя, после чего полученные сведения посылаются на ложный сервер, а пользователю выводится сообщение об ошибке. При этом пользователь, посчитав, что он неправильно ввел пароль (пароль обычно не отображается на экране) снова запустит программу подключения к системе и со второго раза войдет в нее. Результат такой атаки — имя и пароль пользователя, сохраненные на ложном сервере.
5. Сетевой шпион или удаленный контроль за станцией в сети.
Средства, которые могут использоваться для достижения этой цели, различны. Самые изощренные, наиболее труднообнаруживаемые — это программные закладки и несколько легче обнаруживаемые — компьютерные вирусы. Простейшим примером такой закладки может быть программа, перехватывающая ввод с клавиатуры (паролей, например) и сохраняющая перехваченную информацию в определенном секторе жесткого диска.
В связи с объединением компьютеров в сеть у этого вида РПС появляется новый подвид — сетевые шпионы. Сетевой шпион — это программная закладка или компьютерный вирус, функционирующий в сети ЭВМ, основная цель которого — получение удаленного контроля над рабочей станцией в сети. Данный вид РПС добавляет еще один тип атак на сетевые ОС — удаленный съем информации и получение удаленного контроля над рабочей станцией в сети.
Рассмотрим схематично основные этапы работы сетевого шпиона:
1. инсталляция в памяти;
2. ожидание запроса с удаленного атакующего компьютера, на котором запущена головная сервер — программа, и обмен с ней сообщениями о готовности;
3. передача перехваченной информации на головную сервер — программу или предоставление ей контроля над зараженным компьютером.
Рассмотрим основные функции, присущие сетевым шпионам:
1. Перехват и передача вводимой с клавиатуры информации на головную сервер — программу;
2. Перехват и передача экранной информации на головную сервер — программу;
3. Перехват и передача на головную сервер — программу системной информации о ПК (тип ОС, параметры компьютера, загруженные программы и т.д.);
4. Получение контроля сервер — программой над зараженным удаленным компьютером (удаленный запуск программ, копирование данных, удаление данных и т.д.).
Таким образом, проникновение в сетевую ОС сетевых шпионов нарушает политику безопасности, принятую в сети, ведет к нарушению целостности данных и позволяет несанкционированно использовать вычислительные мощности компьютеров, объединенных в сеть.
Одним из примеров подобной закладки может служить Registration Wizard в ОС Windows 95, которая после установки данной операционной системы пытается совершить звонок по модему в офис фирмы Microsoft и сообщить данные о параметрах ПК, на который она установлена и данные о пользователе, ее использующем.
Сетевой шпион — активное воздействие, совершаемое как с целью перехвата, так и искажения информации, являющееся атакой по запросу. Сетевой шпион — это как внутрисегментная, так и межсегментная удаленная атака, осуществляемая на сетевом уровне модели OSI.
Сетевой червь (WORM).
В сети ЭВМ существует вид вирусов, называемый сетевыми червями (worm), распространяющийся в ней. Основная цель и задача сетевого червя — получение управления в операционной системе удаленного компьютера.
Рассмотрим схематично основные этапы работы сетевого червя:
1. Поиск в сети цели атаки — удаленных ЭВМ;
2. Передача по сети своего кода на цель атаки;
3. Получение управления в операционной системе цели атаки:
Из этой схемы видно, что основной проблемой для сетевого червя является получение управления на удаленном компьютере. Решение этой задачи на практике чрезвычайно затруднено, так как, для ее решения необходимо либо знать имя и пароль пользователя для входа в компьютер, либо обладать информацией о люках или дырах в программном обеспечении, обеспечивающем удаленный доступ, либо использовать ошибки администрирования служб предоставления удаленного доступа. Единственный пример сетевого червя — это червь Морриса, распространившийся в сети Internet в 1988г., который использовал описанные выше ошибки, существовавшие в ранних версиях утилит finger и sendmail, а также ошибки администрирования сетевых служб ОС UNIX (r — служб).
7. Удаленные атаки, использующие ошибки администрирования или ошибки в реализации служб предоставления удаленного доступа.
Одной из особенностей сетевых операционных систем является наличие в них служб предоставления удаленного доступа (СПУД). Под удаленным доступом понимается предоставление прав и полномочий пользователю на чтение, запись, запуск программ или получение информации на удаленном компьютере. Соответственно основная задача службы предоставления удаленного доступа — это принятие решения о возможности предоставления пользователю удаленного доступа и его обеспечение.
В современных сетевых ОС одним из важнейших фактором, обеспечивающим безопасность сети, является безопасное администрирование СПУД. Очевидным фактом является то, что какой бы ни была надежной СПУД, при неправильном ее администрировании безопасность системы в целом будет сведена на нет. На практике оказывается, что администрирование СПУД является довольно сложным делом. Это связано с тем, что СПУД нельзя рассматривать в отрыве от конкретной сетевой ОС, в которой она используется. А так как современные сетевые ОС в большинстве своем довольно сложны и состоят из большого количества объектов разной степени значимости (пользователей, процессов, файлов, периферийных устройств и т.д.), отношения между которыми и, соответственно, доступ к которым и должна регулировать СПУД, то задача разграничения доступа и задание тех или иных приоритетов (уровней безопасности) для объектов компьютерной системы в основном ложится на администратора безопасности системы. В связи с этим увеличивается вероятность ошибки при администрировании СПУД.
На практике оказывается, что ошибки администрирования сетевых ОС — один из основных факторов, приводящих к различным нарушениям безопасности системы и одна из основных причин успеха удаленных атак.
Другая причина возможного успеха удаленной атаки может заключаться в наличии программных или алгоритмических ошибок в СПУД. Обнаружить такую ошибку довольно сложно. Информацию о подобных ошибках можно узнать, используя информационные услуги сети Internet.
Удаленная атака, использующая ошибки администрирования или ошибки в реализации СПУД, является наиболее просто осуществляемым воздействием, которое классифицируется по любому классу в классификации удаленных атак.