Я понял насчёт int3 :) я чуть-чуть аналогию дальше увёл просто. Всё же для провайдера частных абонентов, важнее внутренне спокойствие этих самых абонентов, соответственно надёжность внутренней сети.
А выход в мир, как правило самое простое — потому что стоит хорошее железо — нужно BGP, и память, и трафика много молотить, не надо распыляться на множество интерфейсов — несколько входов, несколько выходов, картинка полностью охватывается и редко меняются условия. С внешней стороны, опять же, качественно управляемые сети, собственно в примерах в статье видно, что при больших объёмах трафика мусора сильно меньше. Конечно, надо обезопасить себя от Интернета и Интернет от себя, но так как это край сети то здесь сходятся большие агрегированные сети, поэтому правил получается меньше при том, что возможности написать много правил существенно больше.
А вот чем глубже в сеть тем интереснее, объёмы трафика на конкретном устройстве меньше, а самих устройств сильно-сильно больше — соответственно устройства дешевеют, по производительности и по возможностям, даже при том что они сильно поумнели, иначе была бы вообще катастрофа. При этом внутренних угроз больше (конечные подключения слабоуправляемые), а средств защиты от них меньше.
З.Ы. При скрипты, кстати, это вообще отдельная песня :)
Это печально и грустно, я представлю себе ситуацию отлично, просто очень хочется чтобы все друг к другу с уважением относились, а forum.nag.ru нужен был бы, чтобы в обеденный перерыв «за жизнь поговорить».
Про ACL, есть одна беда масштабируемости — пусть у нас 256 интерфейсов на маршрутизаторе с сетями по /24, общая агрегированная сеть значит /16. И если мы блокируем сеть целиком по /16 со стороны абонентов, тогда абонент может заспуфить 65535 адресов, глобально в Интернете это не будет заметно, но провайдер в таком объёме получить ощутимые неприятности внутри своей сети. Т.е. унифицированный ACL для каждого абонентского интерфейса может привести к «китайской» проблеме, вроде всё своё родное, но его так много что не справиться.
Если на каждый интерфейс вешать одинаковые ACL различающиеся только сетью абонентов /24, то у нас 256 ACL, не такая большая беда в общем, но визуально уже трудноуловимо, да и памяти у некоторых устройств уже может не хватать.
Если продолжить масштабировать дальше и представить себе 100 таких устройств… (Цифры беру вовсе не с потолка).
Так что как и в любом деле — разумный компромисс — цена, надёжность, безопасность, масштабируемость, управляемость, профессионализм. У всех по разному получается.
Вполне может быть. Но у нас клиент в основном, это частное лицо — роутер, пару устройств за ним. Так что здесь надо что-то автоматическое и легкодоступное искать, потому что такого добра реально много.
Многие не фильтруют это точно. Как провайдер могу сказать, что когда у тебя в сети автоматическая маршрутизация, то практически с любого линка можно добраться до интернета, причём с любого адреса. Причины — uRPF накладная по производительности вещь и к тому же не каждая железка такое умеет. Уникальные ACL опять же под каждый линк, это организационно сложно и опять же дорого в плане расходования памяти. Конечно ради собственного спокойствия приходится жертвовать, но унификация наше всё.
Так что если провайдер что-то упустил, то лучше его предупредить, пока кто-нибудь не воспользовался и не сделал бяку всем, и провайдеру, и его клиентам и себе в том числе. А уж предупредить, как я выразился в статье «собрата провайдера», если что-то у тебя пошло не так или что-то нашёл странное, это вообще без вопросов должно быть.
Тогда невероятное предположение, если ни src ни dst совсем не близко, тогда возможно кто-то считал ваш адрес маршрутизатором (какая-то виртуальная сеть, как с Hamachi. TOR?), в локальной сети соседа можно по маку посмотреть, он то точно не должен был отличаться разнообразием, чтобы понять хотя бы откуда всё это.
Обычно в случае с провайдерами видны кучами netbios и arp запросы от всех соседей по коммутатору.
Так сложно сказать. Простейшее, что можно предположить — первый кадр прилетающий на коммутатор, с мак адресом не присутствующим в таблице коммутации отправляется на все доступные интерфейсы (это стандартное поведение), тоже происходит при исчерпании таблицы коммутации (здесь надо думать о расширении). Тоже в общем касается и маршрутизаторов, основная задача передать данные, если при этом нам не хватает ресурсов на анализ — тогда передаём данные любой ценой.
В качестве расследования, как мне кажется надо искать общую разделяемую среду, если это облачная инфраструктура значит сервер делит с кем-то физическую сетевую карту и драйвер. Если физическая инфраструктура то общие коммутаторы, маршрутизаторы. Смотрим находимся ли мы с источником или получателем в одной или близкой сети, если запросы реальные то адреса должны быть реальные.
В некоторых моментах очень знакомо, хотя для меня это были разные компании с разным профилем, как у вас это всё сошлось в одном месте…
Жму крепко руку, завидую упорству в достижении целей. Пишите ещё: автоматизация, база знаний — очень хочется увидеть ваш опыт в этом вопросе.
Спасибо всем кто помнит, странно наверное, но у меня просто невозможный детский восторг после того как всё заработало — перепробовал проиграть все файлы до которых добрался :)
Почему так категорично? Иначе быть может — Cisco не воспринимает ничего кроме строгой десятичной записи разделённой точками. Причём запись с ведущими нулями воспринимается также десятичной, а не восьмеричной. Cisco не подчиняется POSIX, что вероятно, но подчиняется RFC, что тоже во многом вероятно.
На мой взгляд это правильно с точки зрения использования, чем меньше потенциальной возможности напортачить — тем лучше, плата — меньше гибкости.
CONFORMING TO
4.3BSD. inet_addr() and inet_ntoa() are specified in POSIX.1-2001. inet_aton() is not specified in POSIX.1-2001, but is available on most
systems.
Обычная практика говорит что это будет работать почти всегда, но не абсолютно всегда. Причём inet_ntoa() преобразует в полную нотацию с 4-мя десятичными октетами и он описан в POSIX.
Справедливости ради и чтобы не повторятся в обсуждениях, вот тут много копий сломали habrahabr.ru/blogs/sysadm/69587
Запись 127.1 не однозначна, на мой взгляд — так и тянет добавить 127.1/16 и читать этот адрес 127.1.0.0
В тексте про exit я упоминал, жутко некрасиво. Про процедуры спасибо, не видел необходимости в достаточно коротком коде выделять процедуры, буду знать — обычно исходил из принципа: «Всё что повторяется два раза выделяем в подпрограмму».
ping 2130707809 — тоже работает, машине всё равно, а вот человеку не очень понятно. Строгая типизация адреса, нужна больше как защита от дурака, а то с получившимся списком можно таких дел натворить.
Да получилось длинновато, каюсь, искание мысли длиннее выражать чем саму мысль.
Здесь же прямой пиринг по IPv6. he.net (точнее даже tunnelbroker.net) как туннельный брокер это в концепции перехода на IPv6 по всему миру — только временная мера.
Слона то я и не приметил, это точно всё работает. Сосредоточился больше на проверке клиентов — из коробки Psi, QIPInfium, Miranda, Pidgin у меня не завелись.
А выход в мир, как правило самое простое — потому что стоит хорошее железо — нужно BGP, и память, и трафика много молотить, не надо распыляться на множество интерфейсов — несколько входов, несколько выходов, картинка полностью охватывается и редко меняются условия. С внешней стороны, опять же, качественно управляемые сети, собственно в примерах в статье видно, что при больших объёмах трафика мусора сильно меньше. Конечно, надо обезопасить себя от Интернета и Интернет от себя, но так как это край сети то здесь сходятся большие агрегированные сети, поэтому правил получается меньше при том, что возможности написать много правил существенно больше.
А вот чем глубже в сеть тем интереснее, объёмы трафика на конкретном устройстве меньше, а самих устройств сильно-сильно больше — соответственно устройства дешевеют, по производительности и по возможностям, даже при том что они сильно поумнели, иначе была бы вообще катастрофа. При этом внутренних угроз больше (конечные подключения слабоуправляемые), а средств защиты от них меньше.
З.Ы. При скрипты, кстати, это вообще отдельная песня :)
Про ACL, есть одна беда масштабируемости — пусть у нас 256 интерфейсов на маршрутизаторе с сетями по /24, общая агрегированная сеть значит /16. И если мы блокируем сеть целиком по /16 со стороны абонентов, тогда абонент может заспуфить 65535 адресов, глобально в Интернете это не будет заметно, но провайдер в таком объёме получить ощутимые неприятности внутри своей сети. Т.е. унифицированный ACL для каждого абонентского интерфейса может привести к «китайской» проблеме, вроде всё своё родное, но его так много что не справиться.
Если на каждый интерфейс вешать одинаковые ACL различающиеся только сетью абонентов /24, то у нас 256 ACL, не такая большая беда в общем, но визуально уже трудноуловимо, да и памяти у некоторых устройств уже может не хватать.
Если продолжить масштабировать дальше и представить себе 100 таких устройств… (Цифры беру вовсе не с потолка).
Так что как и в любом деле — разумный компромисс — цена, надёжность, безопасность, масштабируемость, управляемость, профессионализм. У всех по разному получается.
Многие не фильтруют это точно. Как провайдер могу сказать, что когда у тебя в сети автоматическая маршрутизация, то практически с любого линка можно добраться до интернета, причём с любого адреса. Причины — uRPF накладная по производительности вещь и к тому же не каждая железка такое умеет. Уникальные ACL опять же под каждый линк, это организационно сложно и опять же дорого в плане расходования памяти. Конечно ради собственного спокойствия приходится жертвовать, но унификация наше всё.
Так что если провайдер что-то упустил, то лучше его предупредить, пока кто-нибудь не воспользовался и не сделал бяку всем, и провайдеру, и его клиентам и себе в том числе. А уж предупредить, как я выразился в статье «собрата провайдера», если что-то у тебя пошло не так или что-то нашёл странное, это вообще без вопросов должно быть.
Обычно в случае с провайдерами видны кучами netbios и arp запросы от всех соседей по коммутатору.
В качестве расследования, как мне кажется надо искать общую разделяемую среду, если это облачная инфраструктура значит сервер делит с кем-то физическую сетевую карту и драйвер. Если физическая инфраструктура то общие коммутаторы, маршрутизаторы. Смотрим находимся ли мы с источником или получателем в одной или близкой сети, если запросы реальные то адреса должны быть реальные.
Жму крепко руку, завидую упорству в достижении целей. Пишите ещё: автоматизация, база знаний — очень хочется увидеть ваш опыт в этом вопросе.
На мой взгляд это правильно с точки зрения использования, чем меньше потенциальной возможности напортачить — тем лучше, плата — меньше гибкости.
Приведённый вами участок описывает inet_aton(), а далее по тексту:
CONFORMING TO
4.3BSD. inet_addr() and inet_ntoa() are specified in POSIX.1-2001.
inet_aton() is not specified in POSIX.1-2001, but is available on most
systems.
Обычная практика говорит что это будет работать почти всегда, но не абсолютно всегда. Причём inet_ntoa() преобразует в полную нотацию с 4-мя десятичными октетами и он описан в POSIX.
Я не зря привёл запись 127.1/16 == 127.1.0.0/16, это встречается довольно часто. На вскидку, juniper подразумевает именно в этом смысле: www.juniper.net/techpubs/software/junos-es/junos-es92/junos-es-swconfig-interfaces-and-routing/ipv4-addressing.html — в разделе IPv4 Variable-Length Subnet Masks есть запись вида 192.14.17/24, в смысле сети 192.14.17.0/24, а никак не адреса 192.14.0.17/24.
Запись 127.1 не однозначна, на мой взгляд — так и тянет добавить 127.1/16 и читать этот адрес 127.1.0.0
Да получилось длинновато, каюсь, искание мысли длиннее выражать чем саму мысль.