Руководство по Ubuntu Server



Pdf просмотр
страница6/16
Дата17.11.2016
Размер1.78 Mb.
Просмотров3785
Скачиваний3
ТипРуководство
1   2   3   4   5   6   7   8   9   ...   16
Глава 8. Служба доменных
имён (DNS)
Служба доменных имён (Domain Name Service, DNS) — это служба интернета, которая ставит в соответствие друг с другом IP-адреса и полные доменные имена (Fully Qualified Domain Names, FQDN). Таким образом,
DNS избавляет от необходимости запоминать IP-адреса. Компьютеры,
на которых запущен сервер DNS, называются серверами имён. Ubuntu включает в себя BIND (Berkley Internet Naming Daemon), наиболее распространенную программу для обслуживания серверов имён в Linux.

Служба доменных имён (DNS)
159
1. Установка
Для установки bind наберите в терминале следующую команду:
sudo apt-get install bind9
Очень полезный пакет для тестирования и решения проблем с DNS — это пакет dnsutils. Очень часто эти инструменты уже установлены, но для проверки и/или установки dnsutils введите следующее:
sudo apt-get install dnsutils

Служба доменных имён (DNS)
160
2. Конфигурация
Существует много способов настроить BIND9. Наиболее распространенные конфигурации — это кэширующий сервер имён, первичный мастер и вторичный мастер.
• Когда BIND9 настроен как кэширующий сервер, он ищет ответы на запросы имени и запоминает ответ на случай, если запрос придёт повторно.
• В качестве первичного мастера BIND9 читает данные зоны из локального файла и является ответственным за эту зону.
• В качестве вторичного мастера BIND9 получает данные по зоне (целиком)
с другого сервера имён, отвечающего за эту зону.
2.1. Обзор
Файлы настройки DNS сохраняются в каталоге
/etc/bind
. Основной файл конфигурации — это
/etc/bind/named.conf
Строки include определяют имена файлов, которые содержат опции
DNS. Строка directory в файле
/etc/bind/named.conf.options сообщает DNS,
где искать файлы. Пути ко всем файлам, используемым BIND, будут относительными к этому каталогу.
Файл с именем
/etc/bind/db.root описывает корневые сервера имён в мире.
Сервера со временем меняются, поэтому файл
/etc/bind/db.root должен время от времени обслуживаться. Обычно это делается через обновлений к пакету bind9. Секция zone определяет мастер сервер, и она хранится в файле, определяемом опцией file.
Существует возможность настроить один сервер как кэширующий сервер имён, первичный мастер и вторичный мастер одновременно. Сервер может быть началом Authority (Start of Authority, SOA) для одной зоны,
при этом предоставляя вторичный сервис для другой, и при всём этом предоставлять кэширующий сервис в локальной сети (LAN).
2.2. Кэширующий сервер имён
По умолчанию конфигурация настраивается на работу в качестве кэширующего сервера. Всё, что для этого требуется — это добавить
IP-адреса DNS-серверов вашего интернет-провайдера. Просто раскомментируйте и исправьте следующее в
/etc/bind/named.conf.options
:

Служба доменных имён (DNS)
161
forwarders {
1.2.3.4;
5.6.7.8;
};
Замените 1.2.3.4 и 5.6.7.8 на актуальные IP-адреса серверов имён.
Теперь перегружаем DNS-сервер для применения новой конфигурации.
Наберите в терминале:
sudo service bind9 restart
Смотрите Раздел 3.1.2, «dig» [166] для информации по тестированию кэширующего DNS-сервера.
2.3. Первичный мастер
В этом разделе BIND9 будет настроен как первичный мастер для домена
example.com. Просто замените example.com на ваше FQDN (Fully Qualified
Domain Name).
2.3.1. Файл прямой зоны
Чтобы добавить зону DNS в BIND9, превратив его в сервер первичного мастера, первым шагом отредактируем
/etc/bind/named.conf.local
:
zone "example.com" {
type master;
file "/etc/bind/db.example.com";
};
Теперь используем существующий файл зоны в качестве шаблона для создания файла
/etc/bind/db.example.com
:
sudo cp /etc/bind/db.local /etc/bind/db.example.com
Редактируем новый файл зоны
/etc/bind/db.example.com
, заменив localhost.
на FQDN нашего сервера, оставляя дополнительную "." в конце. Заменим
127.0.0.1 на IP-адрес сервера имён и root.localhost на правильный адрес электронной почты, но с "." вместо символа "@", опять же оставляя "." в конце. Измените комментарий для указания домена, для которого этот файл сделан.
Создайте запись A для базового домена example.com. Также создайте
запись A для ns.example.com — сервера имён в данном примере:

Служба доменных имён (DNS)
162
;
; BIND data file for example.com
;
$TTL 604800
@ IN SOA example.com. root.example.com. (
2 ; Serial
604800 ; Refresh
86400 ; Retry
2419200 ; Expire
604800 ) ; Negative Cache TTL
IN A 192.168.1.10
;
@ IN NS ns.example.com.
@ IN A 192.168.1.10
@ IN AAAA ::1
ns IN A 192.168.1.10
Вы должны увеличивать порядковый номер (Serial) каждый раз, когда делаете изменения в файле зоны. Если вы делаете множественные изменения перед перезапуском BIND9, просто увеличьте Serial на единицу один раз.
Теперь вы можете добавлять DNS записи в конец файла зоны. Смотрите подробности в разделе Раздел 4.1, «Общие типы записей» [170].
Многие администраторы предпочитают использовать дату последнего редактирования в качестве порядкового номера (Serial)
зоны в виде 2012010100, что соответствует формату yyyymmddss
(где ss — порядковый номер)
Как только вы произвели изменения в файле зоны, требуется перегрузить
BIND9 для применения изменений:
sudo service bind9 restart
2.3.2. Файл обратной зоны
Теперь, когда зона создана и разрешает имена в IP-адреса, требуется создать также обратную зону. Обратная зона позволяет DNS определять имя по IP-адресу.
Редактируем /etc/bind/named.conf.local и добавляем следующее:
zone "1.168.192.in-addr.arpa" {
type master;
file "/etc/bind/db.192";
};

Служба доменных имён (DNS)
163
Замените 1.168.192 на первые три октета адресов сети, которую вы используете. Также дайте имя файлу зоны
/etc/bind/db.192
в соответствии с первым октетом вашей сети.
Теперь создаём файл
/etc/bind/db.192
:
sudo cp /etc/bind/db.127 /etc/bind/db.192
Далее редактируем
/etc/bind/db.192
, изменяя в основном те же опции, что и в
/etc/bind/db.example.com
:
;
; BIND reverse data file for local 192.168.1.XXX net
;
$TTL 604800
@ IN SOA ns.example.com. root.example.com. (
2 ; Serial
604800 ; Refresh
86400 ; Retry
2419200 ; Expire
604800 ) ; Negative Cache TTL
;
@ IN NS ns.
10 IN PTR ns.example.com.
Порядковый номер (Serial)в обратной зоне также требуется увеличивать при каждом изменении. Для каждой Записи A, которую вы настроите в
/etc/
bind/db.example.com
, то есть для каждого адреса, вы должны создать запись
PTR в
/etc/bind/db.192
После создания файла обратной зоны перегрузите BIND9:
sudo service bind9 restart
2.4. Вторичный мастер
Поскольку первичный мастер (Primary Master) настроен, требуется
Secondary Master для того, чтобы поддерживать домен при недоступности первичного мастера.
Для начала на первичном мастере надо разрешить передачу зоны.
Добавьте опцию allow-transfer к определениям прямой и обратной зон в
/
etc/bind/named.conf.local
:
zone "example.com" {
type master;

Служба доменных имён (DNS)
164
file "/etc/bind/db.example.com";
allow-transfer { 192.168.1.11; };
};
zone "1.168.192.in-addr.arpa" {
type master;
file "/etc/bind/db.192";
allow-transfer { 192.168.1.11; };
};
Замените 192.168.1.11 на IP-адрес вашего вторичного сервера имён.
Перезапустим BIND9 на первичном мастере:
sudo service bind9 restart
Далее, на вторичном мастере установите пакет bind9 так же, как делали на первичном. Затем отредактируем
/etc/bind/named.conf.local и добавим следующие определения к прямой и обратной зонам:
zone "example.com" {
type slave;
file "db.example.com";
masters { 192.168.1.10; };
}; zone "1.168.192.in-addr.arpa" {
type slave;
file "db.192";
masters { 192.168.1.10; };
};
Замените 192.168.1.10 на IP-адрес вашего первичного сервера имён.
Перегружаем BIND9 на вторичном мастере:
sudo service bind9 restart
В
/var/log/syslog вы сможете увидеть нечто похожее на (некоторые строки разделены для соответствия формату документа):
client 192.168.1.10#39448: received notify for zone '1.168.192.in-addr.arpa'
zone 1.168.192.in-addr.arpa/IN: Transfer started.
transfer of '100.18.172.in-addr.arpa/IN' from 192.168.1.10#53:
connected using 192.168.1.11#37531
zone 1.168.192.in-addr.arpa/IN: transferred serial 5
transfer of '100.18.172.in-addr.arpa/IN' from 192.168.1.10#53:

Служба доменных имён (DNS)
165
Transfer completed: 1 messages,
6 records, 212 bytes, 0.002 secs (106000 bytes/sec)
zone 1.168.192.in-addr.arpa/IN: sending notifies (serial 5)
client 192.168.1.10#20329: received notify for zone 'example.com'
zone example.com/IN: Transfer started.
transfer of 'example.com/IN' from 192.168.1.10#53: connected using 192.168.1.11#38577
zone example.com/IN: transferred serial 5
transfer of 'example.com/IN' from 192.168.1.10#53: Transfer completed: 1 messages,
8 records, 225 bytes, 0.002 secs (112500 bytes/sec)
Обратите внимание, что передача зоны произойдет только если
порядковый номер (Serial) на первичном сервере больше значения на вторичном. Если вы хотите, чтобы первичный мастер DNS
сообщал вторичному DNS серверу об изменении зоны, вы можете добавить also-notify { ipaddress; }; в
/etc/bind/named.conf.local
, как показано в примере ниже:
zone "example.com" {
type master;
file "/etc/bind/db.example.com";
allow-transfer { 192.168.1.11; };
also-notify { 192.168.1.11; };
};
zone "1.168.192.in-addr.arpa" {
type master;
file "/etc/bind/db.192";
allow-transfer { 192.168.1.11; };
also-notify { 192.168.1.11; };
};
Каталог по умолчанию для файлов неавторизованных зон —
/var/
cache/bind/
. Этот каталог также настроен в AppArmor для разрешения доступа сервису named на запись в него. Для дополнительной информации по AppArmor смотрите Раздел 4, «AppArmor» [189].

Служба доменных имён (DNS)
166
3. Устранение проблем
Этот раздел посвящён способам определения причины проблем,
возникающих с DNS и BIND9.
3.1. Тестирование
3.1.1. resolv.conf
Первый шаг в тестировании BIND9 — это добавление IP-адреса сервера имён в список определителя сетевых имен. Первичный сервер имён должен настраиваться, как и любой другой узел сети, с двойной проверкой. Просто отредактируйте
/etc/resolv.conf
, добавив следующее:
nameserver 192.168.1.10
nameserver 192.168.1.11
Вам надо добавить также IP-адрес вторичного сервера имен на случай недоступности первичного.
3.1.2. dig
Если вы установили пакет dnsutils, вы можете проверить свою установку,
используя обзорную утилиту DNS dig:
• После установки BIND9 примените dig к интерфейсу обратной петли
(loopback), чтобы убедиться, что порт 53 прослушивается. Из терминала наберите:
dig -x 127.0.0.1
Вы должны увидеть строки вывода, похожие на следующее:
;; Query time: 1 msec
;; SERVER: 192.168.1.10#53(192.168.1.10)
• Если BIND9 настроен у вас как кэширующий сервер, используйте "dig" для замера времени при разрешении имени внешнего домена:
dig ubuntu.com
Обратите внимание на время в конце вывода результата команды:
;; Query time: 49 msec
После повторного вызова dig должно произойти улучшение:

Служба доменных имён (DNS)
167
;; Query time: 1 msec
3.1.3. ping
Теперь для демонстрации, как приложения могут использовать DNS для разрешения сетевых имён, используйте утилиту ping для отправки эхо- запроса ICMP. Из терминала наберите следующее:
ping example.com
Это проверит, может ли сервер имён разрешить имя ns.example.com в IP- адрес. Вывод команды будет напоминать следующее:
PING ns.example.com (192.168.1.10) 56(84) bytes of data.
64 bytes from 192.168.1.10: icmp_seq=1 ttl=64 time=0.800 ms
64 bytes from 192.168.1.10: icmp_seq=2 ttl=64 time=0.813 ms
3.1.4. named-checkzone
Хороший способ проверить ваши файлы зон — это использовать утилиту named-checkzone, установленную вместе с пакетом bind9.Эта утилита позволяет вам убедиться в корректности настроек до перезапуска BIND9 и применения изменений.
• Для тестирования нашего файла прямой зоны из примера введите следующее в командной строке:
named-checkzone example.com /etc/bind/db.example.com
Если всё настроено верно, вы сможете увидеть вывод, похожий на:
zone example.com/IN: loaded serial 6
OK
• Аналогично, для тестирования файла обратной зоны введите следующее:
named-checkzone 1.168.192.in-addr.arpa /etc/bind/db.192
Вывод должен напоминать следующее:
zone 1.168.192.in-addr.arpa/IN: loaded serial 3
OK
Порядковый номер (Serial) вашего файла зоны может отличаться.

Служба доменных имён (DNS)
168 3.2. Ведение журнала
BIND9 имеет широкий набор доступных опций настроек журналов.
Существуют две основные опции. С помощью опции channel указывается,
где вести журналы, а опция category определяет, какую информацию писать в журнал.
Если опции журналов отсутствуют, по умолчанию применяется следующее:
logging {
category default { default_syslog; default_debug; };
category unmatched { null; };
};
Этот раздел раскрывает, как настроить BIND9 для отправки отладочных
сообщений, связанных с DNS запросами, в отдельный файл.
• Сначала нам надо настроить канал (channel) для определения того, в какой файл посылать сообщения. Редактируем
/etc/bind/named.conf.local и
добавляем следующее:
logging {
channel query.log { file "/var/log/query.log";
severity debug 3;
};
};
• Затем настраиваем категорию (category) для отправки всех DNS запросов в файл:
logging {
channel query.log { file "/var/log/query.log"; severity debug 3;
};
category queries { query.log; };
};
Обратите внимание на опцию debug, которая может принимать значения от 1 до 3. Если уровень отладки не указан, по умолчанию используется 1.
• Поскольку сервис named daemon запускается от имени bind, надо создать файл
/var/log/query.log и сменить его владельца:
sudo touch /var/log/query.log
sudo chown bind /var/log/query.log

Служба доменных имён (DNS)
169
• Перед тем, как сервис named сможет писать в новый файл журнала,
нужно изменить профиль AppArmor. Сначала редактируем файл
/etc/
apparmor.d/usr.sbin.named
, добавив:
/var/log/query.log w,
Затем перезагружаем профиль:
cat /etc/apparmor.d/usr.sbin.named | sudo apparmor_parser -r
Дополнительную информацию по AppArmor смотрите в разделе Раздел 4,
«AppArmor» [189]
• Теперь перезагружаем BIND9 для применения изменений:
sudo service bind9 restart
Теперь вы можете увидеть файл
/var/log/query.log
, заполненный информацией о запросах. Это простейший пример использования опций журналирования BIND9. По использованию расширенных опций смотрите раздел Раздел 4.2, «Дополнительная информация» [170].

Служба доменных имён (DNS)
170
4. Ссылки
4.1. Общие типы записей
Этот раздел покажет некоторые наиболее общие типы записей DNS.
• Запись A: Эта запись указывает IP-адрес для сетевого имени (hostname).
www IN A 192.168.1.12
• Запись CNAME: Используется для создания псевдонима (alias) записи A.
Нельзя создавать запись CNAME, указывающую на другую запись CNAME.
web IN CNAME www
• Запись MX: Используется для определения, куда должна отправляться электронная почта. Должна указывать на запись A, не на CNAME.
IN MX 1 mail.example.com.
mail IN A 192.168.1.13
• Запись NS: Используется для определения, какие сервера поддерживают копии зоны. Должна указывать на запись A, не на CNAME. Ею определяются первичные и вторичные сервера зоны.
IN NS ns.example.com.
IN NS ns2.example.com.
ns IN A 192.168.1.10
ns2 IN A 192.168.1.11 4.2. Дополнительная информация
DNS HOWTO
1
описывает больше расширенных опций для настройки
BIND9.
• Для глубокого освещения DNS и BIND9 смотрите Bind9.net
2
• Популярная книга DNS and BIND
3
теперь в пятой редакции.
• Хорошее место для вопросов поддержки BIND9 и вовлечения в сообщество Ubuntu Server — это канал IRC #ubuntu-server на freenode
4
• Также смотрите BIND9 Server HOWTO
5
на Ubutu wiki.
1
http://www.tldp.org/HOWTO/DNS-HOWTO.html
2
http://www.bind9.net/
3
http://www.oreilly.com/catalog/dns5/index.html
4
http://freenode.net
5
https://help.ubuntu.com/community/BIND9ServerHowto

171
Глава 9. Защита
Безопасность всегда следует учитывать во время установки,
развёртывания и использования любого вида компьютерных систем.
Несмотря на то, что чистая установка Ubuntu весьма безопасна для немедленного использования в Интернете, важно иметь хорошее понимание состояния безопасности ваших систем, на основании того, как они будут использоваться после развёртывания.
В этой главе дается обзор безопасности, связанных с тем, как они относятся к Ubuntu 12.04 LTS Server Edition, а также описываются простые меры, которые вы можете использовать для защиты вашего сервера и сети от любого числа потенциальных угроз безопасности.

Защита
172
1. Управление пользователями
Управление пользователями — это важная часть контроля безопасности системы. Неэффективное управление пользователями и привилегиями часто приводит многие системы к компрометации. Однако, важно, чтобы вы понимали, как можно защитить ваш сервер простыми и эффективными техниками управления пользовательскими учётными записями.
1.1. Где root?
Разработчики Ubuntu сделали сознательное решение по умолчанию отключить административную учётную запись root во всех инсталляциях
Ubuntu. Это не означает, что аккаунт root был удалён или что к нему нельзя получить доступ. Он просто получил пароль, соответствующий невозможному значению, так что войти в систему напрямую под root нельзя.
Вместо этого, пользователям для выполнения административных задач предлагается использовать инструмент sudo. Sudo позволяет авторизованному пользователю временно повышать свои привилегии,
пользуясь их собственным паролем вместо пароля учётной записи root.
Эта простая и эффективная методика предоставляет возможность учёта всех действий пользователей и даёт администратору точечный контроль на тем, какие действия пользователь может выполнять с указанными привилегиями.
• Если по какой-то причине вам хочется включить учётную запись root,
просто дайте ей пароль:
sudo passwd
Sudo запросит ваш пароль, а затем предложит ввести новый пароль для root, как показано ниже:
[sudo] password for username:
(введите ваш пароль)
Enter new UNIX password:
(введите новый пароль для root)
Retype new UNIX password:
(повторите новый пароль для root)
passwd: password updated successfully
• Для отключения учётной запись root используется следующий синтаксис passwd:
sudo passwd -l root
• Вам стоит прочитать больше о Sudo, обратившись к его man-странице.

Защита
173
man sudo
По умолчанию исходный пользователь, созданный инсталлятором Ubuntu
— член группы "admin", который добавляется в файл
/etc/sudoers как авторизованный пользователь sudo. Если вы хотите предоставить любым другим учётным записям полный доступ root через sudo, просто добавьте их в группу admin.
1.2. Добавление и удаление пользователей
Процесс управления локальными пользователями и группами совершенно понятный и почти не отличается от большинства других операционных систем семейства GNU/Linux. В Ubuntu и других дистрибутивах, основанных на Debian, рекомендуется использовать для управления учётными записями пакет "adduser".
• Чтобы добавить учётную запись пользователя, используйте следующий синтаксис и следуйте указаниям системы, чтобы назначить учётной записи пароль и указать другие данные, такие как полное имя, номер телефона и прочее.
sudo adduser username
• Чтобы удалить учётную запись пользователя и его основную группу,
используется следующий синтаксис:
sudo deluser username
Удаление учётной записи не уничтожает соответствующий ей домашний каталог. На вас остаётся решение, удалить ли папку вручную или оставить в соответствии с желаемыми политиками хранения.
Помните, любой пользователь, добавленный позже с такими же UID/GID,
как предыдущий владелец, получит доступ к этому каталогу, если вы не примете требуемых мер предосторожности.
Вы можете захотеть заменить значения UID/GID на что-то более подходящее, такое как учётная запись root, и, возможно, даже переместить каталог во избежание будущих конфликтов.
sudo chown -R root:root /home/username/
sudo mkdir /home/archived_users/
sudo mv /home/username /home/archived_users/
• Чтобы временно заблокировать или разблокировать учётную запись пользователя, используется соответственно следующий синтаксис:

Защита
174
sudo passwd -l username
sudo passwd -u username
• Чтобы добавить или удалить конкретную группу, используется соответственно следующий синтаксис:
sudo addgroup groupname
sudo delgroup groupname
• Чтобы добавить пользователя в группу, используется следующее:
sudo adduser username groupname
1.3. Безопасность пользовательских профилей
Когда создаётся новый пользователь, утилита adduser создаёт новый соответствующий домашний каталог, называющийся
/home/username
. Профиль по умолчанию создаётся на основе содержимого, найденного в папке
/etc/
skel
, включающей всё базовое содержимое профиля.
Если ваш сервер будет использоваться многими пользователями, нужно уделить большое внимание правам доступа к домашним каталогам пользователей, чтобы гарантировать конфиденциальность. По умолчанию,
пользовательские домашние каталоги в Ubuntu создаются с правами чтения/выполнения для всех. Это означает, что все пользователи могут просматривать и читать содержимое домашних каталогов других пользователей. Это может не подходить для вашего рабочего окружения.
• Чтобы проверить текущие права доступа к домашним каталогам ваших пользователей, используйте следующий синтаксис:
ls -ld /home/username
Следующий вывод показывает, что у всех есть право доступа к папке
/
home/username на чтение.
drwxr-xr-x 2 username username 4096 2007-10-02 20:03 username
• Вы можете удалить полномочия чтения для всех, используя следующую команду:
sudo chmod 0750 /home/username
Некоторые люди необдуманно склоняются к использованию рекурсивной опции (-R), которая модифицирует все дочерние

Защита
175
папки и файлы, однако это не требуется и может привести к нежелательным результатам. Изменения прав для родительской папки достаточно для предотвращения неавторизованного доступа ко всему её содержимому.
Гораздо более эффективным подходом к вопросу будет изменение глобальных полномочий по умолчанию на создание пользовательских домашних каталогов для adduser. Просто откройте файл
/etc/adduser.conf и
измените переменную
DIR_MODE
на что-нибудь подходящее, и на все новые домашние каталоги будут устанавливаться корректные права доступа.
DIR_MODE=0750
• После изменения прав доступа к папке с использованием любого из ранее показанных способов, проверьте результат, используя следующий синтаксис:
ls -ld /home/username
Результаты ниже показывают, что полномочия на чтение для всех были удалены:
drwxr-x--- 2 username username 4096 2007-10-02 20:03 username
1.4. Политики паролей
Хорошая политика паролей — это один из наиболее важных аспектов состояния безопасности. Для многих успешных взломов против слабых паролей использовался простой брутфорс и перебор по словарю. Если вы планируете предоставить любой вид удалённого доступа с использованием локальной системы паролей, убедитесь, что вы в достаточной мере обдумали требования к минимально сложности пароля, максимальному сроку его жизни и частоте аудита ваших систем аутентификации.
1.4.1. Минимальная длина пароля
По умолчанию Ubuntu требует минимальную длину пароля в 6 символов,
также выполняет некоторые базовые проверки энтропии. Эти параметры управляются файлом
/etc/pam.d/common-password и приведены ниже:
password [success=2 default=ignore] pam_unix.so obscure sha512
Если вы хотите установить минимальную длину в 8 символов, измените соответствующую переменную на min=8. Изменения приведены ниже:

Защита
176
password [success=2 default=ignore] pam_unix.so obscure sha512 min=8
Базовые проверки на качество (энтропию) и минимальную длину пароля не применяются к администратору, использующему команды уровня sudo для настройки нового пользователя.
1.4.2. Истечение срока действия пароля
При создании пользовательских учётных записей вам следует сделать политику минимального и максимального срока действия пароля,
принуждая пользователей менять их пароли при истечении срока.
• Чтобы просмотреть текущее состояние пользовательской учётной записи,
используйте следующий синтаксис:
sudo chage -l username
Листинг ниже демонстрирует интересные факты о пользовательской учётной записи, а именно, что не применены никакие политики:
Последнее изменение пароля: 20 января 2008 года
Действие пароля заканчивается: никогда
Пароль становится неактивным: никогда
Действие аккаунта заканчивается: никогда
Изменение пароля возможно, если прошло не менее (указывается количество дней): 0
Изменение пароля возможно, если прошло не более (указывается количество дней): 99999
Количество дней, за которое высвечиватся предупреждение об истечении действия пароля: 7
• Чтобы установить любой из этих параметров, просто воспользуйтесь следующей командой и следуйте указаниям:
sudo chage username
Ниже показан пример того, как вы можете вручную изменить дату завершения действия пароля (-E) на 01/31/2008, минимальное время действия пароля (-m) 5 дней, максимальное время действия 90 дней,
период бездействия (-l) 5 дней по окончанию срока действия пароля и период предупреждения (-W) на 14 дней до завершения действия пароля.
sudo chage -E 01/31/2011 -m 5 -M 90 -I 30 -W 14 username
• Чтобы проверить изменения, воспользуйтесь способом, применявшимся ранее:
sudo chage -l username
Листинг ниже показывает новые политики, установленные для учётной записи:

Защита
177
Последнее изменение пароля: 20 января 2008 года
Действие пароля заканчивается: 19 апреля 2008 года
Пароль становится неактивным: 19 мая 2008 года
Действие аккаунта заканчивается: 31 января 2008 года
Изменение пароля возможно, если прошло не менее (указывается количество дней): 5
Изменение пароля возможно, если прошло не более (указывается количество дней): 90
Количество дней, за которое высвечивается предупреждение об истечении действия пароля: 14 1.5. Иные предложения по безопасности
Многие приложения используют собственные механизмы аутентификации,
которые могут быть не замечены даже опытными системными администраторами. Поэтому важно понимать и контролировать, как пользователи проходят аутентификацию и получают доступ к сервисам и приложениям на вашем сервере.
1.5.1. Доступ отключенных пользователей по SSH
Простое отключение или блокирование пользовательской учётной записи не помешает пользователю войти на ваш сервер удалённо, если предварительно они установили аутентификацию по открытому ключу
RSA. У них всё ещё будет возможность получить скрытый доступ к серверу без потребности в каком бы то ни было пароле. Не забудьте проверить домашний каталог пользователя на файлы, которые разрешают данный вид аутентичного доступа по SSH, как например
/home/username/.ssh/
authorized_keys
Удалите или переименуйте каталог
.ssh/
в пользовательском домашнем каталоге, чтобы предотвратить дальнейшее использование возможностей аутентификации по SSH.
Обязательно проверьте наличие любых SSH соединений, установленных отключенными пользователями, так как возможно, что они могут иметь существующее входящее или исходящее подключение. Закройте их, если таковые имеются.
Разрешайте доступ по SSH только тем учётным записям пользователей,
которым он нужен. Например, вы можете создать группу "sshlogin"
и добавить её в переменную, связанную с переменной
AllowGroups
,
расположенной в файле
/etc/ssh/sshd_config
AllowGroups sshlogin
Затем добавьте пользователей, которым разрешён доступ по SSH, в группу "sshlogin" и перезапустите сервис SSH.

Защита
178
sudo adduser username sshlogin
sudo service ssh restart
1.5.2. Аутентификация базы данных сторонних пользователей
Большинство корпоративных сетей требуют централизованную аутентификацию и контроль доступа ко всем системным ресурсам. Если вы настроили ваш сервер на аутентификацию пользователей с помощью внешних баз данных, убедитесь, что вы отключили пользовательские учётные записи для удалённого и локального использования. Так вы удостоверитесь, что невозможен локальных обход аутентификации.

Защита
179
2. Безопасность консоли
Как и в случае с любым другим барьером безопасности, который вы выстраиваете для защиты вашего сервера, требуется довольно жёстко защититься от невообразимого ущерба, который может возникнуть от физического доступа кого-то лица к вашему оборудованию, например,
воровства жёстких дисков, сбоя по питанию, отказа в обслуживании и т.п.
Поэтому безопасность консоли стоит рассматривать просто как ещё один компонент вашей общей стратегии физической безопасности. Блокируемая "ширма" (screen door) может защитить от случайного криминала и очень сильно замедлить активное воздействие, поэтому очень желательно соблюдать простейшие предосторожности по отношению к безопасности консоли.
Нижеприведенные инструкции помогут вам обезопасить сервер от таких событий, которые в ином случае могли бы вызвать серьёзные последствия.
2.1. Отключение Ctrl+Alt+Delete
Прежде всего, любой, кто имеет доступ к клавиатуре, просто может нажать комбинацию Ctrl+Alt+Delete для перезагрузки сервера и без необходимости входить в систему. Конечно, можно просто отключить шнур питания, но отключение этой команды на рабочем сервере по-прежнему необходимо. Это заставит злоумышленника предпринимать более радикальные меры по перезагрузке сервера, и в тоже время предотвратит случайные перезагрузки.
• Для отключения перезагрузки по нажатию комбинации Ctrl+Alt+Delete
закомментируйте следующую строку в файле
/etc/init/control-alt- delete.conf
#exec shutdown -r now "Control-Alt-Delete pressed"

Защита
180
3. Брандмауэр
3.1. Введение
Ядро Linux включает подсистему Netfilter, которая используется для регулирования сетевого траффика, входящего на или проходящего через вашу систему. Все современные средства межсетевой защиты Linux используют эту систему для фильтрации пакетов.
Система фильтрации пакетов ядра была бы малопригодной для администраторов без пользовательского интерфейса управления ею.
Для этого предназначено приложение iptables. Когда пакет достигает вашего сервера, он передаётся подсистеме Netfilter для приёма, обработки или отклонения, в зависимости от правил, передаваемых ей из рабочего пространства пользователя с помощью iptables. Таким образом, если вы хорошо знакомы с iptables — это всё, что вам необходимо для управления межсетевым экраном. Однако существует множество программ,
предоставляющих интерфейс для упрощения этой задачи.
3.2. ufw — Uncomplicated Firewall
По умолчанию, программой для настройки брандмауэра в Ubuntu является приложение ufw. Разработанное для облегчения настройки iptables, приложение ufw предоставляет дружелюбный пользователю способ по созданию брандмауэра для адресов в формате IPv4 или IPv6,
устанавливаемый на машину пользователя.
Приложение ufw по умолчанию отключено. Выдержка из man-страницы ufw:
«Приложение ufw не может предоставить полной функциональности брандмауэра через свой интерфейс командной строки, однако, такое приложение предлагает лёгкий способ добавления или удаления несложных правил. В основном, такое приложение используется для создания брандмауэра, устанавливаемого на компьютере пользователя.»
Ниже идут примеры по использованию приложения ufw:
• Сначала необходимо активировать ufw. Введите в терминале:
sudo ufw enable
• Для того, чтобы открыть порт (в нашем примере — ssh), введите:
sudo ufw allow 22

Защита
181
• Также правила могут быть добавлены в числовом формате:
sudo ufw insert 1 allow 80
• Похожим образом, чтобы закрыть порт, введите:
sudo ufw deny 22
• Чтобы удалить правило, введите delete и, далее, удаляемое правило:
sudo ufw delete deny 22
• Также возможно разрешить доступ с определённых узлов или сетей на конкретный порт. Нижеследующий пример позволяет доступ к порту ssh с узла 192.168.0.2 на любой IP-адрес на данном компьютере:
sudo ufw allow proto tcp from 192.168.0.2 to any port 22
Замените 192.168.0.2 на 192.168.0.0/24, чтобы разрешить доступ к порту ssh из целой подсети.
• Указание опции --dry-run у команды ufw, приведёт к выводу результирующих правил без их применения. Например, следующее будет применено, если открыт порт HTTP:
sudo ufw --dry-run allow http
*filter
:ufw-user-input - [0:0]
:ufw-user-output - [0:0]
:ufw-user-forward - [0:0]
:ufw-user-limit - [0:0]
:ufw-user-limit-accept - [0:0]
### ПРАВИЛА ###
### tuple ### allow tcp 80 0.0.0.0/0 any 0.0.0.0/0
-A ufw-user-input -p tcp --dport 80 -j ACCEPT
### ОКОНЧАНИЕ ПРАВИЛ ###
-A ufw-user-input -j RETURN
-A ufw-user-output -j RETURN
-A ufw-user-forward -j RETURN
-A ufw-user-limit -m limit --limit 3/minute -j LOG --log-prefix "[UFW LIMIT]: "
-A ufw-user-limit -j REJECT
-A ufw-user-limit-accept -j ACCEPT
COMMIT
Правила изменены
• Можно отключить приложение ufw, для этого введите:

Защита
182
sudo ufw disable
• Введите для просмотра статуса брандмауэра:
sudo ufw status
• Для более детального отображения статуса введите следующую команду:
sudo ufw status verbose
• Для просмотра числового формата:
sudo ufw status numbered
Если порт, который вы хотите открыть или закрыть, определён в файле
/etc/services
, вы можете использовать имя порта вместо его номера. Для этого в приведённых выше примерах можно заменить число 22 на ssh.
Это краткое введение в использование ufw. Пожалуйста, обратитесь к справочной странице программы ufw для более подробной информации.
3.2.1. Интеграция приложений с ufw
Приложения, открывающие порты, могут включать ufw профиль, который определяет порты, необходимые для корректной работы приложения. Эти профили содержатся в
/etc/ufw/applications.d и могут быть изменены, если были изменены порты «по умолчанию».
• Для просмотра списка приложений с установленными профилями введите в терминале следующую команду:
sudo ufw app list
• Аналогично, чтобы разрешить трафик через порт с помощью профиля приложения, введите:
sudo ufw allow Samba
• Также доступен расширенный синтаксис:
ufw allow from 192.168.0.0/24 to any app Samba
Замените Samba и 192.168.0.0/24 профилем используемого вами приложения и адресом вашей сети соответственно.

Защита
183
Нет необходимости указывать протокол для приложения, т.к.
эта информация уже содержится в профиле. Также, обратите внимание, что имя приложения — app — заменяет номер порта.
• Для просмотра деталей по портам, протоколам и т.д. для приложения,
введите:
sudo ufw app info Samba
Не для всех приложений, которые требуют открытие сетевого порта,
поставляется профиль ufw, но если у вас есть профиль для приложения,
и вы хотите чтобы этот файл был включен в пакет приложения,
зарегистрируйте ошибку о пакете на сайте Launchpad.
ubuntu-bug имя_пакета
3.3. IP маскировка
Назначение IP маскировки в том, чтобы позволить машинам в вашей сети с частными, не маршрутизируемыми IP-адресами, иметь доступ в Интернет через машину, осуществляющую маскировку. Трафик из вашей сети,
предназначенный для Интернета, должен быть обработан так, чтобы ответы могли вернуться обратно на машину, которая организовала запрос.
Чтобы это сделать, ядро должно изменить IP-адрес источника в каждом пакете так, чтобы ответы возвращались на сервер, а не на частный IP-адрес
(что невозможно в Интернете), с которого сделан запрос. Linux использует
Connection Tracking (conntrack) для хранения записи о том, каким машинам принадлежат соединения, и перенаправляет каждый возвращенный пакет соответствующим образом. Таким образом, трафик, покидающий вашу сеть,
"замаскирован", как будто исходит от машины, которая выполняет роль шлюза. В документации Microsoft этот процесс упоминается как технология
Internet Connection Sharing.
3.3.1. Маскарадинг ufw
Маскарадинг IP может быть реализован использованием пользовательских правил ufw. Это возможно благодаря тому, что текущий бэк-энд для ufw
— это iptables-restore с файлами правил, хранящихся в
/etc/ufw/*.rules
. Эти файлы — замечательный способ добавить родные правила iptables без участия ufw, и эти правила больше ориентированы на шлюз или мост сети.
Правила разделены на два файла: те, которые должны быть выполнены до правил командной строки ufw, и те, которые выполняются после правил командной строки ufw .

Защита
184
• В начале, перенаправление пакетов должно быть включено в ufw. Для этого необходимо настроить два конфигурационных файла: в
/etc/default/
ufw измените DEFAULT_FORWARD_POLICY на «ACCEPT»:
DEFAULT_FORWARD_POLICY="ACCEPT"
После этого отредактируйте
/etc/ufw/sysctl.conf и раскомментируйте:
net/ipv4/ip_forward=1
Аналогично, для форвардинга IPv6, раскомментируйте net/ipv6/conf/default/forwarding=1
• Теперь мы добавим правила в файл
/etc/ufw/before.rules
. Правила по умолчанию задают только таблицу фильтрации, а для включения маскарадинга должна быть отредактирована таблица nat. Добавьте нижеследующее в начало файла, сразу после комментариев в заголовке:
# nat Table rules
*nat
:POSTROUTING ACCEPT [0:0]
# Forward traffic from eth1 through eth0.
-A POSTROUTING -s 192.168.0.0/24 -o eth0 -j MASQUERADE
# don't delete the 'COMMIT' line or these nat table rules won't be processed
COMMIT
Комментарии не обязательны, но считается хорошей практикой документировать свою конфигурацию. При этом, редактируя любой файл
правил в
/etc/ufw
, убедитесь, что эти строки являются последними во всех изменённых таблицах:
# не удаляйте строку "COMMIT", иначе эти правила не будут обрабатываться
COMMIT
Для каждой таблицы требуется соответствующий оператор правила
COMMIT. В этих примерах показаны только таблицы nat и filter, но вы можете точно так же добавить правила для таблиц raw и mangle.
В приведённом примере замените eth0, eth1 и 192.168.0.0/24 на подходящие для вашей сети интерфейсы и диапазон IP.
• Наконец, отключите и заново включите ufw для того, чтобы изменения вступили в силу:

Защита
185
sudo ufw disable && sudo ufw enable
Маскарадинг IP должен быть включён. Также вы можете добавить дополнительные правила FORWARD в
/etc/ufw/before.rules
. Рекомендуется добавлять эти правила в цепочку ufw-before-forward.
3.3.2. Маскарадинг iptables iptables также может быть использован для маскировки соединений.
• Аналогично случаю с ufw, первым шагом будет включение перенаправления пакетов IPv4. Для этого отредактируйте
/etc/sysctl.conf и раскомментируйте следующую строчку net.ipv4.ip_forward=1
Если вы хотите включить и перенаправление IPv6, раскомментируйте:
net.ipv6.conf.default.forwarding=1
• Затем выполните команду sysctl для включения новых настроек в конфигурационном файле:
sudo sysctl -p
• Маскарадинг IP теперь может быть завершён одним правилом iptables,
которое может слегка отличаться, в зависимости от конфигурации вашей сети:
sudo iptables -t nat -A POSTROUTING -s 192.168.0.0/16 -o ppp0 -j MASQUERADE
Команда вверху предполагает, что ваш внутрисетевой диапазон адресов
— 192.168.0.0/16, а интерфейс, смотрящий в Интернет — ppp0. Синтаксис выглядит следующим образом:
• -t nat — правило для обращения к таблице NAT
• -A POSTROUTING — правило, добавляемое (-A) к цепочке POSTROUTING
• -s 192.168.0.0/16 — правило применяется для трафика, происходящего из обозначенного адресного пространства
• -o ppp0 — правило применяется к трафику, который планируется направить через определенное сетевое устройство
• -j MASQUERADE — трафик, попадающий под данное правило, должен быть перенаправлен "jump" (-j) с маскировкой (MASQUERADE) для обработки, как описано выше

Защита
186
• Также, каждая цепочка в таблице фильтров (таблица по умолчанию,
в которой происходит большая часть фильтрации) имеет политику по умолчанию для правила ACCEPT, но если вы создаёте брандмауэр в дополнение к устройству шлюза, вы можете установить политики в DROP
или REJECT. В этом случае ваш замаскированный трафик должен быть разрешён в цепочке FORWARD, для того, чтобы правило вверху работало:
sudo iptables -A FORWARD -s 192.168.0.0/16 -o ppp0 -j ACCEPT
sudo iptables -A FORWARD -d 192.168.0.0/16 -m state \
--state ESTABLISHED,RELATED -i ppp0 -j ACCEPT
Верхняя команда разрешит все соединения из вашей локальной сети с Интернетом, и весь трафик, относящийся к этим соединениям, будет возвращаться машинам, их установившим.
• Если вы хотите включить маскарадинг после перезагрузки, что вы уже,
вероятно сделали, отредактируйте
/etc/rc.local и добавьте любую из перечисленных выше команд. Например, добавьте первую команду без фильтрации:
iptables -t nat -A POSTROUTING -s 192.168.0.0/16 -o ppp0 -j MASQUERADE
3.4. Журналирование
Журналы брандмауэра — это ценные данные при определении атак,
нахождения проблем в правилах и причины необычной активности вашей сети. Вы также должны включить правила регистрации событий брандмауэра, и эти правила должны предшествовать любому применяемому завершаемому правилу (правило, целью которого является определение судьбы пакета: ACCEPT, DROP, or REJECT)
Если вы используете ufw, вы можете включить регистрацию событий, введя следующую команду в терминале:
sudo ufw logging on
Для отключения регистрации событий в ufw просто замените on на off в приведённой выше команде.
Если используется iptables вместо ufw, введите:
sudo iptables -A INPUT -m state --state NEW -p tcp --dport 80 \
-j LOG --log-prefix "NEW_HTTP_CONN: "

Защита
187
Запрос, поступивший на порт 80 от компьютера в локальной сети, затем сгенерирует текст журнала в dmesg, который выглядит примерно так (одна строка разделена на три, чтобы уместить её в этом документе):
[4304885.870000] NEW_HTTP_CONN: IN=lo OUT= MAC=00:00:00:00:00:00:00:00:00:00:00:00:08:00
SRC=127.0.0.1 DST=127.0.0.1 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=58288 DF PROTO=TCP
SPT=53981 DPT=80 WINDOW=32767 RES=0x00 SYN URGP=0
Вышеупомянутый текст журнала также появится в файлах
/var/log/
messages
,
/var/log/syslog и
/var/log/kern.log
. Это поведение можно изменить,
отредактировав соответствующим образом файл
/etc/syslog.conf или с помощью установки и настройки ulogd и использования ULOG вместо LOG.
Демон ulogd — это сервер, работающий в пространстве пользователя,
который слушает инструкции журналирования от ядра специально для межсетевых экранов и может записывать журнал в любой выбранный вами файл, и даже в базы данных PostgreSQL или MySQL. Для того, чтобы легко разобраться в файлах журнала, можно использовать их анализаторы, такие как logwatch, fwanalog, fwlogwatch или lire.
3.5. Другие инструменты
Есть много инструментов, предназначенных помочь вам создать полноценный брандмауэр без каких-либо знаний iptables. Для GUI- ориентированных:
fwbuilder
1
очень мощный инструмент, будет удобен администраторам,
уже имевшим дело с коммерческими брандмауэрами, например,
Checkpoint FireWall-1.
Если вы предпочитаете инструменты командной строки с текстовыми конфигурационными файлами:
Shorewall
2
— очень мощное решение, призванное помочь вам настроить улучшенный брандмауэр для любой сети.
3.6. Ссылки
• Вики-страница Ubuntu Firewall
3
содержит необходимую информацию о работе c ufw..
• Также руководство пользователя по ufw содержит много полезной информации: man ufw.
• Больше информации по использованию iptables ищите на страничке
packet-filtering-HOWTO
4 1
http://www.fwbuilder.org/
2
http://www.shorewall.net/
3
https://wiki.ubuntu.com/UncomplicatedFirewall
4
http://www.netfilter.org/documentation/HOWTO/packet-filtering-HOWTO.html

Защита
188
• Страничка nat-HOWTO
5
содержит дополнительную информацию о маскарадинге.
IPTables HowTo
6
Ubuntu Вики также отличный источник.
5
http://www.netfilter.org/documentation/HOWTO/NAT-HOWTO.html
6
https://help.ubuntu.com/community/IptablesHowTo

Защита
189
4. AppArmor
AppArmor — это реализация в виде модулей безопасности Linux (LSM)
основанного на именах мандатного управления доступом. AppArmor ограничивает доступ отдельных программ к перечисленному набору файлов и возможностей, указанных в стандартах 1003.1e posix.
Приложение AppArmor по умолчанию установлено и запущено. Оно использует профили приложений, чтобы определить, какие файлы и права требуются данному приложению. Некоторые пакеты будут устанавливать собственные профили, дополнительные профили могут быть найдены в пакете apparmor-profiles.
Для установки пакета apparmor-profiles наберите в терминале:
sudo apt-get install apparmor-profiles
Профили AppArmor имеют два режима выполнения:
• Жалоб/Обучения (Complaining/Learning): нарушения профиля разрешаются и фиксируются. Удобен для тестирования и разработки новых профилей.
• Принудительный/Ограниченный (Enforced/Confined): принудительно применяет политику профиля и регистрирует нарушения.
4.1. Использование AppArmor
Пакет apparmor-utils содержит утилиты для командной стоки, которые вы можете использовать для изменения режима выполнения AppArmor,
находить статус профиля, создавать новые профили и т.д.
• apparmor_status используется для просмотра текущего статуса профилей
AppArmor.
sudo apparmor_status
• aa-complain переводит профиль в режим жалоб.
sudo aa-complain /path/to/bin
• aa-enforce переводит профиль в принудительный режим.
sudo aa-enforce /path/to/bin
• Каталог
/etc/apparmor.d хранит профили AppArmor. Он может использоваться для управления режимом всех профилей.
Введите следующее для перевода всех профилей в режим жалоб:

Защита
190
sudo aa-complain /etc/apparmor.d/*
Для перевода всех профилей в принудительный режим:
sudo aa-enforce /etc/apparmor.d/*
• apparmor_parser используется для загрузки профиля в ядро. Он также может использоваться для перезагрузки текущего загруженного профиля с помощью опции -r. Для загрузки профиля:
cat /etc/apparmor.d/profile.name | sudo apparmor_parser -a
Для перезагрузки профиля:
cat /etc/apparmor.d/profile.name | sudo apparmor_parser -r

/etc/init.d/apparmor может использоваться для перезагрузки всех профилей:
sudo /etc/init.d/apparmor reload
• Каталог
/etc/apparmor.d/disable может использоваться совместно с опцией apparmor_parser -R для отключения профиля.
sudo ln -s /etc/apparmor.d/profile.name /etc/apparmor.d/disable/
sudo apparmor_parser -R /etc/apparmor.d/profile.name
Для повторного включения отключённого профиля удалите символическую ссылку на профиль в
/etc/apparmor.d/disable/
. После этого загрузите профиль с помощью опции -a.
sudo rm /etc/apparmor.d/disable/profile.name
cat /etc/apparmor.d/profile.name | sudo apparmor_parser -a
• Приложение AppArmor может быть отключено, а модули ядра —
выгружены, если вы введёте нижеследующее:
sudo /etc/init.d/apparmor stop
sudo update-rc.d -f apparmor remove
• Для повторного включения AppArmor введите:
sudo /etc/init.d/apparmor start
sudo update-rc.d apparmor defaults
Замените profile.name на имя того профиля, которым вы хотите управлять. Также замените
/path/to/bin/
на действительный путь к файлу. Например, для команды ping используйте
/bin/ping

Защита
191 4.2. Профили
Профили AppArmor являются простыми текстовыми файлами,
расположенными в
/etc/apparmor.d/
. Имена этих файлов состоят из полного пути к исполняемому файлу с заменой "/" на ".". Например,
/etc/apparmor.d/
bin.ping является профилем AppArmor для команды
/bin/ping
Есть два главных типа правил в профилях:
Path entries: описывает, к каким файлам приложение может иметь доступ в файловой системе.
Capability entries: определяет, какие привилегии ограниченному процессу разрешено использовать.
Например, взгляните на файл
/etc/apparmor.d/bin.ping
:
#include
/bin/ping flags=(complain) {
#include
#include
#include
capability net_raw,
capability setuid,
network inet raw,
/bin/ping mixr,
/etc/modules.conf r,
}
#include : включает операторы из других файлов. Это позволяет помещать в общий файл операторы, относящиеся к нескольким приложениям.
/bin/ping flags=(complain): путь к профилированной программе, также настройки режима complain
capability net_raw,: даёт доступ к возможности CAP_NET_RAW Posix.1e.
/bin/ping mixr,: даёт приложению права доступа на чтение и исполнение файла.
После редактирования файла профиля он должен быть перезагружен. Более подробно смотрите Раздел 4.1,
«Использование AppArmor» [189] .
4.2.1. Создание профиля
Разработка тест-плана: Попробуйте продумать, как приложение должно быть использовано. Тест-план должен быть разделён на небольшие

Защита
192
тестовые случаи. Каждый тестовый случай должен иметь краткое описание и список шагов, по которым нежно следовать.
Некоторые стандартные тестовые случаи:
• Запуск программы.
• Завершение программы.
• Перезагрузка программы.
• Проверка всех команд, поддерживаемых скриптом init.
Генерация нового профиля: используйте aa-genprof, чтобы сгенерировать новый профиль. Введите в консоли:
sudo aa-genprof executable
Например:
sudo aa-genprof slapd
• Чтобы ваш новый профиль был включён в пакет apparmor-profiles,
отправьте на Launchpad сообщение об ошибке в пакете AppArmor
7
:
• Включите ваш план тестирования и контрольные примеры.
• Укажите в сведениях об ошибке ваш профиль.
4.2.2. Обновление профилей
Когда программа неправильно работает, сообщения аудита посылаются в файлы журналов. Программа aa-logprof может использоваться для сканирования журналов на предмет сообщений аудита AppArmor, их проверки и обновления профилей. Введите в терминале:
sudo aa-logprof
4.3. Ссылки
• Расширенные опции конфигурирования можно найти в Руководстве
администратора по AppArmor
8
• Чтобы подробнее узнать о том, как использовать AppArmor с другими выпусками Ubuntu, зайдите на страницу AppArmor Community Wiki
9
• Ещё одним введением в AppArmor является страница OpenSUSE
AppArmor
10 7
https://bugs.launchpad.net/ubuntu/+source/apparmor/+filebug
8
http://www.novell.com/documentation/apparmor/apparmor201_sp10_admin/index.html?page=/documentation/
apparmor/apparmor201_sp10_admin/data/book_apparmor_admin.html
9
https://help.ubuntu.com/community/AppArmor
10
http://en.opensuse.org/SDB:AppArmor_geeks

Защита
193
• Отличное место для получения помощи по AppArmor, а также для участия в сообществе Ubuntu Server — это IRC канал #ubuntu-server на freenode
11 11
http://freenode.net

Защита
194
5. Сертификаты
Одной из наиболее распространённых видов криптографии на сегодняшний день является криптосистема с открытым ключом. Криптографическая система с открытым ключом использует открытый ключ и секретный
ключ. Система шифрует информацию с помощью открытого ключа. Такая информация может быть дешифрована только с помощью секретного ключа.
Обычное применение криптосистемы с открытым ключом — шифрование трафика приложений с помощью соединений через Secure Socket Layer
(SSL) или Transport Layer Security (TLS). Например, конфигурирование
Apache для поддержки HTTPS (протокола HTTP через SSL). Это обеспечивает возможность шифровать трафик, используя протокол, который сам по себе не обеспечивает шифрования.
Сертификат является методом, используемым для распространения
публичного ключа и другой информации о сервере и организации, которая за него отвечает. Сертификаты могут иметь цифровую подпись от центра сертификации (CA). Центр сертификации является доверенным третьим лицом, которое подтверждает, что информация, содержащаяся в сертификате, является точной.
5.1. Типы сертификатов
Чтобы создать защищённый сервер с использованием криптографии открытого ключа, в большинстве случаев, вы посылаете запрос на сертификат (с открытым ключом), подтверждаете подлинность данных о своей компании и оплачиваете услуги удостоверяющего центра (CA).
Удостоверяющий центр проверяет ваш запрос и присылает вам сертификат для вашего сервера. В качестве альтернативы вы можете создать свой собственный самоподписанный сертификат.
Учтите, что самоподписанные сертификаты не должны использоваться в большинстве серьёзных производственных систем.
Продолжая пример с HTTPS, подписанный CA сертификат имеет две важных особенности, которых сампоподписанный сертификат не имеет:
• Браузеры (обычно) автоматически определяют сертификаты и разрешают безопасные соединения без подтверждения пользователя.
• Выданный CA подписанный сертификат является гарантией подлинности организации, предоставляющей веб-страницы браузеру.

Защита
195
Большинство веб-браузеров и компьютеров, которые поддерживают
SSL, имеют список центров сертификации, чьи сертификаты они принимают автоматически. Если браузер сталкивается с сертификатом,
чей центр сертификации отсутствует в списке, то браузер просит пользователя принять или отклонить это соединение. Также, различные приложения могут генерировать сообщение об ошибке при использовании самоподписанных сертификатов.
Процесс получения сертификата от CA довольно прост. Краткие сведения об этом:
1. Создайте пару ключей шифрования, открытый и закрытый.
2. Создайте запрос сертификата, основанный на открытом ключе. Данный запрос содержит в себе информацию о вашем сервере и компании, где он размещается.
3. Отправьте запрос сертификата вместе с документами,
подтверждающими вашу личность, в CA. Мы не можем рекомендовать вам, какой удостоверяющий центр выбрать. Ваше решение может основываться на вашем прошлом опыте, на опыте ваших друзей и коллег,
или просто на финансовых факторах.
Если вы определились с CA, вам необходимо следовать инструкциям,
которые он предоставит для получения его сертификата.
4. Когда CA установит, что вы являетесь тем, за кого себя выдаёте, он пришлёт вам цифровой сертификат.
5. Установите этот сертификат на ваш защищённый сервер и настройте соответствующие приложения на использование сертификата.
5.2. Генерация запроса на подпись сертификата
(Certificate Signing Request, или CSR)
Получаете ли вы сертификат от CA или генерируете его собственноручно,
первым шагом должно быть создание ключа.
Если сертификат будет использоваться системными сервисами, такими как
Apache, Postfix, Dovecot и т.п., уместно создать ключ без пароля. Отсутствие пароля позволяет сервису запускаться без вмешательства пользователя,
обычно это предпочтительный вариант запуска сервиса.
В этом разделе показано, как создать ключ с паролем и без него. Ключ без пароля затем будет использован для создания сертификата, который можно использовать для различных системных сервисов.
Запуск вашего защищённого сервиса без пароля удобен потому, что вам не потребуется вводить пароль при каждом запуске данного

Защита
196
сервиса. Однако это небезопасно и компрометация ключа будет означать и компрометацию сервера.
Для генерации ключей запроса подписи сертификата (CSR) запустите следующую команду из строки терминала:
openssl genrsa -des3 -out server.key 2048
Generating RSA private key, 2048 bit long modulus
..........................++++++
.......++++++
e is 65537 (0x10001)
Enter pass phrase for server.key:
Теперь вы можете ввести свою парольную фразу. Для наилучшей безопасности она должна содержать не менее восьми символов.
Минимальная длина — четыре символа. Пароль должен содержать цифры и/или специальные символы и не являться словом из словаря. Запомните то, что вы введёте.
Для подтверждения наберите парольную фразу ещё раз. Как только вы наберете её правильно, ключ к серверу будет создан и сохранён в файле server.key
Теперь создадим небезопасный ключ, без кодовой фразы, и перетасуем имена ключей:
openssl rsa -in server.key -out server.key.insecure
mv server.key server.key.secure
mv server.key.insecure server.key
Небезопасный ключ теперь называется server.key
, и вы можете использовать его для создания CSR без кодовой фразы.
Для создания CSR выполните следующую команду в терминале:
openssl req -new -key server.key -out server.csr
У вас будет запрошена парольная фраза (при использовании ключа с паролем - прим. пер.). Если пароль введён правильно, у вас запросят название компании, имя сайта, адрес электронной почты и пр. Как только вы введёте все эти подробности, будет создан запрос CSR и сохранен в файл server.csr
Теперь вы можете отправить этот CSR-файл в CA для обработки. CA,
используя этот CSR-файл, выпустит сертификат. С другой стороны, вы

Защита
197
можете создать самоподписанный сертификат сами, используя тот же CSR- файл.
5.3. Создание сертификата со своей подписью
Для того, чтобы создать самоподписанный сертификат, исполните следующую команду в терминале:
openssl x509 -req -days 365 -in server.csr -signkey server.key -out server.crt
Вышеприведённая команда предложит ввести парольную фразу. При вводе правильной парольной фразы ваш сертификат будет создан и сохранён в файле server.crt
Если ваш защищённый сервер будет использоваться в производственной среде, вам, скорее всего, необходим сертификат,
подписанный CA. В данном случае не рекомендуется использовать самоподписанный сертификат.
5.4. Установка сертификата
Вы можете установить ключевой файл server.key и файл сертификата server.crt
, или файл сертификата, выданный вам CA, запустив следующую команду в строке терминала:
sudo cp server.crt /etc/ssl/certs
sudo cp server.key /etc/ssl/private
Теперь просто сконфигурируйте любые приложения, имеющие поддержку криптографии с открытым ключом, для использования файлов сертификата
и ключа. Например, Apache может использовать HTTPS, Dovecot — IMAPS и
POP3S и т.д.
5.5. Центр Сертификации
Если для ваших сетевых сервисов требуется много самоподписанных сертификатов, стоит затратить дополнительные усилия и установить свой собственный центр сертификации (CA). Использование сертификатов,
подписанных вашим собственным CA, позволяет различным использующим сертификаты сервисам проще доверять другим сервисам, использующим сертификаты от этого же CA.
1. Сначала создайте каталоги для хранения сертификата CA и связанных с ним файлов:

Защита
198
sudo mkdir /etc/ssl/CA
sudo mkdir /etc/ssl/newcerts
2. Для работы CA требует несколько дополнительных файлов: один содержит запись о последнем серийном номере, выданном CA (каждый сертификат должен иметь уникальный серийный номер), другой файл предназначен для записи, какие сертификаты были выданы:
sudo sh -c "echo '01' > /etc/ssl/CA/serial"
sudo touch /etc/ssl/CA/index.txt
3. Третьим файлом является файл конфигурации CA. Хотя он не обязателен, тем не менее, он обеспечивает удобство при выдаче нескольких сертификатов. Отредактируйте
/etc/ssl/openssl.cnf и в
[ CA_default ] измените:
dir = /etc/ssl/ # Где все сохраняется database = $dir/CA/index.txt # база данных файла index.
certificate = $dir/certs/cacert.pem # CA сертификат serial = $dir/CA/serial # Верный серийный номер private_key = $dir/private/cakey.pem# Частный ключ
4. Затем создайте самоподписанный корневой сертификат:
openssl req -new -x509 -extensions v3_ca -keyout cakey.pem -out cacert.pem -days 3650
Затем вас попросят ввести описание сертификата.
5. Теперь установите корневой сертификат и ключ:
sudo mv cakey.pem /etc/ssl/private/
sudo mv cacert.pem /etc/ssl/certs/
6. Теперь вы готовы к подписыванию сертификатов. Первое, что вам необходимо, это запрос на подпись сертификата (CSR), подробнее смотрите Раздел 5.2, «Генерация запроса на подпись сертификата
(Certificate Signing Request, или CSR)» [195]. Как только у вас будет
CSR, можно перейти к получению сертификата, подписанного центром сертификации:
sudo openssl ca -in server.csr -config /etc/ssl/openssl.cnf
После ввода пароля для ключа центра сертификации, вас попросят дважды подписать сертификат, для его подтверждения. Затем вы увидите большое количество генерируемых данных процесса создания сертификата.
7. Теперь у вас должен появиться новый файл
/etc/ssl/newcerts/01.pem
,
с таким же содержанием, что и в предыдущем выводе. Выделите и

Защита
199
скопируйте всё, начиная со строки -----BEGIN CERTIFICATE----- и до строки
----END CERTIFICATE----- в файл с названием, соответствующим сетевому имени сервера, где он будет установлен. Например, mail.example.com.crt
— вполне хорошее описательное имя.
Последующие сертификаты будут называться
02.pem
,
03.pem
, и т.д.
Замените mail.example.com.crt своим описательным именем.
8. Наконец, скопируйте новый сертификат на компьютер, для которого он выпущен, и настройте соответствующие приложения на его использование. Место по умолчанию для установки сертификатов —
каталог
/etc/ssl/certs
. Это позволяет нескольким сервисам использовать один и тот же сертификат без чрезмерного усложнения прав доступа к файлу.
Для приложений, требующих использования сертификата CA, вы должны скопировать файл
/etc/ssl/certs/cacert.pem в каталог
/etc/ssl/
certs/
на каждом сервере.
5.6. Ссылки
• Для получения более подробных инструкций по использованию криптографии смотрите SSL Certificates HOWTO
12
на tlpd.org
• На странице Википедии HTTPS
13
вы найдете больше информации о протоколе HTTPS
• Для дополнительной информации об OpenSSL смотрите домашнюю
страницу OpenSSL
14
• Также хорошим подробным руководством является Network Security with
OpenSSL
15
издательства O'Reilly.
12
http://tldp.org/HOWTO/SSL-Certificates-HOWTO/index.html
13
http://ru.wikipedia.org/wiki/Https
14
http://www.openssl.org/
15
http://oreilly.com/catalog/9780596002701/

Защита
200
6. eCryptfs
eCryptfs — это POSIX-совместимая многоуровневая криптографическая файловая система промышленного уровня для Linux. Располагаясь поверх уровня файловой системы, eCryptfs защищает файлы безотносительно к нижележащим файловым системам, типам разделов и пр.
Во время установки предлагается возможность шифрования раздела
/
home
. Это позволит автоматически настроить всё, что необходимо для шифрования, и смонтировать раздел.
В качестве примера в этом разделе приводится шифрование
/srv с
помощью eCryptfs.
6.1. Использование eCryptfs
Сначала установите необходимые пакеты. Введите в командной строке:
sudo apt-get install ecryptfs-utils
Теперь смонтируйте раздел для шифрования:
sudo mount -t ecryptfs /srv /srv
Вам будет задано несколько вопросов о том, как ecryptfs должен зашифровать данные.
Чтобы убедиться, что файлы, находящиеся в
/srv
, действительно являются зашифрованной копией каталога
/etc/default в
/srv
:
sudo cp -r /etc/default /srv
Теперь отмонтируйте
/srv и попробуйте просмотреть файл:
sudo umount /srv
cat /srv/default/cron
Перемонтирование
/srv с помощью ecryptfs сделает данные снова доступными.
6.2. Автоматическое монтирование зашифрованных разделов
Существует пара способов автоматически монтировать файловую систему,
зашифрованную ecryptfs, на этапе загрузки. В этом примере используется

Защита
201
файл
/root/.ecryptfsrc
, содержащий опции монтирования, совместно с файлом парольной фразы, расположенным на USB ключе.
Сначала создайте файл
/root/.ecryptfsrc
, содержащий:
key=passphrase:passphrase_passwd_file=/mnt/usb/passwd_file.txt ecryptfs_sig=5826dd62cf81c615
ecryptfs_cipher=aes ecryptfs_key_bytes=16
ecryptfs_passthrough=n ecryptfs_enable_filename_crypto=n
Измените параметр ecryptfs_sig на сигнатуру из файла
/
root/.ecryptfs/sig-cache.txt
Далее создадим файл парольной фразы
/mnt/usb/passwd_file.txt
:
passphrase_passwd=[secrets]
Теперь добавьте необходимые строки в
/etc/fstab
:
/dev/sdb1 /mnt/usb ext3 ro 0 0
/srv /srv ecryptfs defaults 0 0
Удостоверьтесь, что USB-носитель смонтирован перед шифруемым разделом.
Наконец, перегрузитесь и
/srv будет смонтирован с использованием
eCryptfs.
6.3. Другие утилиты
Пакет ecryptfs-utils содержит несколько других полезных утилит:
ecryptfs-setup-private: создаёт каталог
/Private
, информация в котором хранится в зашифрованном виде. Эту утилиту могут запустить пользователи без административных полномочий, чтобы защитить личные данные от других пользователей системы.
ecryptfs-mount-private и ecryptfs-umount-private: соответственно смонтирует и отмонтирует пользовательский каталог
/Private
ecryptfs-add-passphrase: ecryptfs-add-passphrase: добавляет новую парольную фразу в хранилище ключей ядра.
ecryptfs-manager: управляет объектами eCryptfs, например ключами.
ecryptfs-stat: позволит вам увидеть метаинформацию ecryptfs для файла.

Защита
202 6.4. Ссылки
• Дополнительная информация о eCryptfs доступна на странице проекта на
Launchpad
16
• Существует также статья в Linux Journal
17
, посвящённая eCryptfs.
• Также для дополнительных опций ecryptfs смотрите страницу
руководства man ecryptfs.
18
eCryptfs Ubuntu Wiki
19
также содержит дополнительную информацию.
16
https://launchpad.net/ecryptfs
17
http://www.linuxjournal.com/article/9400 18
http://manpages.ubuntu.com/manpages/precise/en/man7/ecryptfs.7.html
19
https://help.ubuntu.com/community/eCryptfs
1   2   3   4   5   6   7   8   9   ...   16


База данных защищена авторским правом ©nethash.ru 2019
обратиться к администрации

войти | регистрация
    Главная страница


загрузить материал