Вход на хостинг
IT-новости
20.04.2016 iPhone 2017 года поместят в водонепроницаемый корпус из стекла
Линейка iPhone в новом году серьезно поменяется. В этом уверен аналитический исследователь Мин Чи Ку......
30.07.2015 Ищем уникальный контент для сайта
Ищем уникальный контент для сайта Без уникального контента Ваш сайт обречен на то, что его страницы......
# ipfw add 2000 allow tcp from any to ${external} 22,25,80 setup
# ipfw add 2100 allow tcp from any to any established
Первое правило разрешает устанавливать соединения из любой точки сети на внешний интерфейс нашего хоста ${external} по портам 22, 25 и 80. Ключевое слово setup в конце строки говорит о том, что правило относится только к пакетам, инициирующим соединение (то есть тем, которые имеют установленный флаг SYN и сброшенные ACK и RST). Второе правило относится к другим пакетам: тем, которые передаются в рамках уже установленного соединения. Такие пакеты разрешаются все. Логика правила очень простая: «Если соединение уже каким-то образом удалось установить, то значит все нормально, данные могут проходить. Если же соединение не установлено, а пакет просто делает вид, что относится к какому-то соединенеию, ну что ж, это его проблемы, он все равно никому не нужен.» Правило рассуждает так, но здесь оно немного ошибается. В определенных случаях подобный пакет, если его умело составить, может нанести вред компьютерам за брандмауэром. Для того чтобы справиться с такими пакетами, нужно использовать фильтр с поддержкой состояний (stateful), но об этом в другой раз.
Если соединение хотим установить мы, то препятствий быть не должно:
# ipfw add 3000 allow tcp from ${external} to any setup
Обратите внимание на то, что мы разрешаем соединение только с одного IP-адреса. Если же нас интересует несколько IP-адресов, то мы должны указать их либо в виде адреса сети, либо создать несколько правил – по одному для каждого из адресов.
Следующее правило относится к UDP-трафику. Этот трафик справедливо заслужил репутацию не самого безопасного: из-за отсутствия внутренних механизмов контроля соединения отследить его действительный источник практически невозможно, что делает подмену адресов легким делом. Проблема осложняется тем, что этот трафик используют такие потенциально небезопасные службы, как, например, NFS. Внутри сети UDP ведет себя хорошо: неперегруженный лишними механизмами обеспечения надежной доставки и контроля соединения, он легок и экономичен, и в сети это, определенно, является благом, но за ее пределами все обстоит совершенно иначе. В результате правило работы с UDP звучит так: если от UDP нельзя избавиться совсем, его должно быть как можно меньше.
# ipfw add 4000 allow udp from ${external} to any 53
# ipfw add 4100 allow udp from any 53 to ${external}
Правила разрешают прохождение UDP-трафика в том случае, если он отправлен на внешний DNS-сервер или, наоборот, DNS-сервер направил его нам. Эти правила не являются идеальными, хотя и решают подавляющее большинство проблем с UDP. Но ничто не мешает злоумышленнику представиться DNS-сервером и отправлять UDP-пакеты с 53 порта. Здесь, также как и раньше, полную уверенность может дать только фильтрация с поддержкой состояний.
Последнее, что мы хотим разрешить, – это ICMP. Но мы почему-то хотим, чтобы наш компьютер нельзя было пропинговать извне, однако при этом, как свойственно человеческой природе, сами пинговать других собираемся:
# ipfw add 5000 deny icmp from any to ${external} in icmptypes 8
# ipfw add 5100 allow icmp from ${external} to any out icmtypes 8
# ipfw add 5200 allow icmp from any to ${external} in icmptypes 0
Правило 5000 запрещает входящие (in), а правило 5100 разрешает исходящие (out) ICMP эхо-запросы (ECHO REQUEST, 8). Правило 5200 разрешает эхо-ответы (ECHO REPLY, 0), приходящие на наш хост.
Последним правилом, которое подводит черту под настройкой фильтрации пакетов, является запрет всего, что не разрешено:
# ipfw add 64000 deny ip from any to any