Программное обеспечение компьютерных сетей
учебно-методический материал на тему
Комплект практических работ по дисциплине "Программное обеспечение компьютерных сетей", для обучающихся на 3 курсе специальности "Компьютерные сети"
Скачать:
Вложение | Размер |
---|---|
![]() | 28.79 КБ |
![]() | 37.84 КБ |
![]() | 18.88 КБ |
![]() | 176.87 КБ |
![]() | 25.13 КБ |
![]() | 105.69 КБ |
![]() | 118.41 КБ |
![]() | 140.57 КБ |
![]() | 2.04 МБ |
![]() | 283.53 КБ |
Предварительный просмотр:
Практическая работа №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.
Уровни важности
0 | emerg | Аварийная ситуация (PANIC) |
1 | alert | Тревожная ситуация, при которой потребуется вмешательство |
2 | crit | Критическая ситуация |
3 | err | Сообщение об ошибке (ERROR) |
4 | warning | Предупреждение (WARN) |
5 | notice | Информация о важном событии |
6 | info | Информационное сообщение |
7 | debug | Отладочное (подробное) сообщение |
Теперь, что касается источников сообщений:
0 | kern | Сообщения ядра |
1 | user | Пользовательские программы |
2 | Подсистема пересылки почты | |
3 | daemon | Сообщения прочих сервисов |
4 | auth | Авторизация пользователя, изменение прав доступа |
5 | syslog | Сообщения от самой системы журналирования |
6 | lpr | Подсистема печати |
7 | news | Устарело. Сообщения от провайдера новостей |
8 | uucp | Устарело. Сообщения Unix-to-Unix Copy Protocol. |
9 | cron | Сообщения от планировщика cron |
10 | authpriv | Похоже на auth, только пишет в закрытый для прочих пользователей файл |
11 | ftp | Действия FTP-сервиса |
12 | ntp | Сообщения сервиса синхронизации времени |
13,14 | log audit, alert | |
15 | clock daemon | Сервис времени |
16-23 | local0-local7 | Зарезервированные уровни. local7, например, для этапа загрузки системы. |
Ну и теперь, что касается действия.
- Отправка в обычный файл — указывается путь к файлу-источнику. Если необходимо отключить синхронизацию файла после дозаписи, перед путём ставится дефис. Отключенная синхронизация повышает производительность на нагруженных логах, но может потерять данные.
- Отправка в именованный канал, указывается символ пайпа | и путь к каналу.
- Отправка в терминал /dev/console.
- Отправка на удалённый сервер, указывается символ @ и имя-порт хоста.
Сейчас уже существуют и более гибкие продукты вроде 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 имеется три режима работы:
- Enforcing — основной режим работы. В этом режиме все действия, которые приводят к нарушению установленных политик логируются и запрещаются.
- Permissive — отладочный режим. В этом режиме все действия, которые приводят к нарушению установленных политик так же логируются, но выполняются.
- Disabled — SELinux не проверяет политики доступа.
Проверить, в каком режиме работает SELinux достаточно просто. Есть целых две команды: getenforce или sestatus:
Получить статус SELinux
Установить режим по умолчанию можно в конфиг-файле /etc/selinux/config
Режим SELinux по умолчанию
Итак, система под контролем SELinux в режиме Enforced работает в режиме минимальных прав, то есть процессам разрешено делать только необходимый набор функций и ни шагу в сторону. Как правило, такой подход сопряжен и с наименьшим удобством пользователя и администратора, настраивающего систему.
Овчинка стоит выделки только на Enterprise серверах, где безопасность выходит на первое место перед удобством, на пользовательских же машинах эта система может доставлять определенные неудобства. Хотя, смотря как к ней подойти. Для всех популярных сервисов уже заготовлены базовые политики. Политику видно по контексту. Те процессы, для которых политики не определены — выполняются в домене unconfined_t.
Терминология SELinux
Чтобы далее понимать о чём идет речь, необходимо совершенно определенно пояснить несколько моментов:
- Домен — это список действий, которые может выполнить процесс.
- Тип — список действий, которые можно выполнить, обращаясь к объекту. Здесь объектом может служить и файл и каталог и поток.
- Роль — список доменов, которые могут быть использованы.
- Контекст — полный перечень (домен, тип, роль) какого-либо объекта.
Как контролируется доступ в SELinux
Принято выделять три модели управления доступом:
- Type Enforcement (TE) — основной тип. Для каждого объекта контекст настраивается детально.
- Role-Based Access Control (RBAC) — расширенный (TE) — здесь права реализуются при помощи так называемых «ролей». На мой взгляд, нечто похожее реализовано в Windows с группами пользователей.
- 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
' > /home/site.ru/index.html
Далее, оформим виртуальный хост:
Виртуальный хост
Само-собой подправим /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;
vsftpd | имя пользователя и базы |
12345 | пароль пользователя |
Создаем таблицу учеток:
> 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'));
ftp-mysql | имя пользователя |
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; };
};
Эта конфигурация обеспечит работу обычного кэширующего сервера в локальной сети. Комментарии к некоторым параметрам:
listen-on-v6 port 53 { none; }; | Отключили работу на интерфейсе ipv6. |
allow-query { 127.0.0.1; 192.168.7.0/24; }; | Разрешаем обычные запросы только из локальной сети. |
allow-recursion { 127.0.0.1; 192.168.7.0/24; }; | Разрешаем рекурсивные запросы только из локальной сети. |
forwarders { 8.8.8.8; }; | Перенаправляем запросы, которые сами не резолвим, на днс сервер гугла. У меня указан он просто для примера. Тут лучше всего указать сначала ДНС серверы провайдера. |
version «DNS Server»; | Скрываем версию бинда, вместо этого выводим указанную строку. |
Не забудьте отредактировать правила фаервола для корректной работы 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 может принимать следующие значения:
Описание параметров severity | |
critical | Только критические ошибки. |
error | Обычные ошибки и все что выше. |
warning | Предупреждения и все, что выше. |
notice | Уведомления и все, что выше. |
info | Информационные сообщения и все что выше. |
debug | Сообщения уровня debug и все, что выше. Уровни debug регулируются значениями 0, 1, 2, 3. |
dynamic | То же, что и debug, только его уровень регулируется глобальной настройкой сервера. |
Параметр print-time указывает на то, что в лог необходимо записывать время события. Помимо указанных мной настроек, в конфигурации канала могут быть добавлены следующие параметры:
- print-severity yes | no — указывает, писать или нет параметр severity в лог
- print-category yes | no — указывает писать или нет название категории логов
Я эти параметры не указал, так как по-умолчанию устанавливается значение no, которое лично меня устраивает.
Дальше необходимо указать категорию логов и в какой канал мы будем ее записывать:
category general { general; };
Категорий у днс сервера bind достаточно много. Вот мой перевод полного списка с описаниями:
Описание категорий логов в bind (named) | |
default | Сюда будут попадать события всех категорий из этой таблицы, если они не определены отдельно, за исключением категории queries, которую нужно включать специально. То есть если обозначить только категорию default, то в нее будут сыпаться события всех категорий. |
general | Эта категория для всех логов, которые не включены ни в одну из перечисленных категорий. |
database | Сообщения, относящиеся к хранению зон и кэшированию. |
security | Подтверждение и отказ в выполнении запросов. |
config | Все, что относится к чтению и выполнению файла конфигурация. |
resolver | Разрешение имен, включая информацию о рекурсивных запросах, выполняемых от имени клиента кэширующим сервером. |
xfer-in | Информация о получении зон. |
xfer-out | Информация о передаче зон. |
notify | Логирование операций протокола NOTIFY. |
client | Выполнение клиентских запросов. |
unmatched | Сообщения, которые named не смог отнести ни к одному классу или для которых не определено отображение. |
network | Логирование сетевых операций. |
update | Динамические апдейты. |
update-security | Подтверждение или отклонение запросов на апдейт. |
queries | Логирование запросов к ДНС серверу. Для включения этой категории необходимо отдельно задать параметр в конфигурации сервера. Это связано с тем, что эта категория генерирует очень много записей в лог файл, что может сказаться на производительности сервера. |
query-errors | Ошибки запросов к серверу. |
dispatch | Перенаправление входящих пакетов модулям сервера на обработку. |
dnssec | Работа протоколов DNSSEC и TSIG. |
lame-servers | Фиксируются ошибки, которые получает bind при обращении к удаленным серверам в попытке выполнить запрос на разрешение имени. |
delegation-only | Логирование запросов, вернувших NXDOMAIN. |
edns-disabled | Запросы, которые вынуждены использовать plain DNS из-за превышения timeouts. |
RPZ | Все операции, связанные с выполнение Response Policy Zone (RPZ). |
rate-limit | Операции связанные с одним или несколькими rate-limit statements в options или view. |
Таким образом, чтобы вывести все категории логов в отдельные файлы, необходимо в конфиг 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 сервер, включить лог запросов. В клиенте указать единственный днс сервер, который мы настроили. Дальше можно отслеживать, к примеру, куда лезет винда после загрузки без нашего ведома. Или откуда грузится реклама в скайпе. Все запросы будут аккуратно складываться в файл, который потом можно спокойно анализировать, а затем, к примеру, настроить запрет сайтов на микротике.
По теме: методические разработки, презентации и конспекты
![](/sites/default/files/pictures/2012/09/15/picture-109275.jpg)
Итоговый тест по дисциплине "Программное обеспечение компьютерных сетей"
Этот тест является формой итогового контроля, для выявления понимания вопросов, рассматриваемых в рамках данной дисциплины.Такой вариант итогового контроля знанийвозможен после лекционно-семинарской ч...
![](/sites/default/files/pictures/2012/09/15/picture-109275.jpg)
Методическая разработка открытого урока Дисциплина: Программное обеспечение компьютерных сетей Тема: «Службы Интернета»
Это занятие посвящено решению таких вопросов, как:1. подключение локальной сети к Интернет;2. возможности одновременного доступа к ресурсам Интернет пользователей на всех клиентских рабочих станциях;3...
![](/sites/default/files/pictures/2015/11/06/picture-703616-1446802045.jpg)
Методические рекомендации по выполнению практических работ для специальности 230111 Компьютерные сети (углубленный уровень) по ПМ 02 Организация сетевого администрирования/МДК 02.01 Программное обеспечение компьютерных сетей
Методические рекомендации по выполнению практических работ для специальности 230111 Компьютерные сети (углубленный уровень) по ПМ 02 Организация сетевого администрирования/МДК 02.01 Программное обеспе...
Аппаратное и программное обеспечение компьютерной сети
Методическая разработка урока по Информатике для 9 класса. Тема "Аппаратное и программное обеспечение компьютерной сети"...
![](/sites/default/files/pictures/2020/10/29/picture-1038321-1603938320.jpg)
Лекция на тему "Возможности сетевого программного обеспечения для организации коллективной деятельности в глобальных и локальных компьютерных сетях электронная почта, чат, видеоконференция, интернет-телефония."
Лекция "Возможности сетевого программного обеспечения для организации коллективной деятельности в глобальных и локальных компьютерных сетях: электронная почта, чат, видеоконференция, интернет-тел...
![](/sites/default/files/pictures/2020/03/17/picture-1227795-1584425409.jpg)
РАБОЧАЯ ПРОГРАММА ПРОФЕССИОНАЛЬНОГО МОДУЛЯ «ПМ.04 СОПРОВОЖДЕНИЕ И ОБСЛУЖИВАНИЕ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ КОМПЬЮТЕРНЫХ СИСТЕМ»
Рабочая программа профессионального модуля «ПМ.04 Сопровождение и обслуживание программного обеспечения компьютерных систем» разработана на основе Федерального государственного образовател...
![](/sites/default/files/pictures/2022/03/10/picture-1392853-1646912596.jpg)
КАЛЕНДАРНО-ТЕМАТИЧЕСКИЙ ПЛАН на 1 семестр 2021/2022 учебного года для 4 курса группы ИСП.18А по МДК.04.01. Внедрение и поддержка программного обеспечения компьютерных систем
Календарно-тематический план по дисциплине МДК.04.01. Внедрение и поддержка программного обеспечения компьютерных систем, разработанный в рамках учебной программы по специальности 09.02.07 Информ...