Распознавание Прокси
Я вот думал на тему обнаружения проксей. Если у нас есть веб сервер, то часто довольно полезно знать - пользователь заходит через проксю или без посредников. Некоторые прокси отмечают факт своего существования в HTTP заголовках. но не все. Хорошие анонимные прокси стараются не выдавать себя ничем.
Обычные подходы - это либо использовать баги в браузере или плагинах, чтобы заставить компьютер пользователя связаться с нами напрямую (decloak.net - один пример) , либо разбирать отдельные IP-пакеты и пытаться найти несоответствия (клиент говорит, что виндовс, а трафик линусом пахнет)
А мне тут пришел в голову еще один подход, насколько я знаю, никем не обнародованный.
Можно судить по некоторым временнЫм характеристикам трафика. Если какая-то часть информации обрабатывается клиентом (браузером), а какая-то на прокси - то времена ответа будет заметно различаться. И чем дальше прокся от ее клиента, тем разница по времени больше. (и тем выше шанс, что пользователь что-то замышляет)
Конкретный пример:
Получаем коннект с адреса 1.2.3.4 - это прокся? Не знаем, но сначала отсылаем обратно ping 1.2.3.4. тот возвращается за 100 миллисекунд. Если посредине стоит прокся - то на ping ответила как раз она.
Теперь шлем браузеру редирект на другую страницу нашего сайта. Послали, и через минуту нам возвращается HTTP запрос по новому адресу. Редиректы отрабатываются в браузере. а не на прокси, поэтому минута - это меря расстояния до самого пользователя (плюс скорости браузера итп)
Расхождение очень большое, поэтому можно утверждать, что да - пользователь зашел через проксю. Точные параметры, что считать за большое расхождение, что - нет, надо выяснять из опыта, но статистику набрать нетрудно.
Вот такой метод. У кого-нибудь есть соображения и предложения по поводу?
ЗЫ: Существует еще минимум три-четыре варианта атаки, которые работают куда точнее, но это уже секрет фирмы =) Попробуйте сами прикинуть )
ЗЗЫ: Всесто ping который будет виден в трафике можно использовать среднее время между отсылкой TCPпакета и его приходом его подтверждения. Тогда никаких аномалий не будет вообще.
Обычные подходы - это либо использовать баги в браузере или плагинах, чтобы заставить компьютер пользователя связаться с нами напрямую (decloak.net - один пример) , либо разбирать отдельные IP-пакеты и пытаться найти несоответствия (клиент говорит, что виндовс, а трафик линусом пахнет)
А мне тут пришел в голову еще один подход, насколько я знаю, никем не обнародованный.
Можно судить по некоторым временнЫм характеристикам трафика. Если какая-то часть информации обрабатывается клиентом (браузером), а какая-то на прокси - то времена ответа будет заметно различаться. И чем дальше прокся от ее клиента, тем разница по времени больше. (и тем выше шанс, что пользователь что-то замышляет)
Конкретный пример:
Получаем коннект с адреса 1.2.3.4 - это прокся? Не знаем, но сначала отсылаем обратно ping 1.2.3.4. тот возвращается за 100 миллисекунд. Если посредине стоит прокся - то на ping ответила как раз она.
Теперь шлем браузеру редирект на другую страницу нашего сайта. Послали, и через минуту нам возвращается HTTP запрос по новому адресу. Редиректы отрабатываются в браузере. а не на прокси, поэтому минута - это меря расстояния до самого пользователя (плюс скорости браузера итп)
Расхождение очень большое, поэтому можно утверждать, что да - пользователь зашел через проксю. Точные параметры, что считать за большое расхождение, что - нет, надо выяснять из опыта, но статистику набрать нетрудно.
Вот такой метод. У кого-нибудь есть соображения и предложения по поводу?
ЗЫ: Существует еще минимум три-четыре варианта атаки, которые работают куда точнее, но это уже секрет фирмы =) Попробуйте сами прикинуть )
ЗЗЫ: Всесто ping который будет виден в трафике можно использовать среднее время между отсылкой TCPпакета и его приходом его подтверждения. Тогда никаких аномалий не будет вообще.
