Михаил Флёнов - Linux глазами хакера

□ log_type — запись событий будет производиться в указанный файл или системный журнал;

□ log_on_success и log_on_failure — информация, которая будет сохраняться в журнале при удачном и неудачном входе в систему соответственно, Здесь можно указывать значения: PID, HOST или USER;

□ per_source — максимальное количество соединений от одного пользователя. Их может быть несколько, потому что юзеры любят максимально нагружать каналы и повышать скорость работы с помощью создания нескольких одновременно работающих соединений;

□ server_args — аргументы, с которыми будет запускаться сервер.

При рассмотрении параметра user я упомянул о необходимости прав администратора для доступа к портам с номером менее 1024. Это действительно так, но зачем это нужно? Не имея прав root, пользователь не сможет запустить сервер, который работает с портом от 1 до 1024. Такая защита необходима, потому что в данном диапазоне функционируют очень важные сервисы, и их нельзя запускать простому пользователю.

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

5.4.2. Безопасность

Мы уже знаем, что программа xinetd позволяет определять права и время доступа к сервисам. Для этого в конфигурационном файле можно использовать три команды: no_access, only_from и access_time.

Директива no_access запрещает доступ с указанных компьютеров. Например, следующая строка в конфигурационном файле закрывает доступ с адреса 192.168.1.1:

no_access 192.168.1.1

Если необходимо запретить доступ целой сети, то достаточно указать только ее номер. Например, не должны иметь доступ все компьютеры с адресами 192.168.1.X, где X может быть любым числом. В этом случае нужно использовать следующую строку:

no_access 192.168.1.

Обратите внимание, что в этом случае указанный IP-адрес состоит из трех октетов, разделенных точками, а не четырех.

Для полного запрета доступа необходимо указать в конфигурационном файле следующую строку:

no_access 0.0.0.0

Теперь посмотрим, как можно предоставлять доступ с помощью директивы only_from. Она удобна тем, что изначально запрещает все, кроме указанных в качестве параметра адресов. Получается, что мы действуем от запрета. Указав эту команду без параметра, мы вообще запретим доступ:

only_from =

Я рекомендую включить эту строку в основной конфигурационный файл /etc/xinetd.conf, а потом для каждого отдельного сервиса в его собственном конфигурационном файле прописывать разрешения. Например, давайте откроем доступ с адресов 192.168.1.2 и 192.168.1.19. Для этого добавляем в конфигурационный файл следующую строку:

only_from = 192.168.1.2 192.168.1.19

Можно разрешать доступ целым сетям:

only_from = 192.168.1.

А что, если всей сети разрешен доступ, а компьютеру с номером 1 запрещен? В этом случае можно использовать следующие две строки:

no_access = 192.168.1.1

only from = 192.168.1.

Запрет имеет больший приоритет, и даже несмотря на то, что у сети есть разрешение, компьютер из этой сети с номером 192.168.1.1 подключиться не сможет.

Теперь рассмотрим, как можно задать время доступа. Если вы настраиваете сервер, который будет работать в офисе компании, то вполне логичным будет разрешить подключение к нему только в рабочее время. Например, следующая строка делает сервисы доступными только с 8:00 до 18:00:

access_time = 8:00-18:00

В данном случае я бы увеличил второе значение до 19:00, потому что очень чаете сотрудники задерживаются на работе, и не хочется, чтобы они дергали меня каждый день из-за доступа.

Функции обеспечения безопасности, встроенные в сервис xinetd, удобны и обладают достаточно мощными возможностями, хотя и повторяют права доступа. которые можно настраивать из файлов /etc/hosts.allow и /etc/hosts.deny. Мне больше нравится заниматься настройкой безопасности с помощью конфигурационных файлов сервиса xinetd, потому что параметры доступа хранятся в тех файлах, на которые они влияют.

5.4.3. Недостатки xinetd

У любой технологии есть недостатки, и inetd/xinetd не являются исключением. При подключении пользователя к одному из портов вашего сервера программа inetd (или xinetd) просматривает таблицу портов, чтобы найти сервис, который необходимо запустить, и передать ему управление. Это может повлечь за собой большие затраты на поиск сервиса и его запуск.

В идеальном случае, любой запрос должен выполняться максимально быстро, иначе это грозит нам увеличением времени отклика. Но не это самое страшное. Лишнюю пару секунд пользователь может подождать, а вот хакер ждать не будет. Он может направить большое количество запросов на соединение с сервером, и программа inetd (или xinetd) съест все ресурсы своим поиском и запуском сервисов. Таким образом, увеличивается вероятность удачного проведения DoS атаки со стороны хакера.

Глава 6

В стиле Samba

Изначально для обмена файлами между компьютерами использовался FTP-протокол (об этом подробно поговорим в гл. 10). Но он неудобен, т.к. использует технологию "клиент-сервер". Чтобы получить с компьютера друга файл, он должен запустить у себя FTP-сервер, а вы с помощью специальной программы FTP-клиента должны подключаться к этому серверу и скачивать нужный файл.

Чтобы не утруждать себя настройками FTP-сервера, многие стали использовать специализированные обменники в своих локальных сетях. Для этого выделялся FTP-сервер с открытым доступом, который превращался в мусорную корзину.

В Windows появился более удобный способ публиковать свои файлы — "Сетевое окружение", с помощью которого пользователь может зайти на любой компьютер и использовать его открытые ресурсы. Это действительно хорошая возможность, и пользователи привыкли к ней, несмотря на то, что работа с открытыми ресурсами была небезопасной.

Чтобы пользователи Windows могли видеть сервер Linux в своем сетевом окружении и работать с ним как с Windows-машиной, был разработан пакет Samba (чаще всего можно встретить сокращение smb), который состоит из двух программ. Сервер позволяет публиковать локальные папки для всеобщего просмотра, а с помощью клиента вы можете подключаться к другим компьютерам и работать с их открытыми ресурсами.

С помощью Samba можно сделать легко доступный и удобный в использовании файловый сервер. Раньше у меня на работе для этих целей использовался Windows 2000-сервер, который параллельно работал как сервер баз данных. Но файловый архив занимает слишком много места, отнимает ресурсы сети и сервера и понижает безопасность. Поэтому было принято решение перенести файловый архив на отдельный физический сервер. Использовать для этого Windows 2000 слишком дорого и неэффективно — это то же самое, что вывозить мусор из дома на расстояние 20 метров на Ford Mondeo. Для этих целей лучше подойдет Linux, который обходится дешевле и не требует обслуживания. Достаточно один раз настроить такой сервер, и можно использовать годами. Именно так мы и поступили.

Одно из мощнейших преимуществ Samba — возможность удаленного управления через SSH или SWAT (Samba Web-based Administrative Tool, набор администратора через Web для Samba).

6.1. Конфигурирование Samba

Основным конфигурационным файлом для Samba является smb.conf, который можно найти в директории /etc/samba (в некоторых дистрибутивах это может быть каталог /etc). Кроме него в этой директории можно найти файл lmhosts, с помощью которого происходит преобразование IP-адресов и имен компьютеров аналогично etchosts в Linux, а Диск:Windowssystem32driversetclmhosts.sam в Windows только используется сервером Samba.

Дополнительно вы можете создать следующие файлы (некоторые из них могут существовать):

□ smbusers — файл хранит список пользователей, которым разрешено подключаться к серверу Samba;

□ smbpasswd — пароли пользователей из файла smbusers;

Как видите, у Samba свои конфигурационные файлы для хранения списка пользователей. Если вы создаете их вручную, то убедитесь, что права на чтение и запись установлены правильно. Файл должен быть доступен только администратору т.е. владельцем может быть исключительно root, и никто более.

Конфигурационный файл smb.conf содержит не так много директив, поэтому для удобства восприятия я привел небольшой пример (листинг 6.1), который поможет вам увидеть общую структуру такого файла. В дальнейшем нам предстоит рассматривать другие серверы Linux, где настроек намного больше.

[global]

# Основные директивы