Как видно из текста сценария, порт 53, на котором «сидит» DNS, для UDP пакетов закрыт, то есть правило, открывающее 53-й порт в сценарии присутствует, но закомментировано. Если вы пожелаете запустить DNS на брандмауэре, то это правило следует раскомментировать.
Я лично разрешаю порт 123, на котором работает NTP (network time protocol). Этой службой обычно пользуются для приема точного времени с серверов времени в Интернет. Однако, вероятнее всего, что вы не используете этот протокол, поэтому соответствующее правило в сценарии так же закомментировано.
Порт 2074 используется некоторыми мультимедийными приложениями, подобно speak freely, которые используются для передачи голоса в режиме реального времени.
И наконец – ICQ, на порту 4000. Это широко известный протокол, используемый ICQ-приложениями Я полагаю не следует объяснять вам что это такое.
Кроме того в сценарии приведены еще два правила, которые по-умолчанию закомментированы. Ими можно воспользоваться, если брандмауэр чрезмерно нагружен. Первое – блокирует широковещательные пакеты, поступающие на порты со 135 по 139. Эти порты используются протоколами SMB и NetBIOS от Microsoft. Таким образом данное правило предотвращает переполнение таблицы трассировщика в сетях Microsoft Network. Второе правило блокирует DHCP запросы извне. Это правило определенно имеет смысл если внешняя сеть содержит некоммутируемые сегменты, где IP адреса выделяются клиентам динамически.
ПРИМЕЧАНИЕ: Последние два правила не являются обязательными (в тексте сценария они закомментированы). Все пакеты, которые не были отвергнуты или приняты явно, логируются в журнал последним правилом в цепочке INPUT, поэтому, если вас беспокоит проблема «раздувания» системного журнала – можете раскомментировать эти правила.
7.2.6.5. Цепочка для ICMP
Здесь принимается решение о пропуске ICMP пакетов. Если пакет приходит с eth0 в цепочку INPUT, то далее он перенаправляется в цепочку icmp_packets. В этой цепочке проверяется тип ICMP сообщения. Пропускаются только ICMP Echo Request, TTL equals 0 during transit и TTL equals 0 during reassembly. Все остальные типы ICMP сообщений должны проходить брандмауэр беспрепятственно, поскольку будут иметь состояние RELATED.
ПРИМЕЧАНИЕ: Если ICMP пакет приходит в ответ на наш запрос, то он приобретает статус RELATED (связанный с имеющимся соединением). Более подробно состояние пакетов рассматривается в главе Механизм определения состояний
При принятии решения я исхожу из следующих соображений: ICMP Echo Request пакеты посылаются, главным образом, для проверки доступности хоста. Если удалить это правило, то наш брандмауэр не будет «откликаться» в ответ на ICMP Echo Request, что сделает использование утилиты ping и подобных ей, по отношению к брандмауэру, бесполезными.
Time Exceeded (т.е., TTL equals 0 during transit и TTL equals 0 during reassembly). Во время движения пакета по сети, на каждом маршрутизаторе поле TTL, в заголовке пакета, уменьшается на 1. Как только поле TTL станет равным нулю, то маршрутизатором будет послано сообщение Time Exceeded. Например, когда вы выполняете трассировку (traceroute) какого либо узла, то поле TTL устанавливается равным 1, на первом же маршрутизаторе оно становится равным нулю и к нам приходит сообщение Time Exceeded, далее, устанавливаем TTL = 2 и второй маршрутизатор передает нам Time Exceeded, и так далее, пока не получим ответ с самого узла.
Список типов ICMP сообщений смотрите в приложении Типы ICMP Дополнительную информацию по ICMP вы можете получить в следующих документах:
The Internet Control Message Protocol
RFC 792 – Internet Control Message Protocol – от J. Postel.
ПРИМЕЧАНИЕ: Будьте внимательны при блокировании ICMP пакетов, возможно я не прав, блокируя какие-то из них, может оказаться так, что для вас это неприемлемо.
Цепочка INPUT, как я уже писал, для выполнения основной работы использует другие цепочки, за счет чего снижая нагрузку на сетевой фильтр. Эффект применения такого варианта организации правил лучше заметен на медленных машинах, которые в другом случае начинают «терять» пакеты при высокой нагрузке. Достигается это разбиением набора правил по некоторому признаку и выделение их в отдельные цепочки. Тем самым уменьшается количество правил, которое проходит каждый пакет.
Первым же правилом мы пытаемся отбросить «плохие» пакеты. За дополнительной информацией обращайтесь к приложению Цепочка bad_tcp_packets. В некоторых особенных ситуациях такие пакеты могут считаться допустимыми, но в 99% случаев лучше их «остановить». Поэтому такие пакеты заносятся в системный журнал (логируются) и «сбрасываются».
Далее следует целая группа правил, которая пропускает весь трафик, идущий из доверительной сети, которая включает в себя сетевой адаптер, связанный с локальной сетью и локальный сетевой интерфейс (lo) и имеющий исходные адреса нашей локальной сети (включая реальный IP адрес). Эта группа правил стоит первой по той простой причине, что локальная сеть генерирует значительно бОльший трафик чем трафик из Internet. Поэтому, при построении своих наборов правил, всегда старайтесь учитывать объем трафика, указывая первыми те правила, которые будут обслуживать больший трафик.
Первым в группе, анализирующей трафик идущий с $INET_IFACE, стоит правило, пропускающее все пакеты со статусом
ESTABLISHED
или RELATED
(эти пакеты являются частью уже УСТАНОВЛЕННОГО или СВЯЗАННОГО соединения). Это правило эквивалентно правилу, стоящему в цепочке allowed. И в некоторой степени является избыточным, поскольку затем цепочка allowed вызывается опосредованно через цепочку tcp_packets, однако оно несколько разгружает сетевой фильтр, поскольку значительная доля трафика пропускается этим праилом и не проходит всю последовательность до цепочки allowed. После этого производится анализ трафика, идущего из Internet. Все пакеты, приходящие в цепочку INPUT с интерфейса $INET_IFACE распределяются по вложенным цепочкам, в зависимости от типа протокола. TCP пакеты передаются в цепочку tcp_packets, UDP пакеты отправляются в цепочку udp_packets и ICMP перенаправляются в цепочку icmp_packets. Как правило, большую часть трафика «съедают» TCP пакеты, потом UDP и меньший объем приходится на долю ICMP, однако в вашем конкретном случае это предположение может оказаться неверным. Очень важно учитывать объем трафика, проходящего через набор правил. Учет объема трафика – абсолютная необходимость. В случае неоптимального распределения правил даже машину класса Pentium III и выше, с сетевой картой 100 Мбит и большим объемом передаваемых данных по сети, довольно легко можно «поставить на колени» сравнительно небольшим объемом правил.
Далее следует весьма специфическое правило (по-умолчанию закомментировано). Дело в том, что клиенты Microsoft Network имеют «дурную привычку» выдавать огромное количество Multicast (групповых) пакетов в диапазоне адресов 224.0.0.0/8. Поэтому можно использовать данное правило для предотвращения «засорения» логов в случае, если с внешней стороны имеется какая либо сеть Microsoft Network. Подобную же проблему решают два последних правила (по-умолчанию закомментированы) в цепочке udp_packets, описанные в Цепочка для UDP.
Последним правилом, перед тем как ко всем не принятым явно пакетам в цепочке INPUT будет применена политика по-умолчанию, траффик журналируется, на случай необходимости поиска причин возникающих проблем. При этом мы устанавливаем правилу, ограничение на
