Комментарии 30
Изменить порт по умолчанию или настроить файрвол правильно?
За смену порта по умолчанию скажут "спасибо" те, у кого свой файрвол настроен правильно, т.е. разрешает обращение к веб-серверам только по стандартным портам.
И часто вы видите жесткую блокировку всех портов назначения, кроме белого списка? Как по мне, для таких в аду отдельный котел должен стоять.
Ежедневно.
Мотивируете?
Да запросто. В интернете полным-полно веб-серверов, которые настроены "неправильно", т.е. на другом порту. Если вы запрещаете все нестандартные порты - вы просто теряете совместимость с www.
"Неправильно" Вы неправильно в кавычки взяли, т.к. см. рис.1 фиг.2 и все, что не соответствует - неправильно без всяких кавычек и это оно теряет совместимость с WWW, а не наоборот. На практике я всего несколько раз сталкивался с HTTP не на 80 порту, и то ЕМНИП это всегда были альтернативные HTTP-порты, а не взятые от балды. HTTPS не на 443 вообще не встречал.
Вы как-то неправильно смотрите на этот список. Суть общеизвестных и зарегистрированных портов - не в том, что программы обязаны их использовать, а в том что программы обязаны их не использовать если порт регистрировался не для них.
То есть любая программа, которая выступает в роли HTTP-сервера технически, но при этом не является HTTP-сервером общего назначения, не может использовать ни порт 80, ни альтернативные порты HTTP (по крайней мере, в настройках по умолчанию). Но это не означает что доступ к ней следует запрещать.
Формально Вы правы, фактически же сегодня: если веб-сервер, то 80/443. Я еще застал времена, когда было 8080 и то редко, а сегодня уже и не вспомню, где видел такое.
Я и не утверждал, что следует запрещать всем, кроме браузера - это решается по месту, речь шла о том, что администратору сервера следует помнить и о другой стороне, у которой может стоять запрет (в т.ч. на местном сервере, т.е. не под контролем пользователя) на исходящие соединения по нестандартным портам. В частности, запрет на HTTP по портам, отличным от 80/443.
администратору сервера следует помнить и о другой стороне
Вот здесь согласен целиком и полностью. Жизнь была бы намного проще, если бы администраторы/infosec всегда думали о другой стороне. И я бы сказал, что большая ответственность здесь как раз на тех, кто что-либо зарезает-блокирует на любой из сторон.
Сама смена порта мало дает прибавки к надежности. У меня RDP был выведен на внешние порты 3389x, но очень быстро они оказались скомпрометированы. Пришлось вообще прикрыть их, где возможно.
Но вот если стандартный порт сменить на нестандартный, а на стандартный навесить ханипот с мгновенной блокировкой IP источника на недельку, на другую ... Это уже полезнее, т.к. в первую очередь будет попытка сканирования именно стандартных портов.
Открытый доступ к машине с белым IP чему-то кроме ВПН с самоподписными сертификатами - случай классического ССЗБ
Например, сейчас ваш адрес — 198.51.100.54. Вы узнали, что адрес принадлежит сети 198.51.100.0/24, и вам нужно ограничить доступ по SSH. Тогда внесём всю подсеть следующим образом:
iptables -t filter -A INPUT -p tcp -s 198.51.100.0/24 --dport 22 -j ACCEPT
Тот странный случай, когда в 2023 году читаешь инструкцию по iptables. А её не ставят в современные дистрибутивы…
Подробнее, как перейти с iptables на nftables (статья в блоге этой же компании).
Проверил свежий Ubuntu Server — iptables стоит
Это слой совместимости nftables со старым синтаксисом. Но вообще, на ubuntu всё же стоит использовать ufw тогда (или отключать его, переходя полностью на nft).
$ update-alternatives --config iptables
Есть 2 варианта для альтернативы iptables (предоставляет /usr/sbin/iptables).
Выбор Путь Приор Состояние
------------------------------------------------------------
* 0 /usr/sbin/iptables-nft 20 автоматический режим
1 /usr/sbin/iptables-legacy 10 ручной режим
2 /usr/sbin/iptables-nft 20 ручной режим
Или как вариант — firewalld. Правила из iptables в него тоже можно вставить, с незначительными изменениями в синтаксисе.
китайским ботам всё равно, поменяли вы порт или нет. Тут более менее срабатывает порткнокинг на фаерволе, защита по сертификату (но если пользюков много отснашают вопросами по установке и.т.д.), ограничение по подсетям для подключения (если есть такая возможность), использование Fail2ban или аналогов. И двухфакторная авторизация по типу Google Authenticator - настраивать геморно, но штука очень не плохая.
А как китайские боты узнают о наличии хоста, если порты не стандартные? Если условный http сервер легко обнаружится автоматическим сканом, то со шлюзом будет посложнее - нужно ведь сканировать все порты во всем Интернете. А в остальном согласен - с port knocking ваши логи будут чистыми а системы в безопасности.
китайским ботам всё равно
Если вы не ждёте посетителй из Китая, то
GeoIP -> China -> Block на пару порядков снижает головную боль.
Нестандартные порты, порт нокинг - это все security through obscurity, и, следовательно, не нужно и вредно. Оно, может быть, и снизит количество ботов на графиках, но боты и так безвредны (тут как с акулами, нет нужды плыть быстрее всех); в то же время, от направленной атаки это вас никак не защитит
fail2ban еще туда-сюда, но тут надо понимать, что он может и в ногу пальнуть.
Port knocking не просто "снизит количество ботов на графиках", а практически полностью убирает возможность атак эксплойтов и перебора, также достаточно неплохо защитит от DoS/DDoS. Боты тоже не обязательно перебором будут заниматься. Вот вы уверены, что после сканера к вам не прилетит перебор уязвимостей?
Ну смотрите, нокинг, очевидно, нельзя использовать на портах публичных сервисов, типа хттп, смтп и так далее. Соответственно, от уязвимостей в этих сервисах он не защищает. Что у нас тогда остается? Всякие служебные порты, вроде ssh. Ну, удачи попытаться найти там уязвимость.
Так что да, вполне уверен, и за почти 20 лет меня ломали только через очевидно глупые настройки веб-серверов, VoIP серверов (особенно больно) и прочих публичных штук.
Да, но вы забываете, что бывают серверы, на которых публичных сервисов как таких нету. Те самые шлюзы. И вот там опция "остаться невидимым" ой как хороша.
Ну, "ой как хороша" это так себе аргумент, я бы рекомендовал вместо админских баек и присказок руководствоваться чем-то более рациональным:
Модель злоумышленника. От кого мы хотим защититься? (От неведомого хакера, который будет искать уязвимости в sshd?)
Цена, как настройки всех этих выкрутасов, так и удобство использования
Надежность. Что будет если какой-нить knockd внезапно умрет/закрешлупится, системд не сможет его перезапустить (например, место кончилось), как тогда доступаться?
Вот после ответа хотя бы на эти вопросы уже можно подумать, а надо ли оно вам.
Так я ведь не из админских баек это всё услышал, а дошёл по собственному опыту. Приходилось администрировать сетевое оборудование MT. Там есть достаточно неплохая графическая утилита winbox. Но вот протокол немного дырявый и иногда обнаруживаются серьёзные уязвимости. Открыл в мир и прохлопал момент - сеть скомпрометирована. Открывать каждый раз - страдает удобство и логи ssh всегда забиты. И тут киллерфича в виде простукивания спасает.
Вообще никто и не говорил, что оно применимо везде и всегда. Неудобства тоже имеются. В крупном ентерпрайзе вряд ли кто-то будет использовать. Но открытый в мир sshd и ко - моветон.
Вообще есть компромиссное решение в виде VPN. Ентерпрайз тоже использует для доступа к управлению.
От уязвимости в таких сервисах ничего не защищает. Только своевременные обновления модулей вебсервера, скриптов и.т.д. Вот только не всё можно обновить. Это вообще большая головная боль.
Выставлять наружу rdp? Вы серъезно? Давно шифровальщика не получали в "подарок"?
И проблема не в том, что пароль могут подобрать - проблема в очередной уязвимости самой реализации rdp-протокола. Недавно же была проблема (
Развернуть впн -- дел на 15 мин. Даже на Win.
Зы. Ойтишники ((
Зы2. Блог "Информационная безопасность" ))
Изменить порт по умолчанию или настроить файрвол правильно?