Построение защищенных корпоративных сетей

ПОСТРОЕНИЕ 

ЗАЩИЩЕННЫХ

КОРПОРАТИВНЫХ

СЕТЕЙ

Ачилов Р. Н.

Москва, 2023

Издание рекомендовано в качестве учебного пособия 
для студентов технических вузов

2-е издание, электронное

УДК 004.732:004.056
ББК 32.973.202
A97

A97
Ачилов, Рашид Нурмухамедович.
Построение защищенных корпоративных сетей / Р. Н. Ачилов. — 2-е 
изд., эл. — 1 файл pdf : 251 с. — Москва : ДМК Пресс, 2023. — Систем. требования: 
Adobe Reader XI либо Adobe Digital Editions 4.5 ; экран 10". — 
Текст : электронный.
ISBN 978-5-89818-515-2

В книге рассказано обо всем, что необходимо для построения защищенной от 
внешних воздействий корпоративной сети — о том, как создать собственный удостоверяющий 
центр для выдачи SSL-сертификатов, как выдавать, отзывать, преобразовывать 
и просматривать сертификаты. Как установить SSL-сертификат в ОС 
или браузер, как его использовать, работая с защищенным ресурсом и какие ошибки 
при этом возникают.
Описывается, как с помощью сертификатов защитить корпоративную электронную 
почту на всех этапах ее передачи — от почтовой программы пользователя до 
сервера получателя; как установить веб-интерфейс к хранимой на сервере почте, 
позволяющий просматривать ее в защищенном режиме с любой точки мира.
Также уделено внимание защите служебных коммуникаций, в частности подключения 
из скриптов для управления серверами. В книге приводится большое 
число примеров конфигурационных файлов с подробным пояснением параметров, 
а также скриптов на языке Bourne Shell 1.x.
Издание предназначено для системных и сетевых администраторов UNIX, администраторов 
средств информационной безопасности.

УДК 004.732:004.056 
ББК 32.973.202

Электронное издание на основе печатного издания: Построение защищенных корпоративных 
сетей / Р. Н. Ачилов. — Москва : ДМК Пресс, 2013. — 250 с. — ISBN 978-5-94074-884-7. — 
Текст : непосредственный.

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

В соответствии со ст. 1299 и 1301 ГК РФ при устранении ограничений, установленных техническими средствами 
защиты авторских прав, правообладатель вправе требовать от нарушителя возмещения убытков или выплаты компенсации.


ISBN 978-5-89818-515-2
©  Ачилов Р. Н., 2012
© Оформление, издание, ДМК Пресс, 2013

Оглавление

Предисловие ..........................................................................6
Введение .................................................................................8

Глава 1
Корпоративный «паспортный стол» ...................................12

1.1. Создание удостоверяющего центра ....................................13

1.1.1. Файловая структура CA ................................................................13
1.1.2. Конфигурационный файл openssl.cnf..........................................15
1.1.3. Задание subjectAltName ................................................................25
1.1.4. Создание ключа СА .......................................................................26
1.1.5. Скрипты по управлению СА .........................................................28

1.2. Генерация запроса на сертификат .......................................38

1.2.1. Создание запроса на сертификат с помощью OpenSSL ......40
1.2.2. Создание запроса на сертификат с помощью Crypto4 PKI ....46
1.2.3. Создание запроса на сертификат с помощью Certreq.exe .....50

1.3. Создание сертификата .........................................................55
1.4. Отзыв сертификата. Управление списками отзыва .............59
1.5. Передача сертификата по сетям общего пользования .......62
1.6. Дополнительные операции с сертификатами ......................65

Глава 2
Сертификаты в браузерах Интернет ..................................71

2.1. Установка сертификатов в браузеры ...................................72

2.1.1. В системное хранилище Windows ...............................................73
2.1.2. В браузер Mozilla Firefox ...............................................................80

ОГЛАВЛЕНИЕ

2.1.3. В браузер Opera.............................................................................84

2.2. Доступ к ресурсам, защищенным сертификатами ..............88

2.2.1. Из браузера Internet Explorer .......................................................89
2.2.2. Из браузера Mozilla Firefox ..........................................................92
2.2.3. Из браузера Opera ........................................................................95
2.2.4. Из браузера Google Chrome ......................................................97

2.3. Общие ошибки при использовании сертификатов .............98

2.3.1. Подключение без сертификата ...................................................99
2.3.2. Невозможно проверить подлинность сертификата ..............101
2.3.3. Срок действия сертификата истек или еще не начинался .....104
2.3.4. Сертификат отозван  ...................................................................107
2.3.5. Другие ошибки сертификатов ....................................................109

Глава 3
Сквозная аутентификация в электронной почте ............. 110

3.1. Аутентификация в AD с помощью PAM- и NSS-сервисов ...114
3.2. Настройка модулей nss_ldap и pam_ldap .......................... 117

3.2.1. Настройка nss_ldap.conf .............................................................117
3.2.2. Настройка pam_ldap.conf ..........................................................121
3.2.3. Примеры конфигурационных файлов модулей NSS и PAM ....122
3.2.4. Изменения на сервере контроллера домена ........................123

Глава 4
Защита электронной почты .............................................. 130

4.1. Сертификаты в sendmail ..................................................... 131

4.1.1. Простое шифрование ..................................................................134
4.1.2. Шифрование с взаимной перекрестной проверкой  ...........139
4.1.3. Шифрование при приеме от локального пользователя ......145

4.2. Сертификаты в почтовых серверах для локального 
офиса ................................................................................... 150
4.2.1. Использование сертификатов в POP3-сервере qpopper ...151
4.2.2. Использование сертификатов в IMAP-сервере dovecot .....154

4.3. Сертификаты в клиентских почтовых программах ........... 158

4.3.1. Сертификаты в программе Mozilla Thunderbird ....................159
4.3.2. Сертификаты в программе Microsoft Outlook 2007 .............164

ОГЛАВЛЕНИЕ

4.3.3. Сертификаты в Opera Mail .........................................................167
4.3.4. Сертификаты в почтовых программах мобильных 
устройств ....................................................................................................169

Глава 5
Корпоративный веб-портал ............................................. 172

5.1. Сертификаты в веб-сервере Apache ................................. 174
5.2. Установка Horde Groupware Webmail Edition ................... 179
5.3. Настройка Horde Groupware Webmail Edition .................. 187

5.3.1. Настройки портала в целом (модуль horde) ...........................188
5.3.2. Настройки функциональных модулей портала ......................198
5.3.3. Дополнительные настройки в конфигурационных файлах ....200

5.4. Пользовательские настройки и почтовые функции 
Horde4 ................................................................................. 207
5.4.1. Пользовательские настройки портала ....................................208
5.4.2. Почтовые функции Horde4 .........................................................215

5.5. Функции календаря, задач и заметок в Horde4 ............... 220

Глава 6
Защита служебных коммуникаций .................................. 230

6.1. Удаленная работа на сервере UNIX без ввода пароля ... 233

Заключение ....................................................................... 241
Глоссарий .......................................................................... 242
Внешние ссылки и литература ......................................... 245
Предметный указатель ..................................................... 247

Предисловие

Пожалуй, нет ничего более неприятного на свете, чем быть разбуженным 
рано утром во время отпуска. Мозг еще цепляется за остатки сна, 
а слух уже ловит «трубный глас» мобильника, играющего мелодию, 
которая настроена на непосредственного руководителя. Полный неприятных 
предчувствий, вы подымаете трубку и слышите роковые 
слова: «Сервер взломан, почта похищена, сеть неработоспособна, сайт 
в черном списке». И, несмотря на то что вы предсказывали это еще 
два месяца назад, это произошло именно тогда, когда вам удалось 
отпроситься в отпуск. И теперь большая часть того, что вам хочется 
сказать, состоит из слов, воспроизвести которые не возьмется ни один 
забор...
Всего лишь несколько лет назад таким абзацем можно было бы начинать 
фантастические произведения на тему «постъядерной зимы», 
захвата мира кибермозгом и т. п. Сейчас это пойдет разве что на 
скромную газетную статью об очередном взломе очередного сервера. 
Тема информационной безопасности, в особенности  корпоративной 
информационной безопасности, сейчас стоит остро, как никогда, – 
почти каждый день приносит сообщения то о взломе банка и утечке 
данных кредитных карт, то о взломе крупного игрового сервера и 
утечке сотен тысяч пользовательских бюджетов. Ну а уж о «сливе» 
информации действующими и уволенными сотрудниками я даже и 
не говорю – порой ценные данные от утечки спасают только глупость 
и некомпетентность. Есть защита от дурака, а есть защита дураком, и 
зачастую только она одна и выручает – люди просто не знают, что у 
них лежит под боком и кому это можно сбыть. Но однажды находятся 
те, кто догадывается...

ПРЕДИСЛОВИЕ

Почему так происходит? Да потому, что правильно построенная 
информационная безопасность предъявляет множество требований 
к организации и людям. Требуется наличие грамотно составленной 
политики информационной безопасности, которая немыслима без 
полного анализа бизнес-процессов, производящих и потребляющих 
данные. В существующей системе их далеко не всегда можно реализовать, 
как правило, из-за человеческого фактора (Вася – мой друг! 
Что из того, что он не сотрудник? Настроить сеть так, чтобы он мог 
прийти к нам в офис и выходить в инет со своего планшета!). Да и 
финансовые соображения здесь играют далеко не последнюю роль – 
затраты на безопасность по определению пассивны, и не приведи Господи 
применить их по назначению! Раза после второго, когда «вдруг» 
ценные коммерческие данные оказываются у конкурентов просто 
потому, что были переотправлены (легитимно!) через бесплатный 
почтовый ящик, который на следующий день был взломан, когда содержимое 
конфиденциального письма одного руководителя другому 
становится известно третьему, от которого его нужно было категорически 
утаить (потому что один из руководителей был в отпуске за 
рубежом и письмо ему зачитывала в трубку секретарь, которая потом 
проболталась подруге...), интерес к защите информации «внезапно» 
просыпается и приходится с криком «Ура!» бросаться на амбразуру 
(заказывать оборудование, устанавливать софт, планировать, писать, 
раздавать указания и т. д.). 
Зато потом в течение какого-то времени одно слово  – «утечка» – 
будет обладать в течение какого-то времени (пока еще не забылось) 
поистине магической силой – вопросы будут решаться максимально 
быстро, счета подписываться без вопросов...
Возможно, эта книга сэкономит вам несколько ценных часов. Или 
даже дней. Потому что информация, собранная в ней в компактном 
и готовом к употреблению виде, тоненьким слоем размазана по Интернету, 
по зиллиону сайтов, форумов, файлов технической документации 
и т. д.
Пользуйтесь на здоровье.

Введение

Это книга о том, как построить защиту информации в корпоративной 
сети. О том, как обеспечить основной принцип – надежно доступна 
кому надо, надежно защищена от того, от кого не надо, и надежно контролируется 
тем, кем надо. Рассчитана она на администраторов сетей, 
в которых, кроме офиса, имеются еще и филиалы или розничная сеть, 
требующие постоянной связи с центром, хотя многие приемы с некоторыми 
оговорками можно применять в любых случаях. За основу 
для построения сети берется ОС UNIX (конкретно FreeBSD). Да-да, 
не переживайте, у вас все в порядке с глазами. На ответственных постах 
не будет никакого Windows. У Windows будет своя задача – Active 
Directory, офис, базы данных, пользователи... В качестве же ОС для 
построения сети – только UNIX.
Это естественным образом подводит нас к тому, что многое здесь 
будет делаться «самопально» – написанием собственных скриптов, 
обработчиков, посредников и т. д. Специализированный код всегда 
работает быстрее и эффективнее универсального. Платой за это 
является то, что сначала этот специализированный код необходимо 
написать, поэтому крайне желательно, чтобы вы умели программировать 
на каком-либо скриптовом языке, хоть на Visual Basic Script (на 
самом деле для Windows – вполне себе ничего язык). Ну а потому что 
это UNIX, конфигурироваться все это будет исключительно правкой 
текстовых файлов. При этом, поскольку я отношусь к тем людям, 
которые предпочитают вместо навязывания готовых решений выдать 
максимальное количество информации и оставить с ней наедине, чтобы 
вы сами создали свой, нужный именно вам конфигурационный 
файл, поясняться все будет очень подробно, причем говорить будем 
не только о том, что произойдет, если сделать как сказано, но и что 

ВВЕДЕНИЕ

случится, если сделать не так, как сказано, а наоборот. Хотя, конечно, 
готовые примеры будут, и в большом количестве.
В главе первой мы составим наши наполеоновские планы по защите 
от злобных хакеров и запустим наш «паспортный стол» – Удостоверяющий 
Центр (Certificate Authority), который впоследствии 
позволит нам беспрепятственно делить пользователей на «своих» и 
«чужих».
В главе второй расскажем об установке сертификатов в браузеры 
и системное хранилище Windows, рассмотрим типичные ошибки при 
использовании сертификатов.
В главе третьей настроим модули для сквозной аутентификации 
на сервере без использования такой громоздкой и в последнее время 
весьма «дырявой» вещи, как Samba. Мы люди простые, обойдемся 
без нее.
В главе четвертой закрываем самое ценное – электронную почту. 
Защищается среда передачи внутри офиса как от клиента к серверу 
(отправляемая почта), так и от сервера к клиенту (просматриваемая 
почта). Защищается также коммуникация между серверами узлов 
сети, а при наличии правильной настройки внешних серверов – и 
коммуникация с ними. Здесь же мы расскажем о том, как настроить 
клиентские почтовые программы – Mozilla Thunderbird и Microsoft 
Outlook, а также какие тут могут возникать ошибки.  
В главе пятой разворачиваем веб-интерфейс для доступа к электронной 
почте с произвольной точки (чтобы не приходилось секретарше 
читать письма вслух, когда руководитель в Дубае:-)) и защищаем 
его от посторонних, предполагая, что с сертификатами в браузере мы 
уже умеем работать.
Ну и в главе шестой защищаем служебные коммуникации – собственно 
программы-аутентификаторы, а также разбираемся, как избежать 
необходимости указания паролей в командных файлах Windows, запускаемых 
по расписанию или событию (например, при обработке сигнала 
от UPS). Ну а про то, что рутовый пароль вообще не должен НИГДЕ 
использоваться, кроме как для входа с консоли в самом крайнем случае, 
я думаю, вы и так знаете. Ну а не знали – так знаете теперь.
Понятное дело, что нам придется разбирать примеры. Чтобы каждый 
раз не объяснять, что «из пункта А до пункта Б шел пешеход, 
он шел и думал», заранее опишем конфигурацию, применительно к 
которой будут строиться любые примеры. Эта конфигурация показана 
на рис. В.1.

ПРЕДИСЛОВИЕ

Веб-сервер, сервер 
отправки почты
www.deltahw.ru
(FreeBSD 8.2)

 Шлюз сети A
node1.deltahw.ru
(FreeBSD 8.2)

Машина WinX

212.20.5.1

 Шлюз сети B
node2.deltahw.ru
(FreeBSD 8.2)

Машина WinY

170.70.70.1

180.80.80.1

10.87.1.1

10.42.1.1

10.42.1.2

10.87.1.2

 Машина WinZ

10.54.1.1

10.54.1.2
                   
Сервер приема почты
mail.deltahw.ru
(FreeBSD 8.2)

 Шлюз 
kaktus.deltahw.ru
(FreeBSD 8.2)

212.20.5.9

212.20.5.3

212.20.5.2

Switch

Интернет

Рис. В.1. Конфигурация сети, на которой будут разбираться примеры

Перед тем как начать приводить примеры, я хочу сделать одно 
замечание. Ниже приводится описание некой компании, применительно 
к которой будут рассматриваться все примеры. Также мне 
придется приводить фрагменты логов и конфигурационных файлов. 
В этих примерах, логах, файлах будут указаны почтовые адреса, адреса 
серверов и прочая информация, даже «персональные данные»! 
Так вот – все эти адреса и прочее – ненастоящие! Несмотря на то что 
приводимая конфигурация вся протестирована, все фрагменты будут 
намеренно искажены так, что все почтовые адреса, IP-адреса и имена 
серверов будут заменены придуманными, никогда не существовавшими 
адресами. Они только похожи на настоящие. Имейте это в виду.
Кроме того, поскольку нам придется выдавать и проверять персональные 
сертификаты, мы «назначим» в компании как минимум 
директора и системного администратора. Все совпадения с реальными 
именами, фамилиями и должностями случайны, все персонажи 
вымышлены. Как говорил в свое время один из моих любимых 
писателей Томас Майн Рид: «Читатель! Перед тобой роман и ничего 
более. Не считай автора книги ее героем».
Предположим, существует фирма «DeltaHardware Ltd.», которая 
занимается производством и продажей средств промышленной автоматизации. 
У нее есть центральный офис с IP-адресом 212.20.5.1 
и некоторое количество филиалов – на схеме показаны два: с IP-
адресами 180.80.80.1 и 170.70.70.1. Все подразделения объединены в 

ВВЕДЕНИЕ

один VPN, в котором сеть головного офиса имеет адрес 10.54.1.0/24, 
сеть первого филиала – 10.42.1.0/24, а сеть второго – 10.87.1.0/24. 
В каждой сети UNIX-шлюз имеет адрес .1 (например, 10.54.1.1), контроллер 
домена Windows – .2 (например, 10.42.1.2). Фирма имеет 
собственный сайт по адресу http://www.deltahw.ru, который размещен 
также на 212.20.5.1, почтовый сервер mail.deltahw.ru с адресом 
212.20.5.2 и файрволл по адресу 212.20.5.3. Внешний адрес файрволла 
212.20.5.9. На всех UNIX-шлюзах установлена FreeBSD 8.2-STABLE, 
на контроллерах домена Windows – Windows 2003 R2 Server, на рабочих 
станциях – Windows XP. Да, я знаю, что уже есть Windows 7 и 
Windows 2008 Server. Но корпоративная среда отличается большой 
инертностью и склонностью не менять программы без крайней на то 
необходимости – ведь это все будет стоить немалых денег. Вследствие 
того, что у директора «экономить мое любимое», на рабочих станциях 
стоит минимум платного программного обеспечения и вместо привычной 
многим связки Microsoft Office плюс Microsoft Exchange будет 
стоять Mozilla Thunderbird + Mozilla Sunbird + хранение почты на 
сервере и доступ по протоколу IMAP. Имя домена Windows – deltahw.
int, «короткое» имя – DELTAHW (потом эти имена нам понадобятся).

Директором конторы является Головань Павел Серафионович, 
почтовый адрес golovan-ps@deltahw.ru, системным администратором – 
Северцев Руслан Валентинович, почтовый адрес – severtsev-
rv@deltahw.ru.
Вперед, викинги!

КОРПОРАТИВНЫЙ 
«ПАСПОРТНЫЙ 

СТОЛ»
1

ГЛАВА

Большая работа всегда начинается с большого… нет, не перекура, а с 
большого плана. Итак:

филиалы при подключении к VPN должны быть уверены в том, 
что «та» сторона – это именно тот компьютер, за который он 
себя выдает;
почтовые серверы при пересылке писем между узлами VPN 
должны быть уверены в том, что получатель – именно тот, за 
которого он себя выдает;
при подключении к веб-интерфейсу почты сервер должен быть 
уверен, что клиент имеет право к нему подключаться, а клиент – 
в том, что сервер – именно тот сервер, за которого он себя 
выдает.

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

значит, он подлинный. Вот поначалу мы и займемся тем, что создадим 
собственный «паспортный стол», а потом объявим, что в масштабах 
компании наличие сертификата, подписанного сертификатом нашего 
УЦ, означает его подлинность.
УЦ будет размещаться по адресу 212.20.5.1, на компьютере www.
deltahw.ru (это чтобы не путаться при создании сертификатов).
И точно так же, как наличие паспорта у человека означает предоставление 
ему некоторых привилегий, так и наличие сертификата 
будет означать предоставление привилегий с точки зрения программы. 
Правда, привилегия будет всего одна – предоставить доступ к 
данным.

1.1. Создание удостоверяющего 
центра

Прежде чем выдавать паспорта, надо построить паспортный стол. 
Прежде чем выдавать сертификаты, необходимо будет создать  удостоверяющий 
центр (УЦ). Правда, мы будем пользоваться его англоязычным 
наименованием – СА, Center of Authority – так будет 
понятнее при чтении документации и конфигурационных файлов. 
В UNIX для создания не нужно ничего запускать: собственно весь 
CA – это несколько файлов и каталогов, ключ самого CA, сертификат 
CA и список отозванных сертификатов. Ну и конечно же конфигурационный 
файл  openssl.cnf, настройки которого будут играть чрезвычайно 
важную роль. Собственно говоря, openssl.cnf и ключ корневого 
сертификата CA плюс его индексный файл и есть CA, потому что все 
остальное – просто обвязка. 

1.1.1. Файловая структура CA

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

принятые нами запросы на сертификацию (CSR);
подписанные нами сертификаты (CRT);
список отозванных сертификатов (CRL);
закрытый ключ нашего собственного сертификата.

СОЗДАНИЕ УДОСТОВЕРЯЮЩЕГО ЦЕНТРА