Определение туннеля двусторонний пинг обнаружен: «Определение туннеля (двусторонний пинг): обнаружен»

Содержание

Как убрать определение туннеля (двусторонний пинг) в VPN? — Записи обо всём

Вы пытаетесь максимально замаскировать свой VPN или прокси? Тогда вам наверняка необходимо убрать «Определение туннеля (двусторонний пинг)».

ICMP, Internet Control Message Protocol — доступно говоря, позволяет выполнить ping, на доступность сервера. Если вы за анонимность, то необходимо запретить ICMP трафик к своему VPN серверу или «определение туннеля (двусторонний пинг)».

Как запретить ICMP трафик?

Скорей всего, если задались таким вопросом, то наверняка, вы уже знакомы терминалом и командной строкой, так как абсолютно вся настройка сервера будет происходить с помощью ввода команд.

Debian/Ubuntu:

Запускаем ssh, переходим на сервер и логинимся под root пользователем
Переходим к редактированию настроек ufw c помощью nano: nano /etc/ufw/before.rules
Добавляем новую строку и сохраняем результат:

-A ufw-before-input -p icmp —icmp-type echo-request -j DROP

4. Перезапускаем фаервол ufw
ufw disable && ufw enable
5. Сервер больше не должен отправлять ICMP трафик, а значит вам удалось скрыть двусторонний пинг!

Прочие дистрибутивы:

Самый простой способ блокировать команду ping в системах Linux — это добавить правило в iptables, как будет показано в приведенном ниже примере. Iptables является частью ядра Linux netfilter и, как правило, устанавливается по умолчанию в большинстве Linux-сред.

# iptables -A INPUT --proto icmp -j DROP
# iptables -L -n -v [List Iptables Rules]

Другим общепринятым методом блокировки ICMP-сообщений в системе Linux является добавление ниже приведенной переменной ядра, которая «выведет из строя» все пакеты ping.

# echo “1” > /proc/sys/net/ipv4/icmp_echo_ignore_all

Чтобы сделать это правило постоянным, добавьте следующую строку в файл /etc/sysctl. conf и затем примените правило с помощью команды sysctl.

# echo “net.ipv4.icmp_echo_ignore_all = 1” >> /etc/sysctl.conf
# sysctl -p

В дистрибутиве CentOS или Red Hat Enterprise Linux, использующем интерфейс Firewalld для управления правилами iptables, добавьте нижеприведенное правило для удаления сообщений ping.

# firewall-cmd --zone=public --remove-icmp-block={echo-request,echo-reply,timestamp-reply,timestamp-request} --permanent
# firewall-cmd --reload

—remove-icmp-block удалит разрешение, а так как по умолчанию все запрещено то пинга не будет.
Если у вас по умолчанию все разрешено всем, тогда нужно ставить правило —add-icmp-block.

Двусторонний пинг обнаружен что это значит

Встроенные инструменты контроля портов

Мы предлагаем две команды, чтобы показать список. В первом списке отображаются активные порты вместе с именем процесса, который их использует. В большинстве случаев эта команда будет работать нормально. Иногда, однако, имя процесса не поможет вам определить, какое приложение или служба фактически использует порт. В таком случае вам нужно будет перечислить активные порты вместе со номерами идентификатора процессов, а затем просмотреть эти процессы в диспетчере задач.

Просмотр портов вместе с именами процессов

Во-первых, вам нужно открыть командную строку в режиме администратора. Нажмите «Поиск», а затем введите «командная» в поле поиска. Когда вы увидите «Командная строка» в результатах, щелкните его правой кнопкой мыши и выберите «Запуск от имени администратора».

В командной строке введите следующий текст и нажмите «Ввод»:

netstat -ab

После того, как вы нажмете Enter, результаты могут занять минуту или две для полного отображения, поэтому будьте терпеливы. Прокрутите список, чтобы найти порт (который указан после двоеточия справа от локального IP-адреса), и вы увидите имя процесса, использующего этого порт.

Если вы хотите сделать это немного проще, вы также можете выгрузить результаты команды в текстовый файл. Затем вы можете просто найти номер порта в текстовом файле.

Здесь, например, вы можете видеть, что порт 62020 связан процессом Skype4Life.exe. Skype – это приложение для общения между пользователями, поэтому мы можем предположить, что этот порт фактически связан процессом, который регулярно проверяет наличие обновлений для приложения.

Просмотр портов вместе с идентификаторами процессов

Если имя процесса для номера порта, который вы просматриваете, затрудняет определение того, какому приложению он соответствует, вы можете попробовать версию команды, которая показывает идентификаторы процессов (PID), а не имена. Введите следующий текст в командной строке, а затем нажмите Enter:

netstat -aon

В столбце справа справа перечислены PID, поэтому просто найдите тот, который связан с портом, который вы пытаетесь устранить.

Затем откройте диспетчер задач, щелкнув правой кнопкой мыши любое открытое пространство на панели задач и выбрав «Диспетчер задач».

Если вы используете Windows 8 или 10, перейдите на вкладку «Подробности» в диспетчере задач. В более старых версиях Windows вы увидите эту информацию на вкладке «Процессы». Отсортируйте список процессов по столбцу «ИД процесса» и найдите PID, связанный с портом, который вы исследуете. Возможно, вы сможете узнать больше о том, какое приложение или служба использует указанный порт, посмотрев столбец «Описание».

Если нет, щелкните процесс правой кнопкой мыши и выберите «Открыть расположение файла». Расположение файла, скорее всего, даст вам подсказку о том, какое приложение задействовано.

Ttl Details

The TTL value of an IP packet represents the maximum number of IP routers that the packet can go through before being thrown away. In current practice you
can expect each router in the Internet to decrement the TTL field by exactly one.

The TCP/IP specification states that the TTL field for TCP packets should be set to 60, but many systems use smaller values (4. 3 BSD uses 30, 4.2 used 15).

The maximum possible value of this field is 255, and most Unix systems set the TTL field of ICMP ECHO_REQUEST packets to 255. This is why you will find you
can »ping» some hosts, but not reach them with telnet(1) or ftp(1).

In normal operation ping prints the ttl value from the packet it receives. When a remote system receives a ping packet, it can do one of three things with
the TTL field in its response:

Not change it; this is what Berkeley Unix systems did before the 4.3BSD Tahoe release. In this case the TTL value in the received packet will be 255 minus
the number of routers in the round-trip path.
Set it to 255; this is what current Berkeley Unix systems do. In this case the TTL value in the received packet will be 255 minus the number of routers in
the path from the remote system to the pinging host.
Set it to some other value. Some machines use the same value for ICMP packets that they use for TCP packets, for example either 30 or 60. Others may use
completely wild values.

Устраняем замечания по анонимности и безопасности

DoNotTrack В вашем браузере не включен запрет на отслеживание.

Открываем настройки браузера, выбираем Приватность и защита. Находим защиту от отслеживания и выбрать Использовать защиту от отслеживания для блокировки известных трекеров ВСЕГДА, Передавать сайтам сигнал “Не отслеживать”, означающий, чтобы вы не хотите быть отслеживаемыми ВСЕГДА.

Заходим на whoer.net, замечания DoNotTrack больше нет. Анонимность, по-прежнему, 64%.

Разное системное время

Это замечание означает, что часовой пояс и время на вашем компьютере отличаются от времени расположения сервера VPN. В нашем случае это Нидерланды. Чтобы определить какой часовой пояс и какое время нам необходимо установить, воспользуемся сервисом whoer.net.

Теперь, когда нам известно, какой часовой пояс и время соответствует местоположению, соответствующему IP, можем изменить системное время и часовой пояс. Щелкните по часа в правом нижнем углу экрана и выберите «Изменение настроек даты и времени». Установите часовой пояс и время, соответствующие местонахождению сервера. Подробнее о том, как это сделать можно прочитать тут.

Заходим на whoer.net. Анонимность уже 70%. Смотрим параметры времени.

Замечания Разное системное время больше нет. Осталось только одно замечание.

Отличие языка

Это замечание означает, что язык операционной системы и браузера, отличается от языка страны местоположения. Посмотрим какой язык показывает сервис проверки whoer.net. Чтобы понять какой именно язык необходимо установить, определитесь к какому серверу VPN будет производиться подключение. Все тарифы включают сервера в 16 странах. В бесплатной версии это Нидерланды.

Для устранения этого замечания перейдем в настройки браузера, откроем дополнительные настройки и добавим язык местоположения. Чтобы определить какой язык необходимо установить, можно задать запрос в интернете, например, язык Нидерланды. Википедия подсказала нам, что в Нидерландах нидерландский (голландский) язык.

Находим настройки языка, жмем кнопку «Выбрать».

В открывшемся окне щелкаем «Выберите язык, чтобы его добавить…».

Нидерландского языка в списке нет. Находим голландский. Удаляем русский язык, для этого выбираем язык из списка и жмем «Удалить». Нажимаем кнопку «ОК». Закрываем окно настроек.

Заходим на whoer.net. Ура! Замечаний нет.

Итак, всего в несколько шагов мы добились 100% анонимности, используя бесплатный клиент Whoer VPN, браузер Mozilla Firefox 59.0.2 в Windows 10. Если вы используете другие операционные системы или браузеры, вы можете воспользоваться инструкциями на whoer.net для настройки именно вашей операционной системы и браузера.

Discovering network hosts with TCP SYN ping scans

How to do it…

Open your terminal and enter the following command:

# nmap -sn -PS

You should see the list of hosts found in the target range using TCP SYN ping scanning:

# nmap -sn -PS 192. 1.1/24 
   Nmap scan report for 192.168.0.1 
   Host is up (0.060s latency). 
   Nmap scan report for 192.168.0.2 
   Host is up (0.0059s latency). 
   Nmap scan report for 192.168.0.3 
   Host is up (0.063s latency). 
   Nmap scan report for 192.168.0.5 
   Host is up (0.062s latency). 
   Nmap scan report for 192.168.0.7 
   Host is up (0.063s latency). 
   Nmap scan report for 192.168.0.22 
   Host is up (0.039s latency). 
   Nmap scan report for 192.168.0.59 
   Host is up (0.00056s latency). 
   Nmap scan report for 192.168.0.60 
   Host is up (0.00014s latency). 
   Nmap done: 256 IP addresses (8 hosts up) scanned in 8.51 seconds

How it works…

The -sn option tells Nmap to skip the port scanning phase and only perform host discovery. The -PS flag tells Nmap to use a TCP SYN ping scan. This type of ping scan works in the following way:

Nmap sends a TCP SYN packet to port 80.
If the port is closed, the host responds with an RST packet.
If the port is open, the host responds with a TCP SYN/ACK packet indicating that a connection can be established.
Afterward, an RST packet is sent to reset this connection.

The CIDR /24 in 192.168.1.1/24 is used to indicate that we want to scan all of the 256 IPs in our local network.

There’s more…

TCP SYN ping scans can be very effective to determine if hosts are alive on networks. Although Nmap sends more probes by default, it is configurable. Now it is time to learn more about discovering hosts with TCP SYN ping scans.

Privileged versus unprivileged TCP SYN ping scan

Running a TCP SYN ping scan as an unprivileged user who can’t send raw packets makes Nmap use the connect() system call to send the TCP SYN packet. In this case, Nmap distinguishes a SYN/ACK packet when the function returns successfully, and an RST packet when it receives an ECONNREFUSED error message.

Firewalls and traffic filtering

A lot of systems are protected by some kind of traffic filtering, so it is important to always try different ping scanning techniques. In the following example, we will scan a host online that gets marked as offline, but in fact, was just behind some traffic filtering system that did not allow TCP ACK or ICMP requests:

# nmap -sn 0xdeadbeefcafe.com 
   Note: Host seems down. If it is really up, but blocking our ping   
   probes, try -Pn 
   Nmap done: 1 IP address (0 hosts up) scanned in 4.68 seconds 
   # nmap -sn -PS 0xdeadbeefcafe.com 
   Nmap scan report for 0xdeadbeefcafe.com (52.20.139.72) 
   Host is up (0.062s latency). 
   rDNS record for 52.20.139.72: ec2-52-20-139-72.compute-   
   1.amazonaws.com 
   Nmap done: 1 IP address (1 host up) scanned in 0.10 seconds

During a TCP SYN ping scan, Nmap uses the SYN/ACK and RST responses to determine if the host is responding. It is important to note that there are firewalls configured to drop RST packets. In this case, the TCP SYN ping scan will fail unless we send the probes to an open port:

# nmap -sn -PS80

You can set the port list to be used with -PS (port list or range) as follows:

# nmap -sn -PS80,21,53 
# nmap -sn -PS1-1000 
# nmap -sn -PS80,100-1000

TTL details

The TTL (time-to-live) value of an IP packet represents the maximum number of IP routers that the packet can go through before being thrown away. In practice, you can expect each router in the Internet to decrement the TTL field by exactly one.

The TCP/IP specification states that the TTL field for TCP packets should be set to 60, but many systems use smaller values (4.3 BSD uses 30, 4.2 used 15).

The maximum possible value of this field is 255, and most Unix systems set the TTL field of ICMP ECHO_REQUEST packets to 255. This is why you will find you can ping some hosts, but not reach them with telnet or ftp.

In normal operation, ping prints the ttl value from the packet it receives. When a remote system receives a ping packet, it can do one of three things with the TTL field in its response:

Not change it; this is what Berkeley Unix systems did before the 4.3 BSD Tahoe release. In this case, the TTL value in the received packet will be 255 minus the number of routers in the round-trip path.
Set it to 255; this is what current Berkeley Unix systems do. In this case, the TTL value in the received packet will be 255 minus the number of routers in the path from the remote system to the pinging host.
Set it to some other value. Some machines use the same value for ICMP packets that they use for TCP packets, for example either 30 or 60. Others may use completely wild values.

Trying different data patterns

The (inter)network layer should never treat packets differently depending on the data contained in the data portion. Unfortunately, data-dependent problems have been known to sneak into networks and remain undetected for long periods of time. In many cases, the particular pattern that has problems is something that doesn’t have sufficient «transitions,» such as all ones or all zeros, or a pattern right at the edge, such as almost all zeros. It isn’t necessarily enough to specify a data pattern of all zeros (for example) on the command line because the pattern that is of interest is at the data link level, and the relationship between what you type and what the controllers transmit can be complicated.

This means that if you have a data-dependent problem you will probably have to do a lot of testing to find it. If you are lucky, you may manage to find a file that either can’t be sent across your network or that takes much longer to transfer than other similar length files. You can then examine this file for repeated patterns that you can test using the -p option.

Насколько безопасен OpenVPN – TheWired

В прошлой статье я писал о том, как настроить свой собственный OVPN (OpenVPN). К сожалению, более-менее стандартный конфиг хоть и не раскрывает реальный IP-адрес клиента (это хорошо), но все же обнаруживает сам факт существования средств анонимизации (это не есть хорошо). Сегодня я расскажу, как именно происходит детекция и как с ней бороться 😉

Итак, если зайти сюда то вот что мы увидим:

Как видим из скриншота, утечка информации происходит по следующим пунктам:

Открытые порты web proxy
Разница во временных зонах (браузера и IP)
Принадлежность IP хостинг провайдеру
Определение туннеля (двухсторонний пинг)
VPN Fingerprint

Постараемся максимально устранить утечки данных. По порядку.

#1 Открытые порты web proxy

#2 Разница во временных зонах (браузера и IP)

Проще всего будет изменить время на клиентском устройстве и привести его в соответствие с временной зоной той страны и/или города, где физически находится OpenVPN-сервер.

#3 Принадлежность IP хостинг провайдеру

Увы, не изменить никак 🙁

#4 Определение туннеля (двухсторонний пинг)

Заходим в настройки ufw:

nano /etc/ufw/before.rules

Приводим секцию к такому виду:

# ok icmp codes
-A ufw-before-input -p icmp —icmp-type destination-unreachable -j ACCEPT
-A ufw-before-input -p icmp —icmp-type source-quench -j ACCEPT
-A ufw-before-input -p icmp —icmp-type time-exceeded -j ACCEPT
-A ufw-before-input -p icmp —icmp-type parameter-problem -j ACCEPT
# -A ufw-before-input -p icmp —icmp-type echo-request -j ACCEPT

# ok icmp codes

-A ufw-before-input -p icmp —icmp-type destination-unreachable -j ACCEPT

-A ufw-before-input -p icmp —icmp-type source-quench -j ACCEPT

-A ufw-before-input -p icmp —icmp-type time-exceeded -j ACCEPT

-A ufw-before-input -p icmp —icmp-type parameter-problem -j ACCEPT

# -A ufw-before-input -p icmp —icmp-type echo-request -j ACCEPT

Перезапускаем ufw:

Все, теперь туннель определяться не будет.

#5 VPN Fingerprint

Открываем конфиг VPN-сервера:

nano /etc/openvpn/server.conf

После строки:

Добавляем строку:

Перезапускаем VPN-сервер:

Если вы используете Viscosity (как я рекомендовал в прошлой статье), то заходите в свойства соединения, затем вкладка “Расширенные настройки” и в поле “Введите дополнительные команды для OpenVPN” пишем:

Пробуем прогнать тест еще раз:

Как видите — остался только 80-й порт, который я просто не стал убирать и IP, принадлежащий датацентру — но тут мы уже ничего не можем сделать. Базовая часть настроек выполнена, но это еще не все, есть еще нюансы 😉 Едем дальше, заходим вот сюда. И видим печальный результат:

#1 Отключаем Flash в браузере

Я использую Google Chrome (для других браузеров ищите как отключить в гугле), в адресной строке пишем:

Ищем там Adobe Flash Player и вырубаем его.

#2 Включаем опцию запрета отслеживания в браузере (Do Not Track)

В Google Chrome это делается в настройках, пункт меню — “Личные данные”, затем ставим галочку на пункте меню “Отправлять с исходящим трафиком запрос “Не отслеживать””.

#3 Отключаем WebRTC в браузере

Для Google Chrome есть плагин WebRTC Leak Prevent, ставим его.

В финале Whoer показал мне вот такую картинку:

Разное системное время Whoer определил по временной зоне (да, ее тоже надо исправлять). Язык тоже, думаю, понятно как узнал. На мой взгляд, это не является великой проблемой, т.к. путешествующий (условно) пользователь вполне логично будет иметь отличную от места пребывания временную зону и время, равно как и локаль. По большому счету, сделать то, что я описал в статье — лишним не будет 😉 Ну а для параноиков будут совсем иные рецепты. На связи, пишите в комментарии, если будут вопросы 😉

Смотрим на ситуацию с точки зрения защиты

При написании подобных инструментов важно посмотреть на всё с точки зрения защиты и подумать, что нужно принять во внимание. Наиболее важно помнить, что инструменты кибербезопасности не ограничиваются политиками белого списка брандмауэра. Большинство современных инструментов для защиты включают в себя различную функциональность по обнаружению аномалий

Но прежде чем заводить речь об аномалиях, нужно узнать больше о нормальном поведении субъекта

Большинство современных инструментов для защиты включают в себя различную функциональность по обнаружению аномалий. Но прежде чем заводить речь об аномалиях, нужно узнать больше о нормальном поведении субъекта

Наиболее важно помнить, что инструменты кибербезопасности не ограничиваются политиками белого списка брандмауэра. Большинство современных инструментов для защиты включают в себя различную функциональность по обнаружению аномалий

Но прежде чем заводить речь об аномалиях, нужно узнать больше о нормальном поведении субъекта.

Если говорить о ping-сообщениях в обычной сети, то их свойства примерно такие:

Большинство ping-сообщений отсылаются одинаковым образом — по 4 сообщения за раз.
Ping-сообщение имеет тип 8 (echo ping request), ping-ответ — тип 0 (echo ping reply).
С каждым ping-пакетом отсылаются несколько полей (при использовании Windows 8.1):
- = 0x0001;
- ответа будет равно запроса;
- У полезной нагрузки останется размер (32 байта) и содержимое («abcdefghijklmnopqrstuvwabcdefghi») по умолчанию.

Учитывая всё вышеперечисленное, вам следует:

Написать управляющий сервер и агент таким образом, чтобы каждую минуту (например) отправлялось не больше 4 ping-сообщений. Если на отправку ваших данных требуется 15 сообщений, то весь процесс займёт 4 минуты. Да, возможно это медленно, но стоит того, чтобы остаться незамеченным.
Убедиться, что ping-запрос и ответ логически правильны

Если все сообщения, которые вы отправляете, будут типа 0, то будет странно увидеть много ответов, когда нет никаких запросов.
Обратить внимание, что размер полезной нагрузки повлияет на первый пункт (количество ping-сообщений на размер данных) и что это метаданные.
Подумать о содержимом полезной нагрузки в контексте возможного наличия DPI.

Двусторонний пинг обнаружен что это значит

Защита различных CMS от взлома, вредоносные программы, анонимность и безопасность в интернете

Страницы

AdSense-web

29 мая 2018

Тестируем настройки браузера на анонимность с использованием прокси-сервера

Настройки браузера, на примере Mozilla Firefox, помогут скрыть факт использования прокси-сервера и максимально обеспечить анонимность в сети. Также, идентифицирующие вас данные в User agent не просто скрываются, а подменяются на наиболее используемые пользователями, что позволяет «раствориться» среди многих.

Конечно, легче использовать браузер Tor, где, даже, настройки по умолчанию обеспечивают хорошую анонимность, но некоторые сайты просто блокируют доступ по этой сети. И если вы еще не разобрались, как скрыть использование сети Tor, или подобных анонимных сетей, то стоит попробовать воспользоваться прокси-сервером.

На странице одного из популярных сервисов, в онлайн-базе прокси-листов, выбрал прокси HTTP, HTTPS с высокой степенью анонимности 145.249.106.107 Netherlands Amsterdam.

Тест проверки анонимности на сервисе 2ip.ru, я уже делал в предыдущей статье О чем расскажет ваш браузер, теперь посмотрим результаты с использованием прокси-сервера.

Непонятно почему в шапке показало Казахстан, но в колонке разницы во временных зонах браузера и IP, Amsterdam указан правильно.

Утечка IP через WebRTC. Как видим, использование прокси-сервера, даже с заявленной высокой степенью анонимности, не скрыло реальный (внутренний) IP-адрес компьютера. Для тех, кто не в теме, с внутренними адресами нельзя соединится из интернета, они работают только в пределах локальной сети.

К приватным «серым» IP-адресам относятся адреса из следующих подсетей:

от 10.0.0.0 до 10.255.255.255 с маской 255.0.0.0 или /8;
от 172.16.0.0 до 172.31.255.255 с маской 255.240.0.0 или /12;
от 192.168.0.0 до 192.168.255.255 с маской 255.255.0.0 или /16;
от 100.64.0.0 до 100.127.255.255 с маской подсети 255.192.0.0 или /10. Данная подсеть рекомендована согласно rfc6598 для использования в качестве адресов для CGN (Carrier-Grade NAT).

Напрямую доступ к внешней сети, используя внутренний IP-адрес, невозможен, но как вариант, связь с интернетом осуществляется через механизм NAT, где трансляция сетевых адресов заменяет частный IP на публичный. Если интернет-провайдер предоставил локальный IP, то будет проблематично настроить удаленное управление компьютером и скажем, видеонаблюдением, при использовании компьютера.

Что касается безопасности, то использование «серого» IP-адреса более безопасно, чем использование «белого» IP, так как «серые» не видны напрямую в интернете и находятся за NAT, который обеспечивает безопасность домашней сети.

Конечно, внешний IP не определился, но какой от этого толк, если внутренний сливается. Для целей идентификации, даже показательней будет локальный IP, чем публичный, на который провайдер может повесить множество пользователей.

Для устранения утечки настоящего IP адреса через WebRTC, в адресной строке браузера Firefox введите «about:config», найдите «media.peerconnection.enabled» и дважды кликните для установки значения «false».

Устранение разницы во временных зонах браузера и IP-адреса прокси-сервера. Также, мы видим прокол в разнице во временных зонах браузера компьютера и местонахождения прокси-сервера. Переводим системное время программой настройки времени в Ubuntu, в Меню приложений – Система, или соответствующей в другой операционке.

Для внесения изменений необходимо разблокировать программу, нажав Unlock и введя пароль администратора. Зная место расположения прокси-сервера, меняем часовой пояс.

Определение туннеля (двусторонний пинг). Не знаю по какой причине, но туннель методом пинга перестал определяться после двух предыдущих настроек.

Если коротко, то запущенный пинг от посещаемого сайта, показывает приблизительную длину маршрута. То же самое можно сделать со стороны браузера. Полученная разница в петле более 30 мс. указывает на туннель. Маршруты туда и обратно могут различаться, но в целом, точность получается довольно хорошая. Как вариант защиты – запретить ICMP трафик к своему VPN серверу. Следует заметить, результат теста на двусторонний пинг может то показывать наличие туннеля, то нет, это по опыту.

Как видим, настройки браузера позволили поменять IP-адрес и скрыть факт использования прокси-сервера, но данные, которые отправляет браузер о вашем компьютере, по-прежнему те-же.

Отключение методов слежения в браузере. Что бы уменьшить вероятность идентификации, даже, если вы сменили IP-адрес, желательно максимально скрыть передаваемую браузером информацию.

Shockwave Flash. Новый профиль в Firefox создается с двумя предустановленными плагинами Openh364 Video Codec и Shockwave Flash. Не заметил, на что влияет первый плагин, но Flash, в том числе настроенный на «Включать по запросу», отдает факт своего присутствия и свою версию. Только после выключения плагина, он становится невидимым для отслеживания.

JavaScript. Отдельно можно остановиться на JavaScript, который выключается параметром «javascript.enabled» в настройках about:config. Настраивать JavaScript удобно с помощью плагина NoScript. Наличие и версия JavaScript тоже отслеживается, но данный функционал работает почти во всех браузерах и его отключение, наоборот, сделает ваш браузер индивидуальней.

User agent. Наиболее идентифицирующая вас информация, передается в строке кода User agent, с данными типа браузера и операционной системы. В разделе about:config, если вбить в строку поиска «useragent», отфильтруются соответствующие строки настроек. Далее, создается параметр general.useragent.override. Выберите тип создаваемого параметра «Строка» и в новом окне впишите нужное значение user agent. Список наиболее используемых конфигураций user agent смотрите, например, здесь или здесь. Работает ли данный параметр лично не проверял, так как популярные user agent есть в плагине User-Agent Switcher, где быстро и легко переключаются между собой или корректируются.

Сервис на странице 2ip.ru/browser-info/ показал, какие пункты слежения были изменены в браузере, благодаря вышеперечисленным действиям. Изначальную конфигурацию смотрите все в той же предыдущей статье.

Таким образом, можно подменить идентифицирующую вас информацию и скрыть факт использования прокси-сервера через настройки браузера, и максимально обеспечить анонимность в сети.

Вы пытаетесь максимально замаскировать свой VPN или прокси? Тогда вам наверняка необходимо убрать «Определение туннеля (двусторонний пинг)». Как это сделать? Поговорим об этом в этой статье!

Как запретить ICMP трафик?

Запускаем ssh, переходим на сервер и логинимся под Root пользователем
Переходим к редактированию настроек ufw c помощью nano:
Добавляем новую строку и сохраняем результат:

Перезапускаем фаервол ufw:

Сервер больше не должен отправлять ICMP трафик, а значит вам удалось скрыть двусторонний пинг!

У вас остались еще дополнительные вопросы? Пишите их в комментариях, о том что у вас получилось или наоборот!

Вот и все! Больше статей и инструкций читайте в разделе Статьи и Хаки Linux. Оставайтесь вместе с сайтом Android +1, дальше будет еще интересней!

Несколько дней назад на хабре проскочила заметка об определении пользователей VPN. В комментариях я опубликовал ссылку на наш сервис с похожей функциональностью, написанием которого я совсем недавно занимался.

Главная идея — определить, скрывается пользователь во время сёрфинга в сети или нет, и по возможности узнать его реальный IP адрес. Есть несколько интересных фишек, которые в принципе я нигде не встречал (двусторонний пинг, сопоставление пар DNS leak/ISP).

Хотелось иметь под рукой этакий чек-лист, который бы отвечал, «палишься» ты или нет? На данный момент список состоит из 12 методов проверки, о которых ниже и пойдет речь, в том числе о том, как на них не попасться, но сначала о самом простом по порядку.

Заголовки HTTP proxy

Некоторые прокси дописывают свои заголовки к запросу, который инициирует браузер пользователя. Нередко это реальный IP адрес пользователя.

Убедитесь, что прокси сервер если и пишет что-то в заголовки указанные ниже, то хотя бы не ваш адрес:

HTTP_VIA, HTTP_X_FORWARDED_FOR, HTTP_FORWARDED_FOR, HTTP_X_FORWARDED, HTTP_FORWARDED, HTTP_CLIENT_IP, HTTP_FORWARDED_FOR_IP, VIA, X_FORWARDED_FOR, FORWARDED_FOR, X_FORWARDED, FORWARDED, CLIENT_IP, FORWARDED_FOR_IP, HTTP_PROXY_CONNECTION

Открытые порты HTTP proxy

IP адрес, с которого пришел запрос к нашей страничке может сказать о многом. Можно например посмотреть какие на той стороне открыты порты?

Самые интересные порты 3128, 1080, 8123. Если их не использовать, то вполне можно избежать необоснованных подозрений в использовании 3proxy, SOCKS 5 или Polipo.

Открытые порты web proxy

Как и в случае с HTTP, веб прокси можно повесить на любой порт, но мы хотели, чтобы тест работал очень быстро, поэтому ограничились обратным коннектом на порты 80 и 8080.

Отдается веб страничка? Отлично! На данный момент мы умеем определять PHProxy, CGIProxy, Cohula и Glype.

Нестандартные порты с авторизацией закрывают вопрос.

Подозрительное название хоста

Имея IP адрес можно попробовать отрезолвить хостнейм клиента. Стоп слова, которые могут намекать на туннель: vpn, hide, hidden, proxy.

Не стоит привязывать доменные имена к личному VPN, а если и делать это, то стоит избегать «говорящих» имён.

Разница во временных зонах (браузера и IP)

Исходя из данных GeoIP можно узнать страну по IP пользователя, а следовательно и его временную зону. Дальше можно вычислить разницу во времени между браузером и временем соответствующим временной зоне VPN сервера.

Разница есть? Значит пользователь наверняка скрывается.

Для России точной базы latitude и longtitude для регионов нет, а так как временных зон много, то в конечном результате эти адреса мы не учитываем. С Европейскими странами всё наоборот, очень хорошо они палятся.

При переключении на VPN нужно не забывать переводить системное время, менять время в браузере, либо работать с русскими прокси.

Принадлежность IP к сети Tor

Если ваш IP адрес это Tor нода из списка check.torproject.org/cgi-bin/TorBulkExitList.py, поздравляю, вы спалились.

Ничего криминального, но уже факт раскрытия того, что вы скрываетесь, не очень радует.

Режим браузера Turbo

Собрав диапазоны IP адресов Google, Yandex и Opera, и сравнив с пользовательским адресом, можно предположить использование сервисов сжатия трафика в браузерах соответствующих компаний.

Как правило такие сервисы ещё и сливают ваш реальный адрес в заголовках. Как на средство анонимизации, рассчитывать на сжатие трафика не следует.

Определение web proxy (JS метод)

Сравнив window.location.hostname с хостом запрошенной страницы, можно определить используется ли web proxy.

Веб прокси в принципе не надёжны, поэтому лучше обходить такие способы анонимизации совсем.

Утечка IP через Flash

Adobe Flash очень хорошо работает мимо пользовательских прокси. Инициировав соединение к нашему серверу, можно узнать IP пользователя.

Запустив специального демона, который логгирует все входящие соединения с ключами-метками, можно многое узнать. Лучший способ не раскрывать свой адрес — не использовать Adobe Flash вообще, или отключать в настройках браузера.

Определение туннеля (двусторонний пинг)

Запустив пинг к клиентскому IP, со стороны нашего сервера, можно узнать приблизительную длинну маршрута. То же самое можно сделать со стороны браузера, XMLHTTPRequest дёргает пустую страницу нашего nginx. Полученную разницу в петле более 30 мс можно интерпретировать как туннель.

Конечно маршруты туда и обратно могут различаться, или веб сервер чуть притомозит, но в целом точность получается довольно хорошая.

Единственный способ защититься — запретить ICMP трафик к своему VPN серверу.

Утечка DNS

Узнать какой DNS использует пользователь не проблема, мы написали свой DNS сервер, который записывает все обращения к нашим уникально сгенерированным поддоменам.

Следующим шагом собрали статистику на несколько миллионов пользователей, кто и какой DNS использует. Сделали привязку к провайдерам, отбросили публичные DNS и получили список пар DNS/ISP.

Теперь совсем не сложно узнать, если пользователь представился абонентом одной сети, а использует DNS совсем от другой.

Частично проблему решает использование публичных DNS сервисов, если это можно назвать решением.

Утечка через ВКонтакте

Это не утечка IP адреса, но всё же мы считаем, что отдавая всем налево и направо имена авторизованных пользователей, VK сливает частные данные, которые подрывают на корню всё анонимность серфинга.

борьба с утечками трафика и IP

Несколько дней назад на хабре проскочила об определении пользователей VPN. В комментариях я опубликовал ссылку на наш сервис с похожей функциональностью, написанием которого я совсем недавно занимался.

Заголовки HTTP proxy

Убедитесь, что прокси сервер если и пишет что-то в заголовки указанные ниже, то хотя бы не ваш адрес:

Открытые порты HTTP proxy

Открытые порты web proxy

Отдается веб страничка? Отлично! На данный момент мы умеем определять PHProxy, CGIProxy, Cohula и Glype.

Нестандартные порты с авторизацией закрывают вопрос.

Подозрительное название хоста

Не стоит привязывать доменные имена к личному VPN, а если и делать это, то стоит избегать «говорящих» имён.

Разница во временных зонах (браузера и IP)

Разница есть? Значит пользователь наверняка скрывается.

Принадлежность IP к сети Tor

Если ваш IP адрес это Tor нода из списка check.torproject.org/cgi-bin/TorBulkExitList.py , поздравляю, вы спалились.

Ничего криминального, но уже факт раскрытия того, что вы скрываетесь, не очень радует.

Режим браузера Turbo

Определение web proxy (JS метод)

Сравнив window.location.hostname с хостом запрошенной страницы, можно определить используется ли web proxy.

Веб прокси в принципе не надёжны, поэтому лучше обходить такие способы анонимизации совсем.

Утечка IP через Flash

Определение туннеля (двусторонний пинг)

Единственный способ защититься — запретить ICMP трафик к своему VPN серверу.

Утечка DNS

Частично проблему решает использование публичных DNS сервисов, если это можно назвать решением.

Утечка через ВКонтакте

Подробнее можно посмотреть документацию здесь

Или чтобы увидеть скрытый текст

Зарубежный ресурс

На данный момент собрано 14 методов проверки:

1. Заголовки HTTP proxy

Убедитесь, что прокси сервер, если и пишет что-то в заголовки указанные ниже, то хотя бы не ваш адрес:

2. Открытые порты HTTP proxy

Самые паленые порты: 3128, 1080 и 8123. Если их не использовать, то вполне можно избежать необоснованных подозрений в использовании 3proxy, SOCKS 5 или Polipo.

3. Открытые порты web proxy

Отдается веб страничка? Отлично! На данный момент мы умеем определять PHProxy, CGIProxy, Cohula и Glype.

Нестандартные порты с авторизацией закрывают вопрос.

4. Подозрительное название хоста

Не стоит привязывать доменные имена к личному VPN, а если и делать это, то стоит избегать «говорящих» имён.

5. Разница во временных зонах (браузера и IP)

Разница есть? Значит пользователь наверняка скрывается.

6. Принадлежность IP к сети Tor

Если ваш IP адрес это Tor нода из списка

Поздравляю, вы спалились.

Ничего криминального, но уже факт раскрытия того, что вы скрываетесь, не очень радует.

7. Режим браузера Turbo

8. Определение web proxy (JS метод)

Сравнив window.location.hostname с хостом запрошенной страницы, можно определить используется ли web proxy.

Веб прокси (по нашему анонимайзеры) в принципе не надёжны, поэтому лучше обходить такие способы анонимизации совсем.

9. Утечка IP через Flash

Запустив специального демона, который логирует все входящие соединения с ключами-метками, можно многое узнать. Лучший способ не раскрывать свой адрес — не использовать Adobe Flash вообще, или отключать в настройках браузера. К примеру, браузер Firefox по умолчанию отключает flash, стоит задуматься.

10. Определение туннеля (двусторонний пинг)

Запустив пинг к клиентскому IP, со стороны нашего сервера, можно узнать приблизительную длину маршрута. То же самое можно сделать со стороны браузера, XMLHTTPRequest дёргает пустую страницу нашего nginx. Полученную разницу в петле более 30 мс можно интерпретировать как туннель.

Конечно маршруты туда и обратно могут различаться, или веб сервер немного притормаживает, но в целом точность получается довольно хорошая.

Единственный способ защититься — запретить ICMP трафик к своему VPN серверу, правильно настроив свой фаервол.

11. Утечка DNS

Частично проблему решает использование публичных DNS сервисов, если это можно назвать решением.

Это не утечка IP адреса, но отдавая всем налево и направо имена авторизованных пользователей, к примеру VK сливает частные данные, которые подрывают всю анонимность серфинга.

Подробнее можно посмотреть документацию здесь

Пожалуйста или чтобы увидеть скрытый текст

Кнопка «Выход» после каждой сессии в общем то решает вопрос, но лучшая рекомендация — не использовать социальные сети

13. WEB-RTC

WebRTC позволяет устанавливать конференц-связь без использования плагинов через современные браузеры Mozilla и Chrome, но при этом раскрывает Ваш реальный IP даже при использовании VPN, а также список всех локальных IP-адресов, находящихся за NAT.
WebRTC поддерживается только в браузерах Chrome и Firefox. Родной поддержки WebRTC браузерами Internet Explorer и Safari не существует.

Отключение WebRTC в Firefox:
В адресной строке браузера вводим
Код:
about:config
Задаем в поиске:

Код:
media.peerconnection.enabled
Устанавливаем значение в «false» и снова проверяем!

Отключение WebRTC в Chrome:
В браузере Google Chrome для блокировки WebRTC необходимо установить плагин

Пожалуйста или чтобы увидеть скрытый текст

Отключение WebRTC на Android для пользователей Chrome:
В адресной строке браузера Chrome вводим:

Код:
chrome://flags/#disable-webrtc
Устанавливаем значение «enable»

Еще один альтернативный способ определения proxy и vpn:

14. MSS и MTU

MTU, или Maximum Transmission Unit — максимальное количество данных, которые могут быть переданы в одном пакете. MTU установлен у каждого сетевого адаптера, даже у тех маршрутизаторов, через которые трафик от вас до удаленного сервера идет транзитом. В большинстве случаев, в интернете используют MTU 1500, однако бывают заметные исключения, которые зачастую подчиняются некоторым правилам.

Когда ваш браузер или любое другое ПО, работающее с сетью, создает TCP-соединение к удаленному серверу, в заголовки пакета помещается значение Maximum Segment Size (MSS), которое сообщает серверу, какого максимального размера сегменты он может передавать в одном пакете. Это значение очень близкое к MTU, оно сразу дает понять серверу о возможностях вашего интернет-соединения, исключая излишнюю фрагментацию и позволяя утилизировать ваш канал по полной.
Когда вы отправляете пакет, будучи подключенным к VPN по какому-то протоколу (PPTP, L2TP(±IPsec), IPsec IKE), он помещается (инкапсулируется) в еще один пакет, что вносит свои накладные расходы, и большие пакеты, которые были бы отправлены без фрагментации без VPN, теперь придется фрагментировать. Чтобы избежать такой фрагментации, ОС устанавливает на сетевом интерфейсе MTU меньше, чем MTU реального сетевого интерфейса, из-за чего ОС не пытается создавать большие пакеты, которые требовали бы фрагментации.
В случае с PPTP, L2TP(±IPsec), IPsec, как я понимаю, нет каких-то стандартов на MTU туннеля, все устанавливают такие значения, чтобы работало в большинстве случаев, и устанавливаются они на глаз. Как правило, это 1400, что позволяет использовать, скажем, PPTP на каналах с MTU до 1440 без фрагментации (например, когда для доступа в интернет требуется еще один туннель, как часто бывает у российских провайдеров).

OpenVPN — почти самый популярный вариант VPN.
При совместимости со старым или кривым софтом, OpenVPN по умолчанию не устанавливает меньшее значение MTU на VPN-интерфейсе, а изменяет значение MSS внутри инкапсулированного TCP-пакета. За это отвечает параметр mssfix, установленный по умолчанию в значение 1450. Он изменяет MSS таким образом, чтобы он полностью утилизировал канал с MTU 1450, т. е. высчитывает свои накладные расходы таким образом, чтобы они проходили через канал с MTU 1450 и более без фрагментации. В результате у нас появляется возможность не просто определить пользователей OpenVPN со стандартным mssfix 1450, но и определить их протокол подключения (IPv4, IPv6), протокол транспортного уровня (TCP, UDP), параметры шифрования, сжатия и MAC, т.к. они вносят свои уникальные накладные расходы и отражаются в MSS.
Типичные параметры MSS:

Если используется шифрование в 64 бита, то это Blowfish, а если 128 бит — AES.

Тестирование двух VPN-сервисов: VyprVPN и ibVPN. Оба сервиса подвержены определению настроек описанным методом.
Если вы не хотите, чтобы вас обнаруживали таким способом, вы можете либо отключить mssfix, установив его в 0 и на сервере, и на клиентах, получив таким образом MSS 1460 (характерно для IPv4), что соответствует MTU 1500 — типичному MTU для обычного проводного соединения, которое есть у подавляющего большинства пользователей.
НО в этом случае вы получите излишнюю фрагментацию, что приведет к повышению задержек и уменьшению пропускной способности, поэтому стоит установить MTU в 1400, 1380 или похожее (должно быть кратно 10), т. к. такие значения часто используются провайдерами, например, мобильного интернета.

Теперь немного о

Пожалуйста или чтобы увидеть скрытый текст

Этот маленький проект расскажет вам о настройках вашего OpenVPN-соединения (если вы не изменяли mssfix), попытается определить вашу ОС и сравнить ее с ОС в User-Agent, получит PTR-запись для вашего IP и сравнит ее с набором правил, определяя, используете ли вы интернет-канал, рассчитанный на домашних или серверных пользователей.
Код:
First seen = 2015/07/24 17:19:29
Last update = 2015/07/24 18:39:37
Total flows = 7
Detected OS = Linux 3.11 and newer
HTTP software = Firefox 10.x or newer (ID seems legit)
MTU = 1409
Network link = OpenVPN UDP bs64 SHA1
Language = Russian
Distance = 15
Uptime = 1 days 19 hrs 39 min (modulo 165 days)

PTR test = Probably home user
Fingerprint and OS match. No proxy detected.
OpenVPN detected. Block size is 64 bytes long (probably Blowfish), MAC is SHA1.

ＷＩＴＣＨ？ также без проблем определяет пользователей Tor Browser, т.к. он использует одинаковый статичный User-Agent (с Windows) на всех ОС, а exit nodes запущены под Linux и FreeBSD.

В результате тестирования на разных ОС и провайдерах выяснилось:

Мобильный интернет от Beeline пропускает все соединения через прокси под Linux. Обнаружилось это, когда человек с Beeline зашел с iPhone на ＷＩＴＣＨ？, и ОС определилась как Linux. Вероятно, именно через него они меняют HTML-теги, добавляют тулбар с поиском mail.ru и изменяют дизайн сайтов.
MTU у мобильных устройств может быть буквально какой угодно, но, как правило, заканчивается на 0. Исключение — Yota с 1358. От чего это зависит — непонятно, подозреваю, что и от настроек на стороне оператора, и от телефонного модуля. Одна и та же SIM в разных телефонах использует разные MTU.
Код, который отвечает за mssfix в OpenVPN, очень медленный.

Ну и в конце статьи я предлагаю затестить
замечательный ресурс

Пожалуйста или чтобы увидеть скрытый текст

Этот проект может пассивно прослушивать трафик, определять ОС, MTU и браузер, оповестить о несовпадении ОС создателя пакетов и ОС в User-Agent.
p0f
также имеет API. Немного

Пожалуйста или чтобы увидеть скрытый текст

Добавив экспорт MTU через API и обновив сигнатуры, можно детектировать пользователей популярных VPN-протоколов, пользователей прокси и тех пользователей, которые подделывают User-Agent.

Ранее мы описывали достаточно шикарный способ утечки вашего реального IP адреса с помощью протокола Кроме этого способа также существуют другие методы определения вашего реального IP адреса. Сегодня мы раскажем вам о основных принципах обеспечения своей безопасности и анонимности в сети.

http://witch.valdikss.org.ru/ – позволяет определить какой тип подключения вы используете и исползуете ли вы VPN.

http://2ip.ru/privacy/ – позволяет собрать множество дополнительной информации о вашем браузере, типе подключения и IP адресе.

https://diafygi.github.io/webrtc-ips/ – определяет ваш IP адрес с помощью протокола WebRTC.

Мы подобрали для вас этакий чек-лист, который бы отвечал, «палишься» ты или нет? На данный момент список состоит из 12 методов проверки, о которых ниже и пойдет речь, в том числе о том, как на них не попасться, но сначала о самом простом по порядку.

Заголовки HTTP proxy

Убедитесь, что прокси сервер если и пишет что-то в заголовки указанные ниже, то хотя бы не ваш адрес:

Открытые порты HTTP proxy

Открытые порты web proxy

Отдается веб страничка? Отлично! На данный момент мы умеем определять PHProxy, CGIProxy, Cohula и Glype.

Нестандартные порты с авторизацией закрывают вопрос.

Подозрительное название хоста

Не стоит привязывать доменные имена к личному VPN, а если и делать это, то стоит избегать «говорящих» имён.

Разница во временных зонах (браузера и IP)

Разница есть? Значит пользователь наверняка скрывается.

Принадлежность IP к сети Tor

Если ваш IP адрес это Tor нода из спискаcheck.torproject.org/cgi-bin/TorBulkExitList.py , поздравляю, вы спалились.

Ничего криминального, но уже факт раскрытия того, что вы скрываетесь, не очень радует.

Режим браузера Turbo

Определение web proxy (JS метод)

Сравнив window.location.hostname с хостом запрошенной страницы, можно определить используется ли web proxy.

Веб прокси в принципе не надёжны, поэтому лучше обходить такие способы анонимизации совсем.

Утечка IP через Flash

Определение туннеля (двусторонний пинг)

Единственный способ защититься — запретить ICMP трафик к своему VPN серверу.

Утечка DNS

Частично проблему решает использование публичных DNS сервисов, если это можно назвать решением.

Утечка через ВКонтакте

Подробнее можно посмотреть документацию здесь

Всем привет! Недавно, благодаря одному человеку, наткнулся на сервис 2ip.ru/privacy/ . Данный сервис предлагает Вам проверить степень своей анонимизации. Дефект моей системы для вбива заключался в том, что мерчи могли спалить наличие туннеля при помощи двустороннего пинга. Если сервис обнаружит у вас наличие туннеля, то соответственно появляется заветная надпись: «Вероятность анонимизации 99%»
Наша задача заключается в том, чтобы запретить компьютеру принимать запросы пинга от интернет ресурсов. Приступаем к настройке.Во-первых, для начала советую Вам настроить Фаерволл в соответствии с темой пользователя Kardiara
Я сделать это для того, чтобы исключить утечки, а также задобрить Богов Кардинга, принеся в жертву все исходящие подключения, кроме тех, которые производятся из Bitvise»a и Proxifier»a. После того как основная настройка Фаерволла произведена, вносим некоторые дополнения.
Шаг 1.
Заходим в расширенные настройки Фаерволла(Advanced settings).
SpoilerTarget»>Спойлер: Спойлер
Шаг 2.
Выбираем Inbound Rules слева, а затем New Rule справа.
SpoilerTarget»>Спойлер: Спойлер
Шаг 3.
Выбираем Custom Rule.
SpoilerTarget»>Спойлер: Спойлер
Шаг 4.
Выбираем All Programs
SpoilerTarget»>Спойлер: Спойлер
Шаг 5.
Выбираем Protocol type: ICMPv4, если используете для подключение протокол TCP/IPv4 или ICMPv6, если используете для подключения протокол TCP/IPv6 соответственно.
SpoilerTarget»>Спойлер: Спойлер
В разделе Customize оставляем All ICMP types.
Шаг 6.
Оставляем всё как есть для того, чтобы наше правило действовало для всех подключений.
SpoilerTarget»>Спойлер: Спойлер
Шаг 7.
Выбираем Block the Connection. Ведь нам же нужно заблокировать все запросы, связанные с протоколом ICMP (Ping).
Видим, что сервис не имеет доступа для проверки двустороннего пинга.
Что касается открытых портов. Пообщавшись с опытными людьми, пришел к выводу, что это не критично. Ведь разве не имеет права человек открыть порты? К примеру, для поднятия того же сервера Counter-Strike. Значение открытых портов Web Proxy может варьироваться в зависимости от самого туннеля.Можно увидеть: Yes, Maybe,No. Порты открыты именно на самом SSH сервере.
UPD
: Подводя итоги двух дней исследований, сделал вывод о том, что на программном уровне данный тест никак не обойти.
1.Можно попытаться заблокировать ICMP траффик на самом сервере.
2.Обойти данный детект можно:
а.) Использованием дедиков
б.)Использовать быстрый интернет в совокупности с шустрым туннелем.
в.)Используя соксы,вместо SSH (?)
3.Лучше работать с мозиллы, чем с гугл хрома (Личные наблюдения)
4.Обязательно настройте фаерволл в соответствии с темой Kardiara, дабы исключить утечки при разрыве соединения.
5. Не забывайте о таком важном параметре как ProxyScore.

Привет коллеги:-)! А давайте поговорим о мифической анонимности в сети
. За последние несколько лет, мне на глаза попадалось несколько сценариев деанонимизации пользователя и я брал их себе на вооружение. Эти сценарии и опишу в текущей заметке. Мы рассмотрим случаи утечки реального IP и трафика при работе через VPN, соксы, прокси сервера и то, как можно от этого защититься
. А вообще я любитель Tails’а и TOR’а:-).

Утечка VPN трафика и IP при обрыве соединения.

Одна из главных проблем в работе с частными виртуальными сетями – это утечка трафика
. По-другому говоря, тот трафик, который должен был быть передан через VPN соединение в анонимном виде, попадает в открытый доступ. Данный сценарий не следствие проблем с клиентом или сервером. На самом деле всё гораздо интереснее. Самый банальный вариант – это обрыв VPN-соединения
. К примеру, решил прочекать лист SSH или FTP акков, запустил сканер, отошёл по своим делам на несколько минут, приходишь, а соединение внезапно разорвано. Но чекер/сканер при этом продолжает функционировать, и работа идёт уже с твоего реального адреса.

Что делать в этом случае?

Чтобы избежать утечки трафика и реального IP, сохранив свою анонимность, в ситуациях, когда VPN-соединение внезапно разорвалось, попробуйте:

Утечка VPN трафика и IP при работе в сетях с IPv6 и IPv4.

Но есть и более коварные ловушки. Например, утечка VPN трафика довольно часто происходит на хостах, поддерживающих обе версии протокола IPv6 и IPv4
.

Сосуществование двух протоколов может приводить к довольно не приятной ситуации утечки трафика в обход VPN туннеля и раскрытие реального IP. Не смотря на то, что шестая версия протокола не имеет обратной совместимости с четвертой, обе версии словно «склеены» доменными именами (DNS). Рассмотрим простой пример: есть доменное имя веб-сервиса или сайта, у него одновременно прописаны A запись (IPv4 адрес хоста) и AAAA запись (IPv6 запись хоста), их может быть сразу по несколько каждых. Далее, когда наше ПО, поддерживающая оба протокола или только IPv6 (браузер, чекер, сканер и прочее), захочет начать взаимодействие с сайтом, она может запросить любой адрес из прописанных и начнет слать пакеты по полученному адресу и по соответствующему протоколу.

Ииии “сейчас вылетит птичка”:-(Многие VPN реализации не умеют работать с IPv6 протоколом, или игнорируют его. VPN клиент переадресовывает все пакеты с IPv4 адресом через свой туннель, а вот пакеты с IPv6 адресами в заголовке просто игнорируются или не узнаются… Как результат – если у домена указан только IPv6 адрес, трафик пойдет через локальный роутер в открытом виде с реального IP. Карамба, мы работаем себе в сеточке через VPN, а траф топает другими, не предусмотренными нами дорожками!
Повторюсь, основная причина кроется в том, что хоть два протокола и несовместимы друг с другом, но они поддерживаются системой доменных имён. Получается, что для системы поддерживающей оба протокола, невозможно обеспечить безопасное соединение с другой системой, не обезопасив и IPv4 и IPv6.

Провоцируем преднамеренную утечку трафика.

Атакующий пользователь может специальным образом вызвать подключение по шестому протоколу на компьютере жертвы, отправляя ICMPv6 Router Advertisement сообщения. Аналогичные пакеты данных можно отправлять через программы rtadvd (http://www.gsp.com/cgi-bin/man.cgi?section=8&topic=rtadvd), SI6 Networks’ IPv6 Toolkit (http://www.si6networks.com/tools/ipv6toolkit/)или THC-IPv6 (http://thc.org/download.php?t=r&f=thc-ipv6-2.1.tar.gz), в результате при удавшемся ipv6 соединении можно получить утечку трафика и данных, перехватывая их далее MITM атакой.

Что делать в этом случае?

Чтобы отправлять весь трафик через VPN-соединение, тогда стоит сделать следующее:

В случае отсутствия поддержки IPv6 VPN клинетом, необходимо отключить шествую версию протокола на всех доступных сетевых интерфейсах. Тогда, у всех активных в сети приложений не будет другого выбора, кроме как использование IPv4 протокола. !!!Коротко!!!
снимите галочку у протокола IPv6 в настройках сети!
В случае если IPv6 у VPN клиента поддерживается — стоит убедиться в том, что весь передаваемый трафик отправляется через VPN.

А теперь проверь себя!

Проверьте уязвимость своей конфигурации на утечку данных через сайт www.dnsleaktest.com , после чего примените советы, приведённые в этой статье, чтобы убрать утечку DNS-трафика.

Тестируем настройки браузера на анонимность с использованием прокси-сервера | FreeWebmaster

Тестируем настройки браузера на анонимность с использованием прокси-сервера

Тестирование настроек браузера на анонимность показало, что, вполне, реально скрыть свои данные, а для посещаемого сайта вы будете находиться в стране IP-адреса прокси-сервера. Однако, не достаточно поменять IP-адрес и скрыть факт использования прокси-сервера, так как данные, которые отправляет браузер о себе и вашем компьютере, по-прежнему, те-же.

Что бы уменьшить вероятность идентификации, даже, если вы сменили IP-адрес, желательно максимально скрыть передаваемую браузером информацию, в том числе утечку IP через WebRTC, устранить разницу во временных зонах браузера и IP-адреса прокси-сервера и сделать невозможным определение туннеля (двусторонний пинг).

По возможности, отключите такие методы слежения в браузере, как Shockwave Flash и JavaScript. Наиболее идентифицирующая вас информация, передается в строке кода User agent, с данными типа браузера и операционной системы, которую также, желательно подменить.

Тестируем настройки браузера на анонимность с использованием прокси-сервераТестируем настройки браузера на анонимность с использованием прокси-сервераТестируем настройки браузера на анонимность с использованием прокси-сервераТестируем настройки браузера на анонимность с использованием прокси-сервераТестируем настройки браузера на анонимность с использованием прокси-сервера

скрытие ip адреса от утечки

07 Sep 2016 | Автор: anchous |

В последнее время неоднократно приходится сталкиваться с вопросами людей, как им повысить анонимность, чтобы конечный сайт, к которому обращается клиент через прокси или VPN, не видел их реальный IP адрес.

Ибо народу, специализирующемуся на бонусхантинге, вилках, покере и прочих гемблингах и букмекерах; требуется более высокая анонимность, чем, скажем, людям работающим в социалках или парсящих поисковые системы. Понятно, что всем пользователям прокси или VPN нужна помена IP адреса, но в некоторых нишах, вроде онлайн казино или букмекерских контор, клиенты проходят более глубокую проверку, по результатам которой клиенту не всегда получается успешное IP адреса.

Причем многие новички полагают, что если чекалки, вроде _https://whoer.net/ или _https://2ip.ru/privacy/ видят реальный IP, скрытый за прокси, то это проблема анонимности прокси.

Возможно я кого то разочарую, но в данной проблеме чаще всего виноват не прокси сервер.

Прокси бывает либо анонимным, либо не анонимным: первый переписывает заголовок пакета полностью, убирая все хвосты клиенты и оставляя только IP прокси; второй же оставляет исходящий IP, который видит конечная система.

Единственное, чем можно повысить анонимность прокси, использовать для сервера нестандартные исходящие порты, т.к при проверки приватности чекаются открытые порты клиентского IP (в данном случае прокси) и если видят стандартные 80, 8080, 1080 и т. д, то раcценивают это – как практически 100% вероятность подмены IP адреса с помощью прокси.

Все остальное, что палит более точная проверка приватности, происходит на уровне приложения, то есть браузера, который сливает IP различными способами.

И собственно, закрываются эти протечки, точно также, на уровне браузера. Проверку на отклик клиентского IP, в данном случае, можно не считать, т.к большинство компов, имеющих IP провайдера, точно также отвечают на пинг.

Также я не буду особо вдаваться в технические аспекты того или иного протекания IP (IP leak) в браузере, т.ч если хотите технических подробностей, то гугл вам в помощь.

Большая часть настроек, разве кроме части закрытия протекания DNS, делается в тонких настройках браузера Firefox, куда можно попасть, если ввести в адресную строку about:config

Начну с двух наиболее критических дырок, роняющих приватность ниже плинтуса, т.к через них реальный IP адрес протекает гарантировано. И все попытки скрыть реальный IP адрес от обнаружения, обречены на провал.

Это протекание через Adobe Flash и WebRTC. Первый является сторонним плагином, а второй встроенная во все браузеры технология, предназначенная для общения бродилок peer-to-peer и шпарящая в обход прокси.

Adobe Flash

Плагину ShockWave Flash в принципе лучше сказать запускаться по требованию: Основное меню FF -> Дополнения -> Расширения
а также изменить значение параметра в настройках FF
plugin.state.flash = 0

WebRTC

Здесь мы либо просто блокируем технологию
media.peerconnection.enabled = false

либо говорим ей логиниться по дефолтному маршруту
media.peerconnection.ice.default_address_only = true

но не знаю как это должно отрабатывать на проксях, т.ч для гарантированной подмены IP я предпочитаю закрывать все.

Для Google Chrome существует плагин WebRTC Block или WebRTC Leak Prevent (оно также есть и для Opera). Для FF не нашел, но особо и не искал, т.к по мне достаточно заблокировать сам движок.

Также можно заморочиться с добавлением в систему дополнительного интерфейса, с нужным IP. В виндовой машине это будет Microsoft Loopback Adapter. Но там есть мутотень, что каждый раз, при смене IP прокси, придется менять и айпи адрес нашего виртуального интерфейса, а также его маршрутизацию наружу. Так что этим стоит загоняться только если у вас с избытком свободного времени и не подошли вышеописанные варианты.

JavaScript и ActiveX

Эти надстройки также подвержены протечкам IP, т.ч их желательно закрыть с помощью дополнения NoScript. Оно будет не бесполезно и в мирное время, т.к позволит предотвратить XSS атаки от злодейских сайтов и попыток напихать всякое зверье в процессе браузинга.

Отключаем геолокацию через браузер

geo.enabled = false

Отключаем фичу предупреждения о вредоносных сайтах Google Safe Browsing

browser.safebrowsing.enabled = false

browser.safebrowsing.downloads.enabled = false

browser. safebrowsing.malware.enabled = false

Отключаем отправку телеметрии и отчетов производительности

datareporting.healthreport.service.enabled = false

datareporting.healthreport.uploadEnabled = false

toolkit.telemetry.unified = false

toolkit.telemetry.enabled = false

Отключаем Encrypted Media Extensions (DRM)

media.eme.enabled = false

media.gmp-eme-adobe.enabled = false

Отключаем возможность FF логиниться без спроса к сторонним сервакам Telefonica

loop.enabled = false

Отключаем отслеживание статей и видосов через сторонний сервис Pocket

browser.pocket.enabled = false

Отключаем передачу текста, который мы вводим в окно поиска

browser.search.suggest.enabled = false

Отключаем передачу параметров соединения с сетью

dom.network.enabled = false

Все это и много другое, можно также отрубить с помощью отдельного . И/Или можно поставить HTTP UserAgent cleaner, который позволяет отключать Ajax и WebRTC для определенных доменов, что несомнено лучше чем для всех. Плюс затрудняет идентификацию через другие каналы.

Поскольку я рассматриваю только вопрос анонимности с точки зрения скрытия реального IP, то я не буду вдаваться в подробности всяких параноидальных вопросов защиты от суровых людей в сером, вроде удаления кэша или подгрузки плагинов.

Поэтому я лучше перейду еще к одному разделу – не критическому, но доставляющему некоторым пользователям ментальные страдания. Хотя, наверное, на каких то сайтах по этому параметру, возможно, и могут делать далекоидущие выводы. Я говорю про утечку DNS, которая также сливается браузером.

Вариантов сокрытия своего DNS от сдачи врагам, несколько.

Наиболее простой и безболезненный – это заменить автоматически выданные DNS сервера вашего провайдера на публичные:
Google DNS 8.8.8.8
и 8.8.4.4

OpenDNS 208.67.222.222
и 208. 67.222.220

но т.к к примеру Google вместо 8.8.8.8 светит ближаший DNS, то например для рунета будет показываться финский 74.125.46.10 или любой другой из этой же (или 74.125.74.Х) сеток, что может поставить в тупик. Поэтому надежней выбрать какой нить наиболее близкий к нужной стране из

Вдобавок к этому варианту можно закрыть доступ в браузере FF, чтобы он передавал запросы только через прокси (при работе с SOCKS прокси) и поставить запрет на преварительное разрешение доменных имен (например при просмотре страницы с исходящими ссылками), которые также могут пойти в обход прокси
network.proxy.socks_remote_dns = true

network.dns.disablePrefetch = true

Также можно запретить технологию Teredo, созданную для подключения к хостам IPv6 через чистую сеть IPv4. Для этого надо вызвать DOS-PROMT: Win + R -> cmd
после чего выполнить в консоли команду
netsh interface teredo set state disabled

если понадобится включить Teredo, то в дос-промте выполняем
netsh interface teredo set state type=default

Либо же просто аппаратными средствами, вроде Proxyfier, перенаправить весь трафик по умолчанию через прокси.

Тут надо заметить, что в VPN сетях OpenVPN выше версии v2.3.9 проблема протечки DNS решена введение нового параметра конфига block-outside-dns

Также можно доставить плагин Modify Headers для корректуры фингеров агента, дабы выдавать то, что нужно конечному сайту, хотя по большому счету – этот раздел ни на что не влияет, кроме как на приступы паранойи у серфера.

Либо же настроить руками в конфиге Mozilla

general.appname.override = Netscape

general.description.override = Mozilla

general.appversion.override = 5.0 (Windows)

general.oscpu.override = Windows NT 6.1

general.platform.override = Win32

general.useragent.override = Mozilla/5.0 (Windows NT 6.1; rv:25.0) Gecko/20130730 Firefox/25.0

general.productSub.override = 20100101

general.buildID.override = 20100101

browser.startup.homepage_override.buildID = 20100101

можно поменять фингеры и на какой нить айфон или ведроид, но учитывайте что браузер будет получать код в соответствии с отправленными фингерпринтами, т. ч на компе вы будете смотреть сайт в мобильной версии, что не очень увлекательно.

Утечка VPN трафика и IP при обрыве соединения.

Что делать в этом случае?

Утечка VPN трафика и IP при работе в сетях с IPv6 и IPv4.

Провоцируем преднамеренную утечку трафика.

Что делать в этом случае?

Чтобы отправлять весь трафик через VPN-соединение, тогда стоит сделать следующее:

В случае отсутствия поддержки IPv6 VPN клинетом, необходимо отключить шествую версию протокола на всех доступных сетевых интерфейсах. Тогда, у всех активных в сети приложений не будет другого выбора, кроме как использование IPv4 протокола. !!!Коротко!!!
снимите галочку у протокола IPv6 в настройках сети!
В случае если IPv6 у VPN клиента поддерживается — стоит убедиться в том, что весь передаваемый трафик отправляется через VPN.

А теперь проверь себя!

Всем привет! Недавно, благодаря одному человеку, наткнулся на сервис 2ip.ru/privacy/ . Данный сервис предлагает Вам проверить степень своей анонимизации. Дефект моей системы для вбива заключался в том, что мерчи могли спалить наличие туннеля при помощи двустороннего пинга. Если сервис обнаружит у вас наличие туннеля, то соответственно появляется заветная надпись: «Вероятность анонимизации 99%»
Наша задача заключается в том, чтобы запретить компьютеру принимать запросы пинга от интернет ресурсов. Приступаем к настройке.Во-первых, для начала советую Вам настроить Фаерволл в соответствии с темой пользователя Kardiara
Я сделать это для того, чтобы исключить утечки, а также задобрить Богов Кардинга, принеся в жертву все исходящие подключения, кроме тех, которые производятся из Bitvise»a и Proxifier»a. После того как основная настройка Фаерволла произведена, вносим некоторые дополнения.
Шаг 1.
Заходим в расширенные настройки Фаерволла(Advanced settings).
SpoilerTarget»>Спойлер: Спойлер
Шаг 2.
Выбираем Inbound Rules слева, а затем New Rule справа.
SpoilerTarget»>Спойлер: Спойлер
Шаг 3.
Выбираем Custom Rule.
SpoilerTarget»>Спойлер: Спойлер
Шаг 4.
Выбираем All Programs
SpoilerTarget»>Спойлер: Спойлер
Шаг 5.
Выбираем Protocol type: ICMPv4, если используете для подключение протокол TCP/IPv4 или ICMPv6, если используете для подключения протокол TCP/IPv6 соответственно.
SpoilerTarget»>Спойлер: Спойлер
В разделе Customize оставляем All ICMP types.
Шаг 6.
Оставляем всё как есть для того, чтобы наше правило действовало для всех подключений.
SpoilerTarget»>Спойлер: Спойлер
Шаг 7.
Выбираем Block the Connection. Ведь нам же нужно заблокировать все запросы, связанные с протоколом ICMP (Ping).
Видим, что сервис не имеет доступа для проверки двустороннего пинга.
Что касается открытых портов. Пообщавшись с опытными людьми, пришел к выводу, что это не критично. Ведь разве не имеет права человек открыть порты? К примеру, для поднятия того же сервера Counter-Strike. Значение открытых портов Web Proxy может варьироваться в зависимости от самого туннеля.Можно увидеть: Yes, Maybe,No. Порты открыты именно на самом SSH сервере.
UPD
: Подводя итоги двух дней исследований, сделал вывод о том, что на программном уровне данный тест никак не обойти.
1.Можно попытаться заблокировать ICMP траффик на самом сервере.
2.Обойти данный детект можно:
а.) Использованием дедиков
б.)Использовать быстрый интернет в совокупности с шустрым туннелем.
в.)Используя соксы,вместо SSH (?)
3.Лучше работать с мозиллы, чем с гугл хрома (Личные наблюдения)
4. Обязательно настройте фаерволл в соответствии с темой Kardiara, дабы исключить утечки при разрыве соединения.
5. Не забывайте о таком важном параметре как ProxyScore.

Как добиться 100% анонимности на главной странице Whoer.net

Если вы читаете эту статью, значит у вас есть желание добиться 100% анонимности в сети. Нас часто спрашивают, как добиться заветных Ваша анонимность: 100% на whoer.net. Покажем на примере, что нужно делать, чтобы обеспечить 100% анонимность в сети.

Дано: компьютер с операционной системой Windows 10, Mozilla Firefox 59.0.2.

Цель: 100% анонимности на whoer.net

Организуем VPN подключение

VPN подключение позволит нам скрыть свой IP адрес, DNS и, как следствие, фактическое расположение.

Переходим по предложению приобрести Whoer VPN.

Мы можем купить впн с доступом к серверам 17 стран на максимальной скорости или для начала попробовать бесплатную версию с сервером Нидерландов на скорости 1мб/с. В этой статье рассмотрим использование бесплатной версии Whoer VPN. Проходим по ссылке и вводим e-mail, на который будет выслан код авторизации.

Код придет спустя пару минут на мейл. Проверьте папку СПАМ, если не обнаружили его во входящих.

Скачаем клиент по ссылке из письма или отсюда. Устанавливаем клиент. Если возникают сложности используем инструкцию.

Запускаем скачанный файл. В появившемся окне выбираем необходимый язык. В нашем случае – русский.

Жмем кнопку «ОК». В окне приветствия жмем кнопку «Далее».

Принимаем условия лицензионного соглашения. Выбираем папку для установки и жмем кнопку «Установить».

Ставим галочку «Всегда доверять программному обеспечению «OpenVPN Technologies, Inc.» и жмем «Установить».

Жмем «Готово».

При этом значок клиента Whoer VPN появится в системном трее (подробнее о том, что такое системный трей и где он находится можно прочитать тут).

Если клиент не запустился автоматически, нужно кликнуть по значку Whoer в трее. Для входа в клиент используем код авторизации из письма.

Для настройки параметров запуска, переходим в закладку «Настройки» и производим настройки, например, как на скриншоте.

WhoerVPN запущен. Можно двигаться дальше.

Оценка исходного уровня анонимности

Заходим на whoer.net, видим такую картину. IP сменился, но анонимность 78%.

Чтобы узнать почему уровень анонимности такой, щелкнем по зеленой плашке Ваша анонимность: 78%.

Открылся список замечаний по анонимности и безопасности и рекомендации по устранению этих замечаний. Именно с ними и будем работать.

Устраняем замечания по анонимности и безопасности

DoNotTrack В вашем браузере не включен запрет на отслеживание.

При работе в Интернете все действия пользователя сохраняются в кэше браузера: адреса посещенных сайтов, поисковые запросы, покупки в интернет-магазинах и т.д. Все эти данные могут быть прочитаны сайтами и затем использованы в целях маркетинга или аналитики. Do Not Track – это HTTP-заголовок, который позволяет пользователю обходить отслеживание его действий третьими лицами.

Открываем настройки браузера, выбираем Приватность и защита. Находим защиту от отслеживания и выбрать Использовать защиту от отслеживания для блокировки известных трекеров ВСЕГДА, Передавать сайтам сигнал “Не отслеживать”, означающий, чтобы вы не хотите быть отслеживаемыми ВСЕГДА.

Если у вас возникли трудности при настройке, воспользуйтесь инструкцией по ссылке.

Заходим на whoer.net, замечания DoNotTrack больше нет. Анонимность, по-прежнему, 78%.

Разное системное время

Заходим на whoer.net. Анонимность уже 70%. Смотрим параметры времени.

Замечания Разное системное время больше нет. Осталось только одно замечание.

Отличие языка

Это замечание означает, что язык операционной системы и браузера, отличается от языка страны местоположения. Посмотрим какой язык показывает сервис проверки whoer.net. Чтобы понять какой именно язык необходимо установить, определитесь к какому серверу VPN будет производиться подключение. Все тарифы включают сервера в 17 странах. В бесплатной версии это Нидерланды.

Находим настройки языка, жмем кнопку «Выбрать».

В открывшемся окне щелкаем «Выберите язык, чтобы его добавить…».

Заходим на whoer.net. Ура! Замечаний нет.

Платная версия клиента Whoer VPN включает в себя сервера 17 стран: Россия, США, Канада, Германия, Нидерланды, Великобритания, Франция, Украина, Швеция, Италия, Швейцария, Сингапур, Румыния, Испания, Турция, Польша, Латвия, тогда как в бесплатной версии – только Нидерланды. Таким образом, используя платный клиент Whoer VPN вы сможете настроить VPN под любые требования. Остались вопросы? Задавайте их в комментариях.

Обнаружение скрытых каналов ICMP посредством анализа полезной нагрузки

Мы начинаем Новый 2019 год с пары скриптов Trisul для обнаружения скрытых каналов, использующих PING. Этот сценарий был вдохновлен сообщением в блоге [How To: C2 over ICMP]

Многие межсетевые экраны с отслеживанием состояния разрешают исходящие запросы ICMP ECHO (также известные как PING) и передают соответствующие ответы. Полная блокировка PING встречается редко из-за того, что ИТ-специалисты широко используют ее для устранения неполадок.Обнаружение на основе сигнатур, такое как те, что обнаруживаются в snort icmp.rules по умолчанию, не очень эффективно при отсутствии определенного шаблона в каждом пакете.

Здесь мы представляем новые скрипты Ping Tunnel Detector, которые мы выпустили на Github, которые используют анализ полезной нагрузки с отслеживанием состояния, чтобы обнаружить плохие новости.

Используйте отслеживание содержимого полезной нагрузки для обнаружения C&C или однонаправленного Exfil

Exfil vs C&C Tunnels

Классический способ создания туннелей ICMP — запустить pTunnel.Используя pTunnel, вы получаете TCP-туннель с низкой пропускной способностью около 50 Кбит / с через ECHO и ECHO-REPLY. Это отлично подходит для командования и управления (C&C), которые обычно требуют двусторонней связи.

Типичный C&C

Сначала происходит обмен действительным PING, чтобы пробить дыру в брандмауэре
Затем у вас в значительной степени есть двунаправленный поток, чтобы поддерживать брешь в брандмауэре

Типичный Exfil — туннели, используемые для кражи данных

Конечная точка просто нарезает информацию на небольшие фрагменты, скажем по 512 байтов, и передает ICMP ECHO получателю. Это может быть однонаправленным, могут быть потери пакетов, но таким образом может быть украден большой объем информации. Так как исходящие ICMP ECHO обычно разрешены. Это ничего не трогает.

Существуют правила Snort и Suricata для обнаружения пакетов ICMP ECHO большого размера. Злоумышленники должны поддерживать небольшие размеры пакетов, чтобы избежать этих IDS.

Анализ полезной нагрузки для обнаружения туннелей ICMP

Trisul — это открытая платформа с мощным встроенным механизмом сценариев LuaJIT и API.Мы выпустили два скрипта на Github trisulnsm / trisul-scripts для точного обнаружения практически любого туннеля ECHO. Эти два метода показаны ниже.

icmp-echo-check.lua

см. Icmp-echo-check.lua

Протокол ICMP ECHO требует, чтобы полезная нагрузка в пакете ECHO совпадала с полезной нагрузкой в пакете ECHO-REPLY. Итак, здесь мы проверяем КАЖДУЮ полезную нагрузку эхо-запроса с соответствующим ответом. Это делает невозможным наличие функционального двустороннего C&C, если одна сторона просто перекликается с другой.

hamming-check.lua

см. Hamming-check.lua

Все клиенты PING, которых мы видели, не отправляют полностью случайные данные в полезной нагрузке ECHO. Каждый последующий пакет ECHO изменяется только в первых 8 или 16 байтах или около того. Многие клиенты включают в полезную нагрузку 8-байтовую метку времени, остальная часть полезной нагрузки остается неизменной между пакетами. Мы используем это понимание здесь. Расстояние Хэмминга — это просто причудливый термин для числа, которое говорит вам, насколько похожи две струны одинаковой длины.

Этот сценарий отслеживает расстояние Хэмминга между последовательными полезными нагрузками эха / ответа. Любой C&C или Exfil провалит эту проверку, потому что последовательные полезные данные будут сильно отличаться. На нашей странице GitHub мы задокументировали наш расчет для клиентов PING Linux / Windows / MAC / Cisco, полезные нагрузки очень похожи с расстоянием хэмминга <10. Туннели с фактическими пользовательскими данными составляют> 90!

Оповещение в реальном времени при обнаружении нового туннеля PING

Если такой вид анализа вас интересует, перейдите к Trisul Scripting, загрузив Trisul и ознакомившись с учебными пособиями по началу работы с LUA.

Удачного мониторинга!

Начать работу с Trisul NSM 6.5 прямо сейчас

Ping Tunnel — отправка TCP-трафика через ICMP

Для тех случаев, когда все остальное заблокировано.

Даниэль Стёдл, [email protected]

Последнее обновление: 26 мая 2005 г.

Что это?

Ptunnel — это приложение, которое позволяет надежно туннелировать TCP-соединения с удаленным хостом, используя эхо-запросы и ответные пакеты ICMP, обычно известные как запросы и ответы ping.На первый взгляд это может показаться довольно бесполезным занятием, но в некоторых случаях оно действительно может пригодиться. Следующий пример иллюстрирует главную мотивацию создания туннеля:

Настройка: вы в пути и наткнетесь на открытую беспроводную сеть. Сеть дает вам IP-адрес, но не позволяет отправлять пакеты TCP или UDP в остальную часть Интернета, например, для проверки вашей почты. Что делать? Случайно вы обнаружите, что сеть позволит вам пинговать любой компьютер в остальной части Интернета.С помощью ptunnel вы можете использовать эту функцию для проверки почты или других действий, требующих TCP.

Характеристики и требования

Ptunnel ни в коем случае не является многофункциональным инструментом, но он делает то, что рекламирует. Итак, вот что он может делать:

Туннель TCP с использованием эхо-запроса ICMP и пакетов ответа
Соединения надежны (потерянные пакеты при необходимости пересылаются повторно)
Обрабатывает несколько подключений
Приемлемая полоса пропускания (150 кб / с в нисходящем направлении и около 50 кб / с в восходящем направлении — это измеренные в настоящее время максимумы для одного туннеля, но с настройкой это можно улучшить)
Аутентификация, чтобы никто не мог использовать ваш прокси

Итак, что вам нужно, чтобы все это работало?

Один компьютер, доступный в Интернете, который не защищен брандмауэром (или, по крайней мере, разрешает входящие пакеты ICMP)
Компьютер, выступающий в качестве клиента (обычно это мобильный портативный компьютер, работающий в дороге. .)
Root доступ, желательно на обоих компах
Posix-совместимая ОС с libpcap (для захвата пакетов)

Компиляция исходников просто состоит из запуска make. Нет ./configure, make, make install, just make. Полученный двоичный файл называется ptunnel . См. Раздел использования ниже для получения информации о его запуске.

Как это работает

Это техническое описание того, как работает ptunnel. Если вас не интересуют детали низкоуровневой сети, вы можете пропустить этот раздел.Это может помочь прочитать его в любом случае, поскольку он дает некоторое представление о ситуациях, когда ptunnel не работает.

Ptunnel работает путем туннелирования TCP-соединений через пакеты ICMP. Далее мы поговорим о прокси-сервере , , клиенте и назначении . Прокси-сервер — это «конечная точка» для наших пакетов ping, то есть компьютер, на который мы отправляем пакеты ping. Клиент — это компьютер, с которого мы пытаемся выйти в сеть, а место назначения — это компьютер, к которому мы обычно пытаемся получить доступ через TCP (например, веб-сайт или где-нибудь ssh-сервер).

Итак, для этого нам нужна возможность отправлять и получать ping-пакеты. Многие операционные системы позволяют нам делать это с помощью так называемых сырых сокетов. Необработанные сокеты являются предпочтительным механизмом для отправки пакетов ICMP и используются как прокси-сервером, так и клиентом. К сожалению, для необработанных сокетов требуется root-доступ, поэтому есть возможность использовать стандартные сокеты для дейтаграмм, если они поддерживаются операционной системой (Mac OS X 10.2 или более поздней версии поддерживает это, но для Linux-систем потребуется root-доступ в любом случае).Ptunnel поддерживает это, но не рекомендуется для фактического использования. Мы вернемся к причине позже.

Клиент будет выполнять все свои коммуникации, используя пакеты эхо-запроса (ping) ICMP (тип 8), тогда как прокси будет использовать пакеты эхо-ответа (тип 0). Теоретически возможно, чтобы прокси также использовал пакеты эхо-запроса (и, таким образом, заставлял его работать без root), но эти пакеты не обязательно пересылаются клиенту за пределы хост-сети, поэтому они не используются.

Рисунок 1.Настройка сети.

Протокол

Протокол прокси использует четыре разных типа сообщений в сочетании с порядковыми номерами и полем подтверждения. Магическое число используется для того, чтобы отличать наши запросы и ответы на запросы ping от «обычных» запросов. Общий формат пакета (не включая заголовки IP или ICMP) показан на рисунке ниже.
Рисунок 2. Формат пакета, используемый для обмена сообщениями между клиентом и прокси.

Поля IP и порта используются только в пакетах от клиента к прокси.Они указывают, куда клиент хочет пересылать полученные пакеты (на самом деле они используются только один раз — когда прокси получает первое сообщение с кодом состояния kProxy_start).

Коды состояний:
kProxy_start = 0;
kProto_data = 1;
kProto_ack = 2;
kProto_close = 3;
kProto_authenticate = 4;

Флаги идентификатора:
kUser_flag = 1 << 30;
kProxy_flag = 1 << 31;

Государственный кодекс служит двойной цели.

Во-первых, он указывает, какое сообщение получено — либо сообщение, запускающее новый сеанс прокси (kProxy_start), сообщение, содержащее данные для пересылки (kProto_data), явное подтверждение полученных пакетов (kProto_ack, сообщение закрытия (kProto_close) или запрос / ответ аутентификации (kProto_authenticate). Во-вторых, он указывает, кто отправил сообщение: сообщение, отправленное клиентом, будет иметь установленный бит kUser_flag, тогда как сообщение, отправленное прокси, имеет установленный бит kProxy_flag.Это необходимо, поскольку запрос ping заставит операционную систему на прокси-компьютере вернуть свой собственный эхо-ответ, который идентичен пакету, который мы только что отправили на прокси.

Поля ack и seq тесно связаны. Смоделированный после использования подтверждений в TCP, протокол ptunnel помещает порядковый номер последнего полученного пакета в поле подтверждения любого исходящего сообщения. Поле seq представляет собой монотонно увеличивающийся 16-битный счетчик, которому разрешено оборачиваться (хорошо, поэтому я предполагаю, что это монотонный до , который он оборачивает). Каждый раз, когда исходящий пакет слишком долго ждал подтверждения, одноранговый узел будет пытаться повторно отправить первый пакет, еще не подтвержденный.

Поле длины просто указывает длину части пакета данных и равно 0 для всех других значений состояния, кроме kProto_data. Наконец, поле rsv содержит два байта, которые зарезервированы (пока они служат заполнением).

Получив запрос kProxy_start, прокси откроет TCP-соединение с сервером, указанным в полях ip и port.Когда данные поступают через TCP-соединение, прокси-сервер преобразует данные в пакеты эхо-ответа ICMP и отправляет их удаленному узлу. Клиент будет делать то же самое, за исключением того, что его пакеты всегда будут пакетами эхо-запроса.

Аутентификация

Начиная с версии 0.60, Ping Tunnel поддерживает аутентификацию. Используемая аутентификация очень проста и работает следующим образом. Пользователь сначала указывает пароль или кодовую фразу, которая затем хешируется с использованием алгоритма MD5 (Ping Tunnel использует реализацию L. Питер Дойч, доступно здесь. Обратите внимание, что реализация включена в Ping Tunnel, поэтому нет необходимости загружать ее отдельно).

Всякий раз, когда прокси получает запрос на новый туннель, он отвечает запросом аутентификации. Задача состоит из отметки времени, дополненной случайными данными, всего 32 байта. Ответ рассчитывается следующим образом (+ означает конкатенацию строк):

md5 (вызов + md5 (пароль))

Прокси-сервер проверяет результат, вычисляя те же суммы md5, а затем сравнивая их.Если аутентификация прошла успешно, прокси позволяет трафику TCP начать течь в любом направлении; в противном случае соединение разорвано.

Обработка нескольких подключений

Прокси-сервер обрабатывает несколько различных подключений с помощью поля идентификатора ICMP. Клиент случайным образом сгенерирует идентификатор при запуске сеанса, и удаленный партнер будет использовать этот идентификатор для связывания пакетов с соединением. Этот механизм не является надежным, но работает приемлемо до тех пор, пока никакие два экземпляра не пытаются использовать один и тот же идентификатор (в настоящее время нет механизма для сообщения о таких ошибках).

Поле порядкового номера ICMP не используется ptunnel, в основном из-за опасений, что некоторые маршрутизаторы могут отбрасывать пакеты, порядковые номера которых повторяются. Вместо этого отдельный порядковый номер используется как часть формата пакета ptunnel (см. Выше).

Окна отправки и получения

Ptunnel использует простую концепцию окон отправки и получения для управления количеством пакетов, которые могут находиться в полете одновременно. Окно в настоящее время статически распределено на 64 пакета, но это число можно настроить, изменив файл заголовка ptunnel (да, требуется перекомпиляция).Увеличение размера окна улучшит максимальную потенциальную пропускную способность.

Окна отправки и приема просто реализованы как набор круговых массивов с указателями, указывающими следующий доступный слот отправки / получения и первый неподтвержденный пакет.

Обработка потери пакетов

Ptunnel обрабатывает потерю пакетов, повторно отправляя (предположительно) потерянные пакеты. По мере отправки пакетов он увеличивает порядковый номер. И клиент, и прокси поддерживают свой собственный порядковый номер, а также номер, указывающий последний порядковый номер, подтвержденный удаленным партнером.Каждый раз, когда проходит слишком много времени (1,5 секунды) без подтверждения пакета, одноранговый узел повторно отправляет этот пакет.

Обратите внимание, что партнер только повторно отправит первый отсутствующий пакет. Как только этот пакет был подтвержден, может повторно отправить следующий пакет (ы), в зависимости от того, сколько пакетов было подтверждено. Если следующие несколько пакетов также подтверждаются, они удаляются из очереди отправки. Нередко один пакет теряется, а большинство остальных проходит.Этот механизм позволяет избежать ненужных повторных отправок в максимально возможной степени.

Контроль перегрузки

В настоящее время Ptunnel не осуществляет явного контроля перегрузки. Он будет отправлять столько пакетов ping, сколько позволяет размер окна, так медленно или так быстро, как сочтет нужным. Это может быть улучшено в будущем, если это окажется проблемой (что совсем не маловероятно ..).

Когда что-то не работает

Есть ряд ситуаций, когда ptunnel не работает. Вкратце их можно разделить на следующие категории:

Исходящий / входящий пинг не разрешен или отфильтрован шлюзом где-то по пути
Операционная система, вызывающая проблемы
Возможно и другие отказы;)

Мы не можем справиться с первой ошибкой — если наши пакеты фильтруются до того, как мы до них добираемся, мы мало что можем сделать.Со вторым сценарием можно справиться, используя библиотеку захвата пакетов, чтобы получить пакеты до того, как их увидит ОС. Это необходимо в Mac OS X, а также может быть необходимо на других платформах. Проблема заключается в том, что ОС может иногда не доставлять ICMP-пакеты в необработанный сокет, который мы открыли для отправки и получения. Это происходит, когда пакет ICMP является эхо-запросом (который ОС обрабатывает сама по себе) или когда пакет ICMP является повторной отправкой (по какой-то странной причине). Обходной путь — использовать захват пакетов, однако это имеет тенденцию к значительному уменьшению пропускной способности.По этой причине вы всегда должны пытаться запустить прокси без захвата пакетов и сначала посмотреть, работает ли это. (Это режим «по умолчанию.)

Скачать

Текущая версия ptunnel — 0.61, а исходный код доступен для загрузки здесь . Страница проекта Freshmeat находится здесь (пожалуйста, уделите время, чтобы оценить ptunnel, если вы сочтете его полезным — спасибо!). Здесь также доступен ряд RPM для разных платформ:
http: // dries.studentenweb.org/apt/packages/ptunnel/info.html
или в этом зеркале:
http://dag.wieers.com/packages/ptunnel/

На данный момент Ptunnel был протестирован на различных конфигурациях, включая Linux Fedora Core 2 и Mac OS X 10.3.6 и выше.

Доступны два неофициальных порта Windows, представленные Альфредом Янгом и Бастианом Шмитцем на основе дистрибутива 0. 52. Нажмите здесь, чтобы загрузить оба . Обратите внимание: если у вас есть вопросы по их компиляции, вам нужно будет связаться с соответствующими авторами — я не запускаю Windows, поэтому я не могу помочь в этом отношении.

Использование ptunnel

Клиент: ./ptunnel -p <адрес прокси> -lp <порт прослушивания> -da <адрес назначения> -dp <порт назначения> [-c <сетевое устройство>] [-v <многословие>] [-f < файл журнала>] [-u] [-x пароль]
Прокси: ./ptunnel [-c <сетевое устройство>] [-v <многословность>] [-f <файл журнала>] [-u] [-x пароль ]

Ключ -p устанавливает адрес хоста, на котором работает прокси.Быстрый тест, чтобы увидеть, будет ли работать прокси, — это просто попытаться проверить связь с этим хостом — если вы получите ответы, вы сможете заставить туннель работать.

Ключи -lp, -da и -dp устанавливают локальный порт прослушивания, адрес назначения и порт назначения. Например, для туннелирования ssh-соединений с клиентского компьютера через прокси-сервер, работающий на proxy.pingtunnel.com, на компьютер login.domain.com, будет использоваться следующая командная строка:

sudo ./ptunnel -p proxy.pingtunnel.com -lp 8000 -da логин.domain.com -dp 22

Теперь можно установить ssh-соединение с login.domain.com следующим образом:

ssh -p 8000 локальный хост

Если ssh жалуется на потенциальные атаки типа «злоумышленник в середине», просто удалите неверный ключ из файла known_hosts. Предупреждение / ошибка ожидается, если вы ранее подключились по ssh к локальному компьютеру (например, ssh localhost) или использовали ptunnel для перенаправления ssh-соединений на разные хосты.

Конечно, чтобы все это работало, вам нужно запустить прокси на вашем прокси-компьютере (мы назовем его прокси.pingtunnel.com здесь). Сделать это очень просто :

sudo ./ptunnel

Если вы обнаружите, что прокси не работает, вам нужно будет включить захват пакетов на основном сетевом устройстве. В настоящее время предполагается, что это устройство является Ethernet-устройством (то есть Ethernet или беспроводным). Захват пакетов включается переключателем -c и указанием имени устройства для захвата пакетов (например, eth0 или en1). То же самое и с клиентом. В версиях Mac OS X до 10.4 (Tiger), захват пакетов должен быть всегда включен (как для прокси, так и для клиента), иначе повторно отправленные пакеты не будут получены.

Чтобы защитить себя от других, использующих ваш прокси-сервер, вы можете защитить доступ к нему паролем с помощью переключателя -x. Пароль никогда не отправляется в открытом виде, но имейте в виду, что он может быть виден из таких инструментов, как top или ps, которые могут отображать командную строку, используемую для запуска приложения.

Наконец, ключ -u попытается запустить прокси в непривилегированном режиме (т.е.д., нет необходимости в корневом доступе), а ключ -v контролирует объем вывода из ptunnel. -1 указывает на отсутствие вывода, 0 показывает только ошибки, 1 показывает информационные сообщения, 2 дает больше вывода, 3 обеспечивает еще больше вывода , уровень 4 отображает отладочную информацию, а уровень 5 отображает абсолютно все, включая неприятные детали отправок и
получает. Ключ -f позволяет сохранять вывод в файл журнала.

Изменения

0.61 — 26. Май 2005 г.

Отметил, что ptunnel теперь работает без захвата пакетов в Mac OS X 10.4 Тигр.
Файлы журнала теперь открываются в режиме добавления (т. Е. Не усекаются).
Исправлена ошибка, которая могла привести к сбою ptunnel, если использовались пароли короче 16 символов (подавляющее большинство паролей, скорее всего!).

0.60 — 15. Апр 2005

Добавлена поддержка аутентификации, изменяются части протокола ptunnel.
Добавлена страница руководства.
Добавлена реализация MD5 Л. Питером Дойчем для аутентификации.
Перемещено объявление переменной, чтобы позволить ptunnel правильно скомпилировать на gcc 2.95 — спасибо Чунг!
Добавлена обработка ошибок для прокси-соединений.
Исправлена проблема с печатью информации об отправке / получении. Все уровни детализации теперь должны работать.
Обновленная контактная информация.

0,55 — 18 февраля 2005 г.

Исправлена ошибка блокировки, которая проявлялась при достижении максимального количества подключений на прокси-сервере.
Исправлен ptunnel для правильной компиляции на 64-битных архитектурах (спасибо Осмунду Граммельтведту за указание на необходимые изменения!)
Добавлен новый уровень ведения журнала (уровень 5).Уровень 4 больше не выводит информацию об отправке и получении; для этой информации необходим 5 уровень.
Когда используется libpcap, интерфейс больше не переводится в неразборчивый режим. В этом никогда не было необходимости, а также делает невозможным использование ptunnel более чем с одним клиентом в одной сети.
Обнаружена проблема с pcap, из-за которой ptunnel зависал при использовании pcap. Эта проблема не решена; обходной путь — просто повторно запустить клиент или, если возможно, отключить pcap.
Добавлена поддержка для указания файла журнала в командной строке с помощью ключа -f.

0,54 — 1 февраля 2005 г.

Исправлена ошибка порядка байтов (спасибо Альфреду!)

0.53 — 31. Янв 2005

Исправлена ошибка потоковой передачи и реализована поддержка ограничения максимального количества туннелей.

Благодарим Альфреда Янга за сообщение и исправление следующих ошибок:

Исправлена ошибка с пакетами, захваченными через libpcap, когда struct sockaddr не обнулялась должным образом.
Исправлена ошибка порядка байтов в create_and_insert_proxy_desc.
Исправлена утечка памяти в remove_proxy_desc.

0,52 — 3 января 2005 г.

Исправлена проблема, связанная с изменением поля идентификатора ICMP. Прокси-сервер не сохранял идентификаторы пакетов, полученных от клиентов, что приводило к отбрасыванию пакетов ICMP на маршрутизаторе. Это, в свою очередь, приводит к тому, что туннель больше не работает, в зависимости от строгости маршрутизатора. Эта версия устраняет эту проблему.
Makefile стал лучше благодаря Дрису Верахтерту.

0,51 — 2 января 2005 г.

Исправлено некорректное вычисление контрольной суммы для повторно отправленных пакетов.
Перестал полагаться на «встроенное» поле идентификатора пакета ICMP и переместил информацию в часть пакета данных.
Уровень детализации по умолчанию изменен с отладки на подробный.

0,50 — 7 декабря 2004 г.
Первоначальный общедоступный выпуск.

Лицензия

Ptunnel находится под лицензией BSD.

Обратная связь

Буду благодарен за любые отзывы, которые у вас могут быть — отправьте их мне сюда: daniels @ cs.uit.no. Мне интересно услышать об ошибках, предложениях и, естественно, общей критике. Если вы сочтете это полезным, я тоже хотел бы узнать об этом 🙂

Как хакеры используют туннелирование ICMP для владения вашей сетью

В недавних статьях мы видели, как злоумышленники могут получить первоначальный доступ к сети с помощью Office Макроатаки и способы использования Responder для кражи учетных данных, повышения привилегий и горизонтального перемещения в сети. Первоначальный доступ, повышение привилегий и горизонтальное перемещение — три ключевых компонента корпоративных атак, но это еще не все.

На самом деле, гораздо больше: согласно модели злоумышленника MITRE, методологии корпоративных атак можно разделить на 12 подкатегорий, представляющих различные фазы жизненного цикла кампании. В этой серии статей мы рассмотрим различные методологии и инструменты атак, объясним их роль в общей схеме работы киберсетей и обсудим варианты снижения рисков.

Рисунок: 1 ATT & CK MITRE для Enterprise Adversary Model

Сегодняшняя статья касается C&C Communication и Data Exfiltration .Наличие в той или иной форме интерфейса управления и проникновения с целевыми машинами является жизненно важной частью большинства кибер-кампаний, и это может показаться довольно простым. В конце концов, C&C — это, по сути, форма связи между жертвой и атакующей машиной, а связь между конечными точками — одна из самых основных функций любой современной машины.

Но по мере того, как с годами увеличивались угрозы безопасности, растёт и ландшафт решений безопасности. От межсетевых экранов, систем обнаружения и предотвращения вторжений (IDS & IPS) и систем управления информацией и событиями безопасности (SIEM) до аналитики поведения пользователей и объектов (UEBA), анализа протоколов с отслеживанием состояния и стеганографии — мониторинг трафика становится все более жестким, и злоумышленники вынуждены найти новые способы остаться незамеченными.

Туннелирование протокола

Одним из основных методов запутывания трафика является Туннелирование протокола (MITER T1572: Туннелирование протокола ^[1]) . При туннелировании протокола вместо явной отправки пакетов данных в выбранном протоколе (например, TCP) злоумышленники инкапсулируют пакеты в другой протокол. Такое поведение помогает скрыть вредоносный трафик внутри, казалось бы, безобидных форм связи, помогая избежать обнаружения. Кроме того, его можно использовать для шифрования данных и защиты личности и интересов злоумышленника.

Помимо создания скрытого канала управления и утечки данных между двумя машинами, туннелирование протоколов также может использоваться для обхода недоступных порталов для платных услуг Wi-Fi. Часто портальные системы блокируют большую часть трафика TCP и UDP к / от незарегистрированных хостов, но разрешают другие протоколы, такие как ICMP, DNS и т. Д. Злоумышленники могут использовать это, туннелируя свой трафик внутри пакетов разрешенного протокола.

Расширяя возможности традиционного туннелирования протоколов, хакеры могут использовать протоколы неприкладного уровня, которые, как правило, считаются менее подверженными отслеживанию на предмет злонамеренных действий, для сокрытия своего трафика.

ICMP и туннелирование

ICMP

Одной из распространенных форм туннелирования протоколов неприкладного уровня является ICMP Tunneling .

Протокол управляющих сообщений Интернета (ICMP) — это протокол сетевого уровня OSI, используемый для обнаружения и управления проблемами маршрутизации в сети.Когда сетевые устройства обнаруживают определенные ошибки, они генерируют пакеты ICMP, чтобы проинформировать конечные точки о том, что произошло.

Например, когда в сети возникает петля маршрутизации, IP-пакеты будут бесконечно перемещаться по петле, и в конечном итоге их значение TTL упадет до нуля. На этом этапе последний маршрутизатор, получивший пакет, отправит сообщение ICMP «Превышено время: TTL истек при передаче» на IP-адрес источника пакета.

ICMP-сообщения также могут использоваться для управления маршрутизацией.Например, если конечная точка отправляет пакет по неэффективному маршруту, маршрутизаторы по пути могут обнаружить это поведение и отправить пакет ICMP «Перенаправить сообщение », который предложит лучший маршрут для использования в следующий раз.

Вообще говоря, этот протокол не реализован на конечных компьютерах, за исключением двух очень известных инструментов:

Ping — Сетевая утилита, используемая для проверки доступности хоста по IP и измерения времени приема-передачи. Ping использует для работы пакеты ICMP «Echo» — мы подробно остановимся на них позже.
Traceroute — Утилита сетевой диагностики, которая отображает узлы и задержки передачи маршрута между двумя машинами в IP-сети с использованием ICMP. При «отслеживании маршрута» traceroute отправляет несколько IP-пакетов на запрошенный хост. Эти пакеты предназначены для того, чтобы каждый маршрутизатор на своем пути отправлял сообщение ICMP « Time Exceeded» хосту-источнику, содержащее различную информацию о маршрутизаторе.

Туннелирование ICMP

Помните, как ping использует пакеты ICMP Echo для проверки доступности хоста по сети? Обычно хост, отправляющий эхо-запрос, отправляет пакет Echo с некоторыми данными хосту, по которому выполняется пинг. Затем проверенный хост ответит эхо-ответом , содержащим те же данные. Данные могут быть произвольными, и никаких строгих правил не определено в RFC ICMP.

Злоумышленники могут использовать эту конструкцию, чтобы скрыть вредоносное поведение сети.Вместо того, чтобы явно связываться с машиной в выбранном протоколе, каждый пакет будет вставлен в пакет Echo или Echo Reply . Теперь поток связи будет выглядеть как последовательность операций проверки связи, а не, например, TCP-соединение.

Почему это проблема

ICMP предназначается для обнаружения и контроля сетевых проблем, поэтому его фактическая способность устанавливать канал данных между двумя машинами часто упускается из виду.Более того, поскольку ICMP является важной, хорошо зарекомендовавшей себя частью Internet Protocol Suite и протоколом, не относящимся к прикладному уровню, предприятия с меньшей вероятностью будут отслеживать его так же внимательно, как подозревают обычные кражи данных — HTTP, HTTPS, TCP, IMAP. и т. д.

Более того, смягчение последствий нетривиально, поскольку во многих случаях функциональные возможности ICMP нельзя полностью отключить без значительного воздействия на взаимодействие с пользователем.

Common Tunneling Toolkits

Существует несколько общих наборов инструментов для туннелирования трафика через ICMP, и каждый из них предоставляет немного разные функции.Давайте изучим их.

Icmpsh

Icmpsh — это простой набор инструментов для запуска обратных оболочек на машинах Windows. Он состоит из клиента, написанного на C и работающего только на компьютерах Windows, и POSIX-совместимого сервера, доступного на C, Python и Perl.

Вот некоторые из примечательных особенностей icmpsh:

Используется для C&C — в отличие от некоторых других наборов инструментов icmpsh создает обратную оболочку, которая позволяет использовать ее для C&C с целевыми машинами.
Нацелен на машины Windows — клиент является исполняемым файлом Windows и пока может работать только на машинах Windows.
Низкие привилегии — клиенту не требуются права администратора для правильной работы.
Простота использования — и клиентское, и серверное приложения чистые, портативные и очень простые в использовании и практически не требуют настройки.

Ptunnel

В отличие от icmpsh, который используется для C&C, ptunnel предназначен для обфускации и туннелирования TCP-трафика.При выполнении клиент ptunnel будет туннелировать TCP через ICMP на назначенный сервер ptunnel. Сервер будет действовать как прокси-сервер и будет пересылать TCP-пакеты к их фактическому месту назначения и обратно. Этот набор инструментов может работать только в операционных системах, совместимых с POSIX.

Некоторые из функций ptunnel:

Надежные соединения — ptunnel может обнаруживать потерянные пакеты и повторно отправлять их при необходимости.
Несколько подключений — сервер можно настроить для одновременной обработки нескольких подключений.
Поддерживает аутентификацию — для предотвращения использования вашего прокси-сервера неизвестными хостами.

Icmptunnel

Icmptunnel имеет архитектуру, в чем-то похожую на архитектуру ptunnel, но в отличие от последнего он может туннелировать любой IP-трафик. Кроме того, он будет туннелировать все IP-пакеты клиента, а не только один сеанс, порт и т. Д. Это делает этот инструмент очень полезным для обхода захваченных порталов Wi-Fi, но несколько менее полезным для скоординированных кибератак. И клиент, и сервер должны быть совместимы с POSIX.

Некоторые из примечательных особенностей icmptunnel:

Шифрование данных — полезная нагрузка ICMP зашифрована.
Универсальность — туннелировать можно любой IP-трафик.

Демонстрация

В этой демонстрации мы будем использовать icmpsh для туннелирования сеанса обратной оболочки между нашей атакующей машиной Kali Linux и машиной жертвы Windows 10.

Мы выбрали icmpsh, потому что он не требует прав администратора для работы на машине жертвы и очень портативен.

Рисунок 2: Схема демонстрационной сети. Атакующий — 192.168.68.113, жертва — 192.168.68.115.

Шаг 1.

Отключение эхо-ответов ядра

Перед запуском icmpsh нам нужно запретить ядру отвечать на эхо-запросы ICMP. Большинство инструментов туннелирования ICMP реализуют механизмы для синхронизации потока данных между двумя машинами, и ответы ядра могут привести к неожиданным результатам.

Чтобы отключить ответы ядра, мы добавили следующую строку в файл / etc / sysctl.conf файл: net.ipv4.icmp_echo_ignore_all = 1 .

Рисунок 3: Редактирование файла sysctl.conf для отключения эхо-ответов ядра

Шаг 2 — Запуск сервера и клиента Icmpsh

Сначала мы запустим сервер icmpsh на нашей машине Kali Linux. К счастью, этот инструмент очень прост в использовании и требует только двух аргументов: IP-адреса злоумышленника и жертвы.

Рисунок 4. Запуск сервера icmpsh на машине Kali Linux.

Наша машина ожидает ping-запросов от нашей жертвы 192.168.68.115.

Теперь мы можем запустить клиент, который представляет собой исполняемый файл, который можно загрузить со страницы GitHub, указанной выше. Вот его аргументы. на машине с Windows 10.

На атакующей стороне мы начинаем получать данные SSH:

Рисунок 7. Сервер Icmpsh, отображающий вывод обратной оболочки клиента.

Шаг 3. Выполнение команд оболочки

Теперь, когда все настроено, у нас есть работающая обратная оболочка на нашем сервере Kali. Например, мы можем ввести systeminfo , чтобы собрать информацию о машине нашей жертвы:

Рисунок 8: Запуск systeminfo через обратную оболочку icmpsh

При проверке сетевого трафика между двумя машинами мы можем увидеть обширный объем пакетов ICMP:

Рисунок 9: Обширный трафик ICMP между злоумышленником и жертвой, зафиксированный в Wireshark после запуска обратной оболочки.

Кроме того, поскольку icmpsh не шифрует данные, мы можем видеть текст оболочки, введенный внутри дейтаграмм:

Рисунок 10: Открытый текст обратного вывода оболочки (отмечен синим), запутанный внутри пакета ICMP.

Снижение риска

Вообще говоря, трафик ICMP не может быть полностью заблокирован, поэтому меры по снижению риска должны быть сосредоточены на минимизации рисков с помощью мер по обнаружению сети и конечных точек.

Продукты Cynet для защиты сети реализуют интеллектуальную эвристику и алгоритмы машинного обучения для обнаружения и предотвращения туннелирования ICMP. Некоторые общие шаблоны туннелирования, которые могут быть обнаружены:

Расширенное использование ICMP — Особенно при туннелировании больших объемов данных может быть обнаружен значительный объем ICMP-трафика, входящего или исходящего из сети.
Ненормальный размер пакета — Тесно связано с предыдущим пунктом, злоумышленники могут уменьшить общее количество пакетов, вставляя более крупные датаграммы в каждый запрос или ответ. Как правило, допустимые запросы и ответы Echo будут иметь фиксированный стандартный размер, поэтому различные размеры дейтаграммы могут указывать на то, что соединение используется для туннелирования.
Периодические запросы Ping — Как отмечалось ранее, некоторые инструменты туннелирования периодически отправляют пустые запросы ICMP, чтобы пробивать дыры через NAT и межсетевые экраны с отслеживанием состояния. Эту закономерность легко обнаружить, но иногда ее труднее отличить от законного поведения.
Непроизвольная полезная нагрузка ICMP — С помощью инструментов глубокой проверки пакетов данные ICMP-пакетов можно сканировать и сравнивать со структурами и заголовками общих протоколов для непосредственного обнаружения туннелирования.Однако данные могут быть зашифрованы, и если это сделано элегантно, их будет трудно отличить от безобидных полезных данных ICMP.

Кроме того, в дополнение к традиционным методам обнаружения, которые основаны на централизованном анализе трафика через межсетевые экраны, системы IPS и т. Д. ^[2], продукты Cynet могут обнаруживать и предотвращать попытки туннелирования непосредственно на конечных точках, без необходимости в назначенных сетевых устройствах. .

Дополнительная литература

Сноски:

https: // attack.mitre.org/beta/techniques/T1572/
https://arxiv.org/ftp/arxiv/papers/1408/1408.1136.pdf

Туннелирование протокола

Туннелирование DNS — https://www.cynet. com / attack-methods-hands-on / how-hackers-use-dns-tunneling-to-own-your-network /
https://www.kaspersky.com/resource-center/definitions/tunneling-protocol

ICMP

ICMP RFC — https://tools.ietf.org/html/rfc792
http: //www.enterprisenetworkingplanet.com / netsp / article.php / 3584166 / Networking-101-Understanding-and-Using-ICMP.htm
https://en.wikipedia.org/wiki/Traceroute#Implementations
https: //en.wikipedia. org / wiki / Ping_ (Network_utility)

Инструменты туннелирования ICMP

ptunnel — https://www.mit.edu/afs.new/sipb/user/golem/tmp/ptunnel-0.61.orig/web/
ptunnel-ng — https://github.com/lnslbrty/ptunnel-ng
icmptunnel — https://github. com/DhavalKapil/icmptunnel

Mitigation

https: // ссылка.springer.com/chapter/10.1007/3-540-45067-X_20

icmptunnel: Pivot with Ping

Icmptunnel — это инструмент для туннелирования IP-трафика в пакетах эхо-запросов и ответов (ping) ICMP. Он предназначен для полускрытого обхода брандмауэров, например, при повороте внутри сети, где разрешен пинг. Это также может быть полезно для выхода из корпоративной сети в Интернет, хотя эхо-трафик ICMP довольно часто фильтруется по периметру сети.

Хотя существует несколько инструментов, реализующих эту технику, icmptunnel предоставляет более надежный протокол и механизм для туннелирования через межсетевые экраны с отслеживанием состояния и NAT.

Страница проекта находится по адресу: https://github.com/jamesbarlow/icmptunnel.

Чтобы клонировать код с помощью Git:

 # git clone https://github.com/jamesbarlow/icmptunnel.git

Чтобы собрать код, запустите make из каталога проекта.

Инструмент предназначен только для Linux.Во-первых, отключите эхо-ответы ICMP как на клиенте, так и на сервере. Это препятствует тому, чтобы ядро само отвечало на пакеты ping.

 # эхо 1> / proc / sys / net / ipv4 / icmp_echo_ignore_all

На стороне сервера запустите icmptunnel в режиме сервера и назначьте IP-адрес новому туннельному интерфейсу.

 # ./icmptunnel –s 
 открытое туннельное устройство: tun0 
 (ctrl-z) 
 # bg 
 # / sbin / ifconfig tun0 10.0.0.1 netmask 255.255.255.0

На стороне клиента укажите icmptunnel на сервере и назначьте IP-адрес.

 # ./icmptunnel  
 открытое туннельное устройство: установлено соединение tun0 
. 
 (ctrl-z) 
 # bg 
 # / sbin / ifconfig tun0 10.0.0.2 сетевая маска 255.255.255.0

На этом этапе у вас должен быть функционирующий двухточечный туннель через пакеты ICMP. На стороне сервера — 10.0.0.1, а на стороне клиента — 10.0.0.2. На клиенте попробуйте подключиться к серверу через SSH:

 # ssh root@10. 0.0.1 
 Пароль:

Для использования удаленного сервера в качестве зашифрованного прокси-сервера SOCKS:

 # ssh -D 8080 -N root @ 10.0.0.1 
 Пароль:

Теперь укажите в браузере локальный сервер SOCKS.

Инструменты

Ping работают, отправляя целевой пакет эхо-запроса ICMP с сегментом случайных данных, добавленным в качестве полезной нагрузки. Принимающая система копирует эту полезную нагрузку в пакет эхо-ответа ICMP и отправляет его обратно источнику. Идентификатор и порядковый номер используются для сопоставления пакетов запроса и ответа.

Инструменты ping для Windows и Linux по умолчанию отправляют полезные данные размером 64 байта, и это то, что обычно наблюдается при захвате пакетов, но протокол фактически допускает до 64 КБ.

Для туннелирования данных мы назначаем одну конечную точку клиентом, а другую — сервером. Клиент упаковывает IP-кадры в пакеты эхо-запроса ICMP и отправляет их на сервер, в то время как сервер использует соответствующие пакеты эхо-ответа ICMP для обратного трафика. Наблюдателю это кажется последовательностью совпадающих запросов ping и ответов.

Межсетевые экраны с отслеживанием состояния и NAT

Проблема возникает при туннелировании через межсетевой экран с отслеживанием состояния или через устройство NAT.Устройство будет фильтровать ответы ping, не имеющие соответствующего запроса. Для асимметричных соединений, которые имеют гораздо больший трафик от сервера к клиенту, чем наоборот, устройство, вероятно, заблокирует многие ответы ping, поскольку ответов больше, чем запросов.

У инструмента icmptunnel есть механизм, позволяющий обойти это. Клиент периодически отправляет пустые пакеты эхо-запроса ICMP в качестве носителей, чтобы пробить дыры через межсетевой экран с отслеживанием состояния или NAT. Они записываются в таблицу состояний брандмауэра и позволяют возвращать ответный пакет.Удерживая в пути несколько пакетов оператора связи одновременно, клиент поддерживает «окно пакетов», которое сервер может использовать для отправки трафика обратно.

И в Linux, и в Windows программам пользовательского режима требуются повышенные привилегии для взаимодействия с необработанными сокетами. Это недостаток туннелирования ICMP — если вы хотите использовать его для поворота в сети, вам необходимо иметь права root или локального администратора на обоих концах соединения.

Некоторые мысли об обнаружении вредоносного ICMP-трафика:

Отслеживайте объем эхо-пакетов ICMP, исходящих от хоста.Настоящий инструмент ping должен отправлять не более пары пакетов в секунду. Для просмотра веб-страницы с помощью туннелирования HTTP через ICMP может потребоваться несколько тысяч пакетов ICMP за то же время.

Ищите пакеты ICMP, которые содержат более 64 байтов полезной нагрузки, что является значением по умолчанию для большинства реальных реализаций ping. Инструмент icmptunnel можно настроить на ограничение туннелируемых пакетов до 64 байтов, чтобы они выглядели как обычные эхо-запросы и затрудняли обнаружение.

Искать эхо-ответы ICMP, которые не содержат той же полезной нагрузки, что и запрос.

Проверьте эхо-пакеты ICMP на наличие маркеров протокола. Например, этот инструмент включает 4 байта «TUNL» в начале каждой полезной нагрузки ICMP, чтобы различать туннельные пакеты. Это зависит от реализации.

Вместо обычного туннеля, который может транспортировать любой тип трафика, было бы интересно поэкспериментировать со специальным инструментом C2 / pivoting, использующим туннелирование ICMP.

Использование ICMP для передачи произвольных протоколов, таких как HTTP, является шумным, поскольку мы потенциально генерируем огромное количество пакетов ping, и часто необходимо увеличить размер полезной нагрузки сверх нормального, чтобы обеспечить полезный MTU.Благодаря специализированному протоколу C2, использующему простые управляющие сигналы, мы могли бы воспользоваться гораздо более низкой скоростью передачи пакетов и сохранить ожидаемый размер полезной нагрузки в 64 байта. Это сделало бы трафик почти неотличимым от реального ping-трафика.

Кроме того, существующий инструмент не обеспечивает аутентификацию или шифрование. Это сделано намеренно — он создан для передачи IP-пакетов с предположением, что если вам нужна безопасность, вы можете запустить через него защищенный протокол, например SSH. Эта возможность, вероятно, потребуется более специализированному инструменту C2.

Устранение неполадок с подключением к системам через VPN-туннель

Проблемы с путем подключения

Под проблемами пути подключения мы подразумеваем путь между клиентом OpenVPN и целевым сервером, который вы пытаетесь достичь. Мы специально не говорим здесь о проблемах с установкой самого туннеля OpenVPN. Это обрабатывается на отдельной странице: устранение проблем с подключением к VPN-туннелю клиента.

Проблемы с подключением на пути между VPN-клиентом и целевой системой — это большая проблема, особенно если они влияют на ваш бизнес. Поскольку в такой проблеме задействовано множество переменных, а сетевой трафик не виден человеческому глазу, решить проблему, по-видимому, невозможно, несмотря на усилия, которые вы приложили для ее решения. Тем не менее, с помощью правильных диагностических инструментов устранение такой проблемы, безусловно, управляемо и может быть решено. Практически во всех случаях проблемы на самом деле не в конфигурации сервера доступа OpenVPN или клиента Connect, а в целевой сети, к которой вы пытаетесь подключиться, или даже в самой целевой системе.Но чтобы прийти к такому выводу, нужно исключить возможности. Эта страница посвящена выполнению тестов, которые исключают возможности до тех пор, пока не будет сделан вывод, который можно использовать для эффективного решения проблемы.

Специальные настройки Amazon AWS

Если вы используете NAT на сервере доступа, то трафик от клиентов VPN будет отображаться в сети Amazon, как если бы он исходил от самого экземпляра сервера доступа. Это означает, что он выглядит как местный трафик и никаких специальных действий предпринимать не нужно.Но если вы используете режим маршрутизации, в котором исходный IP-адрес пакетов, поступающих от клиентов VPN, остается неизменным, тогда в сети Amazon могут быть функции безопасности, которые блокируют этот трафик. Поэтому в отношении маршрутизации необходимо предпринять особые шаги. Кроме того, вам потребуется реализовать статический маршрут, который направляет ответы на трафик VPN-клиента обратно через экземпляр сервера доступа.

В Amazon AWS, когда вы используете маршрутизацию, в вашем VPC должна быть настроена таблица маршрутизации, которая должна содержать статический маршрут, который указывает подсеть VPN-клиента на экземпляр сервера доступа, чтобы трафик мог попасть туда.Найдите эту таблицу маршрутизации в консоли Amazon AWS, перейдя на панель мониторинга VPC и выбрав Route Tables . Здесь вы можете настроить маршрутизацию для подсети VPN-клиента или межсайтовый трафик к дополнительным подсетям за VPN-клиентами. Когда вы добавляете подсеть в таблицу маршрутизации, вы должны указать цель. Целью может быть AMI ID экземпляра сервера доступа. Затем он должен распознать, что этот конкретный экземпляр EC2 с запущенным на нем сервером доступа является шлюзом к подсети VPN-клиента или дополнительным подсетям типа «сеть-сеть».

Еще одна особенность Amazon — проверка источника / назначения . Грубо говоря, это настройка безопасности самого экземпляра EC2, которая в основном просто смотрит на трафик, исходящий от экземпляра EC2 и идущий к нему, и если это не трафик, имеющий исходный или целевой IP-адрес, который совпадает с адресом сетевого интерфейса этого экземпляра EC2. , затем он просто отфильтровывается. Поскольку клиенты VPN в режиме маршрутизации, а также трафик между сайтами будут отправлять пакеты через сервер доступа, сохраняя исходный IP-адрес источника этих пакетов, этот параметр безопасности будет отфильтровывать этот трафик.Точно так же трафик, идущий на IP-адреса VPN-клиентов или подсети между сайтами и пытающийся пройти через сервер доступа, будет отфильтрован таким же образом. Чтобы решить эту проблему, перейдите на панель EC2 Dashboard , перейдите к Instances и найдите свой конкретный экземпляр, на котором работает сервер доступа. Затем щелкните его правой кнопкой мыши и в меню Networking выберите Change Source / Dest. Проверить . Нажмите кнопку Да, отключить , чтобы отключить этот параметр и пропустить трафик.Если вы используете систему межсетевого шлюза VPN-клиента на Amazon, вам придется сделать то же самое и с этим экземпляром.

Особые настройки Microsoft Azure

Если у вас есть виртуальная сеть с установленным на ней сервером доступа OpenVPN, и вы хотите направлять трафик непосредственно в подсеть клиента VPN, важно отметить, что вы должны сделать это, реализовав маршруты в таблице маршрутизации виртуальной сети. Это самый простой, но необходимый способ. Если вы попытаетесь использовать статический маршрут на виртуальном экземпляре вместо того, чтобы направлять трафик на сервер доступа, а оттуда в подсеть клиента VPN, трафик, скорее всего, будет отфильтрован в сети между вашим экземпляром и сервером доступа.Это похоже на функцию безопасности. Решение состоит в том, чтобы вместо этого реализовать маршрут в таблице маршрутизации виртуальной сети.

Если у вас все настроено и работает, и туннель OpenVPN устанавливается нормально, но у вас возникают проблемы с подключением к определенной системе, информация на этой странице должна помочь вам диагностировать проблему. Если у вас возникли проблемы с подключением к VPN-туннелю в первую очередь, проверьте эту страницу. Один из самых первых шагов в попытке решить проблему соединения между исходной системой (обычно клиентом VPN или системой за клиентом VPN) и целевой системой (обычно системой за сервером доступа) является визуализация пути, по которому трафик следующий.А поскольку сетевые пакеты невидимы для человеческого глаза, это может быть сложно. Есть несколько инструментов, которые помогут визуализировать трафик и проверить, по какому пути следует трафик, а именно:

TCPdump — инструмент командной строки Linux для визуализации сетевых пакетов
WireShark — инструмент Windows GUI для визуализации сетевых пакетов
ping — инструмент тестирования для определения возможности отправки сообщения между источником и местом назначения
traceroute — Аналогично предыдущему, но пытается определить каждый переход между источником и целевым пунктом назначения

С помощью этих инструментов можно отправлять тестовые пакеты информации по соединению от одной системы к другой и видеть эти пакеты появляются на экране и показывают, откуда они приходят (адрес источника) и куда они направляются (адрес назначения).Имея эту информацию, обычно достаточно легко логически проследить путь, по которому следует трафик, и определить, где поток трафика останавливается. И в зависимости от того, где он останавливается, обычно может быть получено логическое объяснение.

В Windows, Macintosh и Linux инструмент ping присутствует по умолчанию. Traceroute обычно также присутствует, но вместо этого может называться tracert. WireShark отсутствует по умолчанию и предназначен только для Windows, но его можно бесплатно загрузить с веб-сайта WireShark. TCPdump — это бесплатный инструмент для Linux, который обычно можно установить с помощью команд, подобных приведенным ниже:

В системах Ubuntu / Debian:

 apt-get install tcpdump

В системах CentOS / Red Hat:

 yum install tcpdump

Прежде чем начать…

Перед тем, как приступить к устранению возникшей проблемы (-ов), было бы целесообразно взглянуть на этих распространенных виновников:

Если вы не можете подключиться к удаленной частной подсети, убедитесь, что правильный доступ делегирован внутри сервера доступа.(например, убедитесь, что ваши локальные подсети перечислены в разделе Настройки VPN , а в разделе Укажите частные подсети, к которым должен быть предоставлен доступ всем клиентам (как ‘network / netmask_bits’, по одному в строке): текстовое поле .) Если вы используете Да, используя параметр маршрутизации (расширенный) , убедитесь, что вы добавили правильные статические маршруты на свой локальный маршрутизатор. Если вы не знаете, как это сделать, или не можете этого сделать, желательно использовать значение по умолчанию Да, используя опцию NAT .Если вы используете опцию NAT, убедитесь, что вы НЕ перечислили свои подсети в разделе Advanced VPN в разделе Private Routed Subnets (Optional) section. Это приведет к потере связи.
Если вы используете режим работы Layer 3 на сервере доступа, убедитесь, что вы не используете тот же диапазон динамических IP-адресов, который вы используете для своей удаленной сети. Другими словами, если ваша ЛВС на стороне VPN имеет сеть 192.168.3.0 с маской подсети 255.255.255.0 , НЕ использует тот же диапазон адресов внутри Настройки VPN , Сеть динамических IP-адресов . Вместо этого используйте то, что не конфликтует с удаленной сетью (например, 10.0.0.0 , маска подсети: 255.255.255.0 ).
Если вы установили Access Server на платформе ESXi, убедитесь, что тип сетевого адаптера — , а не , установленный на Flexible . Если поддерживается вашей ОС и программным обеспечением ESXi, выберите VMXNET3 в качестве типа сетевой карты.Если ваш тип сетевой карты для вашего устройства сервера доступа в настоящее время установлен на , гибкий, , выключите виртуальную машину, удалите сетевой адаптер и прочтите его как другой поддерживаемый тип (предпочтительно VMXNET3). Если у вас установлено значение «Гибкий», могут возникнуть очень странные периодические проблемы.
Убедитесь, что Jumbo Frames , а не включены на каких-либо узлах в вашей сети (например, ваш VPN-сервер, ваш VPN-клиент и целевой сервер, к которому ваш клиент пытается подключиться).
Если установлен программный или аппаратный брандмауэр (особенно если брандмауэр вносит соединения в белый список), убедитесь, что он разрешает ICMP Destination Unreachable: Fragmentation Needed (ICMP Type 3, Code 4) в вашу сеть.Брандмауэр Windows по умолчанию настроил это правило, и нет необходимости явно добавлять это правило на компьютерах с Windows.
Если использование режима TCP для VPN-подключений не является абсолютным, рассмотрите возможность использования режима UDP или Multi-daemon внутри сервера доступа. Выполнение соединений на основе TCP через VPN на основе TCP может привести к периодическим сбоям подключения, а также к другим проблемам с производительностью, и поэтому не рекомендуется в качестве основного метода для установления соединения VPN между двумя узлами.
Убедитесь, что ваш VPN-клиент использует надежное Интернет-соединение с низкой частотой пакетов ошибок. Если ваши клиенты используют менее надежное Интернет-соединение (например, спутниковый Интернет, соединение 3G Mobile / Aircard), то очень важно настроить сервер на использование режимов UDP или multidaemon, как упоминалось ранее.
Используйте тестер сетевых кабелей и / или встроенные инструменты для тестирования кабелей, чтобы убедиться, что ваши кабели Ethernet находятся в хорошем состоянии. Замените все дефектные кабели, о которых сообщили ваши средства тестирования.
Убедитесь, что программное обеспечение / прошивка аппаратного брандмауэра обновлены, и обновите их, если необходимо / необходимо.
Отключите все продукты для обеспечения безопасности в Интернете и антивирусные программы, установленные на компьютерах ваших клиентов, при попытке определить проблемы в сети. Известно, что некоторые антивирусные продукты и продукты для обеспечения безопасности в Интернете вызывают помехи для VPN-соединений, и их следует отключить во время тестирования, чтобы исключить такую возможность.

Обучение диагностике на примере ситуации

Если все вышеперечисленное было проверено, и у вас все еще есть проблема с достижением целевой системы, то следующим логическим шагом будет использование TCPdump и ping для тестирования и визуализации пути между исходной и целевой системой.Итак, давайте предположим, что у нас есть ситуация, подобная показанной на рисунке ниже, и что мы подключены к клиентской программе OpenVPN на компьютере (синий) слева, к серверу доступа (зеленый) посередине, и что мы не могут связаться с сервером справа (фиолетовый).

Это довольно простая ситуация. В нашем примере наш клиент OpenVPN имеет IP-адрес VPN 172.27.232.4 , а сам сервер доступа имеет IP-адрес 192.168.47.133 , а целевой сервер, которого мы пытаемся достичь, имеет IP-адрес 192.168.47.252 . Предположим, вы правильно настроили сервер доступа OpenVPN, и в настоящее время он настроен в настройках VPN для предоставления доступа к 192.168.47.252/32 через yes, используя метод маршрутизации (расширенный) . Предположим также, что подсеть в вашей локальной сети отличается от подсети, в которой находится сервер доступа. Мы предполагаем, что вы выполнили приведенный выше контрольный список и ни одна из упомянутых там проблем не применима, но вы по-прежнему не можете подключиться к фиолетовому целевому серверу.Приступим к тестам.

Использование traceroute на клиенте

Этот инструмент полезен для определения того, куда направляется трафик с вашего компьютера VPN-клиента. Допустим, вы подключены своим компьютером с Windows к серверу OpenVPN, и у вас возникли проблемы с подключением к определенной системе за сервером доступа или на сервере доступа. Один из шагов, который вы можете попробовать, — это выполнить трассировку до IP-адреса, который вы хотите достичь. Например, в командной строке Windows вы можете использовать tracert — короткое имя, которое используется в операционных системах Windows для приложения traceroute.Мы используем параметр -d, чтобы tracert не пытался найти совпадающие имена хостов с каждым IP-адресом, так как это займет много времени и, скорее всего, в любом случае не удастся.

Использование tracert / traceroute в Windows:

 C: \ Windows \ System32> tracert -d 192.168.47.252
Трассировка маршрута до 192.168.47.252 максимум на 30 переходах
 1 20 мс 21 мс 17 мс 172.27.232.1
 2 21 мс 18 мс 18 мс 192.168.47.133
 3 22 мс 23 мс 21 мс 192.168.47.252
Трассировка завершена.

Я хотел достичь целевого IP-адреса 192.168.47.252 , который доступен только через туннель OpenVPN к моему серверу доступа по адресу 192.168.47.133 . IP-адрес моего VPN-клиента по-прежнему 172.27.232.4 , как показано на диаграмме выше. Из приведенных выше результатов видно, что самый первый адрес на пути от VPN-клиента к цели — 172.27.232.1 . Это внутренний IP-адрес подсети VPN-клиента самого моего сервера доступа OpenVPN. Это означает, что трафик с пунктом назначения 192.168.47.252 определенно сначала пытается пройти через VPN-туннель, а оттуда может добраться до места назначения.

Это уже дает нам один полезный вывод, даже если шаги 2 и 3 не сработали. Даже если сработал только шаг 1, очевидно, что трафик попадает в туннель OpenVPN и на сервер доступа OpenVPN. Так что какой бы ни была проблема, она вряд ли сейчас будет на стороне клиента.
Если на самом первом шаге он даже не пытался связаться с внутренней VPN-подсетью VPN-сервера, то, вероятно, есть отсутствующий маршрут, или вы используете клиент с открытым исходным кодом без административных прав, или есть конфликт подсети или разрешений настроены как-то неправильно на сервере.

Использование TCPdump и ping для проверки пути

Перейдите в консоль OpenVPN Access Server или запустите сеанс SSH с этим сервером и получите привилегии root. Убедитесь, что TCPdump установлен. Мы предполагаем, что вы используете систему Debian / Ubuntu.

Установить TCPdump:

 apt-get install tcpdump

Запустить TCPdump и отфильтровать пакеты ICMP (эхо-запросы ping и эхо-ответы). ctrl + c можно использовать, чтобы прервать его, но пока оставьте его включенным:

 tcpdump -eni any icmp

Не закрывая эту программу, перейдите к подключенному клиенту OpenVPN (синий компьютер на нашей схеме).Откройте командную строку или терминал и пропингуйте целевую систему (фиолетовый):

 пинг 192.168.47.252

В выводе TCPdump вы можете увидеть такие результаты:

 15: 35: 18.509365 В ethertype IPv4 (0x0800), длина 76: 172.27.232.4> 192.168.47.252: эхо-запрос ICMP, id 1, seq 28, длина 40
15: 35: 18.509379 Out 00: 0c: 29: c7: 60: e9 ethertype IPv4 (0x0800), длина 76: 172.27.232.4> 192.168.47.252: эхо-запрос ICMP, id 1, seq 28, длина 40

Давайте рассмотрим эти результаты.Мы видим, что поступает пакет эхо-запроса с адресом источника 172.27.232.4 и адресом назначения 192.168.47.252 . Мы также можем видеть присвоенный ему порядковый номер. Пакеты информации, отправляемые по сети, обычно логически пронумерованы, чтобы мы могли легко следить за их ходом. Например, вторая строка — это тот же пакет, у него такой же порядковый номер. Вторая строка показывает, что это исходящий пакет с адресом источника 172.27.232.4 и адрес назначения 192.168.47.252 .
Итак, что мы можем определить здесь, так это то, что запрос на ответ поступает от клиента OpenVPN на сервере доступа, и что сервер доступа перенаправляет этот запрос в сеть, подключенную к интерфейсу с MAC-адресом 00: 0c: 29: c7 : 60: e9 . Если мы посмотрим на наш вывод ifconfig на сервере доступа, мы увидим, что это интерфейс eth0 , который подключен к сети, показанной на диаграмме выше в виде синей пунктирной линии, к которой также подключена целевая система. .Итак, сервер доступа сделал свое дело. Он отправил пакет в целевую сеть.

 корень @ OPENVPNAS: / # ifconfig
[...]
eth0 Link encap: Ethernet HWaddr  00: 0c: 29: c7: 60: e9 
 inet адрес: 192.168.47.133 Bcast: 192.168.47.255 Маска: 255.255.255.0
[...]

Однако в нашем примере нам не хватает пакета эхо-ответа . Итак, на данный момент единственное, в чем мы можем быть уверены, — это то, что сервер доступа перенаправил информацию от VPN-клиента на правильный сетевой интерфейс, и он должен был попасть на целевой сервер.

Если целевой сервер (фиолетовый на схеме) также является системой Linux, вы также можете запустить TCPdump там. Если вы это сделаете, вы должны увидеть такой результат:

 15: 46: 47.568355 In 00: 0c: 29: c7: 60: e9 ethertype IPv4 (0x0800), длина 76: 172.27.232.4> 192.168.47.252: эхо-запрос ICMP, id 1, seq 28, длина 40
15: 46: 47.568395 Out 00: 0c: 29: c9: 6b: 24 ethertype IPv4 (0x0800), длина 76: 192.168.47.252> 172.27.232.4: эхо-ответ ICMP, id 1, seq 28, длина 40

Давайте рассмотрим этот результат.Мы видим, что порядковый номер 28, как и исходный пакет, полученный и пересылаемый сервером доступа OpenVPN. Мы также можем видеть, что пакет пришел в эту систему от сетевого устройства с MAC-адресом 00: 0c: 29: c7: 60: e9 , который является MAC-адресом eth0 на сервере доступа. Таким образом, очевидно, что пакет проходит весь путь от клиента OpenVPN и через сервер доступа OpenVPN в сеть и, наконец, в эту целевую систему. Вторая строка здесь показывает, что эхо-ответ отправляется обратно.Другими словами, целевая система получила запрос на ответ и делает это сейчас. Мы можем видеть, какой MAC-адрес используется для отправки трафика, и мы можем снова сопоставить это с правильным сетевым интерфейсом. В этом случае в системе есть только один сетевой интерфейс, и он подключен к сети, в которой также находится сервер доступа.

Предположим, вы не видели, чтобы пакет прибыл в целевую систему. Что это могло значить? По какой-то причине, например, брандмауэру, трафик прошел от клиента OpenVPN через сервер доступа, но не поступил в целевую систему.Если это на Amazon AWS, я бы заподозрил, что проверка источника блокирует трафик из неизвестной клиентской подсети VPN или параметр группы безопасности , запрещающий пропускать трафик из подсети VPN-клиента. Так что это то, что нужно проверить. Вы также можете проверить, можете ли вы выполнить эхо-запрос от самого сервера доступа к целевой системе. Это должно сработать. Если нет, то есть более серьезная проблема.

После того, как проблема решена и пакеты поступают от клиента OpenVPN через сервер доступа в целевую систему, затем возвращается обратный путь к клиенту OpenVPN.Вот где в большинстве ситуаций что-то идет не так. Как вы увидите в пакете эхо-ответа , адреса источника и назначения поменялись местами. Это вполне логично: он пытается ответить клиенту OpenVPN. Исходный адрес теперь 192.168.47.252 , а адрес назначения теперь 172.27.232.4 .

Если вы видите, что целевая система пытается ответить:

 15: 46: 47.568395 Out 00: 0c: 29: c9: 6b: 24 ethertype IPv4 (0x0800), длина 76: 192.168.47.252> 172.27.232.4: эхо-ответ ICMP, идентификатор 1, последовательность 28, длина 40

Но вы не видите этих строк на сервере доступа:

 15: 56: 07.605958 In 34: 31: c4: 8e: b5: 67 ethertype IPv4 (0x0800), длина 76: 192.168.47.252> 172.27.232.4: эхо-ответ ICMP, id 1, seq 28, длина 40
15: 56: 07.605966 Out ethertype IPv4 (0x0800), длина 76: 192.168.47.252> 172.27.232.4: эхо-ответ ICMP, id 1, seq 28, длина 40

Тогда наиболее вероятным объяснением, если вы упускаете из виду вышеизложенное, является то, что пакеты эхо-ответа не могут найти свой путь к серверу доступа OpenVPN, а оттуда достигают клиента OpenVPN.Чтобы решить эту проблему, необходимо перейти к системе шлюза по умолчанию, обычно к Интернет-маршрутизатору в сети, или к таблице маршрутизации в Amazon AWS, и добавить туда статический маршрут. Статический маршрут подобен карте, которая сообщает сети: если вы хотите достичь этой конкретной сети, вы должны пройти через компьютер / устройство (шлюз) по этому конкретному IP-адресу. В нашем примере я добавил статический маршрут:

Сеть 172.27.224.0 с маской подсети 255.255.240.0 для прохождения через шлюз на 192.168.47.133

Чтобы объяснить этот маршрут немного подробнее, все мои клиенты VPN находятся в подсети 172.27.224.0/20, которая также может быть записана как 172.27.224.0 с маской подсети 255.255.240.0. Для большинства систем, использующих статические маршруты, необходимо указать маску подсети. Некоторые также принимают вместо этого нотацию / 20 CIDR. Здесь есть удобная шпаргалка, которая позволяет легко конвертировать один формат в другой.
Итак, что я сказал своему маршрутизатору в сети, где находится сервер доступа OpenVPN и моя целевая система, так это то, что если вы пытаетесь связаться с моими VPN-клиентами, вам следует пройти через систему по адресу 192.168.47.133. И это IP-адрес моей установки сервера доступа. Всякий раз, когда он получает трафик, предназначенный для клиента OpenVPN, он пытается его ретранслировать (но не при использовании NAT). Так как у меня есть доступ, настроенный с помощью , да, возможно использование маршрутизации (расширенная) для двустороннего трафика .

Почему статический маршрут должен быть добавлен в систему шлюза по умолчанию? Это наиболее логичное место. Когда компьютер является частью сети, он уже знает, как достичь этой сети. Он является частью сети и знает, что если трафик отправляется через сетевой интерфейс, который он использует для подключения к этой сети, он достигнет компьютеров, которые также уже являются частью этой сети и подключены к ней.Это все локально, поэтому нет необходимости использовать какие-либо шлюзы. Но подсеть VPN-клиента не является частью этой локальной сети. Итак, как компьютер узнает, как подключиться к этой подсети VPN-клиента? Ответ — система шлюза по умолчанию. Если компьютер не знает, где находится эта подсеть VPN-клиента, он просто отправит ее на шлюз по умолчанию. Это затем скажет ему, куда вместо этого отправлять трафик.
Теперь TCPdump на сервере доступа при пинге от моего VPN-клиента к целевой системе показывает этот эхо-запрос :

 15:56:07.605601 В Ethernet IPv4 (0x0800), длина 76: 172.27.232.4> 192.168.47.252: эхо-запрос ICMP, id 1, seq 38, длина 40
15: 56: 07.605620 Out 00: 0c: 29: c7: 60: e9 ethertype IPv4 (0x0800), длина 76: 172.27.232.4> 192.168.47.252: эхо-запрос ICMP, id 1, seq 38, длина 40

И в целевой системе я вижу это:

 15: 56: 11.397533 In 00: 0c: 29: c7: 60: e9 ethertype IPv4 (0x0800), длина 76: 172.27.232.4> 192.168.47.252: эхо-запрос ICMP, id 1, seq 38, длина 40

Теперь целевая система отвечает эхо-ответом :

 15:56:11.397563 Out 00: 0c: 29: c9: 6b: 24 ethertype IPv4 (0x0800), длина 76: 192.168.47.252> 172.27.232.4: эхо-ответ ICMP, id 1, seq 38, длина 40

И снова на TCPdump на сервере доступа я вижу, что ответ возвращается и ретранслируется на VPN-клиент:

 15: 56: 07.605958 In 34: 31: c4: 8e: b5: 67 ethertype IPv4 (0x0800), длина 76: 192.168.47.252> 172.27.232.4: эхо-ответ ICMP, id 1, seq 38, длина 40
15: 56: 07.605966 Исходящий IPv4 Ethernet (0x0800), длина 76: 192.168.47.252> 172.27.232.4: эхо-ответ ICMP, идентификатор 1, последовательность 38, длина 40

Эти результаты показывают, что эхо-запроса проходят весь путь от клиента OpenVPN через сервер доступа OpenVPN, в сеть и в целевую систему, а эхо-ответ проходит весь путь обратно от целевая система, обратно через OpenVPN Access Server и обратно в OpenVPN-клиент. Это означает, что связь в двух направлениях теперь работает идеально.

Заключение

В приведенном выше примере показана настройка с маршрутизацией, при которой пакеты проходят весь путь от клиента OpenVPN до целевой системы, а ожидаемые результаты — в TCPdump.Если вы получите разные результаты, дайте нам знать, как выглядит ваша ситуация и какие результаты вы получили, и мы постараемся выяснить, где находится наиболее вероятная точка поломки. Вы, конечно же, можете использовать приведенную выше информацию, чтобы попытаться логически определить это самостоятельно.

Ping Power — ICMP Tunnel. Злоумышленнику часто приходится сталкиваться с… | автор: Нир Чако

Злоумышленнику часто приходится сталкиваться с рядом проблем в своей деятельности.
Две из этих проблем включают:

Преодоление сетевых барьеров (сетевая политика, сегментация и т. Д.).
Выполняйте различные операции в «скрытом режиме», чтобы его не поймали.

Один хороший способ справиться с этими проблемами — использовать ICMP Tunnel при попытке создать скрытое соединение, которое может преодолевать различные барьеры в сети.

В компьютерных сетях туннелирование обычно представляет собой инкапсуляцию одного сетевого протокола в качестве полезной нагрузки другого сетевого протокола. Подробнее

ICMP (протокол управляющих сообщений Интернета) — это поддерживающий протокол в наборе Интернет-протоколов.Он используется сетевыми устройствами для отправки сообщений об ошибках и оперативной информации. Наиболее известным и, вероятно, наиболее часто используемым сообщением ICMP является сообщение Ping.

Ping — это управляющее сообщение, которое является частью ICMP (Internet Control Message Protocol).

Пинг отправляется от одного узла сети к другому. Он состоит из заголовков уровня 2 и уровня 3 (заголовки MAC и IP, определенные модулем OSI) и специального пакета ICMP. Отправляющий узел установит параметры назначения, и если сообщение получено адресатом, он вернет его обратно —

Это IP-дейтаграмма пакета ping —

ICMP-туннелирование может быть выполнено путем изменения данных полезной нагрузки поэтому он будет содержать данные, которые мы хотим отправить.

Обычно он содержит данные полезной нагрузки по умолчанию, такие как эта строка ASCII — «abcdefghijklmnopqrstuvwabcdefghi»

Wireshark — пакет ICMP, данные полезной нагрузки

Если мы инкапсулируем пакет HTTP внутри данных полезной нагрузки, мы получим наиболее распространенный способ этого метода — выскользнуть из платного Wi-Fi.

Этого можно достичь с помощью прокси-сервера, который ожидает сообщений ping и отправляет их по мере необходимости (например, как HTTP).

Используя подходящие инструменты (например, ptunnel), инкапсулируйте HTTP-пакет, который вы хотите отправить в Google, в пакет Ping (внутри Payload Data).Затем отправьте его на IP-адрес прокси-сервера в качестве пункта назначения.

Примечание. Этот IP-адрес не является адресатом HTTP-пакета (IP-адресом HTTP-пакета будет IP-адрес www.google.com)

Поскольку маршрутизаторы аэропортов обычно разрешают трафик ICMP из сети , маршрутизатор доставит сообщение Ping на прокси-сервер.
Прокси-сервер получает пакет Ping, разбивает его на 2 части —

Заголовки ICMP.
Полезная нагрузка, содержащая исходное сообщение HTTP.
Примечание. IP-адрес источника HTTP-пакета, который прокси-сервер отправляет в Google, должен быть IP-адресом самого прокси-сервера, а не IP-адресом вашего ноутбука (или маршрутизатора аэропорта…), потому что Google должен ответить прокси-серверу и не вам.

Это может быть наиболее распространенное использование туннеля ICMP, но , как Red Teamer, я нахожу довольно полезным в качестве «незаметного» метода для обхода брандмауэров и других сетевых политик.

Все это возможно, потому что сообщениям ping разрешено пересекать маршрутизатор из локальной сети «Pay-for-WiFi» в Интернет.
Почему кто-то может допустить такую ситуацию?

Как бывший сетевой инженер, я могу сказать вам, что ping имеет большую мощность при попытке понять и решить даже самые сложные проблемы.
Большинство процессов устранения неполадок начинается с проверки того, проходит ли информация из одной точки в другую. Спрашивают — возможен ли вообще этот информационный маршрут? активны ли сетевые компоненты и могут ли они отвечать?

Сообщения Ping могут самым простым способом ответить на эти и многие другие вопросы.

Эти процессы поиска и устранения неисправностей происходят ежедневно. Это означает, что конфигурация сети должна позволять передачу сообщений ping по сети от одного узла к другому. Каждая политика брандмауэра, политика маршрутизатора и ACL коммутатора (список доступа) должны разрешать поток сообщений ICMP практически от любого сетевого компонента к любому другому.
Вот почему ping-сообщения, скорее всего, будут меньше зависеть от сегментации сети и политик .

Зная это, мне кажется, что для создания соединения в сети, когда вам нужно преодолеть препятствия, такие как сегментация и сетевые политики, было бы неплохо, чтобы агенты соединялись с C&C сервером с помощью туннелирования ICMP.

Я написал простой POC (Proof Of Concept) на Python, чтобы продемонстрировать, как он работает.

Обратите внимание, что:
— Этот POC требует, чтобы вы установили Scapy (это отличный инструмент для узнать о в любом случае)
— Этот POC не будет включать обработку с фрагментация. Фрагментация произойдет, например, если ответ от агента будет больше, чем разрешенный размер данных полезной нагрузки.

Этот POC будет включать C&C сервер и агента. Если сервер C2 будет отправлять команды агента через туннель ICMP, а агент будет возвращать результаты также через туннель ICMP.

Использование этого будет выглядеть примерно так —

И всегда полезно посмотреть, что именно происходит с помощью Wireshark —

C2- pwd commandAgent — pwd result

Как видите — есть 2 сообщения ICMP, одно с команда и один с результатом.

Важно взглянуть с точки зрения защиты и подумать о том, что мы должны учитывать при создании такого рода инструментов.

Самое важное, что нужно помнить, — это то, что инструменты кибербезопасности не начинаются и не заканчиваются политиками белых списков брандмауэра. Большинство современных средств защиты будут включать в себя некоторые функции обнаружения аномалий.

Это хороший способ обозначить некоторые интересные аномалии, сначала описав общее поведение соответствующего объекта.

Говоря о сообщениях ping в обычной сети, мы можем предположить следующие особенности —

Большинство сообщений ping будут отправляться стандартным способом — 4 ping за раз.
Сообщение ping относится к типу 8 (эхо-запрос ping), а ответ Ping относится к типу 0 (ответ эхо-ping)
Есть несколько полей, которые отправляются с каждым пакетом ping (с использованием Windows 8.1) —

id = 0x0001
seq воспроизведения будет равно seq запроса
Данные полезной нагрузки останутся с размером по умолчанию (32 байта) и содержимым — «abcdefghijklmnopqrstuvwabcdefghi»

Зная Затем вы должны учитывать все вышеперечисленное —

Создайте C&C и агент таким образом, чтобы в одном пакете на каждую минуту (например) приходилось не более 4-х ping-сообщений.Если данные, которые вам нужно передать, потребуют 15 сообщений ping — это займет 3 минуты. Это может быть медленным, но если кто-то или что-то наблюдает за этой аномалией — оно того стоит.
Убедитесь, что запрос ping и ответ логически верны . Если каждое отправляемое вами сообщение ping будет иметь, например, тип 0, было бы странно видеть много ответов ping при отсутствии запросов ping.
Постарайтесь быть максимально похожими на свое окружение.Проведите свое исследование. Конечно, вы можете оставить эти поля настраиваемыми и изменять их по мере необходимости.
Обратите внимание, что размер данных полезной нагрузки будет влиять на первый раздел (количество сообщений ping на размер данных), а это информация метаданных .
Содержимое данных полезной нагрузки — давайте поговорим о DPI…

DPI — Deep Packet Inspection

В то время как обычные проверки пакетов считывают метаданные пакета (в основном заголовки), Deep Packet Inspection считывает содержимое пакета , который проходит через него в реальном времени.По сути, он смотрит на полезную нагрузку и пытается понять, правильно ли это выглядит.

В нашем случае — инструмент DPI, использующий свои возможности аномалии протокола, может обнаружить туннель ICMP, посмотрев на полезную нагрузку, и увидеть, что он отличается от того, каким должен быть.

В данном случае это не поможет нам изменить все остальные параметры.

Итак — зачем нам вообще заниматься туннелированием ICMP?

Потому что —

DPI — нетривиальная возможность, и вы можете встретить во многих сетях без этой возможности.
Большинство инструментов DPI полагаются на базу данных сигнатур — если для сообщений ICMP нет сигнатуры, она не обнаружит туннель ICMP.
Даже если в базе данных есть соответствующая подпись, оператор должен сначала настроить ее на активный режим.

Почему он не может активировать его?
Каждая проверка подписи требует ресурсов обработки (в основном ЦП и времени), поэтому она может замедлить работу сети .
Проверки сети могут включать в себя различные типы сообщений ping с разным размером полезной нагрузки (например, ping -l 1234 8.8.8.8 , отправит сообщение ping с данными полезной нагрузки размером 1234 [байт]) для устранения проблем, связанных с функциями MTU. Активация такой подписи приведет к появлению множества ложных срабатываний и, таким образом, раздражает команду мониторинга и снижает надежность подписи.

ICMP Tunneling — отличный инструмент для общения «незаметно». Хотя бывают случаи, когда это будет менее эффективно, в зависимости от существующей защиты в сети, во многих случаях вы обнаружите, что это простой и удобный способ преодолеть определенные ограничения.

Прежде всего, стоит знать эту концепцию. Если у вас есть уловка, вы можете разработать столько различных решений, сколько вам нужно, например — туннель DNS, туннель SSH и так далее…

Как обнаружить туннелирование ICMP

Известно ли вам о каком-либо туннелировании данных, которое может происходить в вашей сети? Вы думаете, что ваша сеть полностью безопасна? Если сеть вашей компании подключена к Интернету, велика вероятность того, что ваш бизнес небезопасен от всех форм вредоносного ПО.

Проблема с большинством решений безопасности заключается в том, что им обычно нужно знать, что они ищут.Администраторы настраивают брандмауэры и маршрутизаторы с правилами доступа в зависимости от того, что они хотят разрешить или заблокировать. Системы обнаружения вторжений используют сигнатуры, и даже межсетевые экраны следующего поколения, использующие глубокую проверку пакетов (DPI), должны понимать какой-то набор правил, который определяет разрешенные или запрещенные пакеты. Приемлемые политики использования пользователями? Они хороши ровно настолько, насколько хорошо пользователь соблюдает правила.

В наши дни на ИТ-рынок наводнен поток решений по обеспечению безопасности. Все они заявляют, что защищают конфиденциальные корпоративные и личные активы.Тем не менее, мы продолжаем регулярно видеть новостные сообщения о взломах компаний и краже данных.

Похоже, злоумышленники опережают кривая решений безопасности. У них есть методы проникновения в сети, которые неизвестны с точки зрения сигнатур. Они используют протоколы и приложения, которые скрывают то, что они делают, и выглядят как совершенно нормальные потоки трафика.

Суть в том, что вы не можете остановить то, чего не знаете, или можете?

Вы можете более активно распознавать и расследовать подозрительное поведение.В наши дни хакеры очень хорошо умеют использовать общие порты и протоколы, особенно те, которые обычно должны быть открытыми. За последние несколько лет мы видели много случаев, когда данные перебрасывались из корпоративных активов с использованием туннелей данных. Туннель — это механизм, используемый для доставки внешнего протокола по сети, который обычно не поддерживает его. Протоколы туннелирования позволяют использовать IP для отправки другого протокола в части «данных» дейтаграммы IP. У большинства протоколов туннелирования есть агент на стороне клиента и сервера, который инкапсулирует данные TCP или UDP в разрешенный, обычно используемый протокол.За последний год мы опубликовали множество блогов, в которых рассказывается об использовании туннелирования DNS и способах обнаружения туннелирования приложений.

Как и в случае туннелирования DNS, когда DNS обычно открыт, ICMP также не блокируется глобально. Существуют законные причины, по которым пользователю или администратору может потребоваться использовать ICMP в сетевой среде для проверки доступности внутреннего или внешнего адреса или маршрутов. Подобно приложениям, используемым для туннелирования DNS, существует множество программ для передачи данных из одной точки в другую через туннелирование ICMP.

Клиент загружает пакеты ICMP с содержимым файла / данных и передает пакеты запроса ICMP адресату. У места назначения есть программа-слушатель, которая считывает и распаковывает пакеты ICMP. Другой метод может заключаться в захвате пакетов, например TCPDUMP, который прослушивает пакеты ICMP с IP-адреса инициирующего клиента.

На самом деле это очень просто. Итак, что мы можем сделать, чтобы знать об этом поведении туннелирования ICMP?

Проблема с DPI в том, что вы не всегда знаете, что искать.Но с помощью NetFlow / IPFIX собираются потоки, которые представляют все разговоры, проходящие по сети. Таким образом, вы получаете возможность видеть подозрительные разговоры, входящие и исходящие из вашей сети, а также входящие внутрь сети, без необходимости видеть содержимое пакета. Подозрительные шаблоны туннелирования распознаются и немедленно предупреждаются без необходимости глобальной блокировки протокола ICMP.

Итак, что мы ищем?

В большинстве случаев ICMP генерирует фиксированное количество байтов в пакете.Размер может меняться в зависимости от операционной системы хоста, но остается очень предсказуемым значением. Таким образом, если мы можем сигнализировать о случаях, когда общее количество байтов по сравнению с количеством пакетов приводит к большему, чем обычно, количеству, мы можем обнаружить это нарушение порога, ничего не зная о содержимом.

Алгоритм проверяет подозрительные шаблоны трафика ICMP и выдает сигнал тревоги. Затем эти шаблоны трафика можно легко проанализировать.

Анализ сетевого трафика с помощью NetFlow или IPFIX может распознавать достаточно странное поведение для защиты от кибератак.Сбор потоков от всех брандмауэров, маршрутизаторов и коммутаторов в вашей сети, по сути, превращает каждое устройство в зонд безопасности и обеспечивает отличный дополнительный уровень безопасности для вашего решения по предотвращению вторжений в сеть.

Суть в том, что ваша компания может и будет взломана. Когда это случится? Что они будут делать? Как вы будете расследовать это событие?

Есть ли у вас представление о трафике, перемещающемся по вашей сети? Свяжитесь с нашей службой поддержки, если вы хотите узнать больше или вам нужна помощь с настройками сигналов тревоги.

Скотт обеспечивает предпродажную техническую поддержку отделу продаж Plixer. Скотт имеет опыт работы в технической поддержке, имея многолетний опыт работы во всем, от управления учетными записями клиентов до системного программирования. В некоторые из его интересов входит обучение молодежным спортивным программам здесь, в Сэнфорде, игра на барабанах и гитаре в местных джем-бэндах и участие в турнирах по дартсу на лужайке.

Связанные

Сетевые операции

Отрасль здравоохранения находится в состоянии повышенной готовности более года.Рабочие нагрузки увеличились вдвое, а количество…

Декабрь 2024
Пн	Вт	Ср	Чт	Пт	Сб	Вс
						1
2	3	4	5	6	7	8
9	10	11	12	13	14	15
16	17	18	19	20	21	22
23	24	25	26	27	28	29
30	31

Определение туннеля двусторонний пинг обнаружен: «Определение туннеля (двусторонний пинг): обнаружен»

Как убрать определение туннеля (двусторонний пинг) в VPN? — Записи обо всём

Как запретить ICMP трафик?

Двусторонний пинг обнаружен что это значит

Встроенные инструменты контроля портов

Просмотр портов вместе с именами процессов

Просмотр портов вместе с идентификаторами процессов

Ttl Details

Устраняем замечания по анонимности и безопасности

DoNotTrack В вашем браузере не включен запрет на отслеживание.

Разное системное время

Отличие языка

Discovering network hosts with TCP SYN ping scans

How to do it…

How it works…

There’s more…

Privileged versus unprivileged TCP SYN ping scan

Firewalls and traffic filtering

TTL details

Trying different data patterns

Насколько безопасен OpenVPN – TheWired

Смотрим на ситуацию с точки зрения защиты

Двусторонний пинг обнаружен что это значит

Страницы

AdSense-web

29 мая 2018

Тестируем настройки браузера на анонимность с использованием прокси-сервера

Как запретить ICMP трафик?

Заголовки HTTP proxy

Открытые порты HTTP proxy

Открытые порты web proxy

Подозрительное название хоста

Разница во временных зонах (браузера и IP)

Принадлежность IP к сети Tor

Режим браузера Turbo

Определение web proxy (JS метод)

Утечка IP через Flash

Определение туннеля (двусторонний пинг)

Утечка DNS

Утечка через ВКонтакте

борьба с утечками трафика и IP

Заголовки HTTP proxy

Открытые порты HTTP proxy

Открытые порты web proxy

Подозрительное название хоста

Разница во временных зонах (браузера и IP)

Принадлежность IP к сети Tor

Режим браузера Turbo

Определение web proxy (JS метод)

Утечка IP через Flash

Определение туннеля (двусторонний пинг)

Утечка DNS

Утечка через ВКонтакте

Заголовки HTTP proxy

Открытые порты HTTP proxy

Открытые порты web proxy

Подозрительное название хоста

Разница во временных зонах (браузера и IP)

Принадлежность IP к сети Tor

Режим браузера Turbo

Определение web proxy (JS метод)

Утечка IP через Flash

Определение туннеля (двусторонний пинг)

Утечка DNS

Утечка через ВКонтакте

Утечка VPN трафика и IP при обрыве соединения.

Что делать в этом случае?

Утечка VPN трафика и IP при работе в сетях с IPv6 и IPv4.

Провоцируем преднамеренную утечку трафика.

Что делать в этом случае?

А теперь проверь себя!

Тестируем настройки браузера на анонимность с использованием прокси-сервера | FreeWebmaster

скрытие ip адреса от утечки

Утечка VPN трафика и IP при обрыве соединения.

Что делать в этом случае?

Утечка VPN трафика и IP при работе в сетях с IPv6 и IPv4.

Провоцируем преднамеренную утечку трафика.

Что делать в этом случае?

А теперь проверь себя!

Рекомендуем также