Внутреннее устройство Linux - Уорд Брайан. Страница 75

# iptables -A INPUT -s 192.168.34.37 -j ACCEPT

Однако это не срабатывает. Чтобы понять почему, взгляните на новую цепочку:

Chain INPUT (policy ACCEPT)

target prot opt source destination

DROP all — 192.168.34.63 anywhere

DROP tcp — 192.168.34.0/24 anywhere tcp dpt:smtp

ACCEPT all — 192.168.34.37 anywhere

Ядро считывает цепочки сверху вниз, применяя первое правило, которое подходит.

Первое правило не подходит для адреса 192.168.34.37, а второе подходит, так как оно применяется ко всем хостам в диапазоне адресов от 192.168.34.1 до 192.168.34.254 и говорит о том, что пакеты должны отвергаться. Когда правило подходит, ядро приступает к действиям и уже не смотрит остальные цепочки. Вы, наверное, заметили, что с адреса 192.168.34.37 можно отправлять пакеты на любой порт вашего компьютера, кроме 25, так как второе правило применяется только для него.

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

# iptables -D INPUT 3

Затем вставьте это правило в верхней части цепочки с помощью команды iptables -I:

# iptables -I INPUT -s 192.168.34.37 -j ACCEPT

Чтобы вставить правило где-либо внутри цепочки, укажите номер правила после имени цепочки (например, iptables –I INPUT 4 ...).

9.21.3. Стратегии для брандмауэров

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

Существуют два основных типа сценариев для брандмауэров: один для защиты отдельных компьютеров (здесь можно указывать правила в цепочке INPUT каждого компьютера), а второй — для защиты компьютеров в составе сети (здесь правила указываются в цепочке FORWARD маршрутизатора). В обоих случаях вы не можете достичь серьезной защиты, если вы применяете по умолчанию политику ACCEPT, а затем постоянно добавляете правила, которые отбрасывают пакеты от источников, начинающих рассылать нежелательный контент. Вы должны разрешать только те пакеты, которым доверяете, и отвергать все остальные.

Допустим, что у вашего компьютера имеется SSH-сервер, обслуживающий TCP-порт 22. Нет никаких оснований для того, чтобы какой-либо хост инициировал соединение с другими портами вашего компьютера, и вы не должны давать такой возможности никаким хостам. Чтобы это организовать, сначала установите для цепочки INPUT политику DROP:

# iptables -P INPUT DROP

Чтобы включить ICMP-трафик (для команды ping и других утилит), используйте такую строку:

# iptables -A INPUT -p icmp -j ACCEPT

Убедитесь в том, что вы можете получать пакеты, которые вы отправляете как на IP-адреса внутри собственной сети, так и на адрес 127.0.0.1 (локальный хост). При условии, что my_addr — это IP-адрес вашего хоста, выполните следующее:

# iptables -A INPUT -s 127.0.0.1 -j ACCEPT

# iptables -A INPUT -s my_addr -j ACCEPT

Если вы управляете подсетью в целом (и доверяете в ней всему), можно заменить адрес my_addr на адрес вашей подсети и ее маску, например, на 10.23.2.0/24.

Теперь, хотя вам по-прежнему требуется отклонять входящие TCP-соединения, необходимо убедиться в том, что ваш хост способен устанавливать TCP-соединения с внешним миром. Поскольку все TCP-соединения начинаются с пакета SYN (запрос соединения), то можно позволить поступление всех TCP-пакетов, которые не являются SYN-пакетами, и тогда все будет в порядке:

# iptables -A INPUT -p tcp '!' —syn -j ACCEPT

Далее, если вы используете удаленный сервер DNS с протоколом UDP, вы должны принимать трафик от вашего сервера имен, чтобы компьютер мог отыскивать имена с помощью службы DNS. Выполните это для всех серверов DNS, указанных в файле /etc/resolv.conf, используя следующую команду (здесь ns_addr означает адрес сервера имен):

# iptables -A INPUT -p udp —source-port 53 -s ns_addr -j ACCEPT

И наконец, разрешите SSH-соединения от кого угодно:

# iptables -A INPUT -p tcp —destination-port 22 -j ACCEPT

Приведенные настройки IP-таблиц подходят для многих ситуаций, включая любое прямое соединение (в особенности широкополосное), когда злоумышленник будет, скорее всего, сканировать порты вашего компьютера. Можно было бы также адаптировать эти настройки для маршрутизатора с функцией брандмауэра, использовав цепочку FORWARD вместо INPUT и указав подсети источника и назначения, где это допустимо. Для более сложных конфигураций может оказаться полезным такой инструмент, как надстройка Shorewall.

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

9.22. Сеть Ethernet, протоколы IP и ARP

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

Обычно мы не раздумываем над этим вопросом, поскольку сетевое ПО содержит автоматическую систему поиска MAC-адресов, которая называется протоколом ARP (Address Resolution Protocol, протокол разрешения адресов). Хост, который использует сеть Ethernet как физический уровень и протокол IP как сетевой уровень, содержит небольшую таблицу, называемую кэшем ARP, которая сопоставляет IP-адреса адресам MAC. В Linux кэш ARP расположен в ядре. Чтобы просмотреть кэш ARP на компьютере, используйте команду arp. Как и для многих других сетевых команд, параметр -n здесь отключает обратный поиск DNS.

$ arp -n

Address Hwtype Hwaddr Flags Mask Iface

10.1.2.141 ether 00:11:32:0d:ca:82 C eth0

10.1.2.1 ether 00:24:a5:b5:a0:11 C eth0

10.1.2.50 ether 00:0c:41:f6:1c:99 C eth0

При загрузке компьютера кэш ARP пуст. Как же тогда MAC-адреса попадают в этот кэш? Все начинается тогда, когда компьютер желает отправить пакет другому хосту. Если целевой IP-адрес отсутствует в кэше ARP, выполняются следующие действия.

1. Хост-источник создает специальный кадр Ethernet, содержащий пакет запроса у кэша ARP тех адресов, которые соответствуют целевому IP-адресу.

2. Хост-источник передает этот кадр по всей физической сети в целевой подсети.

3. Если один из других хостов этой подсети знает правильный MAC-адрес, он создает ответный пакет и кадр, содержащий данный адрес, а затем отправляет его источнику. Зачастую отвечающий хост является целевым и просто отправляет в ответ собственный MAC-адрес.

4. Хост-источник добавляет пару адресов IP-MAC в кэш ARP и готов продолжить работу.

примечание

Помните о том, что кэш ARP применяется только для компьютеров локальных подсетей (загляните в раздел 9.4, чтобы определить ваши локальные подсети). Чтобы добраться до пунктов назначения за пределами подсети, хост отправляет пакет маршрутизатору, и эта задача в итоге переходит к кому-то другому. Конечно же, ваш хост должен знать MAC-адрес маршрутизатора и может использовать кэш ARP, чтобы выяснить адрес.

Единственная настоящая проблема с кэшем ARP может возникнуть, когда он становится устаревшим, если вы присвоили IP-адрес от одной карты сетевого интерфейса другой карте (например, при тестировании компьютера), поскольку у этих карт различные MAC-адреса. Система Unix делает недействительными записи в кэше ARP, если они неактивны в течение некоторого времени, поэтому здесь возникнет лишь небольшая задержка, вызванная недействующими данными. Можно немедленно удалить запись в кэше ARP с помощью такой команды: