Убедитесь в том, что вы можете получать пакеты, которые вы отправляете как на 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, чтобы выяснить адрес.