Реферат: Несанкционированный доступ к терминалам серверов с операционными системами семейства 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)

     

еще рефераты
Еще работы по компьютерным сетям