Маю цікаву ідею сервісу для проксірування трафіку 🚀💻. Детально розпишу у статті або статтях 📝, інформації для вивчення там немало, а тут опишу суть.
А суть в тому, що помітив, що іноді DNS-трафік летить напряму до резолвера, незважаючи на те, що я намагаюся використовувати проксі 🌐. Ця ситуація повторюється і якщо використовувати проксі напряму через CLI-інструменти, і навіть якщо використовувати через proxychains чи проксі-брокери. Погуглив і зрозумів, що проблема відома і є декілька варіантів її вирішити 🔍.
Варіанти є, а готового безкоштовного рішення нема. Непорядок 😤. Буду виправляти!
Підніму шлюз з кастомною логікою проксіювання запитів. 🖥
Також прийшла в голову ідея автоматично збирати проксі, перевіряти і ранжувати їх під капотом, не перекладаючи цей процес на плечі користувача.
Логіка зрозуміла. Детальніше буде у статті 📄 і в наступних постах.
А суть в тому, що помітив, що іноді DNS-трафік летить напряму до резолвера, незважаючи на те, що я намагаюся використовувати проксі 🌐. Ця ситуація повторюється і якщо використовувати проксі напряму через CLI-інструменти, і навіть якщо використовувати через proxychains чи проксі-брокери. Погуглив і зрозумів, що проблема відома і є декілька варіантів її вирішити 🔍.
Варіанти є, а готового безкоштовного рішення нема. Непорядок 😤. Буду виправляти!
Підніму шлюз з кастомною логікою проксіювання запитів. 🖥
Також прийшла в голову ідея автоматично збирати проксі, перевіряти і ранжувати їх під капотом, не перекладаючи цей процес на плечі користувача.
Логіка зрозуміла. Детальніше буде у статті 📄 і в наступних постах.
🤯1🤝1
Як я зрозумів, що проблема є? 🤔
Розкажу, що саме сталось 📝.
Запустив whatweb із заданим параметром проксі і одразу отримав відмову 🛑. Спершу не зрозумів, у чому справа — просто щось не спрацювало. Почав розбиратись і зрозумів: тула в обхід налаштувань проксі сама йшла до DNS напряму — минаючи проксі повністю. Але я для того проксі й накинув, щоб звертатись не напряму 🔄. А без проксі цей запит просто не відпрацював. Так стало зрозуміло, що маю справу з витоком🫣 .
Обійти це я спробував через proxychains, але й тут виникла проблемка, whatweb всеодно слав запити напряму, ігноруючи мої налаштування ❌.
Я зрозумів, що так може зробити не тільки whatweb, а будьяка інша тула і спробуй вгадай яка і в який момент вирішить мене спалить 💔.
А отже, якщо є проблема, то потрібно знайти для неї вирішення, щоб зберегти баланс у всесвіті ⚖️.
Я вирішив, якщо в системі мої налаштування проксі може обійти будь-яка тулза, то я буду ловити їх запити поза системою і акуратно загортати у проксікі, так як мені потрібно 🛡.
Отака ідея 💡.
Далі я пішов шукати готові рішення 🔍.
Про те, що я знайшов, буду писати далі ✍️.
Розкажу, що саме сталось 📝.
Запустив whatweb із заданим параметром проксі і одразу отримав відмову 🛑. Спершу не зрозумів, у чому справа — просто щось не спрацювало. Почав розбиратись і зрозумів: тула в обхід налаштувань проксі сама йшла до DNS напряму — минаючи проксі повністю. Але я для того проксі й накинув, щоб звертатись не напряму 🔄. А без проксі цей запит просто не відпрацював. Так стало зрозуміло, що маю справу з витоком
Обійти це я спробував через proxychains, але й тут виникла проблемка, whatweb всеодно слав запити напряму, ігноруючи мої налаштування ❌.
Я зрозумів, що так може зробити не тільки whatweb, а будьяка інша тула і спробуй вгадай яка і в який момент вирішить мене спалить 💔.
А отже, якщо є проблема, то потрібно знайти для неї вирішення, щоб зберегти баланс у всесвіті ⚖️.
Я вирішив, якщо в системі мої налаштування проксі може обійти будь-яка тулза, то я буду ловити їх запити поза системою і акуратно загортати у проксікі, так як мені потрібно 🛡.
Отака ідея 💡.
Далі я пішов шукати готові рішення 🔍.
Про те, що я знайшов, буду писати далі ✍️.
Please open Telegram to view this post
VIEW IN TELEGRAM
Останній тиждень просто скажений 😵💫.
Розгортаю нову ноду для прикольних нових проектів 🚀.
Збираю онлайн платформу для того, щоб збирати свої думки в одному місці 🧠.
І реалізую новий проект прозорого проксі 🔍. Перші версії вже викладені на github 💻.
Перша частина статті, де я розповім детальніше про проблему і підхід до її вирішення вже на підході ✍️.
💪
Розгортаю нову ноду для прикольних нових проектів 🚀.
Збираю онлайн платформу для того, щоб збирати свої думки в одному місці 🧠.
І реалізую новий проект прозорого проксі 🔍. Перші версії вже викладені на github 💻.
Перша частина статті, де я розповім детальніше про проблему і підхід до її вирішення вже на підході ✍️.
Please open Telegram to view this post
VIEW IN TELEGRAM
DNS leak за кілька хвилин 🕵️
Проксі налаштували, а DNS точно йде через нього? 🤔
Я для себе перевіряю це просто через tcpdump 🔍.
На машині, де крутиться тула, запускаю:
Потім у другому вікні роблю звичайний запит через інструмент, який нібито працює через проксі 🌐.
Якщо в tcpdump видно пакети до 8.8.8.8:53, 1.1.1.1:53 або системного resolver — DNS іде напряму 🫣
Тобто HTTP-запит може піти через проксі, а домен, до якого ви звертаєтесь, уже засвітився назовні ⚠️.
Саме так я й знайшов проблему з WhatWeb.
У наступному пості покажу, чому proxychains не завжди рятує від цього 😬 ✍️
Проксі налаштували, а DNS точно йде через нього? 🤔
Я для себе перевіряю це просто через tcpdump 🔍.
На машині, де крутиться тула, запускаю:
tcpdump -ni any port 53
Потім у другому вікні роблю звичайний запит через інструмент, який нібито працює через проксі 🌐.
Якщо в tcpdump видно пакети до 8.8.8.8:53, 1.1.1.1:53 або системного resolver — DNS іде напряму 🫣
Тобто HTTP-запит може піти через проксі, а домен, до якого ви звертаєтесь, уже засвітився назовні ⚠️.
Саме так я й знайшов проблему з WhatWeb.
У наступному пості покажу, чому proxychains не завжди рятує від цього 😬 ✍️
Чому Proxychains не гарантує проксіювання DNS 🔄
Після того як WhatWeb почав ходити до DNS напряму, я подумав: ну ок, є ж proxychains 🤷♂️
Але в моєму випадку картина не змінилась ❌.
proxychains добре працює там, де може перехопити мережевий виклик самої програми. Але DNS може оброблятись окремо: через системний resolver, бібліотеку, кеш або інший механізм, який не потрапляє під його контроль 🔍.
Тобто логіка «обгорнув тулу в proxychains — значить усе анонімно» небезпечна ⚠️
Будь-яка програма може:
• зарезолвити домен напряму;
• використати нестандартний механізм DNS;
• просто помилитися в реалізації;
• або в якийсь момент обійти ваші налаштування.
Тому я вирішив контролювати DNS не всередині конкретної тули, а на рівні gateway 🛡 🌐
Далі покажу схему, до якої в підсумку прийшов.
Після того як WhatWeb почав ходити до DNS напряму, я подумав: ну ок, є ж proxychains 🤷♂️
Але в моєму випадку картина не змінилась ❌.
proxychains добре працює там, де може перехопити мережевий виклик самої програми. Але DNS може оброблятись окремо: через системний resolver, бібліотеку, кеш або інший механізм, який не потрапляє під його контроль 🔍.
Тобто логіка «обгорнув тулу в proxychains — значить усе анонімно» небезпечна ⚠️
Будь-яка програма може:
• зарезолвити домен напряму;
• використати нестандартний механізм DNS;
• просто помилитися в реалізації;
• або в якийсь момент обійти ваші налаштування.
Тому я вирішив контролювати DNS не всередині конкретної тули, а на рівні gateway 🛡 🌐
Далі покажу схему, до якої в підсумку прийшов.
Схема Transparent Gateway 🗺
Поступово в голові склалась така конструкція 🧠.
Є робоча VM. Їй не потрібно знати, як саме працює проксіювання, які проксі зараз живі та через який resolver відправляти DNS.
Вона просто працює 🌐
А gateway уже ловить і маршрутизує трафік ⚙️:
Головна думка: не довіряти кожній окремій тулі 🔍.
Якщо програма може відправити DNS не туди, куди потрібно, gateway має це побачити й перехопити. Інакше достатньо одного невдалого запиту, щоб засвітити реальний маршрут 😶🌫️
Наступний крок — розділити звичайні DNS-запити й запити до конкретних resolver 🚀.
Поступово в голові склалась така конструкція 🧠.
Є робоча VM. Їй не потрібно знати, як саме працює проксіювання, які проксі зараз живі та через який resolver відправляти DNS.
Вона просто працює 🌐
А gateway уже ловить і маршрутизує трафік ⚙️:
Робоча VM → gateway
TCP → redsocks → HAProxy → upstream → Internet
DNS →
стандартний запит → DoH → resolver
запит до конкретного resolver → UDP-to-TCP → resolver
Головна думка: не довіряти кожній окремій тулі 🔍.
Якщо програма може відправити DNS не туди, куди потрібно, gateway має це побачити й перехопити. Інакше достатньо одного невдалого запиту, щоб засвітити реальний маршрут 😶🌫️
Наступний крок — розділити звичайні DNS-запити й запити до конкретних resolver 🚀.
DoH, UDP-to-TCP і два маршрути для DNS 🔀
Не весь DNS однаковий 🤔.
У більшості випадків мені неважливо, який саме resolver поверне IP-адресу. Такі запити можна завернути в DoH: вони шифруються та виходять із gateway контрольованим шляхом 🔒
Але іноді треба звернутись до конкретного resolver, наприклад до 8.8.8.8 🌐.
Тут DoH не завжди підходить: конкретний DNS-сервер може не підтримувати його або потрібна саме його відповідь.
Тому в gateway є дві гілки 🔀:
• DNS на стандартні адреси → локальний DoH relay;
• DNS на конкретну адресу → перехоплення через TPROXY → UDP-to-TCP relay → потрібний resolver.
Так запит від програми виглядає для неї звичайним UDP DNS, але gateway сам вирішує, як доставити його далі 🛡 ⚙️ 🚀
Далі — трохи магії iptables і TPROXY.
Не весь DNS однаковий 🤔.
У більшості випадків мені неважливо, який саме resolver поверне IP-адресу. Такі запити можна завернути в DoH: вони шифруються та виходять із gateway контрольованим шляхом 🔒
Але іноді треба звернутись до конкретного resolver, наприклад до 8.8.8.8 🌐.
Тут DoH не завжди підходить: конкретний DNS-сервер може не підтримувати його або потрібна саме його відповідь.
Тому в gateway є дві гілки 🔀:
• DNS на стандартні адреси → локальний DoH relay;
• DNS на конкретну адресу → перехоплення через TPROXY → UDP-to-TCP relay → потрібний resolver.
Так запит від програми виглядає для неї звичайним UDP DNS, але gateway сам вирішує, як доставити його далі 🛡 ⚙️ 🚀
Далі — трохи магії iptables і TPROXY.