Home » Полезные советы » Проверка открытых портов с помощью Nmap

Проверка открытых портов с помощью Nmap

Небольшой практический совет. Время от времени рекомендую сканировать свои внешние ip адреса какими-нибудь сканерами портов, например, nmap. Можно это делать на регулярной основе с помощью скриптов и отправлять отчет себе на почту. Если не делать таких проверок, то рано или поздно что-то забудете заблокировать.

Если у вас есть желание научиться работать с роутерами микротик и стать специалистом в этой области, рекомендую по программе, основанной на информации из официального курса MikroTik Certified Network Associate. Курс стоящий, все подробности читайте по ссылке. Есть бесплатные курсы.

Пример, как это бывает обычно у меня. Поднимается временно какой-то сервис для теста в отдельной виртуальной машине. Для простоты к нему просто пробрасывается определенный порт. После теста виртуальная машина удаляется, а проброс порта остается. Через некоторое время на этот же ip адрес может приехать что-то другое. Например, у меня приехал новый сервер и на этот ip был посажен idrac. Каково же было мое удивление, когда я, сканируя внешний ip, увидел доступ к консоли управления сервером. Сначала перепугался, думал кто-то что-то сломал. Полез разбираться, оказалось, что старый проброс 443 порта остался на этом внешнем ip.

Вот еще один пример. Стоял тестовый гипервизор HyperV, подключенный в том числе к WAN порту. Подключили на всякий случай, вдруг пригодится. В момент установки и настройки внешний ip ему никто не настраивал, так как он был не нужен. Может интерфейс отключили или что-то еще сделали. Не суть важно. В какой-то момент конфигурировали виртуальные свитчи, в том числе на этом интерфейсе. Он стал активен и автоматом получил настройки внешнего ip по dhcp. Заметил случайно. Сколько HyperV провисел всеми своими портами, в том числе и rdp в интернете - не известно.

Самый простой пример, как можно автоматизировать сканирование внешних ip адресов. Поставьте nmap на какой-то внешний по отношению к тестируемым серверам сервер. И с него по крону раз в неделю запускайте проверку с отправкой результата вам на почту:

nmap -T4 -A -v 111.222.333.444 | mail -s "Nmap Scan 111.222.333.444" zeroxzed@gmail.com

Если почта через консоль не отправляется, почитайте у меня, как это исправить - отправка почты через консоль linux.

Получите подробный отчет по всем типовым портам, которые открыты на вашем ip адресе.

Nmap cканирование внешнего ip

Ниже в отчете будет информация о работающих сервисах. Имеет смысл просматривать и их.

Отчет nmap

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

Онлайн курс по Linux

Если у вас есть желание научиться строить и поддерживать высокодоступные и надежные системы, рекомендую познакомиться с онлайн-курсом "Administrator Linux. Professional" в OTUS. Курс не для новичков, для поступления нужны базовые знания по сетям и установке Linux на виртуалку. Обучение длится 5 месяцев, после чего успешные выпускники курса смогут пройти собеседования у партнеров. Что даст вам этот курс:
  • Знание архитектуры Linux.
  • Освоение современных методов и инструментов анализа и обработки данных.
  • Умение подбирать конфигурацию под необходимые задачи, управлять процессами и обеспечивать безопасность системы.
  • Владение основными рабочими инструментами системного администратора.
  • Понимание особенностей развертывания, настройки и обслуживания сетей, построенных на базе Linux.
  • Способность быстро решать возникающие проблемы и обеспечивать стабильную и бесперебойную работу системы.
Проверьте себя на вступительном тесте и смотрите подробнее программу по .

Автор Zerox

Zerox
Владимир, системный администратор, автор сайта. Люблю настраивать сервера, изучать что-то новое, делиться знаниями, писать интересные и полезные статьи. Открыт к диалогу и сотрудничеству.

14 комментариев

  1. Аватар
    Александр

    Добрый день,

    Есть предложение и вопрос по статье.

    Предложение:

    если использовать команду в таком виде как в статье
    "nmap -T4 -A -v 111.222.333.444 | mail -s "Nmap Scan 111.222.333.444" zeroxzed@gmail.com"
    то она просканирует порты Хоста с IP 111.222.333.444 только в том случае если он отвечает на пинг. Т.е. если открыть все что только можно, но пинг запрещен, при тех опциях которые указанны выше Nmap просто напишет что "Host seems to be down", и даже не приступит к сканированию портов.

    Чтобы Nmap отработал когда пинг запрещен нужно добавить ключ "-Pn" --> Nmap как бы будет считать что каждый Хост доступен, и даже если не отвечает на Пинг --> будет сканировать порты.

    Вопрос:

    К примеру у вас есть клиент с блоком публичных IP адресов с /27 маской (30 доступных хостам IP адресов). Диапазон к примеру 8.8.8.1-8.8.8.30

    И у вас есть желание просканировать единоразово, или раз месяц максимально хорошо все TCP + UDP порты, длительность сканирования - не играет роли.

    Какие бы вы это сделали? Какие ключи использовали?

    У меня в данный момент идеи следующие: разделить сканирование на TCP и UDP отдельными запусками.

    UDP:
    nmap -T4 -Pn -A -v -sU -p1-65535 8.8.8.1-30 | mail -s "Nmap Scan range 8.8.8.1-30" olololo@gmail.com

    TCP:
    nmap -T4 -Pn -A -v -sS -p1-65535 8.8.8.1-30 | mail -s "Nmap Scan range 8.8.8.1-30" olololo@gmail.com
    или
    nmap -T4 -Pn -A -v -sT -p1-65535 8.8.8.1-30 | mail -s "Nmap Scan range 8.8.8.1-30" olololo@gmail.com

    • Zerox

      Предложение понятно, но мы же сканируем сами себя и заранее знаем, отвечает хост на пинг или нет :)

      Я не уверен, что это решение подходит для списка из 30 хостов. Сидеть потом глазами читать отчеты по такому списку очень утомительно. Мой совет актуален, когда у вас пару-тройку адресов и проверить их вручную не занимает много времени.

      Я бы в этом случае придумал что-то другое. А вот что уже зависит от специфики этих ip адресов. Что там может случайно появиться, какие порты должны быть открыты и т.д.

  2. Аватар

    Если в организации есть политика того что должно быть снаружи и что нет то не вижу необходимости в таких сканах. Если есть шлюз и на нем стоит файрвол к которому нету upnp (вообще недопустимо) и доступа у людей которые делают на "и так сойдет" то такой ситуации не возникнет. Плюс сканирование портов не найдет выброшенного через прокси с sni неверно настроенного elk и тд. Тут скань, не скань, нужно просто ответственно подходить к настройке сервисов, в том числе тестовых.

    • Аватар

      В догонку если речь идет о скане ipv4 - то еще нужно найти src ip левый который не разрешен в whitelist, с учётом дифицита публичных ipv4 это проблема. С ipv6 вообще фокус не выйдет:
      1) сканить можно долго и бесполезно в никуда
      2) нужно отдельную подсеть которая не входит в корпоративный ipsec к примеру ибо там все ip публичные и с ipsec по правилам порты доступны, а с наружи - нет

    • Zerox

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

      Так же и тут, по ошибке часто наружу выставляют то, что не должно торчать в интернет. Сколько уже было историй, когда базы mongodb или elasticsearch торчали наружу с доступом для всех. И эти данные сливали. А всего то надо было следить за тем, чтобы они не торчали наружу. Но вот не уследили почему-то.

      • Аватар

        Так я и говорю что http сервис вы все равно простым сканом словите, но не поймете что там есть, а чего нет

      • Аватар

        По SSL вы правы! Начинаю напоминать начальству за 2 месяца продлить сертификат. Еще не было что вовремя оплатили :( Cертификат let's encrypt для нас не вариант :(

  3. Аватар

    Боже, вы прям элементарное рассказываете 😂
    P.s
    Вы иногда все так подробно расписываете. А иногда и шлете на три буквы. Увидел как вы челу на вопрос про установку кубика ответили.

    • Zerox

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

Добавить комментарий

Ваш адрес email не будет опубликован.

Нажимая кнопку "Отправить комментарий" Я даю согласие на обработку персональных данных.