Знайдіть невдалий запит у журналах Squid
Використовуйте access.log для результатів транзакцій, а cache.log — для збоїв самого Squid, відрізняючи стан тунелю від стану адресата.
У пакеті Squid 6 для Debian почніть зі звичних журналів транзакцій і демона:
sudo tail -n 50 /var/log/squid/access.log
sudo tail -n 50 /var/log/squid/cache.logВласні налаштування журналювання або менеджер служб можуть спрямовувати їх в інше місце. Відтворіть один запит з обмеженим обсягом із відомого джерела та запишіть час, метод і адресата, щоб знайти правильний запис.
| Дані | Що з них дізнатися |
|---|---|
| Результат access.log у власному форматі | Код результату Squid і HTTP-статус — окремі частини транзакції. |
| Інформація про ієрархію доступу | Як пересилання використовувало батьківський проксі або інший маршрут. |
| Успішний CONNECT | Тунель відкрився; це не подальший статус сайту всередині зашифрованого TLS. |
| cache.log | Збої допоміжних програм, запуску, резолвера й конфігурації самого Squid. |
Якщо відповідного запиту немає, переконайтеся, що цей клієнт дістався саме цього екземпляра та слухача. Перевірте ACL журналювання, буферизацію, ротацію й чи транзакція ще активна: тривалий тунель може ще не мати кінцевого запису доступу. Обхід проксі або старий процес проксі може спрямовувати трафік в інше місце, тому перед зміною політики доступу зіставте процес, що слухає, із завантаженою ним конфігурацією.
Надайте відповідну транзакцію з прихованими конфіденційними даними та сусідні помилки. URL, параметри запитів, адреси джерел та імена користувачів можуть бути приватними. Вивантаження цілих журналів або запис усіх заголовків без конкретної потреби збільшує розкриття даних замість корисних свідчень.