Установить Linux/BSD — не проблема, инсталлятор все сделает за нас, а вот правильно настроить систему, чтобы ее тут же успешно не атаковали хакеры, удается далеко не каждому. Проанализировав ситуацию, мыщъх отобрал десяток наиболее распространенных ошибок, допускаемых не только начинающими, но и матерыми юниксоидами.
Все видели логотип на главной странице OpenBSD? «Всего лишь две удаленных уязвимости в конфигурации по умолчанию за десять лет промышленной эксплуатации». Означает ли это, что, установив OpenBSD на свою машину, мы можем ничего не опасаться? Нет и еще раз нет!
Несмотря на то что в xBSD и особенно в Linux имеется достаточное количество дыр, под которые написано множество эксплойтов, большинство атак совершается не через них (хотя и через них тоже), а «благодаря» грубым ошибкам конфигурации, допущенным администратором. Это справедливо как для серверов, так и для рабочих станций, однако серверы имеют свою специфику: здесь доминируют дыры в PHP/Perl-скриптах, SQL-injecting и т.д. Об этом уже неоднократно говорилось на страницах нашего журнала, так что оставим серверы в покое (о них есть кому позаботиться) и сосредоточимся на рабочих станциях обычных пользователей, которые обучаются методом тыка и совершенно не знакомы с тактикой ведения боя против хакеров. Как быстро получить кредиты онлайн узнайте у нас.
1. Использование одинаковых паролей
Как ни печально, но большинство пользователей, выбрав себе пароль, используют его везде, где только можно: на вход в систему, для доступа к почтовому ящику, при регистрации на различных форумах и других сетевых ресурсах, забывая о том, что во всех этих случаях пароли передаются в открытом виде и могут быть выловлены любым снифером или путем отправки фальшивого ответа от имени DNS-сервера, перенаправляющего жертву на узел злоумышленника (подробнее об этом рассказывается в пункте 4). Также не стоит забывать о том, что хакер может заманить жертву на свою страничку, под тем или иным предлогом требующую регистрации (например, для записи в гостевой книге), или предложить бесплатный почтовый сервис.
С другой стороны, удержать в голове целую кучу паролей практически невозможно, особенно если они не вводятся с клавиатуры каждый раз, а автоматически подставляются программой. Но за это удобство приходится платить, и через некоторое время пароли начисто забываются. Что делать? Как быть? Записывать пароли? Так ведь это не выход. Если листок со списком паролей спрятать в секретном месте, то при выходе в сеть с чужой машины он все равно не поможет, а хранить пароли в записной книжке слишком рискованно. Мир не без любопытствующих товарищей! Никому доверять нельзя, а бумаге — тем более.
Некоторые используют довольно хитрый трюк: слегка видоизменяют пароли или включают в пароль имя ресурса. Например, используем в качестве базового пароля «rfn3g1k-h», добавляя к нему 1nb0x при регистрации почтового ящика на inbox.ru или 030n при создании аккаунта в интернет-магазине www.ozon.ru.
2. Установка открытого proxy
Proxy-серверы на рабочих станциях встречаются намного чаще, чем можно подумать. Во-первых, с кэшированием web-страничек они справляются лучше, чем браузеры. К тому же, при использовании нескольких браузеров (равно как и браузеров, запускаемых из-под разных пользователей) каждый из них ведет свой кэш, что не только нецелесообразно, но и неэкономично! При отключении в настройках браузеров использования локального кэша (кстати говоря, работа Горящего Лиса после этого заметно ускоряется) proxy позволяет взять кэширование на себя. Во-вторых, proxy может решить проблему совместного доступа в интернет для всех членов семьи и виртуальных машин (типа VM Ware). В-третьих, многие устанавливают proxy-сервер просто «на всякий случай», даже не разобравшись, что это за штука и нужна ли она им или нет.
При этом по умолчанию proxy-сервер обычно доступен всем желающим, и такие желающие находятся достаточно быстро ;). Какой резон в использовании чужого proxy? Начнем с того, что большинство интернет-провайдеров либо вообще не тарифицируют внутрисетевой трафик, либо продают его значительнее дешевле, чем внешний. Таким образом, отыскав свободный proxy внутри сети провайдера, хакер кидает жертву на бабки. Или, что еще хуже, совершает через него атаку, оставляя в логах чужой IP.
Некоторые переводят proxy на нестандартные порты, надеясь, что «там» хакеры их не найдут. Наивные! Ведь хакеры ищут не вручную, а через сканеры. Другие предпочитают закрывать доступ на proxy паролем, что в смысле защищенности выглядит блестящим решением, но, к сожалению, на сегодняшний день далеко не все прикладные программы поддерживают функцию авторизации. Для отсечения всех «левых» хакеров достаточно использовать привязку к внутренним сетевым интерфейсам и IP-адресам. Это достаточно надежный способ защиты, хотя и существует ряд атак, позволяющих его обойти.
Примечание: как вариант, чтобы прокся не стала прокисшей, демон кэширующего прокси-сервера можно подвесить на интерфейс обратной петли и с помощью файрвола перенаправлять на него все www-запросы, поступающие от доверенных хостов. Например, так:
# vi /etc/pf.conf
ext_if = «fxp0»
int_if = «fxp1»
table { 192.168.1.2/32, 192.168.1.3/32, 192.168.1.9/32 }
table { 192.168.1.0/24, 192.168.2.0/24 }
nat on $ext_if inet from to any -> $ext_if
rdr on $int_if inet proto tcp from to ! \
port www -> 127.0.0.1 port 3128
3. Включение поддержки IPv6
Поддержка IPv6 в BSD и Linux появилась не вчера и даже не позавчера, между тем IPv6-стек все еще остается сырым и подверженным целому спектру атак: от отказа в обслуживании до захвата управления машиной, причем реально в нашей стране IPv6 никому не нужен. Сегодня с ним можно разве что поиграться, да и то, в основном, на серверах, а не на рабочих станциях. Пройдет немало лет, прежде чем протокол IPv6 окажется востребованным, но и тогда останется возможность работы через древний IPv4. Так что нет никаких оснований держать IPv6 на своей машине, подвергая ее ненужному и совершенно неоправданному риску хакерской атаки.
Выбор протокола IPv6 осуществляется на стадии установки, и в дальнейшем отказаться от него без перекомпиляции ядра не так-то просто, однако существует более простой путь — заблокировать весь IPv6-трафик на брандмауэре. Для этого на xBSD-системах в правила файрвола достаточно добавить следующую строчку:
# vi /etc/pf.conf
block quick inet6 all
4. DNS на UDP
DNS-протокол, по умолчанию работающий с использованием UDP, небезопасен, и хакер может перенаправить нас на свой узел, просто отправив фейковый ответ от имени DNS-сервера. Чтобы этого не произошло, необходимо общаться с DNS-сервером только по TCP-протоколу. Это чуть медленнее, зато намного надежнее, поскольку, в отличие от UDP, TCP работает с установкой соединения, включающей в себя операцию «рукопожатия», то есть просто так отправить TCP-пакет с поддельным IP-адресом в заголовке нельзя, как минимум требуется угадать идентификатор последовательности, чтобы подделать все остальные пакеты.
Проще всего это сделать путем блокировки всего UDP-трафика на 53 порту, однако если DNS-сервер провайдера не поддерживает работу через TCP (как, например, djbdns), то мы не сможем разрешать доменные имена вообще, что очень нехорошо. А почему бы не установить свой собственный локальный DNS-сервер? Как показывает практика, DNS-серверы большинства провайдеров тормозят со страшной силой и гораздо выгоднее обращаться к корневым DNS-серверам, это, к тому же, еще и безопаснее. BIND входит в поставку практически любого дистрибутива (смотри man named) и уже содержит все необходимое, в том числе и адреса корневых DNS-серверов, прописанные в конфигурационных файлах. Для большей надежности рекомендуется задействовать цифровую подпись, установив параметр auth-nxdomain конфигурационного файла named.conf в значение yes.
5. Запуск подозрительных программ под root’ом
Считается, что вирусов под Linux/BSD не существует. Это неверно. Вирусы есть, просто они не получили большого распространения в силу низкой распространенности самих Linux/BSD, а также того факта, что нормальные люди сидят не под root’ом, а под простым пользователем, не имеющим права модификации уже установленных исполняемых файлов. Тем не менее, если запустить вирус под root’ом, он сможет такого натворить… Причем это относится не только к запуску, но и к компиляции! А точнее к сборке исходных текстов утилитой make, обрабатывающей Makefile, который может включать в себя команды операционной системы, предоставляющие хакеру неограниченную власть над машиной.
Если программа получена из ненадежных источников, то необходимо либо выполнить аудит исходных текстов, либо запускать ее с помощью защитных механизмов типа systrace.
6. Использование Горящего Лиса
Лис считался надежным браузером лишь до тех пор, пока на него никто не обращал внимания, но теперь по количеству обнаруженных дыр он вплотную приближается к печально известному IE. И хотя массовых атак на Лиса пока отмечено не было, это не значит, что можно и дальше спокойно бродить с ним по Сети. Беспечная жизнь закончилась. Лис уже отхватил солидную долю рынка, что делает его весьма соблазнительной мишенью для хакеров. Даже оперативная установка самых свежих заплаток не гарантирует безопасности!
К счастью, помимо Лиса, есть и другие браузеры, например, Konqueror, интегрированный в KDE, а также текстовой браузер Lynx (входящий в большинство дистрибутивов по умолчанию), которым очень любит пользоваться мыщъх.
7. Использование готового ядра без перекомпиляции
Большинство эксплойтов, использующих дыры в ядрах Linux и BSD, содержат в себе жестко прошитые (hardcoded) адреса машинных команд, изменяющиеся от версии к версии и, естественно, при перекомпиляции.
Ядро из коробки довольно предсказуемо, и атакующий может без труда установить, какой именно байт передаваемых данных затирает адрес возврата и чем его необходимо заменить, чтобы передать управление на shell-код. В большинстве случаев его заменяют адресом машинной инструкции jmp esp. А если выполнение в стеке запрещено, то выделяют блок памяти посредством вызова malloc() с последующей установкой атрибутов исполнения через функцию mprotect() и копирования shell-кода на новое место обитания функцией memcpy(). Естественно, адреса всех этих функций атакующий должен знать заранее, иначе у него ничего не получится. Уязвимая программа выбросит исключение, которое будет отловлено ядром, и если программист не предусмотрел специальной обработки критических ситуаций, программа завершится в аварийном режиме. То есть дальше банального DOS’а хакер не продвинется.
Атаковать систему с перекомпилированным ядром и всеми стандартными библиотеками практически не реально. Это по плечу только настоящим профессионалам, а не кидисам, научившимся скачивать эксплойты из сети.
8. Неудаленный map-файл
Файл System.map (обычно располагающийся в каталоге /boot) включает в себя символьную информацию о глобальных переменных и функциях, экспортируемых ядром, и широко используется руткитами, которые прячут от глаз администратора враждебные файлы, процессы и сетевые соединения. И хотя достаточно многие руткиты могут находить необходимые им функции и без System.map’a, его удаление существенно уменьшает вероятность успешного проведения атаки. В «мирных целях» System.map нужен разве что отладчикам, да некоторым низкоуровневым программам. На всякий случай, чтобы потом не перекомпилировать ядро (а System.map создается именно при перекомпиляции ядра), скопируй его в надежное место (например, на внешний носитель) или просто переименуй во что-то менее «напряженное».
9. Отсутствующие директории в lib
Порядок поиска динамических библиотек задается системной переменной LD_LIBRARY_PATH, значение которой берется из конфигурационного файла /etc/ld.so.config, перечисляющего директории с динамическими библиотеками. В корректно установленной системе право создания новых файлов в этих директориях имеет только root. Это логично, поскольку в противном случае любой желающий смог бы добавить свою зловредную библиотеку в вышестоящую директорию, да так, чтобы она загружалась вместо оригинала. Некоторые инсталляторы (например, установщик Knoppix’а) прописывают в файле /etc/ld.so.config пути к несуществующим директориям. Казалось бы, ну что тут такого? Мелочь… На самом деле, это огромная дыра в безопасности, поскольку для создания директорий иметь права root’а совершенно не обязательно, и в них можно размещать библиотеки-спутники, работающие по принципу вирусов-спутников, известных еще со времен MS-DOS. Открой файл /etc/ld.so.config и удали из него все несуществующие пути, если таковые там присутствуют.
10. Игнорирование битов NX/XD
Долгое время x86-процессоры поддерживали только два атрибута защиты на уровне страниц: атрибут доступности и атрибут записи. Атрибут исполнения кода поддерживался только на уровне селекторов, и практически все *nix-подобные системы размещали стек, код, данные и кучу в едином адресном пространстве, доступном для исполнения.
Несмотря на то что функция mprotect() поддерживает четыре атрибута защиты: PROT_NONE, PROT_READ, PROT_WRITE и PROT_EXEC, на аппаратном уровне атрибут PROT_EXEC является синонимом атрибута PROT_READ, то есть если страницу можно прочитать, то с тем же успехом ее можно и исполнять. Этой дырой воспользовались хакеры, размещая исполняемый код в стеке, и хотя было предложено множество защитных комплексов, размещающих стек в неисполняемой области памяти, все они были глючными и ненадежными.
Настоящая революция наступила только с появлением в процессорах Intel и AMD новых атрибутов защиты в каталогах страниц, называемых NX (Not eXecutable) и XD (eXecutable Disabled). Последние версии Linux/BSD поддерживают эти биты в том или ином виде, но поскольку ряд честных программ (и прежде всего, runtime-компиляторов, транслирующих код «на лету» прямо в память) нуждается в исполняемом стеке, по умолчанию защита выключена во всех системах, кроме OpenBSD.
И хотя неисполняемые биты — отнюдь не панацея (хакеры уже давно научились обходить их), тем не менее они чрезвычайно затрудняют атаку, а в сочетании с перекомпилированным ядром и системными библиотеками делают ее практически невозможной. Так что смысл в этой защите все-таки есть, и лучше держать ее наготове.
