LINUX.ORG.RU
решено ФорумAdmin

Nmap не находит открытые порты

 , , ,


3

2

Здравствуйте спасители! 😁 Имеется VPS с Ubuntu v20.04, который я сканирую с помощью Nmap 7.94. Вот скриншот с результатами сканирования Nmap: https://disk.yandex.ru/i/7Rv6xP-ecmMxKg

Профили использовал эти: Intense scan plus UDP и Intense scan, all TCP ports. А вот мои правила пре-роутинга из файла rules v4:

*MANGLE
:PREROUTING ACCEPT
:INPUT ACCEPT
:FORWARD ACCEPT
:OUTPUT ACCEPT
:POSTROUTING ACCEPT

*NAT
:PREROUTING ACCEPT
:INPUT ACCEPT
:OUTPUT ACCEPT
:POSTROUTING ACCEPT
-A PREROUTING -i eth0 -p udp -m udp --dport 443 -j DNAT --to-destination 140.82.121.3:443
-A PREROUTING -i eth0 -p tcp -m tcp --dport 80 -j DNAT --to-destination 140.82.121.3:80
-A POSTROUTING -s 192.168.10.0/24 -o eth0 -j MASQUERADE

Zenmap не находит порт с tcp 80. Более того, когда я ввожу IP_своего_сервера:80 перенаправления на 140.82.121.3:80 не происходит 😒 Ограничений по 80 порту со стороны провайдера нет.

Ещё я проверил порт 2347 для shadowsocks с помощью https://www.reg.ru/web-tools/port-checker и он оказался открыт, а Nmap его тоже не нашёл 😒

Мой список открытых портов в системе, правда в нём почему-то выдаётся ещё протокол v6, но у меня адрес выдан только ipv4:

Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name
tcp        0      0 127.0.0.1:631           0.0.0.0:*               LISTEN      349226/cupsd
tcp        0      0 127.0.0.1:8888          0.0.0.0:*               LISTEN      650/xray
tcp        0      0 127.0.0.1:8889          0.0.0.0:*               LISTEN      650/xray
tcp        0      0 127.0.0.1:8443          0.0.0.0:*               LISTEN      650/xray
tcp        0      0 0.0.0.0:443             0.0.0.0:*               LISTEN      655/nginx: master p
tcp        0      0 127.0.0.1:8444          0.0.0.0:*               LISTEN      655/nginx: master p
tcp        0      0 0.0.0.0:2700            0.0.0.0:*               LISTEN      652/sshd: /usr/sbin
tcp        0      0 127.0.0.53:53           0.0.0.0:*               LISTEN      265/systemd-resolve
tcp6       0      0 ::1:3350                :::*                    LISTEN      664/xrdp-sesman
tcp6       0      0 ::1:631                 :::*                    LISTEN      349226/cupsd
tcp6       0      0 :::3389                 :::*                    LISTEN      684/xrdp
tcp6       0      0 :::2347                 :::*                    LISTEN      650/xray
tcp6       0      0 :::2700                 :::*                    LISTEN      652/sshd: /usr/sbin
udp        0      0 0.0.0.0:67              0.0.0.0:*                           633/dhcpd
udp        0      0 0.0.0.0:631             0.0.0.0:*                           349228/cups-browsed
udp        0      0 0.0.0.0:35500           0.0.0.0:*                           297500/vpnserver
udp        0      0 0.0.0.0:5353            0.0.0.0:*                           297/avahi-daemon: r
udp        0      0 0.0.0.0:42734           0.0.0.0:*                           297/avahi-daemon: r
udp        0      0 0.0.0.0:8967            0.0.0.0:*                           297500/vpnserver
udp        0      0 192.168.10.1:4500       0.0.0.0:*                           297500/vpnserver
udp        0      0 127.0.0.1:4500          0.0.0.0:*                           297500/vpnserver
udp        0      0 ip_сервера:4500         0.0.0.0:*                           297500/vpnserver
udp        0      0 0.0.0.0:33207           0.0.0.0:*                           297500/vpnserver
udp        0      0 192.168.10.1:500        0.0.0.0:*                           297500/vpnserver
udp        0      0 127.0.0.1:500           0.0.0.0:*                           297500/vpnserver
udp        0      0 ip_сервера:500          0.0.0.0:*                           297500/vpnserver
udp      768      0 0.0.0.0:58926           0.0.0.0:*                           297499/vpnserver
udp        0      0 0.0.0.0:53              0.0.0.0:*                           297500/vpnserver
udp        0      0 127.0.0.53:53           0.0.0.0:*                           265/systemd-resolve
udp6       0      0 :::5353                 :::*                                297/avahi-daemon: r
udp6       0      0 :::2347                 :::*                                650/xray
udp6       0      0 fe80::5c35:f6ff:fe:4500 :::*                                297500/vpnserver
udp6       0      0 ::1:4500                :::*                                297500/vpnserver
udp6       0      0 fe80::216:3cff:fe1:4500 :::*                                297500/vpnserver
udp6       0      0 :::52120                :::*                                297/avahi-daemon: r
udp6       0      0 fe80::5c35:f6ff:fe0:500 :::*                                297500/vpnserver
udp6       0      0 ::1:500                 :::*                                297500/vpnserver
udp6       0      0 fe80::216:3cff:fe1f:500 :::*                                297500/vpnserver
raw        0      0 0.0.0.0:1               0.0.0.0:*               7           297500/vpnserver
raw        0      0 0.0.0.0:1               0.0.0.0:*               7           633/dhcpd
raw        0      0 0.0.0.0:1               0.0.0.0:*               7           309/pingtunnel
raw        0      0 192.168.10.1:50         0.0.0.0:*               7           297500/vpnserver
raw        0      0 127.0.0.1:50            0.0.0.0:*               7           297500/vpnserver
raw        0      0 ip_сервера:50           0.0.0.0:*               7           297500/vpnserver
raw        0      0 192.168.10.1:52         0.0.0.0:*               7           297500/vpnserver
raw        0      0 127.0.0.1:52            0.0.0.0:*               7           297500/vpnserver
raw        0      0 ip_сервера:52           0.0.0.0:*               7           297500/vpnserver
raw6       0      0 fe80::5c35:f6ff:fe00:50 :::*                    7           297500/vpnserver
raw6       0      0 ::1:50                  :::*                    7           297500/vpnserver
raw6       0      0 fe80::216:3cff:fe1f::50 :::*                    7           297500/vpnserver
raw6       0      0 fe80::5c35:f6ff:fe00:52 :::*                    7           297500/vpnserver
raw6       0      0 ::1:52                  :::*                    7           297500/vpnserver
raw6       0      0 fe80::216:3cff:fe1f::52 :::*                    7           297500/vpnserver

-A PREROUTING -i eth0 -p tcp -m tcp --dport 80 -j DNAT --to-destination 140.82.121.3:80
Более того, когда я ввожу IP_своего_сервера:80 перенаправления на 140.82.121.3:80 не происходит Ограничений по 80 порту со стороны провайдера нет.

А web сервер работает на этом хосте? Если с шлюза curl'ом дернуть возвращает страницу?

Kolins ★★★★
()
Ответ на: комментарий от u5er

С какими ключами запускаешь nmap? Попробуй nmap -sS .

Да, такой параметр присутствует в вышеперечисленных профилях:

nmap -sS -sU -T4 -A -v ip_сервера

nmap -p 1-65535 -T4 -A -v ip_сервера

Kisliy
() автор топика
Ответ на: комментарий от Kolins

А web сервер работает на этом хосте? Если с шлюза curl’ом дернуть возвращает страницу?

Работает nginx, там в списке портов он на 443 и 8444 сидит. Но в любом случае прероутинг не должен доводить до INPUTа.

Kisliy
() автор топика

Более того, когда я ввожу IP_своего_сервера:80 перенаправления на 140.82.121.3:80 не происходит

И как вы определяете, что не происходит именно перенаправления, а не то, что, допустим 140.82.121.3 не отвечает на запросы?

проверил порт 2347 для shadowsocks ... и он оказался открыт

Берёте и проверяете отдельно этот порт с помощью nmap. Если он будет открыт, значит при прошлом запуске nmap либо где-то защта от перебора портов сработала, либо процесс в тот момент не слушал порт. А если будет закрыт, можете запустить tcpdump и смотреть, уходит ли syn-пакет на этот порт, приходит ли на сервер...

mky ★★★★★
()
Ответ на: комментарий от Kisliy

Под «этом хосте» подразумевалось 140.82.121.3:80.

Но в любом случае прероутинг не должен доводить до INPUTа.

Дак и DNAT правило не должно доводить до ответного пакета при скане портов. Сканирующий SYN-пакет будет перенаправлен, и тот комп, которому перенаправлен пакет, формирует ответный.

mky ★★★★★
()
Ответ на: комментарий от Kisliy

Работает nginx, там в списке портов он на 443 и 8444 сидит. Но в любом случае прероутинг не должен доводить до INPUTа.

нет я имел в виду хост на который идет dnat, там все нормально с web сервером?

Kolins ★★★★
()
Ответ на: комментарий от Kolins

нет я имел в виду хост на который идет dnat, там все нормально с web сервером?

Угу.

lynx 140.82.121.3

Looking up 140.82.121.3 first
Looking up 140.82.121.3
Making HTTP connection to 140.82.121.3
Sending HTTP request.
HTTP request sent; waiting for response.
HTTP/1.1 301 Moved Permanently
Data transfer complete
HTTP/1.1 301 Moved Permanently
Using https://140.82.121.3/
Looking up 140.82.121.3
Making HTTPS connection to 140.82.121.3
Retrying connection without TLS.
Looking up 140.82.121.3
Making HTTPS connection to 140.82.121.3

anc ★★★★★
()
Ответ на: комментарий от mky

И как вы определяете, что не происходит именно перенаправления, а не то, что, допустим 140.82.121.3 не отвечает на запросы?

Если по адресу 140.82.121.3:80 я зайду браузером, то страница загрузится. Соответственно, если правило (-A PREROUTING -i eth0 -p tcp -m tcp –dport 80 -j DNAT –to-destination 140.82.121.3:80) рабочее, тогда меня лихо перекинет на 140.82.121.3:80 🐱‍🐉 Но видимо что-то идёт не так :) Может вы уже догадались?

Берёте и проверяете отдельно этот порт с помощью nmap. Если он будет открыт, значит при прошлом запуске nmap либо где-то защта от перебора портов сработала, либо процесс в тот момент не слушал порт.

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

Kisliy
() автор топика
Ответ на: комментарий от Harliff

Можно вывод nmap -Pn -p 80 ?

Host is up.

PORT   STATE    SERVICE
80/tcp filtered http

Nmap done: 1 IP address (1 host up) scanned in 2.20 seconds

Спасибо! Уже хоть что-то прояснилось! Выходит надо по новой теперь сканировать, только -Pn добавлять всегда? Тогда точно верняком все дырки найдёт?

Kisliy
() автор топика
Последнее исправление: Kisliy (всего исправлений: 1)
Ответ на: комментарий от BOOBLIK

…Автор не в курсе domain fronting для xray и городит странную неработающую дичь.

Всё по инструкции из тех статей, так что ненаписывайте на меня 🤷‍♂️

Kisliy
() автор топика
Последнее исправление: Kisliy (всего исправлений: 2)
Ответ на: комментарий от Kisliy

С чего ты взял, что сервера github будут отдавать ответ через твой сервер? Получив запрос, они отправляют его назад через свой default gateway, которым ты не являешься. Поэтому очевидно, что nmap ничего тебе не скажет. Здесь не в нём проблема, а в том, что ты делаешь что-то странное.

shell-script ★★★★★
()
Ответ на: комментарий от Kisliy

Внимательно прочитай man nmap. Раза три. Оно сказало, что сканируемый хост работает. Ничего про доступность http-сервера тут нет и ни о каких дырках тут информации тоже нет.

shell-script ★★★★★
()
Ответ на: комментарий от shell-script

С чего ты взял, что сервера github будут отдавать ответ через твой сервер? Получив запрос, они отправляют его назад через свой default gateway, которым ты не являешься. Поэтому очевидно, что nmap ничего тебе не скажет. Здесь не в нём проблема, а в том, что ты делаешь что-то странное.

Любопытно, тогда это правило (-A PREROUTING -i eth0 -p tcp -m tcp –dport 80 -j DNAT –to-destination 140.82.121.3:80) ни о чём?

Kisliy
() автор топика
Ответ на: комментарий от Kisliy

Я не знаю, что ты пытаешься сделать. Правило работает. Можешь проверить счётчики iptables. Но как я выше и написал, github'у на твои правила как-то глубоко пофиг.

shell-script ★★★★★
()
Ответ на: комментарий от shell-script

Внимательно прочитай man nmap. Раза три. Оно сказало, что сканируемый хост работает. Ничего про доступность http-сервера тут нет и ни о каких дырках тут информации тоже нет.

Ну да, я и не спорю. Состояние filtered, уже видно что-то сработало, это же лучше чем вообще ничего. Имел ввиду конечно не дырки, а открытые порты.

Kisliy
() автор топика
Ответ на: комментарий от shell-script

Я не знаю, что ты пытаешься сделать. Правило работает. Можешь проверить счётчики iptables. Но как я выше и написал, github’у на твои правила как-то глубоко пофиг.

Спасибо, я уже понял из предыдущего сообщения. Но что оно в итоге мне даёт? Вот цитата из той инструкции без пояснений: Сделайте проброс порта не только на 443/TCP-порт (его делает XTLS-Reality), а еще на 443/UDP и 80/TCP до сервера, под который вы маскируетесь. Например, если вы маскируетесь под www.microsoft.com, то отрезолвте его IP-адрес (с помощью nslookup, ping или какого-нибудь онлайн-сервиса), а потом добавьте правила iptables (можно засунуть в /etc/rc.local, если он у вас есть - см. инструкции для вашего Linux-дистрибутива): iptables -t nat -A PREROUTING -i eth0 -p udp –dport 443 -j DNAT –to-destination fake_site_ip:443 iptables -t nat -A PREROUTING -i eth0 -p tcp –dport 80 -j DNAT –to-destination fake_site_ip:80

Kisliy
() автор топика
Ответ на: комментарий от Kisliy

Сервис оно показало, потому что взяло его из /etc/services. А закрыто оно, судя по всему потому, что ты показал не все настройки iptables, включённые у тебя в данный момент. Выше уже говорили, что нужно показывать актуальный выхлоп iptables-save или же iptables -L, а не отсебятину.

shell-script ★★★★★
()
Ответ на: комментарий от shell-script

Сервис оно показало, потому что взяло его из /etc/services

👍

Выше уже говорили, что нужно показывать актуальный выхлоп iptables-save или же iptables -L, а не отсебятину.

Вот, пожалуйста:

target     prot opt source               destination
ACCEPT     all  --  anywhere             anywhere
ACCEPT     all  --  anywhere             anywhere             ctstate RELATED,ESTABLISHED
ACCEPT     all  --  192.168.10.0/24      anywhere             ctstate NEW
ACCEPT     all  --  мой домашний_ip_:)/30     anywhere        ctstate NEW

Chain FORWARD (policy DROP)
target     prot opt source               destination
ACCEPT     all  --  anywhere             anywhere             ctstate RELATED,ESTABLISHED
ACCEPT     all  --  anywhere             anywhere             ctstate NEW

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination
Kisliy
() автор топика
Ответ на: комментарий от Kisliy

Показывайте не «правила из», а выхлоп iptables-save.

Да вроде вопрос то изи…

Вам что именно было непонятно в моем сообщении? Ну и раз «вопрос то изи» то видимо вы сами все знаете и все умеете, непонятно только зачем тему создали?

anc ★★★★★
()
Ответ на: комментарий от shell-script

А ещё, судя по упоминанию /etc/rc.local, этой статье очень много лет.

Вот та статья от 2023, у меня не заблокирована пока: https://habr.com/ru/articles/731608/ Материал не самого низкого уровня там.

Kisliy
() автор топика
Ответ на: комментарий от anc

Вам что именно было непонятно в моем сообщении? Ну и раз «вопрос то изи» то видимо вы сами все знаете и все умеете, непонятно только зачем тему создали?

Извиняюсь за своё ламерство, я не специально 🐱‍💻

Chain INPUT (policy ACCEPT)
target     prot opt source               destination
ACCEPT     all  --  anywhere             anywhere
ACCEPT     all  --  anywhere             anywhere             ctstate RELATED,ESTABLISHED
ACCEPT     all  --  192.168.10.0/24      anywhere             ctstate NEW
ACCEPT     all  --  мой домашний_ip_:)/30anywhere             ctstate NEW

Chain FORWARD (policy DROP)
target     prot opt source               destination
ACCEPT     all  --  anywhere             anywhere             ctstate RELATED,ESTABLISHED
ACCEPT     all  --  anywhere             anywhere             ctstate NEW

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination
Kisliy
() автор топика
Ответ на: комментарий от Kisliy

Мда. На мой взгляд уровень не очень. Но это не важно. Суть в другом.

Там же написано, что нужно фейковый ip использовать для DNAT. А ты пытаешься подсунуть реальные.

Ну а про /etc/rc.local в 2023-ем говорить должно быть стыдно.

UPD: Хотя, фиг его знает, что там автор статьи имел ввиду. Но, повторюсь, с реальными айпишниками оно работать не будет.

shell-script ★★★★★
()
Последнее исправление: shell-script (всего исправлений: 1)
Ответ на: комментарий от Kisliy

В принципе, уже написали, но напишу ещё раз. Правило DNAT рабочее, пакет к 140.82.121.3 перекидывается, но он отвечает напрямую, а не через ваш комп. Одно DNAT правило пишут, если у компа, на который DNAT'ят маршрут по умолчанию через комп, на котором написано DNAT правило. Иначе, обычно, добавляют ещё SNAT-правило.

mky ★★★★★
()
Ответ на: комментарий от mky

В принципе, уже написали, но напишу ещё раз.

Большое спасибо! 👍

Правило DNAT рабочее, пакет к 140.82.121.3 перекидывается, но он отвечает напрямую, а не через ваш комп. Одно DNAT правило пишут, если у компа, на который DNAT’ят маршрут по умолчанию через комп, на котором написано DNAT правило. Иначе, обычно, добавляют ещё SNAT-правило.

Теперь понятно что имелось ввиду, ну и нагородило в тех статьях 🤬
В общем, я тогда удаляю те 2 правила, они вообще ни к селу не к городу 😉

Kisliy
() автор топика