Port 6881 Details
Notes:
Port numbers in computer networking represent communication endpoints. Ports are unsigned 16-bit integers (0-65535) that identify a specific process, or network service. IANA is responsible for internet protocol resources, including the registration of commonly used port numbers for well-known internet services.
Well Known Ports: 0 through 1023.
Registered Ports: 1024 through 49151.
Dynamic/Private : 49152 through 65535.
TCP ports use the Transmission Control Protocol, the most commonly used protocol on the Internet and any TCP/IP network. TCP enables two hosts to establish a connection and exchange streams of data. TCP guarantees delivery of data and that packets will be delivered in the same order in which they were sent. Guaranteed communication/delivery is the key difference between TCP and UDP.
UDP ports use the Datagram Protocol. Like TCP, UDP is used in combination with IP (the Internet Protocol) and facilitates the transmission of datagrams from one computer to applications on another computer, but unlike TCP, UDP is connectionless and does not guarantee reliable communication; it’s up to the application that received the message to process any errors and verify correct delivery. UDP is often used with time-sensitive applications, such as audio/video streaming and realtime gaming, where dropping some packets is preferable to waiting for delayed data.
When troubleshooting unknown open ports, it is useful to find exactly what services/processes are listening to them. This can be accomplished in both Windows command prompt and Linux variants using the «netstat -aon» command. We also recommend runnig multiple anti-virus/anti-malware scans to rule out the possibility of active malicious software. For more detailed and personalized help please use our forums.
Непонятный флуд из "внешки"
Владимир Штарк, а что если средствами iptables просто дропать все входящие пакеты на порт 6881? Как думаете, поможет?
Если закрыть порт фаерволлом, то, по крайней мере, не будет ICMP ответов.
Тут может быть такая ситуация, что ДДоСят не Вас, а с Вашей помощью. Например, приходит udp-пакет с поддельным адресом в заголовке, а Ваш компьютер честно рассылает на этот поддельный адрес (адрес «жертвы») ICMP-ответ.
Я бы порт закрыл.
- Страница 1 из 2
- 1
- 2
- Авторизуйтесь для ответа в теме
#1 NightmareMan
- Пользователи
- 36 сообщений
Помогите пожалуйста разобраться что происходит. С недавнего времени заметил, то на роутере мигает индикатор WAN порта как бешеный, в то время как к роутеру никто не подключен. Засунул кабель напрямую и запустил Wireshark. И увидел, что с довольно большой скоростью ко мне валит куча всякого г**на на порт 6881 с разных айпишников. А от меня в ответку следовательно Port unreachable. Сразу скажу — на момент захвата траффика все использующие траффик программы были закрыты. Utorrent тоже. Да и настроен он на другой порт.
Порт 6881 что это
У меня ПК подключен к Интернету через сервер с pfSense. pfSense настроен почти 100% дефолтненько. Мне нужно, чтобы работал проброс порта 6881, который используется uTorrent'ом. Чтобы я активно не только скачивал, но и раздавал.
Вот мои настройки:
Раньше всё работало. Я запускал uTorrent, начинал скачивать и раздавать, uTorrent казал зелёную галочку в соединенях (что порт открыт и я доступен извне), я заходил на https://2ip.ru/check-port/ , чекал порт 6881, и сайт писал красным, что порт открыт.
Но что-то произошло. Я так и не понял, что именно спровоцировало это изменение, но теперь порт 6881 постоянно закрыт. Я отключил для проверки firewall SimpleWall на клиентской машине. Windows Brandmower вообще отключен как служба. Создавал и пересоздавал в pfSense правило для проброса порта. Даже сам pfSense переустановил (мало ли. ). Но ничего не помогает. Порт теперь всё время закрыт. (Узнаю о его закрытости по соответствующей зелёной записи на https://2ip.ru/check-port/ и по жёлтому треугольнику с вослицательным знаком в uTorrent.)
Mavrikii
Раньше всё без UPnP работало. Да и не безопасен он. Я всё же хочу руками сделать.
Еще одна «критическая» «уязвимость» «VPN» и почему Port Fail — ерунда
Утро 26 ноября началось для меня с интересной новости — ребята из Perfect Privacy опубликовали информацию об уязвимости Port Fail, которая позволяет раскрывать IP-адрес клиентов VPN-сервисов с функцией проброса портов. Я немного понегодовал из-за того, что ее назвали уязвимостью, т.к. это никакая не уязвимость, а особенность маршрутизации: трафик до IP-адреса VPN-сервера всегда идет напрямую, в обход VPN. Вполне очевидная вещь, подумал я, о которой должен знать любой сетевой администратор. Заметка вменяемая и технически грамотная, придраться можно только к слову vulnerability (уязвимость). Но потом за дело взялись СМИ, и пошло-поехало…
Критическая уязвимость во всех протоколах VPN на всех операционных системах. У-у-у, как страшно!
В новости, опубликованной на Geektimes, изначально имевшей желтый заголовок, было сказано о награде в $5000 за найденную «уязвимость» от Private Internet Access — одного из крупнейших VPN-сервисов. «$5000 за типичную, совершенно очевидную любому сетевику вещь?» — подумал я — «Невероятно!», и высказал свое негодование по этому поводу в комментариях, попутно расписав еще одну, не менее очевидную, особенность маршрутизации, с которой сталкивался любой настраивавший работу двух и более интернет-провайдеров на одном компьютере: ответ на входящий запрос не обязательно уйдет через этого же провайдера и с этим же IP, чего запросившая сторона совсем не ожидает. Если мы представим, что вместо второго провайдера у нас VPN-соединение, то отправив запрос на IP-адрес нашего провайдера, при определенных условиях может получиться так, что ответ на наш запрос мы получим с IP VPN-сервера.
Как такое может происходить?
Когда вы подключаетесь к VPN, маршрут по умолчанию, который до этого был установлен через вашего провайдера, меняется на маршрут через VPN.
Приложения, которые слушают порт и принимают на него входящие соединения, в большинстве своем полагаются на операционную систему при формировании ответа на пришедший входящий пакет. Это отлично работает, когда у вас один сетевой интерфейс, но ситуация меняется с несколькими интерфейсами, в зависимости от ОС и протокола:
- OpenVPN (def1) — UDP уходит через VPN-интерфейс, TCP работает корректно
- IPsec IKEv2 — UDP уходит через VPN-интерфейс, TCP отбрасывается
- OpenVPN (def1) — UDP уходит через VPN-интерфейс, TCP отбрасывается
- IPsec IKEv2 — UDP уходит через VPN-интерфейс, TCP работает корректно
- OpenVPN (def1) — UDP и TCP уходят через VPN-интерфейс при rp_filter=0, отбрасываются при rp_filter=1
Чем это может быть чревато?
Как можно видеть, проблему представляют только входящие пакеты к приложениям, прослушивающим UDP-порт. Вряд ли на типичном компьютере пользователя таких приложений найдется много, но несколько, как правило, все же есть.
BitTorrent
Как вы можете знать, в некоторых странах, например, в США, Германии, Франции, Австрии, Канаде, Великобритании, существуют специальные организации, которые отслеживают участников интересующих их BitTorrent-раздач по просьбам правообладателей. Они соединяются с BitTorrent-трекерами и DHT-сетью и сохраняют все IP-адреса конкретной раздачи, чтобы потом отправить «письма счастья» — сообщения о том, что такой-то IP-адрес с таким-то портом раздавал такой-то файл в такое-то время, что это все незаконно, и что нужно-бы заплатить за это дело штраф. Жители этих стран используют VPN в других, «менее развитых» странах, чтобы не попасться в сканеры этих злодеев, и компании от этого грустят.
- Пользователь, которому провайдер выдает «белый» (маршрутизируемый) IP-адрес, подключается к VPN, запускает BitTorrent-клиент и скачивает некоторые файлы, оставаясь после скачивания на раздаче. BitTorrent-клиент прослушивает порт и открывает его, в случае необходимости, через UPnP.
- Компания, занимающиеся мониторингом, собирает все IP-адреса на этой раздаче, в том числе и IP-адрес и порт VPN-сервера нашего пользователя.
- Компания массово отправляет UDP-пакеты BitTorrent-клиентам на все IP-адреса в интернете, на порты, собранные ранее. Можно уложиться в десятки минут при использовании 10-гигабитного канала.
- BitTorrent-клиент пользователя, получив входящий пакет на сетевой интерфейс провайдера, отправляет ответ через VPN-интерфейс, с IP VPN-сервера.
- Компания обнаруживает настоящий IP клиента, раздающего интересующий их материал.
Skype
Используя эту технику, можно узнать настоящий IP интересующих вас пользователей Skype, если они используют VPN. Существует большое количество публичных Skype-резолверов, которые покажут вам IP и порт пользователя по Skype-логину. Далее, вам нужно прибегнуть к такой же технике, которую использовали бы правообладатели — разослать какие-нибудь данные на UDP-порт по всему интернету, и следить за ответами. Примечательно, что отсылать в Skype можно почти любой мусор! Воспользуемся замечательной программой nping из состава nmap:
Как защититься?
Хоть и я и не считаю эту особенность такой уж большой проблемой, мне все же интересно, как предотвратить утечки такого рода с технической точки зрения.
С Linux все предельно просто — для IPv4 достаточно установить опцию
в 1, если она еще не установлена. Мой интерфейс VPN называется tun0 , а интерфейс с интернетом — wlp3s0 , поэтому я делаю следующее:
А для IPv6 необходимо добавить правило iptables:
- Разрешает любые входящие IPv4 unicast UDP-пакеты с адресов 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16, 169.254.0.0/16 и подсетей активных сетевых адаптеров; любые входящие IPv6 unicast UDP-пакеты с fd00::/8, fe80::/10 и подсетей активных сетевых адаптеров.
- Блокирует все новые unicast UDP-пакеты извне VPN-интерфейса.
В OS X все несколько сложнее: PF не позволяет фильтровать только новые UDP-пакеты, поэтому приходится блокировать все входящие UDP, кроме локальных адресов, провайдерской подсети и самого VPN-сервера. Это плохо тем, что вы, например, не сможете использовать DNS провайдера, если захотите, т.к. ответы вам просто не будут доходить, необходимо будет вносить IP DNS-сервера в белый список.
В любом случае, сделать это можно приблизительно так:
Где 185.61.149.121 — IP-адрес VPN-сервера, а utun1 — интерфейс VPN.
Послесловие
Если вы весь из себя злодей, и хотите попробовать проэксплуатировать эту особенность, вам поможет логирование пакетов в Linux средствами netfilter. Достаточно добавить следующее правило iptables, и все пакеты с Марса будут как на ладони:
Где 4455 — интересующий вас порт.
Сообщения об этой особенности я отправил 11 VPN-провайдерам, ответ получил только от 5: Private Internet Access, Perfect Privacy и Mullvad выпустили обновленный клиент с возможностью блокировки входящих соединений, Astrill написал, что они не считают эту особенность существенной, и что она не имеет отношения к VPN. Технически, они правы, однако в их клиенте есть защита от других клиентских проблем — утечек IPv6, DNS и WebRTC, и почему не добавить еще одну, остается для меня загадкой. Ребята из Cryptostorm подсказали ключ реестра Windows, который должен включать Reverse Path Forwarding, но он не работает, а TorGuard ничего не написали после ответа на некоторые вопросы с их стороны.
Кстати, вышел OpenVPN 2.3.9 с многочисленными исправлениями Windows-ошибок и долгожданной опцией —block-outside-dns , которая исправляет утечки DNS на Windows 8.1 и 10.
Так я и получил свои $5000 от Private Internet Access, $1000 сверху от Perfect Privacy и $1300 от Mullvad за еще одну ерунду, и мне, честно говоря, за это даже несколько неловко. Часть денег уйдет разработчикам OpenVPN и strongSwan.