Перейти к содержимому
Калькуляторы

DNS tunneling

Здравствуйте профессионалы!

Кто-нить борется/живет с http://xgu.ru/wiki/DNS-tunneling

По поиску ничего не нашла...

Исторически ДНС-ы на реальных IP оба.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Добрый день.

 

Что вы хотите получить в результате борьбы?

Есть реальные примеры эксплуатации DNS-tunneling ?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Добрый день.

 

Что вы хотите получить в результате борьбы?

Есть реальные примеры эксплуатации DNS-tunneling ?

Судя по netflow очень похоже, с закономерной периодичностью.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Если есть netflow, то вы же видите ip адрес своего пользователя и ip адрес DNS с туннелем?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Шейпить dst port 53 порядка сотни кбс?

Изменено пользователем pppoetest

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

А какой смысл фильтрации? Ваш рекурсивный сервер страдает?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Если есть netflow, то вы же видите ip адрес своего пользователя и ip адрес DNS с туннелем?

Найти и пальчиком показать ну-ну могу, хочется что-то более системное

 

Шейпить dst port 53 порядка сотни кбс?

Спасибо что по сути! Попробуем

 

А какой смысл фильтрации? Ваш рекурсивный сервер страдает?

Сервер страдает по ночам, не в ЧНН, да и самой неприятно от безконтрольности

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Ну видимо логично шейпить именно свой сервер, а не клиентскую полосу? Я правильно понял?

 

У меня, кстати, была презентация на тему IOD, но о response rate limiting я как-то тогда не задумывался.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

У нас есть студенческий тариф с ограничениями днем и безлимитом ночью.

Шейпим днем весь dns трафик до 32кбит/с. ДНС туннели не прям чтоб хорошо работали и напрягали, но дело принципа.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Весь? То есть если клиент dns-tunnel строит через гугл или через vps - шейпите?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Шейпится все, что летит на порт 53.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Зато дешего, надежно и практично.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

А какой хороший подход?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

А если клиент использует публичные DNS?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Ну по хорошему больше тарифа через туннель не прокачает, такшо пофих )))

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Когда есть интернет у клиента ему нет смысла заморачиваться с туннелями.

Начинаются движения, например, когда интернет отключили и перенаправляют на страницу авторизации.

ДНС в этом случае должны резолвить адреса, иначе перенаправление не случится. Тут-то и вылазит кейс с туннелями.

Я вижу 3 варианта:

 

1. Разрешать доступ только до своих ДНС, там использовать фичу от ipaddr.ru. Пользователи с 8.8.8.8 идут лесом и звонят в техподдержку.

2. Тупо шейпить весь днс трафик, позволяя клиенту пользоваться любым днс на свой вкус. Отключенные пользователи в теории имеют возможность зафигачить днс туннель. На практике он почти не работает. Я так и сделал и навсегда потерял ipaddr.ru как клиента.

3. Можно еще перехватывать все ДНС запросы и перенаправлять их на свой ДНС, где уже применять Response rate limit. Такой метод не тестировал, вообще должно быть ОК.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

3. Можно еще перехватывать все ДНС запросы и перенаправлять их на свой ДНС, где уже применять Response rate limit. Такой метод не тестировал, вообще должно быть ОК.

И тут вам ничто не мешает подменять ответы на youtube.com, редиректить на яндекс-family-dns и делать прочие забавные глупости. В 21 веке такой метод уже вероятно не сработает, т.к. отвалятся валидирующие DNSSEC-клиенты.

 

По факту DNS-туннель через public DNS (из них кто-то ещё не делает RRL???) будет работать со скоростью до сотни килобит в секунду. Я лично не вижу смысла с ними бороться - кино за разумное время не скачать, сёрфинг страдает.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

И тут вам ничто не мешает подменять ответы на youtube.com, редиректить на яндекс-family-dns и делать прочие забавные глупости. В 21 веке такой метод уже вероятно не сработает, т.к. отвалятся валидирующие DNSSEC-клиенты.

По озвученной вами же причине и не тестировал.

 

По факту DNS-туннель через public DNS (из них кто-то ещё не делает RRL???) будет работать со скоростью до сотни килобит в секунду. Я лично не вижу смысла с ними бороться - кино за разумное время не скачать, сёрфинг страдает.

 

Ну вот вы уже ушли в сторону целесообразности, а не методов.

У нас, например, есть свои веские причины не допускать 100 кбит нахаляву.

Насколько я понял, альтернативы нашему плохому методу вы не знаете?

Жаль, хотелось научиться чему-то новому.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Насколько я понял, альтернативы нашему плохому методу вы не знаете?

Ну только базовый - трубу рубить и с клиента долги требовать. Всю клиентскую трубу в 64к не пробовали зарезать?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Гость
Ответить в тему...

×   Вставлено в виде отформатированного текста.   Вставить в виде обычного текста

  Разрешено не более 75 смайлов.

×   Ваша ссылка была автоматически встроена.   Отобразить как ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставить изображения напрямую. Загрузите или вставьте изображения по ссылке.