Комментарии 7
Добрый день! Спасибо за фидбек! Мы пишем эту утилиту прежде всего по мере наших потребностей, и так получилось, что PS — единственное, на чем было возможно запустить клиента. Сейчас, например, мы столкнулись с ситуацией, когда кроме php ничего нет, поэтому в скором времени в репозиторий добавится и php-клиент.
Что касается тактики обнаружения туннелей по количеству запросов в секунду, на практике такой поведенческий анализ обычно выключен. Ну, а если нет, то у нас предусмотрена возможность делать паузы между запросами.
Ещё на тему обнаружения есть интересная статья от китайских коллег, они это делают с помощью подсчета частоты встречаемости биграмм в домене (A Bigram Based Real Time DNS Tunnel Detection Approach), что гораздо эффективнее подсчёта запросов, но такое пока никто не реализовал в продакшене.
Вы не сталкивались с проблемой передачей данных в base64 через DNS? Проблема бывает в том, что некоторые резолверы не всегда нормально передают кейз букв, в котором был запрошен домен. Например перемешивают строчные и заглавные буквы, www.example.com -> wWw.ExAMplE.Com. В таком случае вся кодировка base64 конечно же сломается.
Проблема решается использованием zbase32, правда эта кодировка позволяет закодировать меньшее количество байт чем base64 в строке той же длины.
Почему вы в своем случае используете base64?
Здравствуйте! Да, мы знаем, что base64 — не идеальный вариант для передачи, поэтому со временем появится возможность выбрать кодировку передаваемых сообщений. Стали использовать base64 изначально, потому что в тех сетях, где нам нужно было прокинуть туннель, его пропускает; скорость выше, чем у base32, а также потому, что в случае с Bash считанные нулевые байты нам удалось корректно передать только через конвейер в base64 непосредственно.
Трафик в конце туннеля или DNS в пентесте