Внешнее сканирование Nmap показывает, что порт открыт, ASA сообщает, что порт не открыт, но есть сокет

Ребята, у вас странный вопрос, нужна ваша экспертная помощь. Для одного из наших часто используемых внешних серверов, обнаруженных в ходе аудита, nmap -Pn scan показывает следующее:

    Starting Nmap 5.51 ...
    Host pub.ip is up (0.0032s latency).
    Not shown: 993 filtered ports
    PORT     STATE  SERVICE
    21/tcp   open   ftp
    22/tcp   open   ssh
    80/tcp   open   http
    113/tcp  closed auth
    119/tcp  open   nntp
    8008/tcp open   http
    8010/tcp open   xmpp

Теперь это общедоступный FTP / SFTP-сервер, и netstat / lsof на физическом хосте подтверждает, что прослушиваются только порт 21 (ftp), 22 (ssh) и 25 (внутренний smtp).

Конфигурация ASA FW показывает, что она разрешает NAT только от pub ip к внутреннему IP на ftp / ssh:

 static (dmz3,pub1) pub.ip internalftp.ip netmask 255.255.255.255
 access-list pub1_access_in extended permit tcp any host pub.ip eq ftp
 access-list pub1_access_in extended permit tcp any host pub.ip eq ssh

Это оно. Нет записей для 8010 или порта 8008 во всей конфигурации FW.

Но вот что сбивает с толку:

Когда я пытаюсь открыть сокет (используя telnet) на порту 8008, я получаю сокет, и когда я набираю HEAD / или GET /, я получаю следующее перенаправление на защищенный порт 8010:

HTTP/1.1 302 Found
Location: https://:8010
Connection: close

Connection to host lost.

Я также могу открыть сокет на порту 8010, но ничего не дает, ничего через браузер или wirehark.

Интересно, что на физическом сервере ftp / sftp быстрое

#tcpdump -nni eth0 port 80 or port 8008 or port 8010 

не дает никакого трафика, когда я получаю сокет на моем клиенте. Так что деф. соединение устанавливается где-то еще.

Итак, вот - что такое список на сокете / есть соединение на стороне сервера !?

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

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

ps: Я прочитал только Priv на стороне ASA. Таким образом, вы не сможете запускать какие-либо неисправности там. Придется передать его на ASA / NW admin.

Заранее благодарю вас за ваше время и ценную помощь.

Вывод "netstat -taulpn | grep LISTEN" по запросу:

tcp        0      0 10.x.x.x:427            0.0.0.0:*               LISTEN      3779/slpd
tcp        0      0 127.0.0.1:427           0.0.0.0:*               LISTEN      3779/slpd
tcp        0      0 0.0.0.0:111             0.0.0.0:*               LISTEN      3843/portmap
tcp        0      0 127.0.0.1:2544          0.0.0.0:*               LISTEN      4081/zmd
tcp        0      0 0.0.0.0:21              0.0.0.0:*               LISTEN      4042/xinetd
tcp        0      0 10.x.x.x:22             0.0.0.0:*               LISTEN      4190/sshd
tcp        0      0 127.0.0.1:25            0.0.0.0:*               LISTEN      4282/master
tcp        0      0 ::1:25                  :::*                    LISTEN      4282/master

Обновление: извините, ребята, дальнейшее устранение неполадок для каждого из переходов, приведенное выше верно только тогда, когда мы сканируем внешний IP-адрес из нашего внутреннего н / б. Так что мы действительно не собирались выходить. На моем выходе внутренний интерфейс нашего граничного маршрутизатора направляет его напрямую в ASA. И оказывается, что этот внутренний интерфейс прослушивает эти порты, и мы не знаем почему. В его конфиге ничего нет и мы поставили вопрос перед провайдером. Возможно поведение Cisco 7200 по умолчанию.

Таким образом, настоящий тест с использованием линии DSL показывает, что снаружи открыт только порт 21/22. Сканирование на граничном маршрутизаторе (внешний интерфейс) не показывает открытых портов.

Так что пока у нас все в порядке. Еще нужно выяснить «почему» изнутри. Опубликуем последнее обновление после того, как узнаем.

Спасибо всем. Цените свое время и помощь.