Перейти до змістуЯк налаштувати проксі в Burp Suite
Burp Suite може стояти посеред трафіку вашого браузера, а може відправляти власний трафік через інший проксі. Це не одне й те саме. Якщо їх переплутати, легко витратити 20 хвилин, дивлячись не на той екран.
Цей посібник зосереджений на одному завданні: як налаштувати проксі в Burp Suite, не плутаючи локальний перехоплювальний проксі з вихідним маршрутом. Простими словами: браузер спілкується з Burp на одному порту, а Burp потім може звертатися до другого проксі, перш ніж дістатися цільового сайту. Саме на цьому другому переході й потрібен burp suite upstream proxy, а для пошуку відповідних пунктів інтерфейсу стане у пригоді саме налаштування proxy listener Burp Suite.
Якщо вам потрібен контекст щодо термінів проксі, глосарій VPN і проксі стане корисною вкладкою. Якщо у вашому ширшому робочому процесі є автоматизація, стаття як обрати VPN допоможе з мережевою частиною. Не кожному налаштуванню потрібні обидва варіанти.
1. Визначте, який саме сценарій проксі в Burp вам потрібен
Почніть із маршруту трафіку. Перший сценарій: браузер до Burp, а потім Burp до сайту. Другий: браузер до Burp, далі Burp до іншого проксі, а вже потім до сайту. Саме другий варіант зазвичай мають на увазі, коли запитують про як налаштувати проксі в Burp Suite, але за замовчуванням Burp працює саме як у першому сценарії.
Є один швидкий спосіб перевірити. Якщо ваша мета — переглядати запити з Chrome або Firefox, вам потрібен Burp як локальний перехоплювальний проксі. Якщо ж треба, щоб сам Burp виходив через корпоративний ретранслятор, домашній SOCKS-сервер або шлюз приватності, вам потрібен upstream proxy. Різниця важлива, бо налаштування слухача в Burp не керують вихідним ланцюжком.
Один — локальний. Інший — upstream.
Burp часто використовують у лабораторіях, офісних мережах і QA-середовищах, де браузер може напряму дістатися до Burp, але Burp не може безпосередньо дістатися до цільового хоста. Типовий приклад — віддалена тестова машина в обмеженій мережі, де Burp має йти через компанійний проксі на порту 8080 або 3128. Інший приклад — дослідницька машина, якій потрібна автентифікація для вихідного трафіку ще до того, як буде дозволений будь-який HTTP-запит.
2. Знайдіть потрібне місце в налаштуваннях проксі Burp Suite
Відкрийте Burp Suite і спершу шукайте розділ Proxy, а не налаштування браузера. Відповідні елементи зазвичай розміщені в інструменті Proxy, панелі налаштувань, а також у секціях listener та upstream. Якщо клікати лише по вкладці intercept, можна пропустити місце, де насправді змінюється маршрутизація.
Є два різні типи налаштувань, які треба перевірити. Listener визначає, на яку адресу й порт Burp слухає вхідний трафік браузера. Upstream визначає, куди Burp відправляє трафік після того, як уже його отримав. Існують окремі поля саме з цієї причини.
Шукайте частини інтерфейсу, де згадуються listeners, proxy listeners та request handling. Потім знайдіть область, пов’язану з burp suite proxy settings. Точні назви пунктів меню можуть відрізнятися залежно від версії Burp, тож безпечніше шукати саме керування proxy listener та upstream proxy, а не орієнтуватися на один скріншот зі старого гайда.
Маленька примітка: Burp байдуже, яким браузером ви користуєтесь. Йому важливі хост, порт і те, чи запущено listener.
3. Налаштуйте Burp як локальний перехоплювальний проксі
Для з’єднання браузер—Burp використовуйте адресy loopback, якщо браузер на тому ж комп’ютері. Зазвичай це 127.0.0.1 із портом на кшталт 8080. Браузер має вказувати на той самий хост і порт, на яких Burp слухає, інакше запити просто не дійдуть.
Поставте один listener. Потім перевірте його. Потім перевірте ще раз.
На практиці налаштування проксі в браузері мають точно збігатися з Burp: той самий IP, той самий порт, ті самі очікування щодо протоколу. Якщо Burp слухає HTTP на 127.0.0.1:8080, а браузер вказує 127.0.0.1:8081, не працюватиме нічого, окрім плутанини. Якщо фаєрвол блокує вибраний порт, Burp може виглядати готовим, тоді як з’єднання браузера одразу впаде.
На цьому кроці використовуйте браузер лише як клієнт. Не намагайтеся ще розв’язувати вихідне проксування. Люди часто змінюють три налаштування одночасно, а потім втрачають слід того, яке саме зламало трафік. Зосередьтеся лише на одному: переконайтеся спершу, що Burp може отримувати трафік.
Якщо пізніше ви порівнюєте типи проксі для ланцюжка, варто переглянути гайд SOCKS5 чи HTTP проксі для вебскрапінгу. Burp може стояти перед будь-яким із цих типів, але поля upstream proxy мають містити правильні дані про сервер.
4. Налаштуйте upstream proxy у Burp Suite
Ось частина, яку хоче побачити більшість читачів. burp suite upstream proxy вказує Burp, куди надсилати вихідні запити після їх перехоплення. Це правильний вибір, якщо ваш трафік має пройти через інший HTTP-проксі, SOCKS-ретранслятор або корпоративний шлюз, перш ніж дістатися призначення.
Уважно введіть хост і порт upstream proxy. Помилка тут створює глухий кут, а не попередження. Якщо upstream proxy потребує автентифікації, Burp може знадобитися ім’я користувача й пароль, а в деяких середовищах також очікуються певні правила транспорту або proxy headers. Це залежить від сервісу проксі, який ви використовуєте.
Використовуйте upstream routing тоді, коли Burp має зберігати свою локальну роль слухача, але все одно пересилати запити далі. Це доречно для контрольованого egress, лабораторних мереж або перевірки того, як ціль поводиться з певним вихідним маршрутом. Якщо вам потрібно лише локально переглядати запити браузера, upstream routing взагалі не потрібен.
Один корисний сценарій — тестова робоча станція, яка має виходити в інтернет лише через керований проксі. Інший — сеанс налагодження, де цільовий сайт має бачити конкретний вихідний шлях, а Burp при цьому все одно записує й редагує запит посередині. Саме цей проміжний крок і є головною ідеєю.
Якщо ваш upstream автентифікований, цей старіший гайд про автентифікований SOCKS5 proxy допоможе перевірити формат облікових даних. Легко правильно вказати хост і помилитися в логіні.
5. Налаштуйте Burp Suite Proxy Settings для правил відповідності та маршрутизації
Тут burp suite proxy settings перестають бути одним перемикачем і починають поводитися як система маршрутизації. Burp може зіставляти запити за призначенням, scope або іншими властивостями запиту, а потім вирішувати, чи надсилати трафік, чи перехоплювати його, чи пропускати далі. Якщо здається, що трафік ігнорує ланцюжок проксі, найчастіше причина саме в правилах.
Спершу перевірте scope. Якщо Burp налаштовано обробляти лише елементи, що входять у scope, трафік поза ним може обійти очікуваний маршрут. Далі перевірте правила match-and-route. Правило для одного домену може направляти трафік в один бік, а інше правило — в інший. Це нормально, доки ви не забудете, що створили правило три дні тому.
Тримайте логіку простою. Один listener. Один upstream proxy. Один тестовий об’єкт. Якщо пізніше вам знадобиться складніша поведінка, додавайте її по одному правилу за раз. Так ви зможете побачити, яке саме налаштування змінило результат.
На ланцюжок проксі також можуть впливати рішення щодо перехоплення та переспрямування в Burp. Якщо запити видно в історії, але вони ніколи не доходять до сервера, перевірте, чи не стоять вони на паузі через intercept. Якщо вони виходять із Burp, але не повертаються, проблема може бути в маршруті або в upstream proxy.
Для швидкого ознайомлення з концепціями маршрутизації перегляньте гайд ротація проксі для веб-скрапінгу, де пояснено, як змінюється потік запитів під час заміни проксі. Інший сценарій використання, але та сама звичка: знати, яке правило куди відправляє трафік.
6. Протестуйте ланцюжок проксі від початку до кінця
Тестуйте у три кроки. Спершу переконайтеся, що браузер може дістатися до Burp. Потім — що Burp може дістатися до upstream proxy. Потім — що upstream proxy може дістатися до цільового сайту. Якщо якийсь етап не вдається, ланцюжок розривається саме там.
Почніть з історії проксі в Burp. Надішліть один запит із браузера і подивіться, чи з’явиться він у списку. Якщо не з’являється, проблема в налаштуваннях браузер—Burp. Якщо з’являється, але зависає, можливо, його все ще тримає intercept. Якщо з’являється і виходить, але ціль не відповідає, найімовірніше, проблема у вихідному маршруті.
Потім використайте відому тестову сторінку або просте призначення, яке повертає видимі headers. Вам потрібна відповідь, що доводить проходження запиту через увесь ланцюжок, а не просто те, що Burp щось показав. Запит, який повертає 200 response від цілі через upstream proxy, — кращий сигнал, ніж загальне повідомлення “connected”.
Корисна звичка — окремо порівнювати source IP та фактичну маршрутизацію. Стаття як перевірити, що ваш IP прихований, допоможе зрозуміти, що бачить зовнішній світ. Це особливо корисно, коли upstream proxy є частиною приватного або корпоративного середовища.
7. Виправте найпоширеніші помилки налаштування проксі в Burp
Неправильна адреса listener — перша проблема. Burp слухає на 127.0.0.1, а браузер вказує інший хост. Або Burp слухає на конкретному інтерфейсі, а браузер намагається використати інший. У будь-якому разі запит не доходить до Burp.
Далі йде конфлікт портів. Якщо інша програма вже використовує порт, Burp може не прив’язатися до нього коректно. Симптом часто виглядає як тайм-аут у браузері, а не як акуратне повідомлення про помилку. Змініть порт, перезапустіть Burp і протестуйте ще раз.
Автентифікація upstream — ще один типовий збій. Один відсутній пароль, один прострочений токен або один неправильний тип auth достатньо, щоб зламати ланцюжок. Якщо ваш постачальник проксі використовує облікові дані, звірте їх із гайдом з найкращих практик proxy authentication, перш ніж припускати, що проблема в Burp.
SSL/TLS interception також може зламатися, якщо браузер або ціль не довіряють CA-сертифікату Burp, або якщо upstream proxy відхиляє CONNECT-запити. Це може виглядати як помилка сертифіката в браузері, скидання з’єднання в Burp або порожня відповідь від сайту. На практиці це діагностують, дивлячись, на якому саме переході все ламається.
Трафік, який не відповідає правилам Burp, — остання часта проблема. Якщо хост не входить у scope, виключений фільтром або відправляється розширенням браузера повз проксі, Burp може його ніколи не побачити. Перевірте й розширення браузера. Одне з них може обійти весь ланцюжок без попередження.
Якщо вам потрібен ширший контекст щодо налаштування проксі та приватності, сторінка VPN, proxy & privacy guides збирає пов’язані матеріали в одному місці. Це розумна наступна зупинка, якщо ваше налаштування Burp є частиною більшого тестового середовища.
8. Збережіть багаторазово придатну конфігурацію Burp для цього робочого процесу
Коли ланцюжок запрацює, збережіть його. Робочий профіль Burp варто берегти, бо ті самі listener, scope і upstream settings часто знадобляться в наступному проєкті. Відновлювати все з нуля — зайва витрата часу, та ще й із ризиком дрібних помилок у полях порту чи хоста.
Експортуйте конфігурацію, якщо ваша версія Burp це підтримує. Якщо у вашій редакції експорт недоступний, коротко запишіть адресу listener, порт, upstream host, upstream port і всі дані автентифікації, які треба буде ввести знову пізніше. П’яти рядків достатньо. Десяти — ще краще, якщо облікові дані зберігаються поза файлом.
Практичний трюк: називайте налаштування так само, як проєкт, наприклад “lab-chain-01” або “client-proxy-02”. Так легше завантажити ті самі Burp proxy settings на наступній машині. Це також допомагає, коли ви перемикаєтеся між тестовими середовищами з різними upstream proxy та різними вимогами до автентифікації.
Зберігайте профіль під одну конкретну задачу. Налаштування Burp для перегляду браузерного трафіку не слід бездумно використовувати для корпоративного upstream proxy, а профіль, створений для SOCKS-доступу, не можна вважати таким, що автоматично працюватиме на HTTP без повторної перевірки полів host, port і authentication. Саме ці три значення визначають, чи взагалі рухатиметься трафік.
Збережіть профіль зараз, поки ланцюжок ще працює.