Comments 19
Может сможете ответить на давно мучающий меня вопрос. Как то заметил, что на мой веб сервер (белый, статический IP) поступают запросы, для которых у меня нету виртуальных хостов, посмотрел повнимательнее, и увидел странное. Запросов много, но они есть, приходят от различных пользователей, с различных ОС и браузеров, на различные ресурсы, типа Google, Yandex, VK, но на мой сетевой интерфейс, причём в запросах указаны куки пользователей. Записал дамп, и увидел совсем невероятное, для подобных запросов в dst значился реальный адрес назначения, там не было моего адреса, но пакет почему то прилетал ко мне. Наблюдал подобное поведение в течение года, потом тот IP адрес у меня забрали. Как такое вообще возможно?
Тоже вижу много таких запросов в логах. Мне кажется, это автоматический поиск открытых прокси-серверов, по крайней мере в части случаев.
В тех случаях, когда src — мой адрес — да, это могут быть сканеры открытых прокси, но в большинстве случаев это не так, и это для меня кажется странным.
Тогда невероятное предположение, если ни src ни dst совсем не близко, тогда возможно кто-то считал ваш адрес маршрутизатором (какая-то виртуальная сеть, как с Hamachi. TOR?), в локальной сети соседа можно по маку посмотреть, он то точно не должен был отличаться разнообразием, чтобы понять хотя бы откуда всё это.
Обычно в случае с провайдерами видны кучами netbios и arp запросы от всех соседей по коммутатору.
Обычно в случае с провайдерами видны кучами netbios и arp запросы от всех соседей по коммутатору.
Так сложно сказать. Простейшее, что можно предположить — первый кадр прилетающий на коммутатор, с мак адресом не присутствующим в таблице коммутации отправляется на все доступные интерфейсы (это стандартное поведение), тоже происходит при исчерпании таблицы коммутации (здесь надо думать о расширении). Тоже в общем касается и маршрутизаторов, основная задача передать данные, если при этом нам не хватает ресурсов на анализ — тогда передаём данные любой ценой.
В качестве расследования, как мне кажется надо искать общую разделяемую среду, если это облачная инфраструктура значит сервер делит с кем-то физическую сетевую карту и драйвер. Если физическая инфраструктура то общие коммутаторы, маршрутизаторы. Смотрим находимся ли мы с источником или получателем в одной или близкой сети, если запросы реальные то адреса должны быть реальные.
В качестве расследования, как мне кажется надо искать общую разделяемую среду, если это облачная инфраструктура значит сервер делит с кем-то физическую сетевую карту и драйвер. Если физическая инфраструктура то общие коммутаторы, маршрутизаторы. Смотрим находимся ли мы с источником или получателем в одной или близкой сети, если запросы реальные то адреса должны быть реальные.
Скажите, а зачем прописывать кучу deny шз с разными адресами, если в конце всё равно идёт deny ip any any?
Разве это правило не покроет все предыдущие deny? Или это чтобы конкретно видеть, что запрещается по данному правилу?
Разве это правило не покроет все предыдущие deny? Или это чтобы конкретно видеть, что запрещается по данному правилу?
узел источник трафика имеет на интерфейсе одним из адресов указанный в качестве адреса назначения
Объясняю. Железка хотела поговорить сама с собой или принять чей-то траффик. Только в этот момент один из ее IP-адресов был (временно) снят, и она отправилась его искать согласно таблице маршрутизации.
«Вот эти два случая остались для меня загадкой — кто, как и зачем?»
Элементарно. У кого-то за роутером своя сетка с серой адресацией. Пока в ней все ок, к вам ничего не утекает. Потом пропадает какой-то внутренний линк между какими-то площадками, специфические правильные внутренние маршруты исчезают и все (на адреса назначения отвалившей подсети) начинает улетать по дефолт роуту к вам (в том числе с белых ип срц, если люди используют NAT). У людей отсутствует защитный маршрут в Null с завышенной по сравнению с AD динамического протокола дистанцией. А еще лучше делать такие маршруты не в Null, а куда-нибудь в сторонку, и там банить и логгировать. Я так массу интересных вещей ловлю.
А еще есть добивающий меня приколы. Многие провайдеры не фильтруют у себя нифига, в итоге с их линков на выданные ими белые ип прилетает трафик с серых сетей (причем не из провайдерской сети, а именно с инета), на выход они это тоже часто не фильтруют. Один из провайдеров у нас например не фильтрует даже белые ип срц и в итоге можно через два линка от разных провов мутить асимметричный трафик. Уходит через одного, с неродным для него ип, назад прилетает через другого, для которого этот ип корректен. СОРМ у каждого провайдера видит только половину трафика :)
Элементарно. У кого-то за роутером своя сетка с серой адресацией. Пока в ней все ок, к вам ничего не утекает. Потом пропадает какой-то внутренний линк между какими-то площадками, специфические правильные внутренние маршруты исчезают и все (на адреса назначения отвалившей подсети) начинает улетать по дефолт роуту к вам (в том числе с белых ип срц, если люди используют NAT). У людей отсутствует защитный маршрут в Null с завышенной по сравнению с AD динамического протокола дистанцией. А еще лучше делать такие маршруты не в Null, а куда-нибудь в сторонку, и там банить и логгировать. Я так массу интересных вещей ловлю.
А еще есть добивающий меня приколы. Многие провайдеры не фильтруют у себя нифига, в итоге с их линков на выданные ими белые ип прилетает трафик с серых сетей (причем не из провайдерской сети, а именно с инета), на выход они это тоже часто не фильтруют. Один из провайдеров у нас например не фильтрует даже белые ип срц и в итоге можно через два линка от разных провов мутить асимметричный трафик. Уходит через одного, с неродным для него ип, назад прилетает через другого, для которого этот ип корректен. СОРМ у каждого провайдера видит только половину трафика :)
Ну и клиенты тоже хороши. Получая трафик с серых ип с инета, их роутеры часто честно шлют ицмп эхо ответы или там анричиблы какие внутрь корпоративных ЛВС, что дает возможность элементарного флуда с инета в приватные сети (главное знать внутренню адресацию). И это у многих даже при включенном NAT-е и жестком фильтре на входе.
А еще недавно в корп. MPLS VPN проанонсировал гугловский 8.8.8.8 и оказалось, что многие регионы нашей большой распределенной организации не фильтруют в бгп маршруты и ко мне потек днс трафик :)
А еще недавно в корп. MPLS VPN проанонсировал гугловский 8.8.8.8 и оказалось, что многие регионы нашей большой распределенной организации не фильтруют в бгп маршруты и ко мне потек днс трафик :)
Вполне может быть. Но у нас клиент в основном, это частное лицо — роутер, пару устройств за ним. Так что здесь надо что-то автоматическое и легкодоступное искать, потому что такого добра реально много.
Многие не фильтруют это точно. Как провайдер могу сказать, что когда у тебя в сети автоматическая маршрутизация, то практически с любого линка можно добраться до интернета, причём с любого адреса. Причины — uRPF накладная по производительности вещь и к тому же не каждая железка такое умеет. Уникальные ACL опять же под каждый линк, это организационно сложно и опять же дорого в плане расходования памяти. Конечно ради собственного спокойствия приходится жертвовать, но унификация наше всё.
Так что если провайдер что-то упустил, то лучше его предупредить, пока кто-нибудь не воспользовался и не сделал бяку всем, и провайдеру, и его клиентам и себе в том числе. А уж предупредить, как я выразился в статье «собрата провайдера», если что-то у тебя пошло не так или что-то нашёл странное, это вообще без вопросов должно быть.
Многие не фильтруют это точно. Как провайдер могу сказать, что когда у тебя в сети автоматическая маршрутизация, то практически с любого линка можно добраться до интернета, причём с любого адреса. Причины — uRPF накладная по производительности вещь и к тому же не каждая железка такое умеет. Уникальные ACL опять же под каждый линк, это организационно сложно и опять же дорого в плане расходования памяти. Конечно ради собственного спокойствия приходится жертвовать, но унификация наше всё.
Так что если провайдер что-то упустил, то лучше его предупредить, пока кто-нибудь не воспользовался и не сделал бяку всем, и провайдеру, и его клиентам и себе в том числе. А уж предупредить, как я выразился в статье «собрата провайдера», если что-то у тебя пошло не так или что-то нашёл странное, это вообще без вопросов должно быть.
Предупредить мироеда? Мы раз билайну пытались что-то доказать про упавшую емкость канала, последняя миля которого собрана из e1 потоков. Неделя нервов и только личный контакт с четким челом из Мск офиса этой контоны через forum.nag.ru спас ситуацию на вторую неделю мытарств. Похожие истории с ростелекомом. Ну а указывать им на какие-то ошибки, даже не могу представить себе такую картину.
На счет уникальных ACL — может они и не нужны массово. Но хотя бы на int3 из вашей схемки лист повесить можно с запретом на инпут с серых диапазонов и запретом на аут с белыми ип срц, вам не принадлежащими. Вроде все весьма лаконично должно получиться, не портянка.
На счет уникальных ACL — может они и не нужны массово. Но хотя бы на int3 из вашей схемки лист повесить можно с запретом на инпут с серых диапазонов и запретом на аут с белыми ип срц, вам не принадлежащими. Вроде все весьма лаконично должно получиться, не портянка.
Это печально и грустно, я представлю себе ситуацию отлично, просто очень хочется чтобы все друг к другу с уважением относились, а forum.nag.ru нужен был бы, чтобы в обеденный перерыв «за жизнь поговорить».
Про ACL, есть одна беда масштабируемости — пусть у нас 256 интерфейсов на маршрутизаторе с сетями по /24, общая агрегированная сеть значит /16. И если мы блокируем сеть целиком по /16 со стороны абонентов, тогда абонент может заспуфить 65535 адресов, глобально в Интернете это не будет заметно, но провайдер в таком объёме получить ощутимые неприятности внутри своей сети. Т.е. унифицированный ACL для каждого абонентского интерфейса может привести к «китайской» проблеме, вроде всё своё родное, но его так много что не справиться.
Если на каждый интерфейс вешать одинаковые ACL различающиеся только сетью абонентов /24, то у нас 256 ACL, не такая большая беда в общем, но визуально уже трудноуловимо, да и памяти у некоторых устройств уже может не хватать.
Если продолжить масштабировать дальше и представить себе 100 таких устройств… (Цифры беру вовсе не с потолка).
Так что как и в любом деле — разумный компромисс — цена, надёжность, безопасность, масштабируемость, управляемость, профессионализм. У всех по разному получается.
Про ACL, есть одна беда масштабируемости — пусть у нас 256 интерфейсов на маршрутизаторе с сетями по /24, общая агрегированная сеть значит /16. И если мы блокируем сеть целиком по /16 со стороны абонентов, тогда абонент может заспуфить 65535 адресов, глобально в Интернете это не будет заметно, но провайдер в таком объёме получить ощутимые неприятности внутри своей сети. Т.е. унифицированный ACL для каждого абонентского интерфейса может привести к «китайской» проблеме, вроде всё своё родное, но его так много что не справиться.
Если на каждый интерфейс вешать одинаковые ACL различающиеся только сетью абонентов /24, то у нас 256 ACL, не такая большая беда в общем, но визуально уже трудноуловимо, да и памяти у некоторых устройств уже может не хватать.
Если продолжить масштабировать дальше и представить себе 100 таких устройств… (Цифры беру вовсе не с потолка).
Так что как и в любом деле — разумный компромисс — цена, надёжность, безопасность, масштабируемость, управляемость, профессионализм. У всех по разному получается.
Я в комментарии выше имел в виду немного другое. Не надо со стороны абонентов. Можно на OUT в сторону магистрала. По вашему рисунку это int3. И там это будет не более десятка строк, типа 10.0.0.0/8, 192.168.0.0/16 и т.д. Зачем вам их выпускать в мир?
А если и внутри своих сетей пресекать спуфинг, то можно не плодить эти правила в ядре, нагружая его, можно (если позволяет железо), делать это на доступе, зачем мусор тянуть через всю сеть, когда трафик можно почистить максимально близко к его источнику. Благо доступ давно сильно поумнел, а провайдеры приноровились скриптами творить чудеса автоматизации по настройке этого самого доступа :)
А если и внутри своих сетей пресекать спуфинг, то можно не плодить эти правила в ядре, нагружая его, можно (если позволяет железо), делать это на доступе, зачем мусор тянуть через всю сеть, когда трафик можно почистить максимально близко к его источнику. Благо доступ давно сильно поумнел, а провайдеры приноровились скриптами творить чудеса автоматизации по настройке этого самого доступа :)
Я понял насчёт int3 :) я чуть-чуть аналогию дальше увёл просто. Всё же для провайдера частных абонентов, важнее внутренне спокойствие этих самых абонентов, соответственно надёжность внутренней сети.
А выход в мир, как правило самое простое — потому что стоит хорошее железо — нужно BGP, и память, и трафика много молотить, не надо распыляться на множество интерфейсов — несколько входов, несколько выходов, картинка полностью охватывается и редко меняются условия. С внешней стороны, опять же, качественно управляемые сети, собственно в примерах в статье видно, что при больших объёмах трафика мусора сильно меньше. Конечно, надо обезопасить себя от Интернета и Интернет от себя, но так как это край сети то здесь сходятся большие агрегированные сети, поэтому правил получается меньше при том, что возможности написать много правил существенно больше.
А вот чем глубже в сеть тем интереснее, объёмы трафика на конкретном устройстве меньше, а самих устройств сильно-сильно больше — соответственно устройства дешевеют, по производительности и по возможностям, даже при том что они сильно поумнели, иначе была бы вообще катастрофа. При этом внутренних угроз больше (конечные подключения слабоуправляемые), а средств защиты от них меньше.
З.Ы. При скрипты, кстати, это вообще отдельная песня :)
А выход в мир, как правило самое простое — потому что стоит хорошее железо — нужно BGP, и память, и трафика много молотить, не надо распыляться на множество интерфейсов — несколько входов, несколько выходов, картинка полностью охватывается и редко меняются условия. С внешней стороны, опять же, качественно управляемые сети, собственно в примерах в статье видно, что при больших объёмах трафика мусора сильно меньше. Конечно, надо обезопасить себя от Интернета и Интернет от себя, но так как это край сети то здесь сходятся большие агрегированные сети, поэтому правил получается меньше при том, что возможности написать много правил существенно больше.
А вот чем глубже в сеть тем интереснее, объёмы трафика на конкретном устройстве меньше, а самих устройств сильно-сильно больше — соответственно устройства дешевеют, по производительности и по возможностям, даже при том что они сильно поумнели, иначе была бы вообще катастрофа. При этом внутренних угроз больше (конечные подключения слабоуправляемые), а средств защиты от них меньше.
З.Ы. При скрипты, кстати, это вообще отдельная песня :)
Было время — были вот такие, например, вещи — nag.ru/articles/article/16988/upravlyaem-neupravlyaemyim.html
И уровень мусора был совсем другой. И сети умудрялись быть достаточно большими и даже большую часть времени функционировать, а не лежать.
Сейчас все сильно проще все же.
И уровень мусора был совсем другой. И сети умудрялись быть достаточно большими и даже большую часть времени функционировать, а не лежать.
Сейчас все сильно проще все же.
Стало проще, несомненно, но время ушло пока не очень далеко.
Пару недель назад был на конференции — один из технических докладов:
Пару недель назад был на конференции — один из технических докладов:
Кулибинские решения. Как сделать из неуправляемого коммутатора управляемый и другое.
Sign up to leave a comment.
Что попадает в deny ip any any?