Максимальная Безопасность:

Руководство Хакера по Защите Вашего Internet Сайта и Сети

Предыдущая главаСледующая главаСодержание

11

Троянские Программы

Эта глава исследует одно из наиболее коварных приспособлений, использующихся для обхода безопасности Internet: троянский конь или троянская программа. Никакое другое приспособление с такой большой вероятностью не приводит к полной компрометации системы, и ни одно другое приспособление так трудно не обнаруживается.

Что Такое Троянская Программа?

Прежде, чем начать, я хочу предложить определение троянской программы, потому что эти приспособления часто путают с другим злонамеренным кодом. Троянский конь это

Неавторизованные функции, которые выполняет троянская программа, могут иногда квалифицировать её как другой тип злонамеренного приспособления. Например, некоторые вирусы вписываются в эту категорию. Такой вирус может быть скрыт внутри полезной программы. Когда так происходит, программа может быть правильно названа и троянской программой и вирусом. Файл, который предоставляет кров такой троянской программе/вирусу был сделан троянским.

Классические документы по безопасности Internet определяют термин различными способами. Возможно наиболее известное (и как ни странно, наиболее либеральное) определение дано в RFC 1244, Site Security Handbook (Руководство по Безопасности Сайта):

Троянским конем может быть программа, которая делает что-то полезное, или просто что-то интересное. Она всегда делает что ни будь неожиданное, подобно захвату паролей или копированию файлов без вашего ведома.

Другое определение, которое кажется весьма подходящим, дал Доктор Alan Solomon, международно-известный специалист по вирусам, в своей работе, названной All About Viruses (Все О Вирусах):

Троянская программа это программа, которая делает больше, чем ожидает пользователь, и эта дополнительная функция разрушительна. Это ведет к проблеме обнаружения троянских программ. Предположим, что я написал программу, которая может безошибочно определять, форматировала ли другая программа жесткий диск. Затем, может ли сказать, что эта программа троянская? Очевидно нет, если эта программа предполагает форматирование жесткого диска (подобно Format, например), то это не троянская программа. Но если пользователь не ожидает форматирования, то это троянская программа. Проблема состоит в том, чтобы сравнить то, что программа делает с ожиданиями пользователя. Вы не можете определить ожидания пользователя программы.
Ссылка: Все О Вирусах Доктора Alan Solomon может быть найдена на
http://www.drsolomon.com/vircen/allabout.html.

Любой интересующийся вирусами (или кто только хочет узнать больше о вирусной технологии) должен посетить сайт Доктора Solomon на
http://www.drsolomon.com/.

И наконец, Вы можете классифицировать троянскую программу как: любая программа, которая выполняет скрытую и нежелательную функцию. Она может приходить в любой форме. Это может быть утилита, которая имеет целью индексировать каталоги или которая разблокировывает коды регистрации в программном обеспечении. Это может быть текстовый процессор или сетевая утилита. Короче говоря, троянская программа может быть чем ни будь (и может быть найдена в чем ни будь), что Вы или ваши пользователи вводите в систему.

Откуда Приходят Троянские Программы?

Троянские программы создаются исключительно программистами. Ни кто не может получить троянскую программу другим способом, чем получив троянский файл, который был подготовлен программистом. Правда, это возможно для тысячи обезьян, печатающих 24 часа в день, чтобы, в конечном счете, создать троянскую программу, но статистическая вероятность этого незначительна. Таким образом, троянская программа начинается с человеческого намерения или mens rea. Где-ни будь на этой планете, программист создаёт троянскую программу прямо сейчас. Этот программист знает точно, что он делает, и его намерения вредоносны (или, по крайней мере, не альтруистичны).

Автор троянца имеет повестку дня. Эта повестка дня может быть почти любой, но в контексте безопасности Internet, троянская программа будет делать одну из двух вещёй:

Некоторые троянские программы делают и то и другое. Дополнительно, имеется другой класс троянских программ, которые наносят ущерб адресату (например, такая, которая зашифрует или переформатирует ваш жесткий диск). Так что троянские программы могут выполнять различные разведывательные или диверсионные задачи.

Один пример, который удовлетворяет критерию диверсионного инструмента это троянский конь PC CYBORG. Как объясняется 19 декабря, 1989 в бюллетене CIAC ("Информация Троянском Коне PC CYBORG (СПИД)"):

Недавно имелось значительное внимание средств массовой к информации о новом троянском коне, которые рекламируют его как вирус СПИДА для пользователей компьютеров IBM PC и аналогов PC. Как только троянский конь попадает в систему, он заменяет AUTOEXEC.BAT и считает сколько раз инфицированная система загружалась, пока не достигнет числа 90. В этот момент PC CYBORG скрывает каталоги и шифрует имена всех файлов на диске C:. Существует больше одной версии этого троянского коня, и, по крайней мере, одна версия не ждет, чтобы повредить диск C:, а скрывает каталоги и шифрует имена файлов при начальной загрузке сразу после того, как установлена.
Ссылка: Вы можете найти бюллетень CIAC "Информация о Троянском Коне PC CYBORG (СПИД)" на
http://www.sevenlocks.com/CIACA-10.htm.

Другой пример (который вызвал довольно обширное опустошение) это троянский конь AOLGOLD. Он распространялся, прежде всего, по сети Usenet и через электронную почту. Предполагалось, что программа была усовершенствованным пакетом для доступа к America Online (AOL). Дистрибутив состоял из единственного, заархивированного файла. Разархивирование архива создавало два файла, один из которых был стандартным файлом INSTALL.BAT. Выполнение файла INSTALL.BAT приводило к развертке 18 файлов на жесткий диск. Как сообщалось в консультации по безопасности ("Information on the AOLGOLD Trojan Program" - "Информация по Троянской Программе AOLGOLD") датированной воскресеньем, 16 февраля, 1997:

Троянская программа стартовала с запуска файла INSTALL.BAT. Файл INSTALL.BAT простой пакетный файл, который переименовывает файл VIDEO.DRV в VIRUS.BAT и затем выполняет его. VIDEO.DRV любительский пакетный файл DOS, который удаляет содержимое нескольких критических каталогов на вашем диске C:, включая 

c:\
c:\dos
c:\windows
c:\windows\system
c:\qemm
c:\stacker
c:\norton
Когда пакетный файл завершается, он печатает на экране грубое сообщение и пытается выполнить программу с именем DOOMDAY.EXE. Ошибки в пакетном файле делают невозможным выполнение программы DOOMDAY.EXE. Другие ошибки в файле заставляют его удалять себя, если он запущен с любого диска, отличного от C:. Стиль программирования и ошибки в пакетном файле указывают на то, что троянская программа написана кем-то, кто имеет немного опыта в программировании.
Ссылка: Вы можете найти консультацию по безопасности, озаглавленную "Информация по Троянской Программе AOLGOLD", на
http://www.emergency.com/aolgold.htm.

Эти троянские программы были исключительно работой любительских программистов, детей, которые имели не более сложную причину чем порождение неприятностей. Они обе были разрушительными троянскими программами и не выполняли никаких сложных коллективных или проникающих функций. Такие троянские программы часто отмечаются, и обычно поверхностно, в сети новостей Usenet.

Однако, троянские программы (по крайней мере в мире UNIX) создаются людьми, которые также вовлечены в законопослушную разработку системы. Они на рабочем месте, где ни будь в фирме разработчике, вставляют неавторизованный код в приложение или утилиту (или, в редких случаях, непосредственно в ядро операционной системы). Они могут быть гораздо более опасны по ряду причин:

Имеются также случаи, когда ключевые утилиты UNIX скомпрометированы (и сделаны троянскими) программистами, которые не имеют никакого отношения к разработке исходной программы. Это случалось много раз и, больше чем в одном случае, вовлекало связанные с безопасностью программы. Например, после выпуска SATAN, троянская программа нашла свой путь в дистрибутиве SATAN 1.0 для Linux.

ПРИМЕЧАНИЕ: Этот дистрибутив не был работой Farmer или Venema. Вместо этого, это был прекомпилированный набор двоичных образов, предназначенных исключительно для пользователей Linux, откомпилированных в Университете Temple. Кроме того, троянская программа была ограничена единственным выпуском, который был 1.0.

По сообщениям, файл, на который производилось воздействие, была программа, названная fping. История происходила следующим образом: Программист получил физический доступ к машине, содержащей программу. Он изменил функцию main() и изменил fping так, чтобы, когда пользователи запускали SATAN, в их файл /etc/passwd помещалась специальная запись. Эта специальная запись добавляла пользователя с именем suser. Через идентификатор этого пользователя преступник надеялся скомпрометировать много узлов. Это и произошло, но были зарегистрированы только два случая такой компрометации. Категорически заявляю, что программирование имело низкое качество. Например, троянская программа не обеспечила никакого решения для систем, которые использовали затененные пароли.

ПРИМЕЧАНИЕ: Дистрибутив Linux Slackware по умолчанию имел схему незатененных паролей. Это может быть истинно и для других дистрибутивов Linux. Однако программист, ответственный за рассматриваемую троянскую программу, должен был не рассчитывать на это. Код только бы слегка более усложнился после добавления такого условия.

Как Вы можете видеть, троянская программа может неожиданно возникнуть где ни будь. Даже файл, приходящий из доверенного источника, может быть троянским.

Где Каждый Может Найти Троянскую Программу?

Технически, троянская программа может появиться почти везде, в любой операционной системе или платформе. Однако, за исключением внутренней работы, упомянутой прежде, распространение троянских программ работает очень подобно распространению вирусов. Программное обеспечение, загруженное из Internet, особенно shareare или freeware, всегда подозрительно. Точно так же материалы, загруженные с подпольных серверов или телеконференций Usenet, также кандидаты на это.

Иногда, нет необходимости путешествовать по таким темным и запрещённым переулкам, чтобы найти троянскую программу. Троянские программы могут быть найдены на главных сетевых распределениях. Например, исследуйте эту выборку из консультации по безопасности CIAC ("E-14: Wuarchive Ftpd Trojan Horse" - "E-14: Троянский Конь Wuarchive Ftpd"), зарегистрированную в Сети в 1994:

CIAC получил информацию, что некоторые копии wuarchive демона FTP (ftpd) версии 2.2 и 2.1f изменились на уровне исходных текстов и содержат троянского коня. Эта троянская программа позволяет любому пользователю, локальному или удаленному, стать корневым в пораженной UNIX системе. CIAC строго рекомендует, чтобы все сайты, выполняющие эти или более старшие версии wuarchive ftpd, получили и установили версию 2.3. Возможно, что версии до 2.2 и 2.1f также содержат троянскую программу.

wftpd один из наиболее широко используемых серверов FTP в мире. Эта консультация воздействовала на тысячи сайтов, общественных и частных. Многие из этих сайтов всё ещё в опасности, прежде всего, потому что системные администраторы в этих местах не так сознательны в безопасности, как это должно было бы быть.

СОВЕТ: Выберите 100 случайных узлов в пустоте, и испробуйте их FTP серверы. Держу пари, что из этих узлов больше 80% используют wftpd. Кроме того, другие 40% вероятно используют более старшие версии, которые, хотя и не могут стать троянскими, имеют недостатки безопасности некоторого вида.

Как Часто Троянские Программы Действительно Обнаруживаются?

Троянские программы обнаруживаются достаточно часто, потому что они главная проблема безопасности. Что делает троянские программы настолько коварными так это то, что даже после того, как они обнаружены, их влияние всё ещё чувствуется. В этом отношении троянские программы подобны перехватчикам. Никто не может знать точно, как глубоко в систему проникла компрометация. Имеются несколько причин для этого, но я ограничусь в этом разделе только одной.

Как Вы скоро прочитаете, большинство троянских программ вложено в откомпилированные двоичные образы. То есть код, который содержит троянскую программу, больше не в человеко-читаемой форме, а в откомпилированной. Таким образом, он в машинном языке. Этот язык может быть исследован в некоторых редакторах, но даже тогда обычно понятны только печатаемые символьные строки. Это чаще всего сообщения об ошибках, помощь, флаги опций или другие данные, печатаемые на STDOUT в указанных местах программы: 

my_function() 
{
   cout << "Значение, которое Вы ввели, вне деапазона!\n";
   cout << "Пожалуйста, введите другое:"
}

Поскольку двоичные образы откомпилированы, они приходят пользователю как (более или менее) point-and-shoot приложения. Другими словами, пользователь берет файл, или файлы как есть, не зная близко их структуру.

Когда обнаруживается, что такой двоичный образ содержит троянскую программу, немедленно выпускаются консультации по безопасности. Они имеют тенденцию быть предварительными и позже сопровождаться более исчерпывающими консультациями, которые кратко обсуждают цель и метод работы троянского кода. Если пользователь не программист, эти консультации разъясняют немного больше чем "Получают заплату сейчас и замените поддельный двоичный образ". Опытные системные администраторы ясно понимают значение таких консультаций (или даже ясно понимают цель кода, который обычно включается в исчерпывающую консультацию). Однако даже тогда оценка ущерба может быть трудна.

В некоторых случаях ущерб достаточно просто оценить (например случаи, где цель троянской программы состояла в том, чтобы отправить по почте содержимое файла passwd). Исправление довольно простое: Замените двоичный образ чистой версией, и попросите всех пользователей изменить свои пароли. Дальше от троянской программа не ожидается никакого ущерба или компрометации. Вот и все.

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

ПРИМЕЧАНИЕ: Переинсталляция может быть необходимой. Большое количество ваших файлов могло быть сделано троянскими, начиная с начальной компрометации. Вместо того чтобы пытаться плотно исследовать каждый файл (или поведение каждого файла), лучше было бы начать с этого. Одинаково, даже если большинство файлов не стали троянскими, есть вероятность, что пароли, персональные данные или другие чувствительные материалы были скомпрометированы.

И наоборот, троянские программы могут быть найдены в исполняемых файлах, которые не откомпилированы. Это могут быть shell сценарии, или возможно программы, написанные на Perl, JavaScript, VBScript, Tcl (популярный язык создания сценариев) и т.д. Имеется несколько проверенных случаев этого типа троянской программы. Взломщик, который размещает троянскую программу в неоткомпилированной выполняемой программе, сильно рискует. Исходник это простой, человеко-читаемый текст. В маленькой программе блок троянского кода очень бы выделялся. Однако этот метод может и не быть настолько смешным имея дело с большими программами или с программами, которые включают ряд откомпилированных двоичных образов и выполняемых shell сценариев, вложенных в несколько подкаталогов. Чем более сложна структура дистрибутива, тем менее вероятно то, что человек, используя обычные методы исследования, раскроет троянскую программу.

Кроме того, нужно рассмотреть уровень знаний пользователя. Пользователи, которые знают немного о своей операционной системы, менее вероятно, что отважатся глубоко в структуру каталогов данного дистрибутива, ища таинственный или подозрительный код (даже если этот код человеко-читаем). И все наоборот, если пользователь программист. Однако факт, что пользователь является программистом, не означает, что он немедленно распознает троянскую программу. Я знаю многих БЕЙСИК программистов, которые имеют трудности при чтении кода, написанного на Perl. Таким образом, если троянская программа создана на языке создания сценариев, программист должен сначала быть знаком с этим языком, прежде чем он сможет идентифицировать нежелательный код. Также истинно то, что если язык даже слегка походит на тот, который программист обычно использует, то этот программист может быть способен идентифицировать проблему. Например, Perl достаточно похож на C, так что C программист, который не написал и строки на Perl, может эффективно идентифицировать злонамеренный код в сценарии Perl. И конечно, любой, кто пишет программы на языке оболочки или awk, также распознал бы сомнительный код в Perl программе.

ПРИМЕЧАНИЕ: Многие Perl программы (или другие сценарийные программы оболочки) динамические. То есть они могут изменяться согласно некоторым обстоятельствам. Например, рассмотрите программу, которая, в действительности, перезаписывает себя, основываясь на некоторых условиях, указанных в программном коде. Такие файлы должны проверяться на вмешательство вручную, потому что программы проверки целостности будут всегда сообщать, что файл был атакован, даже, когда это не так. Сегодня существует относительно немного динамических программ, но это собирается меняться. В Internet ведется разговор об использовании языков подобных Perl, чтобы выполнять функции в Электронном Обмене Данными (EDI - Electronic Data Interchange). В некоторых случаях эти файлы выполняют функции, которые обязательно требуют, чтобы программный файл изменился.

Какой Уровень Риска Представляют Троянские Программы?

Троянские программы представляют сверхвысокий уровень риска, главным образом по уже установленным причинам:

Позвольте мне пояснить. Троянские программы являются отличным примером нападения, которое фатально для системного администратора, который имеет только очень мимолетное знание безопасности. В таком климате, троянская программа может привести к полной компрометации системы. Троянская программа может находиться в машине в течение недель или даже месяцев, прежде чем её обнаружат. За это время взломщик с корневыми привилегиями может изменить всю систему, чтобы удовлетворить свои потребности. Таким образом, даже когда троянская программа обнаружена, могут существовать новые дыры, о которых системный администратор полностью не подозревает.

Как Обнаружить Троянскую Программу?

Обнаружить троянские программы не так трудно, как это первоначально кажется. Но сильное знание вашей операционной системы необходимо. А также может помочь некоторое знание шифрования.

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

Большинство форм защиты против (и предотвращения) троянских программ основано на методике, иногда упоминаемой как согласование объектов. Хотя термин звучит пугающе, все намного проще. Это причудливый путь выяснения "Вещи всё ещё такие, как я их оставил?". Вот как это работает: Объекты это или файлы или каталоги. Согласование это процесс сравнения этих объектов с их более ранней (или поздней) копией. Например, возьмите резервную ленту и сравните файл PS, в каком виде он существовал в ноябре 1995, с PS, который теперь постоянно находится на вашем диске. Если они отличаются, и в операционной системе не было сделано никаких изменений, что-что не так. Эта методика неизменно применяется к системным файлам, которые установлены как часть основной операционной системы.

Согласование объектов может быть легко понято, если Вы признаете, что каждый раз, когда файл изменяется некоторым способом, изменяются и его параметры. Например, один способ синхронизировать изменения в файле исследовать дату последнего изменения. Каждый раз, когда файл открывается, изменяется и сохраняется, появляется новая дата последней модификации. Однако этой датой можно легко управлять. Рассмотрим управление этим временем на платформе PC. Насколько это трудно? Измените глобальную установку времени, примените желательные редактирования и сохраните файл. Теперь время изменено. По этой причине, время наименее надёжный способ согласовать объект (по крайней мере, полагаться просто на дату последней модификации ненадежно). Также, последняя дата модификации ничего не покажет, если файл не был изменен (например, если он был только скопирован или отправлен по почте).

ПРИМЕЧАНИЕ: Пользователи PC, которые использовали старые машины, могут легко понять это. Иногда, когда батарея CMOS выходит из строя, система может временно отключиться. Когда она будет восстановлена, Вы увидите, что несколько файлов имеют дату 1 января, 1980.

Другой способ проверять целостность файла исследовать его размер. Однако этот метод чрезвычайно ненадежен из-за легкого управления этим параметром. При редактировании простых текстовых файлов, просто начать с размера, скажем 1,024KB, и закончить с этим же размером. Требуется вырезать немного здесь и добавить немного там. Но ситуация меняется радикально, когда Вы хотите изменить двоичный файл. Двоичные файлы обычно включают специальные функциональные библиотеки и другие модули, без которых программа не будет работать. Таким образом, изменение двоичного файла (и сохранение функциональности программы) более сложный процесс. Программист должен сохранить все необходимые части программы и найти участок памяти для своего собственного кода. Поэтому, размер вероятно слегка более надежен указатель, чем время. Кратко, перед тем как продолжить, позвольте мне объяснить процесс, которым файл становится троянским.

Наиболее общий сценарий, когда полу-доверенный (известный) файл является объектом нападения. То есть файл, присущий дистрибутиву вашей операционной системы. Он приходит от поставщика (csh в UNIX или command.com в DOS). Эти файлы записываются в ваш диск при первой установке, и имеют собственную дату и время. Они также имеют определенный размер. Если время, дата или размеры этих файлов отличаются от первоначальных значений, это немедленно возбуждает подозрение.

Злые программисты знают это. Их работа, поэтому, состоит в тщательном исследовании исходного текста файла (обычно получаемого в другом месте) на элементы, которые могут быть исключены (например, они могут удалить прокомментированный текст или что ни будь другой, не очень существенный элемент файла). В исходник записывается неавторизованный код, и файл перекомпилируется. Затем взломщик исследует размер файла. Возможно, он слишком велик или слишком мал. Затем процесс повторяется, пока нападающий не скомпилирует файл, который будет настолько близок к первоначальному размеру, насколько возможно. Этот процесс занимает много времени. Если двоичный образ довольно большой, может потребоваться несколько дней.

ПРИМЕЧАНИЕ: Когда адресатом является первоначальный файл дистрибутива операционной системы, нападающему придется или вероятно придется пройти этот процесс. Если файл ещё не был никому распространён, нападающий не должен беспокоиться об этой проблеме. Потому что никто ещё не видел файл или его размер. Возможно, только первоначальный автор файла может узнать, что в нем неправильно. Если этот автор не сознателен в безопасности, он может даже и не знать. Если Вы программист, подумайте теперь о самом последнем двоичном образе, который Вы скомпилировали. Насколько он был большой? Каков был размер файла? Держу пари, Вы не помните.

Когда файл был изменен, он помещается туда, где другие могут получить его. В случае дистрибутивов операционной системы, это обычно центральный сайт для загрузки (типа sunsite.unc.edu, который содержит одну из самых больших коллекций программного обеспечения UNIX на планете). Оттуда, файл находит путь к рабочим станциям в пустоте.

ПРИМЕЧАНИЕ: sunsite.unc.edu это поддерживаемый Sun Microsystems сайт на UNC Chapel Hill. Этот сайт содержит большую часть свободного программного обеспечения в Internet. Тысячи людей, включая меня, полагаются на высококачественное программное обеспечение UNIX, доступное в этом месте. Не ничего хорошего, что можно сказать об этом сайте. Это огромная общественная служба.

По причинам, которые должны теперь быть очевидными, размер файла также плохой параметр, чтобы следить за его изменением. И так, давайте перечислим: Дата, дата последнего доступа, время и размер, все эти параметры не имеют реального значения. Ни один из них не подходит для определения целостности файла. В каждом имеется некоторый недостаток, обычно свойственный платформе, который делает эти параметры простыми для изменения. Таким образом, создание массивной базы данных всех файлов и соответствующих им значений (время, размер, дата) имеет только очень ограниченное значение:

...контрольный список одна из форм такой базы данных для UNIX системы. Содержание самого файла обычно не сохраняется, поскольку это потребовало бы слишком большого дискового пространства. Вместо этого, контрольный список содержит набор значений, сгенерированных из первоначального файла, обычно включая длину, время последней модификации и владельца. Контрольный список периодически освежается и сравнивается с сохраненной копией, и несоответствия отмечаются. Однако ... изменения могут быть сделаны в содержимом файлов UNIX без изменения любого из этих значений. В частности пользователь, получивший доступ к корневой учетной записи, может модифицировать диск, чтобы изменить сохраненные данные без отображения в контрольном списке.

Имеются другие параметры, которые можно проверять, типа контрольных сумм. Это гораздо лучшие параметры, но они также не полностью надежны. В системе контрольных сумм элементы данных файла складываются вместе и пропускаются через алгоритм. Результирующее число это контрольная сумма, тип подписи для этого файла (устройства считывания штрихового кода иногда используют контрольные суммы в процессе сканирования). На платформе SunOS можно делать обзор контрольной суммы конкретного файла, используя утилиту sum. sum вычисляет (и печатает на STDOUT или других указанных устройствах) контрольные суммы файлов, обеспеченных в строке параметров.

Хотя контрольные суммы более надежны чем время, дата, или последняя дата модификации, они также могут быть фальсифицированы. Большинство системных администраторов предлагают, если Вы полагаетесь на систему контрольных сумм, список контрольных сумм нужно хранить на отдельном сервере или даже отдельной среде, доступной только корневым и другим доверенным пользователям. В любом случае, контрольные суммы хорошо работают для проверки целостности переданного файла, например, из точки А в точку В.

ПРИМЕЧАНИЕ: Пользователи, которые непосредственно выполняли передачу файлов, используя коммуникационные пакеты типа Qmodem, Telix, Closeup, MTEZ или другие, помнят, что эти программы иногда подсчитывают контрольную сумму или проверяют CRC во время передачи. Каждый переданный файл проверяется на целостность. Это уменьшает, но не устраняет, вероятность поврежденного файла на адресате. Если файл оказывается поврежденным или испорченным, процесс передачи может начаться снова. Однако эта методика недостаточна для борьбы со сложными нападениями против целостности файлов.

Ссылка: По Internet разбросаны справочные документы о поражении систем контрольных сумм. Большинство из них связаны с разработкой вирусов (многие утилиты проверки на вирусы используют анализ контрольной суммы, чтобы идентифицировать вирусную деятельность). Коллекция таких статей (все из которых подпольные) может быть найдена на
http://www.pipo.com/guillermito/darkweb/news.html.

MD5

Вы вероятно задаётесь вопросом, является ли какая ни будь методика достаточной. Я счастлив сообщить, что такая методика имеется. Она включает вычисление цифрового отпечатка пальца, или сигнатуры, для каждого файла. Это производится по средствам различных алгоритмов. Для этой цели используется семейство алгоритмов, названное MD series (MD серия). Одна из наиболее популярных реализаций системы называется MD5.

MD5 это утилита, которая может генерировать цифровую подпись файла. MD5 принадлежит к семейству односторонних хеш-функций, названных алгоритмами обзора сообщений (message digest algorithms). MD5 система определена в RFC 1321. Вкратце:

Алгоритм принимает на входе сообщение произвольной длины и производит на выходе 128-разрядный "отпечаток пальца" или "обзор сообщения". Предполагается, что в вычислительном отношении неосуществимо произвести два сообщения, имеющих тот же самый обзор сообщения, или произвести любое сообщение, имеющее данный предопределенный обзор сообщения. Алгоритм MD5 предназначен для приложений цифровой подписи, где большой файл должен быть "сжат" безопасным способом перед шифровкой частным (секретным) ключом под криптосистемой с открытым ключом, типа RSA.
Ссылка: RFC 1321 расположен на
http://www.freesoft.org/Connected/RFC/1321/1.html.

Когда кто ни будь пропускает файл через реализацию MD5, появляется сигнатура как 32-символьное значение. Она напоминает следующее: 

2d50b2bffb537cc4e637dd1f07a187f4

Многие сайты, которые распространяют исправления безопасности для операционной системы UNIX, используют эту методику. Таким образом, если Вы просмотрите их каталоги, Вы сможете исследовать подлинную цифровую сигнатуру каждого файла. Если, после загрузки того файла, Вы обнаружите, что сигнатуры различны, имеется вероятность 99.9%, что что-что ужасно неправильно.

MD5 выполняет одностороннюю хеш-функцию. Вы возможно знакомы с этими операциями из других форм шифрования, например из шифрования файлов паролей.

Некоторые очень критические программы безопасности используют алгоритмы MD4 и MD5. Одна такая программа S/Key, которая является зарегистрированной торговой маркой Bell Laboratories. S/Key осуществляет схему одноразовых паролей. Одноразовые пароли почти неломаемы. S/Key используется, прежде всего, для удаленных входов в систему и предлагает расширенную безопасность для этих каналов связи (в противоположность использованию слабой или вообще никакой безопасности при инициализации обычной сессии Telnet или Rlogin). Процесс работает как описано в "Кратком Обзоре S/Key" (автор неизвестен):

S/Key использует или MD4 или MD5 (односторонние алгоритмы хеширования, разработанные Ron Rivest) для реализации схемы одноразовых паролей. В этой системе пароли посылаются открытым текстом по сети. Однако после того как пароль использован, он больше не полезен для подслушивателя. Самое большое преимущество S/Key состоит в том, что она защищает против подслушивателей без модификации программного обеспечения клиента и неудобств для пользователей.
Ссылка: Читайте "Краткий Обзор S/Key" на
http://medg.lcs.mit.edu/people/wwinston/skey-overview.html.

С или без MD5, согласование объектов это сложный процесс. Правда, на одной рабочей станции с ограниченными ресурсами технически можно согласовать каждый файл и каталог вручную (я не рекомендую это делать, если Вы хотите сохранить свое здоровье). Однако в больших сетевых средах это просто невозможно. И чтобы справиться с этой проблемой были разработаны различные утилиты. Наиболее известная из них это программа, удачно названная TripWire.

TripWire

TripWire (написанная в 1992) это всесторонняя утилита целостности системы. Она написана на классическом Kernhigan и Ritchie C (Вы помните из Главы 7, "Рождение Сети Internet", что я обсуждал преимущества мобильности C. Именно эта мобильность повлияла на выбор языка авторами TripWire).

TripWire хорошо разработана, легка для понимания и работает с минимальными проблемами. Система читает вашу среду из файла конфигурации. Этот файл содержит все файловые маски (типы файлов, которые Вы хотите контролировать). Эта система может быть весьма чувствительна. Например, Вы можете определить то, какие изменения могут быть сделаны с файлами данного класса без того, чтобы TripWire сообщила об изменении (или, для более полного контроля системы, Вы можете просто пометить каталог как адресат процесса контроля). Первоначальные значения (цифровые подписи) этих файлов сохраняются в файле базы данных. К этому файлу базы данных (просто ASCII) производится доступ всякий раз, когда сигнатура должна быть рассчитана. Хеш-функции, включенные в дистрибутив:

Сообщено, что по умолчанию для генерации значений всех файлов используются хэш-функции безопасности MD5 и Xerox. Однако документация TripWire говорит, что все эти функции могут применяться как к части, так и ко всем файлам.

В целом, TripWire это очень хорошо разработанный пакет со многими опциями.

Ссылка: TripWire (и статьи по использованию и проектированию) может быть найдена на
ftp://coast.cs.purdue.edu/pub/tools/unix/TripWire/.

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

База данных, используемая программой проверки целостности, должна быть защищена от неавторизованных модификаций. Злоумышленник, изменив базу данных, может уничтожить всю схему контроля целостности.
Ссылка: Прежде, чем Вы будете использовать TripWire, прочитайте "The Design and Implementation of TripWire: A File System Integrity Checker" ("Проектирование и Реализация TripWire: Программа Проверки Целостности Файловой Системы") Gene H. Kim и Eugene H. Spafford. Документ расположен на
ftp://ftp.cs.purdue.edu/pub/spaf/security/Tripwire.PS.Z.

Один метод защиты базы данных чрезвычайно надежен: Храните базу данных на носителях только для чтения. Это фактически устраняет любую возможность вмешательства. Фактически, эта методика становится прочной тенденцией в безопасности. В Главе 21, "Plan 9 from Bell Labs", Вы узнаете, что люди из Bell Labs теперь хранят свои log-файлы на средствах с одноразовой записью или только для чтения. Кроме того, в недавней консультации по безопасности я был удивлен, обнаружив, что клиенты (которые только что узнали о безопасности) очень сильно желали средства только для чтения для своих Web баз данных. Эти базы данных были весьма чувствительны, и изменение информации могло бы потенциально угрожать безопасности других систем.

Kim и Spafford (авторы TripWire) также предлагают, чтобы база данных была защищена этим способом, хотя и признают, что это может представлять некоторые практические, процедурные проблемы. Многое зависит от того, как часто база данных будет модифицироваться, насколько она большая и т.д. Конечно, если Вы используете TripWire в широком масштабе (и в его максимальном приложении), обслуживание базы данных только для чтения может быть очень сложной. Снова, это сводится к уровню риска и необходимости в более повышенной или возможно оптимальной безопасности.

TAMU

Набор программ TAMU (конечно из Университета A&M Техас) это совокупность утилит, которые существенно повышают безопасность UNIX машины. Эти утилиты были созданы в ответе на очень реальную проблему. Как объясняется в резюме, которое сопровождает дистрибутив:

Компьютеры UNIX Университета A&M Техас недавно претерпели обширное нападение скоординированной группы Internet взломщиков. Этот документ представляет краткий обзор проблемы и наших ответов на нее, которые включили разработку политики, процедур и sdoels для защиты университетских компьютеров. Разработанные утилиты включают 'drawbridge', расширенный фильтрующий мост Internet, 'tiger scripts', чрезвычайно мощные, но удобные программы для защиты индивидуальных узлов, и 'xvefc', (XView Etherfind Client), мощный распределенный сетевой монитор.

Содержащийся в дистрибутиве TAMU пакет tiger scripts формирует основу аутентификации цифровой подписи дистрибутива. Как объясняет вышеупомянутое резюме:

Выполненная проверка покрывает широкий диапазон элементов, включая элементы, идентифицированные в объявлениях CERT, и элементы, наблюдаемые в недавних вторжениях. Сценарии используют криптографические программы контрольной суммы Xerox'а, чтобы контролировать изменение системных файлов (возможно люки/троянцы), а также проверять наличие требуемых заплат, связанных с безопасностью.
Ссылка: Xerox hash.2.5a может быть найдена на ftp сайте PARC
(ftp://parcftp.xerox.com/pub/hash/hash2.5a/).
Этот пакет обычно упоминается как Xerox Secure Hash Function (Хэш-функция Безопасности Xerox), а дистрибутив назван именем Snefru, фараона древнего Египта. Дистрибутив на вышеупомянутом сайте был выпущено в 1990, и включает источник. Для тех, кто заинтересовался взломом дистрибутива Snefru, этот материал неоценимым. (Также обратитесь к родственному документу относительно дистрибутива с более всесторонним объяснением: A Fast Software One Way Hash Function (Быстрое Программное Обеспечение Односторонней Хеш-функции) Ralph C. Merkle (в конце этой главы в разделе Ресурсы имеется полная ссылка)).

Дистрибутив TAMU всесторонний и может использоваться для решения нескольких проблем безопасности, вплоть до поиска троянских программ. Он включает сетевой монитор и пакетный фильтр.

Ссылка: Дистрибутив TAMU доступен на
ftp://coast.cs.purdue.edu/pub/tools/unix/TAMU/.

ATP (Программа Анти-Вмешательства)

ATP немного более темна, чем TripWire и дистрибутив TAMU, но я не уверен почему. Возможно, потому что она не доступна широко. Фактически, поиски её могут завести Вас за рубеж (один хороший её источник находится в Италии). Во всяком случае, ATP работает несколько подобно TripWire. Как сообщено David Vincenzetti, DSI (Университет Mилана, Италия) в "ATP – Anti-Tampering Program" ("ATP – Программа Анти-Вмешательства"):

ATP 'делает снимок' системы принимая, что Вы находитесь в доверенной конфигурации, и выполняет множество проверок для контроля изменений, которые могли бы быть сделаны в файлах.
Ссылка: "ATP – Программа Анти-Вмешательства" может быть найден на
http://www.cryptonet.it/docs/atp.html.

Затем ATP устанавливает базу данных значений для каждого файла. Одно из этих значений (сигнатура) состоит из двух контрольных сумм. Первое это контрольная сумма CRC32, второе контрольная сумма MD5. Вы можете задаться вопросом, почему именно так, особенно, когда Вы знаете, что контрольные суммы CRC не полностью безопасны или надежны, как было объяснено предварительно. Объясняю: Из-за своей скорости контрольная сумма CRC32 используется в проверках, выполняемых регулярно (возможно ежедневно). MD5, который является более всесторонним (и поэтому требующим больше ресурсов и времени), предназначен для планируемых, периодических проверок (возможно один раз в неделю).

База данных по сообщениям шифруется с использованием DES. Таким образом, ATP обеспечивает гибкий (но весьма защитный) метод контроля вашей сети и идентификации возможных троянских программ.

Ссылка: Документы и дистрибутив ATP могут быть найдены на
ftp://security.dsi.unimi.it/pub/security.

Hobgoblin

Утилита Hobgoblin интересная реализация контроля файловой и системной целостности. Она использует проверку Ondishko Consistency. Авторы документа на Hobgoblin (Farmer и Spafford из Purdue) заявляли, что программа быстрее и конфигурируемее чем COPS и собирают информацию более подробно. Что делает Hobgoblin наиболее интересной, это то, что она является и языком и интерпретатором. Программисты предусмотрели собственные уникальные описатели и структурные соглашения.

Пакет кажется удобным, но имеются некоторые ловушки. Хотя допустимы глобальные соглашения (от csh и от sh/bash), интерпретатор Hobgoblin резервирует знакомые и часто используемые метасимволы, которые имеют специальное значение. Поэтому, если Вы намереваетесь использовать эту утилиту на практике, то должны потратить несколько часов, чтобы ознакомиться с этими соглашениями.

Вобщем Hobgoblin это чрезвычайно мощная утилита для контроля файловых систем. Однако я должен пояснить, что программа была написана специально для систем, расположенных в Университете Rochester, и хотя она была успешно откомпилирована на разнообразных платформах, в вашем случае может так не быть. Особенно, если Вы не используете Sun3, Sun4 или VAX с Ultrix. В этом случае может потребоваться некоторая правка. Кроме того, видно, что Hobgoblin недостает некоторых элементов, представленных в других программах проверки целостности файлов, хотя я полагаю, что программы проверки целостности файлов третьих лиц могут быть интегрированы с Hobgoblin (и их запросы и параметры).

Ссылка: Hobgoblin и её исходник расположены на
ftp://freebsd.cdrom.com/.20/security/coast/tools/unix/hobgoblin/hobgoblin.shar.Z.uu.Z.

На Других Платформах

Вы вероятно задаётесь вопросом, имеются ли такие утилиты для платформы Windows. Случается, что и так, хотя они возможно не как мощны и надежны. Большинство этих утилит используют проверки целостности контрольной суммы и, поэтому, не столь всесторонни, как утилиты, которые используют MD5. Категорически заявляю, большинство из них для платформы Microsoft предназначено для использования в качестве вирусных сканеров.

По этой причине я не перечисляю эти утилиты здесь (их список находится в Главе 14, "Разрушительные Приспособления"). Однако я хочу обратиться к некоторым вещам: Вообще предполагается, что троянские программы проблема безопасности, прежде всего для UNIX и что, когда эта проблема является проблемой Windows, она обычно включает вирус. В этом есть некоторая правда, а так же причины для этого.

До недавнего времени безопасность на IBM аналогах, выполняющих продукты Microsoft, была слаба. Не было никакой необходимости в сложных троянских программах, которые могли захватывать (или иначе собирать) информацию. Таким образом, большинство троянских программ были вирусами, заключенными в противном случае полезные программы (или предположительно полезные). Эта ситуация изменилась.

Должно быть понятно, что троянская программа может быть также легко написана для платформ Microsoft, как и для любой другой. Инструментальные средства разработки для этих платформ это мощные, дружественные приложения (даже VC++ далеко превосходит утилиты компиляции C, сделанные другими фирмами). И теперь, когда среда Windows используется, как материал для Internet сервера, Вы можете ожидать появления троянских программ.

Итог

Люди часто приравнивают троянские кони к вирусным атакам, в то время как это правильно до некоторой степени, но не вся картина. Правда, троянские программы на PC-основанных операционных системах традиционно был связаны с вирусами, но на платформе UNIX полностью другая история. На платформе UNIX взломщики последовательно разработали троянские программы, которые компрометируют безопасность без разрушения данных или включения неавторизованного кода в ту или иную программу.

В любом случае ясно одно: Троянские программы существенный риск для безопасности на любом сервере, а также на машинах, связанных по сети с этим сервером. Поскольку PC-основанные серверы становятся более распространёнными в Internet, должны быть разработаны утилиты (вне уже доступных программ проверки на вирусы), которые могут идентифицировать троянские файлы.

Ресурсы

Дальше Вы найдёте обширный список ресурсов относительно согласования объектов. Некоторые из этих документов связаны с процессом согласования объектов (включая практические примеры), а некоторые связаны с процессом, которым это согласование производится. Все из них были подобраны по релевантности и содержанию. Это основные документы, доступные в пустоте (а также некоторые книги). Я рекомендую, чтобы каждый системный администратор, по крайней мере, получил базовое знание этих методов (без деталей, если фактически не реализовывать процедуры).

"MDx-MAC and Building Fast MACs from Hash Functions." ("MDx-MAC и Создание Быстрых MAC из Хеш-Функций.") Bart Preneel и Paul C. van Oorschot. Crypto 95.

"Message Authentication with One-Way Hash Functions." ("Аутентификация Сообщений Односторонними Хеш-Функциями.") Gene Tsudik. 1992. IEEE Infocom 1992.

"RFC 1446 – 1.5.1. Message Digest Algorithm." ("RFC 1446 – 1.5.1. Алгоритм Обзора Сообщений") Подключение: Энциклопедия Internet.

"Answers To FREQUENTLY ASKED QUESTIONS About Today's Cryptography." ("Ответы На ЧАСТО ЗАДАВАЕМЫЕ ВОПРОСЫ По Современной Криптографии.") Paul Fahn. RSA Laboratories. 1993 RSA Laboratories, подразделение RSA Безопасность Данных.

"The Checksum Home Page." ("Домашняя Страница Checksum.") Macintosh Checksum.

"RFC 1510 – 6. Encryption and Checksum Specifications." ("RFC 1510 – 6. Шифрование и Спецификации Контрольных Сумм.") Подключение: Энциклопедия Internet.

"RFC 1510 – 6.4.5. RSA MD5 Cryptographic Checksum Using DES (rsa-md5des)." ("RFC 1510 – 6.4.5. RSA MD5 Криптографическая Контрольная Сумма, Использующая DES (rsa-md5des).") Подключение: Энциклопедия Internet. J. Kohl. Digital Equipment Corporation, C. Neuman, ISI. Сентябрь 1993.

"Improving the Efficiency and Reliability of Digital Time-Stamping." ("Улучшение Эффективности и Надежности Цифровых Временных Меток.") D. Bayer и S. Haber и W. S. Stornetta. 1992.

"A Proposed Extension to HTTP: Simple MD5 Access Authentication." ("Предложенное Расширение к HTTP: Простая MD5 Аутентификация Доступа.") Jeffery L. Hostetler b Eric W. Sink. 1994.

"A Digital Signature Based on a Conventional Encryption Function." ("Цифровая Подпись, Основанная на Обычной Функции Шифрования.") Ralph C. Merkle. Crypto 87, LNCS, стр. 369-378, SV, Авг. 1987.

"An Efficient Identification Scheme based on Permuted Kernels." ("Эффективная Схема Идентификации, Основанная на Переставленных Ядрах.") Adi Shamir. Crypto 89, LNCS, стр. 606-609, SV, Авг. 1989.

"An Introduction To Digest Algorithms." ("Введение В Алгоритмы Обзора.") Протоколы Общества Компьютерных Пользователей Digital Equipment Австралии, Ross N. Williams. Сент. 1994.

"Data Integrity With Veracity." ("Целостность Данных С Veracity.") Ross N. Williams.

"Implementing Commercial Data Integrity with Secure Capabilities." ("Коммерческая Реализация Целостности Данных с Возможностями Защиты.") Paul A. Karger. SympSecPr. Oakland, CA. 1988. IEEECSP.

"Trusted Distribution of Software Over the Internet." ("Доверенный Дистрибутив Программного Обеспечения По Internet.") Aviel D. Rubin. (Система Bellcore's Trusted Software Integrity (Betsi)). 1994.

"International Conference on the Theory and Applications of Cryptology." ("Международная Конференция по Теории и Приложениям Криптологии.") 1994 Wollongong, N.S.W. Усовершенствования в Криптологии, ASIACRYPT 28 Ноябрь - 1 Декабря, 1994. (Слушания) Берлин и Нью-Йорк. Springer, 1995.

"Managing Data Protection" (Second Edition). ("Управление Защитой Данных" (Второе Издание).) Dr. Chris Pounder и Freddy Kosten, Butterworth-Heineman Limited, 1992.

"Some Technical Notes on S/Key, PGP..." ("Некоторые Технические Примечания к S/Key, PGP...") Adam Shostack.

"Description of a New Variable-Length Key, 64-Bit Block Cipher" (Blowfish). ("Описание Нового Ключа Переменной Длины, 64-разрядного Блочного Шифра" (Blowfish).) Bruce Schneier. Counterpane Systems.

Предыдущая главаСледующая главаСодержание


Macmillan Computer Publishing USA

Macmillan Computer Publishing.


Все мессаги сюда:yanich@inbox.ru
Hosted by uCoz