Перейти к содержимому
Калькуляторы

Защита от кражи трафика при IP Unnumbered схема vlan на коммутатор

Добрый день, коллеги.

Начинаем переходить на IP unnumbered. Адреса раздаем по DHCP, релеем и точкой терминирования абонентов выступает C3750. Схема vlan на коммутатор выбрана из соображения того, что большая часть коммутаторов имеет следующий функционал, который и планируется использовать:

Есть: 802.1Q + Port Isolation + DHCP Snooping

Нет: IP Source Guard + QinQ + не пропускают пакеты QinQ (MTU изменить нельзя)

 

Все остальные свичи умеют всё вышеперечисленное и даже больше. Правильно ли я понимаю, что IP Source Guard нужен только для защиты от IP Spoofing'а и кража трафика без него невозможна? Очень не хочется возиться с ACL, чтобы разрешать на порту только трафик с определенного IP.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

PPPoE - это другая технология.

С vlan per user все и так понятно, но вопрос был по схеме vlan на свич.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

не будет никакой кражи при правильной opt82

просто не использовать poll на аннамбереде, а использовать dhcp snooping + dhcp relay непосредственно на циске

либо влан пер юзер, тогда вешайте опт82 где угодно

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Забыл уточнить, что используем привязку по MAC вместо opt82, но думаю значения это не имеет в данном случае. dhcp relay и dhcp snooping включены на циске. Вот типовой пример настройки vlan интерфейса:

 

interface Vlan105
description dhcp-test
ip unnumbered Loopback1
ip helper-address 192.168.4.18
no ip redirects
no ip unreachables
ip local-proxy-arp
ip route-cache same-interface
end

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

... в момент его отсутствия кто-то подключил его кабель.

 

Зачем? О_о

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Зачем? О_о

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Соорудил тест на стенде. Ноутбук и роутер в одном вилане на одном коммутаторе. Каждый получает свой IP по DHCP. Вот тут если на ноутбуке прописать IP адрес роутера, то можно спокойно работать. Особенно если с роутера почти нет никакой активности.

Включил на циске arp inspection и всё. Больше таким образом нельзя работать.

 

Привожу конфиг циски

!
ip dhcp snooping vlan 105,107,124,153,158
ip dhcp snooping information option allow-untrusted
no ip dhcp snooping information option
ip dhcp snooping
ip arp inspection vlan 105,107,124,153,158
!
interface Loopback1
ip address 10.1.X.1 255.255.224.0 secondary
ip address 91.X.X.X 255.255.252.0
!
interface Vlan105
description dhcp-test
ip unnumbered Loopback1
ip helper-address 192.168.4.18
no ip redirects
no ip unreachables
ip local-proxy-arp
ip route-cache same-interface
!
interface Vlan107
ip unnumbered Loopback1
ip helper-address 192.168.4.18
no ip redirects
no ip unreachables
ip local-proxy-arp
ip route-cache same-interface
!
interface Vlan124
ip unnumbered Loopback1
ip helper-address 192.168.4.18
no ip redirects
no ip unreachables
ip local-proxy-arp
ip route-cache same-interface
!
interface Vlan153
ip unnumbered Loopback1
ip helper-address 192.168.4.18
no ip redirects
no ip unreachables
ip local-proxy-arp
ip route-cache same-interface
!
interface Vlan158
ip unnumbered Loopback1
ip helper-address 192.168.4.18
no ip redirects
no ip unreachables
ip local-proxy-arp
ip route-cache same-interface
!

 

Я не придумал еще способов как можно поюзать чужой трафик, кроме как прописать себе чужой MAC адрес, но это уже довольно сложно будет вычислить наобум.

Изменено пользователем crank

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Включил на циске arp inspection и всё. Больше таким образом нельзя работать.

 

Если ребутнется коммутатор, то все подключенные от него абоненты, кторые ранее получили IP по DHCP, будут обязаны вручную переполучить адреса, т.к. коммутатор "забудет" привязку после рестарта.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

МАК клиента вычислять не надо, его можно "поймать". dot1x не подойдет для ваших целей?

Изменено пользователем VolanD666

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Каким образом можно поймать мак? Схема вилан на свич + port isolation.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Включил на циске arp inspection и всё. Больше таким образом нельзя работать.

 

Если ребутнется коммутатор, то все подключенные от него абоненты, кторые ранее получили IP по DHCP, будут обязаны вручную переполучить адреса, т.к. коммутатор "забудет" привязку после рестарта.

 

А есть же некий механизм хранения лиз на tftp сервере. Если я не ошибаюсь, конечно.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Если ребутнется коммутатор, то все подключенные от него абоненты, кторые ранее получили IP по DHCP, будут обязаны вручную переполучить адреса, т.к. коммутатор "забудет" привязку после рестарта.

 

А есть же некий механизм хранения лиз на tftp сервере. Если я не ошибаюсь, конечно.

Есть конечно и оно работает - привязки IP - MAC востанавливаються при рестаре.

Но при ip unnumbered свичу нужно еще прописывать маршруты (VLAN) до конкретного IP. А эта инфра НЕ ВОСТАНАВЛИВАЕТЬСЯ при загруке лиз с FTP.

К сожалению, наш случай :(

Поэтому следим за хорошим питанием циски и забываем команду reload ;-)

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Или авторизация по IP? Если так, то проще сделать авторизацию по маку или использовать vlan-per-user или opt 82.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Или авторизация по IP? Если так, то проще сделать авторизацию по маку или использовать vlan-per-user или opt 82.

Использую авторизацию по маку + изоляцию портов. Сам считаю, что этого должно быть достаточно, но решил проконсультироваться правильно ли я всё понял.))

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Запилите MAC+VLAN, тогда кражи трафика не будет

Прибежал легальный МАС, но на счету нет денег, белый IP не выдаем

Прибежал легальный МАС, на счету есть деньги, но мак не со своего VLAN, белый IP не выдаем (если параноик, можете запилить notification)

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

У вас нет проблем с "ip route-cache same-interface"?

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

Вернул "ip route-cache cef" - вроде пока глюков нету..

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

crank

А что мешает сделать vlan per user? Оно фактически даже проще этих хитрых схем с изоляциями и привязками.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Можно выдавать IP-адрес ориентируясь на опцию 82, а трафик блокировать на DPI.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

если подмена MAC + IP то только авторизация по порту

либо влан на юзера и авторизация по терминирующей железке + номер влана или q-in-q и авторизация по svlan + cvlan + по терминирующей железке (аля remote-id)

а опция 82 содержит много инфы, можно авторизовать по опции 82 и вытягивать из нее только мак и remote-id таким образом терминирующая железка либо свитч доступа + мак абона, тоже не годится

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

У вас нет проблем с "ip route-cache same-interface"?

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

Вернул "ip route-cache cef" - вроде пока глюков нету..

Такого глюка пока не замечал. Порт вы меняете на терминирующей железке или на доступе?

 

А что мешает сделать vlan per user? Оно фактически даже проще этих хитрых схем с изоляциями и привязками.

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

 

В общем схема vlan на свич, и будем считать что переделать на что-то другое нет возможности.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Гость
Ответить в тему...

×   Вставлено в виде отформатированного текста.   Вставить в виде обычного текста

  Разрешено не более 75 смайлов.

×   Ваша ссылка была автоматически встроена.   Отобразить как ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставить изображения напрямую. Загрузите или вставьте изображения по ссылке.