Comments 163
Обожаю красное на синем, так приятно читать.
Да уж… Вот это проблеееема… Стандартный хостинг не подойдёт. Можно спать спокойно.
[/sarcasm]
А уж хелпер к PowerDNS написать не дольше, чем javascript для этой атаки.
bash скрипт в cron, который переписывает зону и обновляет честный KnotDNS
Это точно сработает на обычном хостинге?.. cron, который я знаю (как функция в панели), сделан для запуска php-скриптов (хотя может вы и правы, и bash-скрипты исполнять тоже можно, но мне почему-то кажется, что это будет запрещено политиками безопасности). Но даже в этом случае, нам нааверное нужно знать, какой именно DNS сервер использует хостер. Это можно как-то узнать без помощи техподдержки? Опять же, должно быть всё настроено так, чтобы файл конфигурации DNS сервера допускал модификацию пользователем, от которого запускается cron и bash интерпретатор (или чтобы DNS сервер допускал модификацию зон по команде, принятой от нашего скрипта — хотя раз он принимает такие запросы от ISP Manager, то чего бы не принять и от другого процесса, наверное). Тут надо уже у админов спрашивать, которые шарят в линуксе.
На shared, кажется, любой форум и любой WordPress научились cron симулировать, но если есть работающий в браузере скрипт, то проще XHR из браузера сделать.
К услугам нищебродов DynDNS, в котором можно явно указать IP, а также Яндекс.ПДД и т.п.
На shared, кажется, любой форум и любой WordPress научились cron симулировать
Вот это не понял. Каким образом?
Самые дешёвые VPS уже не 100MHz с 16Мб памяти как 10 лет назад. VPS и есть обычный хостинг IMHO.
Характеристики повыше, а цены всё так же кусаются. Тем более, хороший сервис у зарубежных провайдеров, а там цены в долларах или евро. Они и раньше-то были не особо низкими, а с тех пор ещё и курс скакнул. Обычный хостинг я могу найти за 80-100 рублей в месяц, если постараться, максимум за 120. VPS — от 380-400 сейчас (самый фиговый, отечественный). Нормальный — где-то 120-150 долларов в месяц, кажется. Но надо пересмотреть цены, давно не изучал рынок.
VPS — от 380-400 сейчас (самый фиговый, отечественный).
Самый-самый фиговый 90, а не так, чтобы очень фиговый 200-250 начинается. OpenVZ вполне доступные.
И для чего нормальные? Если жырную джаву гонять, ну да, джависты должны страдать. Платить и платить. С OpenVZ джаву попрут. Что трасирующая сборка мусора, что майнинг, одинаково расточительное использование вычислительных ресурсов. Софт, который тут уже успели насоветовать, этой проблеме не подвержен, ему роутеров хватает, не то, что современных хостингов.
У зарубежных хостингов именно самых дешёвых, кажется, нет, но те, которые у них самые дешёвые, временами предлагают сказочные характеристики. Есть один латвийский OpenVZ с 512Мб RAM (на OpenVZ нельзя ходить в своп), но 1Тб HDD. Есть германский за 7 евро в месяц с 6Гб RAM, 2 ядра, KVM, 500Гб HDD. Оверселлинг, да, но, кажется, всё работает вот уже который год. Со всеми скачками курса не знаю отечественного, чтоб мог так же, и чтоб как-то это всё же работало.
Вот это не понял. Каким образом?
Если сайт не оставляют надолго в покое посетители или хотя бы поисковики, то сделать блокировку через базу данных и выполнить код в примерно необходимое время возможно. Куча движков это умеет.
Вы говорите о довольно простом механизме — сохранять куда-нибудь время исполнения задачи и саму задачу, и запускать это всё по достижению заданного времени — но вместо крона сам PHP-скрипт инициируется посетителем сайта. Можно это в скрытом айфрейме сделать или через XHR, чтобы у юзера не «висела» основная страница. Да, это можно, но это не совсем «крон» :)
Тут вопрос в другом — если нам нужна системная команда, а не запуск ещё одного PHP-скрипта, то не все системные команды могут быть разрешены настройками безопасности (даже на уровне php.ini), если у нас не VPS.
И для чего нормальные? Если жырную джаву гонять, ну да, джависты должны страдать. Платить и платить. С OpenVZ джаву попрут. Что трасирующая сборка мусора, что майнинг, одинаково расточительное использование вычислительных ресурсов. Софт, который тут уже успели насоветовать, этой проблеме не подвержен, ему роутеров хватает, не то, что современных хостингов.
Проблема не только в джаве. Я вот, например, поднимал в своё время Icecast2 и PHP-FPM для своих нужд. И там автор книги по FreeBSD настаивал на мысли, что «правильнее компилять самому пакеты из исходников, убирая все лишние модули и подключая нужные, чем ставить готовый бинарник». А компиляция — процесс очень тяжёлый. И на медленном VPS он будет длиться часы, буквально.
Есть германский за 7 евро в месяц с 6Гб RAM, 2 ядра, KVM, 500Гб HDD
Очень щедрые характеристики за такую сумму)
Я когда последний раз искал VPS для какого-то проекта, это было весной 2015-ого, вроде. На эту компанию не натыкался. Вы её название не запомнили
UPD: сейчас бегло поискал в гугле. Одна из ссылок в первой двадцатке (европейский провайдер): www.vps.net/products/instant-servers
17$ в месяц. Такое себе… Причём ресурсы тоже не фонтан.
Полагаете, есть энтузиасты I2P, которые не ставят пароль на админку?
Плюсом туда же локально развернутые базы данных, например тот же MySQL 3306, или часто встречал Firebird (типа sqlite) с тоже открыто слушающим портом и дефолтными логином пасс sysdba:masterkey.
А IP машины за NAT на самом деле можно определить:
xakep.ru/2015/01/29/webrtc-leak
xakep.ru/2014/01/24/61942
Если IP машины 10.137.71.хx то скорее всего IP маршрутизатора 10.137.71.1.Try failed, 35143 more addresses to check.
Можно же ещё делать трюк сл вставкой картинки img src ="http://10.137.71.2:80/image.jpeg", и если картинка загрузилась быстро, значит кто-то на том конце ответил "ошибка", или принудительно разорвал соединение. Если картинка грузилась долго, то скорее всего сработал timeout. Если мы целимся на конкретный сервис, то заранее можем узнать как он себя ведёт при таком запросе картинки.
Это вроде бы не должно уже работать (иначе любая страничка может угадать все посещенные порносайты).
Rebinding здесь не поможет, потому что юзер не ходил на pew.hacker.com/admin.php, даже если оно сейчас резолвится в роутер.
(Вот атака на localhost — это да, это сурово — не верьте localhost, просто не верьте).
Оно действительно более безопасно — в том смысле, что защита в любом случае должна быть многослойной, и NAT честно добавляет ещё один слой, усложняющий доступ.
Боюсь, честный https плюс авторизация по случайным паролям для всех локальных сервисов/устройств — пока что фантастика, причём в стиле рассказа про хакера и столовую. Скорее всего в таком стиле это в принципе никогда не реализуют, слишком неудобно будет пользоваться, и такие "безопасные" устройства купят 2.5 параноика.
А он вообще наступит, этот мир IPv6? В смысле, при нашей жизни? Потому что пока не начнут массово появляться IPv6-only сервисы, причём достаточно популярные и нужные обычным юзерам, текущее состояние (не)поддержки IPv6 может сохраняться неопределённо долгое время.
Сейчас вся индустрия проедает запасы ipv4. Они ещё есть, куда большие, чем ожидал RIPE NCC и IANA, но очевидно, что примерно 3 миллиарда адресов не достаточно для обслуживания 7.5 миллиардов человек (нам же не только и не столько человекам адреса надо выдавать, а железкам и серверам).
Если что, вот нерозданные адреса. Это не то, что нахомячили провайдеры, но всё равно тренд понятный:

Обратите внимание, даже непочатый в 14ом году AFRINIC уже похож на RIPE, а сам RIPE, хоть и самый экономный, но тоже сильно дальше 21ого не пытается. Если верить вот этим товарищам (https://ipv4marketgroup.com/broker-services/buy/), то цена колеблется от 26 до 17 баксов за IP (в зависимости от размера цены). И это довольно много (/24 — $6.5k, /16 — больше миллиона баксов).
Самая мякотка в том, что это не атака на нат. Это атака на проникновение внутрь периметра фаервола. NAT traversal идёт бонусом
А такие вообще есть? iptables такого, вроде бы, не умеет. А то мы договоримся до волшебных файрволов, которых никто не видел, но которые "должны" блокировать 100% любых атак на защищаемую сеть.
The Cisco ASA, PIX and FWSM Firewalls have several features that can be utilized to minimize attacks against the DNS protocol. The following subsections will provide an overview of these features and the capabilities they can provide.
…
DNS Guard
Beginning with software release 7.0(5) for Cisco ASA 5500 Series and Cisco PIX 500 Series, and software release 4.0 for the FWSM the DNS guard function can be controlled through thedns-guard global configuration or the dns-guard parameters submode command for policy-map type inspect dns. For Cisco ASA 5500 and Cisco PIX 500 Firewalls that are running releases prior to 7.0(5) and for the FWSM Firewall releases prior to 4.0, the DNS guard function is always enabled, and it cannot be configured through this command. The configuration of this feature, when configurable, will be detailed later in the feature configuration section.
Сам не щупал, не скажу.
И могу сразу предложить антидот. Во всяких TP-LINK есть волшебные адреса, которые типа заменяют IP. И у TP-LINK их домены прокисают, а они ещё новые покупают, надо список поддерживать постоянно, если прямо хочется заморочиться. Также за счёт всяких NetBIOS есть шанс отрезолвить dlink.workgroup, но это не точно.
Так вот, если вместо A 192.168.0.1 отдать CNAME, дальше оно отрезолвится на роутере «куда надо» в обход безопасного, стоящего после роутера DNS.
Собственный сервер и так анонсируется по DHCP, так что здесь роль файрвола не в защите от DNS rebinding, а в блокировании доступа к сторонним DNS в обход своего, в чём нет необходимости пока кто-то не попытается "выстелить себе в ногу" прописав себе ручками внешний DNS — но таких защищать обычно смысла нет, они с тем же успехом могут и VPN поднять наружу, и тогда такое перенаправление DNS-трафика в iptables уже не спасёт.
Отдельно упомяну 3D принтер на основе OctoPrint. При закрытии паролем он теряет самую удобную функцию — печать по сети прямо из слайсера.
Всякие вай-фай лампочки тоже мало заморачиваются безопасностью. Так что это не выход: LAN должен быть безопасным.
Наверное, это можно вылечить настройками в реестре. Но до прочтения этой статьи мне и не нужно было ставить пароль. Я пробовал это сделать для защиты от малвари, но в итоге защитился иначе — теневой копией на самом NASе через btrfs snapshot. Так что вопрос с безопасностью LAN нужно решать сразу целиком, я не хочу разводить в своём хозяйстве бюрократию как на границе (с дырами как там же).
На самом деле самая главная проблема в том, что кто-то решил, что выполнять что-то на машине клиента — это достаточно безопасно, если это "что-то" немного в чем-то ограничить.
И да, на 127.0.0.1 обычно куча всего висит без авторизации, но с ограничением по источнику.
Правильно ли я понял что CSP и CSRF защиты в веб-сервере устройства достаточно чтобы закрыть такого рода уязвимость?
а что мешает заставлять пользователя делать запрос на адрес вроде 192.168.х.х. напрямую, без плясок с DNS
Запрос отправить можно. Как ответ прочесть без валидного CORS?
Access-Control-Allow-Origin:*
.Как браузер определит можно ли слать запрос без получения ответа от сервера?
С более сложными (если например надо менять content-type на application/json) — сначала отправляется «preflight request» методом OPTION для получения разрешения на отправку основной части запроса. Для обычных post/get такого не делается.
По-хорошему сервер не должен выполнять вообще никаких операций, если не передан валидный токен сессии. При первом запросе такого токена у нас, конечно же, нет (весь пример с роутером строится вокруг того, что пользователь мог установить слишком простой пароль).
Вот здесь https://developer.mozilla.org/en-US/docs/Web/HTTP/Cors можно почитать подробнее.
Если кратко, "простые" запросы выполняются сразу, просто к ним добавляет ся заголовок Origin, и проверяется, что сервер ответил корректным Access-Control-Allow-Origin
Итак, давайте резюмируем вышесказанное:
- Пользователь посещает сайт, получая реальный IP-адрес и короткий TTL
- Находясь на сайте, браузер делает обращения к тому же домену, где находится пользователь. Как только истекает время жизни кэша, браузер снова запрашивает IP домена.
- Далее наш DNS-сервер выдает вместо настоящего адреса, IP-адрес внутреннего сервиса (в нашем случае – роутера)
- После запрос идет по домену на роутер, а результат нам отправляет подгруженный заранее пользователем javascript.
Что-то я не совсем понимаю, как это работает, в частности четвёртый шаг. Как скрипт может отправить нам результат на pew.hacker.com
, если тот уже указывает на IP-адрес роутера, полученный на третьем шаге? Разве запрос с отправкой результата не уйдёт опять на роутер? Или здесь схема сложнее и скрипт сначала сохраняет данные на клиенте, а через 59 секунд новый DNS-запрос снова возвращает IP-адрес злоумышленника и только потом скрипт отправляет ему собранную полезную нагрузку?
Эм, но разве браузер не заблокирует междоменный запрос? Суть ведь этих плясок именно в том, чтобы протокол, домен и порт не менялись. Да и в статье упирается, что запрос отправляется на тот же самый домен:
На следующем этапе сервер отвечает HTML-страницей с javascript кодом, обращающимся на наш же домен.
Отправлять данные мы можем (get-ом так точно, хотя в принципе можно и post-форму скрафтить в iframe-е), читать не можем только.
А я сейчас вот что подумал: если пользователь после ребинда нажмёт F5, то будет эпик-фейл, он увидит админку роутера (ну или того, куда его там ребинднули)? Ведь шансы на это ненулевые?
Jsonp в помощь хакеру. Просто генерирует на странице
document.write('')
Дёшево, сердито, надежно
Скрипт запущен на домене pew.hacker.com. Он получает чувствительные данные, отправляя запрос на pew.hacker.com (IP которого теперь ведёт на локальную сеть), а результат сбора отправляет на report.hacker.com (IP которого ведёт на сервер злоумышленника). Запрос на report.hacker.com возможен, если report.hacker.com добавит в ответ заголовок access-control-allow-origin: *
.
Как можно защититься от такой атаки?
Я вижу такой вариант:
Свой DNS сервер, который имеет белый список доменов, которые могут резолвится в IP из приватных диапазонов (192.168.0.0/16, 10.0.0.0/8 и т. д.). Остальные резолвы, приходящие из внешних источников он игнорит и не передаёт конечному устройству.
--stop-dns-rebind
.Недостаток в том, что некоторые провайдеры с локальной сетью отдают IP-адрес из внутренней сети на некоторые домены, и такие домены перестают открываться вовсе.
Недостаток в том, что некоторые провайдеры с локальной сетью отдают IP-адрес из внутренней сети на некоторые домены, и такие домены перестают открываться вовсе.
У dnsmasq есть опция --rebind-domain-ok (--rebind-domain-ok=/домен1/домен2/домен3/), позволяющая явно указать домены, для которых защита от ребиндинга будет отключена.
Но всё это бесполезно, если используются локальные прокси.
Чем они помешают? Я не очень понял проблему.
хотя точно не помню уже, могу ошибаться в деталях
По моему это уже из области фантастики. Сейчас самый захудалый роутер, как только любой юзверь пытается «сам настроить» сходу через мастера настройки вопит «смени пароль». Или не?
А я смотрю вы оптимист. Зайдите как нибудь на scanhub.shodan.io
Там не только роутеры в интернет торчат с admin:admin, но и айпи камеры, факсы, и прочая IoT херня от наших китайских колег.
И полностью согласен с комментарием popov654.
Дома зухель простенький 5 лет оттарабанил, как установил с дефолтными настройками так и работал.
И не сможет тогда ввести тестовый домен Стива Гибсона (а равно и прочие злохитренные волкИ) систему вашу компьютерную во искушение:
было:

стало:

Краткое описание, если интересна сия информация
;-)
Ни для кого не секрет, что многие рядовые пользователи не меняют стандартные пароли от админ-панелей своих роутеров
Как бы нормальный роутер при настройке принудительно просит ввести вручную пароль. Так что такой номер не пройдёт в случае правильного девайса
Здесь проблема кроется во всё том же JSON-RPC, который мы рассмотрели чуть выше. В данном случае он позволяет изменять пользовательские настройки, например, изменять папку для загрузки файлов
То есть он сам себе сервер, висящий на localhost? Это же не WebControl для управления клиентом по сети через браузер, который обычно по умолчанию выключен. Зачем там вообще JSON-RPC?
С uTorrent сейчас попробовал — там во-первых порт у каждого свой, он генерируется при установке, а во-вторых мне возвращает текст «invalid request» вместо содержимого файла при указании адреса с моим портом…
Вакцина в конфиг:
private-address: "192.168.1.0/24" ### Block attack DNS rebinding
private-domain: "home.lo" ### Block attack DNS rebinding
Первая опция объявляет ресолверу наши приватные IP-адреса. (немаршрутизируемая сеть)
Вторая опция объявляет наш локальный домен, которому можно ресолвиться в адреса нашей локальной сети.
Обе опции можно дублировать, если ресолвером обслуживается несколько сетей. (ремарка, в мультидоменных сетях для недопущения пересечений используйте технологии VLAN 802.1Q)
Для любых не перечисленных в конфиге доменов ответы содержащие немаршрутизируемые адреса будут отброшены нашим ресолвером.
Важно! Для поддержания локального домена unbound не годится. Необходим любой авторитарный сервер. В качестве авторитарной пары к unbound рекомендую nsd.
P.S.: Для bind9 будет чуть сложнее. Постараюсь позже описать реализацию.
Важно! Для поддержания локального домена unbound не годится.
Вот здесь не понял. Что значит для поддержания? Поясните плиз. Вот у меня есть мой личный домен, в качестве DNS-хостинга я использую бесплатный ZoneEdit. IP там прописан мой собственный, домашний. Кстати, он ресолвится во внешний IP, так что тут вообще походу беспроблемный случай.
Я тогда вообще не понял, для каких кейсов ваша инструкция применима :)
В отличии от, например, bind'а который умеет и то и то (от чего случалась масса проблем при неправильной настройке)
deny-answer-addresses { 10.0.0.0/8; 127.0.0.0/8; 169.254.0.0/16; 172.16.0.0/12; 192.168.0.0/16; } except-from { "example.com"; };
Ну здрасьте, единственный.
dnsmasq (трудящийся практически в каждом первом soho роутере) умеет это из коробки одним ключём запуска (и на совести авторов прошивки, включен ли этот ключ по умолчанию).
Да и практически на любом сервере, даже не имеющем такого синтетического сахара, это можно сделать настройками
А откуда логин/пароль роутера-то берется при такой атаке?
Например отсюда
http://www.routerpasswords.com
Ну то есть проблема в том, что люди сидят под дефолтными креденшиалсами, а не в чемто еще.
Понимаете, какие бы страшилки по безопасности не лились на головы рядового пользователя, в целом по больнице это ничего не изменит. Люди покупают коробку, для получения благ, и люди вообще не хотят разбираться в настройках дальше того момента, когда получат преемлимый на их взляд уровень блага.
А зачем менять несферическому непродвинотому пользователю настройки на домашней коробке?
Ну не надо менять, надо ставить рандомный пароль свой на каждом устройстве еще при производстве. Пароль писать на наклейке. У меня вот пароль вай-фая именно так предустановлен на роутере. Непонятно, почему нельзя то же самое делать просто с паролем доступа.
Я считаю, что вообще это надо регламентировать каким-то гостом. Устройства, на которых одинаковый пароль — просто не допускать к розничной торговле.
Вот чем бы заняться вместо запрета интернетов.
Вопрос как будет организована защиты базы с паролями
Не надо никакой базы с паролями. Рандомный пароль на устройство + наклейка на него, кроме как на наклейке пароля больше нигде нет.
Наличие некоего универсального "заводского пароля" при сбросе на "заводские настройки" тоже вполне можно оставить — с возможностью залогиниться и требованием выставить новый пароль. В этом случае если пользователь оставит старый — он уже сам себе злобный буратина.
В любом случае это уже детали, понятно при при гипотетическом принятии такого закона было бы какое-то обсуждение, анализ возможных проблем и т.д.
Дело не в законе.
Дело как раз в законе, потому что без закона нафига кому-то париться?
От избежания дублей при работе псевдослучайного генератора случайных чисел
Будут дубли один на миллиард-другой, ну и что?
и при финальной сборки и тестирования решения перед отправкой
Можно тестировать до смены паролей.
Роутер — это частный случай. Ко многим ресурсам в локальной сети пароль вообще по-умолчанию не устанавливается. И на многих роутерах пароль остаётся по-умолчанию, либо «из стандартных» — именно из-за уверенности в безопасности локальной сети, «зачем усложнять».
Буду себе настраивать DNS-over-HTTPS на домашенем роутере с OpenWRT… но пароли на консоль SyncThing уже поставил.
- В OpenWRT прошивках помимо опции rebind_protection есть опция rebind_localhost (allows upstream 127.0.0.0/8 responses, required for DNS based blacklist services). В частности, к таким сервисам относятся те, что содержат/проверяют ip'шники email спаммеров. Если ip спамерский, в ответе вы получите адрес из 127.0.0.0/8. Собственно поэтому эта опция может поломать работу с ними (если я все правильно понял). Верно ли, что если у меня не поднят собственный почтовый сервак, настроенный на работу с этими самыми DNSBL, то, по идее, ничего не сломается, и лучше эту опцию держать включенной?
- Допустим на компе настроена фильтрация ответов от DNS из локальный диапозонов 192.168.*, 10.*, 172.*, но я подключаюсь к wifi точке, на которой вот это вот ничего не настроено, или к точке, где все настроено, но есть «умник» в локалке с прописанным DNS сервером, например, 8.8.8.8 (что, по большому счету, одно и то же, ибо в обоих случаях локалка подвержена атаке, опять-таки, если я все правильно понял). Правильно ли, что мне побоку DNS rebinding, если:
- у меня не поднято никаких сервисов, к которым можно обращаться по API или
- подняты такие сервисы, но для их использования (API) необходимо сначала авторизоваться или
- подняты такие сервисы, но все входящие соединения режутся фаерволом?
DNS rebinding в 2k19, или как по-настоящему вспотеть, посетив порносайт