Прослушивание сетевого трафика

Существует множество протоколов (таких как POP3, telnet, ftp и др.), передающих по сети незашифрованные данные, в том числе и пароли. Принцип же действия сети Ethernet таков, что любой посланный системой пакет доступен для просмотра всем членам домена коллизий, из которого послан пакет, а так-же всем членам доменов коллизий, через которые пакет пройдет на пути к адресу назначения.

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

Если ваша сеть построена с использованием хабов, Вы сможете сами попробовать перехватить трафик ваших соседей, установив на свой компьютер, например, триальную версию пакета CommView компании TamoSoft (Для Windows).

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

Атака "Фальшивый Сервер"

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

Итак, администратор набирает в командной строке ssh server.home.net, и надеется, что через несколько секунд он окажется на сервере. Ничего подобного! Умный хакер, использовав весь арсенал из предыдущего способа атаки, перехватывает запрос к серверу DNS, который посылает система администратора для получения IP-адреса компьютера с именем server.home.net. Хакеру остается только успеть раньше настоящего сервера DNS отправить системе администратора фальшивый ответ, указав в качестве адреса свою, заранее подготовленную систему, и понаблюдать, как администратор вводит свой пароль. Грамотный хакер может даже самостоятельно установить соединение ssh с сервером, и передавать введенные администратором данные на сервер (а администратору, соответственно, ответы), так что администратор ничего не заметит.

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

Ошибки в программах и скриптах

Пожалуй, больше всего ошибок, связанных с безопасностью, допускают web-программисты в cgi-скриптах. Особенно часто такие ошибки гнездятся в скриптах, посылающих почтовые сообщения по адресу, указанному пользователем. Вот примерный код такого скрипта на языке perl:

Этот скрипт в первой строчке получает введенный пользователем адрес, после чего организуют конвейер (или пайп - механизм, принятый в unix и DOS, позволяющий "вывод" одной программы переправить на "ввод" другой). "Хитрый" хакер может вместе с адресом электронной почты ввести символы, "продожающие" конвейр, например cool@hacker.ru | rm -Rf /bin. Результатом подстановки такого адреса во вторую строку будет двойной конвейр: open(MAIL,"| sendmail cool@hacker.ru | rm -Rf /bin"). При выполнении этой команды текст письма будет перенаправлен на ввод команде sendmail, а вот ее вывод будет перенаправлен на ввод команде rm, которая в данном случае (если у процесса, исполняющего скрипт, хватит полномочий), удалит из системы все основные программы, расположенные в каталоге /bin.

Внутрисистемная атака

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

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

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

Ошибочка состояла в следующем: в своей программе администратор пользовался услугами другой программы (ну, предположим, passwd - изменение пользовательского пароля), и запускал ее функций execlp. В отличие от обычного execl, функции execlp не нужно передавать полный путь к программе (/bin/passwd), а достаточно передать только имя файла - passwd. Путь к программе execlp находит сама, пользуясь для этого переменной окружения PATH... казалось бы - ничего страшного, PATH то обычно и начинается с этого самого /bin... однако, пользователь имеет право менять свою собственную переменную PATH, которую и получит программа.

Юными хакерами была написана собственная программа, названа passwd, выложена в собственном каталоге. Переменная PATH была соответсвенным образом изменена, в результате чего программа администратора вместо /bin/passwd запустила на выполнение /home/.../passwd с правами администратора. К счастью для института, и несчастью для хакеров, взлом был довольно быстро обнаружен сиситемой слежения (хакерам не хватило опыта), но система после этого не работала неделю - искали оставленные хакерами "закладки".

--------------------------------------------------------------

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

Предотвращение атак

Во-первых, необходимо отказаться от использование не необходимых служб на сервере. Если Вам необходим какой-то сервис, но его можно вынести на другую машину - сделайте это. Естественно, эти машины должны быть как можно меньше логически связаны между собой - на каждой из них должна быть собственная система авторизации, пароли администраторов и пользователей, имеющих какие-либо административные привелегии не должны совпадать. Машины не должны "слепо" доверять друг-другу только потому, что они стоят в одной комнате - любое общение между ними должно быть защищено. Если какой-то сервис необходимо оставить на одной машине с критично-важными данными - попробуйте поискать информацию про известные уязвимости, и про более защищенные альтернативные реализации. Для самостоятельного изучения оставлю так-же такие средства безопасности отдельных приложений, как chroot и jail.

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

Вот примерный спикок сервисов, которые могут оказаться запущеными на Вашем сервере, и которые желательно "пристрелить", если в них нет необходимости:

telnet - Один из самых старых сервисов в UNIX. Обеспечивает удаленную работу пользователя с командным интерпретатором (удаленная "консоль"). Один из самый взломоопасных протоколов, т.к. имя пользователя и пароль передаются через сеть открытым текстом. Вместо telnet рекомендуется использовать ssh (Secure SHell) - telnet с шифрованием потока.

Для отключения данного сервиса необходимо закомментировать (поставить в начале строки символ '#') строку telnet stream tcp.... в файле /etc/inetd.conf. Для включения демона Secure Shell добавьте строку sshd_enable="YES" в файл /etc/rc.conf.

ftp - Протокол передачи файлов (File Transfer Protocol). Используется для двустороннего обмена файлами между unix-системами. Пароли - в лучших традициях, открытым текстом. Кроме того, в различных реализациях демонов ftp было найдено очень много ошибок безопасности разной степени критичности. Более надежным способом приема и передачи файлов является защищенный вариант ftp-сервера, включенный в ssh. К сожалению, не все ssh-клиенты поддерживают эту возможность...

Метод отключения аналогичен предыдущему: закомментировать строку ftp stream tcp... в файле /etc/inetd.conf. Впрочем, если нет необходимости в других службах, обрабатываемых с помощью inetd, его можно полностью отключить, добавив в файл /etc/rc.conf строку inetd_enable="NO".

apache (httpd) - Web-сервер. Сам по себе довольно безопасный, основная опасность кроется в неправильном конфигурировании и cgi-скриптах. Кроме того, протокол HTTP легко поддается перехвату, т.е. вся информация передается открытым текстом.

Т.к. внутрений Web-сервер - вещь довольно полезная, то полностью отказываться от него Вы, скорее всего, не захотите. Поэтому желательно установить сервер apache, работающий через защищенное соединение SSL - этим Вы предотвратите перехват данных (очень часто внутренний Web-сервер используется для показа пользователям их личной статистики, доступ к которой происходит по тому-же паролю, что и доступ в интернет). Существуют две параллельно развивающиеся ветки apache с поддержкой SSL - это apache+mod_ssl (/usr/ports/www/apache13-modssl) и apache-ssl. Apache-SSL быстрее и надежнее, чем mod-ssl, но урезан в возможностях
Если пользователям предоставляется возможность размещения собственных страниц с CGI-скриптами (впрочем, к администраторам это тоже относится ), то ошибки в таких скриптах неизбежны. Для защиты системы от таких ошибок применяют программы-оболочки, смягчающие "удары". Примером такой программы может служить CGIwrap.

portmapd - Многофункциональный демон, сильно напоминающий сервер RPC (Remote Procedure Call) в системах семейства Windows. С помощью этого демона работают различные службы "межъюниксного" взаимодействия, в частности NFS (Network File System). Сам по себе демон portmapd безвреден, но он, похоже, стал чемпионом по обнаружению различных дыр в защите.

Пока Вы не обзавелись еще несколькими Unix-серверами, никакой необходимости в portmapd у Вас нет. Пристрелить его можно добавлением в /etc/rc.conf строчки portmap_enable="NO".

Не менее важно для безопасности системы и само поведение администратора в системе. Учетная запись root - самый лакомый кусочек для хакера, и задача администратора - постараться не дать хакеру возможности ее заполучить, даже если хакер уже пробился в систему с пользовательскими правами, или имеет возможность перехвата сетевого трафика. Чем меньше администратор совершает действий с привилегиями учетной записи root, тем меньше риск ошибки. Вот пример того, как администратор (правда, системы Windows NT) "подарил" хакеру свой пароль. А все только потому, что воспользовался браузером из под административной учетной записи.

Хорошим правилом является заведение себе отдельной учетной записи, не обладающей административными привелегиями. Обычных пользовательских прав хватает для выяснения причин возникновения проблемы, а для ее исправления обычно достаточно выполнения всего одной-двух команд с привелениями root - для этого удобно воспользоваться командой su, которая временно даст Вам полномочия root (естественно, только после ввода пароля. Кроме того, для возможности запуска команды su пользователь должен быть членом встроенной группы wheel).

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