Небольшой практический совет. Время от времени рекомендую сканировать свои внешние ip адреса какими-нибудь сканерами портов, например, nmap. Можно это делать на регулярной основе с помощью скриптов и отправлять отчет себе на почту. Если не делать таких проверок, то рано или поздно что-то забудете заблокировать.
На углубленном курсе "Архитектура современных компьютерных сетей" вы с нуля научитесь работать с Wireshark и «под микроскопом» изучите работу сетевых протоколов. На протяжении курса надо будет выполнить более пятидесяти лабораторных работ в Wireshark.
Пример, как это бывает обычно у меня. Поднимается временно какой-то сервис для теста в отдельной виртуальной машине. Для простоты к нему просто пробрасывается определенный порт. После теста виртуальная машина удаляется, а проброс порта остается. Через некоторое время на этот же 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 адресе.
Ниже в отчете будет информация о работающих сервисах. Имеет смысл просматривать и их.
Если у вас небольшая инфраструктура, достаточно раз в неделю просматривать отчеты, чтобы убедиться, что все в порядке. Иначе надо как-то автоматизировать эти проверки. В принципе, ничего сложного нет. Можно с помощью того же Zabbix следить за разрешенным списком открытых портов. Но я не прорабатывал этот вопрос, так как нет надобности. Думаю, что по этой теме уже есть готовые наработки.
Научиться настраивать MikroTik с нуля или систематизировать уже имеющиеся знания можно на углубленном онлайн-курcе по администрированию MikroTik. Автор курcа – сертифицированный тренер MikroTik Дмитрий Скоромнов. Более 40 лабораторных работ по которым дается обратная связь. В три раза больше информации, чем в MTCNA.
Добрый день,
Есть предложение и вопрос по статье.
Предложение:
если использовать команду в таком виде как в статье
"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
Предложение понятно, но мы же сканируем сами себя и заранее знаем, отвечает хост на пинг или нет :)
Я не уверен, что это решение подходит для списка из 30 хостов. Сидеть потом глазами читать отчеты по такому списку очень утомительно. Мой совет актуален, когда у вас пару-тройку адресов и проверить их вручную не занимает много времени.
Я бы в этом случае придумал что-то другое. А вот что уже зависит от специфики этих ip адресов. Что там может случайно появиться, какие порты должны быть открыты и т.д.
Если в организации есть политика того что должно быть снаружи и что нет то не вижу необходимости в таких сканах. Если есть шлюз и на нем стоит файрвол к которому нету upnp (вообще недопустимо) и доступа у людей которые делают на "и так сойдет" то такой ситуации не возникнет. Плюс сканирование портов не найдет выброшенного через прокси с sni неверно настроенного elk и тд. Тут скань, не скань, нужно просто ответственно подходить к настройке сервисов, в том числе тестовых.
В догонку если речь идет о скане ipv4 - то еще нужно найти src ip левый который не разрешен в whitelist, с учётом дифицита публичных ipv4 это проблема. С ipv6 вообще фокус не выйдет:
1) сканить можно долго и бесполезно в никуда
2) нужно отдельную подсеть которая не входит в корпоративный ipsec к примеру ибо там все ip публичные и с ipsec по правилам порты доступны, а с наружи - нет
Если бы все, везде и всегда настраивалось ответственно, внимательно и без ошибок, то можно было бы не делать очень многие вещи. Но по факту это не так и никогда так не будет. Поэтому всегда приходится придумывать что-то, чтобы снизить вероятность человеческих ошибок. Например, мониторинг ssl сертификатов и делегирования доменов. Казалось бы, зачем это надо. Достаточно всего лишь делать напоминания и вовремя все продлевать. Но по факту, это очень часто забывают сделать.
Так же и тут, по ошибке часто наружу выставляют то, что не должно торчать в интернет. Сколько уже было историй, когда базы mongodb или elasticsearch торчали наружу с доступом для всех. И эти данные сливали. А всего то надо было следить за тем, чтобы они не торчали наружу. Но вот не уследили почему-то.
Так я и говорю что http сервис вы все равно простым сканом словите, но не поймете что там есть, а чего нет
По SSL вы правы! Начинаю напоминать начальству за 2 месяца продлить сертификат. Еще не было что вовремя оплатили :( Cертификат let's encrypt для нас не вариант :(
Я сейчас зашел на сайт магазина ulmart точка ru, а там сертификат уже 2 дня как протух. И это крупнейший онлайн гипермаркет!!! Я лет 10 уже в нем тарюсь периодически. Вот это раздолбайство.
Дык, «Юлмарт» банкрот :(
https://vc.ru/finance/109352-kommersant-yulmart-prekratit-rabotat-k-martu-2020-goda
Те кто говорит что let's encrypted не вариант будут страдать всю жизнь.
А кто так говорит? Я везде настраиваю let's encrypt просто потому, что это удобно. Не надо каждый год париться с перевыпуском и обновлением на серверах. Все обновляется автоматически, главное мониторинг настроить и следить за этим.
Боже, вы прям элементарное рассказываете 😂
P.s
Вы иногда все так подробно расписываете. А иногда и шлете на три буквы. Увидел как вы челу на вопрос про установку кубика ответили.
Зачастую очень простые технические решения спасают от больших неприятностей. Причем эти решения большинство игнорирует.