Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 141
Спасибо за статью.
Однако Вы забыли выложить исходник для этого:
Однако Вы забыли выложить исходник для этого:
gcc -Wall -o expl expl-goahead-camera.c
Первая ссылка в гугле
За что минусим, товарищи? Обленились совсем?
Первая ссылка в гугле (понимаю, что у каждого он свой немного, но у меня так) показывает статью, а в статье прямая ссылка на файл https://pierrekim.github.io/advisories/ expl-goahead-camera.c
Первая ссылка в гугле (понимаю, что у каждого он свой немного, но у меня так) показывает статью, а в статье прямая ссылка на файл https://pierrekim.github.io/advisories/ expl-goahead-camera.c
Одно расстраивает — сейчас к сожалению большинство таких устройств находятся за NAT и посему — достаточно труднодоступны. Но когда IPv6 наконец-то победит — все эти устройства получат реальные IP и вот тогда-то начнется настоящее веселье…
Сейчас провайдер выдаёт каждому клиенту подсеть /64. А роутеры выдают адреса клиентам, используя рандомизацию (маловероятно, что кто-то руками настраивает статические адреса).
И вместо статей по обходу NAT, будут статьи по «быстрому» сканированию подсети /64 или по угадыванию выхода генератора псевдослучайных чисел.
И вместо статей по обходу NAT, будут статьи по «быстрому» сканированию подсети /64 или по угадыванию выхода генератора псевдослучайных чисел.
Роутеры не выдают непосредственно адреса если настроены в stateless режиме, а только анонсируют старшие 64 бита адреса в lan сегмент. А дальше уже от клиента зависит как он сгенерирует свой адрес: windows сделает рандомизацию, а большинство линуксов в т.ч. embedded соберут адрес из мака сетевого интерфейса по методу eui64.
Если же роутер в стейтфул режиме (dhcpv6) то как правило конфигурируется пул адресов с ::1 по ::1000 также как и в ipv4.
Я хочу сказать, что просто смена версии ip протокола не увеличит безопасность устройств. Потребитель умных девайсов должен сам заботится о своей безопасности, хотябы установив statefull firewall перед девайсами у себя дома.
Если же роутер в стейтфул режиме (dhcpv6) то как правило конфигурируется пул адресов с ::1 по ::1000 также как и в ipv4.
Я хочу сказать, что просто смена версии ip протокола не увеличит безопасность устройств. Потребитель умных девайсов должен сам заботится о своей безопасности, хотябы установив statefull firewall перед девайсами у себя дома.
Понятно. Т.е. пространство перебора сужается до количества произведённых устройств (узнаём mac-префиксы интересующих вендоров, узнаём по каждому, сколько mac-ов уже выдано в суффиксе 224). Всё равно, сканирование нужно намного большее, чем для сетей ipv4.
А дальше уже от клиента зависит как он сгенерирует свой адрес: windows сделает рандомизацию, а большинство линуксов в т.ч. embedded соберут адрес из мака сетевого интерфейса по методу eui64.
Не делает рандомизацию, а использует privacy extensions (rfc4941) и не «windows делает, а линукс не делает», а так как включено в ОС\Network Manager по умолчанию.
Абсолютное большинство роутеров блокируют внешние соединения.
Первый совет ЛЮБОЙ техподдержки, в ЛЮБОЙ ситуации — «отключите антивирус и фаервол». 95% ему следуют и забывают включить обратно как минимум фаервол.
Вся проблема фаервола, в том что его можно отключить и все будет работать. С NAT такое не проходит. :)
Вся проблема фаервола, в том что его можно отключить и все будет работать. С NAT такое не проходит. :)
Фаерволл отключают на компьютере, при чём тут роутер? Для IPv6 действительно блокируется входящий трафик, ну и NAT никогда нельзя считать аналогом защиты, про это писалось многократно. Недоступность извне — это лишь небольшой побочный и не слишком надёжный эффект.
NAT выполняет некоторые базовые функции защиты, конкретно — не дает возможности устанавливать входящие соединения на компьютеры в сети.
Кстати, немного офтопика — Cisco ASA устройство защиты сети? Однозначно! Вспомните на каких принципах оно функционирует…
Это «небольшой побочный и не слишком надежный эффект» одним махом отсекает кучу векторов атаки. Чтоб далеко не ходить — большинство атак, обсуждаемых в данной статье, работают только если камера имеет внешний IP или сеть уже скомпроментирована — злоумышленник имеет доступ внутрь нее.
Я хочу вас разочаровать — на роутерах тоже. Простой юзер давно запомнил — фаервол это такая ненужная вещь, которая мешает ему пользовать торренты и сетевые игры и постоянно задает какие-то глупые (то есть — непонятные) вопросы. И это первое что надо отключить. :) И ВСЕ службы техподдержки, любого продукта — настойчиво укрепляют его в этом заблуждении. Если хочешь чтоб ничего не работало — включи фаервол!
И хоть каких-то подвижек, чтоб переломить эту ситуацию — нет и не предвидется. Фаерволы — слишком «тупые», их надо тщательно настраивать чтоб от них была польза. Что простого юзера категорически не устраивает.
Фаервол — слишком низкоуровневая штука для обычного юзверя, требует слишком много знаний для своей грамотной настройки. Которых у рядового юзверя нет и никогда не будет. Тут скорей больше пользы от IDS/IPS — их хотя бы в теории можно преднастроить так чтоб они были не менее гиморойны в использовании для обычного юзверя чем антивирус.
Кстати, немного офтопика — Cisco ASA устройство защиты сети? Однозначно! Вспомните на каких принципах оно функционирует…
Это «небольшой побочный и не слишком надежный эффект» одним махом отсекает кучу векторов атаки. Чтоб далеко не ходить — большинство атак, обсуждаемых в данной статье, работают только если камера имеет внешний IP или сеть уже скомпроментирована — злоумышленник имеет доступ внутрь нее.
Фаерволл отключают на компьютере, при чём тут роутер?
Я хочу вас разочаровать — на роутерах тоже. Простой юзер давно запомнил — фаервол это такая ненужная вещь, которая мешает ему пользовать торренты и сетевые игры и постоянно задает какие-то глупые (то есть — непонятные) вопросы. И это первое что надо отключить. :) И ВСЕ службы техподдержки, любого продукта — настойчиво укрепляют его в этом заблуждении. Если хочешь чтоб ничего не работало — включи фаервол!
И хоть каких-то подвижек, чтоб переломить эту ситуацию — нет и не предвидется. Фаерволы — слишком «тупые», их надо тщательно настраивать чтоб от них была польза. Что простого юзера категорически не устраивает.
Фаервол — слишком низкоуровневая штука для обычного юзверя, требует слишком много знаний для своей грамотной настройки. Которых у рядового юзверя нет и никогда не будет. Тут скорей больше пользы от IDS/IPS — их хотя бы в теории можно преднастроить так чтоб они были не менее гиморойны в использовании для обычного юзверя чем антивирус.
NAT выполняет некоторые базовые функции защиты, конкретно — не дает возможности устанавливать входящие соединения на компьютеры в сети.
Это не так. Сам NAT никак не препятствует установлению соединений с компьютерами внутри сети. За это отвечает как раз и только фаервол.
NAT препятствует самой своей сутью — внешние соединения устанавливаются с определенным портом роутера, который сам роутер перенаправляет на внутренний адрес/порт. В этом смысле NAT блокирует все внешние соединения — инициатором всегда должн выступать узел внутренней сети.
Нет, не препятствует. Зная адресацию внутренней подсети, злоумышленик может указать WAN адрес роутера как шлюз для этих внутренних адресов и благополучно будет к ним обращаться, если не настроен фаервол.
Да, конечно, злоумышленик должен быть в той же сети, что и WAN-порт роутера, но сути это не меняет, NAT ничему не препятствует сам по себе. Это не его задача.
Да, конечно, злоумышленик должен быть в той же сети, что и WAN-порт роутера, но сути это не меняет, NAT ничему не препятствует сам по себе. Это не его задача.
благополучно будет к ним обращаться
Reverse Path Filter
Ну то есть Вы тоже пришли к пониманию, что NAT сам по себе ничему не препятствует и нужны дополнительные средства фильтрации. ЧТД.
NAT не препятствует, он не обеспечивает возможности форвардить внешнее соединение, а по умолчанию эта возможность заблокирована с помощью Reverse Path Filter, поэтому дополнительный фаервол при наличии NAT не является необходимым.
Мне это разжевать еще подробнее или вы будете продолжать выделываться в стиле «дверь сама по себе ничему не препятствует, нужны стены»?
Мне это разжевать еще подробнее или вы будете продолжать выделываться в стиле «дверь сама по себе ничему не препятствует, нужны стены»?
Разжуйте, будьте любезны уж. Особенно как reverse filter будет фильтровать IP в случае ситуации, описанной мною. Объясню на пальцах:
Ваш роутер имеет два порта: wan и lan. на wan ip, предположим, 7.7.7.100/24, на LAN 192.168.0.1/24. Фаервола нет, есть rp filter и NAT 192.168.0.0/24->7.7.7.100.
Злоумыленик в той же локалке, что и WAN порт роутера. У злоумышленика один интерфейс с адресом 7.7.7.200/24. Злоумышленик прописывает у себя
ip route add 192.168.0.0/24 via 7.7.7.100. После чего обращается на 192.168.0.2.
Будьте любезны разжевать, что именно воспрепятствует нашему роутеру заблокировать пакеты межу 7.7.7.200 и 192.168.0.2?
Для справки rp filter фильрует только пакеты, у которых адрес отправителя не соотвествует сети на порту. В нашем случаее это условие нигде не нарушается.
И не хамите. Недостаток знаний сам по себе проблемой не является, а вот Ваше упорство при недостатке знаний очень даже.
Ваш роутер имеет два порта: wan и lan. на wan ip, предположим, 7.7.7.100/24, на LAN 192.168.0.1/24. Фаервола нет, есть rp filter и NAT 192.168.0.0/24->7.7.7.100.
Злоумыленик в той же локалке, что и WAN порт роутера. У злоумышленика один интерфейс с адресом 7.7.7.200/24. Злоумышленик прописывает у себя
ip route add 192.168.0.0/24 via 7.7.7.100. После чего обращается на 192.168.0.2.
Будьте любезны разжевать, что именно воспрепятствует нашему роутеру заблокировать пакеты межу 7.7.7.200 и 192.168.0.2?
Для справки rp filter фильрует только пакеты, у которых адрес отправителя не соотвествует сети на порту. В нашем случаее это условие нигде не нарушается.
И не хамите. Недостаток знаний сам по себе проблемой не является, а вот Ваше упорство при недостатке знаний очень даже.
Для ситуации, когда компьютер злоумышленника находится в той же самой подсети, что и роутер жертвы, а соединения между узлами сети не запрещены — да, можно попытаться прописать gateway. Редкая вырожденная ситуация, которую вероятно можно встретить в каких-нибудь студенческих общежитиях с самопальной сетью.
… и дальше очередное хамское предложение с переходом на личности в ключе рассказа «Срезал».
Всего хорошего.
И не хамите.
… и дальше очередное хамское предложение с переходом на личности в ключе рассказа «Срезал».
Всего хорошего.
Забейте — наш опонент очевидно что линаксоид. А у этой публики очень специфичные и в корне неверные представления о сетях…
Задачка «нужно ли настраивать FORWARD фаерволла, если есть NAT?» задачка из «курсов начинающих сетевиков» различных вендоров. И только недотеоретики спорят с моим вариантом ответа. Ибо NAT by design не фильтрующее средство, а как раз средство обеспечения связности.
Возmмем классическое устройство обеспечения безопасности сетей — Cisco ASA… Ну ты понял, линаксоид, да? :)
Нет, не понял. Что в асе\циско вообще не соотвествует тому, что я написал?
Я уточню свой вопрос, а то Вам с Вашей кармой, вызванной вероятно, манерой изъясняться, комментарии редко доступны.
То, что циска назвала фаервол access list никак не меняет его сути. Вам и в циске необходимо кроме непосредственно трансляции адресов (NAT, указания подсети из которой транслировать и IP\подсети, в которую транслировать) указывать отдельно какой откуда траф пропускать или нет. И, даже, если я ошибаюсь (сужу по их официальной документации ). У меня два вопроса:
1) При чем тут вообще ASA\Cisco? Мы разговариваем про NAT вообще, а не его исполнение у конкретного, в случае SOHO (про что данная статья), крайне редкого вендора.
2) Покажите мне в RFC про NAT (3022 или аналогичное) хоть какие-то слова про фильтрацию? Их нет. Ибо NAT — это трансляция адресов, но никак не фильтрация.
То, что циска назвала фаервол access list никак не меняет его сути. Вам и в циске необходимо кроме непосредственно трансляции адресов (NAT, указания подсети из которой транслировать и IP\подсети, в которую транслировать) указывать отдельно какой откуда траф пропускать или нет. И, даже, если я ошибаюсь (сужу по их официальной документации ). У меня два вопроса:
1) При чем тут вообще ASA\Cisco? Мы разговариваем про NAT вообще, а не его исполнение у конкретного, в случае SOHO (про что данная статья), крайне редкого вендора.
2) Покажите мне в RFC про NAT (3022 или аналогичное) хоть какие-то слова про фильтрацию? Их нет. Ибо NAT — это трансляция адресов, но никак не фильтрация.
Для начала пожалуйста запомните — access list это НЕ firewall!!!!!!!!!!!! Уж простите, но за такие фразу возникает желание УБИВАТ!!! :)
Не разумеется топором можно забивать гвозди, но это не повод называть его молотком.
Если вам реально интересно — можем поговорить об access list в Cisco в другом, более удобном месте. Это средство управления потоками данных, а не фаервол. Чтоб понять отличие — посмотрите как описывается тот же NAT в Cisco. А заодно — route map, ipsec и т.д. — везде невозможно обойтись без access list-ов, которыми ты разделяешь трафик, требующих некоторых действий и трафик, который этим действиям подвергаться не должен.
При том что Cisco ASA — очень прикольное и специфическое устройство, его еще называю NAT device ибо там все строится вокруг NAT — куда не ткнешься, упрешься в NAT. Он имеет функции маршрутизатора, но полноценным маршрутизатором не является, к слову так. Вообщем если говоришь о NAT то обойти устройство, где NAT возведен в абсолют, является базовой технологий, где она получила наибольшее развитие — не получится имхо.
А кто сказал что полноценный firewall это обязательно фильтрация? Cisco ASA — классический пример реализации фаервола, основанного на трансляции. :) Нет трансляции — нет коннекта. Есть трансляция — возможно коннект и будет, если остальные условия позволяют. Ну разумеется не коннекта, а прохождение пакета… но это не принципиально.
Именно возня с Cisco ASA дает осознание того факта что этим топором (NAT который) можно не только дрова рубить (раздавать интернеты на приватные адреса), но и целые Кижи построить (ту же сеть для сертификации по PCI DSS). :)
Для полного запутывания ситуации — в Cisco ISR фаервол, тот который ZBFW, основан на фильтрации, ога. Но он считается менее надежным и сеть, защищенную им, на тот же PCI DSS никогда не специфицируют. :)
Не разумеется топором можно забивать гвозди, но это не повод называть его молотком.
Если вам реально интересно — можем поговорить об access list в Cisco в другом, более удобном месте. Это средство управления потоками данных, а не фаервол. Чтоб понять отличие — посмотрите как описывается тот же NAT в Cisco. А заодно — route map, ipsec и т.д. — везде невозможно обойтись без access list-ов, которыми ты разделяешь трафик, требующих некоторых действий и трафик, который этим действиям подвергаться не должен.
При чем тут вообще ASA\Cisco? Мы разговариваем про NAT вообще
При том что Cisco ASA — очень прикольное и специфическое устройство, его еще называю NAT device ибо там все строится вокруг NAT — куда не ткнешься, упрешься в NAT. Он имеет функции маршрутизатора, но полноценным маршрутизатором не является, к слову так. Вообщем если говоришь о NAT то обойти устройство, где NAT возведен в абсолют, является базовой технологий, где она получила наибольшее развитие — не получится имхо.
Покажите мне в RFC про NAT (3022 или аналогичное) хоть какие-то слова про фильтрацию? Их нет. Ибо NAT — это трансляция адресов, но никак не фильтрация.
А кто сказал что полноценный firewall это обязательно фильтрация? Cisco ASA — классический пример реализации фаервола, основанного на трансляции. :) Нет трансляции — нет коннекта. Есть трансляция — возможно коннект и будет, если остальные условия позволяют. Ну разумеется не коннекта, а прохождение пакета… но это не принципиально.
Именно возня с Cisco ASA дает осознание того факта что этим топором (NAT который) можно не только дрова рубить (раздавать интернеты на приватные адреса), но и целые Кижи построить (ту же сеть для сертификации по PCI DSS). :)
Для полного запутывания ситуации — в Cisco ISR фаервол, тот который ZBFW, основан на фильтрации, ога. Но он считается менее надежным и сеть, защищенную им, на тот же PCI DSS никогда не специфицируют. :)
Спасибо, познавательно. В любом случае реализация NAT у отдельного вендора в контексте данной статьи представляет интерес сугубо теоретический. Большинство устройств (а я таки смею заявлять, что для обеспечения безопасности камер, о которой ведется речь в статье, в большинстве случаев будут использоваться linux-based решения) реализуют NAT согласно RFC и следовательно никакой фильтрации не обеспечивают.
а я таки смею заявлять, что для обеспечения безопасности камер, о которой ведется речь в статье, в большинстве случаев будут использоваться linux-based решения
Так, вы присядьте пожалуйста… Сели? Крепко сидите? Шок будет сильным, но вы там держитесь...:) Так вот, Cisco ASA это linux-based решение! У нее унутри
И она «реализует NAT согласно RFC» — просто надо внимательно читать RFC. :) Hint — в RFC нигде не говориться что один из транслируемых адресов обязательно должен быть приватным. :) Как только приходит понимание этого простого факта — взгляды на NAT кардинально меняются :)
Я скачу более — для обеспечения безопасности NAT предпочтительней классической фильтрации. Дело в том что как не крути, но фильтрация по умолчанию подразумевает прохождение пакета. Да разумеется все фаерволы на фильтрации имеют конфигурацию в стили deny any any, но… это именно конфигурация — отключи фильтрацию и сеть станет открытой. NAT же по умолчанию подразумевает непрохождение пакета, нету трансляции — нету пакета. Отключи NAT и сеть окажется полностью блокированной. И кстати сделать глупость в стиле прописывания allov any any в них гораздо сложней. :) Именно поэтому все серьезные фаерволы строятся на основе NAT.
Вы почитайте что я пишу в соседних комментах. Мы с товарищами разобрали мой пример «обхода» NAT, так вот, он как раз работает, потому, что NAT для соединения извне не используется. Именно поэтому фильтрация как таковая, помимо трансляции необходима, будь фильтрация встроена в NAT, как в cisco или нет, как в netfilter в линуксе.
NAT для соединения извне не используется
Вы путаете две вещи — полноценную реализацию NAT и крайне кастрированную версию стандартной реализации оного в линаксе. Кратко — NAT используется ВСЕГДА — http://www.cisco.com/c/en/us/support/docs/ip/network-address-translation-nat/6209-5.html И это — не ASA, а обычный роутер. ASA все еще жестче — либо через NAT, либо никак, просто нет иных механизмов прохождения пакета.
Действительно ли это нат, либо же это отслеживание состояния соединений (connection tracking, stateful firewall)? Не имел дел с оборудованием Cisco, но звучит странно. Т.е. это устройство не умеет просто маршрутизировать пакеты, обязательно подвергает их трансляции?
Опять же. Учитывая контекст в частности и распространенность линуксов вообще, а так же описание NAT в RFC — это вы путаете что такое NAT в общем и его конкретную реализацию у конкретного вендора (cisco). Тем более то, что в линуксе он «кастрированный» — это только ваше частное мнение. Мне вот кажется, что это в cisco (если конечно верить вашим словам о том, как это там устроено) совершенно зря вместе наворотили то, что наворачивать вместе не надо было. И то как работает conntrack мне нравится намного больше, чем то, что вы описываете в cisco.
Учитывая контекст в частности и распространенность линуксов вообще
~2/3 активного сетевого оборудования интернета — произведено Cisco. Так что вопрос о распространенности можно считать закрытым — есть IP-сети в понимании Cisco и прочие неверные представления об IP-сетях. :)
Немного оффтопика
Cisco удалось создать уникальную систему сертификации и обучения. Оно не учит работе с оборудованием Cisco — оно учит работе с IP-сетями. Это такой вендор-лок, который им удалось вывести на принципиально иной уровень — ты либо работаешь с сетью так, как считает правильным Cisco, либо… ты не можешь работать с сетью. И абсолютно неважно твое мнение — есть сетевой инженер с сертификатом Cisco и других сетевых инженеров — просто нет. Даже если ты не работаешь с оборудованием Cisco — ты обязан иметь сертификацию Cisco, чтоб тебя называли сетевым инженером. :)
Мне вот кажется, что это в cisco (если конечно верить вашим словам о том, как это там устроено) совершенно зря вместе наворотили то, что наворачивать вместе не надо было.
Может я криво объяснил… но в Cisco это сделано изящно, эффективно и безопасно. В отличие от ужаса под названием netfilter/iptables. Лучше чем слушать мои объяснения, которые я пытаюсь впихнуть в жалкие объемы поста — почитайте доки и запустите образ от ASA в каком-нибуть QEMU — потыкайте в него пальцем. В конце-концов GNS вам в помощь. :)
А я думал это сказки про напыщенных кошководов-сказочников, про которые не раз слышал на курсах сетевиков (как общих, так и других вендоров) (не стал изучать циско, ибо считаю совершенно гипертрофированно высоким соотношение цены и качества; а пообщавшись с Вами и почитав, благодаря Вам, документацию циски, еще и понял, что оно достатчно криво). А нет, вы действительно существуете. Я думаю дальнейшая дискуссия с вами бесполезна, поэтому я из нее ухожу.
Одно прошу, не рассказывайте таки вне сообщества кошководов про NAT, который можно без фаервола. Люди, которые имели наглость не использовать циску, потом могут вас послушать и настроить NAT без фаервола, оставив доступ во внутренюю сеть.
Одно прошу, не рассказывайте таки вне сообщества кошководов про NAT, который можно без фаервола. Люди, которые имели наглость не использовать циску, потом могут вас послушать и настроить NAT без фаервола, оставив доступ во внутренюю сеть.
не стал изучать циско
То есть — вы не являетесь сетевым инженером и не понимаете как строить IP-сети. :) Так рекомендую — послушайте тех, кто разбирается в IP-сетях. :)
Одно прошу, не рассказывайте таки вне сообщества кошководов про NAT, который можно без фаервола.
Вы так ничего и не услышали. А все потому что вы не понимаете что такое NAT и смотрите на него с позиций, основанных на знании убогой и кастрированной реализации оного в линаксе.
Кратко — NAT для ограничения доступа сети надежней фаервола. Потому что если отключить фаервол (например в результате атаки) — сеть станет полностью открытой и доступной, если отключить NAT — сеть станет полностью недоступной. :) Кроме того что он более надежен — он требует меньше ресурсов, а следовательно — в разы устойчив к атакам типа DDoS.
Хотя и это не совсем корректно — современный фаервол это NAT :)
А фильтрация… ну классическая — по протоколу/порту, в современных фаерволах не применяется — это функции возлагаются на трансляцию, как менее ресурсоемкую и более надежную. Фильтрация осуществляется только на основе данных DPI, но это уже ближе к IDS/IPS чем к классическим фаерволам. :) Хотя опять же — классические фаерволы (в понимании линаксоида) в местах где нужна серьезная защита давно не используются, ибо устаревшая, ресурсоемкая и ненадежная технология.
Вы этот ASA с NAT-ом преподносите, как средство для всех сетевых решений (сравнивая его с линусками и микротиками).
Но всему своё место. Глупо ставить специализированный firewall Cisco ASA у себя дома для раздачи WiFi на 2 планшета и ноут. Также глупо ставить его аплинком в сети провайдера, куда ставят Mikrotik Cloud Core или Cisco Catalyst, где NAT ASA просто захлебнётся от потока (что ни говори, обычный stateless роутинг производительнее, чем NAT, потому что не требует отслеживания каждого соединения). Тут аргумент насчёт DDoS выглядит неубедительно.
Но всему своё место. Глупо ставить специализированный firewall Cisco ASA у себя дома для раздачи WiFi на 2 планшета и ноут. Также глупо ставить его аплинком в сети провайдера, куда ставят Mikrotik Cloud Core или Cisco Catalyst, где NAT ASA просто захлебнётся от потока (что ни говори, обычный stateless роутинг производительнее, чем NAT, потому что не требует отслеживания каждого соединения). Тут аргумент насчёт DDoS выглядит неубедительно.
facepalm.jpg
Смешались в кучу кони, люди…
Ты и коммутаторы, и фаерволы, и какие-то сохо-железки, тот же микротык…
Опять же Cisco ASA я привожу только как пример девайса для защиты сети, реализация которого основывается на NAT, не более того. В пику глупым утверждением что NAT не обеспечивает защиты — только фаервол. Вот вам — обеспечивает. И получше чем iptables — классический пример негодной реализации фаервола имхо. :)
Все бредовые утверждения «NAT не обеспечивает защиты» основаны на одном-единственном недоразумении — автоматическое создание трансляций. Ну да, наверно это механизм можно как-то надурить — автоматы они глупые. Но пока что все примеры такого обдуривания основаны на весьма специфических условиях, достижимых в лаборатории, но не встречающихся в реальной жизни.
И самое главное — отключите этот механизм, нигде не сказано что он — неотъемлемая часть NAT, и получите прекрасный, очень малоресурсуемкий и надежный механизм защиты сети — NAT. :)
Что в линаксе не получается? Ну так это проблема реализации в одной ОС, занимающей ~1% рынка — то же мне проблема. :)
Смешались в кучу кони, люди…
Ты и коммутаторы, и фаерволы, и какие-то сохо-железки, тот же микротык…
Опять же Cisco ASA я привожу только как пример девайса для защиты сети, реализация которого основывается на NAT, не более того. В пику глупым утверждением что NAT не обеспечивает защиты — только фаервол. Вот вам — обеспечивает. И получше чем iptables — классический пример негодной реализации фаервола имхо. :)
Все бредовые утверждения «NAT не обеспечивает защиты» основаны на одном-единственном недоразумении — автоматическое создание трансляций. Ну да, наверно это механизм можно как-то надурить — автоматы они глупые. Но пока что все примеры такого обдуривания основаны на весьма специфических условиях, достижимых в лаборатории, но не встречающихся в реальной жизни.
И самое главное — отключите этот механизм, нигде не сказано что он — неотъемлемая часть NAT, и получите прекрасный, очень малоресурсуемкий и надежный механизм защиты сети — NAT. :)
Что в линаксе не получается? Ну так это проблема реализации в одной ОС, занимающей ~1% рынка — то же мне проблема. :)
Не понял про автоматическое создание.
В линуксах есть правила. Например, создавай трансляцию, если пакет из локальной сети с такого-то IP (или подсети) передаётся в WAN на такую-то подсеть (или на любой адрес).
В цисках не так? Там каждую трансляцию вручную надо прописывать?
— Товарищь майор, можно мне в Гугл?
— Да, можно, но только один tcp-коннект. Твой внешний адрес будет 7.7.7.100, исходящий порт 22001. Выполнять!
В линуксах есть правила. Например, создавай трансляцию, если пакет из локальной сети с такого-то IP (или подсети) передаётся в WAN на такую-то подсеть (или на любой адрес).
В цисках не так? Там каждую трансляцию вручную надо прописывать?
— Товарищь майор, можно мне в Гугл?
— Да, можно, но только один tcp-коннект. Твой внешний адрес будет 7.7.7.100, исходящий порт 22001. Выполнять!
Не совсем. Для начала осознай что это средство защиты сети, а не хоста. Теперь представь себе что единственный вариант прохождения пакетов между интерфейсами устройства защиты сети — через NAT, остальные — отключены. И теперь забуть про трансляцию приватных адресов в реальные, не важно — реальные в реальные тоже транслируются. :)
Начинаешь осознавать как это работает? :)
Начинаешь осознавать как это работает? :)
Теперь представь себе что единственный вариант прохождения пакетов между интерфейсами устройства защиты сети — через NAT, остальные — отключены.Внезапно, отключаем роутинг на линуксах/микротиках и получаем Cisco ASA?
Пока это всё выглядит как выкачивание бабла. В этой железке отрубим роутинг, назовём её сетевым экраном. А в другой железке отрубим NAT, назовём её роутером.
Внезапно, вы вообще в курсе что такое роутинг? Собственно железка может исполнять роль роутера и при этом — не использовать роутинг для маршрутизации пакетов между своими интерфейсами.
Вы меня троллите? Роутинг — передача пакета между интерфейсами устройства без изменения пакета (в отличие от NAT) по определённым правилам, которые могут задаваться либо маршутами, либо ещё как-то.
Не считая изменения системных полей пакета, типа TTL.
Не считая изменения системных полей пакета, типа TTL.
Роутинг — передача пакета между интерфейсами устройства без изменения пакета (в отличие от NAT) по определённым правилам, которые могут задаваться либо маршутами, либо ещё как-то.
facepalm.jpg
А ведь я так и знал. :) Даже не знаю и с чего начать, но кратко — ваше определение роутинга в корне не верно. Чтоб это понять ответьте на простой вопрос — что делают все протоголы роутинга, не важно какой — RIP. OSPF, BGP. Какое их назначение? :)
У вас зашоренность, а не facepalm. Я вам объясняю, что такое роутинг в самом общем виде, а вы всей картины не видите, упёрлись в алгоритмы для обеспечения роутинга в частных случаях.
Ведь роутинг можно сделать на статических маршрутах, без BGP, OSPF. От этого он не перестанет быть роутингом.
Ведь роутинг можно сделать на статических маршрутах, без BGP, OSPF. От этого он не перестанет быть роутингом.
Вы там держитесь. У Вас на другом конце провода оппонент, который видит мир через призму решений одного вендора. Решения эти он возводит в абсолют и считает правильными (Cisco диктует в RFC, а не RFC в Cisco). В общем гремучая смесь недалекого фанатика с зачатками тролля. Дискуссия бессмысленна.
Cisco диктует в RFC, а не RFC в Cisco
Посмотрите кто пишет RFC… Это будет внезапно, ога. :)
google://cisco site:https://tools.ietf.org дает примерно 26 000 вхождений.
google://lucent site:https://tools.ietf.org дает примерно 22 500 вхождений.
google://juniper site:https://tools.ietf.org дает примерно 29 400 вхождений.
google://linux site:https://tools.ietf.org дает примерно 3 670 вхождений.
google://microsoft site:https://tools.ietf.org дает примерно 8 090 вхождений.
Это все что надо знать о значимости линакса в области стандартизации интеренетов. :)
Понятно. Видим мир сквозь того как это реализовано в одной ОС с распространенностью ~ 1%
Придется начать с определения…
В сетях, а не в устройстве!!! По определению!
Более того, я раскрою вам небольшой секрет — передачей пакетов между интерфейсами во всех сетевых устройствах, всех вендоров — это отдельный, коммутационный процесс, forwarding или switching (для L3 Switch).
От этого и танцуйте — от сети, а не от того что происходит внутри устройства. Когда научите так мыслить — можете начинать изучать сетевые протоколы.
Придется начать с определения…
Маршрутизация (англ. Routing) — процесс определения маршрута следования информации в сетях связи.
В сетях, а не в устройстве!!! По определению!
Более того, я раскрою вам небольшой секрет — передачей пакетов между интерфейсами во всех сетевых устройствах, всех вендоров — это отдельный, коммутационный процесс, forwarding или switching (для L3 Switch).
От этого и танцуйте — от сети, а не от того что происходит внутри устройства. Когда научите так мыслить — можете начинать изучать сетевые протоколы.
Ага, отлично. Если вы в этом смысле, то это у вас
потому что здесь
Смешались в кучу кони, люди…
потому что здесь
отключите этот механизм, нигде не сказано что он — неотъемлемая часть NATвы что подразумеваете — не на устройстве отключить, а во всей сети глобально? ))) Вы так умеете?
вы что подразумеваете — не на устройстве отключить, а во всей сети глобально?
Прекратите принимать анонсы сетей — и это будет равнозначно отключению роутинга. По крайней мере это устройство перестанет видеть что в сети существует какой-то роутинг. :)
А блин… Последняя попытка объяснить — вы в корне неправильно думаете для сетевого инженера. :) Вы рассматриваете что происходит в отдельном устройстве, а это — абсолютно не важно. Надо думать о том что происходит в масштабах сети. Вот когда научитесь думать в масштабах сети — тогда поймете о чем вам говорит сетевой инженер. :)
Для решения моих задач мне не нужно быть сетевым инженером, или думать за весь интернет. Я конфигурирую конкретное устройство (устройства), и это необходимый набор действий для решения задачи. Витая в облаках, не снисходя до железок, ничего не настроишь.
Первична — сеть и соответственно — процессы, происходящие в сети. Без их понимания — конкретную железку корректно настроить не получится. Именно потому что она существует не сама по себе, а как часть сети.
Когда попытаетесь управлять хотя бы небольшой сетью, хотя бы — с несколькими десятками маршрутизаторов — поймете о чем я.
Когда попытаетесь управлять хотя бы небольшой сетью, хотя бы — с несколькими десятками маршрутизаторов — поймете о чем я.
Конкретно для сабжевой задачи важнее знать не «теорию», типа «NAT — самое лучшее решение в области сетевой безопасности», а практику — «в mikrotik разрешены входящие соединения за NAT, которые инициируются из подсети внешнего интерфейса»
То есть из за уязвимости одного малозначительного и малораспостраненого вендора ( google://mikrotik site:https://tools.ietf.org — аж 26 упоминаний) вы делаете общий вывод «NAT не является средством защиты сети»?
И после этого эти люди говорят о том что у меня — жесткий вендор лок… Ну да, конечно же! :)
И после этого эти люди говорят о том что у меня — жесткий вендор лок… Ну да, конечно же! :)
Какой уязвимости? Если вы не понимаете, что происходит, то изучать надо, а не лепить вердикты.
Какой уязвимости?
Логические. Из-за неверной/неполной реализации протоколов.
В линуксах всё верно и полно. Кастрированное устройство — это Cisco ASA, если оно в роутинг не может.
Ну да, конечно же! :)
Полная… в рамках убогого понимания протоколов линаксоидами… До сих пор не забуду спор с одним «kernel hackers», который утверждал что «размер пакета TCP/IP (sic!!!) не может превышать 1500 байт» И эти люди реализуют сетевую подсистему линакса… Верно и полно… Ну да, конечно же!
Ребята, вы — анукеи. Продвинутые, но все равно анукеи. И чтоб вам стать инженерами — вам надо долго и нудно учиться. И начинать с азов, типа того что такое маршрутизация и зачем она нужна. И самое главное — забыть все что вы усвоили «о сетях» из линакса как страшный сон. Изучать сети по линаксу, это все равно что начать изучать программирование с бейсика.
Полная… в рамках убогого понимания протоколов линаксоидами… До сих пор не забуду спор с одним «kernel hackers», который утверждал что «размер пакета TCP/IP (sic!!!) не может превышать 1500 байт» И эти люди реализуют сетевую подсистему линакса… Верно и полно… Ну да, конечно же!
Ребята, вы — анукеи. Продвинутые, но все равно анукеи. И чтоб вам стать инженерами — вам надо долго и нудно учиться. И начинать с азов, типа того что такое маршрутизация и зачем она нужна. И самое главное — забыть все что вы усвоили «о сетях» из линакса как страшный сон. Изучать сети по линаксу, это все равно что начать изучать программирование с бейсика.
И эти люди реализуют сетевую подсистему линаксаНе вы ли писали, что cisco — это сеть, как они сделают, так и будет стандартом. И пофиг на RFC.
У линукса тоже есть вес. Как они сделали, циске придётся учитывать и прогибаться.
Иначе, если они со своим видением сделают несовместимо (и даже напишут RFC, вы уже показали, что они могут), новые железки никто не купит. А если купит по ошибке, и за циской линуксы работать не будут, циске задолбают техподдерку и она впилит костыли для поддержки линуксов, бу-га-га.
Ребята, вы — анукеиПосмотрите, где вы пишете. Тут вопрос про закрытие WiFi-камер. Сколько нужно сертифицированных инженеров циски, чтобы обезопасить одну WiFi-камеру?
Этот ваш наезд похож на то, как если бы в обсуждение строительства дачных домиков ворвался строитель БАМа и рассказывал всем, какие тут дебилы собрались, копают котлован неправильно. Ведь, по его мнению, единственный расово верный — это карьерный экскаватор с пятиметровым ковшом. Остальные полумеры для дилетантов.
Не вы ли писали, что cisco — это сеть, как они сделают, так и будет стандартом. И пофиг на RFC.
Я тут в соседнем посте показал кто пишет RFC — Cisco, Juniper, Lucent… И прочие серьезные производители сетевого оборудования. А не линаксоиды.
Так что по факту для тебя Cisco это и есть RFC. :)
А если купит по ошибке, и за циской линуксы работать не будут, циске задолбают техподдерку и она впилит костыли для поддержки линуксов, бу-га-га.
Нет, это вы напишете патчик, чтоб соотвествовать стандартам, определеными Cisco. Прецеденты уже были. :)
Посмотрите, где вы пишете. Тут вопрос про закрытие WiFi-камер. Сколько нужно сертифицированных инженеров циски, чтобы обезопасить одну WiFi-камеру?
В грамотно сконфигурированной сети эти уязвимости — не работают. :) И остаются чистой теорией.
Теперь я знаю всё про снобизм и непробиваемую самоуверенность циско-«инженеров».
Нет, это просты ты не знаешь базовых вещей о сетях — не можешь даже дать правильного определения таких базовых понятий как маршрутизация.
Звучит так, как будто у меня не хватает квалификации заценить всю глубину снобизма и самоуверенности ))
Снобизм — это у вас, у линаксоидов. Выучили десяток трудно запоминающихся команд, изучили потроха малораспространенной и невостребованной системы с хреновой, а посему — кране запутаной и нелогичной архитектурой — и думаете что вы разбираетесь в ИТ. Вы заблуждаетесь.
Простите, что влезаю, хоть и обещал так не делать, но я тут вспомнил, что есть же еще BSD системы, в которых NAT и firewall строятся по принципу ближе к линуксу, чем к cisco. Как Великий Мастер Cisco к ним (*BSD) относится? Или они тоже говно и недостойны?
Это ты обратись к Juniper — им таки удалось сделать из фряхи нечто пристойное… Правда ценник там совсем конский, по сравнению с ними кошечки очень недорогие…
Правда есть одно но — если линакс или бсдя используется в какой-то приличной сетевой железке, то наблюдается смешной момент — от их сетевой подсистемы не остается и камня на камне, фактически она реализуется с нуля, а линакс или фряха фактически используются как простейший бутлоадер и набор дров. :)
Правда есть одно но — если линакс или бсдя используется в какой-то приличной сетевой железке, то наблюдается смешной момент — от их сетевой подсистемы не остается и камня на камне, фактически она реализуется с нуля, а линакс или фряха фактически используются как простейший бутлоадер и набор дров. :)
Большое спасибо за ответ. И еще один вопрос, логично вытекающий из Вашего комментария. Вы чем именно упарываетесь и где берёте? Вы порошком из мелкоперетёртых цисок шприцом прямо в висок бахаетсь или пока еще в дёсны втираете?
Да пожалуйста. Я ничем не упарываюсь, но зато знаю чем упарываетесь вы — пингвинячим д-м. :) Забористая штука… Но зато я знаю чем вы кончите, если не получите базовых, которые позволят вам двигаться дальше, а не сидеть в жестком вендор-локе — на линаксе. Я с годик назад парочку таких увольнял — в 90-х мужики были неплохими спецами, но… они застряли в 90-х. Потом попали в госконтору, потом госконтору поделили, скинули весь в балласт в приватизируемую часть… Ну и нас пригласили — чтоб удержать все это хозяйство на плаву, до продажи… И слегка поразогнать балласт :)
Запомнились два товарища, оба 50+. Оба — прекрасные специалисты… были… в 90-х. Но получением базовых знаний — не озаботились. Так что покладистый дорабатывает до пенсии кладовщиком, хоть и на складе ИТ, а гоношистый, типа тебя — вылетел по статье.
Это и твоя судьба линаксоид. Хотя ты мне разумеется сейчас не веришь. Но вспомнишь об этом посте, когда время придет. :)
Запомнились два товарища, оба 50+. Оба — прекрасные специалисты… были… в 90-х. Но получением базовых знаний — не озаботились. Так что покладистый дорабатывает до пенсии кладовщиком, хоть и на складе ИТ, а гоношистый, типа тебя — вылетел по статье.
Это и твоя судьба линаксоид. Хотя ты мне разумеется сейчас не веришь. Но вспомнишь об этом посте, когда время придет. :)
Избавила судьба мужиков от идиота-начальника. Молодцы мужики, уважаю. Вот Вы с такой квалификацией через чью постель в руководители пробились? Или классические голые понты школьника, живущего с мамой? У взрослого, серьезного человека не будет пригорать настолько, что он тред будет в личный блог выносить. В котором его же еще раз успешно в помои его «квалификацией» и окунули.
Мальчик, мне тоже около 50-ти, внезапно да? И собственно яб оставался обычным ведущим инженером, старшим системным администратором и т.д., вообщем — на чисто инженерной должности, но… есть проблема — людей моего возраста и моего уровня квалификации считается стремным брать на такие должности, чисто инженерные, типа могут быть проблемы с более молодым начальником из-за его возраста и меньшей компетентности оного. Посему от начальственных лычек отвертеться не получается…
Если ты думаешь что увлечение дохода компенсирует гиморой от этих лычек, то ты дико заблуждаешься.
Если ты думаешь что увлечение дохода компенсирует гиморой от этих лычек, то ты дико заблуждаешься.
Мужик 50 лет спорит с «мальчиками» в интернетиках? Забанен на всех технических сайтах рунета, общаясь так как у меня гопники синюшные у подъезда не общаются? (иллюзию компетентности и отсутствие банальной грамотности я уже даже не беру в расчёт)
«Дядя», кого Вы лечите? Вам от силы лет 20, мало мозгов и куча свободного времени на срачи в интернете, так как мама с папой кормят и деньги зарабатывают.
«Дядя», кого Вы лечите? Вам от силы лет 20, мало мозгов и куча свободного времени на срачи в интернете, так как мама с папой кормят и деньги зарабатывают.
Ну вот ты и поплыл. Удачи. Вспомнишь мои слова — никуда не денешься, не долго ждать осталось. Тебе если верить профилю — 34 года, а следовательно — ты уже врятли сможешь получить необходимые базовые знания. Еще лет 10-15 — и у тебя начнутся серьезные проблемы, знания которыми ты владеешь окончательно устареют, а обновлять ты их уже не сможешь — из-за отсутствия теоретических знаний. Изучай складское дело и специальность менеджера по продажам. :)
Мозгов у тебя как я погляжу не хватает даже на то чтоб выяснить кто я такой. А это — не сложно, я не шифруюсь… так небольшая защитка от уж совсем идиотов. Если есть мозги — позвони, поговорим. :)
P.S. Приколно, ты родился в тот год, когда я впервые сел за комп. Это была ЕС1022. :)
Мозгов у тебя как я погляжу не хватает даже на то чтоб выяснить кто я такой. А это — не сложно, я не шифруюсь… так небольшая защитка от уж совсем идиотов. Если есть мозги — позвони, поговорим. :)
P.S. Приколно, ты родился в тот год, когда я впервые сел за комп. Это была ЕС1022. :)
Серьезно? Я не верил, но Вы реально выжидаете кулдаун возможности писать коммент почти с точностью до минуты просто, чтоб уязвить меня? В половину четвертого ночи. Серьезно? 50 лет? Скажите, это же всё-таки наркотики? Алкоголь? Радиация хотя бы? Не может же взрослый мужик просто так остаться по уровню развития на уровне школоты в плохом смысле этого слова.
И да. Насчет профиля. Все врут. Вы врёте, что понимаете что-то в сетях и что какой-то там начальник. Я вру про свои данные в профиле (мне на самом деле 22 (с половиной)).
А зачем мне Вам звонить? Работу ищете? Так мне не нужны кладовщики, спасибо. У нас уже есть один. Отличный дядька. Любил всем навязывать циски на каждом углу… пока не разорился. Теперь отличный кладовщик. Как раз циски снятые с использования за ненужностью охраняет.
А зачем мне Вам звонить? Работу ищете? Так мне не нужны кладовщики, спасибо. У нас уже есть один. Отличный дядька. Любил всем навязывать циски на каждом углу… пока не разорился. Теперь отличный кладовщик. Как раз циски снятые с использования за ненужностью охраняет.
сидеть в жестком вендор-локе — на линаксеКстати, если уж придираться к терминам, то кто вендор?
Но получением базовых знаний — не озаботилисьЗнание linux — необходимо для современного цискаря. У нас давно внедрены cisco CMX location & presence analytics для слежки за сотрудниками. Угадайте, что там под капотом? Centos + PostgreSQL. Если цискарь не сможет их поставить, настроить и обслуживать, то он пойдёт искать другую работу.
Кстати, если уж придираться к терминам, то кто вендор?
Формально — сообщество, по факту — ibm
Знание linux — необходимо для современного цискаря.
Вы так говорите, как будто это что-то сложное — знать линакс :) Для меня — это просто еще одна ОС, один из многих юниксов, с которыми мне приходилось работать.
Имея тот самый набор базовых знаний, о котором я вам постоянно говорю — разобраться с любым линаксом не проблема. Правда наличие этого самого набора гарантирует нелюбовь к линаксу. :)
Ну и вдогонку — даже если не знает, то не уволят. Если действительно нужно — наймут какого-нибуть линаксода, это всего примерно 1/3 от зарплаты цискаря… :)
cisco CMX location & presence analytics
Не работал с этим продуктом. Но по опыту работы с другими подобными продуктами кошководов — могу предположить что знание линакса как такового там не требуется — все делается через веб-морду скорей всего. Или — через свой командный язык, exec-like.
Вы бы лучше привели в пример snort или netflow — тут действительно приходится сталкиваться с линаксом. Хотя и не обязательно, но иногда под ним — удобней.
Не надо смешивать одного неадеквата и всех инженеров только. (Да, я увидел кавычки). Ваш оппонент скорее «морская свинка»: ни к морю, ни к свиньям отношения не имеет.
Это даже скорее редкость. Я на курсах сетевиков встречал инженеров с сертификатами cisco (совершенно разного уровня). Вполне нормальные люди, которые в том числе понимают, что на одном вендоре не зиждется интернет и пришли послушать как сети в остальном большом мире устроены.
Я искренне советую не обращать на него внимания, не отвечать на его посты. Ничему полезному он Вас не научит, даже если вы про циско что-то спросите.
Это даже скорее редкость. Я на курсах сетевиков встречал инженеров с сертификатами cisco (совершенно разного уровня). Вполне нормальные люди, которые в том числе понимают, что на одном вендоре не зиждется интернет и пришли послушать как сети в остальном большом мире устроены.
Я искренне советую не обращать на него внимания, не отвечать на его посты. Ничему полезному он Вас не научит, даже если вы про циско что-то спросите.
Кстати, этот кадр, оказывается с давних времен и других ресурсов известен (3 абзац комментария) как крайне нездоровый фанатик.
>Редкая вырожденная ситуация, которую вероятно можно встретить в каких-нибудь студенческих общежитиях с самопальной сетью.
И у многих крупных провайдеров, которые на дают роутеру клиента внешний адрес, а прячут его за NAT. Не проверял, но уверен, что роутеры всех моих соседей находятся в одной подсети с моим.
И у многих крупных провайдеров, которые на дают роутеру клиента внешний адрес, а прячут его за NAT. Не проверял, но уверен, что роутеры всех моих соседей находятся в одной подсети с моим.
да, можно попытаться прописать gateway. Редкая вырожденная ситуация, которую вероятно можно встретить в каких-нибудь студенческих общежитиях с самопальной сетью.
Ну то есть еще раз. NAT ничего без фаервола не блокирует. Блокирует либо отсутствие маршрутизации, либо фаерволл.
Крупный провайдер крупного российского города. Дает ипы из сети /21. Торренты качаются через сеть провайдера, как раз через внутреннюю сеть этого провайдера.
И такой провайдер не один по РФ. Практически все, кто не использует туннелирование типа l2tp или pppoe. Это же не мультикаст\броадкаст, который изолируют по vlan'ам.
У злоумышленика один интерфейс с адресом 7.7.7.200/24. обращается на 192.168.0.2. Будьте любезны разжевать, что именно воспрепятствует нашему роутеру заблокировать пакеты межу 7.7.7.200 и 192.168.0.2?Интересная теория…
Допустим, злоумышленник посылает SYN с 7.7.7.200:21001 на 192.168.0.2:80. Сервер там отвечает SYN-ACK на 7.7.7.200:21001.
Но обратный пакет перехватывается роутером и отбрасывается NAT-ом, т.к. маппинга нет в таблице трансляции. Новые трансляции должны создаваться пакетом SYN, но не SYN-ACK (NAT-ы следят за фазами TCP-соединения, чтобы вовремя очищать записи в таблице трансляции, так можно держать больше соединений. Да и всякий мусор отбрасывать — благое дело).
Допустим, у нас кривой NAT и ему пофиг, что SYN, что SYN-ACK.
В этом случае ответ будет отправлен с другого IP (7.7.7.100) и другого порта.
Порт нужно менять, т.к. если два клиента, 192.168.0.1 и 192.168.0.2 отправят запрос на сервер 7.7.7.200:80 по случайности с одного порта 22001, сервер не различит эти соединения.
В этом примере NAT принудительно заменит порт и сервер будет видеть 192.168.0.1:21001 как 7.7.7.100:31001, а 192.168.0.2:21001 как 7.7.7.100:31002.
Так и при трансляции SYN-ACK будет подменён и адрес, и порт, и TCP-соединение развалится.
В этом случае ответ будет отправлен с другого IP (7.7.7.100) и другого порта.
Порт нужно менять, т.к. если два клиента, 192.168.0.1 и 192.168.0.2 отправят запрос на сервер 7.7.7.200:80 по случайности с одного порта 22001, сервер не различит эти соединения.
Значит, NAT принудительно заменит порт и сервер будет видеть 192.168.0.1:21001 как 7.7.7.100:31001, а 192.168.0.2:21001 как 7.7.7.100:31002.
Вы вот тут спутали понятия сервер и адреса. Или я Вас совсем не понял. У нас сервер — 192.168.0.2. Злоумышленник — 7.7.7.200. Перепроверьте, пожалуйста, что адресацию в цитируемом абзаце. Я пока сэмулирую предложенную схему на виртуалках и покажу лог сниффера.
Это иллюстрация факта, что NAT подменяет не только ip-адреса клиентов (192.168.0.2 на 7.7.7.100), но и порты (на любые свободные)
Я пока сэмулирую предложенную схему на виртуалкахЛучше объясните, почему ответ сервера 192.168.0.2, который проходит через LAN-интерфейс роутера 192.168.0.254, не попадёт в NAT.
А почему он должен не попасть? Кстати, я сэмулировал свою схему для SSH специально для вас. Все работает. Сейчас почищу и выложу дамп. Использовал микротики, но в них routeros, сиречь модифицированный линукс, так что работать будет на всех линуксах (openwrt, asuswrt и т.п.)
А почему он должен не попасть?Так в том и проблема, что если попадёт, то должен дропнуться NAT-ом, а если не дропнется, то у ответа должен быть подменён SRC-ADDR, SRC-PORT и клиент на 7.7.7.200 не поймет, как так — отправлял на 192.168.0.2:80, а отвечает 7.7.7.100:31001. Это явно ответ не к тому запросу.
Покопавшись в дампе wireshark'ом пришел к выводу, что ответные пакеты и, как следствие все пакеты соединения по src nat не попадают. Почему? У меня сходу нет ответа. Но это так как минимум в линуксах и routeros. Если хотите — покажу дампы, напишите только контакт в ЛС. Публично их выкладывать смысла не вижу, там тихо мирно ходят пакеты между 7.7.7.200 и 192.168.0.2, тогда как src nat на WAN прописан и, если например, с 192.168.0.2 обратиться на 7.7.7.200, то пакеты приходят с 7.7.7.100.
В дампах нет смысла, если это обычные TCP-соединения.
Поспрашиваю у знакомых сетевиков, как настроить firewall против этого случая.
Наивный подход
Поспрашиваю у знакомых сетевиков, как настроить firewall против этого случая.
Наивный подход
/ip firewall filter
add action=drop chain=forward comment="disallow provider access to my network" dst-address=192.168.0.0/16 in-interface=PPPoE-domRUДа как настроить фаервол я знаю, это в последних версиях routeros из коробки:
add action=accept chain=input comment=«defconf: accept establieshed,related» connection-state=established,related
add action=drop chain=forward comment=«defconf: drop all from WAN not DSTNATed» connection-nat-state=!dstnat connection-state=new disabled=yes in-interface=5-lte
Спорил я с невеждами выше о том, что нужен ли вообще фаервол, когда есть NAT. Он, очевидно, нужен.
Вопрос, который Вы у меня зародили, в том «почему оно так?» На основании чего linux\routeros не srcnat'ит SYN+ACK. Я раньше об этом как-то не задумывался, принимал как должное. Сейчас потратил вечер на чтение RFC и гугленье, но ответа пока не нашел.
add action=accept chain=input comment=«defconf: accept establieshed,related» connection-state=established,related
add action=drop chain=forward comment=«defconf: drop all from WAN not DSTNATed» connection-nat-state=!dstnat connection-state=new disabled=yes in-interface=5-lte
Спорил я с невеждами выше о том, что нужен ли вообще фаервол, когда есть NAT. Он, очевидно, нужен.
Вопрос, который Вы у меня зародили, в том «почему оно так?» На основании чего linux\routeros не srcnat'ит SYN+ACK. Я раньше об этом как-то не задумывался, принимал как должное. Сейчас потратил вечер на чтение RFC и гугленье, но ответа пока не нашел.
Я начал гуглить всякие конфиги, и там рекомендуют блочить входящие
И вот этот 'invalid' навёл на мысль, что раз уж у каждого пакета есть такой признак, то он используется для попадания в NAT.
Пакеты new идут в NAT для создания маппинга, а established — для трансляции.
SYN-ACK — invalid, в NAT не попадает, поэтому идёт в роутинг.
PS. Ниже так уже написали )))
connection-state=invalid,newИ вот этот 'invalid' навёл на мысль, что раз уж у каждого пакета есть такой признак, то он используется для попадания в NAT.
Пакеты new идут в NAT для создания маппинга, а established — для трансляции.
SYN-ACK — invalid, в NAT не попадает, поэтому идёт в роутинг.
PS. Ниже так уже написали )))
И вот этот 'invalid' навёл на мысль, что раз уж у каждого пакета есть такой признак, то он используется для попадания в NAT.
Как это у каждого? Правило, которое Вы привели обозначает блочить пакеты с ctstate invalid ИЛИ new. Там же речь про цепочку FORWARD же?
Пакеты new идут в NAT для создания маппинга, а established — для трансляции.
SYN-ACK — invalid, в NAT не попадает, поэтому идёт в роутинг.
SYN-ACK в нашем случае уже established. Поэтому он идет через то же правило NAT, что и первый пакет с NEW — то есть не NATится совсем.
Как это у каждого?То есть, connection-state уже посчитан для каждого пакета, чего бы не использовать для определения, отправлять ли в NAT
Правило, которое Вы привели обозначает блочить пакеты с ctstate invalid ИЛИ new. Там же речь про цепочку FORWARD же?Да, forward. Сделал аналогично для ipv6, а то без этого сеть защищена было только рандомизацией.
SYN-ACK в нашем случае уже establishedЭто я ошибся.
Поспрашиваю у знакомых сетевиков, как настроить firewall против этого случая.Разрешать маршрутизирование пакетов только от уже установленных и вспомогательных соединений (conntrack RELATED, ESTABLISHED, на Mikrotik должно такое быть) из интернет-интерфейса в LAN-интерфейс.
Разобрались вместе с ValdikSS. Спасибо ему большое.
Во-1, я нашел подтверждение в официальной документации netfilter:
Во-2, https://upload.wikimedia.org/wikipedia/commons/3/37/Netfilter-packet-flow.svg (приписка про NEW)
Ну и краткое описание изысканий для интересующихся:
Во-1, я нашел подтверждение в официальной документации netfilter:
3.2.2. NAT
…
This table is slightly different from the `filter' table, in that only
the first packet of a new connection will traverse the table: the
result of this traversal is then applied to all future packets in the
same connection.
Во-2, https://upload.wikimedia.org/wikipedia/commons/3/37/Netfilter-packet-flow.svg (приписка про NEW)
Ну и краткое описание изысканий для интересующихся:
[23:45:17] ValdikSS: SYN от «хакера» в «лан» приходит с внутренним состоянием CONNTRACK «NEW» и не попадает в POSTROUTING, что логично. Когда клиент хочет ответить на этот SYN, это соединение уже имеет состояние «SYN_RECV», и не попадает в цепочку NAT POSTROUTING.
qw1 так-то правильно говорит про сферический NAT в вакууме, думаю, такие, как он говорит, тоже встречаются, просто линуксовый conntrack чуть продвинутей и умней.
[23:48:24] ValdikSS:
» Вот ты это откуда все взял?
Сделал 2 контейнера: «hacker» и «lan», на hacker сделал INPUT -j DROP, на lan сделал nc -l -p 4444 и логирование пакетов iptables в -t nat POSTROUTING, подключился с hacker на lan, посмотрел состояние conntrack, увидел syn-sent, увидел, что пакет не попадает в POSTROUTING, посмотрел на эту таблицу, на которую я тебе дал ссылку (она у меня на стене в распечатанном виде), увидел заметку про NEW.
[23:50:10] ValdikSS: Раньше в линуксе был NAT еще и в iproute2, вот он тупой, он на уровне пакетов работал, и с ним бы вышло так, как говорит qw1. Но это не означает, что это безопасно: пакеты в принципе передаются и принимаются, достаточно только воспользоваться модифицированным TCP-стеком каким-нибудь, чтобы с таким «асимметричными маршрутами» устанавливать TCP-сессии.
[23:51:38] ValdikSS: Предполагаю, что как раз всякие Cisco работают так, как qw1 пишет.
[23:51:58] ValdikSS: (и порты не обязательно должны всегда меняться, зависит от реализации, но это не принципиально).
Более того, в предложенном мною варианте это никак не поможет. Пакеты на WAN интерфейс буду приходит с подсети WAN-интерфейса, как я и указал во втором абзаце предыдущего комментария.
А как вы собираетесь эти камеры находить, если провайдеры раздают по /56 каждому клиенту?
Не говоря уже о том, что если вы хотите пожертвовать P2P-соединениями в целях некоторой безопасности, как в случае с NAT, нет проблемы сделать простое правило «разрешить исходящие, запретить новые входящие сессии» на «домашнем» маршрутизаторе IPv6, NAT для этого не нужен.
Не говоря уже о том, что если вы хотите пожертвовать P2P-соединениями в целях некоторой безопасности, как в случае с NAT, нет проблемы сделать простое правило «разрешить исходящие, запретить новые входящие сессии» на «домашнем» маршрутизаторе IPv6, NAT для этого не нужен.
root:$1$ybdHbPDn$ii9aEIFNiolBbM9QxW9mr0:0:0::/root:/bin/sh
Вот с этим, кстати, не очень понятно что делать… Что из этой строки есть хэш?
$1$ybdHbPDn$ii9aEIFNiolBbM9QxW9mr0 — в базах хэшей не ищется, некоторые пишут что тип хэша неверный.
Здесь используется алгоритм, основанный на MD5. Структура «зашифрованного» пароля, полученная от
crypt (C):$id$salt$hashed, где id — используемый алгоритм, salt — Base64-соль, hashed — Base64-результат от хеширования пароля и соли. Подробнее по ссылке выше.
только я не совсем понял почему, она же USB, неужели дрова открывают порты?
Но ведь это же просто web'ка. Она не работает без ПК, и Wi-Fi в ней тоже нет. Не понятно что она делает в этом списке.
Но… У неё же нет вайфай. Пойду заклею её изолентой, что-ли.
Модель действительно распространенная, по цена/качество выигрывает многие другие модели.
А не проще ли ему было просто заказать себе аппарат сразу без камеры и микрофона, или же привлечь специалиста, что бы он отключил их на физическом уровне?
Наверное потому что если вдруг понадобится — можно будет отклеить и сразу пользоваться. Правда, с таким же успехом можно тумблер поставить )
Предполагаю, что аппарат, делающийся под заказ для Марка Цукерберга — просто лопнул бы от закладок, которые потребовали бы туда установить всякие разные службы. Привлечь специалиста — аналогично, нет 100% доверия, что ему не заплатят за установку дополнительных закладок…
Самое надежное — купить аппарат в первом попавшемся магазине подальше от офиса — по крайней мере, закладки будут только стандартные.
Самое надежное — купить аппарат в первом попавшемся магазине подальше от офиса — по крайней мере, закладки будут только стандартные.
Да, разумеется, предложенные вами варианты сильно проще пары кусочков скотча.
Возможно, он их иногда использует
Камера в спальне? Месье знает толк в наслаждениях!
Самое смешное было, когда я написал китайцам с просьбой предоставить пароль от неотключаемого telnet. Ответили что конечному пользователю (sic!) туда нельзя.
В итоге, камеры живут в отдельной подсети, исходящие инициировать не могут, разрешён входящий 554 и 80.
В итоге, камеры живут в отдельной подсети, исходящие инициировать не могут, разрешён входящий 554 и 80.
А можно где-нибудь найти список более-менее устойчивых к взлому моделей? А то задумался о покупке такой камеры, но что-то стрёмно как-то, учитывая количество разоблачительных статей подобного характера за последние несколько лет.
тогда лучше взять роутер с openWRT и воткнуть в него USB камеру.
Простите, если смысл использовать IP-камеру перед USB я понимаю и полностью с Вами согласен, то зачем «тюнинговать» камеру в целях безопасности, когда можно за 25 баксов купить роутер, которым прикрыть до трех камер, отфилтровав только тот траф, что нужно и можно?
Почти все прошивки массово-потребительских устройств такого же отвратительного качества и никем не обновляются, просто веб-камеры в штуках, наверное, самые массовые после смартфонов.
Просто для примера: в автосалоне лежит выводок китайских систем удаленного запуска двигателя с SIM-картой и приложением для Android… ага, всё понятно.
И так везде:(
Просто для примера: в автосалоне лежит выводок китайских систем удаленного запуска двигателя с SIM-картой и приложением для Android… ага, всё понятно.
И так везде:(
Я так понял, что практичеси все уязвимости связаны не собственно с камерами, а с их «облачными» сервисами.
Но ведь в случае их использования априори глупо ждать какой-либо конфиденциальности. Если сам указываешь устройству сливать данные в сеть, то по меньшей мере наивно думать, что ни у кого кроме тебя не будет там к ним доступа.
Но ведь в случае их использования априори глупо ждать какой-либо конфиденциальности. Если сам указываешь устройству сливать данные в сеть, то по меньшей мере наивно думать, что ни у кого кроме тебя не будет там к ним доступа.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Тысячи моделей Wi-Fi камер разных производителей открыты для злоумышленников