Данный документ не является всеобъемлющим руководством по настройке ACL на свитчах фирмы D-Link, на это есть мануал, я всего лишь хотел показать на примерах некоторые моменты, которые могут пригодится в работе и быть может помогут сэкономить кому - нибудь его время. Я постараюсь объяснить, как строить правила на основе packet_content_mask и почему подобные правила в некоторых случаях предпочтительнее обычных правил.

Прежде чем начать давайте примем за аксиому следующее утверждение - „Каждый передаваемый свичом пакет состоит из N-го количества байт, свитч эти байты „видит“, соответственно пакеты, содержащие эти байты можно отфильтровать.“ и основываясь на этом начнем

Пример №1

Задача: РС1 обращается на ТСР порт 445 РС2. Необходимо заблокировать подобную активность.

Решение:
Вот так пакет выглядит в Ethereal:Построение профиля для правил на основе packet_content_mask, упрощенно, а так же для более удобного сопоставления с имеющимися данными можно представить вот в таком виде (обратите внимание насколько глубоко свитч может залазить в проходящие сквозь него пакеты):Исходя из этого приведем данные к более „юзабельному“ варианту:
Т.к внутри свитча пакеты всегда тегированы, вне зависимости от того назначали вы тег или нет, то заполним символами „х“ данные с 12 по 15 байт (в свитче эти байты заполняются информацией о VLAN и т.д., кому интересно – почитайте RFC ). Обратите внимание - у Вас в этих байтах могут быть данные, которые Вы захотите использовать для написания ACL, в этом примере я эти данные не рассматриваю и сделал это заполнение больше для наглядности, для того чтобы смотреть на пакет так же как его „видит“ свитч:Как видите информация относительно исходного варианта сместилась. Теперь сократим запись оставив только то, что нам нужно:Набросаем примерный скелет будущего правила:Мы точно знаем где, применительно к ACL, находятся нужные нам данные и можно переходить к написанию собственно ACL.Вот и все, ТСР destination port 445 заблокирован. Можно поступить несколько иначе, а именно:Т.е. не указывать протокол (offset_16-31 0x0 0x0 0x000000ff), в таком варианте будут заблокированы все пакеты с destination port 445 вне зависимости от протокола, т.е. под данное правило попадут и ТСР и UDP пакеты.

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

Пример №2

Задача: РС1 обращается на ТСР порт 445 РС2 через нешифрованное РРТР соединение. Необходимо заблокировать подобную активность.

Решение:
Вот так пакет выглядит в Ethereal:Если сравните этот пример и пример №1, то Вы увидите что пакет увеличился за счет транспортной составляющей (GRE, РРР заголовки и т.д.). Но ни нам ни свитчам от D-Link это как Вы понимаете не помеха Опять приведем это к более „юзабельному“ варианту:Заполним символами „х“ данные с 12 по 15 байт, дабы увидеть пакет глазами свитча:Сократим запись оставив только нужную информацию:Набросаем примерный скелет будущего правила:Вот собственно и все, можно переходить к написанию ACL.
Аналогично примеру №1 можно заблокировать порт вне зависимости от протокола, т.е. Вот так:Вот рабочий пример рабочего решения, блокируются те же порты что и в примере №1:
„А зачем все это надо?“, спросите Вы, и я Вам отвечу что я работаю в ISP, доступ в интернет у нас осуществляется с использованием РРТР, а т.к. мы активно используем радиооборудование, то я решил уберечь его, а так же другие „тонкие“ (xDSL, и т.п.) линки от прохождения по ним ненужного трафика. К такому трафику я отношу все не поддерживаемые данным ISP сервисы, но поддерживаемые фирмой Microsoft и внедренные в ОС Microsoft Windows(tm) для организации и работы Windows Network. При этом я хотел уберечь линки не только от обычных ethernet пакетов, которые я уже показал как можно фильтровать в примере №1, а так же сделать так чтобы данный трафик не проходил и в GRE туннелях, т.к. бесполезно кому либо говорить „Отключите пожалуйста в свойствах VPN соединения все протоколы и службы кроме TCP/IP“ да и я считаю что подобные увещевания не более чем сизифов труд. В общем я решил что действовать нужно административными мерами и рассчитывать только на себя и на имеющуюся в наличии продукцию фирмы D-Link Вы можете резонно возразить: „Почему данное решение было осуществлено на свитчах, а не на специально предназначенных для этого firewall-ах?“, на что я Вам отвечу, что: „Firewall-ы от D-Link при всех наличествующих в них плюсах не умеют фильтровать проходящие через них GRE пакеты“ и не надо спрашивать у саппорта так это или нет, не отвлекайте их от работы, они лишь подтвердят Вам мои слова

Тут какой нибудь пытливый ум дочитавший до этого момента может вполне резонно задать вопрос: „Пардон, а как же бродкасты?!?“, на что я могу показать вот такой пример запрещения бродкастов в GRE:
Кстати раз уж речь зашла о бродкастах, то хочу предоставить Вашему вниманию...

Пример №3

Задача: Необходимо заблокировать бродкасты на клиентских портах (для спасения Ваших радиолинков или еще из каких либо административных или иных побуждений).

Решение:
Решить подобную задачу можно вот таким образом:Тут как Вы можете видеть разрешаются ARP бродкасты (это необходимо сделать для функционирования данного протокола!) и запрещаются IP бродкасты. Кое кто может сказать: „Я использую DHCP для раздачи адресов и когда я воспользовался этим правилом все перестало работать!“, на что я только могу показать вот такой пример:Т.е. необходимо разрешить на клиентских портах прохождение пакетов DHCP запросов (src port 68 UDP) и запретить прохождение DHCP ответов (src port 67 UDP) до блокирования бродкастов. Это очень важное замечание, т.к. порядок следования правил определяет очередность их действия и соответственно надо сначала разрешить нужный Вам broadcast трафик, а потом уже его запрещать. Profile_id 1 данного примера аналогичен примеру из FAQ. Если же Вам хочется фильтровать не по src, а по dst порту, то вспомнив, что DHCP пакеты ходят по схеме:то достаточно изменить access_profile 1 следующим образом:Где так же разрешается прохождение DHCP запросов (dst port 67 UDP) и запрещается прохождение DHCP ответов (dst port 68 UDP). Сюда же Вы можете вписать блокировку ненужных Вам как TCP так и UDP dst портов.А вот так может выглядеть profile_id 2, на основе packet_content_mask, а не ethernet заголовках:
Между прочим лично мне до сих пор не понятно, почему на форумах до сих пор у многих авторов есть устойчивая точка зрения что запретить бродкасты можно лишь разбив подсеть на 2 домена коллизий роутером или L3 свитчем, если такие люди попробуют предложенный мной метод, то поймут, что достаточно иметь в арсенале DES-3526 и слово „бродкаст“ они больше не вспомнят Конечно надо принимать во внимание размеры сети, но спор на предмет „при каком размере сети надо ставить L3 свитч/роутер“ не относятся к данной теме.

Как я обещал в самом начале попытаюсь объяснить почему правила на основе packet_content_mask в некоторых ситуациях действительно лучше чем обычные правила, для этого возьмем вот такой пример блокировки трафика генерируемого Microsoft Windows(tm):А вот так этот пример будет выглядеть при использовании правил на основе packet_content_mask:
Как Вы можете видеть использование правил на основе packet_content_mask позволяет уменьшить количество занимаемых правилами профилей без потери функционала акцесс листа.

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

Позволю себе дать несколько советов/рекомендаций

Думаю, что при написании ACL Вам могут пригодится/понадобится следующие документы:
http://www.iana.org/assignments/ethernet-numbers
http://www.iana.org/assignments/protocol-numbers
http://www.iana.org/assignments/port-numbers
http://www.iana.org/assignments/icmp-parameters
http://support.microsoft.com/kb/832017

Для тестирования Ваших ACL, на мой взгляд, Вам могут очень пригодится, помимо ставших уже каноническими tcpdump, Ethereal, и nmap такие программы как HoneyBOT под Windows и honeyd под *NIX.

Disclaimer aka Отмазка

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

Приведенные Выше примеры будут работать на всех свитчах от D-Link имеющих формат правил ACL аналогичный DES-3526, т.е. упоминая DES-3526, я в принципе имел ввиду все подобные свитчи

Каждое решение я старался приводить пошагово, для упрощения понимания функционирования.


З.Ы. Пожалуйста учтите, что свитчу совершенно все равно на то что проходит через него, куда оно идет и как Вы пишете ваши профили и правила. Забота о правильном написании ACL (а „правильно“ - это только в соответствии с мануалом) лежит целиком и полностью на Вас, поэтому не удивляйтесь что удалить неправильно написанный ACL можно только перегрузив свитч или, если вы дали команду save, сбросив его на заводские установки.

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

Хочу сказать огромное, человеческое спасибо В.Карагезову, В. Колосову, А.Шебаронину, И.Демину и другим сотрудникам представительства D-Link - за их помощь, понимание и участие и отдельное спасибо А.Щадневу - за то что он меня терпит

Ну что ж, тема поднята чрезвычайно актуальная, за что вам большое спасибо.
Замечание по второй части примера 1 (и аналогично далее): не проверять значение поля ip_protocol в общем случае опасно, ибо там может быть ни tcp (0x06), ни udp (0x11) - мы запросто можем отфильтровать очень даже полезные пакеты. Но это так, мелкая придирка.

А вот "замечание на засыпку":
В рассматриваемых вами примерах предполагается, что полная длина ip-заголовков всех пакетов одинакова и составляет 20 байт. Однако, в общем случае ip заголовок может содержать еще дополнительные поля опций, в результате чего полная его длина может быть и 24, и 28, и т.д. байт. Причем информация о полном размере ip-заголовка (в четырехбайтных словах) содержится в младших четырех битах первого байта ip-заголовка. (Во всех ваших примерах значение первого байта ip-заголовка равно 0x45, младшие 4 бита этого байта - 0x5, -> длина ip-заголовка 0x5*4=20 байт)
Для сравнения, в моей сетке существенная часть ip-пакетов имеет в первом байте ip-заголовка значение 0x46, и соответственно, размер ip-заголовков 24 байта, и опять-таки соответственно, все заголовки протоколов более высоких уровней (tcp, udp, igmp,...) имеют уже совсем другое смещение -> ваши правила для них не сработают.

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

незачто... я надеюсь кому то это поможет...если кому-то будет надо, то может воспользоваться вот таким примером блокировки 135-го ТСР порта IP протокола:просто я изначально проектировал свою сеть на пропускание _только_ IP протокола... кому нужны иные протоколы (IPX и т.д.) - могут получить отдельный VLAN;)спасибо за замечание, но... но я старался написать то как это работает и как собственно строить подобные механизмы регулировки трафика, согласитесь, я не в силах рассмотреть все возможные варианты и соответственно не смогу написать правила под каждую ситуацию... я лишь старался показать на примерах как можно что либо делать, а вот как именно это делать - тут уж все зависит от конкретной задачи... тот кому надо будет писать правила надеюсь будет думать не о том какой я негодяй раз у него это не работает, а о том как у него построена сеть и соответственно не принимать мои примеры как 100% идеальные, ведь это всего лишь примеры, а не руководство к действию воистину умная мысль!

Так и я вообще-то про IP говорю. Когда я писал про необходимость анализа поля ip_protocol, я имел в виду десятый байт заголовка ip-пакетов. Именно там лежит информация о том, что ВЛОЖЕНО ВНУТРЬ IP: UDP, TCP, ICMP, GRE,... Ибо, например,
1. Если вы думаете, что фильтруете 445 порт назначения, подразумевая, что проходящие пакеты являются tcp или udp, а на самом деле проходят пакеты GRE, у которых "по счастливой случайности" по указанному offset лежит именно значение 445? то кто виноват?...
Или вот еще такой (совершенно противоположный) случАй:
2. В вашей сети появился злоумышленник, желающий поиметь админовский доступ к ПК ваших же клиентов (через RPC-уязвимости "форточек" (tm) NT/w2k/XP). Перваая его попытка поразить ПК-мишени оказывается безуспешной - "зуб" ломается на вашем 445-dstport-фильтре. Однако, наш герой - парень не промах: "а что если вставить в ip-пакеты поле опций?"- спрашивает он сам себя, и о чудо, уже через несколько секунд все "виндуса" падают жертвой, а он, наш герой, становится хозяином положения. И опять же повторюсь: кто виноват в этом случае?

А IPX, NetBEUI, AppleTalk или даже ARP - это совсем другая (хотя тоже небезынтересная) песня.

Напрасно. Вариантов (в конкретном случае протокола IPv4) не так уж и много. Возможно описать их все. (Кстати, помониторьте трафик в своей сети повнимательнее. Уверяю вас, у вас тоже есть пакеты с "недвадцатибайтными" ip-заголовками)

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

А Вы бы примерчик выложили да разъяснили народу где и как можно проколотся... На примере Я то могу выложить, но всетаки хотелось бы чтобы это не выглядело как признание своих ошибок с моей стороны (я ведь могу и ошибаться и даже подло вводить в заблуждение), а скорее как дополнение другого человека, имеющего что сказать по сабжевому вопросу;)Надо будет как нибудь хоть начать запевать, а там глядишь и до припева дойдем или даже концовку услышим Спасибо, Вам добрый человек, но сдается мне что это интересно только нам с Вами...

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

Материал, любезно подготовленный Павлом, уже опубликован в нашем FAQ http://www.dlink.ru/technical/faq_hub_switch_90.php

Еще раз спасибо за нужную и хорошую работу!!!

_________________
С уважением, Карагезов Владислав

Пожалуйста, я старался быть как можно более понятным... Правда конечно еще надо бы выложить варианты с поправками ув. Vladimir Gerasimov, но мне бы очень хотелось чтобы это сделал именно он, почему именно так - я уже объяснил Я вообще планирую переодически выкладывать свои наработки, вдруг кому нибудь да пригодится... В ближайшее время я хочу написать success story о том, как я таки подружил DWL-2100/3200 c 802.1Q VLAN... А то на этом (и не только на этом) форуме об этом много спрашивают, а доки в общем то нет Это Вам спасибо, за ... да за все!

спасибо!
часто не хватает именно нескольких примеров чтобы разобраться, особенно когда все самому приходится изучать
было бы очень интересно узнать подробности о 2100 точках - их закупали как раз из за поддержки VLAN, правда вланы еще не внедрили, почему не сталкивались с проблемами. а фильтрация+сегментация спасла - когда мы начали расти и сеть начала погибать в них для меня было проще разобраться чем осознать концепцию VLAN )

всегда рад помочь вообще нечто подобное примерам уменя уже успешно используется в аккурат для спасения мостов на 2100-х точках от всякого Г... правда у меня подход примерно как "рзарешено только то что надо, остальное запрещено", зато даже на 2100-х (я не говорю о 3Сом и прочем используемом железе) сеть работает и стабильней и быстрее, что подтверждают даже не тесты, а пользователи сегодня-завтра выложу... просто надо собраться с мыслями чтоб нормально написать... блин, соберусь, напишу, а всеравно получится какая нить ерунда

Ну раз вы настаиваете, приведу "слегка" подредактированные варианты примеров, фигурирующих в исходном сообщении

Модифицированный вариант примера 1 (с учетом некоторых "подводных камней"):
условия:
а) фильтруем пакеты, входящие в первый порт коммутатора
б) протокол 3-го уровня - IP (ethernet_type=0x0800),
в) версия протокола - IPv4, длина IP-заголовка - 20 или 24 байт (ip_version/ip_hl=0x45 или ip_version/ip_hl=0x46. В принципе, конечно надо анализировать весь диапазон от 0x46 до 0x4f, но возможности ACL в плане гибкости пока еще оставляют желать лучшего, хотя положительная тенденция налицо),
г) протокол 4-го уровня - TCP или UDP (ip_protocol=0x06 или ip_protocol=0x11),
д) TCP/UDP-порт назначения - 445 (0x01bd), TCP 135 (0x0087), UDP 137 (0x0089),... (нужно больше? - добавьте по вкусу)
е) если передаваемое IP-сообщение является фрагментированным (т.е. грубо говоря, пакет полностью не умещается в рамки MTU), то информация о tcp/udp-портах источника и получателя содержится ТОЛЬКО В самом ПЕРВОМ пакете сообщения. Т.е. в общем случае следует проверять, не является ли пакет фрагментом (фрагменты - это тоже отдельная песня)
Итак,


Модифицированный вариант рабочего примера 2:
Здесь от себя добавлю контроль того, что:
а) ETHERNET_TYPE=IP (0x0800);
б) IPv4 header_length=20 (0x45);
в) инкапсулированный внутрь GRE/PPTP IP-пакет не является фрагментом;
г) во всех случаях "offset_32-47" надо заменить на "offset_64-79",
а также "offset_48-63 0x0 0x0 0x000000ff 0x0" на "offset_48-63 0x0 0x0 0x0 0x000000ff" и
"offset_48-63 0x0 0x0 0x00000006 0x0" на "offset_48-63 0x0 0x0 0x0 0x00000006" и далее все смещения "съехали"... (полагаю, что в оригинальном примере просто досадные очепятки)



Модифицированный вариант примера 3:
Фильтруем широковещательный IP_other_ETHERNET-трафик (исключая DHCP-запросы)
замечания по DHCP/BOOTP:
а) UDP-порты для DHCP-запросов и откликов указаны с точностью до наоборот. Правильно так:

б) DHCP-отклики не являются широковещательными
Ну и, кроме того, правило, явно разрешающее прохождение ARP-пакетов (ETHER_TYPE=0x0806), является лишним (здесь работает принцип "разрешено все, что явно не запрещено").



ЗЫ. Прошу сходу не принимать на веру все вышесказанное - возможны ошибки/очепятки. Как говорится, "Доверяй, да проверяй!"

Не то чтобы настаиваю, мне действительно было приятно увидеть Вашу точку зрения, вот в таком виде... Вы же понимаете, что это кому то да пригодится Просто когда я постил, я это в общем то все проверил на столе, в одной подсети, а как Вы сами знаете IP загловки в одной сети имеют длину - 20 байт, а при шлюзовании в другую сеть - 40 байт то у меня и получилось то что получилось... В любом случае СПАСИБО Вам за поправки!Хох блин! Только что глянул что я написал... точно! Перепутал В голове было одно, а написал другое... Банально слова "запрос" и "ответ" перепутал Спасибо, сейчас поправлю... Всеравно надо верить ни нам с вами ибо erare humanum est, а в обязательном порядке RFC или хотя бы ISC DHCP Version 3 README в части "Firewall rules"А я этого и не говорил... Я просто переписал пример из FAQ в несколько иной форме... Хотя мне хотелось бы Вас поправить, а именно отослать Вас к RFC 2131 где сказано:Так что как видите ответы сервера таки могут быть бродкастовыми...Ну а если в конце применять что то в духеЧто я обычно и делаю ибо мне ничего кроме IP в сети не нужно?.. Я вообще сейчас больше использую правила вида "разрешено только то что надо, остальное - запрещено" и в общем то все довольны...Присоединяюсь! Так что наш пытливый читатель Ахтунг! В креативе возможны очепятки!

Кстати, классная тема!
Сам бы я, пожалуй, с такими профилями бы и не разобрался.
По прочтении у меня вопросы появились.
Мне, к примеру, необходимо жестко привязать фиксированный IP-адрес к порту свича.
Типа такого
create access_profile ip source_ip_mask 255.255.255.255 profile_id 10
config access_profile profile_id 10 add access_id 1 ip source_ip 10.37.0.49 port 3 permit

Но насколько я понял из личного опыта , профили с ip имеют более низкий приоритет по сравнению с теми же ethernet. И в итоге окажутся после правила

create access_profile ethernet source_mac 00-00-00-00-00-00 profile_id 9
config access_profile profile_id 9 add access_id 1 ethernet source_mac 00-00-00-00-00-00 port 1 deny

И работать уже не будут.

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

порядок очередности определяется через profile_id #, т.е. правило с profile_id 1 по любому сработает раньше чем profile_id 9, а насчет такого понятия как "проритет выполнения правил" я честно говря впервые слышу... может конечно в даташите чипа оно как то и указано, но я его не читал...ACL на основе packet_content_mask - это всего лишь один из вариантов написания оных ACL... в чем то он лучше, в чем то хуже... какой путь выбрать - это только Вам решать

А вы сами попробуйте......
Поставьте последним по номеру

# Kill non-IP traffic
create access_profile ethernet source_mac 00-00-00-00-00-00 profile_id 200
config access_profile profile_id 200 add access_id 1 ethernet source_mac 00-00-00-00-00-00 port 1-26 deny

А перед ним - что-нибудь вроде
# Accept right IPs
create access_profile ip source_ip_mask 255.255.255.255 profile_id 90
config access_profile profile_id 90 add access_id 1 ip source_ip 10.37.0.150 port 3 permit

Все это дело будет у вас работать до перетыкания патчкорда в 3-м порту. А после - уже нет. Пока вы 90-й профиль не прибьете и тут же заново его не создадите.
Кстати, я эту тему уже поднимал....

А про эти приоритеты и правда нигде не написано....