— Как обойти блокировку Nmap?
спросил
Изменено 8 лет, 2 месяца назад
Просмотрено 23 тысячи раз
Я арендую сервер, а мой провайдер блокирует nmap. Есть ли какие-либо другие инструменты, которые я мог бы использовать для проверки моей домашней сети извне?
Кроме того, обеспечивает ли блокировка nmap в сети безопасность?
РЕДАКТИРОВАТЬ:
Если я попытаюсь:
nmap scanme.nmap.org — я получаю: 1 IP-адрес (0 хостов) сканируется за 0,50 секунды
nmap -sT -P0 -p 80 scanme.nmap.org — работает
nmap -sT -p 80 scanme.nmap.org — не работает
Кроме того, только -sT (подключение TCP работает), сканирование SYN (-Ss) не работает. Похоже, это может быть какой-то тип выходной фильтрации.
- сеть
- сеть-сканеры
- порты
- nmap
3
nmap scanme.nmap.org — я получаю: 1 IP-адрес (0 активных хостов) сканируется за 0,50 секунды
Кажется, они блокируют запросы SYN TCP к необычным портам. Есть ли обходной путь для этого?
Мне кажется, вместо этого они блокируют ping, и по умолчанию nmap запускает сканирование только на хосте, который отвечает на ping. Попробуйте nmap -sT -P0 -p 80 , чтобы посмотреть, как он отреагирует, поскольку мы знаем, что 80 открыт. Затем попробуйте nmap -sT -p 80 и посмотрите, будет ли он реагировать по-другому.
Это может происходить на вашем пограничном маршрутизаторе, а не на вашем интернет-провайдере. Некоторые из них не отвечают на пинг по умолчанию.
3
Если фильтрующее устройство вашего провайдера (идентификаторы, защита конечных точек) обнаружило вредоносный трафик, генерируемый из вашей домашней сети; что правило (блокировка) namp может быть связано в этом случае.
Или иногда эти устройства имеют автоматические правила для блокировки в случае разведывательных атак. Трафик из домашней сети больше похож на клиент-> интернет-запросы; устройства, которые просто анализируют поведение, становятся осторожными, поскольку теперь они видят входящий трафик, генерируемый в направлении домашней сети. В любом случае, вы должны решить этот вопрос с провайдером.
Что касается сканирования домашней сети, пробовали ли вы онлайн-решение?
- http://nmap.online-domain-tools.com/
- http://www.seomastering.com/port-scanner.php
Если результаты по-прежнему неудовлетворительны, значит, дело не только в вас; это просто подпись, которая попадает в фильтрующее устройство и блокируется.
Попробуйте изменить исходный порт, который использует nmap?
nmap -g 80 <цель>
Возможно, вы обнаружите, что брандмауэр разрешает сканирование других портов.
1
Блокировка nmap очень беспокоит.
Кто бы ни ввел эту политику в действие, у него нет функционального понимания безопасности, потому что они затрудняют вам тестирование вашего собственного брандмауэра (черт возьми!). Вероятно, вы можете собрать nmap из исходного кода в своем домашнем каталоге или использовать netcat (который установлен по умолчанию во многих дистрибутивах *nix):
nc -z google.com 0-65535
5
Вы действительно можете установить какие-либо исходящие TCP-соединения? Судя по тому, что вы пишете, они блокируют исходящие SYN-пакеты.
Можно ли выполнять исходящие соединения через порт 80 или 443? Они могут фильтровать «необычные» порты. Блокировка исходящих пакетов на самом деле не обеспечивает большой безопасности, если они разрешают порт 80 или 443. Однако это может создать некоторый шум, если клиенты запускают исходящие сканирования nmap для различных целей.
Кроме nc можно еще попробовать старый добрый telnet:
$ telnet your-ip [port]
Похоже, что-то блокирует исходящий трафик.
Вы настроены на использование прокси-сервера, например прокси-сервера веб-защиты? Попробуйте отправлять через него пакеты HTTP/TLS с помощью ProxyChains — https://github.com/rofl0r/proxychains-ng/ — но используя только флаги Nmap, ориентированные на соединение и не пингующие (т. е. -Pn -sT). Работает ли флаг traceroute (т. е. —traceroute) Nmap? Что это показывает?
Если есть устройство NGFW, UTM или IPS, блокирующее ваш трафик, рассмотрите возможность использования SniffJoke. Он специально создан для таких ситуаций. Если бы вы просидели там часами с socat, dnscat, nmap, SniffJoke, Wireshark и удаленным сервером, вы, вероятно, смогли бы понять, что происходит. Не будучи там сам, это лучшее, что я могу порекомендовать.
Таб-Таб, заходи! Обход интернет-блокировки для классификации устройств DPI
Артуро Филасто и Т. 2013-05-14
В течение последних двух лет мы следили за техническими разработками в
Интернет-фильтрация в Узбекистане и Туркменистане. Интернет-пользователи были
сообщает, что некоторые веб-сайты были заблокированы, соединения были сброшены, а в некоторых
случаев, когда пользователи были перенаправлены на другой сайт.
Помимо нашего технического интереса к тому, как реализована интернет-фильтрация на большой масштаб и как его можно обойти, мы заинтересованы в предоставлении технические факты о том, как происходит блокировка. Отсутствие технических информация в этой области имеет интересный побочный эффект в Интернете пользователи. Недостаток информации, помогите слухам распространить и закрепить идею что правительства имеют неограниченные возможности, которые не только контролируют все связи, но в конечном итоге ничего нельзя сделать, чтобы остановить их контроль. Понимание того, как происходит интернет-фильтрация, является важной задачей, поскольку позволяет обнаружить механизмы обхода его и отпечатков пальцев и в конечном итоге раскрывать компании, которые предоставляют технологии и ноу-хау правительствам, которые хотят подавить свободный поток информации в Сети.
Общая архитектура блокировки интернета в Туркменистане и Узбекистане занимает
места в два основных этапа. Первый этап отвечает за определение того, какие
Сеансы web/HTTP пытаются получить доступ к веб-сайту из черного списка.
Соответствие
В ходе нашего технического расследования мы обнаружили, что ключевой элемент в Этап сопоставления — это «заголовок хоста» в сеансе HTTP. Как только начальный устанавливается рукопожатие между пользователем и конечным веб-сервером (TCP/IP рукопожатие) браузер отправит HTTP-пакет с содержимым вида:
GET / HTTP/1.1 Хост: www.youtube.com
Этот первый пакет сообщает веб-серверу, что мы хотим запросить домашнюю страницу веб-сайта www.youtube.com
Заголовок Host был введен, чтобы иметь возможность указать, какой домен мы
запрос в обычном сценарии, что один IP-адрес обслуживает разные
веб-сайты (подумайте здесь о виртуальном хостинге).
.Независимо от того, какой тип технологии перехвата используется, сопоставление занимает место, наблюдая за полем заголовка HTTP Host. Есть хорошие технические причины для реализации сопоставления таким образом. Фильтровальное оборудование не нужно отслеживать IP-адреса, может работать в скрытом режиме, так как ему не нужно выполнять любое разрешение имен и проверять пакеты для этого заголовка, как технически сложно, поскольку отслеживание содержимого полного HTTP сессии.
Этот метод сопоставления прост и даже более эффективен с текущим трендом веб-серверов или веб-сайтов, чтобы заставить пользователей использовать правильное доменное имя, когда запрос ресурсов с сервера.
Фильтрация
После положительного совпадения можно при желании выполнить блокировку.
У нас есть
определил три основных метода, используемых для блокировки сеанса. Сброс, проксирование и
Активное перенаправление.
Сброс
В методе сброса два пакета RST будут отправлены на оба конца коммуникация. Путем ввода этих двух пакетов между взаимодействующими сторон, как пользователь/браузер Интернета, так и веб-сервер, внесенный в черный список, будут получил указание разорвать соединение. Этот метод блокировки присутствует в Туркменистан, когда мы могли эффективно инициировать трафик RST в результате доменное имя присутствует в заголовке хоста.
Чтобы убедиться, что трафик между браузером и заблокированным веб-сайтом полностью заблокирован, мы решили игнорировать пакеты RST на обоих концах связи. Результат эксперимента — удалось посетить заблокированный веб-сайт, а устройство перехвата не осуществляло полную блокировку всех трафик. К сожалению, игнорирование всех пакетов RST невозможно и делает это метод обхода блокировки нецелесообразен.
Есть несколько веских технических причин, по которым фильтрация реализована с использованием RST
пакеты.
Механизму фильтрации не нужно отслеживать каждую сессию.
(без гражданства), и блокировка может происходить без существенных изменений в
существующая сетевая инфраструктура. Тот факт, что блокировка сброса ограничивается
вводить поддельный трафик, не изменяя законный трафик, облегчает его
реализация и масштабируемость.
Интересным побочным эффектом блокировки RST является пассивное перенаправление. Из-за
обратная совместимость с HTTP/1.0, когда браузеры получают пакет RST, который
проинструктировать их закрыть соединение, инициируется новое соединение браузера
против того же веб-сайта, но на этот раз без заголовка Host. Когда
браузер получает RST, он считает, что общается со старым веб-сервером
который не поддерживает HTTP/1.1 и, следовательно, инициирует сеанс HTTP/1.0. Этот
сессия не будет «сопоставлена» устройством перехвата и не будет заблокирована.
Веб-сайт, получающий соединение HTTP/1.0, затем отправит перенаправление на
домен по умолчанию, размещенный на его IP-адресе. Например, соединение HTTP/1.
Проксирование
Второй механизм блокировки веб-сайтов — полу- или полностью прозрачные прокси. В обоих случаях HTTP-прокси размещается между пользователями. и Интернет. Все исходящие веб-соединения перехватываются прокси. В зависимости от используемой технологии прокси может скрывать свое присутствие от конечный пользователь (полупрозрачный), веб-сервер или оба (полностью прозрачный). наиболее распространенной прозрачной реализацией прокси является полупрозрачная; этот реализация перехватывает HTTP-запросы от пользователей и размещает исходящее соединение от имени пользователя, но не скрывает IP-адрес веб-прокси адрес с веб-сервера, т.е. веб-сервер может видеть, что соединения исходить не от пользователя напрямую, а с IP-адреса прокси.
Полностью прозрачный веб-прокси скрывает как от пользователя, так и от веб-сервера,
сеансы перехватываются.
Веб-сервер не может определить, установлено ли соединение
поступает непосредственно от конечного пользователя или самого прокси. Полупрозрачные прокси
обычно используются в сочетании с кэшированием для ускорения соединений, в то время как
полностью прозрачные прокси обычно используются для наблюдения.
Базовый механизм сопоставления в любом случае выполняется с учетом Хоста Заголовок. В отличие от механизма блокировки RST, веб-прокси имеет полный доступ к потоку данных и может выполнять наиболее сложное сопоставление строк, например: блокировка определенных статей или случайных страниц на основе ключевых слов. Прозрачный webproxy может выполнять более сложную фильтрацию, но требует обработки всех веб-запросы в инфраструктуре.
Этот метод блокировки используется в Узбекистане и Туркменистане, где мы может эффективно идентифицировать заголовки прокси при запросе заблокированных веб-сайтов.
Активное перенаправление
Таким же образом, как пакеты RST могут быть введены в поток данных для
разорвать соединение, мы увидели другой тип внедренного трафика в направлении
клиент.
В этом случае устройство перехвата отправляет HTTP 302
пакет перенаправления, информирующий браузер о том, что веб-сайт был «перемещен»
в другое место.
Вместо того, чтобы иметь полную реализацию веб-прокси для выполнения перенаправления, мы могли бы определить, что этот тип перенаправления выполняется без необходимости сохранения любого состояния сеанса. Как и в случае блокировки RST, как только Host найден заголовок пакет с перенаправлением на www.msn.com отправляется на клиент.
ПОЛУЧИТЬ / HTTP/1.1 Агент пользователя: TLT/2.6.4 (linux-gnu) Принимать: */* Ведущий: www.uznews.net Соединение: Keep-Alive HTTP/1.1 302 Найдено Местонахождение: http://www.msn.com/ Тип содержимого: текст/html; кодировка = utf-8 Длина контента: 136 Подключение: близкоОбъект перемещен Объект перемещен в
здесь.
Этот метод перенаправления легко масштабируется, и пользователи знают, что блокировка
место для разговора.
Как нам удается обойти блокировку?
В ходе нашего расследования мы обнаружили, что можно обойти фильтрация путем подделки заголовка Host, чтобы этап сопоставления не сработал.
Основная идея заключается в использовании символов \t (TAB) и \n (перевод строки) в
основные заголовки HTTP-запросов. Мы могли бы протестировать и убедиться, что веб-серверы
очистить заголовки запросов и добавить символ табуляции в конце
Заголовок хоста не повлияет на веб-сервер, но будет обходить
фаза обнаружения-согласования блокирующего механизма.
Таким образом, вместо отправки Host: www.youtube.com\n наши запросы выглядят как Host: www.youtube.com\t\n .
Мы также обнаружили, что метод активного перенаправления можно обойти с помощью
предварительно ожидая перевода строки в заголовок GET. Таким образом, вместо отправки GET/HTTP/1.1 наши запросы выглядят как \nGET/HTTP/1.1 .
Мы запустили внутри TM и UZ набор тестов OONI Probe для сбора некоторых данных
о том, как происходила фильтрация, и подтверждаем нашу гипотезу о цензуре
стратегии обхода.
На территории Узбекистана мы провели следующие тесты: лишний HTTP-заголовок был добавляются к нашим исходящим запросам. Как мы видим тело ответа содержит те же заголовки, которые были отправлены клиентом.
Проверка строки недопустимого запроса HTTP
https://ooni.org/reports/0.1/TM/http_invalid_request_line-2013-01-30T214938Z-AS20661.yamloo
С помощью такого теста мы смогли определить, что устройство DPI не вести себя некорректно при получении неверной строки запроса. Это приводит нас к мысли, что рассматриваемое устройство не является устройством синего мундира, поскольку такие устройства обычно сбой на ‘test_random_invalid_version_number’ и ‘test_random_invalid_field_count’, как показано в измерениях, выполненных в Мьянма (https://ooni.org/reports/0.1/MM/http_invalid_request_line-2012-12-06T162217Z-AS18399.yamloo).
Тест хоста HTTP
https://ooni.org/reports/0.1/TM/http_host-2013-01-30T224041Z-AS20661.yamloo
С помощью этого теста мы смогли подтвердить, что описанная выше фильтрация
обходные стратегии действительно работают, как показано
‘test_filtering_prepend_newline_to_method’ и
‘test_filtering_add_tab_to_host’.
Мы также смогли определить, что фильтрация
также происходит на поддоменах целевого имени хоста, как показано
‘test_filtering_of_subdomain’. Примечания: код ошибки «response_never_received»
происходит из-за TCP RST.
Внутри Туркменистана мы провели те же тесты и получили очень похожие результаты:
https://ooni.org/reports/0.1/UZ/http_invalid_request_line-2013-02-02T183110Z-AS31203.yamloo
Тест хоста HTTP
https://ooni.org/reports/0.1/UZ/http_host- 2013-02-02T183406Z-AS31203.yamloo
Также здесь происходит цензура поддоменов, хотя стратегия фильтрации должен ответить перенаправлением 302 на «http://www.msn.com».
Такие результаты особенно интересны, потому что теперь мы можем проверить
эти обходные стратегии в будущем. Если можно обойти
цензуры с помощью этих двух стратегий, мы можем сделать вывод, что устройство DPI, которое мы
сталкиваются могут быть похожи на эти. Если мы будем продолжать это делать, мы будем
разработка эвристики для категоризации устройств DPI.
Ваш комментарий будет первым