Ну хотя бы потому что в статье автора речь про 802.1x идет в разделе «Противодействие «левым» устройствам» где обсуждается вопрос о мерах защиты в проводной сети.
Планирование и настройка CA — самая вершина айсберга. Гораздо больше времени потратится на решение вопросов с принтерами и теми кто так же не поддерживает 802.1x. Потом появится желание аутентифицировать не только рабочее место (это самое простое — ввели машину в домен, она тут же получила сертификат и прекрасно им аутентифицируется), но и пользователя. А заодно, в зависимости от того что за пользователь, совать его в тот или иной VLAN, а потребует пересмотр сетевой архитектуры. Потом найдется что нибудь все еще живущее под XP ( хотя сейчас уже проще с ним).
Но в любом случае не стоит преувеличивать — внедрение 802.1x не так страшно если не полениться и выпустить проект на внедрение, в начале которого просто перечислить все подключенное, а в теле по каждому типу прописать что делаем(впрочем это касается любого внедрения).
Планирование и настройка CA? Все что введено в домен, все уже с сертификатом и делать ничего не надо. А вот с принтерами и прочим, не поддерживающим 802.1x точно придётся что то делать. И если возникнет желание (а оно возникнет)
Да, вы правы, опечатка. На самом деле можно ещё аналогичных языков привести и не только к Forth. Но на мой взгляд основная разница не в названии а в подходе. Пишем на C, не забываем обрабатывать исключения и делать range check, в ответ получаем исключительную гибкость в части кода, C# + dot Net быстрая разработка но скорость исполнения оставляет желать лучшего. Перешли на ASM — «сами, все сами» за компактность и быстродействие на высоте ну и так далее. Статья была бы существенно познавательнее и интереснее если бы описывала различия языков с этой точки зрения.
Прошу прощения, но страшилки про многогигабитные атаки уже порядком приелись. Судя по Вашей презентации, очередной «велосипед» анализ xFlow и выявление аномалий. Но для вас ведь не новость, что хост среднего уровня довести до состояния DoS можно парой мегабит «правильного» трафика и анализ xFlow тут не поможет. Что по этим векторам можете предложить?
В этих параметрах не хватает самого главного — процента False Positive. Ну и опять таки, вот например для UDP Flood заявлено блокирование 90% атаки, то есть при атаке хотя бы в 10G (тот же DNS Amplification дает усиление 80+, с собственным каналом 1Gb/s получим атаку до 80G) до конечного ресурса «долетит» 1Gb/s атаки. Ресурс, как приложение/платформа не пострадает, но подключение единичного выделенного сервера…
А в статье неплохо бы поправить явное несоответствие —
Для обнаружения аномалий трафика система в режиме реального времени анализирует трафик, проходящий через маршрутизаторы, фильтрует его, причем используются высокопроизводительные методы фильтрации трафика на уровне стека TCP/IP и на уровне приложений (HTTP, DNS, SIP и т.д.).
. Анализ трафика на уровне приложения на маршрутизаторе? Тогда, согласно приведенной схеме, весь трафик проходит через «Очиститель» у которого производительность 10Gb/s согласно информации на сайте.
Но в любом случае не стоит преувеличивать — внедрение 802.1x не так страшно если не полениться и выпустить проект на внедрение, в начале которого просто перечислить все подключенное, а в теле по каждому типу прописать что делаем(впрочем это касается любого внедрения).
А в статье неплохо бы поправить явное несоответствие — . Анализ трафика на уровне приложения на маршрутизаторе? Тогда, согласно приведенной схеме, весь трафик проходит через «Очиститель» у которого производительность 10Gb/s согласно информации на сайте.