Практическая работа №4.

Тема: Монтирование файловых систем

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

В текущем наборе смонтированных файловых систем точка монтирования является обычной директорией дерева каталогов, в которую файловая система устройства добавляется при монтировании. Монтирование – это процсс, благодаря которому файловая система устройства становится доступной для использования. Например, можно смонтировать файловые системы разделов жесткого диска в точках монтирования /boot, /tmp или /home, файловую систему дискеты в точке монтирования /mnt/floppy, а файловую систему компакт-диска в точке монтирования /media/cdrom1. Как видите, точки монтирования могут располагаться как в корневой директории, так и в поддиректориях дерева каталогов любого уровня вложенности.

Помимо файловых систем на разделах, дискетах и компакт-дисках, существуют и другие типы файловых систем. Например, файловая система tmpfs является файловой системой в виртуальной памяти. Сетевые файловые системы, такие как NFS или AFS, позволяют монтировать на локальном компьютере файловые системы, расположенные на других компьютерах. Можно даже создать файл в существующей файловой системе, отформатировать его в качестве отдельной файловой системы (возможно, другого типа), после чего смонтировать эту новую файловую систему. Этот способ часто используется при работе с образами оптических носителей, когда загруженный ISO-образ CD- или DVD-диска монтируется вместо реального физического носителя для последующего копирования. Другим таким примером может являться пространство подкачки, размещенное не на выделенном разделе, а в файле.

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

Для монтирования и демонтирования файловых систем обычно требуются привилегии пользователя root. Если вы вошли в систему под учетной записью обычного пользователя, используйте для получения прав суперпользователя команду su - или su. Если в наших примерах вы видите, что приглашение командной строки начинается с символа #, как в листинге 1, значит, для их выполнения необходимо обладать привилегиями пользователя root.

Базовая форма команды mount принимает на вход два параметра: имя устройства (или другого ресурса), содержащего монтируемую файловую систему, и точку монтирования. В листинге 1 приведен пример, в котором мы смонтировали FAT32-раздел /dev/sda9 в точке монтирования /dos.

Листинг 1. Монтирование в точку монтирования /dos

[root@echidna ~]# mount /dev/sda9 /dos

Точка монтирования, в которую монтируется файловая система, должна существовать. В противном случае возникнет ошибка, и нужно будет либо создать указанную точку монтирования, либо использовать другую точку монтирования, как показано в листинге 2.

Листинг 2. Ошибка монтирования

[root@echidna ~]# mount /dev/sda9 /dos

mount: mount point /dos does not exist

[root@echidna ~]# mkdir /dos

[root@echidna ~]# mount /dev/sda9 /dos

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

После того как файловая система смонтирована, все файлы и директории, создаваемые или копируемые в точку монтирования или ее поддиректории, будут созданы в смонтированной файловой системе. Если в нашем примере мы создадим файл /dos/sampdir/file.txt, то он будет создан в файловой системе FAT32, которая была смонтирована в точку монтирования /dos.

Обычно команда mount автоматически определяет тип монтируемой файловой системы. Тем не менее, иногда вам может потребоваться явно указать тип файловой системы, для чего можно использовать опцию -t, как показано в листинге 3.

Листинг 3. Монтирование с явным указанием типа файловой системы

[root@echidna ~]# mount -t vfat /dev/sda9 /dos

Чтобы просмотреть список смонтированных файловых систем, используйте команду mount без каких-либо параметров. В листинге 4 показан пример нашей тестовой системы. Заметьте, что для просмотра списка файловых систем привилегии суперпользователя не требуются.

Листинг 4. Просмотр смонтированных файловых систем

[ian@echidna ~]$ mount

/dev/sda6 on / type ext4 (rw)

proc on /proc type proc (rw)

sysfs on /sys type sysfs (rw)

devpts on /dev/pts type devpts (rw,gid=5,mode=620)

tmpfs on /dev/shm type tmpfs (rw,rootcontext="system_u:object_r:tmpfs_t:s0")

/dev/sda2 on /grubfile type ext3 (rw)

none on /proc/sys/fs/binfmt_misc type binfmt_misc (rw)

sunrpc on /var/lib/nfs/rpc_pipefs type rpc_pipefs (rw)

gvfs-fuse-daemon on /home/ian/.gvfs type fuse.gvfs-fuse-daemon (rw,nosuid,nodev,user=ian)

dw.raleigh.ibm.com:/vol/vol1/dwcontent on /mnt/dwcontent type nfs (rw,addr=9.42.155.6)

/dev/sdb9 on /mnt/sdb9 type ext3 (rw)

/dev/sda9 on /dos type vfat (rw)

/dev/sr0 on /media/KNOPPIX type iso9660 (ro,nosuid,nodev,uhelper=udisks,uid=1000,gid=1000

,iocharset=utf8,mode=0400,dmode=0500)

Эту же информацию можно получить, просмотрев содержимое файла /proc/mounts или /etc/mtab; оба этих файла содержат информацию о смонтированных файловых системах

Опции монтирования

Команда mount имеет ряд опций, которые изменяют ее поведение по умолчанию. Например, с помощью опции -o ro можно смонтировать файловую систему в режиме "только для чтения". Если файловая система уже была смонтирована, добавьте опцию remount, как показано в листинге 5.

Листинг 5. Повторное монтирование в режиме только для чтения

[root@echidna ~]# mount -o remount,ro /dos

Примечания.

• Если используется несколько опций (например, remount и ro), необходимо разделять их запятыми.
• Если выполняется повторное монтирование уже смонтированной файловой системы, достаточно указать либо точку монтирования, либо имя устройства. Нет необходимости указывать и то, и другое.
• Невозможно смонтировать файловую систему, предназначенную "только для чтения", в режиме чтения и записи. Носители, файловые системы которых изменить невозможно (например, CD- и DVD-диски), автоматически монтируются в режиме "только для чтения".
• Для повторного монтирования допускающего возможность записи устройства в режиме чтения и записи, используйте опцию -o remount,rw.

Команды повторного монтирования не будут успешно завершены, если какой-либо процесс использует файлы или директории повторно монтируемой файловой системы.

Метки, идентификаторы и ссылки

В UNIX и ранних системах Linux директория /dev обычно содержала записи всех возможных устройств, которые могли быть подключены к системе. Любое подключаемое устройство всегда располагалось в одном и том же месте дерева /dev, поэтому использование имен устройств (например, /dev/sda6) было естественным. Современные устройства, поддерживающие технологию горячей замены, такие как устройства с интерфейсом USB или Firewire (IEEE 1394), могут подключаться каждый раз к разным портам. В таких случаях может возникнуть желание всегда монтировать определенный USB-накопитель в одну и ту же директорию (например, /media/myusbstick) независимо от того, к какому порту он будет подключен. Если файловая система раздела поддерживает метки или UUID, то их можно использовать и для работы с командой mount. Чтобы узнать, какой идентификатор и метка (если она есть) назначены устройству, используйте команду blkid. В листинге 6 показано, как использовать blkid для определения метки и UUID нашего корневого раздела, создать две дополнительные точки монтирования и смонтировать в них корневой раздел. Этот пример приведен лишь для демонстрации, и его не стоит использовать его на практике.

Листинг 6. Монтирование с использованием меток и идентификаторов UUID

[root@echidna ~]# blkid /dev/sda6

/dev/sda6: LABEL="Fedora-13-x86_64" UUID="082fb0d5-a5db-41d1-ae04-6e9af3ba15f7"

 TYPE="ext4"

[root@echidna ~]# mkdir /mnt/sda6label

[root@echidna ~]# mkdir /mnt/sda6uuid

[root@echidna ~]# mount LABEL="Fedora-13-x86_64" /mnt/sda6label

[root@echidna ~]# mount UUID="082fb0d5-a5db-41d1-ae04-6e9af3ba15f7" /mnt/sda6uui

Благодаря менеджеру устройств udev, в директории /dev можно найти дополнительные символические ссылки на такие устройства, как, например, жесткие диски. В листинге 7 показаны ссылки на устройство /dev/sda6 в моей операционной системе Fedora 13.

Листинг 7. Символические ссылки на устройство /dev/sda6

[ian@echidna ~]$ find /dev -lname "*sda6"

/dev/disk/by-label/Fedora-13-x86_64

/dev/disk/by-uuid/082fb0d5-a5db-41d1-ae04-6e9af3ba15f7

/dev/disk/by-path/pci-0000:00:1f.2-scsi-0:0:0:0-part6

/dev/disk/by-id/wwn-0x50014ee001a8d027-part6

/dev/disk/by-id/scsi-SATA_WDC_WD1001FALS-_WD-WMATV3772868-part6

/dev/disk/by-id/ata-WDC_WD1001FALS-00J7B1_WD-WMATV3772868-part6

/dev/block/8:6

Символические ссылки можно использовать как еще один способ указания имени устройства при его монтировании.

Демонтирование файловых систем

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

Файловые системы можно демонтировать и вручную. Более того, вы должны делать это при извлечении доступных для записи съемных устройств, таких как дискеты или USB-накопители.

Для демонтирования файловой системы выполните команду umount, указав в качестве аргумента либо имя устройства, либо точку монтирования. В листинге 10 показано, как демонтировать файловую систему, указав точку монтирования /dos, а затем снова смонтировать ее и вновь демонтировать, указав на этот раз имя устройства.

Листинг 8. Демонтирование файловых систем

[root@echidna ~]# umount /dos

[root@echidna ~]# mount /dev/sda9 /dos

[root@echidna ~]# umount /dev/sda9

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

Если вы попытаетесь демонтировать файловую систему, содержащую файлы, открытые каким-либо процессом, то вы получите сообщение об ошибке. Прежде чем начинать демонтирование файловой системы, следует проверить, что ее файлы не используются работающими процессами. Чтобы посмотреть, какие файлы открыты определенным процессом или какой процесс использует те или иные файлы, используйте команды lsof и fuser. Чтобы не выдавались предупреждения, относящиеся к GNOME Virtual File system (gvfs), может потребоваться использовать опцию -w команды lsof. О дополнительных опциях монтирования и команде lsof можно узнать из соответствующих man-страниц. Если вы проверяете все устройство целиком, то можно указать имя устройства или точку монтирования. Также можно проверить использование отдельного файла.

Для демонстрации работы этих команд я создал копию файла /etc/fstab в директории /dos и написал небольшой сценарий, который каждые 10 секунд считывает строки с устройства стандартного ввода и выводит их в устройство стандартного вывода. В листинге 11 показано сообщение об ошибке, выводимое командой umount при использовании файлов демонтируемой файловой системы, а также приведен пример использования команд lsof и fuser для проверки файлов в директории /dos, т. е. на устройстве /dev/sda9.

Листинг 9. Проверка на наличие открытых файлов

[root@echidna ~]# umount /dos

umount: /dos: device is busy.

        (In some cases useful info about processes that use

         the device is found by lsof(8) or fuser(1))

[root@echidna ~]# lsof -w /dos

COMMAND    PID USER   FD   TYPE DEVICE SIZE/OFF NODE NAME

slowread. 2560  ian    0r   REG    8,9      899  123 /dos/fstab

sleep     2580  ian    0r   REG    8,9      899  123 /dos/fstab

[root@echidna ~]# lsof -w /dev/sda9

COMMAND    PID USER   FD   TYPE DEVICE SIZE/OFF NODE NAME

slowread. 2560  ian    0r   REG    8,9      899  123 /dos/fstab

sleep     2580  ian    0r   REG    8,9      899  123 /dos/fstab

[root@echidna ~]# fuser -m /dos

/dos:                 2560  2586

[root@echidna ~]# fuser -m /dev/sda9

/dev/sda9:            2560  2588

На этом этапе вы можете либо подождать, пока все открытые файлы не освободятся, либо выполнить "ленивое" демонтирование, указав опцию -l. Такой способ демонтирования немедленно удаляет файловую систему из дерева каталогов, а также все ссылки на нее по мере того, как она освобождается.

Пространство подкачки

При обсуждении fstab вы могли обратить внимание на то, что пространство подкачки не имеет точки монтирования. В процессе монтирования обычно активируется пространство подкачки, определенное в файле /etc/fstab (если не используется опция noauto). Чтобы вручную управлять пространством подкачки в работающей системе (например, если добавляется новый раздел подкачки), используйте команды swapon и swapoff. Для получения подробной информации обратитесь к man-странцам.

Для просмотра пространств подкачки, доступных в текущий момент, выполните команду cat /proc/swaps или swapon -s, как показано в листинге 13.

Листинг 10. Просмотр пространства подкачки

[ian@echidna ~]$ swapon -s

Filename                                Type                Size        Used        Priority

/dev/sdb1                               partition        514044        0        -1

/dev/sdb5                               partition        4192928        0        -2

[ian@echidna ~]$ cat /proc/swaps

Filename                                Type                Size        Used        Priority

/dev/sdb1                               partition        514044        0        -1

/dev/sdb5                               partition        4192928        0        -2

На этом мы завершаем знакомство с монтированием устройств в Linux.

Практическая работа №2

Тема: Значение log-файлов для системного администратора

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

Основное вместилище логов по умолчанию (и этого правила лучше придерживаться) — каталог /var/log/.

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

• /var/log/messages — основной журнал событий. Включает в себя события всего системного ПО, этапы загрузки не связанные с ядром.
• /var/log/dmesg — журнал событий загрузки, включает в себя события ядра, инициализацию аппаратной части и подключения дополнительных устройств.
• /var/log/secure — события системы безопасности. Включает в себя журналы аутентификации. Если вы подозреваете, что к системе был осуществлен несанкционированный доступ, этот файл нужно проверить в первую очередь.
• /var/log/audit/audit.log — журнальный файл SELinux подсистемы.
• /var/log/yum.log — журнал установщика yum.
• /var/log/boot.log — журнал загрузки системы.
• /var/log/httpd/ — каталог с логами веб-сервера и т.д.

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

# tail /var/log/messages

выведет последние 10 записей файла. Если нужно изменить число выводимых строк, указывается параметр -n <число>.

Кстати, отобразить  последние записи и обновляться по мере появления новых записей можно с использованием ключа -f:

# tail -f /var/log/messages

Когда в файл поступит новое событие, оно тут же отобразится на экране в терминале. Выход из этого режиме — Ctrl+C.

В редких случаях, но всё-таки бывает, нужно вывести не последние, а первые записи. Для этого служит команда head, имеющая похожий синтаксис, что и tail.

Стоит сказать, что логи в системе могут порождаться как локальными процессами или ядром, так и приходит с других узлов. Приходят они соответственно через сокет /dev/log, либо на 514/udp порт/

Syslog и его конфигурация

Конфигурационный файл syslog.conf (rsyslog.conf) расположен в каталоге /etc/ и представляет собой список правил, по которым демон будет фильтровать приходящие сообщения и раскидывать их по местам.

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

Конфигурационный файл syslog.conf

Вот пример такого файла на моём CentOS 5.3

Получая сообщение через локальный сокет или по сети, демон syslogd проверяет совпадения источника и приоритета этого сообщения с описанными в конфиг файле. Причём, сообщение проверяется сразу по всем правилам последовательно, а не до первого совпадения, что позволяет выполнить различные действия над сообщением (фасовка в журналы и отправка по сети дальше).

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

Возможно использование служебных конструкций типа * (любой источник или уровень), none (никакой уровень для конкретного источника), ! (отрицание), = (только этот уровень).

Возьмём к примеру строку:

authpriv.*  /var/log/secure

Если в приходящем сообщении в качестве источника будет authpriv.error (например), то это сообщение запишется в журнал /var/log/secure.

Уровни важности

Теперь, что касается источников сообщений:

Ну и теперь, что касается действия.

1. Отправка в обычный файл — указывается путь к файлу-источнику. Если необходимо отключить синхронизацию файла после дозаписи, перед путём ставится дефис. Отключенная синхронизация повышает производительность на нагруженных логах, но может потерять данные.
2. Отправка в именованный канал, указывается символ пайпа | и путь к каналу.
3. Отправка в терминал /dev/console.
4. Отправка на удалённый сервер, указывается символ @ и имя-порт хоста.

Сейчас уже существуют и более гибкие продукты вроде syslog-ng (next generation), позволяющие сортировать по регулярным выражениям и многое другое.

Ротация логов

Ротация — периодическое обновление файлов журналов, при этом старые журналы сохраняются и сжимаются, а для записи событий создается новый файл. Именно этим и занимается программа logrotate, которая, как правило, запускается планировщиком.

Конфигурация содержится в файле /etc/logrotate.conf

Информацию по настройке этого сервиса можно найти так:

# man logrotate

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

Практическая работа № 3

Тема: Установка и настройка DHCP сервера на Linux CentOS 7

Базовая настройка DHCP

Устанавливаем DHCP:

yum install dhcp

Теперь откроем на редактирование конфигурационный файл:

vi /etc/dhcp/dhcpd.conf

И внесем в него, примерно, следующее:

subnet 192.168.0.0 netmask 255.255.255.0 {
  range 192.168.0.100 192.168.0.200;
  option domain-name-servers 192.168.0.10, 192.168.0.11;
  option domain-name "dmosk.local";
  option routers 192.168.0.1;
  option broadcast-address 192.168.0.255;
  default-lease-time 600;
  max-lease-time 7200;
}

* где

• subnet обозначает сеть, в области которой будет работать данная группа настроек; 
• range — диапазон, из которого будут браться IP-адреса; 
• option domain-name-servers — через запятую перечисленные DNS-сервера; 
• option domain-name — суффикс доменного имени; 
• option routers — шлюз по умолчанию; 
• option broadcast-address — адрес сети для широковещательных запросов; 
• default-lease-time, max-lease-time — время и максимальное время в секундах, на которое клиент получит адрес, по его истечению будет выполнено продление срока.

** все примеры настроек можно увидеть в файле /usr/share/doc/dhcp*/dhcpd.conf.example (вместо * будет версия установленного dhcp).

Разрешаем автозапуск сервиса:

systemctl enable dhcpd

и запускаем его:

systemctl start dhcpd

Добавляем правило в firewalld:

firewall-cmd --permanent --add-service=dhcp

firewall-cmd --reload

Определенный интерфейс для работы

Если в системе присутствует несколько сетевых адаптеров, а сервер DHCP должен работать только для определенных, открываем на редактирование следующий файл:

vi /etc/sysconfig/dhcpd

И добавляем в него следующее:

DHCPDARGS=ens32

* в данном примере сервер будет работать только для интерфейса ens32.

Перезапускаем сервис:

systemctl restart dhcp

Резервирование IP

Резервирование создается по MAC-адресу сетевого адаптера.

Пример настройки dhcpd.conf:

vi /etc/dhcp/dhcpd.conf

host host1 {
    hardware ethernet 28:10:7B:27:C2:A0; fixed-address 192.168.0.101;
}
host host2 {
    hardware ethernet 28:10:7B:27:C2:A1; fixed-address 192.168.0.102;
}

* где host1 — имя узла, для когорого резервируем адрес (не обязательно должен совпадать с реальным); 28:10:7B:27:C2:A0 — mac-адрес; 192.168.0.101 — IP, который будет назначать узлу. Аналогичо, для второго узла.

Подключение конфигурационных файлов

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

vi /etc/dhcp/dhcpd.conf

include "/etc/dhcp/conf.d/subnets.conf";

Список арендованных адресов

Для просмотра списка адресов, которые были выданы DHCP-сервером вводим команду:

cat /var/lib/dhcpd/dhcpd.leases

Настройка логов

По умолчанию, сервер dhcp ведет лог в файле /var/log/messages, что не очень удобно, так как это общий лог-файл, в котором может находиться много записей.

Для того, чтобы сервер сохранял записи в отдельный файл, открываем на редактирование rsyslog.conf:

vi /etc/rsyslog.conf

И добавляем следующее:

local6.*       /var/log/dhcp.log

Далее открываем конфигурационный файл dhcp:

vi /etc/dhcp/dhcpd.conf

И добавляем:

log-facility                    local6;

Перезапускаем сервисы:

systemctl restart dhcpd

systemctl restart rsyslog

Резервирование IP-адреса на сервере DHCP в Linux

Резервирование DHCP — это специальная настройка, которая позволит одному и тому же устройству выдавать один и тот же IP-адрес. Закрепление происходит по MAC-адресу.

Настройка DHCP

Открываем конфигурационный файл:

vi /etc/dhcp/dhcpd.conf

И либо добавляем группу хостов внутрь настройки pool:

...
pool {
    range 192.168.0.10 192.168.0.200;
    group {
        host host1 { hardware ethernet 28:10:7B:27:C2:A0; fixed-address 192.168.0.15; }
        host host2 { hardware ethernet F0:7D:68:05:E9:11; fixed-address 192.168.0.20; }
    }
}
...

либо выносим настройки за пределы subnet:

subnet 192.168.0.0 netmask 255.255.255.0 {
    ...
}

host host1 {
    hardware ethernet 28:10:7B:27:C2:A0; fixed-address 192.168.0.15;
}
host host2 {
    hardware ethernet F0:7D:68:05:E9:11; fixed-address 192.168.0.20;
}

* в данных примерах, для устройства с MAC-адресом 28:10:7B:27:C2:A0 закреплен IP-адрес 192.168.0.15; за F0:7D:68:05:E9:11 — 192.168.0.20.

После необходимо перезапустить сервер DHCP командой:

systemctl reload dhcpd

или: 

service dhcpd reload

Проверить список выданных адресов можно командой:

cat /var/lib/dhcpd/dhcpd.leases

Практическая работа №5

Тема: SELinux в CentOS основные моменты

SELinux — это система принудительного контроля доступа, работающая на уровне ядра Linux.

Надо сказать, что до этого мы знали две стандартные модели разграничения прав: DAC (избирательное управление доступом) и ACL (списки доступа). Но порой этого оказывается недостаточно. Здесь важно помнить, что политики (а правила здесь называются политиками) проверяются после того, как были проверены DAC и ACL. То есть если запрещен доступ на уровне DAC прав, то до SELinux даже не дойдёт дело.

Режимы работы

В SELinux имеется три режима работы:

1. Enforcing — основной режим работы. В этом режиме все действия, которые приводят к нарушению установленных политик логируются и запрещаются.
2. Permissive — отладочный режим. В этом режиме все действия, которые приводят к нарушению установленных политик так же логируются, но выполняются.
3. Disabled — SELinux не проверяет политики доступа.

Проверить, в каком режиме работает SELinux достаточно просто. Есть целых две команды: getenforce или sestatus:

Получить статус SELinux

Установить режим по умолчанию можно в конфиг-файле /etc/selinux/config

Режим SELinux по умолчанию

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

Овчинка стоит выделки только на Enterprise серверах, где безопасность выходит на первое место перед удобством, на пользовательских же машинах эта система может доставлять определенные неудобства. Хотя, смотря как к ней подойти. Для всех популярных сервисов уже заготовлены базовые политики. Политику видно по контексту. Те процессы, для которых политики не определены — выполняются в домене unconfined_t.

Терминология SELinux

Чтобы далее понимать о чём идет речь, необходимо совершенно определенно пояснить несколько моментов:

• Домен — это список действий, которые может выполнить процесс.
• Тип — список действий, которые можно выполнить, обращаясь к объекту. Здесь объектом может служить и файл и каталог и поток.
• Роль — список доменов, которые могут быть использованы.
• Контекст — полный перечень (домен, тип, роль) какого-либо объекта.

Как контролируется доступ в SELinux

Принято выделять три модели управления доступом:

1. Type Enforcement (TE) — основной тип. Для каждого объекта контекст настраивается детально.
2. Role-Based Access Control (RBAC) — расширенный (TE) — здесь права реализуются при помощи так называемых «ролей». На мой взгляд, нечто похожее реализовано в Windows с группами пользователей.
3. MultiLevel Security (MLS) — многоуровневая модель безопасности. Каждому объекту в системе присваивается некий уровень. В зависимости от соотношения этих уровней и определяется дальнейший результат операции.

Контекст безопасности определяется теми же утилитами, что и права доступа, (ls, ps и т.д.), с использованием ключа -Z.

На прошлом уроке я создавал HTTP-сервер. Посмотрим, какой контекст у индексного файла:

# ls -Z /var/www/linux-my.ru/index.html

Проверяем контекст файла

Увидим метки root:object_r:httpd_sys_content_t

Метки контекста приводятся в формате user:role:type:mls, где mls зачастую скрыто.

Чтож, посмотрим, какой контекст у процесса httpd:

# ps axZ | grep httpd

Смотрим контекст процесса

Как видим, у процесса указан домен httpd_t. Это значит, что процесс httpd сможет получить доступ к файлам с типом httpd_sys_content_t. А если вдруг веб-сервер будет сломан, сможет ли злоумышленник получить с помощью него…скажем….файл из домашнего каталога пользователя? Проверим:

Контекст файла в домашнем каталоге

Здесь тип указан как user_home_t — по умолчанию такой контекст накладывается на все пользовательские файлы. Но это так же означает, что веб-сервер не сможет получить доступ к пользовательским файлам даже на чтение. Даже если у файла будет стоять 777 атрибуты. Это убережет от значительной потери документов, если веб, например, сервер, будет скомпрометирован злоумышленником или неправильно настроен.

Пример блокирования SELinux

Всё хорошо, но как вот проверить настоящую работу этой системы? Для этого я смоделировал ситуацию из предыдущей статьи с веб-сервером. Модифицируем наш виртуальный хост backup.com. Создадим новый каталог:

# mkdir /home/site.ru

И создадим в нём индексный файл:

# echo '

SITE.RU

Далее, оформим виртуальный хост:

Виртуальный хост

Само-собой подправим /etc/hosts. Перезагрузим сервер

# service httpd restart

и попытаемся открыть сайт:

Сайт не открывается

Что? Почему тестовая страница? Пойдём в логи, путь к которым указан в виртуальном хосте:

Читаем лог об ошибках apache

Первая же запись: Permission denied: access to /index.html denied — доступ запрещён. Хм.. Интересно, чем это? Взглянем на лог аудита:

Лог аудита SELinux

Интересующие нас события помечаются типом AVC. Я подчеркнул интересные моменты: доступ запрещен. Файл /home/site.ru/index.html, контекст источника httpd_t, контекст цели: user_home_t. Вот и несовпадение! Естественно, что доступ не был получен. Но не беда.

Контекст файла

Проверили контекст файла:

# ls -Z /home/site.ru/

Увидели user_home_t. Будем менять его на необходимый (httpd_sys_content_t):

# chcon -v --type=httpd_sys_content_t -R /home/site.ru/

Меняем контекст

Теперь пробуем открыть сайт:

Сайт открылся!

Всё получилось! Теперь вы, надеюсь, представляете, как работает SELinux и где искать логи безопасности.

Отключить SELinux

Для отключения SELinux в CentOS много мудрить не надо. Просто переводим его в режим Permissive.

# setenforce 0

или равнозначно

# setenforce Permissive

Практическая работа №6

Тема: Начальная настройка CentOS 7

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

Начальная настройка CentOS 7

Итак, у нас имеется:

# uname -a

Linux zeroxzed.ru 3.10.0-123.20.1.el7.x86_64 #1 SMP Thu Jan 29 18:05:33 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux

Первым делом обновим базовую систему:

# yum -y update

Для удобства администрирования, я всегда устанавливаю Midnight Commander, или просто mc:

# yum -y install mc

Дальше нам пригодятся сетевые утилиты. В минимальной настройке вы будете удивлены, когда наберете команду:

# ifconfig

И увидите ответ:

-bash: ifconfig: command not found

Вместо ifconfig в CentOS 7 теперь утилита ip.

Сделаем это:

# yum -y install net-tools.x86_64

Теперь, чтобы у нас работали команды nslookup или, к примеру, host необходимо установить пакет bind-utils. Если этого не сделать, то на команду:

# nslookup

Будет вывод:

-bash: nslookup: command not found

Так что устанавливаем bind-utils:

# yum -y install bind-utils

Отключаем SELinux. Так что отключаем:

# mcedit /etc/sysconfig/selinux

Меняем значение
SELINUX=disabled
Чтобы изменения вступили в силу, перезагружаемся:

# reboot

Можно без перезагрузки применить отключение SElinux:

# setenforce 0

Указываем сетевые параметры

Теперь произведем настройку сети в CentOS.  Для этого открываем файл /etc/sysconfig/network-scripts/ifcfg-eth0

# mcedit /etc/sysconfig/network-scripts/ifcfg-eth0

В поле IPADDR вводим свой адрес, в NETMASK маску сети, в GATEWAY шлюз, DNS1 адрес днс сервера. Сохраняем файл и перезапускаем сеть для применения настроек:

# /etc/init.d/network restart

Настраиваем firewall

Сейчас мы быстро и просто настроим firewall. В CentOS 7 в качестве фаервола выступает iptables. По-умолчанию он запущен. Чтобы посмотреть текущие правила, нужно ввести команду:

# iptables -L -v -n

Сразу хочу предупредить, что не имея доступа к консоли сервера, настраивать firewall плохая идея. Даже если вы очень хорошо понимаете что делаете и проделывали подобное много раз, все равно есть шанс остаться без доступа к серверу. Так что первым делом перед настройкой iptables проверяем доступ к консоли через KVM или физически.

В 7-й версии CentOS для управления iptables разработан новый инструмент под названием firewalld и все управление производится через него. Но CentOS зачем-то придумали firewalld, в Ubuntu стоит ufw, но суть одна и та же — это утилиты для конфигурирования iptables, который один и тот же во всех дистрибутивах.  Так что для начала остановим и отключим firewalld:

# systemctl stop firewalld

# systemctl disable firewalld

rm '/etc/systemd/system/dbus-org.fedoraproject.FirewallD1.service'

rm '/etc/systemd/system/basic.target.wants/firewalld.service'

Установим утилиты для iptables:

# yum -y install iptables-services

Включим автозапуск iptables:

# systemctl enable iptables

Теперь создадим файл /etc/iptables_rules.sh следующего содержания:

#!/bin/bash

#

# Объявление переменных

export IPT="iptables"

# Интерфейс который смотрит в интернет

export WAN=eth0

export WAN_IP=149.154.71.205

# Очистка всех цепочек iptables

$IPT -F

$IPT -F -t nat

$IPT -F -t mangle

$IPT -X

$IPT -t nat -X

$IPT -t mangle -X

# Установим политики по умолчанию для трафика, не соответствующего ни одному из правил

$IPT -P INPUT DROP

$IPT -P OUTPUT DROP

$IPT -P FORWARD DROP

# разрешаем локальный траффик для loopback

$IPT -A INPUT -i lo -j ACCEPT

$IPT -A OUTPUT -o lo -j ACCEPT

# Разрешаем исходящие соединения самого сервера

$IPT -A OUTPUT -o $WAN -j ACCEPT

# Состояние ESTABLISHED говорит о том, что это не первый пакет в соединении.

# Пропускать все уже инициированные соединения, а также дочерние от них

$IPT -A INPUT -p all -m state --state ESTABLISHED,RELATED -j ACCEPT

# Пропускать новые, а так же уже инициированные и их дочерние соединения

$IPT -A OUTPUT -p all -m state --state ESTABLISHED,RELATED -j ACCEPT

# Разрешить форвардинг для уже инициированных и их дочерних соединений

$IPT -A FORWARD -p all -m state --state ESTABLISHED,RELATED -j ACCEPT

# Включаем фрагментацию пакетов. Необходимо из за разных значений MTU

$IPT -I FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu

# Отбрасывать все пакеты, которые не могут быть идентифицированы

# и поэтому не могут иметь определенного статуса.

$IPT -A INPUT -m state --state INVALID -j DROP

$IPT -A FORWARD -m state --state INVALID -j DROP

# Приводит к связыванию системных ресурсов, так что реальный

# обмен данными становится не возможным, обрубаем

$IPT -A INPUT -p tcp ! --syn -m state --state NEW -j DROP

$IPT -A OUTPUT -p tcp ! --syn -m state --state NEW -j DROP

# Открываем порт для ssh

$IPT -A INPUT -i $WAN -p tcp --dport 22 -j ACCEPT

# Открываем порт для DNS

$IPT -A INPUT -i $WAN -p udp --dport 53 -j ACCEPT

# Открываем порт для NTP

$IPT -A INPUT -i $WAN -p udp --dport 123 -j ACCEPT

# Логирование

# Все что не разрешено, но ломится отправим в цепочку undef

$IPT -N undef_in

$IPT -N undef_out

$IPT -N undef_fw

$IPT -A INPUT -j undef_in

$IPT -A OUTPUT -j undef_out

$IPT -A FORWARD -j undef_fw

# Логируем все из undef

$IPT -A undef_in -j LOG --log-level info --log-prefix "-- IN -- DROP "

$IPT -A undef_in -j DROP

$IPT -A undef_out -j LOG --log-level info --log-prefix "-- OUT -- DROP "

$IPT -A undef_out -j DROP

$IPT -A undef_fw -j LOG --log-level info --log-prefix "-- FW -- DROP "

$IPT -A undef_fw -j DROP

# Записываем правила

/sbin/iptables-save  > /etc/sysconfig/iptables

В принципе, добавить нечего, в файле даны все комментарии. В таком виде, логи всего заблокированного будут писаться в файл /var/log/messages и записей там будет очень много. Так что в обычной работе эти строки нужно закомментировать, и использовать только во время отладки.

Делаем файл c правилами исполняемым и запускаем:

# chmod 0740 /etc/iptables_rules.sh

# /etc/iptables_rules.sh

Проверяем, применились ли правила:

# iptables -L -v -n

При каждом запуске файла с правилами iptables, все изменения записываются в файл /etc/sysconfig/iptables и применяются при загрузке системы.

Настройка SSH в CentOS 7

Дальше внесем некоторые изменения в работу ssh для увеличения безопасности. По-умолчанию, сервис работает на 22 порту и если все оставить как есть, то мы получим огромное количество попыток авторизоваться. Боты сканят непрерывно интернет и подбирают пароли к ssh. Чтобы обезопасить себя от сканов простых ботов, изменим порт, на котором работает ssh. Можно выбрать любой пятизначный номер, это не принципиально. От автоматического сканирования это защитит. Повесим демон ssh на 25333 порт. Для этого редактируем файл /etc/ssh/sshd_config

# mcedit /etc/ssh/sshd_config

Раскомментируем строку Port 22 и заменим значение 22 на 25333.
Разрешаем подключаться по ssh пользователю root. Чтобы разрешить пользователю root подключаться по ssh, раскомментируйте строку PermitRootLogin yes.

Сохраняем файл. Теперь обязательно изменяем настройки iptables, добавляем в разрешенные подключения вместо 22 порта 25333. Если этого не сделать, то после перезапуска sshd мы потеряем удаленный доступ к серверу. Итак, открываем /etc/iptables_rules.sh и меняем в строке

$IPT -A INPUT -i $WAN -p tcp --dport 22 -j ACCEPT

22 на 25333 и исполняем файл. Наше текущее соединение не оборвется, так как оно уже установлено, но заново подключиться по ssh к 22 порту уже не получится.

Перезапускаем sshd:

# systemctl restart sshd

Проверяем какой порт слушает sshd:

# netstat -tulpn | grep sshd

tcp        0      0 0.0.0.0:25333           0.0.0.0:*               LISTEN      1799/sshd

tcp6       0      0 :::25333                :::*                    LISTEN      1799/sshd

Если вывод такой же как у меня, то все в порядке, теперь к ssh можно подключаться по 25333 порту.

Настраиваем время

Узнать, какое время на сервере можно с помощью команды date:

# date

Чтобы сменить часовой пояс, необходимо выбрать подходящий файл часовой зоны в /usr/share/zoneinfo. В случае, если у вас часовой пояс Москвы, выполните следующее:

# mv /etc/localtime /etc/localtime.bak

# ln -s /usr/share/zoneinfo/Europe/Moscow /etc/localtime

Либо можете воспользоваться специальной утилитой, которая входит в комплект CentOS 7. Делает она ровно то же самое:

# timedatectl set-timezone Europe/Moscow

В CentOS 7 есть утилита для синхронизации времени chrony. В стандартной установке она должна быть установлена в системе, в минимальной ее нет. Если у вас она не стоит, то устанавливайте вручную:

# yum install -y chrony

Запускаем chrony и добавляем в автозагрузку:

# systemctl start chronyd

# systemctl enable chronyd

Проверяем, нормально ли запустился:

# systemctl status chronyd

● chronyd.service - NTP client/server

Loaded: loaded (/usr/lib/systemd/system/chronyd.service; enabled; vendor preset: enabled)

Active: active (running) since Fri 2016-08-05 00:33:09 MSK; 52min left

Main PID: 667 (chronyd)

CGroup: /system.slice/chronyd.service

└─667 /usr/sbin/chronyd

Aug 05 00:33:09 centos.local systemd[1]: Starting NTP client/server...

Aug 05 00:33:09 centos.local chronyd[667]: chronyd version 2.1.1 starting (+CMDMON +NTP +REFCLOCK +RTC +PRIVDROP +DEBUG +ASYNCDNS +IPV6 +SECHASH)

Aug 05 00:33:09 centos.local chronyd[667]: Generated key 1

Aug 05 00:33:09 centos.local systemd[1]: Started NTP client/server.

Aug 05 00:33:26 centos.local chronyd[667]: Selected source 85.21.78.91

Aug 05 00:33:26 centos.local chronyd[667]: System clock wrong by -3595.761368 seconds, adjustment started

Aug 04 23:33:30 centos.local chronyd[667]: System clock was stepped by -3595.761368 seconds

Все в порядке, сервис работает. После запуска он автоматически синхронизирует время.

Для синхронизации времени вы можете воспользоваться более привычно программой, которая присутсвует практически во всех unix дистрибутивах — ntp. Устанавливаем утилиту синхронизации времени ntp в CentOS:

# yum install -y ntp

Разово синхронизируем время:

# /usr/sbin/ntpdate pool.ntp.org

 Запустим демон синхронизации и запишем его запуск в автозагрузку:

# systemctl start ntpd

# systemctl enable ntpd

ln -s '/usr/lib/systemd/system/ntpd.service' '/etc/systemd/system/multi-user.target.wants/ntpd.service'

Теперь наши часы будут автоматически синхронизироваться с сервером времени.

Не используйте одновременно оба демона синхронизации времени — chrony и ntp. Выберите какой-нибудь один.

Добавление репозиториев

Для инсталляции различного софта необходимо подключить репозитории в CentOS. Наиболее популярные это EPEL и rpmforge, поэтому добавим их. Сначала ставим EPEL. С ним все просто, он добавляется из стандартного репозитория:

# yum -y install epel-release

Устанавливаем rpmforge:

# rpm --import http://apt.sw.be/RPM-GPG-KEY.dag.txt

# yum -y install http://pkgs.repoforge.org/rpmforge-release/rpmforge-release-0.5.3-1.el7.rf.x86_64.rpm

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

# yum -y install http://repository.it4i.cz/mirrors/repoforge/redhat/el7/en/x86_64/rpmforge/RPMS/rpmforge-release-0.5.3-1.el7.rf.x86_64.rpm

Установка iftop, atop, htop на CentOS 7

И напоследок добавим несколько полезных утилит, которые могут пригодиться в процессе эксплуатации сервера.

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

# yum -y install iftop

И два интересных диспетчера задач, я чаще всего пользуюсь htop, но иногда пригодится и atop. Ставим оба, сами посмотрите, разберетесь, что вам больше нравится, подходит:

# yum -y install htop

# yum -y install atop

Вот как выглядит htop:

Заключение

Мы выполнили некоторые начальные шаги по настройке сервера. Полезно после настройки сразу же подключить сервер к системе мониторинга. Либо настроить ее, если у вас еще нет.

Практическая работа№7

Тема: Начинаем работу с веб-сервером HTTP

Как известно, веб-сервер необходим для передачи гипертекста (сейчас уже не только). Мы будем ставить простенький Apache без особого ковыряния в настройках. Ну, пожалуй, ещё виртуальные хосты сделаем. PHP прикручивать будем позже.

# yum -y install httpd

Установка Apache

После того, как установка будет завершена, идём в конфиг-файл: /etc/httpd/conf/httpd.conf

А так же создадим два виртуальных хоста: linux-my.ru и backup.com, которые будут ссылаться в различные каталоги. Нам тут потребуются директивы DocumentRoot (указывает каталог с файлами сайтов), ServerAlias (имя сайта), а так же логи. Журнальные файлы иначе.

Настраиваем виртуальные хосты

Прописываем алиасы в файл hosts. Это для того, чтобы наш узел отвечал на имена linux-my и backup (поскольку DNS у нас нет).

Не забываем создать каталоги и индексные файлы для наших «сайтов»:

Создаем каталоги и индексные файлы

Ну и каталог под логи создать. Запускаем сервер:

# service httpd start

и открываем в браузере любой сайт:

Открываем сайт

Практическая работа №9

Тема: Установка и настройка vsftpd на CentOS 7

Введение

Рассмотрим настройку ftp сервера на примере vsftpd. Сделаем несколько конфигураций:

Самая быстрая и простая. В качестве пользователей ftp будут системные пользователи.

Более сложная конфигурация, где пользователи будут виртуальные, хранить их будем в отдельном файле.

Вариант с виртуальными пользователями, но хранить мы их будем в mysql базе.

Работать будем на следующем сервере:

Простая настройка ftp в CentOS 7

Если у вас уже есть готовый сервер, то сразу приступайте к установке vsftpd. Если нет, то рекомендую две подходящие статьи для предварительной подготовки: подробная установка centos 7 и базовая настройка сервера.

Начинаем традиционно с обновления системы:

# yum -y update

Устанавливаем vsftpd:

# yum -y install vsftpd

Переходим к настройке. Я использую следующую схему работы ftp сервера с системными пользователями. Пользователю root разрешаю ходить по всему серверу. Всем остальным пользователям только в свои домашние директории. Анонимных пользователей отключаю.

Открываем конфиг сервера /etc/vsftpd/vsftpd.conf

# mcedit /etc/vsftpd/vsftpd.conf

и приводим его к следующему виду vsftpd.conf:

# Запуск сервера в режиме службы

Listen=YES

# Работа в фоновом режиме

Background=YES

#Имя pam сервиса для vsftpd

pam_service_name=vsftpd

#Входящие соединения контроллируются через tcp_wrappers

Tcp_wrappers=YES

#Запрещает подключение анонимных пользователей

Anonymous_enable=NO

#Каталог куда будут попадать анонимные пользователи, если они разрешены

#anon_root=/ftp

#Разрешает вход для локальных пользователей

Local_enables=YES

#Разрешает команды на запись и изменение

Write_enable=YES

#Указывает исходящим с сервера соединениям использовать 20-й порт

Connect_from_port_20=YES

#Логирование всех действий на сервере

Xferlog_enable=YES

#Путь к лог-файлу

Xferlog_file=/var/log/vsftpd.log

#Включение специальных ftp команд, некоторые клиенты без этого могут зависать

Async_abor_enable=YES

#Локальные пользователи по умолчанию не могут выходить за пределы своего домашнего каталога

Chroot_local_user=YES

#Разрешить список пользователей, которые могут выходить за пределы домашнего каталога

Chroot_list_enable=YES

#Cписок пользователей, которым разрешен выход из домашнего каталога

Chroot_list_file=/etc/vsftpd/chroot_list

#Разрешить запись в корень chroot каталога пользователя

Allow_writeable_chroot=yes

#Контроль доступа к серверу через отдельный список пользователей

Userlist_enable=YES

#Файл со списками разрешенных к подключению пользователей

Userlist_file=/etc/vsftpd/user_list

#Пользователь будет отклонен, если его нет в user_list

Userlist_deny=NO

#Директория с настройками пользователей

User_config_dir=/etc/vsftpd/users

#Показывать файлы, начинающиеся с точки

Force_dot_files=YES

#Маска прав доступа к создаваемым файлам

Local_umask=022

#Порты для пассивного режима работы

Pasv_min_port=49000

Pasv_max_port=55000

Создаем необходимых пользователей, файлы и каталоги для установленной конфигурации. Добавим тестового пользователя ftp в систему:

# useradd -s /sbin/nologin ftp-user

# passwd ftp-user

Пользователя создаем без оболочки. Тут сразу можно указать в качестве домашней директории необходимый каталог, в котором будет работать пользователь. Я специально этого не делаю, чтобы продемонстрировать работу пользовательских настроек в отдельном файле. Пользователь будет создан со стандартным домашним каталогом в /home, но при работе по ftp он будет направлен в другой каталог, который мы ему укажем через файл пользовательских настроек vsftpd.

Создаем каталог для персональных настроек пользователей:

# mkdir /etc/vsftpd/users

В каталоге можно будет создать отдельно файлы с именами пользователей и передать им персональные параметры. Для примера создадим файл с именем пользователя ftp-user и укажем его домашний каталог:

# touch /etc/vsftpd/users/ftp-user

# echo 'local_root=/ftp/ftp-user/' >> /etc/vsftpd/users/ftp-user

Не забываем создать этот каталог и назначить ему владельца:

# mkdir /ftp && chmod 0777 /ftp

# mkdir /ftp/ftp-user && chown ftp-user. /ftp/ftp-user/

Создаем файл c пользователями, которым можно выходить за пределы домашнего каталога:

# touch /etc/vsftpd/chroot_list

Добавляем туда рута:

# echo 'root' >> /etc/vsftpd/chroot_list

Создаем файл со списком пользователей ftp, которым разрешен доступ к серверу:

# touch /etc/vsftpd/user_list

# echo 'root' >> /etc/vsftpd/user_list && echo 'ftp-user' >> /etc/vsftpd/user_list

Этим списком мы можем ограничить доступ к ftp серверу системных пользователей, которым туда ходить не нужно. Осталось только создать файл для логов:

# touch /var/log/vsftpd.log && chmod 600 /var/log/vsftpd.log

Все готово для работы. Добавляем vsftpd в автозагрузку и запускаем:

# systemctl enable vsftpd

# systemctl start vsftpd

Проверяем, запустился ли он:

# netstat -tulnp | grep vsftpd

tcp 0 0 0.0.0.0:21 0.0.0.0:* LISTEN 19505/vsftpd

Все в порядке, можно подключаться клиентом.

Прежде чем начнете проверять подключение, убедитесь, что у вас настроен firewall. Либо выключите его, либо настройте для разрешения подключений по ftp. Узнать как правильно настроить iptables для работы ftp сервера можно в отдельной статье, посвященной настройке iptables. Там есть все необходимые пояснения и примеры.

Заходим под пользователем root и смог прогуляться по всей файловой системе.

Пользователь ftp-user ограничен своим домашним каталогом, указанном в индивидуальном файле с параметрами. Выйти за его пределы он не может. В лог файле отражены все действия пользователей на сервере: загрузка и скачивание файлов.

Настройка vsftpd с виртуальными пользователями

Рассмотрим вариант, когда пользователи ftp сервера не должны пересекаться с локальными. В данном примере будут работать только виртуальные пользователи. Чтобы авторизовать виртуальных пользователей, установим дополнительный пакет compat-db:

# yum -y install compat-db

На всякий случай сохраните оригинальный pam.d файл, если захотите снова вернуться к системным пользователям:

# cp /etc/pam.d/vsftpd /etc/pam.d/vsftpd.orig

Нужно изменить pam файл /etc/pam.d/vsftpd, приведя его к следующему виду:

# mcedit /etc/pam.d/vsftpd

auth required pam_userdb.so db=/etc/vsftpd/virt_users

account required pam_userdb.so db=/etc/vsftpd/virt_users

session required pam_loginuid.so

# mcedit /etc/vsftpd/vsftpd.conf

Рисуем следующий конфиг для vsftpd vsftpd.conf Создаем файл с виртуальными пользователями:

# touch /etc/vsftpd/virt_users

Добавляем туда в первую строку имя пользователя, во вторую его пароль. В конце не забудьте перейти на новую строку, это важно. Файл должен быть примерно таким:

ftp-virt1

password1

ftp-virt2

password2

Сохраняем файл и генерируем локальное хранилище учеток:

# db_load -T -t hash -f /etc/vsftpd/virt_users /etc/vsftpd/virt_users.db

Должен появиться файл virt_users.db.

Нужно создать каталоги для этих пользователей:

# mkdir /ftp/ftp-virt1 /ftp/ftp-virt2

Для папки /ftp надо назначить соответствующего владельца, от которого ftp сервер будет пускать виртуальных пользователей:

# chown -R ftp. /ftp

На этом настройка виртуальных пользователей ftp закончена. Перезапускаем vsftpd и пробуем залогиниться:

# systemctl restart vsftpd

Создадим скрипт, чтобы было удобно добавлять новых пользователей, предлагаю воспользоваться:

# mcedit /etc/vsftpd/add_virt_user.sh

#!/bin/sh

echo -n "Enter name of virtual user: "

read virtuser

echo -n "Enter password: "

read virtpass

mkdir /ftp/$virtuser

chown ftp. /ftp/$virtuser

touch /etc/vsftpd/users/$virtuser

echo "$virtuser" >> /etc/vsftpd/virt_users

echo "$virtpass" >> /etc/vsftpd/virt_users

db_load -T -t hash -f /etc/vsftpd/virt_users /etc/vsftpd/virt_users.db

Делаете файл исполняемым и запускаете:

# chmod 0700 /etc/vsftpd/add_virt_user.sh

# /etc/vsftpd/add_virt_user.sh

Enter name of virtual user: ftp-virt2

Enter password: 123456

Все, пользователь добавлен, можно сразу им заходить. Вот так легко и просто настраиваются виртуальные пользователи в vsftpd. Рассмотрим теперь третий вариант, когда эти пользователи хранятся в mysql базе.

Хранение vsftpd пользователей в mysql

Настройка не отличается от предыдущего раздела. Конфиг один в один совпадает. Изменится только файл в pam.d. Но перед тем, как его изменить, выполним подготовительные настройки. Первым делом нам понадобится mariadb, устанавливаем ее:

# yum install -y mariadb mariadb-server

Запускаем и добавляем ее в автозагрузку:

# systemctl start mariadb

# systemctl enable mariadb.service

Выполняем скрипт первоначальной настройки mysql:

# /usr/bin/mysql_secure_installation

Подробнее о настройке mysql рассказано в статье про настройку web сервера на centos. Если вам в будущем понадобится веб сервер, можете сразу его настроить, а заодно поставить phpmyadmin, дальнейшие действия проще будет выполнить там. Но я сейчас не буду на этом останавливаться, сделаем все в консоли.

Подключаемся к mysql:

# mysql -u root -p

Создаем пользователя и базу данных для хранения учетных записей пользователей ftp:

> CREATE DATABASE vsftpd;

> GRANT SELECT ON vsftpd.* TO 'vsftpd'@'localhost' IDENTIFIED BY '12345';

> FLUSH PRIVILEGES;

Создаем таблицу учеток:

> USE vsftpd;

> CREATE TABLE `accounts` (

`id` INT NOT NULL AUTO_INCREMENT PRIMARY KEY ,

`username` VARCHAR( 30 ) NOT NULL ,

`pass` VARCHAR( 50 ) NOT NULL ,

UNIQUE (`username`)

) ENGINE = MYISAM ;

Обратите внимание на кавычки при копировании. Если будут ошибки в синтаксисе mysql, вам нужно будет их удалить и проставить заново.

Создадим сразу одного пользователя:

> INSERT INTO accounts (username, pass) VALUES('ftp-mysql', md5('123'));

Список пользователей можно посмотреть с помощью команды:

> select * from accounts;

+----+-----------+----------------------------------+

| id | username | pass |

+----+-----------+----------------------------------+

| 1 | ftp-mysql | 202cb962ac59075b964b07152d234b70 |

+----+-----------+----------------------------------+

1 row in set (0.01 sec)

Выходим из консоли mysql и создаем каталог для нового пользователя:

# mkdir /ftp/ftp-mysql && chown ftp. /ftp/ftp-mysql

Ставим модуль pam_mysql для centos 7:

# rpm -Uvh //serveradmin.ru/files/pam_mysql-0.7-0.16.rc1.fc20.x86_64.rpm

Теперь редактируем файл /etc/pam.d/vsftpd. В интернете много примеров конфигурации. Опытным путем собрал рабочий вариант:

# mcedit /etc/pam.d/vsftpd

session optional pam_keyinit.so force revoke

auth required pam_mysql.so user=vsftpd passwd=12345 host=localhost db=vsftpd table=accounts usercolumn=username passwdcolumn=pass crypt=3

account required pam_mysql.so user=vsftpd passwd=12345 host=localhost db=vsftpd table=accounts usercolumn=username passwdcolumn=pass crypt=3

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

# systemctl restart vsftpd

Если будут какие-то проблемы, то смотрите в первую очередь на работу mysql_pam в логе /var/log/audit/auditlog. У меня были такие ошибки, когда я настраивал авторизацию и она не работала:

type=USER_AUTH msg=audit(1459442408.756:724): pid=21483 uid=0 auid=4294967295 ses=4294967295 msg='op=PAM:authentication grantors=? acct="ftp-mysql" exe="/usr/sbin/vsftpd" hostname=192.168.1.100 addr=192.168.1.100 terminal=ftp res=failed'

После правильной настройки, появились такие записи:

type=CRED_ACQ msg=audit(1459442810.698:735): pid=21564 uid=0 auid=4294967295 ses=4294967295 msg='op=PAM:setcred grantors=pam_mysql acct="ftp-mysql" exe="/usr/sbin/vsftpd" hostname=192.168.1.100 addr=192.168.1.100 terminal=ftp res=success'

В логе /var/log/secure тоже может быть полезная информация. У меня было так:

Mar 31 19:39:44 vsftpd[21475]: pam_mysql - MySQL error(Unknown column 'passwd' in 'field list')

Заключение

Мы подробно рассмотрели вопрос использования vsftpd сервера с различной настройкой учетных записей.

Практическая работа № 10

Тема: Настройка iptables в CentOS 7

На защиту сервера от внешних угроз в первую очередь встает межсетевой экран, который фильтрует входящий и исходящий траффик. Настройкой iptables — частного случая фаервола на CentOS его установка и отключение.

Вступление

Iptables в настоящее время является стандартом де-факто в среде современных linux дистрибутивов.

К этому фаерволу существуют разные обвязки, которые используются для более «удобной» настройки. В ubuntu есть ufw, в centos — firewalld.

Первым делом отключим firewalld, который присутствует в centos 7 по-умолчанию сразу после установки:temctl stop firewalld

Теперь удалим его из автозагрузки, чтобы он не включился снова после рестарта:

# systemctl disable firewalld

После этого на сервере настройки сетевого экрана становятся полностью открытыми. Посмотреть правила iptables можно командой:

# iptables -L -v -n

Установка iptables

На самом деле фаервол у нас на сервере уже стоит и работает, просто нет никаких правил, все открыто. Установить нам нужно будет дополнительные утилиты управления, без которых конфигурировать iptables невозможно. Например, нельзя будет перезапустить фаервол:

# systemctl restart iptables.service

Failed to issue method call: Unit iptables.service failed to load: No such file or directory.

Или добавить в автозапуск не получится:

# systemctl enable iptables.service

Failed to issue method call: No such file or directory

Чтобы подобных ошибок не было, установим необходимый пакет с утилитами:

# yum -y install iptables-services

Теперь можно добавить iptables в автозагрузку и запустить:

# systemctl enable iptables.service

# systemctl start iptables.service

Настройка фаервола

Для управления правилами фаервола я использую скрипт. Создадим его:

# mcedit /etc/iptables.sh

Далее будем наполнять его необходимыми правилами.

Первым делом зададим все переменные, которые будем использовать в скрипте. Это не обязательно делать, но рекомендуется, потому что удобно переносить настройки с сервера на сервер. Достаточно будет просто переназначить переменные.

Перед применением новых правил, очищаем все цепочки:

Блокируем весь трафик, который не соответствует ни одному из правил:

Разрешаем весь трафик локалхоста и локалки:

Разрешаем делать ping:

Если вам это не нужно, то не добавляйте разрешающие правила для icmp.

Открываем доступ в инет самому серверу:

Если вы хотите открыть все входящие соединения сервера, то добавляйте дальше правило:

Делать это не рекомендуется, привожу просто для примера, если у вас появится такая необходимость.

Дальше разрешим все установленные соединения и дочерние от них. Так как они уже установлены, значит прошли через цепочки правил, фильтровать их еще раз нет смысла:

Теперь добавим защиту от наиболее распространенных сетевых атак. Сначала отбросим все пакеты, которые не имеют никакого статуса:

Блокируем нулевые пакеты:

Закрываемся от syn-flood атак:

Следом за этими правилами рекомендуется поставить правила на запрет доступа с определенных IP, если у вас имеется такая необходимость. Например, вас задолбал адрес 84.122.21.197 брутом ssh. Блокируем его:

Если вы не ставите ограничений на доступ из локальной сети, то разрешаем всем выход в интернет:

Следом запрещаем доступ из инета в локальную сеть:

Чтобы наша локальная сеть пользовалась интернетом, включаем nat:

Чтобы не потерять доступ к серверу, после применения правил, разрешаем подключения по ssh:

И в конце записываем правила, чтобы они применились после перезагрузки:

Мы составили простейший конфиг, который блокирует все входящие соединения, кроме ssh и разрешает доступ из локальной сети в интернет. Попутно защитились от некоторых сетевых атак.

Сохраняем скрипт, делаем исполняемым и запускаем:

# chmod 0740 /etc/iptables.sh

# /etc/iptables.sh

Выполним просмотр правил и проверим, все ли правила на месте:

# iptables -L -v -n

Обращаю ваше внимание — применять правила нужно лишь в том случае, если у вас имеется доступ к консоли сервера. При ошибке в настройках вы можете потерять доступ. Убедитесь, что в нештатной ситуации вы сможете отключить фаервол и скорректировать настройки.

Открытие портов

Теперь немного расширим нашу конфигурацию и откроем в iptables порты для некоторых сервисов. Допустим, у нас работает веб-сервер и необходимо открыть к нему доступ из интернета. Добавляем правила для веб-трафика:

Было добавлено разрешение на входящие соединения по 80-му и 443-му портам, которые использует web сервер в своей работе.

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

Для корректной работы DNS сервера, нужно открыть UDP порт 53

И так далее. По аналогии можете открыть доступ для всех необходимых сервисов.

Проброс (forward) порта

Рассмотрим ситуацию, когда необходимо выполнить проброс портов с внешнего интерфейса на какой-то компьютер в локальной сети. Допустим, вам необходимо получить rdp доступ к компьютеру 10.1.3.50 из интернета. Делаем проброс TCP порта 3389:

Если вы не хотите светить снаружи известным портом, то можно сделать перенаправление с нестандартного порта на порт rdp конечного компьютера:

Если вы пробрасываете порт снаружи внутрь локальной сети, то обязательно закомментируйте правило, которое блокирует доступ из внешней сети во внутреннюю. В моем примере это правило:

$IPT -A FORWARD -i $WAN -o $LAN1 -j REJECT

Либо перед этим правилом создайте разрешающее правило для доступа снаружи к внутреннему сервису, например вот так:

$IPT -A FORWARD -i $WAN -d 10.1.3.50 -p tcp -m tcp --dport 3389 -j ACCEPT

Включение логов

Во время настройки полезно включить логи, чтобы мониторить заблокированные пакеты и выяснять, почему отсутствует доступ к необходимым сервисам, которые мы вроде бы уже открыли.  Отправляем все заблокированные пакеты в отдельные цепочки (block_in, block_out, block_fw), соответствующие направлению трафика и маркирую в логах каждое направление. Так удобнее делать разбор полетов. Добавляем следующие правила в самый конец скрипта, перед сохранением настроек:

Все заблокированные пакеты вы сможете отследить в файле /var/log/messages.

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

Как отключить iptables

Если вы вдруг решите, что firewall вам больше не нужен, то отключить его можно следующим образом:

# systemctl stop iptables.service

Эта команда останавливает фаервол. А следующая удаляет из автозагрузки:

# systemctl disable iptables.service

Отключив сетевой экран, мы разрешили все соединения.

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

Практическая работа №12

Тема: Установка Bind 9 (named) в CentOS 7

Одним из важных сервисов, обеспечивающих функционирование современного интернета является сервис по преобразованию имени сайта в ip адрес. Настройкой реализации сервиса DNS на примере настройки Bind 9 (named) на сервере под управлением CentOS 7. Мы подготовим минимально необходимый базовый функционал и заглянем немного глубже в настройки логирования.

Что такое DNS сервер BIND

Bind — самая распространенная на текущий день реализация dns сервера, которая обеспечивает преобразование IP адресов в dns-имена и наоборот. Его также называют named.

Устанавливаем Bind 9 (named) в CentOS 7

Первым делом проверим, установлен ли у нас dns сервер в системе:

# rpm -qa bind*

 bind-libs-lite-9.9.4-14.el7.x86_64

 bind-license-9.9.4-14.el7.noarch

Сервер имен у нас будет работать в chroot окружении, так что устанавливаем соответствующие пакеты:

# yum -y install bind bind-utils bind-chroot

Еще раз обращаю внимание, что мы будем использовать bind в chroot среде для увеличения безопасности. Это накладывает определенные особенности в настройке и управлении сервером. Нужно быть внимательным в этих мелочах. Итак, запускаем bind:

# systemctl start named-chroot

# systemctl enable named-chroot

ln -s '/usr/lib/systemd/system/named-chroot.service' '/etc/systemd/system/multi-user.target.wants/named-chroot.service'

Проверяем содержимое chroot каталога:

# ls -l /var/named/chroot/etc

Все в порядке, сервер запустился, необходимые файлы созданы, все готово для настройки. Займемся ей.

Настраиваем DNS сервер в CentOS 7

Файл конфигурации нашего сервера распоашдулагается по адресу /var/named/chroot/etc/named.conf. Открываем его и приводим к следующему виду:

# mcedit /var/named/chroot/etc/named.conf

options {

listen-on port 53 { any; };

listen-on-v6 port 53 { none; };

directory "/var/named";

dump-file "/var/named/data/cache_dump.db";

allow-query { 127.0.0.1; 192.168.7.0/24; };

recursion yes;

allow-recursion { 127.0.0.1; 192.168.7.0/24; };

forwarders { 8.8.8.8; };

version "DNS Server";

managed-keys-directory "/var/named/dynamic";

pid-file "/run/named/named.pid";

session-keyfile "/run/named/session.key";

};

zone "." IN {

type hint;

file "named.ca";

};

include "/etc/named.rfc1912.zones";

include "/etc/named.root.key";

logging {

channel default_file {

file "/var/log/named/default.log" versions 3 size 5m;

severity dynamic;

print-time yes;

};

category default { default_file; };

};

Эта конфигурация обеспечит работу обычного кэширующего сервера в локальной сети. Комментарии к некоторым параметрам:

Не забудьте отредактировать правила фаервола для корректной работы DNS сервера — открыть 53 порт UDP для работы кэширующего сервера, который мы сейчас настроили, и 53 порт TCP для пересылки зон, о которых речь пойдет дальше

Поддержка собственной зоны

Допустим, нам необходимо в нашем named разместить собственную зону site1.ru. Первым делом создаем файл зоны, которую будет обслуживать dns сервер:

# mcedit /var/named/chroot/var/named/site1.ru.zone

$TTL 86400

@        IN     SOA     site1.ru. site1.ru.local. (

                        2015092502

                        43200

                        3600

                        3600000

                        2592000 )

        IN NS ns1.site1.ru.

        IN NS ns2.site1.ru.

        IN A 192.168.7.254

        IN MX 10 mx.site1.ru.

gate    IN A 192.168.7.254

mx      IN A 192.168.7.250

ns1     IN A 192.168.7.235

ns2     IN A 192.168.7.231

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

Выставляем необходимые права:

# chown root:named /var/named/chroot/var/named/site1.ru.zone

# chmod 0640 /var/named/chroot/var/named/site1.ru.zone

Дальше подключаем файл зоны в конфигурационном файле bind — /var/named/chroot/etc/named.conf:

zone "site1.ru" {

 type master;

 file "site1.ru.zone";

};

Перечитываем конфигурацию named с помощью rndc:

# rndc reconfig

Настройка логов в bind (named)

Гораздо интереснее и полезнее разобраться с подробным логированием работы сервера. Я долгое время поверхностно хватался за всякие рекомендации и куски примерных конфигов в интернете, пока в не решил разобраться сам с этой темой и не полез в оригинальный .

Bind дает широкие возможности для ведения логов. Можно фиксировать практически все, что связано с работой сервера. Я сейчас на простых примерах покажу, как это работает.

Первым делом в конфигурации мы задаем канал, куда будут складываться логи по тем или иным событиям. Вот пример подобного канала:

channel general {

file "/var/log/named/general.log" versions 3 size 5m;

severity dynamic;

print-time yes;

Здесь указано название канала, которые мы придумываем сами — general, указан путь до файла, сказано, что хранить будем 3 версии лога размером не более 5 мегабайт. Параметр severity может принимать следующие значения:

Параметр print-time указывает на то, что в лог необходимо записывать время события. Помимо указанных мной настроек, в конфигурации канала могут быть добавлены следующие параметры:

• print-severity yes | no — указывает, писать или нет параметр severity в лог
• print-category yes | no — указывает писать или нет название категории логов

Я эти параметры не указал, так как по-умолчанию устанавливается значение no, которое лично меня устраивает.

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

category general { general; };

Категорий у днс сервера bind достаточно много. Вот мой перевод полного списка с описаниями:

Таким образом, чтобы вывести все категории логов в отдельные файлы, необходимо в конфиг named добавить следующую конструкцию:

logging {

channel default {

file "/var/log/named/default.log" versions 3 size 5m;

severity dynamic;

print-time yes;

};

channel general {

file "/var/log/named/general.log" versions 3 size 5m;

severity dynamic;

print-time yes;

};

channel database {

file "/var/log/named/database.log" versions 3 size 5m;

severity dynamic;

print-time yes;

};

channel security {

file "/var/log/named/security.log" versions 3 size 5m;

severity dynamic;

print-time yes;

};

channel config {

file "/var/log/named/config.log" versions 3 size 5m;

severity dynamic;

print-time yes;

};

channel resolver {

file "/var/log/named/resolver.log" versions 3 size 5m;

severity dynamic;

print-time yes;

};

channel xfer-in {

file "/var/log/named/xfer-in.log" versions 3 size 5m;

severity dynamic;

print-time yes;

};

channel xfer-out {

file "/var/log/named/xfer-out.log" versions 3 size 5m;

severity dynamic;

print-time yes;

};

channel notify {

file "/var/log/named/notify.log" versions 3 size 5m;

severity dynamic;

print-time yes;

};

channel client {

file "/var/log/named/client.log" versions 3 size 5m;

severity dynamic;

print-time yes;

};

channel unmatched {

file "/var/log/named/unmatched.log" versions 3 size 5m;

severity dynamic;

print-time yes;

};

channel network {

file "/var/log/named/network.log" versions 3 size 5m;

severity dynamic;

print-time yes;

};

channel update {

file "/var/log/named/update.log" versions 3 size 5m;

severity dynamic;

print-time yes;

};

channel update-security {

file "/var/log/named/update-security.log" versions 3 size 5m;

severity dynamic;

print-time yes;

};

channel queries {

file "/var/log/named/queries.log" versions 3 size 5m;

severity dynamic;

print-time yes;

};

channel query-errors {

file "/var/log/named/query-errors.log" versions 3 size 5m;

severity dynamic;

print-time yes;

};

channel dispatch {

file "/var/log/named/dispatch.log" versions 3 size 5m;

severity dynamic;

print-time yes;

};

channel dnssec {

file "/var/log/named/dnssec.log" versions 3 size 5m;

severity dynamic;

print-time yes;

};

channel lame-servers {

file "/var/log/named/lame-servers.log" versions 3 size 5m;

severity dynamic;

print-time yes;

};

channel delegation-only {

file "/var/log/named/delegation-only.log" versions 3 size 5m;

severity dynamic;

print-time yes;

};

channel edns-disabled {

file "/var/log/named/edns-disabled.log" versions 3 size 5m;

severity dynamic;

print-time yes;

};

channel rpz {

file "/var/log/named/rpz.log" versions 3 size 5m;

severity dynamic;

print-time yes;

};

channel rate-limit {

file "/var/log/named/rate-limit.log" versions 3 size 5m;

severity dynamic;

print-time yes;

};

channel cname {

file "/var/log/named/cname.log" versions 3 size 5m;

severity dynamic;

print-time yes;

};

category default { default; };

category general { general; };

category database { database; };

category security { security; };

category config { config; };

category resolver { resolver; };

category xfer-in { xfer-in; };

category xfer-out { xfer-out; };

category notify { notify; };

category client { client; };

category unmatched { unmatched; };

category network { network; };

category update { update; };

category update-security { update-security; };

category queries { queries; };

category query-errors { query-errors; };

category dispatch { dispatch; };

category dnssec { dnssec; };

category lame-servers { lame-servers; };

category delegation-only { delegation-only; };

category edns-disabled { edns-disabled; };

category rpz { rpz; };

category rate-limit { rate-limit; };

category cname { cname; };

};

Теперь создадим папку для логов. Не забываем, что мы работаем в chroot окружении:

# cd /var/named/chroot/var/log && mkdir named && chown named. named

Если мы хотим собирать все логи запросов из категории queries, то в раздел options файла конфигурации необходимо добавить параметр, который это разрешает:

querylog yes;

Перезапускаем bind:

# systemctl reload named-chroot.service

Проверка работы DNS Server

Первым делом пойдем в каталог с логами и проверим, что там у нас:

# cd /var/named/chroot/var/log/named

# ls -l

Все файлы журнала созданы и начали наполняться. Можно проверить один из них. Например, посмотрим, как наш сервер centos (192.168.7.246) логирует запросы пользователей. Попробуем с компьютера 192.168.7.254 (windows) выполнить nslookup yandex.ru и посмотрим как это отразится в лог файле:

26-Sep-2015 19:25:30.923 client 192.168.7.254#56374 (yandex.ru): query: yandex.ru IN A + (192.168.7.246)

26-Sep-2015 19:25:31.013 client 192.168.7.254#56375 (yandex.ru): query: yandex.ru IN AAAA + (192.168.7.246)

Теперь выполним ping site1.ru, чтобы проверить, как сервер поддерживает нашу зону:

Смотрим, что в логах:

26-Sep-2015 19:28:01.660 client 192.168.7.254#49816 (site1.ru): query: site1.ru IN A + (192.168.7.246)

Таким образом очень удобно отследить, куда лезет компьютер. Например, можно поднять временно dns сервер, включить лог запросов. В клиенте указать единственный днс сервер, который мы настроили. Дальше можно отслеживать, к примеру, куда лезет винда после загрузки без нашего ведома. Или откуда грузится реклама в скайпе. Все запросы будут аккуратно складываться в файл, который потом можно спокойно анализировать, а затем, к примеру, настроить запрет сайтов на микротике.