Курсовая: Несанкционированный доступ к терминалам серверов с операционными системами семейства UNIX - текст курсовой. Скачать бесплатно.
Банк рефератов, курсовых и дипломных работ. Много и бесплатно. # | Правила оформления работ | Добавить в избранное
 
 
   
Меню Меню Меню Меню Меню
   
Napishem.com Napishem.com Napishem.com

Курсовая

Несанкционированный доступ к терминалам серверов с операционными системами семейства UNIX

Банк рефератов / Компьютерные сети

Рубрики  Рубрики реферат банка

закрыть
Категория: Курсовая работа
Язык курсовой: Русский
Дата добавления:   
 
Скачать
Microsoft Word, 1893 kb, скачать бесплатно
Заказать
Узнать стоимость написания уникальной курсовой работы

Узнайте стоимость написания уникальной работы

Министерство образования российской федерации Липецкий государственный технический университет Кафедра АСОИУ Индивидуальное домашнее задание по дисциплине «Операционные сист емы» «Несанкционированный доступ к терминалам серверов с операционными системами семейства UNIX . На примере octopus . stu . lipetsk . ru » Выполнил : Архипов Н.А. Группа : АС -99-2 Принял : Журавлева М.Г. Липецк 2001 Предисловие План , что и говорить , был превосходный : простой и ясный , лучше не придумаешь . Недостаток у него был только один : было совершенно неизвестно , как привести его в исполнение. Л . Кэрролл . Алиса в стране чудес В данном отчете мы попытаемся выявить «дыры» и «изъяны» локальной компьютерной сети ЛГТУ ( LSTU ) в целом и в частности сервера для изучения операционных систем UNIX – octopus . lstu . Для этого мы расскажем о возможных попытках получения доступа к терминалам серверов , в том числе и с правами roo t ’ a , а так же попытка перегрузить сервер . Здесь не рассматривается такой вид атаки как «Социальная инженерия» , поскольку наша задача – изучение операционных систем , а не психологии . Сразу предупреждаю , что на практике не использовалось ни каких деструктив ных действий (в том числе перегрузки сервера ), кроме тех действий которые использовались только для изучения сети . Поэтому , мы ни какой ответственности за использование этого документа не несем . Особенности безопасности компьютерных сетей Основной особе нностью любой сетевой системы является то , что ее ком поненты распределены в пространстве , а связь между ними осуществляет ся физически , при помощи сетевых соединений (коаксиальный кабель , витая пара , оптоволокно и т . п .), и п рограммно , при помощи механизма со общений . При этом все управляющие сообщения и данные , пересылаемые между объектами распределенной вычислительной системы , передаются по сетевым соединениям в виде пакетов обмена. К сетевым системам , наряду с обычными (лок альными ) атаками , осуще ствляемыми в пределах одной компьютерной системы , применим специфи ческий вид атак , обусловленный распределенностью ресурсов и информа ции в пространстве так называемые сетевые (или удаленные ) атаки ( re mote или network attacks ). Они характеризуются , во-первых , тем , что злоумышленник может находиться за тысячи километров от атакуемого объекта , и , во-вторых , тем , что нападению может подвергаться не конкрет ный компьютер , а информация , передающаяся по сетев ым соединениям . С развитием локальных и глобальных сетей именно удаленные атаки стано вятся лидирующими как по количеству попыток , так и по успешности их применения , и , соответственно , обеспечение безопасности ВС с точки зре ния противостояния сетевым ата к ам приобретает первостепенное значение. удаленные атаКИ НА ХОСТЫ iNterNet Многое наша Земля повидала , Но не видала Такого скандала ! Б . Заходер . География всмятку Анализ сетевого трафика Internet В Internet базовыми протоколами удаленного доступа являются T ELNET и FTP ( File Transfer Protocol ). TELNET - это протокол виртуального тер минала (ВТ ), позволяющий с удаленных хостов подключаться к серверам Internet в режиме ВТ . FTP - протокол , предназначенный для передачи файлов между удаленными хостами . Для получен ия доступа к серверу по данным протоколам пользователю необходимо пройти процедуры иденти фикации и аутентификации . В качестве информации , идентифицирующей пользователя , выступает его имя , а для аутентификации используется па роль . Особенностью протоколов 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 4 K ). Поскольку данная шифровка работает тольк о «в одну сторону» , а проверка подлинности пароля заключается в том , что при вводе пароля пользователя , операционная система шифрует введенную последовательность и сравнивает ее со строкой в файле / etc / passwd . Вот пример записи паролей и имен пользователей в / etc / passwd : root:LyavHDdahFcwU:0:1:Superuser:/: … malysh:7DnDkTMD9/wG2:1007:25:Olga A. Bocharnikova, AS-98-1:/user/students/as98/malysh: Для перебора п аролей мы используем тот же метод , что и операционная система : перебираю все возможные комбинации букв латинского алфавита (причем имеет значение прописная буква или строчная ), цифр и специальных знаков . Здесь можно использовать как функции самой операцио н ной системы , так и написать свою функцию шифровки . Но нужно быть точно уверенным что за алгоритм используется в данном случае , иначе перебор не приведет ни к каким результатам . На компьютере octopus используется алгоритм шифрования DES [48/64 4 K ]. Так как на octopus ’ e столь неважные , по сегодняшним меркам , аппаратные средства (см . следующий пункт ), то ни о каком переборе пароля не может идти и речи . Тем более , даже на более быстрых машинах ( Pentium III – 650 MHz ) расшифровка заняла примерно 30 суток (!!!). Д а и сервер не все время находится в рабочем состоянии , как уже было замечено выше . В отчете прилагается часть программы , для расшифровки паролей файла / etc / passwd . Deny of Service (DoS) атака . Дословно Deny of Service переводится как «отказ в обслужива нии» . Это означает например , что операционная система не может обслужить запрос пользователя или другой системы . Рассмотрим нарушение работоспособности хоста в сети при ис пользовании направленного шторма ложных TCP-запросов на создание соединения либо пр и переполнении очереди запросов . Из рассмотренной в предыдущем пункте схемы создания TCP-соедине ния следует , что на каждый полученный TCP-запрос ( TCP SYN ) операци онная система должна сгенерировать начальное значение идентификатора ISN и отослать его на з апросивший хост . Но так как в Internet (стандарта IPv 4) не предусмотрен контроль за IP-адресом отправителя сообщения , то проследить истинный маршрут , пройденный IP-пакетом , невозможно и , следовательно , у конечных абонентов сети нет способа ограничить число запросов , принимаемых в единицу времени от одного хоста . Поэтому возможно осуществление типовой удаленной атаки «отказ в обслужива нии» , которая будет заключаться в передаче на объект атаки как можно большего числа ложных TCP-запросов на создание соедине н ия от имени любого хоста в сети (направленный шторм запросов TCP SYN , схема ко торого приведена на рисунке ). При этом атакуемая сетевая ОС в зависимости от вычислительной мощности компьютера либо перестает реагиро вать на легальные запросы на подключение (отказ в обслуживании ), либо , в худшем случае , практически зависает . Это происходит потому , что система должна , во-первых , сохранить в памяти полученную в ложных сообщениях информацию и , во-вторых , выработать и отослать о т вет на каждый запрос . Таким образом , «съедаются» все ресурсы системы : переполняется очередь запросов , и ОС вынуждена заниматься только их обработкой . Эф фективность данного воздействия тем выше , чем больше пропускная способность канала между атакующим и е г о целью , и тем ниже , чем больше вычислительная мощность атакуемого компьютера (число и быстродействие процессоров , объем ОЗУ и т.п .). Такую атаку можно было предсказать еще лет двадцать назад , когда по явилось семейство протоколов 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, установ ленная на 486 DX 2-66 с 8 Мб ОЗУ , «замирала» и переставала реагировать на любые внешние воздействия (в частности , нажатия на клавиатуру ); ОС Linux 2.0.0 на 486 DX 4-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 486 DX 66 16 RAM . По аппаратной части серверы кафедры АСУ (здесь не имеется ввиду 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, v 2.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 и Wind ows for WorkGroups 3.11- абсолютно не реагировали на подобный некоррект ный запрос , продолжая нормально функционировать . Тогда были пред приняты специальные поиски операционной системы , которую бы дей ствительно вывела из строя данная атака . Ей оказалась W indows 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 небезопасной . А следовательно , все пользователи сети могут быть атакованы в любой момент. Подведем итоги. Учитывая все вышесказанное , я думаю , что студе нтам кафедры АСОИУ уже сейчас не представляется никакой сложности для несанкционированного доступа к терминалам серверов с правами администраторов (причем это не необоснованное высказывание ). Другой вопрос – целесообразности всего этого . Я думаю что не ст о ит проверять все вышесказанное на практике в целях своей же безопасности . В целом , вычислительная сеть университета администрируется весьма неплохо , нужно отдать должное системным администраторам . На серверах стоят последние версии операционных систем. Однако на 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" #i nclude "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 requested\n"); error(); stati c 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.l oader); 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 left\n", database.guess_count ? "\n" : "", database.guess_count, database.guess_count != 1 ? "s" : "", database.password_count - database.guess_count); retu rn; if (options.flags & (FLG_SINGLE_CHK | FLG_BATCH_CHK)) options.loader.flags |= DB_WORDS; else if (mem_saving_level) options.loader.flags &= ~DB_LOGIN; ldr_init_database(&database, &options.loader); if ((current = options.passwd->he ad)) do ldr_load_pw_file(&database, current->data); while ((current = current->next)); ldr_load_pot_file(&database, LOG_NAME); ldr_fix_database(&database); printf("Loaded %d password%s%s", database.password_count, database.password_count != 1 ? "s" : "", database.password_count ? "" : ", exiting..."); if (database.password_count > 1) printf(" with "); printf(database.salt_count != 1 ? "%d" : "no", database.salt_count); printf(" different salts"); if (database.password_count) printf(" (%s [%s])\n", database.format->params.format_name, database.format->params.algorithm_name); else putchar('\n'); if ((options.flags & FLG_PWD_REQ) && !database.salts) exit(0); static void john_init(int argc, char **argv) #if CPU_DETECT if (!CPU_detect()) #if CPU_REQ fprintf(stderr, "Sorry, %s is required\n", CPU_NAME); error(); #endif #endif path_init(argv); cfg_init(CFG_NAME); status_init(NULL, 1); opt_init(argc, argv); john_register_all(); common_init(); sig_init(idle_yield); john_load(); static void john_run() if (options.flags & FLG_TEST_CHK) benchmark_all(); else if (options.flags & FLG_MAKECHARS_CHK) do_makechars(&database, options.charset); else if (options.flags & FLG_CRACKING_CHK) if (!(options.flags & FLG_STDOUT)) log_init(LOG_NAME); tty_init(); if (options.flags & FLG_SINGLE_CHK) do_single_crack(&database); else if (options.flags & FLG_WORDLIST_CHK) do_wordlist_crack(&databa se, options.wordlist, (options.flags & FLG_RULES) != 0); else if (options.flags & FLG_INC_CHK) do_incremental_crack(&database, options.charset); else if (options.flags & FLG_EXTERNAL_CHK) do_external_crack(&database); else if (options .flags & FLG_BATCH_CHK) do_batch_crack(&database); status_print(); tty_done(); if (!(options.flags & FLG_STDOUT)) log_done(); static void john_done() path_done(); check_abort(); int main(int argc, char **argv) char *name; #ifdef __DJGPP__ if (--argc <= 0) return 1; if ((name = strrchr(argv[0], '/'))) strcpy(name + 1, argv[1]); name = argv[1]; argv[1] = argv[0]; argv++; #else if (!argv[0]) name = ""; else if ((name = strrchr(argv[0], '/'))) name++; else name = argv[0]; #endif #ifdef __CYGWIN32__ if (strlen(name) > 4) if (!strcmp(strlwr(name) + strlen(name) - 4, ".exe")) name[strlen(name) - 4] = 0; #endif if (!strcmp(name, "john")) john_init(argc, argv); john_run(); john_done(); return 0; if (!strcmp(name, "unshadow")) return unshadow(argc, argv); if (!strcmp(name, "unafs")) return unafs(argc, argv); if (!strcmp(name, "unique")) return unique(argc, argv); fprintf(stderr, "Sorry, I can't find myself\n"); return 1; Файл des_b s.c #include #include "arch.h" #include "DES_std.h" #include "DES_bs.h" DES_bs_combined DES_bs_all; int DES_bs_mem_saving = 0; extern void DES_bs_body(); void DES_bs_init() int index, bit; for (index = 0; index < 0x300; index++) bit = DES_K_bits[index]; bit -= bit >> 3; DES_bs_all.Kp[index] = &DES_bs_all.K[55 - bit]; void DES_bs_set_salt(ARCH_WORD salt) register int src, dst; register ARCH_WORD mask; mask = 1; for (dst = 0; dst < 48; dst++) if (dst == 24) mask = 1; if (salt & mask) if (dst < 24) src = dst + 24; else src = dst - 24; else src = dst; DES_bs_all.E[dst] = &DES_bs_all.B[DES_E[src]]; DES_bs_all.E[dst + 48] = &DES_bs_all.B[DES_E[src] + 32]; mask <<= 1; void DES_bs_clear_keys() memset(DES_bs_all.K, 0, sizeof(DES_bs_all.K)); void DES_bs_set_key(char *key, int index) register char *ptr; register int ofs, bit; register ARCH_WORD value; ofs = 56; for (ptr = key; *ptr && ofs; ptr++) bit = (ofs -= 7); value = *ptr & 0x7F; do DES_bs_all.K[bit++] |= (value & 1) << index; while (value >>= 1); void DES_bs_crypt(int count) register int bit; register ARCH_WORD R, L; memset(DES_bs_all.B, 0, sizeof(DES_bs_all.B)); do DES_bs_body(); if (!--count) break; for (bit = 0; bit < 32; bit++) R = DES_bs_all.B[bit]; L = DES_bs_all.B[bit + 32]; DES_bs_all.B[bit + 32] = R; DES_bs_all.B[bit] = L; while (1); ARCH_WORD *DES_bs_get_binary(char *ciphertext) static ARCH_WO RD out[64]; ARCH_WORD *raw; int bit; int index, shift; int value; raw = DES_raw_get_binary(ciphertext); out[1] = out[0] = 0; for (bit = 0; bit < 64; bit++) index = bit >> 4; /* Swap L and R here instead of doing it one more time in DES_bs_crypt() */ index ^= 2; /* Calculate the number of one of the 16 data bits in raw[index] */ shift = ((bit & 0xC) << 1) + (bit & 3) + 1; /* Get the bit */ value = (raw[index] >> shift) & 1; if (DES_bs_mem_saving) /* Memory saving: pack the bits into two words */ out[bit >> 5] |= value << (bit & 0x1F); else /* We either set or clear all the bits in every word */ out[bit] = value ? ~(ARCH_WORD)0 : 0; return out; int DES_ bs_binary_hash(ARCH_WORD *binary, int count) int bit, result; if (DES_bs_mem_saving) return (int)*binary & ((1 << count) - 1); result = 0; for (bit = 0; bit < count; bit++) if (binary[bit]) result |= 1 << bit; return result; int DES_bs_get_hash(int index, int count) register int bit, result; register ARCH_WORD mask; mask = (ARCH_WORD)1 << index; result = 0; for (bit = 0; bit < count; bit++) if (DES_bs_all.B[bit] & mask) result |= 1 << bit; return result; /* * T he trick I used here allows to compare one ciphertext against all the * DES_bs_crypt() outputs in just O(log2(ARCH_BITS)) operations. */ int DES_bs_cmp_all(ARCH_WORD *binary, int count) register int bit; register ARCH_WORD mask; mask = 0; if (DES_bs_mem_saving) for (bit = 0; bit < ((count < 32) ? count : 32); bit++) mask |= DES_bs_all.B[bit] ^ ((binary[0] & (1 << bit)) ? ~(ARCH_WORD)0 : 0); if (mask == ~(ARCH_WORD)0) return 0; else for (bit = 0; bit < count; bit++) mask | = DES_bs_all.B[bit] ^ binary[bit]; if (mask == ~(ARCH_WORD)0) return 0; return 1; int DES_bs_cmp_one(ARCH_WORD *binary, int count, int index) register int bit; register ARCH_WORD mask; if (DES_bs_mem_saving) for (bit = 0; bit < count; b it++) if (((DES_bs_all.B[bit] >> index) ^ (binary[bit >> 5] >> (bit & 0x1F))) & 1) return 0; return 1; mask = (ARCH_WORD)1 << index; for (bit = 0; bit < count; bit++) if ((DES_bs_all.B[bit] ^ binary[bit]) & mask) return 0; return 1;
1Архитектура и строительство
2Астрономия, авиация, космонавтика
 
3Безопасность жизнедеятельности
4Биология
 
5Военная кафедра, гражданская оборона
 
6География, экономическая география
7Геология и геодезия
8Государственное регулирование и налоги
 
9Естествознание
 
10Журналистика
 
11Законодательство и право
12Адвокатура
13Административное право
14Арбитражное процессуальное право
15Банковское право
16Государство и право
17Гражданское право и процесс
18Жилищное право
19Законодательство зарубежных стран
20Земельное право
21Конституционное право
22Конституционное право зарубежных стран
23Международное право
24Муниципальное право
25Налоговое право
26Римское право
27Семейное право
28Таможенное право
29Трудовое право
30Уголовное право и процесс
31Финансовое право
32Хозяйственное право
33Экологическое право
34Юриспруденция
 
35Иностранные языки
36Информатика, информационные технологии
37Базы данных
38Компьютерные сети
39Программирование
40Искусство и культура
41Краеведение
42Культурология
43Музыка
44История
45Биографии
46Историческая личность
47Литература
 
48Маркетинг и реклама
49Математика
50Медицина и здоровье
51Менеджмент
52Антикризисное управление
53Делопроизводство и документооборот
54Логистика
 
55Педагогика
56Политология
57Правоохранительные органы
58Криминалистика и криминология
59Прочее
60Психология
61Юридическая психология
 
62Радиоэлектроника
63Религия
 
64Сельское хозяйство и землепользование
65Социология
66Страхование
 
67Технологии
68Материаловедение
69Машиностроение
70Металлургия
71Транспорт
72Туризм
 
73Физика
74Физкультура и спорт
75Философия
 
76Химия
 
77Экология, охрана природы
78Экономика и финансы
79Анализ хозяйственной деятельности
80Банковское дело и кредитование
81Биржевое дело
82Бухгалтерский учет и аудит
83История экономических учений
84Международные отношения
85Предпринимательство, бизнес, микроэкономика
86Финансы
87Ценные бумаги и фондовый рынок
88Экономика предприятия
89Экономико-математическое моделирование
90Экономическая теория

 Анекдоты - это почти как рефераты, только короткие и смешные Следующий
Застолье. Все усаживаются:
- Надо попросить чашку чаю и быстренько ее выпить.
- Зачем?
- Тут очень маленькие рюмки.
Anekdot.ru

Узнайте стоимость курсовой, диплома, реферата на заказ.

Обратите внимание, курсовая по компьютерным сетям "Несанкционированный доступ к терминалам серверов с операционными системами семейства UNIX", также как и все другие рефераты, курсовые, дипломные и другие работы вы можете скачать бесплатно.

Смотрите также:


Банк рефератов - РефератБанк.ру
© РефератБанк, 2002 - 2016
Рейтинг@Mail.ru