diplom (663758), страница 11

Просмтор этого файла доступен только зарегистрированным пользователям. Но у нас супер быстрая регистрация: достаточно только электронной почты!

Текст из файла (страница 11)

Для распределения нагрузки и простоты в управлении можно создать в таблице filter дополнительные цепочки с разным функциональным назначением.

[root@app /]# /sbin/iptables -N bad_tcp_packets

[root@app /]# /sbin/iptables -N allowed

[root@app /]# /sbin/iptables -N tcp_packets

[root@app /]# /sbin/iptables -N udp_packets

[root@app /]# /sbin/iptables -N icmp_packets

Цепочка bad_tcp_packets предназначена для отфильтровывания пакетов с "неправильными" заголовками. Здесь отфильтровываются все пакеты, которые распознаются как NEW, то есть пакеты, открывающие новое соединение, но не являются SYN пакетами, то есть часть пакета, ответственная за синхронизацию, отсутствует, а так же обрабатываются SYN/ACK-пакеты, имеющие статус NEW. Эта цепочка может быть использована для защиты от вторжения и сканирования портов.

[root@app /]# /sbin/iptables -A bad_tcp_packets -p tcp --tcp-flags SYN,ACK SYN,ACK -m state --state NEW -j REJECT --reject-with tcp-reset

[root@app /]# /sbin/iptables -A bad_tcp_packets -p tcp ! --syn -m state --state NEW -j LOG --log-prefix "New not syn:"

[root@app /]# /sbin/iptables -A bad_tcp_packets -p tcp ! --syn -m state --state NEW -j DROP

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

[root@app /]# /sbin/iptables -A tcp_packets -p TCP --dport 22 -j allowed

[root@app /]# /sbin/iptables -A tcp_packets -p TCP --dport 25 -j allowed

[root@app /]# /sbin/iptables -A tcp_packets -p TCP --dport 80 -j allowed

[root@app /]# /sbin/iptables -A tcp_packets -p TCP –i eth0 --dport 110 -j allowed

[root@app /]# /sbin/iptables -A tcp_packets -p TCP –i eth1--dport 110 -j allowed

Цепочка allowed используется для дополнительной фильтрации tcp пакетов, прошедших цепочку tcp_packets и разрешенных в ней. Первое правило проверяет, установлен ли в заголовке пакета бит SYN, то есть, является ли пакет первым пакетом установления соединения. Такие пакеты считаются разрешенными и пропускаются. Второе правило проверяет состояние пакета, и если оно либо ESTABLISHED, либо RELATED, то пакет разрешается. Эти состояния присваиваются пакетам, когда соединение уже установлено и ведется обмен данными. Последнее правило просто сбрасывает все остальные пакеты, не попавшие под первые два правила.

[root@app /]# /sbin/iptables -A allowed -p TCP --syn -j ACCEPT

[root@app /]# /sbin/iptables -A allowed -p TCP -m state --state ESTABLISHED,RELATED -j ACCEPT

[root@app /]# /sbin/iptables -A allowed -p TCP -j DROP

Цепочка udp_packets имеет ту же функцию, что и цепочка tcp_packets, с единственным отличием – в этой цепочке производится фильтрация udp-соединений. Сервис DNS использует как раз протокол UDP для обмена информацией, поэтому правило, которое будет разрешать пакеты DNS, необходимо добавить именно в эту цепочку.

[root@app /]# /sbin/iptables -A udp_packets -p UDP --dport 53 -j ACCEPT

Цепочка icmp_packets предназначена для фильтрации icmp-пакетов. Для нормального функционирования сервера Linux в сети достаточно разрешение только двух типов сообщений: ICMP Echo Request и Time Exceeded.

[root@app /]# /sbin/iptables -A icmp_packets -p ICMP --icmp-type 8 -j ACCEPT

[root@app /]# /sbin/iptables -A icmp_packets -p ICMP --icmp-type 11 -j ACCEPT

Еще раз хочу заметить, что по умолчанию без использования параметра –t все действия производятся в таблице filter.

Теперь перейдем к заполнению основных системных таблиц. Начнем с входящей цепочки INPUT таблицы filter.

[root@app /]# /sbin/iptables -A INPUT -p tcp -j bad_tcp_packets

[root@app /]# /sbin/iptables -A INPUT -i lo –s 127.0.0.0/8 -j ACCEPT

[root@app /]# /sbin/iptables -A INPUT -i lo -s 192.168.0.1 -j ACCEPT

[root@app /]# /sbin/iptables -A INPUT -i lo -s 192.168.1.1 -j ACCEPT

[root@app /]# /sbin/iptables -A INPUT -i lo -s 144.333.333.333 -j ACCEPT

[root@app /]# /sbin/iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

[root@app /]# /sbin/iptables -A INPUT –p TCP -j tcp_packets

[root@app /]# /sbin/iptables -A INPUT -p UDP -j udp_packets

[root@app /]# /sbin/iptables -A INPUT -p ICMP -j icmp_packets

[root@app /]# /sbin/iptables -A INPUT -m limit --limit 3/minute --limit-burst 3 -j LOG --log-level DEBUG --log-prefix "IPT INPUT packet died: "

Сначала все пакеты должны пройти через цепочку bad_tcp_packets на предмет неправильного заголовка. Далее необходимо принять все пакеты, пришедшие со всех адресов сетевых карт через локальный интерфейс. Такие пакеты могут посылать только локальные приложения, поэтому для их нормального функционирования необходимо пропускать эти пакеты беспрепятственно. Затем следует правило определяющее состояние пакета. Если пакет находится в одном из двух состояний (RELATED или ESTABLISHED), то он тоже беспрепятственно разрешается. Дело в том, что настройка брандмауэра подразумевает 99-процентную достоверность фильтрации приходящих запросов, поэтому, если соединение было разрешено на этапе установления, то при последующем обмене информацией критерии сервиса не проверяются, что позволяет немного увеличить скорость обработки и уменьшить нагрузку на сервер.

Если пакет не удовлетворяет ни одному из перечисленных условий, далее следуют правила, в которых пакет классифицируется по типу используемого протокола. Пакеты протоколов TCP, UDP и ICMP попадают в одноименные цепочки для их фильтрации по типу запрашиваемого сервиса. Если пакет проходит одну из этих цепочек, и к нему не было применено действие ACCEPT, то есть пакет не является запросом к разрешенному сервису, сначала происходит запись параметров запроса в журнальный файл (действие LOG), а затем применяется политика по умолчанию цепочки INPUT, то есть пакет просто уничтожается.

[root@app /]# /sbin/iptables -A FORWARD -p tcp -j bad_tcp_packets

[root@app /]# /sbin/iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT

[root@app /]# /sbin/iptables -A FORWARD -i eth0 –s 192.168.0.0/24 -j ACCEPT

[root@app /]# /sbin/iptables -A FORWARD -i eth1 –s 192.168.1.30 -j ACCEPT

[root@app /]# /sbin/iptables -A FORWARD -i eth1 –s 192.168.1.45 -j ACCEPT

[root@app /]# /sbin/iptables -A FORWARD -m limit --limit 3/minute --limit-burst 3 -j LOG --log-level DEBUG --log-prefix "IPT FORWARD packet died: "

Аналогично цепочке INPUT, пакеты, проходящие транзитом, сначала фильтруются на предмет неправильного заголовка с помощью таблицы bad_tcp_packets. Пакеты уже установленного соединения разрешаются без дополнительных проверок. Далее все пакеты, пришедшие с интерфейса eth0, через который к серверу подключена сеть 192.168.0.0, разрешаются, что позволяет всем пользователям сети 192.168.0.0 работать в Интернет. Однако, перед этим необходимо настроить NAT, что и будет сделано дальше.

[root@app /]# /sbin/iptables -t nat -A POSTROUTING -o eth2 -j SNAT --to-source 144.333.333.333

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

[root@app /]# /sbin/iptables -A OUTPUT -p tcp -j bad_tcp_packets

[root@app /]# /sbin/iptables -A OUTPUT -s 127.0.0.0/8 -j ACCEPT

[root@app /]# /sbin/iptables -A OUTPUT -s 192.168.0.1 -j ACCEPT

[root@app /]# /sbin/iptables -A OUTPUT -s 192.168.1.1 -j ACCEPT

[root@app /]# /sbin/iptables -A OUTPUT -s 144.333.333.333 -j ACCEPT

[root@app /]# /sbin/iptables -A OUTPUT -m limit --limit 3/minute --limit-burst 3 -j LOG --log-level DEBUG --log-prefix "IPT OUTPUT packet died: "

Для цепочки OUTPUT необходимо указать, с каких IP адресов разрешать пакеты. Здесь должны быть перечислены все адреса, которые присвоены сетевым картам сервера.

В конце созданные правила необходимо сохранить командой

[root@app /]# /sbin/iptables-save > /etc/sysconfig/iptables

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

На этом настройку брандмауэра можно считать оконченной.

ПРИМЕР 7.

Исходные данные: ОС Linux RedHat 7.3 без графической оболочки. Назначение – маршрутизатор. Программное обеспечение – пакет OpenSSH-3.6.1p2.

Задача: выполнить безопасную настройку сервиса SSH с учетом уязвимостей в версии SSH 1.0.

Реализация.

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

Protocol 2

Эта строка указывает демону sshd использовать только протокол версии 2.0. В противном случае, если клиент запросит разрешение на открытие сеанса с использованием протокола 1.0, запрос будет отвергнут.

OpenSSH версии 3.6 и некоторых более ранних версий имеет специальный параметр UsePrivilegeSeparation, который позволяет запускать процесс sshd от имени аутентифицированного пользователя. После того, как пользователь успешно прошел аутентификацию, основной процесс sshd, запущенный от имени привилегированного пользователя, передает управление дополнительному процессу sshd, который выполняется уже от имени аутентифицированного пользователя. Такая технология позволяет добиться более высокого уровня безопасности по сравнению с предыдущими версиями пакета OpenSSH, в которых доступ пользователей контролировался процессом, запущенным с правами пользователя root. Конфигурация демона по умолчанию уже использует этот параметр, однако в некоторых более ранних версиях этот параметр выключен. Для активации разделения пользовательских привилегий в файл sshd_config необходимо добавить строку

UsePrivilegeSeparation yes

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

Чтобы ограничить доступ привилегированному пользователю, можно использовать параметр PermitRootLogin. Установка этого параметра в значение

PermitRootLogin no

не позволит пользователю root получить доступ к удаленному терминалу. Получение привилегий пользователя root в таком случае можно будет осуществить только запуском команды su.

Для настройки ограничения доступа существуют также параметры AllowGroups, DenyGroups и AllowUsers, DenyUsers для разрешения и запрета на доступ определенным группам и пользователям соответственно. Например, для запрета доступа всем группам пользователей кроме пользователей группы wheel, конфигурационный файл должен содержать такие строки

DenyGroups *

AllowGroups wheel

Для усиления уровня безопасности можно поменять еще два параметра. Значения этих параметров по умолчанию являются приемлемыми для большинства систем и их изменение в данном случае большой роли не играет. Параметр MaxStartups позволяет задать максимальное количество одновременно запущенных процессов демона sshd, другими словами, этот параметр определяет максимальное количество одновременно подключенных пользователей. По умолчанию ограничение на количество пользователей равно 10. Если в систему должен иметь доступ только администратор и еще пара человек обслуживающего персонала, этот параметр можно выставить в значение 5. Параметр LoginGraceTime определяет период времени, в течение которого, начиная с момента установления соединения, должна быть осуществлена аутентификация пользователя. По умолчанию это значение равно 2 минутам. Если в течение этого времени пользователь не пройдет аутентификацию, серверная сторона просто закроет соединение. Если администрирование производится из локальной сети, для аутентификации может быть достаточно 30 секунд, если же существует хотя бы вероятность, что доступ будет осуществляться через низкоскоростное соединение, например, посредством телефонного соединения, имеет смысл выставить это значение в 60 секунд минимум.

Далее приводится часть конфигурационного файла, сформированная с учетом всего вышеуказанного

…

Protocol 2

UsePrivilegeSeparation yes

PermitRootLogin no

MaxStartups 5

LoginGraceTime 30

…

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

108

Характеристики

Список файлов реферата