скачать рефераты
  RSS    

Меню

Быстрый поиск

скачать рефераты

скачать рефератыРеферат: Исследование уровня безопасности операционной системы Linux

Схема сетевого запроса на сервер с установленным брандмауэром показана на рисунке 2.4.1.


Рис. 2.4.1. Пошаговая схема выполнения сетевого запроса с установлением соединения к ОС Linux



Ядро ОС Linux версии 2.4 и более поздних имеет встроенный межсетевой экран netfilter, который располагает следующими возможностями:

·     позволяет осуществлять фильтрацию входящих, исходящих и транзитных пакетов, основываясь на содержании заголовка пакета, типе пакета, определяющего его состояние в соединении (первый пакет установления соединения, пакет синхронизации,  пакет завершения сеанса), IP адресе компьютера-отправителя и компьютера-получателя, MAC адресе отправителя и получателя и так далее.

·     позволяет осуществлять трансляцию сетевых адресов NAT (Network Address Translation) и подмену портов NPT (Network Port Translation). Действие NAT заключается в подмене IP адреса компьютера-отправителя или компьютера-получателя на указанный. В большинстве случаев эта возможность используется для организации обмена информацией между двумя сетями, имеющими разные диапазоны IP адресов. Действие NPT аналогично NAT с тем различием, что в последнем производится подмена порта приложения вместо IP адреса.

·     позволяет менять специальные поля заголовка пакета, такие как TOS (Type Of Service), TTL (Time To Live) и так далее, что предоставляет расширенные возможности для управления процессом маршрутизации.

Вся логическая структура экрана netfilter строится на понятиях цепочек, таблиц и правил доступа.

Цепочка – определенный набор правил управления доступом. Попадая в цепочку, пакет проходит все ее правила, начиная с самого первого. Каждое правило имеет критерий и действие. Если пакет попадает под критерий правила, то с пакетом производится действие, определенное для этого правила.

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

Netfilter содержит только три таблицы:

mangle – эта таблица используется для внесения изменений в заголовки пакетов. Примером может служить изменение поля TTL, TOS или MARK. Таблица имеет пять цепочек: PREROUTING, POSTROUTING, INPUT, OUTPUT и FORWARD. Цепочка PREROUTING используется для внесения изменений на входе в брандмауэр, перед принятием решения о маршрутизации. Цепочка POSTROUTING используется для внесения изменений на выходе из брандмауэра уже после принятия решения о маршрутизации. Цепочка INPUT используется для внесения изменений в пакеты перед тем, как они будут переданы локальному приложению внутри брандмауэра. Цепочка OUTPUT используется для внесения изменений в пакеты, поступающие от приложений внутри брандмауэра. И, наконец, цепочка FORWARD используется для внесения изменений в транзитные пакеты после первого принятия решения о маршрутизации, но перед последним принятием решения о маршрутизации. Использование таблицы для других целей, нежели изменения заголовка пакета, является недопустимым.

nat – эта таблица используется для преобразования сетевых адресов, именуемого также NAT, и подмены портов NPT. Через эту таблицу проходит только первый пакет из всего потока данных соединения. Преобразование адресов автоматически применяется ко всем последующим пакетам. Эта таблица содержит три заранее определенные цепочки. Цепочка PREROUTING используется для внесения изменений в пакеты на входе в брандмауэр. Цепочка OUTPUT используется для преобразования адресов в пакетах, созданных приложениями внутри брандмауэра, перед принятием решения о маршрутизации. И последняя третья цепочка в этой таблице – POSTROUTING, которая используется для преобразования пакетов перед отправкой их в сеть. Эта таблица должна использоваться только для преобразования адресов и портов в пакете.

filter – эта таблица используется главным образом для фильтрации пакетов. Таблица имеет три встроенных цепочки. Первая – FORWARD, используемая для фильтрации пакетов, не адресованных серверу, на котором установлен брандмауэр, то есть идущих транзитом через него. Цепочку INPUT проходят пакеты, которые предназначены локальным приложениям сервера. И цепочка OUTPUT используется для фильтрации исходящих пакетов, сгенерированных приложениями на сервере с брандмауэром.

Структурная схема брандмауэра netfilter показана на рисунке 2.4.2.


Рис. 2.4.2. Структурная организация брандмауэра

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

Следуя рисунку 2.4.2, рассмотрим, какой путь совершает пакет, прежде чем достичь места назначения. Попадая на сервер, пакет сначала проходит цепочки PREROUTING таблиц mangle и nat. Затем, в зависимости от того, кому адресован пакет, его направление может меняться. Если пакет адресован локальному процессу сервера, после маршрутизации он попадает в цепочки INPUT таблиц mangle и filter. Если ему удается успешно пройти эти цепочки, пакет достигает локального процесса. Ответ локального процесса перед отправкой проходит сначала цепочку OUTPUT всех трех таблиц, и, если пакет не был отфильтрован, он попадает в заключительную цепочку POSTROUTING таблиц mangle и nat. После этого пакет покидает сервер.

Если же пакет адресован другому компьютеру, то есть является транзитным, то после маршрутизации он попадает в цепочку FORWARD таблиц mangle и filter, в которой осуществляются все необходимые действия по управлению доступом для всех транзитных пакетов. Далее, как и пакет локального процесса, перед отправкой в сеть транзитный пакет проходит через цепочки POSTROUTING таблиц mangle и nat.

Этих трех таблиц с заранее закрепленным функциональным назначением вполне достаточно для реализации всех перечисленных ранее возможностей. Количество таблиц является определенным и не может быть изменено ни при каких условиях. При настройке брандмауэра в таблицы могут быть добавлены другие цепочки в дополнение к уже существующим, что позволяет создавать более гибкую систему управления доступом, нежели просто добавление правил в заранее определенные цепочки. В отличие от цепочек, созданных администратором, системные цепочки INPUT, OUTPUT, FORWARD, PREROUTING и POSTROUTING не могут быть удалены ни при каких условиях.

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

iptables – основная программа пакета, с помощью которой производится манипулирование правилами в цепочках. Эта программа позволяет совершать с правилами и пользовательскими цепочками все доступные действия.

iptables-save – программа, которая позволяет сохранять все текущие правила в одном файле для последующего их восстановления. По умолчанию этим файлом является /etc/sysconfig/iptables. В файле /etc/sysconfig/iptables хранится вся конфигурация брандмауэра и из этого файла она считывается при загрузке системы.

iptables-restore – эта программа позволяет считывать правила и цепочки, сохраненные ранее программой iptables-save. По умолчанию эта программа пытается загрузить файл /etc/sysconfig/iptables, если он существует.

Более подробная информация о программном пакете iptables содержится в файлах документации, а также в соответствующих man-руководствах.

Практическое применение рассмотренной информации приводится в приложении в примере 6.

2.5. Удаленное управление

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

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

В таких случаях идеальным решением является организация полнофункционального управления сервером посредством сетевого доступа. Существует несколько очень распространенных протоколов удаленного администрирования, позволяющих управлять системой посредством сети. Самым старым и самым распространенным, но в то же время самым небезопасным, является протокол Telnet. Это самый первый протокол удаленного взаимодействия, появившийся на заре развития вычислительных сетей, когда проблеме безопасности при передаче информации не уделялось практически никакого внимания. При передаче информации по протоколу Telnet все данные передаются в открытом незашифрованном виде, в том числе имена и пароли пользователей. Любой, даже малоопытный в компьютерных делах, пользователь, имея программу под общим названием network sniffer (с англ. «сетевой анализатор пакетов»), может получить имя и пароль при передаче их по сети.

Помимо протокола Telnet в UNIX-системах существует целое семейство так называемых r-программ. К ним относятся rsh, rlogin (начальная буква r трактуется как remote) и другие, позволяющие производить различные операции, связанные с удаленным администрированием. Однако уровень безопасности при использовании r-программ, как и уровень безопасности при использовании Telnet, также оставляет желать лучшего.

Существует еще один протокол для управления некоторыми параметрами системы и получения информации о ней. Это протокол SNMP (Simple Network Management Protocol). Протокол SNMP имеет ограниченный спектр возможностей и не лишен тех же недостатков в плане безопасности, что и протокол Telnet.

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

На сегодняшний день одним из самых распространенных и безопасных протоколов удаленного администрирования, использующих шифрование при передаче данных, является протокол SSH (Secure SHell). Рассмотрим поподробнее, в чем же состоит преимущество  протокола SSH перед другими протоколами удаленного управления.

Протокол SSH появился в 1995 году и с самого начала в основу была положена идея создания средства организации безопасного доступа к компьютерам при работе по небезопасным каналам связи, таким как сеть Интернет. В протоколе SSH для организации безопасного доступа применяется процедура аутентификации с использованием асимметричного шифрования с открытым ключом. Это обеспечивает более высокую безопасность, чем при использовании симметричного шифрования, хотя и порождает дополнительную вычислительную нагрузку. При последующем обмене данными применяется уже симметричное шифрование, более экономичное в смысле затрат процессорного времени. Также SSH поддерживает возможность работы с уже упомянутым протоколом Telnet, безопасную работу по протоколу графического уровня X11, благодаря возможности перенаправления соответствующих данных по надежным SSH-каналам, предоставляет безопасную замену многим r-программам UNIX, с которыми традиционно связаны проблемы обеспечения безопасности.

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

Протокол транспортного уровня обеспечивает аутентификацию сервера, конфиденциальность и целостность. Протокол аутентификации обеспечивает аутентификацию клиента для сервера. Наконец, протокол соединения SSH мультиплексирует безопасный шифруемый канал, представляя его в виде нескольких логических каналов, которые используются для различных целей или различных видов служб. Помимо этого протокол транспортного уровня предусматривает возможность сжатия данных, что является бесспорным преимуществом по сравнению с протоколом Telnet при передаче данных по низкоскоростному каналу. Протокол транспортного уровня работает поверх соединения TCP/IP, в свою очередь  протокол аутентификации работает поверх протокола транспортного уровня, а протокол соединения – поверх протокола аутентификации. В итоге получается жесткая взаимосвязь протоколов, обеспечивая в сумме наиболее безопасную и эффективную передачу данных.

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

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

При установке пакета из исходных файлов при запуске программы конфигурирования configure можно задать целый ряд ключей. В частности, можно указать, какие методы шифрования сеанса будут использованы при работе SSH: IDEA, DES, тройной DES, ARCFOUR и BLOWFISH. По умолчанию основным является алгоритм IDEA, использующий 128-разрядные ключи. Если он исключен соответствующим ключом, основным алгоритмом становится 3DES - трехкратное последовательное DES-шифрование c 56-разрядным ключом. Можно выделить также метод BLOWFISH, который при той же длине ключа (от 32 до 448 разрядов) работает быстрее IDEA и DES. Можно задать также замену стандартных команд rlogin и rsh соответствующими одноименными модулями из дистрибутива SSH. Тогда для соединений будет использоваться протокол SSH, конечно, если удаленный компьютер его поддерживает. В противном случае после предупреждения будет осуществлен переход к обычным r-средствам. Все возможные ключи конфигурационной программы можно узнать из документации, идущей с дистрибутивом, или запуском программы с ключом –help.

По умолчанию, если путь не был изменен ключом  конфигурационной программы, файлы конфигурации OpenSSH при установке помещаются в каталог /usr/local/etc/ssh. После установки этот каталог содержит несколько конфигурационных файлов, основными из которых являются файлы конфигурации sshd_config и ssh_config серверной и клиентской частей соответственно. Эти файлы имеют формат

Страницы: 1, 2, 3, 4, 5, 6, 7, 8, 9


Новости

Быстрый поиск

Группа вКонтакте: новости

Пока нет

Новости в Twitter и Facebook

  скачать рефераты              скачать рефераты

Новости

скачать рефераты

© 2010.