|
|
Страница 1 из 1
|
[ Сообщений: 8 ] |
|
IP Spoofing, но как это возможно?
Автор |
Сообщение |
Castus
Зарегистрирован: 19 янв 2016, 21:33 Сообщения: 47
|
Друзья, несколько обескуражен тем, что увидел сегодня по выводу ip nat translations на ISR 2901 через который проходит трафик до шлюза, предоставляющего подключение через RDP для пользователей. В выводе увидел адрес из подсети 10.0.0.0/8 - то есть фейк, всё бы ничего - обычная подмена адресов и всё такое, но пользователь работает и трафик ходит, а не просто сессия висит! Тут я несколько впал в ступор - как это может быть, если адрес не маршрутизируемый?! Адрес пришёл из интернета - это однозначно. Трассировка не проходит - если предположить, что провайдер как-то может, видя, что пользователь из его сети маршрутит трафик внутри себя... Вложение:
FAKEcisco.jpg [ 16.79 КБ | Просмотров: 6428 ]
Вложение:
FAKErdgw.jpg [ 6.91 КБ | Просмотров: 6428 ]
|
07 апр 2020, 05:31 |
|
|
Black Fox
Зарегистрирован: 12 июл 2012, 17:44 Сообщения: 841
|
А можно схему? Может быть, у вас там ещё какое-нибудь устройство натит. Либо клиенты не напрямую из инета приходят, а через ВПН, например.
|
07 апр 2020, 18:42 |
|
|
Castus
Зарегистрирован: 19 янв 2016, 21:33 Сообщения: 47
|
Black Fox писал(а): А можно схему? Может быть, у вас там ещё какое-нибудь устройство натит. Либо клиенты не напрямую из инета приходят, а через ВПН, например. Ничего такого нет, 2901 смотрит в интернет, за ней коммутатор в котором живёт сервер, всё, больше ничего... Есть подозрения, что проделки провайдера и они натят клиентов своих же, но пока не ответили ничего насчёт почему у них Bogon ходит... Провайдер ТТК, что как бы вообще странно, если так и есть...
|
07 апр 2020, 18:47 |
|
|
tonve
Зарегистрирован: 26 сен 2013, 10:29 Сообщения: 422
|
uRPF, к сожалению, мало у кого включен. Из-за чего и генерят всякий мусор от айпишников из серых сетей. Магистралы такое не фильтруют, перекладывая проблему на конечных потребителей трафика. На сабинтерфейсе с инетом включите rpf loose, создайте если не создали interface null0, задайте в нём no ip unreach, ip route 10.0.0.0 255.0.0.0 null 0
|
07 апр 2020, 19:05 |
|
|
Castus
Зарегистрирован: 19 янв 2016, 21:33 Сообщения: 47
|
tonve писал(а): создайте если не создали interface null0, задайте в нём no ip unreach, ip route 10.0.0.0 255.0.0.0 null 0 В чём преимущество этого решения относительно фильтрации в ACL? На интерфейсе у меня включено ip verify unicast reverse-path...
|
07 апр 2020, 20:07 |
|
|
tonve
Зарегистрирован: 26 сен 2013, 10:29 Сообщения: 422
|
ACL выгоднее, особенно на софтроутерах - он отрабатывает до route lookup. Просто по мне так кажется решать подобную проблему...эээ..изящнее, что ли.
|
07 апр 2020, 20:29 |
|
|
Silent_D
Зарегистрирован: 07 сен 2014, 02:54 Сообщения: 548 Откуда: Msk
|
tonve писал(а): Просто по мне так кажется решать подобную проблему...эээ..изящнее, что ли. Вот это сомнительное утверждение. ACL дропает левые пакеты на входе, а tonve писал(а): создайте ... interface null0, задайте в нём no ip unreach, ip route 10.0.0.0 255.0.0.0 null 0
заворачивает в null ответы, что конечно лучше, чем ничего, но сам входящий то пакет вы уже сожрали. Плюс у вас собственная 10-ая сетка может быть внутри. Вообще должен быть стандартный набор в In ACL: Код: access-list 101 remark === Firewall ACL access-list 101 deny ip host 0.0.0.0 any access-list 101 deny ip host 255.255.255.255 any access-list 101 deny ip 127.0.0.0 0.255.255.255 any access-list 101 deny ip 172.16.0.0 0.15.255.255 any access-list 101 deny ip 192.168.0.0 0.0.255.255 any access-list 101 deny ip 10.0.0.0 0.255.255.255 any access-list 101 permit icmp host <ISP_GW> any time-exceeded access-list 101 permit icmp host <ISP_GW> any echo-reply access-list 101 deny ip <User_Net>.0 0.0.0.255 any access-list 101 remark --- access-list 101 ...
_________________ Knowledge is Power
|
07 апр 2020, 21:15 |
|
|
tonve
Зарегистрирован: 26 сен 2013, 10:29 Сообщения: 422
|
Silent_D писал(а): tonve писал(а): Просто по мне так кажется решать подобную проблему...эээ..изящнее, что ли. Вот это сомнительное утверждение. Дело вкуса. О том что acl сработает раньше я указал. Silent_D писал(а): заворачивает в null ответы Нет, не заворачивает. CEF дропнет эти пакеты при route lookup, там обрабатывается urpf. Если быть дотошным, то это верно скорее только для NCS, и для обычных роутеров это не совсем так, гугл ciso ios order of operations. Silent_D писал(а): Плюс у вас собственная 10-ая сетка может быть внутри. Вся /8? И даже если так, uRPF здесь очень даже к месту. Или подразумевается что приходит суммированный анонс /8 из динамики, и всё будет поломано? Циска о моём выборе глаголет сие: "With Unicast RPF, ingress filtering is done at Cisco Express Forwarding PPS rates. Because Unicast RPF uses the Forwarding Information Base (FIB), ACL maintenance is not required, and thus, the administration overhead of traditional ACLs is reduced. " На софтроутерах пытаться изображать оптимизацию под хайлоад смысла (имхо) нет. На роутерах с асиками, типа мангала, смысла в оптимизации мало, ибо пакет всё равно получен.
|
08 апр 2020, 00:36 |
|
|
|
Страница 1 из 1
|
[ Сообщений: 8 ] |
|
Кто сейчас на конференции |
Сейчас этот форум просматривают: Google [Bot] и гости: 85 |
|
Вы не можете начинать темы Вы не можете отвечать на сообщения Вы не можете редактировать свои сообщения Вы не можете удалять свои сообщения Вы не можете добавлять вложения
|
|
|