Комментарии 33
После сообщения исследователя Н. Пелосси об уязвимости к атакам сената, Гугуль заблокировал пользователей по следующему набору регулярных выражений:
t.{4}
.r.{3}
.{2}u.{2}
.{3}m.
.{4}p.
Действие такого же порядка. Софт в нарушение RFC начинает отказываться работать по случайному набору портов.
Ну и еще там по мелочи докидываются некоторые плюшки по безопасности в новом протоколе.
Но я действительно могу многого не знать, и еще многое не учитывать.
Решается целый класс атак, связанных с тем, как работает NAT и routing. То же переполнение nf contrack таблиц (иначе нат и не работает).
Второй момент — очень многие думают, что нат от чего-то защищает. Переход на ipv6 этих балбесов заставил бы настроить файрволл нормально, что в общем — привело бы к ПОВЫШЕНИЕ безопасности
То же переполнение nf contrack таблиц (иначе нат и не работает).Гм…
Видимо, я плохо понимаю суть проблемы: вы хотите сказать, что конечный хост не подвержен этой атаке? Что-то мне сомневательно.
Переход на ipv6 этих балбесов заставил бы настроить файрволл нормальноСкорее, оставил бы их даже без этой эфемерной защиты. Вы переоцениваете человеческие способности.
Но да, психологические причины, наверное, валидны.
Ну, есть разные топологии сети ) например, самое страшное — когда на роутере не только DST, но и SRC NAT. И тогда, например, РДП сервер ВНУТРИ периметра не может полагаться на фильтры СВОЕГО файрволла и акцес листы. Короче, НАТ — это костыль из старых лет.
Или, не знаю, роутер получает адрес по дхцп и в какой-то момент времени снаружи стала прилетать серая сетка… Дальше какие-нибудь форвард правила неудачные и приплыли (мы же за НАТом, нам все равно! гы).
Еще, кстати, очень занятно лечить проблемы с доскером, который по умолчанию сажается на 172.12.x.x, а это бывает вполне валидной корпоративной сеткой. Трафик начинает хитро заруливаться и приплыли )))) Сколько раз устранял эту проблему :-) Так что количество кривых комбинаций невообразимо и к каким последствиям они могут привести — тоже.
Кто там говорил, что сети — это просто? :-)
Просто идея, что устранение NAT само по себе повысит безопасность… по мне весьма схожа с идеей, что демонтаж входной двери в подъезд заставит жителей поставить себе железные двери в квартирах.
Но я, еще раз, могу чего-то не знать и ошибаться.
Устранение nat не повысит безопасность, а устранит ложное ощущение безопасности. Ну, грубо говоря, у вас была сеть, в которой стоит файрвол с правилами allow * в обе стороны, плюс специальная IDS образца 2002 года, которая умеет детектить tear drop и ping of death для windows 98. Какая сеть безопаснее? С такой IDS или без?
Очевидно, что без IDS, потому что уровень базовой безопасности хостов остался тот же, а кода (образца 2002 года) с сетевым exposure стало меньше.
IDS не является неотъемлемой частью NAT'а, так что этот случай не очень чистый. Если вы хотите сказать, что защита не пойми от чего, настроенная непонятно как во времена Очакова и покоренья Крыма, может не уменьшать, а увеличивать угрозы безопасности — так я с этим не спорю.
Сам по себе nat в сравнении с просто открытым хостом с белым айпишником угроз не увеличивает, а чуть-чуть уменьшает — по моему скромному. «Чуть-чуть» — это на уровне отсечь соседского школьника от захода на вашу сетевую шару через «Сетевое окружение» в винде.
А в моём представлении — увеличивает. Причина в том, что вместо простого stateless стека маршрутизации, у нас теперь появляется сложная stateful штука, которая может подглядывать в протоколы, менять своё поведение в зависимости от того, что она там нашла и делать странное. Когда у вас в сети сетевое устройство, которое делает странное (потому что в природе есть такой странный протокол с тремя связными портами) — оно усложняет картину происходящего.
Что проще охранять — пустое поле или отдельно стоящие куски заборов с неизвестным количеством дверок?
Зато будут сразу взламывать прикладные протоколы на машине, что хорошего?
Файрволл от взлома прикладного протокола не помогает. Не публикуйте то, что не должно быть опубликовано — и все будет в порядке. Нат то тут причём? )
Я сравнивал чистый нат с чистым же хостом с белым адресом. Полагая надежды моего оппонента на то, что отсутствие ната немедленно заставит всех взять и настроить файрволлы… несколько безосновательными.
Все остальное требует отдельных усилий, и это понятно. Но если говорить про сугубую психологию… наверное да, эта причина возможна. Спасибо.
Поясните, пожалуйста, кто разобрался в подробностях, в чем суть уязвимости? В том, что у моего телевизора адрес 192.168.1.2 вроде бы и так не является секретом.
Снаружи что ли может что-нибудь до телевизора долететь?
Трансляция настраивается с использованием шлюза прикладного уровня (ALG) на шлюзе NAT, который нужен для работы протокола H.323. Именно в этом протоколе можно указать необходимость входящео подключения на другое устройство (для переадресации звонка). Есть и другие протоколы (FTP, например), для работы которых их ALG настраивает прием входящего подключение на шлюзе NAT, но для остальных, кроме H.323, возможна настройка переадресации подключения только на тот же хост внутренней сети, который инциировал настройку.
Chrome заблокировал TCP-порты 69, 137, 161, 1719, 1720, 1723 и 6566