Comments 23
За картинку поспорю, в определенных ситуациях нет потребности 100% предотвратить доступ, доступ требуется лишь немного ограничить, например в больших дворах часто так ставят кнопки для удобства жильцов, это хватает чтобы посторонние не шатались.
Все кодовые замки с 10 кнопками такие. 1024 комбинации всего, из них одна — все отжаты, одна — все нажаты, 45 — нажато две одновременно, 120 — нажато три одновременно. Больше трёх редко используется, так что тупо перебором за две-три минуты реально подобрать код. И это ещё не использовался тот факт, что на кнопках часто есть следы использования, что резко уменьшает число необходимых попыток.
Это примерно как WEP: в теории должен обеспечивать безопасность, на практике годен разве что для защиты от «пионэров». И ведь многие до сих пор используют. Поэтому с точки зрения удобства пользователей так проще, но вот в плане безопасности — fail.
Чем WEP проще/удобнее WPA2-Personal?
Хороший вопрос. Встречал варианты:
-когда-то настроили, всё и так работает
-тыкнул первое в списке
-???
Похожая ситуация с WPA и WPA/WPA2.
-когда-то настроили, всё и так работает
-тыкнул первое в списке
-???
Похожая ситуация с WPA и WPA/WPA2.
У нас в офисе одно время был WEP, просто потому что у кого-то смартфон не поддерживал WPA… Выбирая между вариантами «нас взломают» и «ничего не будет работать», пришлось выбрать первый.
Обычно применяется иной подход. Если поддержка legacy устройств требует снижения уровня безопасности или сервиса для прочих устройств, то пишется политика, по которой устаревший хлам не должен подключаться к сети.
Примеры legacy устройств:
1) Поддерживающие только 802.11b (автоматически идут лесом — они существенно снижают пропускную способность беспроводной сети)
2) Для отдельных WLAN — не поддерживающие WMM девайсы. Аналогично с п.1.
3) Разумеется, кто не знает про WPA2-Enterprise с AES, тому в сети не место.
Примеры legacy устройств:
1) Поддерживающие только 802.11b (автоматически идут лесом — они существенно снижают пропускную способность беспроводной сети)
2) Для отдельных WLAN — не поддерживающие WMM девайсы. Аналогично с п.1.
3) Разумеется, кто не знает про WPA2-Enterprise с AES, тому в сети не место.
Не соглашусь с «обычно». Опыт показывает, что обычно делают так, как проще, а потом, если прижало, пытаются заткнуть дыры и приделать подпорки. Вы, конечно, возразите про квалификацию и стандарты, но реалии, увы, такие. Предположим, телефон или ноутбук у начальника, WiFi он хочет, а менять чудо-девайс не хочет. Много ли среднестатистических админов категорично скажут «Покупайте новый»?
И WPA2-Enterprise с AES видели далеко не все, а уж настраивали…
И WPA2-Enterprise с AES видели далеко не все, а уж настраивали…
Ну возможно я сужу по опыту работы в относительно крупных компаниях… В них кто угодно вплоть до председателя правления следует корпоративным политикам, и если попросит их нарушить — ему покажут бумажку с его же подписью. И если он попросит подключить к сети старенький мобильник, а CIO и CISO скажут «низя, иначе похакают/пострадают другие пользователи», то мобильник не будет подключен к сети.
mayorovp
>Задача была подключить к сети устаревшее устройство!
Ну и? Задача отменяется, так как безопасники запретили поднимать что угодно содержащее в себе буквы «WEP». И да, во многих случаях такой подход наилучший, в противном случае у вас начнется зоопарк, который категорически не поддается сопровождению и который сможет проломить любой школьник с ноутбуком (а это уже угроза существованию самого бизнеса). Если ваш «среднестатистический админ» не способен объяснить это руководству и категорически отказаться выполнять запрос, то он профнепригоден. А то ведь дальше начнется — «хочу локального админа и доступ к флешкам» от главбуха и тому подобное. Почему-то все забывают, что исключения в безопасности ради руководства — худшее что можно сделать, ведь именно руководство имеет доступ к наиболее нежелательной к утеканию информации, и потому именно их компьютеры и прочие устройства должны быть сильнее всего защищены. Потому имеет смысл послать к черту и Сама, если тот например захочет доступ к почте со всеми вложениями с мобильника, но откажется шифровать устройство и каждый раз при разблокировке вводить длинный пароль.
mayorovp
>Задача была подключить к сети устаревшее устройство!
Ну и? Задача отменяется, так как безопасники запретили поднимать что угодно содержащее в себе буквы «WEP». И да, во многих случаях такой подход наилучший, в противном случае у вас начнется зоопарк, который категорически не поддается сопровождению и который сможет проломить любой школьник с ноутбуком (а это уже угроза существованию самого бизнеса). Если ваш «среднестатистический админ» не способен объяснить это руководству и категорически отказаться выполнять запрос, то он профнепригоден. А то ведь дальше начнется — «хочу локального админа и доступ к флешкам» от главбуха и тому подобное. Почему-то все забывают, что исключения в безопасности ради руководства — худшее что можно сделать, ведь именно руководство имеет доступ к наиболее нежелательной к утеканию информации, и потому именно их компьютеры и прочие устройства должны быть сильнее всего защищены. Потому имеет смысл послать к черту и Сама, если тот например захочет доступ к почте со всеми вложениями с мобильника, но откажется шифровать устройство и каждый раз при разблокировке вводить длинный пароль.
А что делать, если при отсутствии подключения к сети ключевого оборудования конец бизнесу настанет еще раньше? :)
А можно конкретный пример, желательно из жизни? А то ведь при таких запросах почти всегда выясняется, что единственная причина — «мне хочется», и при отказе со стороны IT выполнить запрос бизнес вообще никак не страдает. Ну а если бизнес-процесс, подразумевающий данное решение, действительно важен, то всегда найдется альтернативное решение, не приносящее вместе с собой недопустимые риски.
Если же администратор открывает нараспашку дверь в защищенный сетевой периметр своей организации по причине «кому-то для мобильника надо» (абсолютно неуважительная причина), то это, как я уже говорил, балансирует на грани профнепригодности.
Если же администратор открывает нараспашку дверь в защищенный сетевой периметр своей организации по причине «кому-то для мобильника надо» (абсолютно неуважительная причина), то это, как я уже говорил, балансирует на грани профнепригодности.
Задача была подключить к сети устаревшее устройство! Если запретить «устаревший хлам», то задача не будет решена.
Об этом типе атаки известно уже более 3 лет и за это время я не припомню ни одного случая DDoS атаки с её использованием.
Выкладки чисто теоретические или удалось устроить DDoS методом NDP Table Exhaustion на практике?
Выкладки чисто теоретические или удалось устроить DDoS методом NDP Table Exhaustion на практике?
На эту тему кто-то пошутил: «Сейчас обычные DDoS бывают больше, чем весь IPv6-трафик вместе взятый». В лабораторных экспериментах по состоянию на 2011 (когда тема получила более широкую огласку) результаты были разные. Некоторые устройства от крупных вендоров благополучно складывались, ряд ОС тоже был подвержен. Есть вероятность, что проблему до сих пор закрыли не везде + старые ОС и устройства тоже никуда не делись.
Были ли случаи «в дикой природе»? Такой информации найти не удалось, хотя было бы любопытно. Думаю, когда (если) IPv6 взлетит, кто-нибудь обязательно попробует.
Были ли случаи «в дикой природе»? Такой информации найти не удалось, хотя было бы любопытно. Думаю, когда (если) IPv6 взлетит, кто-нибудь обязательно попробует.
Просто может получиться, как с атакой на истощение DHCP pool'а в IPv4. В теории все легко, просто и возможно, а на практике даже самые простые DHCP серверы с этой атакой справляются.
Я лично надеюсь, что так и случится: меньше атак — проще безопасность.
Статья писалась не как «ужас-ужас-ужас», и больше для иллюстрации интересного явления. Безобидные и даже полезные особенности IPv6 в сочетании не самой лучшей их реализацией могут привести к потенциально большим проблемам. При этом IPv4-мышление может помешать их увидеть.
Вообще, планировалось написать несколько подобных статей «Что есть в IPv6, чего нет в IPv4», если будет интерес. По опыту для многих это ещё в диковинку, а первый вопрос — «Это что, все внутренние компы будут с Интернета видны?».
Статья писалась не как «ужас-ужас-ужас», и больше для иллюстрации интересного явления. Безобидные и даже полезные особенности IPv6 в сочетании не самой лучшей их реализацией могут привести к потенциально большим проблемам. При этом IPv4-мышление может помешать их увидеть.
Вообще, планировалось написать несколько подобных статей «Что есть в IPv6, чего нет в IPv4», если будет интерес. По опыту для многих это ещё в диковинку, а первый вопрос — «Это что, все внутренние компы будут с Интернета видны?».
К слову, никто не требует в IPv6 использовать /64 для point-to-point, и даже никто не требует использовать NDP для /64 сети. Маски (или длина) сетей в IPv6 не всегда работает так же, как в IPv4. Если у вас есть подсеть /64, то не обязательно это должен быть один broadcast-домен. Что-то не могу найти сейчас RFC, но в Linux это называется noprefixroute. Сделано, вероятно, для того, чтобы использовался правильный исходящий IP-адрес для конкретного диапазона, если IP-адресов на интерфейсе несколько.
В том и дело, что по сути требуют, иначе ломаются некоторые механизмы IPv6, и оборудование потенциально может чудить. Кто-то утверждает, что всё отлично, и проблем никаких, но по RFC /64 и только /64 (за очень редкими исключениями в виде /127).
Насчёт ограничения «broadcast-домена» (широковещания-то в старом смысле нет) — не про "on-link" речь?
Насчёт ограничения «broadcast-домена» (широковещания-то в старом смысле нет) — не про "on-link" речь?
Чтобы не утверждать голословно: есть обзор ссылок, упоминаний в RFC и потенциально ломаемых технологий вот здесь.
Интересные наблюдения в этой статье на blog.ipspace.net. Если вкратце, на Cisco Nexus 5500 заложено 16к совокупно IPv4 и IPv6 маршрутов, а также 128 маршрутов с longest prefix match. Наиболее вероятно, что чисто технически это эквивалентно 16к /64 маршрутов и всего 128 остальных маршрутов, в том числе и более длинным префиксом.
Интересные наблюдения в этой статье на blog.ipspace.net. Если вкратце, на Cisco Nexus 5500 заложено 16к совокупно IPv4 и IPv6 маршрутов, а также 128 маршрутов с longest prefix match. Наиболее вероятно, что чисто технически это эквивалентно 16к /64 маршрутов и всего 128 остальных маршрутов, в том числе и более длинным префиксом.
Да, речь по on-link.
Ну а по ссылке на RFC, который вы привели, из нужного может сломаться разве что multicast.
Но, в целом, большинство использует /64 для point-to-point (те же туннель-брокеры), а другое большинство — fe80-адреса.
Ну а по ссылке на RFC, который вы привели, из нужного может сломаться разве что multicast.
Но, в целом, большинство использует /64 для point-to-point (те же туннель-брокеры), а другое большинство — fe80-адреса.
В целом да, и сейчас не могу найти тот RFC, в котором за не-/64 адреса обещали кары небесные. Возможно, почудилось от черезмерного курения RFC, или он уже благополучно устарел.
On-link — очень интересный принцип. Пока ещё не экспериментировал, но в теории получается можно сделать L3 не просто на Access, но и на каждом порту коммутатора, исключив L2-сегменты как явление.
On-link — очень интересный принцип. Пока ещё не экспериментировал, но в теории получается можно сделать L3 не просто на Access, но и на каждом порту коммутатора, исключив L2-сегменты как явление.
Sign up to leave a comment.
Атака на IPv6: NDP Table Exhaustion