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

Страница 4

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

· Отсутствие контроля за виртуальными каналами связи

Объекты распределенной ВС, взаимодействующие по виртуальным кана­лам, могут подвергаться типовой атаке «отказ в обслуживании». Особен­ность этого воздействия состоит в том, что, действуя абсолютно легальны­ми средствами системы, можно удаленно добиться нарушения ее работоспособности. В чем причина успеха данной атаки? В отсутствии необхо­димого контроля над соединением. При этом задача контроля распадается на две подзадачи:

• контроль за созданием соединения;

• контроль за использованием соединения.

Если пути решения второй задачи понятны - обычно соединение раз­рывается по тайм-ауту, определенному системой, - так сделано во всех из­вестных сетевых ОС (однако тут возникает серьезная проблема выбора конкретного значения тайм-аута), то контроль за созданием ВК достаточ­но сложен: в системе, где отсутствует статическая ключевая информация обо всех ее объектах, невозможно отделить ложные запросы на создание соединения от настоящих. Очевидно также, что если один субъект сетево­го взаимодействия будет иметь возможность анонимно занимать неогра­ниченное число каналов связи с удаленным объектом, то подобная систе­ма может быть полностью парализована данным субъектом. Таким образом, если лю­бой объект в распределенной системе способен анонимно послать сооб­щение от имени другого объекта (например, в 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"