Pull to refresh

Comments 14

Стал замечать, что в последнее время таких статей в интернете все больше, разработчик в погоне за защитой от серьезных атак, забывают о таких с одной стороны незначительных деталях, но все же очень обидных.
Забыли указать, что регистрация не означает того, что вы вышлете ссылку на вебинар после регистрации.
Ссылка на вебинар приходит не сразу после регистрации — она рассылается за час до вебинара.

Вам сегодня (17 ноября) не пришла ссылка?
Мне не пришла ссылка на прошлый вебинар (спам папку разумеется проверил), хотя и подтвердили моё участие. На webinar@ptsecurity.ru меня тоже решили проигнорировать когда я спросил о такой оказии.
Тоже мне, открыли Америку.
Любой сетевой инженер должен знать что ICMP пакеты типа «unreachable» обрабатываются/генерируются роутером в «software mode». Поэтому на нормальном железе есть настройки где можно задать лимит на количество таких пакетов в секунду, что-бы не нагружать процессор.

Только вот включение безопасных настроек по умолчанию со всеми лимитами на базе заведомо известных мощностей продукта — в зоне ответственности производителя.

Если следовать такому требованию — то тогда автомобилестроители должны зарезать скорость всех выпускаемых автомобилей до 60 км/ч, а то и ещё меньше.

Однако действительность сложнее…
Не нужно крайностей, но не допустить выхода из строя автомобиля/мотоцикла ограничивая обороты двигателя — уже есть из коробки у многих умных транспортных средств. А для этого случая отключение оборудования по причине нехватки мощности для обработки пакетов — вполне логически предполагаемое, и защита из коробки должна быть и включена по-умолчанию (с вариантом отключения на свой страх и риск).
На мой взгляд не совсем верные аналогии.
Более правильно будет
обороты двигателя — скорость процессора
скорость автомобиля — скорость на внешних портах.

В каких-то случаях двигателя не хватит для перевозки груза превосходящего расчетный.
Странно то, что расчетный груз может вызывать перегрузку двигателя.
По-моему проблема в том что «statefull» межсетевые экраны (те которые appliance а не на конечном сервере) в принципе не могут нормально работать: они не знают и не могут знать реального состояния сетевого стека на стороне клиента и/или сервера, их вычислительная мощность на порядок ниже клиент-серверной. Отсюда и растут ноги бесконечных «drop» политик и «експирящиеся» сессии которые приводят к случайно залипающим/отваливающимся коннектам. В смысле отладки — полный кошмар.
А по-моему именно ICMP Type 3 на ASA выключен.
а можно конкретнее про модели PaloAlto?
Узнать, уязвима ли конкретная система, можно разрешив ICMP на стороне WAN межсетевого экрана и осуществить тест


По умолчанию на Cisco ASA запрещен ICMP протокол.
Нет списка версий прошивок на которых тестировалась данная проблема — проблеме может быть решена несколько релизов назад, а сейчас просто опубликовали.
Sign up to leave a comment.