Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 68
> OpenVPN
Так его же зафиксили вроде?
Так его же зафиксили вроде?
наверняка, там у меня ссылка есть community.openvpn.net/openvpn/wiki/heartbleed
смысл в том, что все приложения зафиксят, вот только далеко не везде
смысл в том, что все приложения зафиксят, вот только далеко не везде
Я не совсем понимаю, откуда такой обширный список софта? Все упомянутые уязвимые приложения по умолчанию в большинстве дистрибутивов собраны со своей копией OpenSSL? Если нет, то достаточно обновить системную бибилиотеку и на этом всё.
А как вынудить клиента (ну, например, мой телевизор) сходить на зловредный сервер?
Ну вот у меня достаточно «умный» телевизор. Какой-то Philips. Он умеет ходить в интернет, забирать себе прошивку, смотреть фильмы с DLNA серверов в локалке, вроде бы умеет YouTube…
Мне с пульта адрес вредного сервера вбить, чтоб негодяй дамп памяти телевизора забрал?
Какие технологии есть, чтобы заставить телевизор бежать на неизвестный ему доселе сервер?
Мне с пульта адрес вредного сервера вбить, чтоб негодяй дамп памяти телевизора забрал?
Какие технологии есть, чтобы заставить телевизор бежать на неизвестный ему доселе сервер?
Ах, это… ну тут всё просто, один из вариантов — ломануть Ваш любимый сайт с бесплатным видео и инжектировать туда невидимый iframe, обычная SQL-инъекция. Разработчикам ведь некогда тестировать все продукты на уязвимости, особенно бесплатные, живущие за счет вёдер рекламы в обмен на халяву. А некоторые сайты настолько погано сделаны, что там даже ломать ничего не надо. Проектная спешка, так сказать. Дальше рассказывать?
Ну, если «ломануть любимый сайт с видео» это просто, то тогда да, конечно.
Т.е. пока я сам куда-то не полезу, особо рисков нет?
Собственно, я то и спрашивал про технологический способ заставить устройство сходить куда-то принудительно.
Т.е. пока я сам куда-то не полезу, особо рисков нет?
Собственно, я то и спрашивал про технологический способ заставить устройство сходить куда-то принудительно.
основная угроза своим данным — это сам пользователь; если телек кроме своих прошивок ничего не качает, вряд ли кто-то будет Вам устраивать персональную MITM-атаку. На Youtube с телека тоже не заходите, и их ломают, но относительно быстро чинят. Хотя если кто-то ломанёт DNS с серверами обновления Philips, вот тогда веселуха может начаться, но долгой её опять же не дадут сделать. Качайте фильмы чем-нибудь пропатченным и спите спокойно.
Side note: если представить себе любой современный терминал доступа в Интернет, нафаршированный браузерами, флэшами, Java, всяческими читалками и смотрелками — это гигантские объёмы почти никем непроверенного кода. Т.е. от всех ужасов киберпространства пользователя отделяет вся эта толстая, пёстрая, но весьма дырявая компания, обновления для которой выходят дай Бог через неделю-две после публикации уязвимости.
Просто теперь сюда добавился ещё и трудяга SSL, который одной своею особо тяжкой уязвимостью перечеркнул годы относительно спокойной работы…
Side note: если представить себе любой современный терминал доступа в Интернет, нафаршированный браузерами, флэшами, Java, всяческими читалками и смотрелками — это гигантские объёмы почти никем непроверенного кода. Т.е. от всех ужасов киберпространства пользователя отделяет вся эта толстая, пёстрая, но весьма дырявая компания, обновления для которой выходят дай Бог через неделю-две после публикации уязвимости.
Просто теперь сюда добавился ещё и трудяга SSL, который одной своею особо тяжкой уязвимостью перечеркнул годы относительно спокойной работы…
Я вот только одного не пойму — а чего ж такого секретного можно украсть из телевизора? Список любимых каналов? Так пусть забирают!
логины и пароли от платных сервисов, ящиков электронной почты и т.п., если, конечно, пользуетесь ими с телевизора
Эх, 21-й век: «кража паролей с телевизора через интернет». 10 лет назад с такого бы посмеялись.
Я и сейчас ржу. Неужели есть кто-то, кто не может себе позволить почтовый агент более удобный, чем в телевизоре, но телевизор может?
Рад, что поднял Вам настроение:)
Да, MUA из телека довольно хардкорный, но не стоит так уж на одной почте зацикливаться. Я скорее ожидаю проблемы по основному фунционалу — просмотр платного видео и попадание логинов-паролей в память телевизора. Опять же, забыли пароль от личного кабинета какой-нибудь медиатеки, что мы делаем? Если гости уже собрались и стучат стаканами «кино, кино!», почему бы не «блеснуть» смекалкой и не зайти в почту за паролем по-быстрому… Да, статья переводная, и не во всех широтах любят платный контент. Но всё же повод задуматься. Хотя бы как в метафоре про украденный батон хлеба ниже…
Да, MUA из телека довольно хардкорный, но не стоит так уж на одной почте зацикливаться. Я скорее ожидаю проблемы по основному фунционалу — просмотр платного видео и попадание логинов-паролей в память телевизора. Опять же, забыли пароль от личного кабинета какой-нибудь медиатеки, что мы делаем? Если гости уже собрались и стучат стаканами «кино, кино!», почему бы не «блеснуть» смекалкой и не зайти в почту за паролем по-быстрому… Да, статья переводная, и не во всех широтах любят платный контент. Но всё же повод задуматься. Хотя бы как в метафоре про украденный батон хлеба ниже…
Я не понял, каким образом клиенты уязвимы? Видимо, сначала должно быть установлено соединение со стороны клиента, не? То есть масштаб атаки много много меньше.
А если наоборот? Например в эти выходные кто то взломал мой запароленный роутер с белой ипшкой. До этого пас не ломался несколько лет… Сходство?
Теоретически, возьмутся за клиентское оборудование. И это очень печально…
Теоретически, возьмутся за клиентское оборудование. И это очень печально…
Синьор, само собой, клиент должен открыть соединение SSL на плохой сайт, но я уже чуть выше описал, что для этого совершенно необязательно заходить на этот сайт; именно таким образом сейчас в основном и проникают в корпоративные сети — не через дыры в firewall, а через уязвимости в браузерах и плагинах, которые за этим firewall прячутся. Да, это не так вкусно, как потрясти один сервер платёжной системы, угроза размазана. Но умножьте на количество клиентских устройств и общее время экспонирования (до нескольких лет). Поэтому сейчас потрошат серверы, а через несколько месяцев, наверное, и займутся клиентами. Пока есть время запатчить всё, что нужно, и даже (при острой необходимости) купить новый смартфон:)
Ну так дырявый и два года непатченый браузер в ТВ — вкусен не меньше, не? Большая же часть консьюмерского железа куды попало не ходит. Кроме браузеров, которым одной дырой больше, одной дырой меньше…
Если сервера — это 11 из 10, то клиенты — ну 8 максимум. Может быть, даже 7. Исполнения кода нет, так что не самая фатальная проблема.
Если сервера — это 11 из 10, то клиенты — ну 8 максимум. Может быть, даже 7. Исполнения кода нет, так что не самая фатальная проблема.
купить новый смартфонА Вы так уверены, что все смартфоны на витринах уже запатчены? Я сомневаюсь даже в том, что кто-то из кастомеров шьёт на заводе сейчас новую версию SSL вместо старой. Может, через месяц-другой. В наши магазины дойдёт тогда, когда кончатся старые запасы. Или в моделях, которые сейчас планируются к выпуску.
P.S. Вот если бы какая добрая душа прописала порядок действий для блока соединений с уязвимыми/злонамеренными сайтами на роутере… Что-то типа:
-- получили запрос от клиента;-- упреждающее соединение с сервером, тест;-- если тест положительный, отправляем клиенту TCP-RESET, сайт на час в чёрный список,только в конфигах и примерах.
А Вы так уверены, что все смартфоны на витринах уже запатчены?Что Вы, нет, конечно:) Чтобы было легче выбирать, см. также соседний топик habrahabr.ru/company/eset/blog/219111/
Вот если бы какая добрая душа прописала порядок действий для блока соединений с уязвимыми/злонамеренными сайтами на роутере…Это функционал Network IPS, решений для бизнеса; либо защитного веб-шлюза с функциями раскрытия SSL.
Уверяю, дома запатчить все девайсы выйдет дешевле.
Впрочем, если роутер под *nix, можно посмотреть в сторону www.snort.org
Я не копал глубоко, потому что *nix не использую. Погуглите что-нибудь из серии «snort heartbleed»
Чтобы было легче выбиратьКак раз 2 недели назад купил ((
либо защитного веб-шлюза с функциями раскрытия SSL.Вот как раз это я могу сделать хоть завтра, так как раскрывать SSL (а точнее проксировать их) умеет тот же squid, но он не может проверять валидность сертификатов сайтов (если я правильно понял его документированный конфиг) и возможен MITM.
Блоком может заняться iptables (-m recent), а вот предсоединения выполнять некому — городить tcpdump с парсингом его выхлопа как-то неохота, а -j ULOG что-то не хочет работать.
Погуглите что-нибудь из серии «snort heartbleed»snort пока только «в курсе», последний релиз январский, но спасибо, буду следить.
Squid и безопасность — примерно как солёные огурцы и молоко, хороши по отдельности. Если справитесь с этим глюкалом и соберёте его на новом OpenSSL, то закрыть от Heartbleed он должен. Можете для более крепкого сна еще SSL heartbeat выключить. Но только учтите, что сертификат УЦ, которым будут теперь подписаны все сертификаты сайтов, должен стать доверенным на всех клиентах, включая браузеры смартфонов, всякие ВКонтакты, банк-клиенты, Gmail и т.д. (но см. ниже про исключения!) А все секреты Ваши теперь бегают в открытом виде внутри еще одного сервера. И если вдруг ни с того, ни с сего перестал работать, например, Skype, или TeamViewer — не удивляйтесь, это Ваша система безопасности пытается их досмотреть и испытывает облом. Когда попробуете всё это собрать, прописать исключения на всё, что надо (те же банк-клиенты, Google), протестировать, выслушать от домашних («почему у меня почта не открывается???!!»), то поймёте, почему так просто знающие люди забираются в корпоративные сети:)
Если смартфон на Android, посмотрите сюда: habrahabr.ru/company/eset/blog/219111/
Может, не так всё плохо.
всех благ
Если смартфон на Android, посмотрите сюда: habrahabr.ru/company/eset/blog/219111/
Может, не так всё плохо.
всех благ
Сам себе и отвечу:
всё немного проще, оказывается, SSL-HEARTBEAT идет открытым текстом, соответственно, можно обойтись одним iptables:
Оригинальный пост здесь.
всё немного проще, оказывается, SSL-HEARTBEAT идет открытым текстом, соответственно, можно обойтись одним iptables:
Отражаем в логе все heartbeat-запросы при помощи iptables и модуля u32:
iptables -t filter -A INPUT -p tcp --dport 443 -m u32 --u32 "52=0x18030000:0x1803FFFF" -j LOG --log-prefix "BLOCKED: HEARTBEAT"
Блокируем heartbeat-запросы:
iptables -t filter -A INPUT -p tcp --dport 443 -m u32 --u32 "52=0x18030000:0x1803FFFF" -j DROP
Отслеживаем возможные атаки при помощи Wireshark:
tshark -i interface port 443 -R 'frame[68:1] == 18'
tshark -i interface port 443 -R 'ssl.record.content_type == 24'
Оригинальный пост здесь.
Пффф, а если HeartBeat будет послан после установки TLS «рукопожатия», в течении SSL сессии?
поясните, пожалуйста, как можно послать HeartBeat до «рукопожатия», чтобы мы поняли разницу
Я не говорил ДО. Ведь кроме ДО и ПОСЛЕ, есть еще ВО ВРЕМЯ ;) См. первый PoC на питоне который был. Начинаем рукопожатие с Хелло, и сразу же HeartBeat. Протокол Рукопожатия еще не завершился, но HeartBeat уже оформился. Кстати, правило-то сработет, так как оно блочит по заголовку, а он не зашфирован, если я не путаю. Так что не важно, во время или после…
Я смутно разбираюсь в этом, но как иначе? Какой смысл удерживать соединение, если оно не полностью инициировано? Просветите, пожалуйста.
Вообще — за что купил, за то и продал. На практике не проверял, применил к своим правилам, за сутки ни единого срабатывания )). Ссылка на оригинал приведена внизу коммента, а я в теме не рублю, поверил на слово.
Вообще — за что купил, за то и продал. На практике не проверял, применил к своим правилам, за сутки ни единого срабатывания )). Ссылка на оригинал приведена внизу коммента, а я в теме не рублю, поверил на слово.
Ответил выше, там блок тупо по типу заголовка. Так что сработает в любом случае.
меня смутила ваша фраза «SSL-HEARTBEAT идет открытым текстом». Дата идет открытым текстом только если HB запрос во время handshake, а если после, то данные зашифрованны. НО заголовок-то с типом пакета — он не шифруется, если я все верно помню.
Извиняюсь, если ввёл в заблуждение, в оригинале такого нет, это мои домыслы, я был уставший, пьян и вообще это был не я, а брат-близнец, известный на весь город разгильдяй :)
насколько можно судить из описания, в TLS Record заголовочный байт Content Type с интересующим значением 0x18 (Heartbeat) всегда передаётся открыто, и на этом построен метод; для снижения вероятности ложно-позитивных срабатываний добавляется ещё и условие Major Version = 0x03. Теоретически можно для более крепкого сна добавить ещё условие на следующий за ним байт Minor Version 0,1,2,3. Дальше уже идёт непредсказуемая двухбайтная длина и само закрытое сообщение. Так что должно сработать.
Чтобы поставить это на «реверс» (для защиты клиентов от плохих серверов, работающих на порту 443), в теории
Чтобы поставить это на «реверс» (для защиты клиентов от плохих серверов, работающих на порту 443), в теории
--dport 443 меняется на --sport 443, но я не проверял.как я понимаю, это правила для защиты серверов от «плохих» клиентов (а не клиентов от плохих серверов) и могут быть интересны коллегам в соседних топиках по данной проблеме; как раз подобные функции я ожидаю и от промышленных систем IPS, и от бесплатных типа SNORT. Конечно, ввинтить пару правил для iptables проще.
На самом деле, есть у этой истории и интересное продолжение в виде потенциальной DoS-атаки на систему регистрации (-j LOG), поэтому использование такой заплатки в «голом» виде дома может быть неприятным, а на нагруженных серверах даже опасным. Кому интересно, можете почитать seclists.org/fulldisclosure/2014/Apr/143
Если попытаться повернуть это правило на «реверс» и защитить клиента от плохого сервера, появляется теоретическая вероятность ложных срабатываний на не-TLS трафике, намеренно идущем через порт 443 и содержащим контрольный маркер по определенному смещению.
Если попытаться повернуть это правило на «реверс» и защитить клиента от плохого сервера, появляется теоретическая вероятность ложных срабатываний на не-TLS трафике, намеренно идущем через порт 443 и содержащим контрольный маркер по определенному смещению.
Мне вот еще что интересно. По сути уязвимость позволяет получить 500 рандомных байт з ОЗУ цели, так?
То есть, чтобы скачать гиг ОЗУ хотя бы на 90% необходимо получить (и заставить клиент отдать) гиг 20 данных? И если пользователь в этот момент закроет вкладку браузера, то передача остановится?
То есть, чтобы скачать гиг ОЗУ хотя бы на 90% необходимо получить (и заставить клиент отдать) гиг 20 данных? И если пользователь в этот момент закроет вкладку браузера, то передача остановится?
Начитались комиксов, блин. 64к за запрос, а не 500 байт.
И не «гиг ОЗУ», а .data у активного процесса.
И не «гиг ОЗУ», а .data у активного процесса.
Ну простите, я вебщик.
Средний размер памяти, что жрет файрфокс — 500 метров. Это та дата?
Средний размер памяти, что жрет файрфокс — 500 метров. Это та дата?
Да. Вопрос про отношения процессов табов и открытых коннектов (через которые может использоваться уязвимость) открыт. Если у каждого таба свои сокеты и отдельный процесс, то доступны будут данные только этого таба. Если коннекты один процесс, а рендеринг табов — другой, то уязвимы будут ошметки данных коннектов всех активных табов.
У Хрома, емнип, своя память на каждый таб (и соотв. коннекты). Из песочницы можно выйти, но только через уязвимости. У последних IE вроде аналогично. А вот у FF, как я понимаю, все в одной куче.
Хромиум, ФФ, и все построеные на них браузеры используют реализацию SSL из библиотеки NSS, поэтому они в безопасности.
пока…
Хромиум, ФФ, и все построеные на них браузеры используют реализацию SSL из библиотеки NSS, поэтому они в безопасности.
Тогда как обычный пользователь, сидящий с ПК, может облажаться с этой уязвимостью? Именно реальный сценарий хочу понять
Кроме упомянутых выше браузеров, ещё Internet Explorer не использует OpenSSL, но на счёт других браузеров (Opera, Safari, Android Browser) я не так уверен. Большинство приложений, умеющие что-нибудь делать в облаке (тот же Dropbox, например) используют SSL. Кроме того, есть ещё мобильные аппы которые могут фигачить REST запросы по HTTPS.
Ну Дропбокс только со своим сервером общается, который мы считаем безопасным (раз уж установили их клиент), разве нет?
Мобильные аппы — тоже к своим серверам, а не случайным.
Мобильные аппы — тоже к своим серверам, а не случайным.
Опера Presto использовала OpenSSL — у них он в титрах упоминается. Новая Опера на Chromium, который использует NSS.
Опера Presto использовала OpenSSL, но не heartbeat:
blogs.opera.com/security/2014/04/heartbleed-heartaches/
blogs.opera.com/security/2014/04/heartbleed-heartaches/
Или heap, а не .data?
На самом деле, упомянутый тут смартфон — более серьезная проблема, чем Smart TV. Довольно живая дискуссия по проблеме клиентских устройств, и достаточно близко к теме: habrahabr.ru/company/eset/blog/219111/ (с лёгкими элементами флейма)
Дискуссия «полное раскрытие VS тихие фиксы» стара примерно столь же, сколь и уязвимости вообще. ;)
Вполне может быть, что если бы её оставили в покое, никто бы и не почесался ещё столько же.
Вполне может быть, что если бы её оставили в покое, никто бы и не почесался ещё столько же.
Массово использовать уязвимую версию начали с декабря прошлого года. Соответственно период — около 4 месяцев. Судя по тому, что каких-то массовых компрометация, в стиле «Пароли всех пользователей Dropbox, скачать бесплатно без смс» за это время не было, можно предположить, что если уязвимостью и пользовались, то точечно.
Для проверки клиентских систем есть ReverseHeartbleed.com
С каких пор nginx в клиенты записали? Реверсивное проксирование != прокси-сервер, у nginx нет «режима прокси-сервера» и работа с untrusted бэкендами не поддерживается в принципе.
Вопрос, как говорится, не в бровь, а в глаз. У автора оригинала, к сожалению, спросить сейчас не могу.
А если учесть ещё SSL termination, то nginx очень даже клиент: nginx.com/products/feature-matrix/
Я чего-то упустил?
in proxy mode, leaks memory of previous requestsрискую предположить следующее: (А) имеется в виду «in reverse proxy mode» и (Б) nginx, стоя на «реверсе», по факту работает сервером пользователю и клиентом бэкенду.
А если учесть ещё SSL termination, то nginx очень даже клиент: nginx.com/products/feature-matrix/
Я чего-то упустил?
Ключевое тут «работа с untrusted бэкендами не поддерживается в принципе». Попытка использовать nginx в таком виде может быть только на свой страх и риск.
А если учесть ещё SSL termination, то nginx очень даже клиент: nginx.com/products/feature-matrix/Хотя после вышесказанного это уже не существенно, но замечу, что «SSL termination» обычно предполагает, что на бэкенд ходят уже без SSL. =)
Коль скоро это только реверсный прокси и только на одностороннюю терминацию SSL, то сюда можно притянуть за уши раскрытие (серверной атакой) содержимого запросов, которые ходили через nginx, когда он уже выступал клиентом trusted бэкенда. Получается использование серверной уязвимости, т.е. nginx не совсем из этого топика. Вообще, nginx вряд ли относится к теме бытовых угроз для «простого пользователя».
«SSL termination» обычно предполагает, что на бэкенд ходят уже без SSL.И тут Вы скорее правы, в балансерах обычно так (а речь именно о них), но в защитных forward proxy терминация как раз двусторонняя (прокси и как SSL-сервер, и как SSL-клиент). Назовём это отраслевой вариативностью:) И хотя можно всякого нагуглить по строке «nginx forward proxy», чаще всего я вижу обломы как раз из-за HTTPS. Не собираюсь даже пробовать, Кесарю — кесарево.
Да, притянуто за уши, с тем же успехом туда можно вписать Apache c mod_proxy. Автор скорее всего не особо разобрался в вопросе, а нахватал всего подряд из упомянутых источников, которые также доверия не вызывают.
Ну а как в список «Client applications that are currently reported as vulnerable are» (в оригинале речь именно о «Client applications») попала MariaDB?
Ну а как в список «Client applications that are currently reported as vulnerable are» (в оригинале речь именно о «Client applications») попала MariaDB?
Да и вообще это большая ошибка говорить об «уязвимых приложениях». Сами по себе приложения не содержат уязвимого кода, их уязвимость может зависеть только от OpenSSL, которая используется (если вообще используется, почти все указанные приложения могут быть собраны без OpenSSL) и уж тем более некорретктно указывать конкретные версии. Почему именно эти версии? Чем они уязвимее других?
Автор скорее всего полный профан в вопросе.
Автор скорее всего полный профан в вопросе.
Это вопрос того, как собирались приложения: статикой или динамикой. С учётом совершенно непредсказуемого потока дистрибутивов может быть всё, что угодно, согласны?
Автор, вероятно, просто хотел дать страшилки в виде невинных, часто используемых приложений, которые лично ему попались собранные статикой, определенной версии. Не будем его слишком строго за это судить, тут главное — тематика клиентских уязвимостей.
Автор, вероятно, просто хотел дать страшилки в виде невинных, часто используемых приложений, которые лично ему попались собранные статикой, определенной версии. Не будем его слишком строго за это судить, тут главное — тематика клиентских уязвимостей.
Ну, ведь клиент у MariaDB есть? И он может по SSL работать? Значит, уязвим:)
Со сценарием атаки, конечно, сложнее, у меня как-то образ вредоносного сервера БД, который «охотится» на своих клиентов в голове не очень укладывается.
Сделаем так: я размещу ссылочки сверху из топика на наши с Вами комментарии, чтобы гости могли сразу сориентироваться.
Со сценарием атаки, конечно, сложнее, у меня как-то образ вредоносного сервера БД, который «охотится» на своих клиентов в голове не очень укладывается.
Сделаем так: я размещу ссылочки сверху из топика на наши с Вами комментарии, чтобы гости могли сразу сориентироваться.
Да, статья безусловно будет полезна простому пользователю. Дам почитать её своей бабушке, которая, как всякий простой пользователь, начинает свой день с того, что сразу после загрузки kde, подключается vpn-ом к разным анонимным серверам, которые нетипично используют nginx в качестве forward proxy, затем запускает links в поисках того, что можно скачать wget-ом, при этом делая ряд запросов curl-ом, клонирует несколько проектов из всяких сомнительных git-репозиториев, делает в них правки и push-ит изменения обратно (и что там утечет интересно? сам push утечет на сервер на который и push-ат?). И в завершение дня, конечно нужно запустить некоего консольного клиента к MariaDB из которого сначала соединиться к своему личному серверу БД, сделать там ряд запросов, а потом ещё к ряду сомнительных в том же процессе.
Теперь переживаю за пенсионера. =)
Теперь переживаю за пенсионера. =)
Ваша бабушка на пенсии ИТ-аутсорсингом случайно не подрабатывает? Дай Бог ей здоровья и долгих лет жизни в любом случае. Моя вот уже не подрабатывает.
Я бы дал почитать статью своему племяннику, если бы он у меня был; и сопроводил бы небольшой лекцией о том, почему надо скачивать обновления на те устройства, которые хоть как-то подключены к Сети. При всём уважении, второстепенные вещи ngix и MariaDB Вы тут уже вырываете из контекста, откидывая всё остальное.
Я бы дал почитать статью своему племяннику, если бы он у меня был; и сопроводил бы небольшой лекцией о том, почему надо скачивать обновления на те устройства, которые хоть как-то подключены к Сети. При всём уважении, второстепенные вещи ngix и MariaDB Вы тут уже вырываете из контекста, откидывая всё остальное.
о, простите, не посмотрел на Ваш профиль, Вам nginx явно не второстепенный…
как обычно в таких случаях, признаю, что Ваши доводы про nginx обоснованы, но предлагаю больше не мусолить эту тему, коллега; зато теперь я знаю, куда мне обращаться по вопросам nginx:)
как обычно в таких случаях, признаю, что Ваши доводы про nginx обоснованы, но предлагаю больше не мусолить эту тему, коллега; зато теперь я знаю, куда мне обращаться по вопросам nginx:)
Имеем неприятное сочетание уязвимости Heartbleed со спецификой встраиваемых (embedded) устройств, которые могут не обновляться вообще никогда.
Подозреваю, что часть встраиваемых устройств еще и до уязвимой версии ssl обновиться не успела, так что их пользователи могут спать спокойно :D
Нехороший сайт сможет запросто выпотрошить память клиента — недопатченного браузера, смартфона, планшета, слишком умного телевизора, видео- или игровой приставки, и т.д. Всякое устройство, способное загружать веб-страницы (включая ваш домашний Linux), и при этом обрабатывающее конфиденциальные данные — это цель, и порой на долгие годы.
Вот по этой причине негоже светить в интернет таким устройствам для всех подряд. На эту тему я написал своеобразный ликбез: Пример безопасной настройки домашней локальной сети Не панацея, но много проблем решает. В том числе и перебор дефолтных паролей
Идея устроить дома периметр с VLAN'ами и с ограниченным выходом в целом здравая, спору нет.
И да, латышский роутер весьма интересен и понятен многим *никсоидам. Функция «простукивания» должна уберечь от атак снаружи. Лично мне там не очень понравилось черезчур лобовое использование iptables, без попытки обвязать их должным образом и сделать хотя бы аппроксимацию «зон безопасности» (как в нормальных брэндмауэрах). Тот же SuSE Linux это умеет делать аж с… даже не помню, столько лет прошло. Впрочем, это оффтоп.
Но спросите себя сами: сколько обычных пользователей захотят себе такое развлечение дома? Бытовая угроза — она на то и бытовая, что целью является обычный, среднестатистический потребитель. Один мой приятель двойной Ethernet протянул по всем комнатам (коих две штуки), причём шестой категории. Только он вряд ли справится с микроштыком даже по Вашему подробному ликбезу, хоть и продаёт решения безопасности.
И да, латышский роутер весьма интересен и понятен многим *никсоидам. Функция «простукивания» должна уберечь от атак снаружи. Лично мне там не очень понравилось черезчур лобовое использование iptables, без попытки обвязать их должным образом и сделать хотя бы аппроксимацию «зон безопасности» (как в нормальных брэндмауэрах). Тот же SuSE Linux это умеет делать аж с… даже не помню, столько лет прошло. Впрочем, это оффтоп.
Но спросите себя сами: сколько обычных пользователей захотят себе такое развлечение дома? Бытовая угроза — она на то и бытовая, что целью является обычный, среднестатистический потребитель. Один мой приятель двойной Ethernet протянул по всем комнатам (коих две штуки), причём шестой категории. Только он вряд ли справится с микроштыком даже по Вашему подробному ликбезу, хоть и продаёт решения безопасности.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Чем ещё грозит Heartbleed простому пользователю?