Серверное применение Linux, 3-е издание

Серверное применение Linux, 3-е издание
Автор: Денис Колисниченко
Год: 2011
ISBN: 978-5-9775-0652-6
Страниц: 514
Язык: Русский
Формат: PDF
Размер: 21 Мб

Download

Описана настройка различных типов серверов: Web-, FTP-, DNS-, DHCP-, почтового сервера, сервера баз данных. Подробно рассмотрена установка и базовая настройка операционной системы, настройка связки Apache + MySQL + PHP, дано общее устройство Linux и разобраны основные принципы работы с этой операционной системой. Отдельное внимание уделено защите сервера на базе Linux: настройка брандмауэра, защита маршрутизатора и точки доступа и т. д. Описана работа системы контроля доступа Tomoyo, прокси-серверов Squid и SquidGuard. Изложение основано на последних на момент написания книги версиях популярных дистрибутивов Fedora, Mandriva, Ubuntu, openSUSE. Третье издание существенно дополнено новым материалом: рассматривается дистрибутив openSUSE, приводится расширенное описание брандмауэра iptables, настройка сети производится не только с помощью графических конфигураторов, но и с помощью конфигурационных файлов системы, рассмотрены средства резервного копирования remastersys, Clonezilla, Linux Live. Для администраторов Linux и опытных пользователей.

+

Что делать в случае взлома?

100% безопасности не гарантируется

Рано или поздно ваш сервер могут взломать. Степень защищенности сервера тоже особой роли не играет — можно “вскрыть” как сервер с настройками по умолчанию, так и самый секретный сервер Пентагона. Важно понимать: то, что защитил один человек, может взломать другой. Просто первый компьютер (с настройками по умолчанию) будет взломан за какой-то час (если не раньше), а на преодоление бастионов более защищенного будет потрачено больше времени. Вот и вся разница.

Так может лучше вообще не тратить время на настройку сервера, а использовать параметры по умолчанию? Ведь это как с автомобилем. Можно вообще не устанавливать сигнализацию — она все равно отпугивает только дилетантов, а настоящие профи, если захотят, то смогут угнать автомобиль. А лучшая защита от угона — это полное КАСКО.

С одной стороны, правильно — можно даже сэкономить несколько десятков тысяч рублей (вряд ли стоит покупать противоугонную систему за 3—5 тысяч — это выброшенные на ветер деньги). Но с другой — даже простейшая сигнализация отпугнет простого воришку, который не захочет разбивать стекло, чтобы стащить магнитолу или документы из машины. Когда станет выбор, стекло какой машины разбить — той, которая с сигнализацией или там где ее нет, выбор будет очевиден. А украсть могут не только магнитолу — можно еще украсть подушку безопасности (стоит довольно дорого), изуродовать панель автомобиля в процессе извлечения магнитолы (на аккуратную работу времени, сами понимаете, нет). Так что наличие сигнализации отпугнет воришек. А наличие серьезной сигнализации — отпугнет даже профессиональных автоворов. Зачем связываться с машиной, где установлена
серьезная противоугонка, если рядом стоит аналогичная с системой попроще? Думаю, логика ясна. Совсем другое дело, если “заказали” именно ваш автомобиль — тогда, действительно, лучшая защита — это КАСКО. Автомобиль будет угнан в любом случае, но вы, хотя бы, получите материальную компенсацию.

С сервером все аналогично. Многое зависит от уровня подготовки злоумышленника и от преследуемых им целей. Если это дилетант, то базовая защита сервера отпугнет его — он попросту не сможет его победить, и будет искать другую систему, на которой “тренироваться” проще. Смысл ему взламывать три дня ваш сервер и в итоге не взломать, если можно за эти три дня найти с десяток незащищенных и взломать их. А каждый сервер очень поднимает самооценку, ради которой и осуществляются подобные мероприятия. То есть человеку все равно, чей сервер взломать, лишь бы поставить еще одну галочку (крестик, звездочку) в своем “послужном списке”.

Другое дело, если вы имеете дело с более подготовленным специалистом. Ваш сервер могут взломать по двум причинам: если он “заказан”, например, конкурентами, или если профи нечего делать, а взламывать “простые” машины ему не интересно — тогда он выберет ваш. Будет ли он взломан, зависит, конечно же, от степени защиты. Может, на взлом уйдет столько времени, что информация, которая могла быть получена в результате сего процесса, уже станет неактуальной. А если это взлом ради интереса, тогда рано или поздно хакеру надоест им заниматься (или же “подойдет” настоящая работа), поэтому он забудет о вашей машине до лучших времен.

Далее мы разберемся, что нужно делать, если вашу машину-таки “скомпрометировали”.

Первым делом нужно отключить все сетевые интерфейсы — ведь в большинстве случаев атака производится по сети. Желательно отключить сетевые интерфейсы физически — просто отключите кабель от сетевого адаптера.

Затем нужно определить, каким образом злоумышленник проник в систему. Здесь ничего посоветовать не могу, кроме как анализировать журналы системы. Хотя, он может эти журналы почистить, тогда анализировать будет нечего. Тогда нужно подумать, как злоумышленник мог попасть в вашу систему. Если были запущены сервисы SSH и FTP, то в большинстве случаев именно они и скомпрометированы, искать “дыру” нужно именно в них.

Не нужно забывать и о человеческом факторе. От него никто не защищен. Предположим, что у вас в подчинении есть младший администратор, установивший слишком простой пароль для своей учетной записи. Пароль могли подобрать или же
узнать его каким-либо другим способом. Потом злоумышленник использовал его имя пользователя и пароль для входа в систему. Как видите, никакой дыры нет — система же не может убедиться, что пароль вводит именно Петров, а не Сидоров.

Ясно одно. Злоумышленник, после того как проник в вашу систему, постарается внедрить backdoor — так называемый “черный” ход. Ведь он прекрасно понимает, что рано или поздно администратор закроет “дыру”. А “черный” ход позволит ему и после этого проникать в систему и оставаться незамеченным.

Далее мы рассмотрим самые часто используемые способы организации backdoor.

Своя учетная запись

Самый простой способ добавить backdoor — это создать еще одного пользователя. Проверьте свой /etc/passwd — вдруг в нем появилась новая учетная запись пользователя, которого вы явно не создавали. Удалите ее немедленно. Также проанализируйте, есть ли в системе пользователи, которые заходят очень редко. Возможно, злоумышленник изменил пароль одного из таких пользователей. А т. к. пользователь заходит в систему очень редко, он ничего пока не заметил. Желательно изменить пароли всех пользователей, если это возможно. Новый пароль пользователь получит при личном обращении — когда заметит, что пароль изменен.Также не забудьте про файлы паролей отдельных сервисов, например сервера Apache (см. файлы .htaccess).

Файлы hosts.allow и hosts.deny

Предыдущий способ был довольно прост — администратору легко определить учетную запись злоумышленника. А этот способ (изменение файлов hosts*) еще и глуп, поскольку злоумышленник в этом случае “засветит” свой IP-адрес или IP-адрес узла, через который он осуществлял взлом. Но, тем не менее, некоторые злоумышленники ничем не брезгуют, а некоторые администраторы забывают проверять эти файлы на предмет записи, разрешающей обращение к серверу компьютера злоумышленника.

Сетевая файловая система

Возможно, злоумышленник оставил в /etc/exports запись вида:

/ компьютер_хакера(rw,no_root,squash)

Данная запись предоставляет полный доступ к вашей корневой файловой системе. Способ тоже глуп, поскольку “светится” компьютер злоумышленника, но иногда и такой способ хорош. Особенно когда администратор никогда в жизни не использовал NFS и даже не подозревает о существовании и назначении файла /etc/exports…

Руткиты

А вот если у злоумышленника было немного времени, и он не поленился установить руткит, вычислить его будет очень сложно. Руткит — это не вирус и не вредоносная программа. Руткит — это набор утилит, позволяющий скрыть присутствие злоумышленника в системе. Как правило, руткит заменяет набор стандартных утилит — ls, cat, ps, adduser, passwd и др. Потом эти утилиты не показывают вам, администратору, следы присутствия злоумышленника. Например, хакер может установить сетевой сервис — аналог SSH для входа в систему. А чтобы вы не заметили “лишний” сервис, программа ls (точнее, ее руткит-версия) будет скрывать наличие в файловой системе ее исполнимого файла, ps — наличие сервиса в списке процессов, netstat — наличие открытого порта.

Найти руткит довольно сложно. Если руткит работает на пользовательском уровне, т. е. представляет собой просто набор приложений, как было сказано ранее, то обнаружить его довольно просто — контрольная сумма файлов стандартных программ будет отличаться от эталонных — файлов, входящих в состав дистрибутива. Если есть подозрение, достаточно сравнить контрольные суммы файлов /bin/ls, /bin/ps (можно проверить и остальные программы). Если они отличаются от эталонных, в вашу систему внедрен руткит. Наличие дополнительного сервиса, запущенного на сервере, можно проверить сетевым сканером nmap. Настоятельно рекомендуется запускать его с другой машины.

Совсем другое дело, если руткит работает на уровне ядра. Внедрить такой руткит намного сложнее, поскольку нужно перекомпилировать ядро, а на это нужно время. Зато обнаружить его практически невозможно. Дело в том, что стандартные
утилиты остаются нетронутыми. А руткит, внедренный в код ядра, изменяет предоставляемую ядром информацию — таблицу процессов, листинг каталога и т. д. То есть утилиты вроде ls, ps и netstat уже получают измененную информацию от ядра. Вычислить наличие такого руткита можно, сравнив вывод утилит ps, netstat и т. д. с выводом этих же утилит, но при условии, что система загружена на другом ядре — предварительно нужно установить это другое ядро.

В Интернете можно найти много программ для обнаружения руткитов, а также множество методик. Пока вы не столкнулись с руткитом лично, для общего развития рекомендую прочитать вот эту статью: www.xakep.ru/post/42886/default.asp

Модули ядра

Устанавливать ядро на удаленный компьютер довольно проблематично. Самая большая проблема — нужна перезагрузка компьютера, а ее могут заметить администраторы. Однако свой код можно внедрить в ядро с помощью модулей. Злоумышленник загружает на ваш компьютер уже откомпилированные модули ядра и добавляет их в ядро командой insmod. Заметить это действие практически невозможно. Правда, есть одно “но”. Наверняка злоумышленник захочет, чтобы его модуль был доступен и после перезагрузки — ведь рано или поздно она произойдет. Поэтому он может добавить его в файл /etc/modules.conf (или conf.modules). А в этом случае вы легко обнаружите лишний модуль ядра.

Удаленный командный интерпретатор

Зачем усложнять себе жизнь и создавать собственную версию SSH, устанавливать ее на компьютере жертвы? Ведь можно просто изменить /etc/xinetd.conf и добавить строки вида:

service myshell
{
socket_type = stream
protocol = tcp
wait = no
user = root
server = /bin/bash -i
port = 9099
instances = UNLIMITED
}

После этого, подключившись по telnet к порту 9099, вы получаете доступ к командному интерпретатору bash с правами root (!). А больше ничего вам и не нужно — путем простого редактирования одного файла вы получаете практически полный контроль над системой!

Так что не забудьте просмотреть свой /etc/xinetd.conf или /etc/inetd.conf (на старых компьютерах) на предмет описания лишних сервисов.

Также проверьте файлы /etc/hosts.equiv и ~/.rhosts, в которых могут быть строки, разрешающие ввод команд удаленному пользователю от имени локального пользователя (кроме root). А чтобы вообще обезопаситься и отключить данную возможность, отключите в вашем inetd/xinetd следующие сервисы:

in.rshd
in.rexecd
in.rlogind

Настройка PHP и CGI

В настройках вашего Web-сервера или в настройках интерпретатора (для PHP — это файл php.ini) отключите возможность использования команд system () и exec (), которые позволяют выполнять различные команды от имени пользователя, запустившего Apache. Некоторые администраторы запускают Apache от имени root… Последствия можете себе представить.

Для PHP откройте php.ini и добавьте в него следующую строку (или раскомментируйте ее, если она закомментирована):

disable_functions = exec,passthru,shell_exec,system, proc_open,
popen,curl_exec,curl_multi_exec,parse_ini_file,show_source

Для остальных интерпретаторов вам нужно прочитать соответствующее руководство. А вообще, по возможности, откажитесь от CGI в пользу PHP.

После редактирования файла php.ini нужно перезапустить Apache, чтобы изменения вступили в силу.

SSH — огромная дыра

Сервис SSH — это огромная черная дыра в безопасности вашего сервера. И вовсе не потому, что он дыряв, как первые версии sendmail. Вовсе нет — это довольно безопасный сервис, но при одном условии: он требует правильной настройки.

Начнем с аутентификации по ключу. Если у клиента есть ключ, sshd проверяет его, и если проверка прошла успешно, клиенту предоставляется доступ. Но если злоумышленник ранее получил полный доступ к системе (как он это сделал — это уже другой вопрос) и добавил свой ключ в /etc/ssh_known_hosts?

Советую открыть ваш sshd_config и установить директиву IgnoreRHosts в значение yes. Это защитит вашу систему от несанкционированного использования файлов hosts.equiv и .rhosts.

Также проверьте, чтобы в root/.shh/authorized.keys не было “лишних” ключей. Ведь если злоумышленник поместит в этот файл свой ключ, то потом сможет войти как root на ваш компьютер с помощью следующей команды: ssh -lroot адрес_вашего_компьютера

Как видите, SSH довольно защищен, но из-за “полиморфизма” аутентификации вы можете не заметить одну из “дыр”. Правда, чтобы ее реализовать, злоумышленнику нужно получить root-доступ каким-либо другим способом.