Безвозмездная поддержка: правила WatchGuard

Вы можете купить off-the-shelf файерволы. Отличный выбор - один из WatchGuard FireBox. Отличный потому, что он мне нравится, он безопасен, основан на Linux, и потому что они финансируют сопровождение ipchains, также как и нового файерволльного кода (в 2.3). Короче говоря, WatchGuard оплачивает за меня еду, в то время как я работаю для вас. Так что пожалуйста посмотрите, что они предлагают.

http://www.watchguard.com

Будущие расширения

В ядрах 2.3 firewalling и NAT разрабатываются повторно. Планы и обсуждения можно найти в архиве netdev и списке рассылки ipchains-dev. Эти расширения должны прояснить много проблем применения (firewalling и маскарадинг не должны быть такими жесткими) и позволить создать гораздо более гибкий firewalling.

Цели

Машина пакетной фильтрации:

PING любой сети

Полезно для определения, действует ли машина.

TRACEROUTE любой сети

Аналогично, полезно для диагностики.

DNS доступ

Чтобы ping и DNS были полезнее.

Внутри DMZ:

Почтовый сервер

SMTP ко внешним соединениям

Прием SMTP от внутренних и внешних соединений

Прием Pop-3 от внутренних соединений

Сервер имен

Отправка DNS во внешнюю сеть

Прием DNS от внутренней и внешней сети и машины пакетной фильтрации

Web сервер

Прием HTTP от внутренней и внешней сетей

Rsync доступ из внутренней сети

Внутренняя сеть:

Разрешенные WWW, ftp, traceroute, ssh доступы во внешнюю сеть.

Это достаточно стандартные вещи, чтобы разрешить их использование: здесь мы ограничиваемся только этими сервисами, а не всеми доступными сервисами Интернет.

Разрешить SMTP на почтовом сервере

То есть позволить отправку почты наружу.

Разрешить POP-3 на почтовом сервере

То есть позволить пользователям читать их почту

Разрешить DNS на серевере имен

Это нужно для работы с внешними именами WWW, ftp, traceroute и ssh.

Разрешить rsync на веб сервер

Для синхронизации внешнего веб сервера со внутренним.

Разрешить WWW на веб сервере

Очевидно, что пользователи должны иметь доступ к своему внешнему веб серверу.

Разрешить ping на машине пакетной фильтрации

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

Частная сеть: маскарадинг

В этом сценарии, пакеты из частной сети никогда не выходят в Internet без специальной обработки, и наоборот. Адреса IP частной сети должны быть назначены по RFC1597 Private Network Allocations (то есть, 10.*.*.*, 172.16.*.* или 192.168.*.*).

Вместо использования прокси, мы используем специальное средство ядра, называемое "маскарадинг". Маскарадинг перезаписывает пакеты, когда они проходят через firewall, так, чтобы казалось, что они всегда исходят от firewall непосредственно. Затем он перезаписывает ответы так, чтобы было похоже, что они пришли от первоначального получателя.

Маскарадинг имеет отдельные модули для обработки "сложных" протоколов, типа FTP, RealAudio, Quake и т.д. Для действительно тяжелых в обработке протоколов применяется "автофорвардинг", который может обработать некоторые из них автоматической установкой форвардинга портов для соответствующих номеров портов: см. `` ipportfw" (ядра 2.0) или ``ipmasqadm" (ядра 2.1).

Любые услуги Интернет, которые вам нужны, должны быть на firewall.

(Однако см. ``Ограниченные внутренние услуги" ниже).

Пример: Разрешить доступ из частной сети к web-сервису Интернет.

Частной сети назначены адреса 192.168.1.*, myhost имеет адрес 192.168.1.100, а ethernet интерфейс firewall'а 192.168.1.1.

Firewall установлен на подмену любых пакетов, исходящих из частной сети и идущих на порт 80 хоста в Интернет.

Netscape сконфигурирован для непосредственного соединения.

DNS в частной сети должен быть правильно сконфигурирован.

Firewall должен быть маршрутом заданным по умолчанию (aka гейтом) для частной сети.

Netscape на myhost обращается к http://slashdot.org.

Netscape запрашивает страницу web "http://slashdot.org" и получает 207.218.152.131. Он открывает соединение с этим IP адресом, используя локальный порт 1050 и запрашивает на web-сервере (порт 80) страницу web.

Поскольку пакеты от myhost (порт 1050) к slashdot.org (порт 80) проходят через firewall, они перезаписываются так, чтобы выходить с интерфейса PPP firewall порт 65000. Firewall имеет допустимый Internet адрес (1.2.3.4), так что ответные пакеты от slashdot.org нормально приходят на firewall.

По прибытию пакеты от slashdot.org (порт 80) на firewall.littlecorp.com (порт 65000) перезаписываются так, чтобы идти на myhost порт 1050. В этом и состоит фокус маскарадинга: он помнит, когда он перезаписал исходящие пакеты, и может переписывать их обратно, когда приходят ответы на них.

Netscape отображает страницу.

то есть с точки зрения slashdot.org соединение было сделано между 1.2.3.4 (интерфейс PPP firewall'а) порт 65000 и 207.218.152.131 (slashdot.org) порт 80. С точки зрения myhost соединение было сделано между 192.168.1.100 (myhost) порт 1050 и 207.218.152.131 (slashdot.org) порт 80.

Частная сеть: прозрачные прокси

В этом сценарии, пакеты из частной сети никогда не выходят в Internet, и наоборот. Адреса IP частной сети должны быть назначены по RFC1597 Private Network Allocations (то есть, 10.*.*.*, 172.16.*.* или 192.168.*.*).

Единственный способ подсоединиться к Internet - через firewall, который является единственной машиной в обеих сетях, которая перераспределяет соединения. Вы запускаете программу (на firewall), называемую прозрачный proxy, которая все это делает; ядро пересылает пакеты прокси вместо того, чтобы отправить их наружу (то есть, это похоже на маршрутизацию).

Прозрачный прокси означает, что клиенты не должны знать, что в сети работает прокси.

Любые услуги Интернет, которые вам потребовались, должны быть на firewall.

(Однако см. ``Ограниченные внутренние услуги" ниже).

Пример: Разрешить доступ из частной сети к web-сервису Интернет.

Частной сети назначены адреса 192.168.1.*, myhost имеет адрес 192.168.1.100, а ethernet интерфейс firewall'а 192.168.1.1.

Прозрачный прокси (я полагаю, что это патчи к squid, или "transproxy") установлен и настроен на firewall, скажем, на порту 8080.

Ядру сообщают, что надо переназначать соединения с портом 80 на прокси, используя ipchains.

Netscape в частной сети настроен на прямое подключение.

В частной сети должен быть настроен DNS (то есть вы должны запустить DNS сервер как прокси на firewall).

В частной сети должен быть настроен маршрут по умолчанию (aka гейт), чтобы пакеты посылались на firewall.

Netscape на myhost обращается к http://slashdot.org.

Поскольку пакеты из myhost (порт 1050) к slashdot.org (порт 80) проходят через firewall, они переназначаются ждущему прозрачному прокси на порту 8080. Прозрачный прокси открывает соединение (используя локальный порт 1025) с 207.218.152.131 порт 80 (которому предназначались первоначальные пакеты).

Как только прокси получит страницу web из соединения с сервером web, он копирует данные на соединение с Netscape.

Netscape отображает страницу.

То есть с точки зрения slashdot.org, соединение установлено между 1.2.3.4 (интерфейс PPP firewall'а) порт 1025 и 207.218.152.131 (slashdot.org) порт 80. С точки зрения myhost соединение установлено между 192.168.1.100 (myhost) порт 1050 и 207.218.152.131 (slashdot.org) порт 80, но фактически обмен информацией совершает прозрачный прокси.

Частная сеть: традиционные прокси

Единственный способ подсоединиться к Internet - через firewall, который является единственной машиной в обеих сетях, которая перераспределяет соединения. Вы запускаете программу (на firewall), называемую proxy, которая все это делает (имеются прокси для FTP, web, telnet, RealAudio, Usenet и других услуг). См. Firewall HOWTO.

Любые услуги Интернет, которые вам потребовались, должны быть на firewall.

(Однако см. ``Ограниченные внутренние услуги" ниже).

Пример: Разрешить доступ из частной сети к web-сервису Интернет.

Частной сети назначены адреса 192.168.1.*, myhost имеет адрес 192.168.1.100, а ethernet интерфейс firewall'а 192.168.1.1.

Web proxy (напр. "Squid") установлен и сконфигурирован на firewall, скажем, на порту 8080.

Netscape в частной сети сконфигурирован для использования firewall порта 8080 в качестве прокси.

DNS в частной сети не нужно настраивать.

DNS должен быть настроен на firewall.

В частной сети маршрут по умолчанию (он же - гейт) не нужно настраивать.

Netscape на myhost обращается к http://slashdot.org.

Netscape соединяется с firewall портом 8080, используя порт 1050 на myhost. Он запрашивает страницу web "http://slashdot.org".

Proxy переводит имя "slashdot.org" в IP адрес, и получает 207.218.152.131. Затем он открывает соединение с этим адресом IP (используя порт 1025 на внешнем интерфейсе firewall'а), и запрашивает у web-сервера (порт 80) страницу web.

Как только он получит страницу web через соединение с сервером web, он скопирует данные в соединение с Netscape.

Netscape отображает страницу.

То есть, с точки зрения slashdot.org, было создано соединение между адресом 1.2.3.4 (интерфейсом PPP firewall'а) порт 1025 и адресом 207.218.152.131 (slashdot.org) порт 80. С точки зрения myhost, соединение создано с 192.168.1.100 (myhost) порт 1050 и 192.168.1.1 (ethernet интерфейс firewall'а) порт 8080.

Что?

Linux ipchains заменяет Linux IPV4 firewalling код (который был главным образом перенесен из BSD) и заменяет ipfwadm, который был потомком ipfw из BSD. Он нужен для администрирования фильтрацией IP пакетов в ядрах Linux версии 2.1.102 и выше.

Весь трафик в сети производится в виде пакетов. Например, при скачивании этого пакета (примерно 50КБ) вы, возможно, приняли 36 или около этого пакетов длиной 1460 байт каждый.

Начало каждого пакета сообщает, куда он направляется, откуда он исходит, тип пакета и другие административные подробности. Это начало пакета называется заголовком. Остальная часть пакета, содержащая фактически передаваемые данные, обычно называется телом.

Некоторые протоколы, такие как TCP, которые используются для web, электронной почты и удаленных регистраций в системах, используют понятие "соединения" - перед посылкой любых пакетов с данными производится обмен различными настроечными пакетами (со специальными заголовками), говорящими "Я хочу соединиться", "Хорошо, соединяйся" и "Спасибо". Затем идут обычные пакеты.

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

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

Что не нужно отфильтровывать

Прежде, чем вы начинете фильтровать наружний трафик, вам надо знать несколько вещей.

Фильтрация фрагментированных бомб

Говорят, в некоторых "менее надежных" TCP стеках имеются проблемы, возникающие при большом количестве фрагментов пакетов, когда на машину приходят не все фрагменты. В Linux нет этой проблемы. Вы можете отфильтровывать фрагменты (что может отразиться и на нормальных пакетах) или скомпилировать ваше ядро с опцией "IP: always defragment "Y"" (только в том случае, если ваша машина Linux - единственный маршрут для этих пакетов).

Фильтрация пакетов непосредственно для Linux машины

Если мы хотим использовать фильтрацию пакета на пакетах, приходящих непосредственно к linux машине, то мы должны настроить фильтрацию в цепочке input. Мы создаем одну цепочку для каждого интерфейса адресата:

ipchains -N bad-if ipchains -N dmz-if ipchains -N good-if

Создаем переходы на них:

ipchains -A input -d 192.84.219.1 -j bad-if ipchains -A input -d 192.84.219.250 -j dmz-if ipchains -A input -d 192.168.1.250 -j good-if

Фильтрация Пинга Смерти (DeathPing)

Linux-машины теперь невосприимчивы к известному Пингу Смерти, который заключается в посылке чересчур большого ICMP пакета, который переполняет буфера TCP-стека на машине-приемнике и приводит к хаосу.

Если вы защищаете машины, которые могли бы быть уязвимы для "пинга смерти", то вы могжете просто фрагментировать блоки ICMP. Нормальный ICMP пакеты не настолько велики, чтобы требовать фрагментации, так что фрагментироваться будут только очень большие пакеты - такие как "пинги смерти". Я слышал (по непроверенным данным), что некоторые системы могут пострадать и от последних фрагментов больших пакетов ICMP, поэтому рекомендуется фрагментировать не только первый фрагмент.

Хотя все известные программы, использующие эту атаку, генерируют ICMP-пакеты, для той же цели можно использовать TCP или UDP-пакеты (или неизвестный протокол), так что эта защита может служить лишь как временная мера.

Фильтрация побочных эффектов

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

Если пакет соответствует правилу, происходят следующие вещи:

Счетчик байтов для того правила увеличивается на размер пакета (заголовок и все остальное).

Счетчик пакетов для того правила увеличивается.

Если правило предусматривает это, то пакет рагистрируется в журнале.

Если правило предусматривает это, изменяется поле Type Of Service.

Если правило предусматривает это, пакет помечается (не для ядер 2.0)

Анализируется, какое действие над пакетом указывается в правиле, чтобы решить дальнейшую судьбу пакета.

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

Фильтрация проходящих пакетов

При маскарадинге самое лучшее -- фильтр в цепочке forward.

Разбейте цепочку forward на несколько пользовательских цепочек в зависимости от интерфейсов источника/приемника; проблема разделяется на более простые в управлении части.

ipchains -N good-dmz ipchains -N bad-dmz ipchains -N good-bad ipchains -N dmz-good ipchains -N dmz-bad ipchains -N bad-good

ACCEPT'ие стандартных ICMP сообщений об ошибках -- достаточно общая вещь, поэтому создадим для нее цепочку.

ipchains -N icmp-acc

Фильтрация Teardrop и Bonk

Teardrop и Bonk - две атаки (главным образом против машин Windows NT Microsoft), которые полагаются на накладывающиеся фрагменты. Решается это дефрагментацией пакетов на маршрутизаторе, либо запретом приема фрагментированных пакетов на уязвимых машинах.

Где?

Официальная страница -

Для сообщений об ошибках, обсуждения, разработки и использования существует список почтовой рассылки. Подписаться на него можно послав сообщение, содержащее слово ``subscribe" в ipchains-request на rustcorp.com. Чтобы отправить письмо в список рассылки укажите " ipchains' вместо "ipchains-requetst".

Хак Michael Hasenstein'а для ftp-data

Michael Hasenstein из SuSE написал патч для ядра, который добавляет в ipchains трекинг ftp-соединений. Сейчас его можно найти на

ICMP пакеты

ICMP пакеты используются (помимо прочего) для индикации состояний других протоколов (типа TCP и UDP). Пакеты "destination-unreachable" в частности. Блокирование этих пакетов означает, что вы никогда не получите сообщений об ошибках "Host unreachable' или "No route to host'; любые соединения будут только ожидать ответ, который никогда не придет. Это раздражает, но несмертельно.

Более коварная проблема - использование ICMP пакетов в проверках MTU. Все хорошие TCP реализации (включая Linux) используют проверки MTU, чтобы выяснить максимальный размер нефрагментированного пакета, который может принять адресат (фрагментация, снижает эффективность, особенно, когда при потере некоторых фрагментов). Проверка MTU осуществляется посылкой пакетов с установленным битом "Don't Fragment". Если в ответ на эти пакеты приходит ICMP-ответ "Fragmentation needed but DF set" -- то есть "необходима фрагментация, но установлен флаг DF". Это пакеты типа "destination unreachable', и если они не получены, локальный хост не будет уменьшать MTU, и эффективность будет крайне низкой или нулевой.

Также обратите внимание на ICMP сообщения перенаправления (тип 5); они могут использоваться для управления маршрутизацией (хотя хорошие IP стеки защищены), и считаются немного опасными.

Интерфейс Bad (внешняя сеть).

Машина пакетной фильтрации:

PING любой сети

TRACEROUTE любой сети

Доступ к DNS

Внешний интерфейс также получает ответы на маскараденные пакеты и ICMP сообщения об ошибках на них и ping ответы.

ipchains -A bad-if -i ! ppp0 -j DENY -l ipchains -A bad-if -p TCP --dport 61000:65096 -j ACCEPT ipchains -A bad-if -p UDP --dport 61000:65096 -j ACCEPT ipchains -A bad-if -p ICMP --icmp-type pong -j ACCEPT ipchains -A bad-if -j icmp-acc ipchains -A bad-if -j DENY

Интерфейс DMZ.

Ограничения машины пакетной фильтрации:

PING любой сети

TRACEROUTE любой сети

Доступ к DNS

DMZ интерфейс получает ответы DNS, ответы ping и ICMP сообщения об ошибках.

ipchains -A dmz-if -i ! eth0 -j DENY ipchains -A dmz-if -p TCP ! -y -s 192.84.219.129 53 -j ACCEPT ipchains -A dmz-if -p UDP -s 192.84.219.129 53 -j ACCEPT ipchains -A dmz-if -p ICMP --icmp-type pong -j ACCEPT ipchains -A dmz-if -j icmp-acc ipchains -A dmz-if -j DENY -l

Интерфейс Good (внутренний).

Ограничения машины пакетной фильтрации:

PING любой сети

TRACEROUTE любой сети

Доступ к DNS

DMZ интерфейс получает ответы DNS, ответы ping и ICMP сообщения об ошибках.

Ограничения внутренней сети:

Разрешить WWW, ftp, traceroute, ssh ко внешней сети

Позволить SMTP к почтовому серверу

Позволить POP-3 к почтовому серверу

Позволить DNS к серверу имен

Позволить rsync к веб серверу

Позволить WWW к веб серверу

Позволить ping к машине пакетной фильтрации

Внутренний интерфейс получает ответы DNS, ответы ping и ICMP сообщения об ошибках.

ipchains -A good-if -i ! eth1 -j DENY ipchains -A good-if -p ICMP --icmp-type ping -j ACCEPT ipchains -A good-if -p ICMP --icmp-type pong -j ACCEPT ipchains -A good-if -j icmp-acc ipchains -A good-if -j DENY -l

IP Firewalling цепочки

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

Ipautofw and ipportfw не работают!

Для 2.0.x это так; у меня нет времени на создание и поддержку гигантского патча для ipchains и ipautofw/ipportfw.

Для 2.1.x скачайте ipmasqadm Juan Ciarlante'а с

и используйте его точно так же, как вы использовали бы ipautofw или ipportfw, за исключением того, что вместо ipportfw вы печатаете ipmasqadm portfw, а вместо ipautofw печатаете ipmasqadm autofw.

Ipchains

Ipchains вставляет и удаляет правила из раздела пакетной фильтрации ядра. Это означает, что все, что вы устанавливаете будет потеряно после перезагрузки; как этого избежать написано в ``Создание постоянных правил" .

Ipchains заменяет ipfwadm, который использовался в старом коде IP Firewall. Есть набор полезных скриптов, доступных на ftp-сайте ipchains:

ftp://ftp.rustcorp.com/ipchains/ipchains-scripts-1.1.2.tar.gz

Это скрипт shell, называемый ipfwadm-wrapper, который позволяет вам сделать такую же пакетную фильтрацию, как это было выполнено прежде. Вам не стоит использовать этот скрипт, если вы не хотите быстро перейти на новую систему со старого ipfwadm (это медленнее, отсутствует настройка параметров и т.д).

В этом случае, вам также не нужен этот HOWTO.

Подробности о проблемах ipfwadm см. в приложениях ``Различия между ipchains и ipfwadm" и ``Использование скрипта ipfwadm-wrapper'.

Ipchains -L замирает!

Вы вероятно блокируете DNS; это будет приводить к таймаутам.

Пробуйте использовать опцию "-n" (numeric) для ipchains, который подавляет преобразование имен.

Использование ipchains

Сначала убедитесь, что ваша версия ipchains соответствует той версии, о которой рассказывается в этом документе:

$ ipchains --version ipchains 1.3.9, 17-Mar-1999

Обратите внимание, что я рекомендую 1.3.4 (у которого нет никаких длинных опций, типа `--sport'), или 1.3.8 или выше; они очень устойчивы.

Ipchains имеет довольно подробный man (man ipchains), а если вам нужны подробности, вы можете проверить программный интерфейс (man 4 ipfw), или файл net/ipv4/ip_fw.c в исходных текстах ядра 2.1.x, который является (очевидно) авторитарным.

Имеется также превосходный краткий справочник Скотта Бронсона в пакете с исходными текстами в форматах A4 и US Letter Postscript(TM).

С ipchains можно делать множество вещей. Во-первых, управлять целыми цепочками. Изначально у вас есть три встроенных цепочки: input, forward и output, которые вы не можете удалять.

Создать новую цепочку (-N).

Удалить пустую цепочку (-X).

Изменить стратегию для встроенной цепочки (-P).

Выдать список правил цепочки (-L).

Удалить правила из цепочки (-F).

Обнулить счетчики пакетов и байтов во всех правилах цепочки (-Z).

Имеется несколько способов управлять правилами внутри цепочки:

Добавить новое правило к цепочке (-A)

Вставить новое правило в определенную позицию цепочки (-I)

Заменить правило в определенной позиции цепочки (-R)

Удалить правило в определенной позиции цепочки (-D)

Удалить первое правило в цепочке, удовлетворяющее условию (-D)

Есть несколько операций для маскарадинга, которые находятся в ipchains из-за отсутствия более подходящего места для их размещения:

Вывести текущие параметры маскарадинга (-M -L)

Установить значения таймаутов для маскарадинга (-M -S)

(Но см. ``Я не могу установить таймауты маскарадинга!").

Последняя (и, возможно, наиболее полезная) функция позволяет вам проверить, что случилось бы с данным пакетом, если бы он должен был пересечь данную цепочку.

Использование ipchains-restore

ipchains-restore восстанавливает цепочки, сохраненные ipchains-save. У скрипта две опции: "-v", которая описывает каждое добавленное правило, и "-f" которая, вынуждает очистить пользовательские цепочки, если они существуют, как описано ниже.

Если пользовательская цепочка найдена в input, ipchains-restore проверяет, не существует ли уже цепочка. Если да, то вас спросят, нужно ли цепочки очистить (от всех правил) или не восстанавливать эту цепочку. Если вы определили "-f" в командной строке, то запроса не будет; цепочка будет очищена.

Например:

# ipchains-restore < my_firewall Restoring `input'. Restoring `output'. Restoring `forward'. Restoring `ppp-in'. Chain `ppp-in' already exists. Skip or flush? [S/f]? s Skipping `ppp-in'. Restoring `ppp-out'. Chain `ppp-out' already exists. Skip or flush? [S/f]? f Flushing `ppp-out'. #

Использование ipchains-save

После настройки firewall цепочек вам надо где-то сохранить их, чтобы эта настройка не потерялась при перезагрузке машины.

Итак, ipchains-save - скрипт, который читает вашу текущую настройку цепочек и сохраняет ее в файле. Я немного расскажу, что делает этот скрипт.

ipchains-save может сохранять одну или все цепочки (если имя цепочки не определено). В настоящее время единственая опция скрипта - "-v", которая печатает правила (на stderr) в том виде, как они записаны. поскольку они сохранены. Также сохраняется политика цепочек input, output и forward

# ipchains-save > my_firewall Saving `input'. Saving `output'. Saving `forward'. Saving `ppp-in'. Saving `ppp-out'. #

Изменение Firewall правил

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

# ipchains -I input 1 -j DENY # ipchains -I output 1 -j DENY # ipchains -I forward 1 -j DENY ... вносим изменения ... # ipchains -D input 1 # ipchains -D output 1 # ipchains -D forward 1 #

На время внесения изменений пакеты будут отбрасываться.

Если ваши изменения касаются только одной цепочки, то можно создать новую цепочку с новыми правилами, и затем заменить ("-R") правило, которое указывает на старую цепочку, на то, которое указывает на новую цепочку; затем вы можете удалить старую цепочку. Эта замена произойдет атомарно.

-J REDIR не работает!

Вы должны разрешить форвардинг пакетов (см. выше) для того, чтобы переназначение работало; иначе код маршрутизации отбрасывает пакет. Так, если вы используете только перенаправление, и вообще не используете форвардинг, то вы должны знать об этом.

Обратите внимание, что REDIR (находящийся во цепочке input) не вохдействует на соединения из локального процесса.

Я хочу файерволлить IPX!

Этим, как мне кажется, занимаются другие. К сожалению, мой код относится только к IP. On the good side, all the hooks are there to firewall IPX! Вам только надо написать код; я счастлив буду помочь там, где возможно.

Я не могу установить таймауты маскарадинга!

Это было так (для ядер 2.1.x) до 2.1.123. В 2.1.124 попытка установить таймаут для маскарадинга вызывает зависание ядра (изменить return на ret = в строке 1328 net/ipv4/ip_fw.c). В 2.1.125 все прекрасно работает.

Я запутался! Маршрутизация, маскарадинг, форвардинг портов, ipautofw ...

Этот HOWTO рассказывает о фильтрации пакетов. Это значит, что принимается решение, нужно ли пакету позволить пройти или нет. Однако, так как Linux является детской песочницей для хакера, то вы вероятно захотите сделать больше, чем только это.

Одна проблема состоит в том, что один и тот же инструмент (``ipchains ") используется для управления и маскарадингом, и прозрачным прокси, хотя они и не имеют к пакетной фильтрации совершенно никакого отношения (текущая реализация Linux создает впечатление, что они близко связаны).

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

Ядро с фильтрацией пакетов

Вам нужно ядро, в которое встроен новый код IP firewall chains (цепочки). Вы можете проверить, если этот код в ядре, поискав файл "/proc/net/ip_fwchains'. Если он существует, то все в порядке.

Если нет, то вы должны сделать ядро, в котором есть IP firewall цепочки. Сначала, скачайте исходники ядра. Если у вас есть ядро 2.1.102 или выше, то вам не надо будет это патчить (сейчас этот код встроен в ядро основной ветки). Иначе, вам придется найти в web патч, указанный выше, и установить конфигурацию как разъяснено ниже. Если вы не знаете, как это сделать, не паникуйте - прочтите Kernel-HOWTO.

Опции настроек, которые вы должны будете установить для ядер 2.0:

CONFIG_EXPERIMENTAL=y CONFIG_FIREWALL=y CONFIG_IP_FIREWALL=y CONFIG_IP_FIREWALL_CHAINS=y

Для ядер 2.1 или 2.2 :

CONFIG_FIREWALL=y CONFIG_IP_FIREWALL=y

ipchains общается с ядром и сообщает ему какие пакеты фильтровать. Если вы не программист, или очень любопытный человек, это как вы будете управлять пакетной фильтрацией.

Как?

В настоящее время код находится в ядрах от 2.1.102. Для ядер 2.0, вам нужно будет загрузить ядерный патч из сети. Если ваше ядро 2.0 более новое, чем предлагаемый патч, то патч должен подойти; эта часть ядер 2.0 довольно устойчива (напр. патч для ядра 2.0.34 работает только лучше на ядрах 2.0.35). Так как патч 2.0 несовместим с патчами ipportfw и ipautofw, я не рекомендую применять его, если вам действительно не нужны некоторые функциональных возможности, предлагаемые ipchains.

Как фильтры отсеивают пакеты

Ядро стартует с тремя списками правил; эти списки называются firewall-цепочками или просто цепочками. Три цепочки называются input, output и forward. Когда приходит пакет (скажем, через плату ethernet) ядро использует цепочку input, чтобы решить судьбу пакета. Если пакет фильтр пропустит пакет, то ядро решает, куда послать пакет дальше (это называется маршрутизацией). Если пакет предназначен для другой машины, ядро консультируется с цепочкой forward. И наконец, прежде, чем пакет выйдет через сетевой интерфейс, ядро консультируется с цепочкой output.

Цепочка - контрольный список правил. Каждое правило говорит "если заголовок пакета походит на это, то с пакетом поступить так-то'. Если правило не применимо к пакету, то рассматривается следующе правило в цепочке. Наконец, если никакие правил не подошли, то ядро обращается к стратегии цепочек, чтобы решить, что делать. В системе с повышенными требованиями к безопасности, эта стратегия обычно заставляет ядро отклонить или отвергнуть пакет.

Для любителей ASCII-картинок, нарисован полный путь пакета, входящего в машину.

---------------------------------------------------------------- | ACCEPT/ интерфейс lo | v REDIRECT _______ | --> C --> S --> ______ --> D -> ~~~~~~~~~~ ->|forward|----> _______ -->

h a |input | e {Решение о } |цепоч- | |output |ACCEPT e n |цепоч-| m {маршр-ции } |__ка___| --->|цепоч- | c i |__ка__| a ~~~~~~~~~~~ | | ->|__ка___| k t | s | | | | | s y | q | v | | | u | v e v DENY/ | | v m | DENY/ r Местный процесс REJECT | | DENY/ | v REJECT a | | | REJECT | DENY d --------------------- | v e ----------------------------- DENY

Вот методическое описание каждой стадии:

Контрольная сумма(Checksum):

Проверка целостности пакета. Если контрольная сумма не совпадает, то пакет отбрасывается(DENY).

Здравомыслие(Sanity):

На самом деле проверка на правильность формата пакета проводится перед каждой цепочкой, но цепочка input наиболее важна. Некоторые пакеты неправильного формата могли бы запутать код, обеспечивающий проверку правила, вот такие пакеты здесь и отбрасываются (DENY) (если такое случилось, то в syslog помещается сообщение).

Цепочка input:

Это - первая firewall цепочка, проверяющая пакет. Если цепочки на приняла решение об отбрасывании(DENY) или отклонении(REJECT) пакета, пакет идет дальше.

Демаскарадинг(Demasquerade):

Если пакет является ответом на замаскараденный пакет, он демаскарадируется, и перебрасывается прямо на цепочку output. Если вы не используете IP маскарадинг, то можете мысленно стереть это место в диаграмме.

Решение о маршрутизации:

Поле адреса назначения исследуется кодом маршрутизации, чтобы решить, не направлен ли этот пакет локальному процессу (см. "Локальный процесс" ниже) или послан удаленной машине (см. "цепочку forward" ниже).

Локальный процесс:

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

Интерфейс lo:

Если пакеты из локального процесса предназначены локальному процессу, они пройдут цепочку output с интерфейсом, установленным в "lo", и возвратятся через входную цепочку с интерфейсом тоже "lo". Интерфейс lo обычно называется петлевым интерфейсом (loopback).

Локальный(local):

Если пакет не был создан локальным процессом, то цепочка forward проверяет его, иначе пакет идет на цепочку output.

Цепочка forward:

Эту цепочку проходят любые пакеты, которые пытаются уйти на другую машину.

Цепочка output:

Эта цепочка проверяет все пакеты прежде, чем выпустить их наружу.

Как организовать ваши Firewall правила

Этот вопрос требует некоторых размышлений. Вы можете попробовать организовать их, чтобы оптимизировать быстродействие (минимизировать число правил-проверок для большинства пакетов) или увеличить управляемость.

Если у вас непостоянная связь, скажем связь PPP, то вы могли бы захотеть установить первое правило в цепочке input "-i ppp0 -j DENY' во время загрузки системы, тогда помещаем нечто такое в ваш скрипт ip-up:

# Создать цепочку `ppp-in' заново. ipchains-restore -f < ppp-in.firewall # Заместить правило DENY на цепочку ppp-обработки. ipchains -R input 1 -i ppp0 -j ppp-in

А в скрипт ip-down:

ipchains -R input 1 -i ppp0 -j DENY

Как установить защиту от IP спуфинга?

IP спуфинг - отправка пакетов с поддельным IP адресом источника. Так как фильтрация пакета принимает решения на основани адреса источника, то IP спуфинг используется, чтобы ввести пакетный фильтр в заблуждение.

Также он используется при комплексных атаках, с использованием SYN, Teardrop, "пинга смерти" и т.п.(если не знаете что это такое - не волнуйтесь), чтобы атакуемый хост не знал, что все это валится с одного адреса .

Самый лучший способ защититься от IP spoofing называется Source Address Verification (проверка адреса источника). Эта проверка выполняется программами маршрутизации, в не программами фильтрации. Поищите файл /proc/sys/net/ipv4/conf/all/rp_filter.

Если он существует, то можно включать Source Address Verification при загрузке. Чтобы cделать это, вставьте следующие строки в скрипты инициализации перед инициализацией сетевых интерфейсов:

# Наилучший способ: включить Source Address Verification и защитить # от спуфинга все текущие и будущие интерфейсы. if [ -e /proc/sys/net/ipv4/conf/all/rp_filter ]; then echo -n "Установка защиты от спуфинга... " for f in /proc/sys/net/ipv4/conf/*/rp_filter; do echo 1 > $f done echo "готово." else echo ПРОБЛЕМЫ ПРИ ПОПЫТКЕ ВКЛЮЧИТЬ ЗАЩИТУ ОТ СПУФИНГА. echo "Нажмите CONTROL-D для выхода в shell и продолжения системной загрузки." echo # Запуск однопользовательского shell на консоли /sbin/sulogin $CONSOLE fi

Если вы не можете сделать это, то вы можете вручную вставлять правила для защитыь каждого интерфейса. Это требует знаний о каждом интерфейсе. Ядра 2.1 автоматически отклоняют пакеты, приходящие с адресов 127.* (зарезервированных для локального петлевого интерфейса, lo).

Например, скажем, мы имеем три интерфейса: eth0, eth1 и ppp0. Мы можем использовать ifconfig, чтобы узнать адреса и сетевые маски интерфейсов.

Допустим, что eth0 присоединен к сети 192.168.1.0 с сетевой маской 255.255.255.0, eth1 присоединен к сети 10.0.0.0 с сетевой маской 255.0.0.0, а ppp0 соединен с Internet (где разрешены любые адреса за исключением зарезервированных частных адресов IP), мы вставили бы следующие правила:

# ipchains -A input -i eth0 -s ! 192.168.1.0/255.255.255.0 -j DENY # ipchains -A input -i ! eth0 -s 192.168.1.0/255.255.255.0 -j DENY # ipchains -A input -i eth1 -s ! 10.0.0.0/255.0.0.0 -j DENY # ipchains -A input -i ! eth1 -s 10.0.0.0/255.0.0.0 -j DENY #

Такой подход не столь хорош как Source Address Verification, потому что если ваши сетевые настройки изменились, вы должны изменить и правила фильтра.

Для ядер 2.0 вам желательно защитить и петлевой интерфейс:

# ipchains -A input -i ! lo -s 127.0.0.0/255.0.0.0 -j DENY #

Кошмары FTP

Классическая проблема при пакетной фильтрации - FTP. FTP имеет два режима; традиционный вызывается активным режимом и более современный называется пассивным режимом. Web-браузеры обычно по умолчанию работают в пассивном режиме, но консольные программы FTP обычно по умолчанию работают в активном режиме.

В активном режиме, когда удаленная сторона хочет послать файл (или даже результаты команд ls или dir), она пробует открыть TCP соединение с локальной машиной. Это означает, что вы не можете отфильтровывать эти TCP соединения без прерывания активного FTP.

Если у вас есть опция использования пассивного режима, то все прекрасно; пассивный режим создает соединения от клиента к серверу, даже для входящих данных. Вам рекомендуется разрешить только TCP соединения с номерами портов более 1024 и не 6000..6010 (используются для XWINDOWS).

Краткая таблица перекрестных ссылок.

[В основном, аргументы команд в ВЕРХНЕМ РЕГИСТРЕ, а параметры опций - в нижнем]

Обратите внимание на такую вещь: маскарадинг определяется "-j MASQ'; это полностью отличается " -j ACCEPT', и не обрабатыватся как просто побочный эффект, как это делает ipfwadm.

================================================================ | ipfwadm | ipchains | Notes ---------------------------------------------------------------- | -A [both] | -N acct | Создает `acct' цепочку | |& -I 1 input -j acct | для входящих с исходящих | |& -I 1 output -j acct | пакетов. | |& acct | ---------------------------------------------------------------- | -A in | input | Правило без действия ---------------------------------------------------------------- | -A out | output | Правило без действия ---------------------------------------------------------------- | -F | forward | Использ. это как [цепочка]. ---------------------------------------------------------------- | -I | input | Использ. это как [цепочка]. ---------------------------------------------------------------- | -O | output | Использ. это как [цепочка]. ---------------------------------------------------------------- | -M -l | -M -L | ---------------------------------------------------------------- | -M -s | -M -S | ---------------------------------------------------------------- | -a policy | -A [chain] -j POLICY | (но см. -r и -m). ---------------------------------------------------------------- | -d policy | -D [chain] -j POLICY | (но см. -r и -m). ---------------------------------------------------------------- | -i policy | -I 1 [chain] -j POLICY| (но см. -r и -m). ---------------------------------------------------------------- | -l | -L | ---------------------------------------------------------------- | -z | -Z | ---------------------------------------------------------------- | -f | -F | ---------------------------------------------------------------- | -p | -P | ---------------------------------------------------------------- | -c | -C | ---------------------------------------------------------------- | -P | -p | ---------------------------------------------------------------- | -S | -s | Можно указывать только | | | один порт, не несколько. ---------------------------------------------------------------- | -D | -d | Можно указывать только | | | один порт, не несколько. ---------------------------------------------------------------- | -V | <нету> | Использ. -i [имя]. ---------------------------------------------------------------- | -W | -i | ---------------------------------------------------------------- | -b | -b | Факт-ки создает 2 правила. ---------------------------------------------------------------- | -e | -v | ---------------------------------------------------------------- | -k | ! -y | Не работает, если нет | | | опции -p tcp. ---------------------------------------------------------------- | -m | -j MASQ | ---------------------------------------------------------------- | -n | -n | ---------------------------------------------------------------- | -o | -l | ---------------------------------------------------------------- | -r [redirpt] | -j REDIRECT [redirpt] | ---------------------------------------------------------------- | -t | -t | ---------------------------------------------------------------- | -v | -v | ---------------------------------------------------------------- | -x | -x | ---------------------------------------------------------------- | -y | -y | Не работает, если нет | | | опции -p tcp. ----------------------------------------------------------------

Маркировка пакета

Это позволяет осуществлять сложные и мощные взаимодействия с новой реализацией Качества Сервиса (Quality of Service) Алексея Кузнецова, для основанного на метках форвардинга в ядрах серии 2.1. Более пока ничего не известно. В ядрах 2.0 эта опция игнорируется.

Маскарадинг/форвардинг не работают!

Удостоверьтесь, что форвардинг пакетов разрешен (в последних версиях ядра, он не блокируется по умолчанию, что означает, что пакеты не приходят в цепочку "forward"). Вы можете отменить этот (от root), введя команду

# echo 1 > /proc/sys/net/ipv4/ip_forward #

Если это у вас сработает, то вы можете поместть эту строку куда-нибудь в ваши загрузочные сценарии, чтобы она выполнялась при загрузке; firewalling должен устанавливаться прежде, чем выполнится эта команда.

Несколько правил одновременно и наблюдение за происходящим

Иногда одна командная строка может воздействовать на несколько правил сразу. Это происходит по двум причинам. Во-первых, если вы определяете имя хоста, которое преобразуется (используя DNS) в несколько IP адресов, ipchains будет действовать так, как будто вы ввели несколько команд для каждой комбинации адресов.

Так, если имя хоста "www.foo.com" указывает на три IP адреса, а имя хоста "www.bar.com" - на два IP адреса, то команда "ipchains -A input -j REJECT -s www.bar.com -d www.foo.com' добавила бы 6 правил ко цепочке input.

Другая причина, заставляющая ipchains выполнить несколько действий, состоит в использовании флажка ("-b" -- bidirectional). Этот флажок заставляет ipchains вести себя так, словно вы ввели команду дважды, поменяв во второй команде местами значения параметров "-s' и "-d'. Так, чтобы запретить обмен с хостом 192.168.1.1, вы могли бы напечатать следующее:

# ipchains -b -A forward -j REJECT -s 192.168.1.1 #

Лично мне опция "-b" не слишком нравится; если вам хочется удобства, см. ``Использование ipchains-save" ниже.

Опция "-b" может использоваться с командами вставки ("-I"), удаления ("-D") (но без использования номера правила), добавления ("-A") и проверки ("-C").

Другой полезный флажок "-v" (verbose), который выводит информацию о том, что ipchains делает с вашими командами. Это полезно, если вы имеете дело с командами, которые могут производить множественные правила. Например, здесь мы проверяем поведение фрагментов между 192.168.1.1 и 192.168.1.2.

# ipchains -v -b -C input -p tcp -f -s 192.168.1.1 -d 192.168.1.2 -i lo tcp opt ---f- tos 0xFF 0x00 via lo 192.168.1.1 -> 192.168.1.2 * -> * packet accepted tcp opt ---f- tos 0xFF 0x00 via lo 192.168.1.2 -> 192.168.1.1 * -> * packet accepted #

Обработка фрагментов

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

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

Если ваша машина - единственое соединение со внешней сетью, то вы можете сообщить Linux ядру, что надо собирать все фрагменты, которые проходят через него, компилируя ядро с установкой IP: always defragment "Y". Это аккуратное решение проблемы.

В любом случае, важно понять, как фрагменты обрабатываются правилами фильтрации. Любое правило фильтрации, которое запрашивает информацию, не будет срабатывать, если не будет соответствия. Это означает, что первый фрагмент обработается подобно любому другому пакету. Второй и далее фрагментя не будут обрабатываться. Таким образом правило "-p TCP -s 192.168.1.1 www' (указание исходного порта "www") никогда не будет соответствовать фрагменту (не первому фрагменту). Обратное правило "-p TCP -s 192.168.1.1 ! www' тоже не сработает.

Однако, вы можете определить правило специально для второго и далее фрагментов, используя флажок "-f". Ясно-понятно, что его нельзя применять при указании TCP или UDP порта, типа ICMP, кода ICMP или TCP SYN, так как эта информация во вторых и последующих фрагментах отсутствует.

Можно также указать, что правило не применяется ко второму и последующим фрагментам, указав '!' перед '-f'.

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

Обратите внимание: пакеты некорректного формата (TCP, UDP и ICMP пакеты, слишком короткие для обработки firewalling кодом, настолько короткие, что из них нельзя получить информацию о портах или коде и типе ICMP) тоже обрабатываются как фрагменты. Только TCP фрагменты, начинающиеся с позиции 8 явно отбрасываются firewall кодом (в syslog отправляется соответствующее сообщение).

Например, следующее правило отбросит любые фрагменты, приходящие на 192.168.1.1:

# ipchains -A output -f -d 192.168.1.1 -j DENY #

Обработка одним правилом

Это - "бутерброд" ipchains; правила управления. Наиболее часто вы вероятно используете команды добавления (-A) и удаления (-D). Другие (-I для вставки и -R для замены) - простые расширения этих концепций.

Каждое правило определяет набор условий отбора (например по полю "адрес назначения") и обработки пакетов. Например, вы можете захотеть отвергать все ICMP пакеты, исходящие с IP адреса 127.0.0.1. В этом случае наши условия заключаются в том, что протокол должен быть ICMP и исходный адрес 127.0.0.1. Наше действие - "DENY"(отбросить).

127.0.0.1 - это "петлевой" интерфейс, который у вас будет существовать, даже если у вас отсутствует реальное сетевое соединение. Вы можете использовать программу "ping", чтобы сгенерировать такие пакеты (она просто посылает тип ICMP 8 (запрос ECHO), на которые все кооперативные хосты должны из вежливости ответить пакетами с типом ICMP 0 (ответ ECHO)). Это полезно для тестирования.

# ping -c 1 127.0.0.1 PING 127.0.0.1 (127.0.0.1): 56 data bytes 64 bytes from 127.0.0.1: icmp_seq=0 ttl=64 time=0.2 ms

--- 127.0.0.1 ping statistics --- 1 packets transmitted, 1 packets received, 0% packet loss round-trip min/avg/max = 0.2/0.2/0.2 ms # ipchains -A input -s 127.0.0.1 -p icmp -j DENY # ping -c 1 127.0.0.1 PING 127.0.0.1 (127.0.0.1): 56 data bytes

--- 127.0.0.1 ping statistics --- 1 packets transmitted, 0 packets received, 100% packet loss #

Вы видите, что первый ping проходит нормально (опция "-c 1' означает, что надо послать один пакет).

Затем мы прибавляем (-A) к цепочке "input" правило, определяющее, что пакеты от 127.0.0.1 ("-s 127.0.0.1') протокола ICMP ("-p ICMP') мы должны отбросить(DENY) ("-j DENY').

Затем мы проверяем наше правило, вторично запустив ping. Программа попытается дождаться ответа, который так и не придет.

Мы можем удалить правило одним из двух способов. Во-первых, так как мы знаем, что это - единственое правило во входной цепочке, то мы можем использовать удаление по номеру. Удаляем правило 1 в цепочке:

# ipchains -D input 1 #

Второй способ состоит в применении зеркальную команде -A команду -D. Это полезно, когда у вас сложная цепочка правил, и вы не хотите выяснять номер правила. В этом случае, мы действовали бы так:

# ipchains -D input -s 127.0.0.1 -p icmp -j DENY #

Синтаксис -D должен иметь такие же опции, что и -A (или -I или -R). Если в той же самой цепочке имеются несколько идентичных правил, то будет удалено только первое из них.

Обработка всей цепочки

Очень полезная возможность ipchains - способность группировать связанные правила в цепочки. Вы можете нызывать цепочки как вам хочется при условии, что имена не совпадают с именами встроенных цепочек (input, output и forward) или действий (MASQ, REDIRECT, ACCEPT, DENY, REJECT или RETURN).

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

Общедоступная сеть

В этом сценарии, ваша персональная сеть - часть Internet: пакеты могут течь без изменения из одной сети в другую. Адреса IP внутренней сети должны быть назначены из выделенного блока адресов IP, так что остальная часть сети будет знать, как получить пакеты, адресованные вам. Подразумевается постоянное соединение.

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

Пример: Разрешить доступ из частной сети к web-сервису Интернет.

В вашей внутренней сети адреса назначены согласно выделенному блоку IP адресов (скажем 1.2.3.*).

Установки firewall позволяют весь трафик.

Netscape настроен для непосредственного соединения.

В вашей сети должен быть правильно настроен DNS.

Firewall должен быть маршрутом заданным по умолчанию (aka гейтом) для частной сети.

Netscape на myhost обращается к http://slashdot.org.

Пакеты проходят через ваш firewall также, как они проходят через несколько маршрутизаторов между вами и slashdot.org.

Netscape отображает страницу.

то есть имеется только одно соединение: между 1.2.3.100 (myhost) порт 1050 и 207.218.152.131 (slashdot.org) порт 80.

Общие Firewall-ные установки

У вас есть домен littlecorp.com. У вас есть внутренняя сеть, и одно подключение к Internet по коммутируемому каналу (PPP) (firewall.littlecorp.com с адресом 1.2.3.4). Ваша локальная сеть построена на ethernet, а ваша персональная машина называется "myhost".

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