Jump to content
Калькуляторы

ADSL сервис и безопасность сети как защититься от вредного клиента?

Доброго времени суток!

 

Хочу посоветоваться :-) Что конкретно может сделать плохого (преднамеренно или нет) ADSL клиент и как с эти бороться.

 

Мои размышления на эту тему таковы:

1) два клиента могут соединить свои модемы езернетом, перевести модемы в бридж и сделать петлю на Л2. Когда это плохо? Учитывая что на дсламах есть изоляция портов, самому дсламу от этого плохо не будет. плохо будет свичу, если абоненты сидят на разных дсламах, а они одним вланом идут в этот свич. Если даже на свиче будет stp это не сильно поможет так как он заблокирует целый порт, то есть дслам.

Значит - нужно обязательно дсламы держать в разных вланах или использовать switchport protected (поможет ли он в этом случае?) или один влан-один пользователь или...

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

3) могут появиться абоненты с одинаковыми маками на разных портах, разных дсламах (левые модемы, игры с сетевыми картами, опять же петли между абонентами и т.д. вообщем бывает), тут вроде как дсламу ничего не повредит, учитывая изоляцию портов, однако на некоторых есть функция антиспуфинга, когда дслам сам шатдаугит порты с одинаковыми маками... зачем тогда эта фича? Вот свичу который идет за дсламом могут одинаковые маки не понравится - даже если они в разных вланах, ведь мак подразумевает уникальность и может он свою таблицу (мак/порт) строит не per-vlan и тогда могут быть проблемы, что скажете?

4) клиент может поставить себе мак pppoe сервера, тогда это не понравится свичу в котором сидит bras и дсламы. Единственное что приходит в голову ставить Л2 acl на порт свича в сторону дслама и фильтовать мак bras'а. Или?

5) еще может быть флуд от клиента на Л2 - просто очень много пакетов до браса со скоростью adsl соединения. Это актуально если подключать абонентов с максимально возможной скоростью по adsl а затем ограничивать скорость на брасе. Это бывает нужно если хочется предоставлять iptv в отдельном pvc в multicast влане. Тогда можно просто зафлудить брас. Шторм контроль на свиче не поможет, так как заблокирует целый порт, то есть брас. На дсламах я такой фишки не видел.

 

Ну вот пока все... Что скажете?

Share this post


Link to post
Share on other sites

1) самому дсламу от этого тоже станет плохо, точнее абонентам в том влане где петля, т.к. через петлю может прийти в том числе и мак адрес шлюза или pppoe сервера. в результате съедет таблица форвардинга и все перестанут работать.

4) как показала практика acl у многих вендоров работают странно. трафик дальше не пускают, но локальную таблицу мак адресов портят.

 

лучше решать проблему радикально. каждый порт в отдельный влан + ограничение на разумное количество маков с порта. только надо обеспечить чтоб до браса был свитчинг по mac+c-vlan, при упаковке в QinQ получится mac+s-vlan, что может доставить неприятности с одинаковыми маками из разных сторон в разных c-vlan.

Share this post


Link to post
Share on other sites

АДСЛ провайдер, которым я пользуюсь, пускает только оговоренные мак адреса.

Любое изменение, добавление - по бумажному заявлению в офисе от владельца телефонной линии с документом.

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

Share this post


Link to post
Share on other sites
АДСЛ провайдер, которым я пользуюсь, пускает только оговоренные мак адреса.

Любое изменение, добавление - по бумажному заявлению в офисе от владельца телефонной линии с документом.

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

в моем регионе это невозможно :-) к сожалению

 

Share this post


Link to post
Share on other sites
1) самому дсламу от этого тоже станет плохо, точнее абонентам в том влане где петля, т.к. через петлю может прийти в том числе и мак адрес шлюза или pppoe сервера. в результате съедет таблица форвардинга и все перестанут работать.

4) как показала практика acl у многих вендоров работают странно. трафик дальше не пускают, но локальную таблицу мак адресов портят.

 

лучше решать проблему радикально. каждый порт в отдельный влан + ограничение на разумное количество маков с порта. только надо обеспечить чтоб до браса был свитчинг по mac+c-vlan, при упаковке в QinQ получится mac+s-vlan, что может доставить неприятности с одинаковыми маками из разных сторон в разных c-vlan.

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

 

Вообщем, проблема безопасности по всем пунктам не надумана, давайте вместе обмозгуем :-)

Share this post


Link to post
Share on other sites
1) два клиента могут соединить свои модемы езернетом, перевести модемы в бридж и сделать петлю на Л2. Когда это плохо? Учитывая что на дсламах есть изоляция портов, самому дсламу от этого плохо не будет. плохо будет свичу, если абоненты сидят на разных дсламах, а они одним вланом идут в этот свич. Если даже на свиче будет stp это не сильно поможет так как он заблокирует целый порт, то есть дслам.

Значит - нужно обязательно дсламы держать в разных вланах или использовать switchport protected (поможет ли он в этом случае?) или один влан-один пользователь или...

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

3) могут появиться абоненты с одинаковыми маками на разных портах, разных дсламах (левые модемы, игры с сетевыми картами, опять же петли между абонентами и т.д. вообщем бывает), тут вроде как дсламу ничего не повредит, учитывая изоляцию портов, однако на некоторых есть функция антиспуфинга, когда дслам сам шатдаугит порты с одинаковыми маками... зачем тогда эта фича? Вот свичу который идет за дсламом могут одинаковые маки не понравится - даже если они в разных вланах, ведь мак подразумевает уникальность и может он свою таблицу (мак/порт) строит не per-vlan и тогда могут быть проблемы, что скажете?

4) клиент может поставить себе мак pppoe сервера, тогда это не понравится свичу в котором сидит bras и дсламы. Единственное что приходит в голову ставить Л2 acl на порт свича в сторону дслама и фильтовать мак bras'а. Или?

5) еще может быть флуд от клиента на Л2 - просто очень много пакетов до браса со скоростью adsl соединения. Это актуально если подключать абонентов с максимально возможной скоростью по adsl а затем ограничивать скорость на брасе. Это бывает нужно если хочется предоставлять iptv в отдельном pvc в multicast влане. Тогда можно просто зафлудить брас. Шторм контроль на свиче не поможет, так как заблокирует целый порт, то есть брас. На дсламах я такой фишки не видел.

1. На портах дслама фильтры по ethertype (pppoe), на портах коммутаторов, в которые включены дсламы, mac access-group in с запретом маков bras'ов, глючных сетевых и нулевых. QinQ тоже используется если железо позволяет.

2. Ограничение на количество мак-адресов с порта. Плюс у некоторых дсламов есть защита от DoS атаки с помощью PADI и DHCP запросов, слишком активный порт просто кладется минут на 20.

3. Если одинаковые маки на одном дсламе, то есть защита от spoofing'а. Порт с которого мак пришел первый продолжает работать, второй порт кладется. Если маки с разных дсламов, то уже не тривиально :( жалобы от техподдержки, просмотр syslog'ов с коммутаторов на предмет %SW_MATM-4-MACFLAP_NOTIF. Причем помниться вирус у одного клиента попортил нам нервы, он сниферил маки в том же влане и подставлял их себе, причем catalyst 3550 молчал, как рыба об лед :( catalyst 3750 сыпал же сообщения о мак флаппинге. Один из выходов - QinQ, хотя еще есть вариант - VMAC, дслам меняет клиентский мак на заранее прописанный, в зависимости от номера порта и ip дслама.

4. Опять mac access-group in с запретом маков всех брасов.

5. Просто много бродкаста? Что-то типа storm-control, но на уровне порта дслама? Надо доку посмотреть. Хотя ограничения обратного канала в adsl является естественным сдерживающим фактором. Вот когда будет VDSL2+, тогда да :(

Использовалась информация о дсламах: D-Link DAS-3248 rev.A, ECI HiFocus4, Teledata BroadAccess1000, Ericsson EDN312xp. Есть еще немного Huawei MA5600 и Zyxel IES-2000/3000, но я с ними плотно не работал, надо доку смотреть на предмет секурных фич.

один порт - один влан конечно многое решает, но я себе не смогу такого позволить... да и опять же получу одинаковые маки в ядре под разными вланами...
Одинаковые маки до ближайшего браса, причем каждый мак в своем личном влане, так что QinQ - один из лучших вариантов. В одном операторском влане - 4к пользовательских.
Edited by p10neer

Share this post


Link to post
Share on other sites

кстати, начиная с какой серии в роутерах есть поддержка qinq pppoe? чтобы qinq не на свиче разворачивать, а прямо на bras'е терминировать и там - pppoe?

 

Share this post


Link to post
Share on other sites

qinq не обеспечивает изоляцию пользовательских MAC-ов. В таких случаях предпочтительней MAC-in-MAC.

Share this post


Link to post
Share on other sites

Что он не обеспечивает?

Даже одиночный Q прекрасно делит пространство адресов. Один VLAN - одно пространство адресов, с соседними VLAN не пересекающееся. Можете при VLAN-per-customer вообще всем абонентам один МАС ставить.

Share this post


Link to post
Share on other sites

Свичи форвардят по MAC+vlan. В случае qinq, MAC'и остаются прежними, а вместо пользовательских vlan появляется общий outer и на inner транзитные свичи не смотрят. Поэтому если в разных inner один и тот же MAC придет из разных мест, то будет плохо, т.к. транзитные свичи ничего про inner не знают, для них есть только outer.

 

В качестве транзита в таких случаях можно еще использовать MPLS PW без MAC learning.

Share this post


Link to post
Share on other sites
Свичи форвардят по MAC+vlan. В случае qinq, MAC'и остаются прежними, а вместо пользовательских vlan появляется общий outer и на inner транзитные свичи не смотрят. Поэтому если в разных inner один и тот же MAC придет из разных мест, то будет плохо, т.к. транзитные свичи ничего про inner не знают, для них есть только outer.

 

В качестве транзита в таких случаях можно еще использовать MPLS PW без MAC learning.

Спасибо, за раскрытие темы - это я и имел в виду.

Не так много в мире коммутаторов, которые могут learning по mac+inner+outer. Точно это делает ALU 7710/7450/7750, но за счёт полного пересмотра концепции vlan в vpls с локальными на порт тагами (как dot1q, так и qinq). Они еще могут mac-in-mac через PBB–vpls связку - но это уже другая история.

К сожалению, PW без MAC learning-a (epipe) тоже немногие умеют - часто PW binding идет в стандартный vlan.

 

Share this post


Link to post
Share on other sites

попробую немного обобщить....

привязка mac-порт помогает решить проблему с пересекающимися mac'ами, подстановка mac'а браса клиентом тоже становится невозможна, флуд огромным количеством маков со стороны клиента тоже невозможен, с петлями у клиентов должен по идее справится port-isolation на дсламе и switchport protected на каталисте (если петля между абонентами на разных дсламах в пределах одного влана). Это вариант A.

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

 

Вариант B - порт-влан в qinq до браса, хорош тем что позволяет полностью справиться с петлями, прост и удобен, но во первых не решает проблему подстановки мака браса клиентом, хотя с этим легко справиться фильтрами на дсламах. Про пересечения маков внутри одного outer-vlan'а (в котором идет dot1q туннель) насколько я понял проблему не решает?

Допустим у меня на АТС-1 есть дслам с 48 портами, соответственно вланы 1-48 и есть два клиента с одинаковыми масами MAC-A, самому дсламу должно быть все равно так как порты в разных вланах, так? Свичу на атс, к которому подключен дслам тоже все равно, так как вланы у пакетов разные, далее свич упаковывает все вланы в один влан 1001 и отправляет в центр, там пакеты, вернее кадры езернет попадают на центральный каталист и он видит что приходят под одним outer вланом 1001 два кадра с одним и тем же MAC-A, он думает что это два разных кадра от одной и той же машины и не паникует, затем отправляет этот outer влан на брас, который распаковывает qinq и получает два кадра в разных сабинтерфейсах с одним маком, как он к этому отнесется? Если нормально то получается, что вариант B тоже решает проблему пересекающихся маков. Проблема может быть только если сделать одинаковые outer вланы в разные направления и принимать их в разных портах на центральном каталисте. Тогда при одинаковых маках на разных атс, центральный свич будет видеть одинаковые маки в одном outer влане на разных портах и это ему уже не понравится :-) Поправьте где ошибся, плз...

Минус варианта B - необходимы свичи и брасы с поддержкой qinq, что не дешево. Но плюсы - решение всех (?) проблем без особых трудностей.

Share this post


Link to post
Share on other sites
попробую немного обобщить....

привязка mac-порт помогает решить проблему с пересекающимися mac'ами, подстановка mac'а браса клиентом тоже становится невозможна, флуд огромным количеством маков со стороны клиента тоже невозможен, с петлями у клиентов должен по идее справится port-isolation на дсламе и switchport protected на каталисте (если петля между абонентами на разных дсламах в пределах одного влана). Это вариант A.

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

 

Вариант B - порт-влан в qinq до браса, хорош тем что позволяет полностью справиться с петлями, прост и удобен, но во первых не решает проблему подстановки мака браса клиентом, хотя с этим легко справиться фильтрами на дсламах. Про пересечения маков внутри одного outer-vlan'а (в котором идет dot1q туннель) насколько я понял проблему не решает?

Допустим у меня на АТС-1 есть дслам с 48 портами, соответственно вланы 1-48 и есть два клиента с одинаковыми масами MAC-A, самому дсламу должно быть все равно так как порты в разных вланах, так? Свичу на атс, к которому подключен дслам тоже все равно, так как вланы у пакетов разные, далее свич упаковывает все вланы в один влан 1001 и отправляет в центр, там пакеты, вернее кадры езернет попадают на центральный каталист и он видит что приходят под одним outer вланом 1001 два кадра с одним и тем же MAC-A, он думает что это два разных кадра от одной и той же машины и не паникует, затем отправляет этот outer влан на брас, который распаковывает qinq и получает два кадра в разных сабинтерфейсах с одним маком, как он к этому отнесется? Если нормально то получается, что вариант B тоже решает проблему пересекающихся маков. Проблема может быть только если сделать одинаковые outer вланы в разные направления и принимать их в разных портах на центральном каталисте. Тогда при одинаковых маках на разных атс, центральный свич будет видеть одинаковые маки в одном outer влане на разных портах и это ему уже не понравится :-) Поправьте где ошибся, плз...

Минус варианта B - необходимы свичи и брасы с поддержкой qinq, что не дешево. Но плюсы - решение всех (?) проблем без особых трудностей.

В варианте В именно так и происходит. Ну и на каждое устройство доступа выделяется свой outer vlan, куда без этого, сразу решается вопрос унификации настройки устройств доступа. Но в qinq есть другие недостатки - весь широковещательный трафик в этом vlan тянется транзитом до ядра в случае централизованной модели, и на все транковые порты, где требуется затерминировать inner vlan с этим outer (или где он просто не исключен из транка). Также нельзя затерминировать на близлежащей машинке без поддержки qinq - и тогда все в центр. Всякие выверты вроде qinq mapping для выдергивания inner vlan существенно повышают стоимость решения. А если возникает мультикаст в metro/sp/outer vlan - мама не горюй. Тут же забываем про igmp и qos, если вопрос цены имеет значение.

Итого - QinQ плохо масштабируется, но хорош при децентрализованной модели, или в случае централизованной, но с простой топологией уровня агрегации.

Share this post


Link to post
Share on other sites

Итак - снова здравствуйте! :)

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

Как оказалось среди клиентов много с одинаковыми маками. Благодаря куинку и разным вланам на дслам, свичи ведут себя спокойно, если такие абоны попадают на разные дсламы и разные брасы. Но если они случайно попадают на один брас или дслам, то начинаются дисконнекты. Ума не приложу, что делать то? Если на некоторых дсламах есть защита от одинаковых маков, которая к тому же не работает (см. http://forum.nag.ru/forum/index.php?showto...p;#entry478893), то что делать с брасами? Единственная мысль, которая приходит в голову - влан на порт, но может есть какие-то другие более экономичные варианты?

 

Share this post


Link to post
Share on other sites

5. Ну будет пусть даже 25 мегабит от абонента к брасу - ну и что? Вон например ЭР-Телеком дают 100мбит эзернетчикам внутри своей сети через BRAS.

Share this post


Link to post
Share on other sites
Единственная мысль, которая приходит в голову - влан на порт, но может есть какие-то другие более экономичные варианты?

а чем она неэкономичная? какое число абонентов?

 

Share this post


Link to post
Share on other sites
а чем она неэкономичная? какое число абонентов?

Тем, что либо нужно разворачивать все вланы в центре перед заводом на пачку брасов, а тогда количество клиентов ограничивается 4096, либо терминировать QinQPPPoE прям на брас, а мое железо такого не умеет...

Share this post


Link to post
Share on other sites

Изолировать порты + фильтровать по макам на дсламе. Влан на абонента не надо.

Что-то вы тут такое сложное напридумывали.

Проще надо быть.

А если абонент завалит брас или дслам - поднять логи и оторвать голову абоненту.

 

Share this post


Link to post
Share on other sites

Если используется vlan на dslam и на каждый порт прописывается мак и выключается learning, то qinq не нужен. А вот если фильтра по макам нет, id порта в pppoe не вставляется/не обрабатывается, то о qinq есть смысл задуматься, чтобы точно знать с какого порта пришёл тот или иной запрос(чтобы не воровали mac-адреса и логины/пароли)

Share this post


Link to post
Share on other sites
А если абонент завалит брас или дслам - поднять логи и оторвать голову абоненту
вашими устами, как говориться, да - меду...

 

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

 

 

Share this post


Link to post
Share on other sites
А если абонент завалит брас или дслам - поднять логи и оторвать голову абоненту
вашими устами, как говориться, да - меду...

 

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

У вас провайдинг или завод?

Даже если у вас 2 дслама то все документировать, иначе будет бардак. Монтерам тоже клизмы. В конце концов у нас не развлекалово, а работа.

Edited by yakuzzza

Share this post


Link to post
Share on other sites
Даже если у вас 2 дслама то все документировать
причем тут это? у меня все документировано...

 

Монтерам тоже клизмы
Монтеры работают в телефонной компании - за их адекватность ручаться не могу, да и ссорится с ними не желательно :)

 

Давайте решать ТЕХНИЧЕСКИЙ вопрос, а не АДМИНИСТРАТИВНО-ОРГАНИЗАЦИОННЫЙ :) пожалуйста

 

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

Share this post


Link to post
Share on other sites

Очень часто вместо технически долгого решения легче организационно быстро решить. Это как запретить порносайты ;)

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

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

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

 

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

Share this post


Link to post
Share on other sites

yakuzzza

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

А то вы прям как янки приходите на другой конец мира и говорите как тут надо жить...

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

 

Share this post


Link to post
Share on other sites

Да ради Бога. Я 130 лет собираюсь прожить и поэтому спорить не буду (старый анекдот).

 

Привязывайте ИП к макам, ставьте arpwatch, пхайте все вланы в этот таз и трекайте логи арпвотча и коммутаторов доступа.

Идеи все уже высказали. А, еще я не янки, я просто люблю спокойно спать ;) Все что я сказал - не более личного опыта.

 

---

Удачи.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this