:::::: ЧОУ ДПО «Центр предпринимательских рисков» :::::

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

Ядро системы

Основная задача ядра системы – обеспечение выполнения процессов в системе, организация разделения времени и ресурсов, в том числе оперативной памяти. Перед загрузкой ядру Linux можно передать параметры загрузки, которые могут изменить нормальный режим загрузки. В частности, в ядре имеется возможность загрузки с заданием инициализационного процесса, отличного от стандартного init. Инициализационный процесс – это первая программа, которая выполняется после загрузки ядра. Стандартный процесс init выполняет загрузочные сценарии и запускает сервисы, в частности запускает процессы getty для терминальных линий и виртуальных консолей. Это важный момент обеспечения безопасности, так как процессы getty (в популярных дистрибутивах Linux, как правило, используется вариант mingetty, mgetty или agetty) организуют доступ к системе с обслуживаемых ими консолей.

Изменение режима загрузки, как правило, необходимо в случае аварийного восстановления системы или иногда используется в вариантах ОС Linux для встраиваемых систем. В случае физического доступа к компьютеру посторонних лиц потенциально существует опасность изменить параметры загрузки и получить неограниченный доступ к системе. Для предотвращения подобной опасности применяется парольная защита в менеджерах загрузки ОС. Стандартные загрузчики Linux (grub и lilo) имеют такую возможность, кроме того, grub может хранить пароли загрузки в зашифрованном виде.

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

Ошибки переполнения буфера могут возникать и в ядре. К счастью, подобные ошибки, как правило, приводят к краху системы и, соответственно, легко выявляются. Так как разработкой и тестированием ядра Linux занимается огромное количество людей, а также благодаря возможности провести аудит кода, ввиду доступности ядра в исходных текстах, информация о потенциальных дырах и ошибках довольно быстро становится общедоступной. К этому можно относиться по-разному: с одной стороны, информацией об ошибках владеют и потенциальные взломщики и многочисленные недоброжелатели, с другой – неоспорим и лозунг «кто информирован – тот вооружен». Несмотря на доступность исходных текстов, из-за сложности ядра системы и использования в нем низкоуровневого программирования, решение подобных проблем для пользователей, как правило, одно: обновление ядра либо, при наличии должной квалификации, – пересборка ядра с необходимыми «заплатками», что, откровенно говоря, лучше.

Что касается ошибок в прикладных программах, то здесь также применимо все, что сказано по поводу ядра. В случае если программа разрабатывается самостоятельно, то существуют средства предварительной проверки кода на наличие потенциальных ошибок и дыр. В данном случае акцент следует ставить на слове «существуют», так как ошибки в программах не являются исключительной особенностью GNU/Linux, но для ОС Linux существуют средства проверки кода. Конечно, они имеются и для других ОС, но суть все же не в этом. Среди наиболее известных и доступных бесплатных средств проверки исходного кода для Linux можно назвать flowfinder, its4 и RATS. Все они предназначены для проверки программ, написанных на языке C, так как ошибки переполнения буфера и доступа к памяти в основном возникают при программировании именно на нем.

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

Разграничение доступа

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

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

Такой способ разграничения – наследие Unix. Можно сказать, что он несколько устарел, если рассматривать его в рамках какой-либо распределенной информационной среды, но это не суть важно, так как использование acl или dacl (списки доступа) с точки зрения безопасности имеет в основном те же проблемы. Потенциальная опасность здесь заключается в неверной установке прав доступа к файлам и каталогам, не предназначенным для посторонних. Это может относиться к секретной переписке по e-mail начальника или доступе к базе данных паролей. Конечно, подобные промахи, как правило, на совести администратора системы. Но даже очень квалифицированный специалист не в состоянии отследить все файлы в системе, количество которых может превышать десятки и даже сотни тысяч, и права доступа к ним. Для решения подобных проблем существует несколько способов, один из которых – использование средств проверки целостности файловой системы.

Системный журнал

Нормальной практикой большинства приложений для ОС Linux, в том числе и для ядра системы, является запись всех важных событий в жизни приложений в системный журнал. Системный журнал – это фактически аналог «черного ящика» или судового журнала. В Linux ведение журнала предоставлено отдельному системному сервису syslog, а в случае ядра – klog. Записи системного журнала имеют определенный формат, в котором указывается время события, имя процесса, приоритет события и строка, отражающая событие. На самом деле, системный журнал, как правило, состоит из нескольких файлов в каталоге /var/log. Имена файлов и тип событий в этих файлах можно настраивать. Чем же полезен системный журнал? В первую очередь, большинство непредвиденных ситуаций возникают вовсе не вдруг и не в пятницу вечером, большинство из них имеет вполне определенные предшествующие изменения в характере работы системы. Эти изменения можно иногда зафиксировать при помощи анализа системного журнала: скажем, проанализировать периодичность какоголибо события или адекватность его в контексте работы системы. Таким образом, можно выявить, например, подозрительную активность хакеров или неочевидные ошибки конфигурации. Для анализа подобных ситуаций применяются средства автоматизации, один из них logcheck. Так как создание универсального инструмента анализа системных журналов – задача бессмысленная, для анализа системного журнала чаще всего пользуются собственными средствами. Лучше, если этим средством окажется какая-нибудь программа, а не администратор системы.

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

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

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

Первый случай – авторизация пользователя в самой системе для использования ее локальных ресурсов. Что собой представляет авторизация? В отличие от доступа к файлам, во время авторизации осуществляется проверка доступности для пользователя определенного сервиса, предоставляемого системой, например сервиса login для входа в систему или сервиса удаленного копирования файлов ftp. Можно разрешить одному пользователю копировать файлы, но в то же время запретить использовать login, другому, наоборот, запретить пользоватся ftp, но предоставить возможность отправлять почту.

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

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

Мы не будем уделять внимание ситуации, когда сервис также производит и проверку соответствия, так как это – пагубная практика, имеющая смысл лишь при условии предоставления одного публичного сервиса. Система производит проверку соответствия на основании файла паролей /etc/passwd, в котором хранятся необходимые атрибуты пользователя; этот файл доступен только для чтения. Сами пароли хранятся отдельно в файле /etc/shadow, точнее даже не пароли, а их уникальные необратимые хэши. Этот файл не доступен ни для чтения, ни для записи никому, кроме «суперпользователя» (суперпользователь или root – вообще уникальная личность в мире Linux).

Угроза безопасности в данном случае состоит, собственно, в модификации файла /etc/passwd, так как формат файла предусматривает наличие у пользователя беспарольного доступа, а также содержит информацию об уровне прав в системе, наличие уровня 0 – означает полный контроль над системой. Однако не стоит преувеличивать эту угрозу. Как правило, изменения в файле легко обнаруживаются, да и изменить его – не такая уж тривиальная задача, так как правами его изменения обладает только «суперпользователь». Чтобы постороннее воздействие обнаружилось не слишком поздно, существуют описанные выше средства проверки целостности ФС, поэтому опытные взломщики-рецидивисты предпочитают не трогать этот файл, а используют так называемые backdoors: после взлома системы устанавливают сетевой сервис на каком-либо доступном сетевом порту, который позволяет им беспрепятственно воспользоваться системой в любое время, не зная пароля. Об этом речь пойдет ниже, при рассмотрении проблем сетевой безопасности.

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

PAM

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

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

К счастью, в Linux имеется реализация PAM (Pluggable Authentication Modules), благодаря которой можно организовать централизованное хранение записей о пользователях, причем совершенно необязательно в этом случае иметь запись о пользователе в файле паролей (/etc/passwd). Благодаря модульности система позволяет проводить авторизацию из различных источников. Кроме того, архитектура PAM такова, что позволяет организовать стек из модулей и таким образом обеспечить многоуровневую систему авторизации. В РАМ реализованы все средства для организации полноценной авторизации пользователя, включая проверку доступности сервиса. Таким образом, отпадает необходимость проводить подобные проверки самим сервисом.

Естественно, чтобы использовать PAM, необходима поддержка его в самом приложении (в данном случае – сервисе). В настоящее время поддержка PAM реализована в большинстве используемых сетевых сервисов, поставляемых вместе с дистрибутивами Linux. В PAM существуют такие понятия, как auth (аутентифиация), account (авторизация), session (сессия) и password.

auth проводит проверку валидности пользователя и предоставляет данные, связанные с пользователем (например, домашний каталог);
account проводит проверку доступности сервиса, проверку источника запроса (например, если используется ограничение по сетевым адресам), проверку времени и т. д.;
session позволяет управлять сессией после авторизации пользователями старта сервиса (может быть полезным, если необходим контроль времени использования сервиса или в иных случаях);
password необходим, собственно, только потому, что аутентификация в принципе может проводиться из любого источника, и дабы предоставить возможность изменения пользователем своего пароля, необходимо указать, как он это может сделать.

Для РАМ в настоящее время доступно огромное количество модулей, в том числе pam_ldap – для авторизации из сервера директории, pam_krb – для использования kerberos, pam_radius – для использования radius-серверов и многие другие. Все они позволяют организовать безопасную и удобную в обслуживании информационную инфраструктуру.

Сервисы авторизации

Так как выше были описаны способы авторизации в Linux, и в том числе с использованием внешних хранилищ информации о пользователях, следует хотя бы вкратце перечислить, какие из них доступны в ОС Linux. Таковыми являются практически все промышленные стандарты, к которым можно отнести radius (freeradius, icradius), tacacs, kerberos версии 4 и 5 (krb4), ldap (openldap).

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

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

Ядро ОС Linux реализует сетевой и транспортный уровни модели OSI, но наибольший интерес для нас представляет стек TCP/IP и организация работы с ним. Рассматривая сетевую безопасность, мы имеем в виду возможности ОС Linux по обеспечению защиты сетей, а не самой себя в сети. Потенциальная угроза сетям заключается в доступе к информации, хранящейся на компьютерах сети и передаваемой в сети или между сетями информации. Можно разделить методы достижения этих целей злоумышленниками или просто случайными людьми. В первом случае для доступа к хранящейся на компьютерах информации необходимо получить контроль над машиной, во втором – над средой передачи данных. Они тесно взаимосвязаны, однако имеют принципиальные различия как в получении контроля над ними, так и в обеспечении их защиты.

Среда передачи

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

Само ядро Linux может обеспечить шифрование только на сетевом уровне, остальное организуется приложением, однако реализация стека TCP/IP в Linux позволяет рассматривать шифрование на сетевом уровне в обозначенных нами рамках.

Для шифрования на сетевом уровне в Linux реализованы протоколы IPsec, CIPE и PPTP, они стандартизованы и их реализация практически полностью совместима с их реализациями в других ОС. Собственно эти протоколы используются при построении виртуальных частных сетей (VPN) и позволяют создавать шифрованные каналы «точка-точка». В последних версиях ядра используется бесплатная реализация IPsec от FreesWAN, доступны GPL-реализация PPTP для ОС Linux.

В случае если организация VPN или постоянного шифрованного соединения на сетевом уровне нецелесообразно или накладно, или попросту не требуется, возможна организация шифрования данных на транспортном уровне или, в терминах Linux, – на уровне сокетов. Для этих целей применяется протокол SSL (Secure Sockets Layer). SSL использует несимметричный метод шифрования RSA (в отличие от IPsec или CIPE, где используются блочные шифры), поэтому с точки зрения безопасности более предпочтителен, хотя и достаточно дорого обходится при большом объеме трафика. В Linux существует бесплатная (GPL) реализация SSL – библиотека OpenSSL. На ее основе реализованы многие защищенные сервисы, в частности Secure Shell (ssh). Есть возможность организовать прозрачное шифрование данных при помощи программы stunnel.

Системы хранения

Для защиты систем хранения будем рассматривать вариант использования Linux в качестве граничного шлюза сети либо ее части.

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

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

Кроме того, есть возможность скрыть внутреннюю структуру сети от «посторонних глаз» с помощью трансляции адресов. Другая возможность – организация виртуальных серверов, в этом случае к серверу внутри сети поступает только необходимая ему информация. Скажем, если это относится к web-серверу, то извне к нему поступают только пакеты, адресованные сервису http (80 порт), остальные попросту игнорируются, при этом снаружи сервис будет представлен таким образом, как будто он работает на сервере, на котором производится фильтрация.

Возможности Linux в фильтрации tcp/ip трафика действительно выдающиеся, при помощи netfilter и iptables можно создавать очень «крепкие орешки» для взломщиков.

Вирусы, однако, с помощью netfilter не отфильтруешь. Впрочем, и здесь есть за что зацепиться. Для ОС Linux существуют версии популярных антивирусных пакетов, а сами вирусы попадают на компьютер вместе с зараженными файлами. Основной путь заражения компьютеров windows – это электронная почта и web-сайты, то есть сама «соль» Интернета. Поэтому эти пути и следует в первую очередь прикрыть.

Наиболее популярный почтовый сервис sendmail имеет возможность фильтрации почты внешними программами еще на этапе ее получения, есть такая возможность у почтового сервера courier, также доступного для ОС Linux. Совместно с антивирусными программами они представляют собой последний бастион на пути вирусов. Использование антивирусов для www-трафика, скорее всего, неоправданно и сопряжено с принципиальными трудностями, решение которых порождает новые трудности. Поиск вирусов в www-трафике можно охарактеризовать известной фразой: грамм добычи, в год труды. При этом следует отметить, что вирусы в Linux не работают. Если сервер c Linux используется в качестве файл-сервера, можно проводить обычную проверку файлов.

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

Все упомянутые утилиты и средства взяты из стандартной поставки ASPLinux, за исключением средств аудита исходных текстов.