Реферат: Несанкционированный доступ к терминалам серверов с операционными системами семейства UNIX. На примере octopus.stu.lipetsk.ru
Министерство образования российской федерации
Липецкий государственный технический университет
Кафедра АСОИУИндивидуальноедомашнее задание по дисциплине «Операционные системы»
«Несанкционированныйдоступ к терминалам серверов с операционными системами семейства UNIX. На примере octopus.stu.lipetsk.ru»
Выполнил: Архипов Н.А.
Группа: АС-99-2Принял: Журавлева М.Г.
Липецк 2001ПредисловиеПлан,что и говорить, был превосходный: простой и ясный, лучше не придумаешь.Недостаток у него был только один: было совершенно неизвестно, как привести егов исполнение.
Л. Кэрролл. Алисав стране чудес
В данном отчете мы попытаемся выявить«дыры» и «изъяны» локальной компьютерной сети ЛГТУ (LSTU) в целом и в частности сервера дляизучения операционных систем UNIX– octopus.lstu. Для этого мы расскажем о возможных попыткахполучения доступа к терминалам серверов, в том числе и с правами root’a, а так же попытка перегрузить сервер. Здесь нерассматривается такой вид атаки как «Социальная инженерия», поскольку нашазадача – изучение операционных систем, а не психологии. Сразу предупреждаю, чтона практике не использовалось ни каких деструктивных действий (в томчисле перегрузки сервера), кроме тех действий которые использовались только дляизучения сети. Поэтому, мы ни какой ответственности за использование этогодокумента не несем.
Особенности безопасности компьютерных сетейОсновной особенностьюлюбой сетевой системы является то, что ее компоненты распределены впространстве, а связь между ними осуществляется физически, при помощи сетевыхсоединений (коаксиальный кабель, витая пара, оптоволокнои т. п.), и программно, при помощи механизма сообщений.При этом все управляющие сообщения и данные, пересылаемые между объектамираспределенной вычислительной системы, передаются по сетевым соединениям в видепакетов обмена.
К сетевымсистемам, наряду с обычными(локальными) атаками, осуществляемыми в пределах одной компьютерной системы,применим специфический вид атак, обусловленный распределенностью ресурсов и информации впространстве так называемые сетевые(или удаленные) атаки (remote или network attacks). Онихарактеризуются, во-первых, тем, что злоумышленник может находиться за тысячикилометров от атакуемого объекта, и, во-вторых, тем, что нападению можетподвергаться не конкретный компьютер, а информация, передающаяся по сетевымсоединениям. С развитием локальных и глобальных сетей именно удаленные атакистановятся лидирующими как по количеству попыток, так и по успешности ихприменения, и, соответственно, обеспечение безопасности ВС с точки зренияпротивостояния сетевым атакам приобретает первостепенное значение.
удаленные атаКИ НА ХОСТЫ iNterNet
Многоенаша Земля повидала, Но не видала Такого скандала!
Б. Заходер. Географиявсмятку
Анализсетевого трафика Internet
В Internet базовыми протоколами удаленного доступа являются TELNET и FTP (File Transfer Protocol). TELNET- этопротокол виртуального терминала(ВТ), позволяющий с удаленных хостов подключаться ксерверам Internet в режиме ВТ. FTP — протокол, предназначенный для передачи файлов междуудаленными хостами. Для получения доступа к серверупо данным протоколам пользователю необходимо пройти процедуры идентификации иаутентификации. В качестве информации, идентифицирующей пользователя, <img src="/cache/referats/11316/image002.gif" align=«left» hspace=«12» v:shapes="_x0000_s2091">выступает его имя,а для аутентификации используется пароль. Особенностью протоколов FTP и TELNET является то, чтопароли и идентификаторы пользователей передаются по сети в открытом, незашифрованномвиде. Таким образом, необходимым и достаточным условием для полученияудаленного доступа к хостам по протоколам FTP и TELNET являются имя ипароль пользователя.
Одним из способов получения таких паролей иидентификаторов в Internet является анализсетевого трафика. Этот анализ осуществляется с помощью специальнойпрограммы-анализатора пакетов (sniffer), перехватывающей все пакеты, передаваемые по сегментусети, и выделяющей среди них те, в которых передаются идентификаторпользователя и его пароль. Сетевой анализ протоколов FTP и TELNET показывает, что TELNET разбивает пароль на символы и пересылает их по одному,помещая каждый символ пароля в соответствующий пакет, a FTP, напротив,пересылает пароль целиком в одном пакете.
Возникает вопрос: а почему бы не сделать передачу именипользователя и пароля в зашифрованном виде? Видимо, проблема в том, чтобазовые прикладные протоколы семейства TCP/IP разрабатывались очень давно, впериод с конца 60-х до начала 80-х годов, и с тех пор абсолютно не изменились.При этом точка зрения на построение глобальных сетей стала иной.Инфраструктура Сети и ее протоколы разрабатывались исходя, в основном, изсоображений надежности связи, но не из соображений безопасности.
Таким образом возможно отследить сетевойпоток и выявить пакеты содержащие необходимые данные (Имя, пароль, и т.д.). Таккак в данном документе рассматриваетсятолько сервер ЛГТУ octopus.lstu, тоя проанализировав сеть, пришел к выводу,что сервер не всегда находится в активном состоянии. Таким образом, данныйвариант атаки отпадает, да и еще чтобы постоянно отслеживать трафик,необходимо, чтобы все это время в сети находился хотя бы один компьютер, чтоневозможно из-за финансовых трудностей.
Перебор паролей в файле /etc/passwd
В ранних версиях операционных системахсемейства UNIX зашифрованные пароли (точнее их хэш-копии) хранились в файле /etc/passwd. В современных UNIX’ах пароли хранятся в /etc/shadow.Хранение зашифрованных паролей в /etc/passwd делает систему сервера octopus.lstu уязвимой. Здесь используется хэш-функцияData Encryption Standard (DES 48/64 4K). Поскольку данная шифровка работаеттолько «в одну сторону», а проверка подлинности пароля заключается в том, чтопри вводе пароля пользователя, операционная система шифрует введеннуюпоследовательность и сравнивает ее со строкой в файле /etc/passwd. Вот пример записи паролей и именпользователей в /etc/passwd:
root:LyavHDdahFcwU:0:1:Superuser:/:
…
<img src="/cache/referats/11316/image003.gif" v:shapes="_x0000_s2090"><img src="/cache/referats/11316/image004.gif" v:shapes="_x0000_s2087"><img src="/cache/referats/11316/image004.gif" v:shapes="_x0000_s2084"><img src="/cache/referats/11316/image003.gif" v:shapes="_x0000_s2083"><img src="/cache/referats/11316/image003.gif" v:shapes="_x0000_s2082">malysh:7DnDkTMD9/wG2:1007:25:Olga A. Bocharnikova,AS-98-1:/user/students/as98/malysh:
<img src="/cache/referats/11316/image005.gif" v:shapes="_x0000_s2085 _x0000_s2086"> <img src="/cache/referats/11316/image006.gif" v:shapes="_x0000_s2088 _x0000_s2089">
<div v:shape="_x0000_s2081">
Local profile
<div v:shape="_x0000_s2080">Полное имя
<div v:shape="_x0000_s2079">ID и группа
<div v:shape="_x0000_s2078">Заш. пароль
<div v:shape="_x0000_s2077">User name
Для перебора паролей мы используем тотже метод, что и операционная система: перебираю все возможные комбинации буквлатинского алфавита (причем имеет значение прописная буква или строчная), цифри специальных знаков. Здесь можно использовать как функции самой операционнойсистемы, так и написать свою функцию шифровки. Но нужно быть точно увереннымчто за алгоритм используется в данном случае, иначе перебор не приведет ни ккаким результатам. На компьютере octopus используется алгоритм шифрования DES [48/64 4K]. Так как на octopus’e столь неважные, по сегодняшним меркам,аппаратные средства (см. следующий пункт), то ни о каком переборе пароля неможет идти и речи. Тем более, даже на более быстрых машинах (Pentium III – 650MHz) расшифровка заняла примерно 30 суток(!!!). Да и сервер не все время находится в рабочем состоянии, как уже былозамечено выше. В отчете прилагается часть программы, для расшифровки паролейфайла /etc/passwd.
Denyof Service (DoS) атака.
Дословно Deny of Service переводится как «отказ в обслуживании».Это означает например, что операционная система не может обслужить запроспользователя или другой системы.
Рассмотримнарушение работоспособности хоста в сети при использованиинаправленного шторма ложных TCP-запросов на создание соединения либо припереполнении очереди запросов. Из рассмотренной впредыдущем пункте схемы создания TCP-соединения следует, что на каждыйполученный TCP-запрос (TCP SYN) операционная система должна сгенерировать начальноезначение идентификатора ISN и отослать его на запросивший хост.Но так как в Internet (стандарта IPv4) не предусмотрен контроль за IP-адресом отправителясообщения, то проследить истинный маршрут, пройденный IP-пакетом, невозможно и,следовательно, у конечных абонентов сети нет способа ограничить число запросов,принимаемых в единицу времени от одного хоста.Поэтому возможно осуществление типовой удаленной атаки «отказ в обслуживании»,которая будет заключаться в передаче на объект атаки как можно большего числаложных TCP-запросов на создание соединения от имени любого хостав сети (направленный шторм запросов TCP SYN, схема которого приведена на рисунке).
<img src="/cache/referats/11316/image008.gif" v:shapes="_x0000_s2092">
При этом атакуемая сетевая ОС в зависимости отвычислительной мощности компьютера либо перестает реагировать на легальные запросына подключение (отказ в обслуживании), либо, в худшем случае, практически зависает. Это происходит потому, чтосистема должна, во-первых, сохранить в памяти полученную в ложных сообщенияхинформацию и, во-вторых, выработать и отослать ответ на каждый запрос. Такимобразом, «съедаются» все ресурсы системы: переполняется очередь запросов, и ОСвынуждена заниматься только их обработкой. Эффективность данного воздействиятем выше, чем больше пропускная способность канала между атакующим и его целью,и тем ниже, чем больше вычислительная мощность атакуемого компьютера (число ибыстродействие процессоров, объем ОЗУ и т.п.).
Такую атаку можнобыло предсказать еще лет двадцать назад, когда появилось семейство протоколов TCP/IP: ее корни находятся в самой инфраструктуресети Internet, в ее базовых протоколах — IP и TCP. Но каково жебыло наше удивление, когда выяснилось, что на информационном. WWW-сервере CERT (Computer Emergency Respone Team) первое упоминание об удаленном воздействии такого родадатировано только 19 сентября 1996 года! Там эта атака носила название «TCP SYN Flooding and IP Spoofing Attacks» («наводнение» TCP-запросами с ложных IP-адресов).Другая разновидность атаки «отказ в обслуживании» состоит в передаче наатакуемый хост нескольких десятков (сотен) запросов TCP SYN в секунду (направленный мини-шторм TCP-запросов)на подключение к серверу, что может привести к временному (до 10 минут)переполнению очереди запросов на сервере (см. атаку К. Митника).Это происходит из-за того, что некоторые сетевые ОС обрабатывают только первыенесколько запросов на подключение, а остальные игнорируют, Таким образом,получив N запросов на подключение, ОС сервераставит их в очередь и генерирует соответственно N ответов. Затем в течениеопределенного промежутка времени (тайм-аут < 10 минут) сервер будет дожидатьсясообщения от предполагаемого клиента, чтобы завершить handshake и подтвердить создание виртуального канала с сервером. Если атакующийпришлет такое количество запросов на подключение, которое равно максимальномучислу одновременно обрабатываемых сервером сообщений, то в течение тайм-аутаостальные запросы будут игнорироваться и установить связь с сервером неудастся.
Мыпровели ряд экспериментов с направленным штормом и направленным миништормом запросов на различных по вычислительным мощностямкомпьютерах с разными операционными системами.
Тестированиенаправленным штормом запросов TCP SYN, проводимое на различных сетевых ОС в экспериментальных10-мегабитных сегментах сети, дало следующие результаты: все описанные далееатаки осуществлялись по определенной методике. Подготавливался TCP-запрос,который при помощи специально разработанной собственной программы в циклепередавался в сеть с соответствующими задержками (вплоть до нулевой) между запросами.При этом циклически изменялись такие параметры запроса, как порт отправителя изначение 32-битного идентификатора SYN. IP-адрес отправителя запроса былвыбран так, чтобы, во-первых, этот хост в настоящиймомент не был активен в сети и, во-вторых, чтобы соответствующий маршрутизатор, в чьей зоне ответственности находится данныйхост, не присылал сообщения Host Unreachable (Хост недоступен). В противном случае хост,от имени (с IP-адреса) которого посылался запрос TCP SYN, получив «неожиданный» ответ TCP АСК от атакуемого сервера, перешлет на него пакет TCP RST, закрывая такимобразом соединение.
При передаче поканалу связи максимально возможного числа TCP-запросов и при нахождении кракера в одном сегменте с объектом атаки атакуемыесистемы вели себя следующим образом: ОС Windows 95, установленная на 486DX2-66 с 8 Мб ОЗУ,«замирала» и переставала реагировать на любые внешние воздействия (в частности,нажатия на клавиатуру); ОС Linux 2.0.0 на 486DX4-133 с 8 Мб ОЗУ также практически не функционировала,обрабатывая одно нажатие на клавиатуре примерно 30 секунд. В результате к этим хостам невозможно было получить не только удаленный, но илокальный доступ.
Неменее интересным было поведение атакуемых систем после снятия воздействия: ОС Windows 95 практически сразу же после прекращения атаки началанормально функционировать; в ОС Linux 2.0.0 с 8 Мб ОЗУ,по-видимому, переполнился буфер, и более получаса система не функционировалани для удаленных, ни для локальных пользователей, а занималась только передачейответов на полученные ранее запросы. CyberGuard сразу же после снятия воздействия стал доступным дляудаленного доступа.
Если кракер находился в смежных сегментах с объектом, то вовремя атаки ОС Windows 95 на Pentium 100 с 16 Мб ОЗУ обрабатывала каждое нажатие склавиатуры примерно секунду, ОС Linux 2.0.0 на Pentium 100 с 16 Мб ОЗУ практически «повисала» — одно нажатиеза 30 секунд, зато после снятия воздействия нормальная работа возобновлялась.
Ненужно обманываться, считая, что ОС Windows 95 показала себя случшей стороны. Такой результат объясняется следующим: Windows 95 — операционная система, не имеющая FTP-сервера, а следовательно, ейне нужно было сохранять в памяти параметры передаваемого TCP-запроса наподключение к этому серверу и дожидаться окончания handshake.
Таким образом,учитывая аппаратные средства сервера octopus.lstu (Olivetti 80286) можно без труда осуществить на него DoS атаку. Даже если локальная сеть будет загружена. Можно предположить, чтои остальные сервера университета могут быть «обездвижены» таким способом.Например сервер кафедры прикладной математики: IBM 486DX66 16RAM. По аппаратной части серверы кафедры АСУ (здесь не имеется ввиду octopus.lstu) более устойчивы к DoS атаке.
Превышениемаксимально возможного размера IP-пакета, или Ping Death
Вмаксимальный размер IP-пакета (65 535 байт) включаются длина IP-заголовка идлина ноля данных в IP-пакете. Так как минимальный размер IP-заголовка — 20байт (максимальный — 60), то соответственно размер данных, передаваемых водном IP-пакете, не может превышать 65 535- 20 = 65 515 байт. А что будет, еслипревысить это число? Тестировать свои программы на предельных критическихзначениях -стандартный для любого программиста ход. Подобные тесты позволяютвыявить такие неприятные ошибки, как всевозможные переполнения (буфера, стека,переменной и т. д.). Но вернемся к IP. В принципе ничтоне мешает атакующему сформировать набор фрагментов, которые после сборкипревысят максимально возможный размер IP-пакета. Собственно в этой фразе исформулирована основная идея данной атаки.
Итак, 18 декабря 2000 года на информационном сервереСЕКТ появились сообщения о том, что большинство сетевых операционных систем,поддерживающих протоколы TCP/IP, обладают следующей уязвимостью: при передаче на нихIP-пакета длиной, превышающей максимально допустимое значение, в этих ОСпереполняется буфер или переменная, в результате система «зависает» илиперезагружается, то есть налицо отказ в обслуживании. Был приведен и списокпотенциально опасных платформ:
• Berkeley Software Design, Inc. (BSD);
• Computer Associates, Intl. (products for NCR);
• Cray Research;
• Digital Equipment Corporation;
• FreeBSD, Inc.; 'Hewlett-Packard Company;
• IBM Corporation;
• Linux Systems;
• NEC Corporation;
• Open Software Foundation (OSF);
• The Santa Cruz Operation, Inc. (SCO);
• Sun Microsystems, Inc.
Мы судивлением прочитали этот перечень операционных систем на различных платформах,а потом принялись за эксперименты. Наше глубочайшее изумление вызвал тот факт,что элементарную ошибку переполнения буфера в модуле IP ядра ОС за почти 20 лет активного функционирования протокола IP разработчики сегодняшних систем до сих пор не замечали.Поэтому мы позволили себе не поверить столь уважаемой организации, как CERT. Но прежде чем начать эксперименты, было решенопосмотреть по указанной в CERT ссылке (http://www.sophist.demon.co.uk/ping) на WWW-сервер,где экспертами проводились подобные исследования на различных ОС. НаWWW-сервере предлагалось реализовать такое воздействие следующим образом: необходимовыполнить на рабочей станции с ОС Windows 95 или Windows NT следующую команду: ping -l 65527 victim.destination.IP.address (по этой командеатака и получила свое название — Ping Death).
Таккак обычный размер IP-заголовка составляет 20 байт, а размер 1СМР-заголовка — 8байт, то подобный ICMP-пакет будет превышать максимально возможный размерIP-пакета на 20 байт: 65 527 +20+8-65 535 =20.
Основываясьна приведенном расчете, эти «эксперты» декларировали, что обычной командой ping можно нарушить работоспособность практически любойсетевой ОС. В завершение предлагалась следующая таблица тестирования различныхоперационных систем
Операционная система Версия ПОСимптомы
Solaris (x86)
2.4, 2.5, 2.5.1
Перезагрузка
Minix
1.7.4, v2.0 и другие
Сбой
HP3000 MPE/iX
4.0, 5.0, 5.5
Сброс системы
Convex SPP-UX
Все версии
Сбой
Apple Mac
MacOs 7.x.x
Сбой
Windows 3.11 with Trumpet winsock
?
Смешанные отчеты
Novell Netware
3.x
Смешанные отчеты
Windows 95
Все версии
Сбой
AIX
3 и 4
Сброс системы
Linux
2.0.23
Спонтанная перезагрузка или зависание (kernel panic)
DEC UNIX / OSF1
2.0 и выше
зависание (kernel panic)
Open VMS for AXP
Различные
Смешанные отчеты
HP-UX
9.0 по 10.20
Сбой, перезагрузка, зависание.
Windows NT
3.5.1
Смешанные результаты
Irix
5.3
зависание (kernel panic)
Windows NT
4
Сбой
SCO Openserver
4.2, 5.0.x
Уязвима
DEC TOPS-20, TOPS-10
Все
Ошибки
Digital Firewall
?
Уязвима
AltaVista Firewall for UNIX
?
Уязвима
(здесьона приводится в сокращении), на которые данная удаленная атака якобыпроизвела необходимый эффект. Итак, мы начали тестирование и, честно говоря,абсолютно не удивились, когда исследуемые ОС — IRIX, AIX, VMS, SunOs, FreeBSD, Linux, Windows NT 4.0, даже Windows 95 и Windows for WorkGroups 3.11- абсолютно не реагировали на подобный некорректныйзапрос, продолжая нормально функционировать. Тогда были предпринятыспециальные поиски операционной системы, которую бы действительно вывела изстроя данная атака. Ей оказалась Windows 3.11 с WinQVT — эта ОС действительно «зависла».
Этим«экспертам», которым столь доверяют CERT и С1АС, мыпослали запрос, где попросили прояснить возникшую ситуацию, а также уточнитьсведения из вышеприведенной таблицы. В полученном нами ответе говорилось, чтоуспех данной атаки зависит от многих факторов, а именно: программного иаппаратного обеспечения, установленного на компьютере, и, самое главное, отфазы Луны. Как говорится, без комментариев. Для полноты картины мы хотели быпривести описание exploit, созданного для Windows NT 4.0, задача которого, используя ping, «завесить» собственныйкомпьютер (!). Сначала предлагалось запустить Web Browser, затем-taskmgr (Task Manager): так Ping Death якобы лучшеработает (еще не хватает шаманского бубна!). И наконец, требовалось запустить18 ping-процессов (почему не 100?). Если вы думаете, что после всего этоговаша ОС немедленно «повиснет», то ошибаетесь! В комментариях к exploit до получения эффекта предлагалось ждать примерно 10минут, а может быть, несколько больше или несколько меньше.
Можно сделать вывод, что опасения по поводу данноговоздействия ни на чем не основаны, и нам остается только назвать эту атакуочередной программистской байкой и причислить ее к разряду практически неосуществимых.
причины усПЕХА УДАЛЕННЫХ АТАК
«То, что изобретено одним человеком,
может быть понято другим», — сказал Холме.
А. Конан Доил. Пляшущие человечки· Использование нестойких алгоритмов идентификации
К сожалению, взаимодействие объектов повиртуальному каналу в распределенной ВС не является панацеей от всех проблем,связанных с идентификацией объектов РВС. ВК — необходимое, но не достаточноеусловие безопасного взаимодействия. Чрезвычайно важным в данном случае становитсявыбор алгоритма идентификации при создании виртуального канала. Основноетребование, предъявляемое к этим алгоритмам, состоит в следующем: перехватключевой информации, которой обмениваются объекты РВС при создании ВК, недолжен позволить атакующему получить итоговые идентификаторы канала иобъектов. Однако в базовых алгоритмах идентификации, используемых при созданииВК в большинстве существующих сетевых ОС, это требование практически неучитывается.
· Отсутствие контроля завиртуальными каналами связи
Объекты распределенной ВС, взаимодействующиепо виртуальным каналам, могут подвергаться типовой атаке «отказ вобслуживании». Особенность этого воздействия состоит в том, что, действуяабсолютно легальными средствами системы, можно удаленно добиться нарушения ееработоспособности. В чем причина успеха данной атаки? В отсутствии необходимогоконтроля над соединением. При этом задача контроля распадается на двеподзадачи:
• контроль за созданием соединения;
• контроль за использованием соединения.
Если пути решениявторой задачи понятны — обычно соединение разрывается по тайм-ауту,определенному системой, — так сделано во всех известных сетевых ОС (однако тутвозникает серьезная проблема выбора конкретного значения тайм-аута), токонтроль за созданием ВК достаточно сложен: в системе, где отсутствуетстатическая ключевая информация обо всех ее объектах, невозможно отделитьложные запросы на создание соединения от настоящих. Очевидно также, что еслиодин субъект сетевого взаимодействия будет иметь возможность анонимно занимать неограниченноечисло каналов связи с удаленным объектом, то подобная система может бытьполностью парализована данным субъектом. Таким образом, если любой объект враспределенной системе способен анонимно послать сообщение от имени другогообъекта (например, в Internet маршрутизаторы не проверяют IP-адрес отправителя), то вподобной распределенной ВС практически невозможен контроль за созданиемвиртуальных соединений. Поэтому основная причина типовой угрозы «отказ вобслуживании» — это отсутствие приемлемого решения задачи контроля за маршрутомсообщений.
· Отсутствие возможностиконтролировать маршрут сообщений
Если вРВС не предусмотреть контроля за маршрутом сообщения, то адрес отправителясообщения оказывается ничем не подтвержденным. Таким образом, в системе будетсуществовать возможность работы от имени любого объекта путем указания взаголовке сообщения чужого адреса отправителя (IP Spoofing). В подобной РВСзатруднительно определить, откуда на самом деле пришло сообщение, аследовательно — вычислить координаты атакующего (в Internet невозможно найти инициатора однонаправленной удаленной атаки).
· Отсутствие полной информацииоб объектах РВС
В распределенной системе сразветвленной структурой, состоящей из большого числа объектов, можетвозникнуть ситуация, когда для доступа к определенному хостуу субъекта взаимодействия не окажется необходимой информации, то есть адресаданного объекта. Очевидно, что всистеме подобного типа существует потенциальная опасность внесения ложногообъекта и выдачи одного объекта за другой путем передачи ложного ответа напоисковый запрос.
· Отсутствие криптозащитысообщений
В распределенных ВС связь между объектамисистемы осуществляется по виртуальным каналам связи, а следовательно, хакеримеет принципиальную возможность прослушать канал, получив несанкционированныйдоступ к информации, которой обмениваются по сети се абоненты. Если этаинформация не зашифрована, то возникает угроза атаки типа «анализ сетевоготрафика».
· Отсутствие выделенного каналасвязи между объектами сети Internet
Глобальная сеть не может быть построена по принципу прямой связи междуобъектами, поскольку для каждого объекта невозможно обеспечить вы деленныйканал связи с любым другим объектом. Поэтому в Internet связь осуществляется через цепочку маршрутизаторов, а следовательно, сообщение, проходя черезбольшое количество промежуточных подсетей, может быть перехвачено. Также к Internet подключено большое число локальныхEthernet-сетей, использующих топологию «общая шина»; в сетях с такой
топологией несложно программно осуществлятьперехват сообщений.
· Недостаточные идентификация иаутентификация
В базовых протоколах обмена идентификация иаутентификация объектов практически отсутствуют. Так, например, в прикладныхпротоколах. FTP, TELNET, РОРЗ имена и пароли пользователей передаются по сети ввиде открытых незашифрованных сообщений.
· Использование нестойких алгоритмов идентификацииобъектов при создании виртуального TCP-соединения
Как уже подчеркивалось, протокол TCP является единственным базовым протоколом транспортногоуровня, в функции которого заложена защита соединения. Однако использованиепростейшего алгоритма идентификации объектов при создании виртуальногоTCP-канала, особенно при условии применения в сетевых ОС простейших времязависимых законов генерации TCP-идентификаторов (ISN), сводит на нет все попытки обеспечения идентификацииканала и объектов при их взаимодействии по протоколу TCP.
· Отсутствие криптозащиты сообщений
В существующих базовых протоколах семейства TCP/IP, обеспечивающих взаимодействие насетевом и транспортном уровнях, не предусмотрена возможность шифрованиясообщений, хотя очевидно, что добавить ее в протокол TCP не составляло труда. Разработчики решили переложить задачу криптозащитына протоколы более высоких уровней, например прикладного уровня. При этомбазовые протоколы прикладного уровня (FTP, TELNET, HTTP и др.) также непредусматривали никакого шифрования сообщений. Только не так давно появилсяобщедоступный прикладной протокол SSL, встроенный в Netscape Navigator, позволяющий какнадежно зашифровать сообщение, так и подтвердить его подлинность. В заключениехотелось бы заметить, что все описанные выше причины, по которым возможнауспешная реализация угроз безопасности РВС, делают сеть Internet небезопасной. А следовательно, все пользователи сетимогут быть атакованы в любой момент.
<img src="/cache/referats/11316/image010.gif" v:shapes="_x0000_s2095">Подведем итоги.
Учитывая все вышесказанное, я думаю, что студентам кафедры АСОИУ ужесейчас не представляется никакой сложности для несанкционированного доступа ктерминалам серверов с правами администраторов (причем это не необоснованноевысказывание). Другой вопрос – целесообразности всего этого. Я думаю что нестоит проверять все вышесказанное на практике в целях своей же безопасности.
В целом, вычислительная сеть университета администрируетсявесьма неплохо, нужно отдать должное системным администраторам. На серверахстоят последние версии операционных систем. Однако на chuck.stu.lipetsk.ru почему-то у обычных пользователей нетправ на компилирование Си программ. Почему? Может это и есть слабое звено вадминистрировании, или это еще одна предосторожность администратора? Хотя на tomcat.am.lstu обычным смертным разрешено…
Вообще-то взлом octopus.stu.lipetsk.ru был бы неуважениемсвоей же кафедры. Ведь та защита которая там присутствует направлена не длятого, чтобы предотвратить проникновение злоумышленника, а для элементарнойзащиты от неопытных пользователей.
ПРИЛОЖЕНИЕ.
В целях безопасности, приводим толькофрагменты программы. Файл john.c
#include <stdio.h>
#include <string.h>
#include <stdlib.h>
#include <sys/stat.h>
#include «arch.h»
#include «misc.h»
#include «params.h»
#include «path.h»
#include «memory.h»
#include «list.h»
#include «tty.h»
#include «signals.h»
#include «idle.h»
#include «common.h»
#include «formats.h»
#include «loader.h»
#include «logger.h»
#include «status.h»
#include «options.h»
#include «config.h»
#include «bench.h»
#include «charset.h»
#include «single.h»
#include «wordlist.h»
#include «inc.h»
#include «external.h»
#include «batch.h»
#if CPU_DETECT
extern int CPU_detect();
#endif
extern struct fmt_main fmt_DES, fmt_BSDI, fmt_MD5, fmt_BF;
extern struct fmt_main fmt_AFS, fmt_LM;
extern int unshadow(int argc,char **argv);
extern int unafs(int argc,char **argv);
extern int unique(int argc, char **argv);
static struct db_main database;
static struct fmt_main dummy_format;
static void john_register_one(struct fmt_main *format)
{
if(options.format)
if(strcmp(options.format,format->params.label)) return;
fmt_register(format);
}
static void john_register_all()
{
if(options.format) strlwr(options.format);
john_register_one(&fmt_DES);
john_register_one(&fmt_BSDI);
john_register_one(&fmt_MD5);
john_register_one(&fmt_BF);
john_register_one(&fmt_AFS);
john_register_one(&fmt_LM);
if(!fmt_list) {
fprintf(stderr, «Unknown ciphertext format name requestedn»);
error();
}
}
static void john_load()
{
struct list_entry *current;
umask(077);
if(options.flags & FLG_EXTERNAL_CHK)
ext_init(options.external);
if(options.flags & FLG_MAKECHARS_CHK) {
options.loader.flags |= DB_CRACKED;
ldr_init_database(&database, &options.loader);
if(options.flags & FLG_PASSWD) {
ldr_show_pot_file(&database, LOG_NAME);
database.options->flags |= DB_PLAINTEXTS;
if((current = options.passwd->head))
do{
ldr_show_pw_file(&database, current->data);
}while ((current = current->next));
}else {
database.options->flags |= DB_PLAINTEXTS;
ldr_show_pot_file(&database, LOG_NAME);
}
return;
}
if(options.flags & FLG_STDOUT) {
ldr_init_database(&database, &options.loader);
database.format = &dummy_format;
memset(&dummy_format, 0, sizeof(dummy_format));
dummy_format.params.plaintext_length = options.length;
dummy_format.params.flags = FMT_CASE | FMT_8_BIT;
}
if(options.flags & FLG_PASSWD) {
if(options.flags & FLG_SHOW_CHK) {
options.loader.flags |= DB_CRACKED;
ldr_init_database(&database, &options.loader);
ldr_show_pot_file(&database, LOG_NAME);
if((current = options.passwd->head))
do{
ldr_show_pw_file(&database, current->data);
}while ((current = current->next));
printf("%s%d password%s cracked, %d leftn",
database.guess_count? «n»: "",
database.guess_count,
database.guess_count != 1? «s»: "",
database.password_count -
database.guess_count);
return;
}
if(options.flags & (FLG_SINGLE_CHK |FLG_BATCH_CHK))
options.loader.flags |= DB_WORDS;
else
if(mem_saving_level)