Нужен совет:
Меня интересует как провайдеры обеспечивают безопасность IP адреса т.е как ISP борются от злоумышленников которые хотят использовать IP других клиентов
Старый способ это привязка ARP (MAC + IP )
Интересует другие способы, кто знает поделитесь....
Спасибо.
> Нужен совет:
> Меня интересует как провайдеры обеспечивают безопасность IP адреса т.е как ISP борются
> от злоумышленников которые хотят использовать IP других клиентов
> Старый способ это привязка ARP (MAC + IP )
> Интересует другие способы, кто знает поделитесь....
> Спасибо.acl src addr на интерфейс
> Нужен совет:
> Меня интересует как провайдеры обеспечивают безопасность IP адреса т.е как ISP борются
> от злоумышленников которые хотят использовать IP других клиентов
> Старый способ это привязка ARP (MAC + IP )
> Интересует другие способы, кто знает поделитесь....Тоже довольно старый способ - управляемое оборудование, с порт-секюрити.
> Нужен совет:
> Меня интересует как провайдеры обеспечивают безопасность IP адреса т.е как ISP борются
> от злоумышленников которые хотят использовать IP других клиентов
> Старый способ это привязка ARP (MAC + IP )
> Интересует другие способы, кто знает поделитесь....
> Спасибо.IPSec
VLAN per user. Решение, правда, недешевое (вланы надо терминить соответствующим оборудованием, а у каждого оборудования есть ограничение на кол-во поддерживаемых вланов), но самое эффективное. Ну и на терминирующем оборудовании роутинг одного IP в определенный (назначенный пользователю) влан. Назначил юзверь другой IP - и получил отлуп - ничего работать не будет. То, что Вы выше назвали "старым способом" - это защита от пионэров. Обычно удел маленьких домовых сетей. Ну и разумеется, технология о которой я говорю требуют наличия в сети везде управляемого оборудования (свичей), никаких неуправляемых мыльниц (которые, к тому же запросто могут положить весь сегмент сети).
> сетей. Ну и разумеется, технология о которой я говорю требуют наличия
> в сети везде управляемого оборудования (свичей),Управляемое оборудование не тождественно свичам.
Бывают неуправляемые свичи (наиболее распространенный вид свичей), а бывают управляемые свичи(стоят несколько дороже дешевых мыльниц "а-ля свытич").
Управляемое оборудование - в части свичей -это только управляемые свичи а не любые свичи вообще.Неуправляемый свичи так же легко кладут сегмент сети как и хабы. И в плане безопасности - полный голяк.
Для организации безопасной работы необходимы управляемые свичи. И тут возникает смысловая коллизия с МБОНЕ.
Зачем нужен терминатор на вланах, если можно банально включить порт-секюрити на порту и жестко (раз уж у нас стоит нормальное управляемое оборудование да :), привязать ФИЗИЧЕСКИЙ порт на оборудовании к клиенту? Как гвоздями прибить.
Клиент не выйдет в сеть с иным адресом чем приписан ему (не пройдет дальше порта на свиче к которому он подключен физически), сеть разгрузится (трафик не будет гоняться через МБОНЕ, а это очень важно, поскольку локальные взаимообмены с трафиком не будут гоняться через центральный узел который станет для них узким местом), трафик можно будет учитывать весь абсолютно (данные о трафике снимаются с порта клиента а не где-то с сети).PS: на самом деле я знаю зачем нужен терминировать клиентов на МБОНЕ. Это использовалось тогда когда выделить управляемый свичь с порт-секюрити на конечный сегмент было дорого, и там ставили управляемый свичи только с поддержкой вланов. Они были дороже мыльниц но дешевле нормальных управляемых свичей. Но эти выгадывания на копейках имеют смысл только при очень-очень пионерской сети. Такое решение имеет указанные выше недостатки - дополнительная нагрузка на центральное оборудование, загрузка каналов лишним трафиком (например клиенты могли бы обмениваться фильмами на высокой скорости внутри сегмента, а с МБОНЕ они будут вынуждены гонять поток в две стороны).
Ну дык VLAN на порту свича - это и есть один из вариантов порт секьюрити. Не более того. "Порт секьюрити" - всего лишь термин. Под которым, кстати, разные производители оборудования могут понимать абсолютно разные термины. Вариант привязки МАК-адреса в данном случае к порту свича - не самый лучший вариант. Причина вполне очевидна - пользователь может поменять оконечное устройство. И что тогда? Руками править настройки свича каждый раз? А если таких пользователей 10? А если 100? А если 1000? А привязка VLAN к номеру порта требует только первоначальной (разовой) настройки. Хотя, конечно, не исключены исправления конфигов в дальнейшем, но они существенно меньше, чем в случае привязки МАК-адреса. Или Вы о другом там выше?
Про управляемые и неуправляемые свичи - я как бы в курсе. :)
Про съем данных о трафике с порта клиента мне понравилось - а если это именно СВИЧИ? Управляемые, но свичи. Без третьего уровня. Снимать данные с портов КАЖДОГО свича? А если их 100? А если 1000? ОБъем снимаемых данных представляете? Да и ненужных к тому же - на кой черт, мне, например, внутрисетевой трафик, если он у меня не считается? А если клиенту потребуется детализация по трафику? Вы по данным снимаемым с порта ее не получите - там есть данные только по количеству пакетов переданных/принятых портом. Если не считается внутрисетевой трафик (а в нормальных сетях это именно так) - то более оптимальный вариант сливать (экспортировать) данные с граничного бордера - тем же НетФлоу. Потом их собирать на неком коллекторе (ну, например, Линукс c flow-tools, или FreeBSD с ng_netflow - не суть важно) и потом делать с ним, что хошь.
Впрочем, это мы уже отвлеклись в сторону. :)
> Нужен совет:
> Меня интересует как провайдеры обеспечивают безопасность IP адреса т.е как ISP борются
> от злоумышленников которые хотят использовать IP других клиентов
> Старый способ это привязка ARP (MAC + IP )
> Интересует другие способы, кто знает поделитесь....
> Спасибо.Выдают клиенту сеть /30? Сменит IP - не попадет в дефолт гейтвей
>> Нужен совет:
>> Меня интересует как провайдеры обеспечивают безопасность IP адреса т.е как ISP борются
>> от злоумышленников которые хотят использовать IP других клиентов
>> Старый способ это привязка ARP (MAC + IP )
>> Интересует другие способы, кто знает поделитесь....личная беседа с наушителями и их родствениками (мама и папа).
коллекторское ШАРИАт к примеру имеет очень высокий процент возврата задолженостей по кредитам.
вообще если пообщатся с папой и мамй нарушителя - это самый действеный способ.
acl по src не пойдет, IPSec не понял мысль. Vlan per user. Для каждого user-a vlan. Не очень понятно, все равно спасибо за мысль, теперь есть думать в какую сторону)). Есть еще предложения. ?
> Vlan per user. Для каждого user-a vlan. Не очень понятно, все равно спасибо за мысль, теперь есть думать в какую сторону)).Ну - Вы сможете нагуглить много на эту тему самостоятельно. :) Если вкратце, то это можно описать так. Оконечный пользователь подключен к оконечному свичу (как выше замечено - ЕСТЕСТВЕННО, управляемому). К порту этого свича привязан (предварительно) некий VLAN. Который УНИКАЛЕН в пределах терминирнующего узла. Соответственно, при прохождении трафика весь трафик пользователя на втором уровне маркируется соответствующим VID. Когда трафик доходит до терминирующего устройства уже на ТРЕТЬЕМ уровне есть некая связка - /32 сеть (то есть один IP) для конкретного VLAN. Собственно, никто не мешает повесить туда хоть /24 сеть (при желании), либо любую другую. Вкратце вот где-то так. На самом деле там все несколько сложнее и более обширнее, но суть приблизительно такая. Опять повторюсь - что эта технология требует больших финансовых вложений (если не строить сеть на софтороутерах, ака Линукс/ФриБСД - ибо глючны есть - но это уже выходит за рамки темы) и некоего механизма (ручного зачастую) отслеживания, чтобы один VLAN не был отдан двум разным IP (и наоборот). Уникальность VLAN, как сказано выше - в пределах одной точки терминации.
> Выдают клиенту сеть /30? Сменит IP - не попадет в дефолт гейтвейИ сколько ж таких дефолт гейтвеев надо прописать, к примеру, на циске? :) Опять же - теряется адресное пространство. На мой взгляд - вариант, предложенный мной выше (а это реально работающий, боевой вариант) намного предпочтительнее. Опять же от юзверя не требуется никаких лишних телодвижений - только ввод в настройки сетевой карты сетевых реквизитов. Еще предпочительнее вариант автоматического (DHCP) назначения IP На терминящий VLAN - но там есть нюансы, в виде, например Option 82 - необходима его поддержка на свичах и на терминирующем оборудовании (циски, джуниперы - не суть важно).
PPPoE
> PPPoEДа про PPoE Забыл написать. Этот вариант используется с BRAS-ом. Спс
ip src-guard + dhcp-snoop это если в домосети.
> ip src-guard + dhcp-snoop это если в домосети.Ок, а если провадейрская сеть ?