Комментарии 71
Здесь можно проверить свой крутой универсальный пароль, не засветился ли он в слитой базе.
Очень хороший способ засветить в ту базу ещё и свой пароль, автор вроде как косит под безопасника, но даёт такие советы, как мило :)
И да и нет. Чем толще стек, тем больше CVE. Верно и обратно — чем тоньше стек, тем он живучее.
Я побуду адвокатом дьявола, а вы попробуйте доказать свою точку зрения.
Берём систему двухлетней давности. Это Debian Jessie, причём я буду строг — используется 8.7 (релиз 2017-01-14). 0 апдейтов по сравнению с установочным CD.
Ставится nginx, который раздаёт статику, ssh/sftp, который используется для администрирования.
Это хороший пример «поставили и забыли». Попробуйте показать хоть одну CVE, которая даст RCE на такой системе.
Я побуду адвокатом дьявола, а вы попробуйте доказать свою точку зрения.
Берём систему двухлетней давности. Это Debian Jessie, причём я буду строг — используется 8.7 (релиз 2017-01-14). 0 апдейтов по сравнению с установочным CD.
Ставится nginx, который раздаёт статику, ssh/sftp, который используется для администрирования.
Это хороший пример «поставили и забыли». Попробуйте показать хоть одну CVE, которая даст RCE на такой системе.
Зачем обязательно RCE? DoSа вполне хватит (например, SYN flood никто не отменял, да и slow lori тоже могут покатать неплохо). Причем в зависимости от настроек системы, подобное открытие еще может дать неплохой amplify для reflected DDoS.
В статье выдвинут тезис, что за два года система становится дырявой. Я попросил показать это, чтобы можно было опираться на эмпирические, а не на чистые размышления.
В контексте linux/nginx, я хочу посмотреть на slow lori и syn-flood. nginx отлично с slow lori справляется, а syn флуд получает куки и на этом всё. Голая задница линукса не такая нежная, как её рисуют в гламурных журналах.
(Если вы можете amplification в такой конфигурации показать, покажите — это тоже будет засчитано за аргумент).
В контексте linux/nginx, я хочу посмотреть на slow lori и syn-flood. nginx отлично с slow lori справляется, а syn флуд получает куки и на этом всё. Голая задница линукса не такая нежная, как её рисуют в гламурных журналах.
(Если вы можете amplification в такой конфигурации показать, покажите — это тоже будет засчитано за аргумент).
Вот эта уязвимость, к примеру, выглядит не очень хорошо.
Не стоит забывать и о том, что если уязвимость не известна на данный момент — это не означает, что её нет. Вот, например, уязвимость в PMA — существует 4 года, а опубликована недавно.
И кстати, когда там проблемы с OpenSSL были? Не проверял уязвима ли версия в Jessie, но, думаю, пример понятен.
Не стоит забывать и о том, что если уязвимость не известна на данный момент — это не означает, что её нет. Вот, например, уязвимость в PMA — существует 4 года, а опубликована недавно.
И кстати, когда там проблемы с OpenSSL были? Не проверял уязвима ли версия в Jessie, но, думаю, пример понятен.
Первое — понятно, но совершенно не прикрыто после прикрытия сервиса CDN'ами. get http://example.com/[bad-esc-seq-here] будет так же плохо после cdn как без него. Т.е. это пример того, как может быть необычно плохо, но совершенно не иллюстрирует тезис про "два года и система дырява". Уязвимость не закрыта до сих пор и не до конца понятно, должен ли nginx её фиксить.
Второе к linux+nginx+ssh совсем не относится, потому что требует поднятия application server (да и sql).
Я ничуть не пытаюсь возражать против апдейтов, я играю роль адвоката дьявола, и пока что дьявол побеждает.
DDoS по IP
Если злоумышленник знает ваш IP, он может на несколько часов или суток заддосить ваш сервер. Далеко не у всех лоукост-хостингов есть защита от DDoS и ваш сервер просто отключат от сети. Если вы спрятали сервер за CDN, не забудьте сменить IP, иначе хакер его нагуглит и будет DDoS'ить ваш сервер в обход CDN (очень популярная ошибка)
Как это связанно с открытыми/закрытыми портами?
Это относительно архитектуры, когда сервер доступен только для CDN. То есть в white-list'е только ip CDN'a.
Когда вам забьют под полку входящий канал будет не важно закрыты у вас порты или нет
Если домен никогда не указывал на ваш сервер, а только на CDN, то злоумышленнику не откуда узнать реальный IP сервера.
НЛО прилетело и опубликовало эту надпись здесь
Это всё понятно, но как это связанно с открытыми/закрытыми портами?
Если нет открытых портов — IP выглядит «мёртвым», кто будет тратить мощности своего ботнета на DDoS неактивного IP?
Все, понял ваш вопрос.
Рассмотрим кейс – веб сайт. Арендуем VPS-ку, получаем SSH, разворачиваем web-приложение с SSL на 443 порт. Через какое-то время ваш 443-ий порт индексируется Shodan'ом вместе с баннером, где виден ваш домен. Даже если вы спрячете web-приложение за CDN, хакер найдет в Shodan'e ваш сервер и будет его DDoS'ить.
Я предлагаю, после получения сервера, сразу сделать white-list, тогда Shodan вас не проиндексирует и хакер не сможет найти сервер.
Рассмотрим кейс – веб сайт. Арендуем VPS-ку, получаем SSH, разворачиваем web-приложение с SSL на 443 порт. Через какое-то время ваш 443-ий порт индексируется Shodan'ом вместе с баннером, где виден ваш домен. Даже если вы спрячете web-приложение за CDN, хакер найдет в Shodan'e ваш сервер и будет его DDoS'ить.
Я предлагаю, после получения сервера, сразу сделать white-list, тогда Shodan вас не проиндексирует и хакер не сможет найти сервер.
А письма ваш сервер не рассылает? А у вас там точно нет уязвимостей через которые IP таки можно получить?
Очень наивно полагать что достаточно поставить CDN и реальный IP никто и никогда не узнает.
Если захотят — узнают.
Так об этом же и речь, а WL упомянут как необходимая, но не достаточная мера.
Присуждаю вам значок «почётный помощник Капитана Очевидность»
Присуждаю вам значок «почётный помощник Капитана Очевидность»
Что на счёт порт нокинга? Если правильно сделать нетривиальную схему то ваши порты будут открываться на секунды только вам? Какие минусы?
Снова и снова, после проведения аудита, на мои рекомендации спрятать порты за white-list'ом встречаюсь со стеной непонимания.
White-list по IP не самая хорошая идея. Разрабы могут не иметь статики (static IP) и выходить в Инет с разных мест.
Если хотите повышать реальную безопасность лучше прислушаться к рекомендациям Microsoft и весь доступ к внутренним сервисам открывать только через remoate access vpn.
Как по мне, так если что-то не работает в конкретном случае — это не означает что это что-то — не самая хорошая идея. Хорошая! Просто может быть не универсальная. Но отказываться от белых списков не надо — где получается, их стоит использовать. ИМХО.
Да, VPN однозначно лучше white-list, т.к. добавляет шифрование. Но если нет возможности поднять VPN, то white-list гораздо лучше, чем ничего.
При этом считается, что vpn-сервер — это такой специальный волшебный сервер на котором нет ни ядра, ни сетевого стека, ни userspace сетевого приложения.
VPN — ровно такое же сетевое приложение, как и nginx, (В зависимости от протокола «как и openvswitch»), и с точки зрения защиты от DoS'а нет разницы, что сервер DoS'ят, что его VPN.
VPN — ровно такое же сетевое приложение, как и nginx, (В зависимости от протокола «как и openvswitch»), и с точки зрения защиты от DoS'а нет разницы, что сервер DoS'ят, что его VPN.
Да, если VPN на этом же сервере. В этом случае торчащий VPN немногим лучше торчащего SSH. Под VPN я имею ввиду – отдельный сервер к которому коннектится обслуживаемый сервер и обслуживающий персонал.
С точки зрения DoS — если это тот же самый канал связи — положат с тем же успехом. И VPN-порт тоже найдут.
С точки зрения уязвимости — компрометация VPN-сервера даёт практически те же возможности, что и компрометация web-сервера.
Т.е. vpn лучше, потому что добавляет гибкости между авторизацией и работой, но это, мягко говоря, не серебрянная пуля.
С точки зрения уязвимости — компрометация VPN-сервера даёт практически те же возможности, что и компрометация web-сервера.
Т.е. vpn лучше, потому что добавляет гибкости между авторизацией и работой, но это, мягко говоря, не серебрянная пуля.
Поэтому все зависит от самого проекта и квалификации атакующей стороны. Два сложных параметра которые имеют много вариаций.
Например я рядовой админ поднимаю мелкие магазины под заказ. Указанные в статье рекомендации служат отличным пособием. Так как неплохо экранировать наш сервер от мамкиных хакеров. Ну а злостные анонимусы не полезут ковыряется в пустячковый магазин помады.
А быть может я и рядовой админ, но интеллигентный. И использую правила хорошого тона администрирования, что бы отточивать свои навыки, и заодно заряжать, как раз таки серебрянные пули против хакеров с ютуба.
Как то так.
Например я рядовой админ поднимаю мелкие магазины под заказ. Указанные в статье рекомендации служат отличным пособием. Так как неплохо экранировать наш сервер от мамкиных хакеров. Ну а злостные анонимусы не полезут ковыряется в пустячковый магазин помады.
А быть может я и рядовой админ, но интеллигентный. И использую правила хорошого тона администрирования, что бы отточивать свои навыки, и заодно заряжать, как раз таки серебрянные пули против хакеров с ютуба.
Как то так.
Ребята — утрирование на утрировании…
1>возьмем к примеру openvpn:
Static preshared TLS key — и все. Пока сервер не получит от клиента этот первичный ключ никак реагировать на клиента не будет.
2>whitelist по IP:
как делаю я: пытаюсь понять статика у сотслуживца или нет. Если да или ответ не известен — прикручиваю только 1 ip. Если нет или в дальнейшем ip изменился есть 2 варианта:
2.1 беру инфу по whois asn и добавляю все.
2.2 прошу если есть возможность настроить ddns и вайтлищю ip на основе резолвинга ddns
VPN-сервер отвечает стандартным ответом на стандартный запрос. Максимум динамики — согласование шифров. Нет правильного сертификата — никаких дальнейших разговоров.
Веб-сервер, к примеру, должен обрабатывать практически бесконечное количество вариаций запросов, в том числе динамических, запускать по запросам исполнимый код, передавать ему параметры. Это принципиально другой уровень потенциальной уязвимости.
DoS-ить случайный адрес в интернете вряд ли кому-то нужно. Если речь идёт о VPN-сервере — ну пусть даже DoS-ят, подключаемся через резервный на другом канале, если доступ для нас критичен, либо ждём, пока бессмысленный DoS закончится, если не критичен и резервного сервера и канала нет.
Веб-сервер, к примеру, должен обрабатывать практически бесконечное количество вариаций запросов, в том числе динамических, запускать по запросам исполнимый код, передавать ему параметры. Это принципиально другой уровень потенциальной уязвимости.
DoS-ить случайный адрес в интернете вряд ли кому-то нужно. Если речь идёт о VPN-сервере — ну пусть даже DoS-ят, подключаемся через резервный на другом канале, если доступ для нас критичен, либо ждём, пока бессмысленный DoS закончится, если не критичен и резервного сервера и канала нет.
«стандартным ответом на стандартный запрос»
Последний раз, когда я сравнивал толщину RFC для http и ipsec, их толщины были несравнимы. Не то, чтобы я сильно возражал, но опять же, ещё на этапе согласования шифров можно столько кормить, что отдать файл по http самому медленному лорри будет проще.
В целом, VPN будет надёжнее, чем самописное приложение, но размеры спецификаций у многих протоколов такие, что иногда периметр атаки становится больше, а не меньше.
Последний раз, когда я сравнивал толщину RFC для http и ipsec, их толщины были несравнимы. Не то, чтобы я сильно возражал, но опять же, ещё на этапе согласования шифров можно столько кормить, что отдать файл по http самому медленному лорри будет проще.
В целом, VPN будет надёжнее, чем самописное приложение, но размеры спецификаций у многих протоколов такие, что иногда периметр атаки становится больше, а не меньше.
Глянул RFC для TLS и IPSEC/IKEv2, особой разницы в размере не заметил. RFC по HTTP к вопросу уязвимостей, мне кажется, имеют мало отношения, разве что длина URL припоминается как один из компонентов уязвимости (и то, насколько я помню, на URI отдельные RFC). Возможность залить картинку, которую внешняя утилита проинтерпретирует как команду к исполнению, стандарт HTTP даёт, а дальше уже не в RFC на HTTP дело. И, главное, таких нюансов — практически бесконечное количество. Собственно, реально бесконечное, если учитывать исполнимый код на back-end.
IKEv2 обменяется 2-6 пакетами с клиентом, у которого нет нужного сертификата. Пакеты не такие уж сложные, можно руками разобрать, если в них что-то серверу не нравится — просто отсылает в ответ ошибку. Это очень небольшая attack surface.
IKEv2 обменяется 2-6 пакетами с клиентом, у которого нет нужного сертификата. Пакеты не такие уж сложные, можно руками разобрать, если в них что-то серверу не нравится — просто отсылает в ответ ошибку. Это очень небольшая attack surface.
чем неудобнее — тем безопаснее. И наоборот.
В цивилизованных странах этот совет может и полезен. Но если разработка в России, а сервер за рубежом, то я даю прямо противоположный совет: ssh (возможно, на нестандартном порту, и точно с авторизацией только по ключам) ДОЛЖЕН быть открыт всему миру. Иначе, если ваш сервер забанен Роскомнадзором по IP (или, хуже, по подсети), то вы его даже почистить (от размещенной пользователями запрещенки) или забекапить (для переноса на другой хостинг) не сможете — ведь тогда заходить придется через VPN (с заранее неизвестного IP) или через TOR. Для других сервисов и для служебных (нечеловеческих) ключей ssh — да, ограничение по IP нужно.
Странно, но у всех провайдеров на этот случай есть консоль управления сервером, включаемая через личный кабинет. В выделенных или размещенных серверах тоже есть аппаратные средства удаленного доступа. Поэтому проблем с блокировкой РКН не будет. Всегда есть обходные способы восстановления доступа к серверу виртуальному или реальному.
Не у всех.
Берем что-то из дешевых dedicated серверов (не виртуалки), где-то за 30уе в месяц. И радуемся строчке KVMoverIP — No. И если в этом случае бешеный принтер сделает так, что мой сервер попадёт в ban_set, то ничего кроме «хеллоу саппорт, плиз, чендж май сервер ипи энд ребут ит» сделать уже не выйдет, либо надо будет заранее держать два сервера.
Это работает только если вы пароль рута помните.
Можно держать на этот случай самую дешевую VPS в пределах $2-5 только для VPN-сервера, IP которого есть во всех whitelist'ах. Или две. Лучше — у разных провайдеров в разных странах.
При чем здесь порты-то? Какой-такой отдельный порт у phpmyadmin? А если это сервер для iot и прием из сетей мобильных операторов? Какой порт у ICMP? Статью можно было свести к 3 рекомендациям:
1. Защищайте периметр.
2. Выставляя сервис наружу позаботьтесь о защите от несанкционированного доступа.
3. Защищайте периметр и от атак изнутри тоже.
1. Защищайте периметр.
2. Выставляя сервис наружу позаботьтесь о защите от несанкционированного доступа.
3. Защищайте периметр и от атак изнутри тоже.
Статья отличная и правильная, спасибо вам за нее! Но тут
Я конечно улыбнулся, когда попытался эту фразу проецировать на windows-системы )
Из опыта, обновления из официального репозитория крайне редко ломают прод.
Я конечно улыбнулся, когда попытался эту фразу проецировать на windows-системы )
Меня эта фраза тоже улыбнула, но совсем наоборот. За всю свою практику работы обновы windows не сломали ни одного функционала ни на одном из проектов, зато на unix без тестирования на dev env обновлять что либо на major версию чревато всем чем угодно. В windows единственное что было из 2 негативов: 1. Сервера не видел всех обнов, приходилость качать и ставить руками, после этого проблема исщезала. 2. Если начать на новом сервере ставить сруз 150± обнов — скорее всего все помрет на ребуте, ставить лучше "пачками" по 30-40шт
Точно, мне стоило упомянуть, что я о *nix. С Windows беда, конечно. Каждый вторник обновляем >1k тачек, обязательно что-то да отвалится. Виноватыми, разумеется, безопасники остаются со своими обновлениями – "жили же без них нормально" )
ни один порт не должен торчать в мир без white-list'a
SMTP и VPN — тоже?
Думаю, здесь нужно разделять масштабы. Если подключаться нужно одному человеку, то все просто и понятно. Но как только людей становится больше одного, возникает вопрос управления этими белыми списками. И снова приходится искать компромисс. При возрастании количества подключающихся управление белыми списками превращается в довольно серьёзную головную боль.
Один банк недавно внедрил подобную идею для подключения POS-терминалов. Сначала они не предусмотрели вариант с динамическими IP-адресами. Потом стали давать разрешения на провайдерские пулы, которые значатся с масками /22 — /18.
В конечном итоге максимум, до чего получится ужать — масштаб страны. Причем не каждый сервис до него ужмётся.
Один банк недавно внедрил подобную идею для подключения POS-терминалов. Сначала они не предусмотрели вариант с динамическими IP-адресами. Потом стали давать разрешения на провайдерские пулы, которые значатся с масками /22 — /18.
В конечном итоге максимум, до чего получится ужать — масштаб страны. Причем не каждый сервис до него ужмётся.
Спасибо за пример из опыт. Да, конечно, white-list не серебряная пуля, но там где можно – стоит применять.
В случае таких ситуаций не правильней было бы запастить на каждый pos terminal / точку банка etc каким нибудь маршрутизатором с vpn и авторизацией по radius который вела бы на централизированую базу юзеров типа ldap?
С позиции банка это было бы хорошо, наверное. В случае если все это сделано на одной железке. Иначе множатся точки отказа.
Клиенту тоже будет хорошо только в том случае, если шлюз будет встроен в POS. Вряд ли кто-то захочет мучиться со сторонним сетевым оборудованием в своей сети. Да и за динамическими адресами часто стоит магазинчик с одним продавцом в штате. Сложное техническое решение туда не загонишь.
В итоге рынок захватит тот, кто предложит более простое решение (одну коробку, которая будет просто работать, не втягивая клиента в технические детали этой работы). И белый список здесь будет работать против бизнеса. Максимум, до уровня региона можно ужать, опять же.
Клиенту тоже будет хорошо только в том случае, если шлюз будет встроен в POS. Вряд ли кто-то захочет мучиться со сторонним сетевым оборудованием в своей сети. Да и за динамическими адресами часто стоит магазинчик с одним продавцом в штате. Сложное техническое решение туда не загонишь.
В итоге рынок захватит тот, кто предложит более простое решение (одну коробку, которая будет просто работать, не втягивая клиента в технические детали этой работы). И белый список здесь будет работать против бизнеса. Максимум, до уровня региона можно ужать, опять же.
В случае если все это сделано на одной железке. Иначе множатся точки отказа.В корне с вами не соглашусь — все напрямую наоборот. Если вы не вкурсе что такое High Availability то это системы с несколькими точками выполняющими одну и ту же функцию для отказоустойчивости и балансировки нагрузки.
В итоге рынок захватит тот, кто предложит более простое решение (одну коробку, которая будет просто работать, не втягивая клиента в технические детали этой работы)Мы живем не в сказке, а в реальном мире. Решения «одна волшебная коробка» и все работает без отказов и без доп. настройки — просто либо лож, либо не гибкое/на дежное решение. Что вы подразумеваете под «клиентом» тоже не ясно. Если вы считаете «клиентом» технического спеца — то мне за вас стыдно. А если конечным «клиентом» считать работника удаленного магазина «касира» — то ему ничего настраивать не нужно. Все «коробки» как и рабочие места подготавливаются в центральном офисе (или где у вас там сидят ИТшники): настраиваются, упаковываются и едут устанавливатся на «точку». На всяк случай перед отправкой — на железках еще в офисе включается «удаленное управление» для кейсов если что то пойдет не так.
VPN сервер для подключения клиентов — 1, может быть с несколькоми IP\шлюзами, а может быть и 2 (например на освнове gw-office.company.com — так можно будет без перенастройки клиентов изменить IP если что)
Радиус сервер — 2 шт внутри приватной сети офиса — например на самих AD DC что бы не плодить сервера с 0 нагрузкой. Если что их слушает только VPN сервер, а не клиенты.
У клиента на его «точку продаж» стоит 1 шлюз аля mikrotik либо что у вас там в распоряжении с IPsec/OpenVPN клиентом. Зачем «шлюз будет встроен в POS»? Это фантастика, причем опасная. Точке нужен доступ в сеть не только для POS (нет?), но и для ПК или что у него там у вас.
Вряд ли кто-то захочет мучиться со сторонним сетевым оборудованием в своей сетиВот этого я вообще не понял. Что вы пытались сказать этим? Я это могу прочитать только так: «Вряд ли кто-то захочет мучиться с сетевым оборудованием.»
И мой вам ответ: значит вы работаете не на той должности на которой должны, оставьте работу системному администратору.
И белый список здесь будет работать против бизнеса.Я что то сказал про белый список? facepalm…
0) Возможно мы друг друга не поняли. POS-терминал — устройство банка, которое ставится на территории клиента банка (торговой точки/ларька/еtc).
1) Мы разговаривали в ключе белых списков.
2) Если бы я был администратором сети компании, я бы не хотел, чтобы мне в режиме High Availability банк ставил два своих VPN-шлюза в сеть только ради того, чтобы клиенты могли расплачиваться с использованием карты. И никакой мелкий магазин не согласится. Да и банки не будут так делать. Вот о чем я писал.
или
1) Мы разговаривали в ключе белых списков.
2) Если бы я был администратором сети компании, я бы не хотел, чтобы мне в режиме High Availability банк ставил два своих VPN-шлюза в сеть только ради того, чтобы клиенты могли расплачиваться с использованием карты. И никакой мелкий магазин не согласится. Да и банки не будут так делать. Вот о чем я писал.
или 
Я знаю что такое PoS. Но как трезвый человек я и предположить не мог что Банк будет работать по хардкодным whitelist IP. Wtf? Это треш если смотреть на вопрос с такого ракурса.
Предположим чисто теоритически вы админ этого банка или наоборот клиент не суть важна. Со стороны клиента есть областной или ценральный офис и куча «точек» (у кого 3g, у кого ethernet, у кого wifi-мост, не суть важна). Клиент подключает все «точки» к себе в областной (или ценральный) по VPN который маршрутизирует только трафик к банку через VPN. Таким образом клиент предоставляет банку только IP-аддресс(а если их несколько) от ценрального офиса, а не все статики/динамики всех своих точек. Вопрос закрыт.
Но по факту — это бред, треш и угар. Банк не может требовать такого — пусть делает нормальные публичные интерфейсы, а если требует — бегите в другой банк.
Предположим чисто теоритически вы админ этого банка или наоборот клиент не суть важна. Со стороны клиента есть областной или ценральный офис и куча «точек» (у кого 3g, у кого ethernet, у кого wifi-мост, не суть важна). Клиент подключает все «точки» к себе в областной (или ценральный) по VPN который маршрутизирует только трафик к банку через VPN. Таким образом клиент предоставляет банку только IP-аддресс(а если их несколько) от ценрального офиса, а не все статики/динамики всех своих точек. Вопрос закрыт.
Но по факту — это бред, треш и угар. Банк не может требовать такого — пусть делает нормальные публичные интерфейсы, а если требует — бегите в другой банк.
Сканеры действительно достают. Долго не мог понять откуда запросы на тестовом нестандартном порту для отладки своего приложения, пока не глянул лог. Зато учит встраивать защиту от чужих подключений.
Какая КДПВ… вежливая :)
тогда уж все, не нужные для публичного доступа, порты (ssh и т.д.) должны быть за порт-кнокингом или пинг-кнокингом :) и вот тогда хер кто туда влезет без знания последовательности на открытие.
а без последовательности простукивания все порты будут качественно закрыты.
пинг-кнокинг потребует ответа на пинг из тырнета (что есть возможность дырки), но он нужен лишь для винды, где элементарно реализуем на любой версии винды обычным батником без доп.бинарников.
а без последовательности простукивания все порты будут качественно закрыты.
пинг-кнокинг потребует ответа на пинг из тырнета (что есть возможность дырки), но он нужен лишь для винды, где элементарно реализуем на любой версии винды обычным батником без доп.бинарников.
> А у вас торчат порты наружу?
Имхо — тут мало вариантов ответов…
У нас торчат 80 и 443 с Allow All — что отвечать? «Всегда»?
Плюс у нас торчат 22 с Allow from the Office, т.е. за фаерволом — что отвечать? Какой вариант выбрать? «Иногда»?
Ну и так далее — 3306 на некоторые реплики.
А вообще — VPN, и все ресурсы спрятаны в приватных сетях. Доступы — через Bastion и/или AWS LoadBalancer (мы живём в AWS).
Имхо — тут мало вариантов ответов…
У нас торчат 80 и 443 с Allow All — что отвечать? «Всегда»?
Плюс у нас торчат 22 с Allow from the Office, т.е. за фаерволом — что отвечать? Какой вариант выбрать? «Иногда»?
Ну и так далее — 3306 на некоторые реплики.
А вообще — VPN, и все ресурсы спрятаны в приватных сетях. Доступы — через Bastion и/или AWS LoadBalancer (мы живём в AWS).
И, как правило, с AWS и прочими пуличными облаками самый ужас.
Помимо «временно в security group открыл доступ к 3306 отовсюду, а не только изнутри» и забыл, еще и куча шансов, что девопс приассайнит EIP не к тестовому серверу, а продуктивному…
Помимо «временно в security group открыл доступ к 3306 отовсюду, а не только изнутри» и забыл, еще и куча шансов, что девопс приассайнит EIP не к тестовому серверу, а продуктивному…
Ну, «с AWS и прочими публичными облаками самый ужас» — спорное утвержение, как по мне.
> временно в security group открыл доступ к 3306 отовсюду, а не только изнутри
Конкретно у нас 3306 открыт к некоторым репликам RDS с определённых IP (Tableau Cloud ходит к ним для сбора данных для своих графиков для команды дата-аналитики).
> куча шансов, что девопс приассайнит EIP не к тестовому серверу, а продуктивному
Тоже не сильно актуально, мне так кажется.
Кто же руками сейчас такое делает? Всё вписано в автоматизацию, в шаблоны того же CloudFormation или Terrafrom, так что руками такую ошибку допустить будет достаточно затруднительно.
Тоже самое, кстати, касается и SecurityGroups — правила добавляются и удаляются в CloudFormation или Terrafrom. Руками это делать, даже на Dev — «плохая примета» :-)
К счастью — Terrafrom такие изменения всё-равно откатит (а вот CloudFormation, увы — нет).
> временно в security group открыл доступ к 3306 отовсюду, а не только изнутри
Конкретно у нас 3306 открыт к некоторым репликам RDS с определённых IP (Tableau Cloud ходит к ним для сбора данных для своих графиков для команды дата-аналитики).
> куча шансов, что девопс приассайнит EIP не к тестовому серверу, а продуктивному
Тоже не сильно актуально, мне так кажется.
Кто же руками сейчас такое делает? Всё вписано в автоматизацию, в шаблоны того же CloudFormation или Terrafrom, так что руками такую ошибку допустить будет достаточно затруднительно.
Тоже самое, кстати, касается и SecurityGroups — правила добавляются и удаляются в CloudFormation или Terrafrom. Руками это делать, даже на Dev — «плохая примета» :-)
К счастью — Terrafrom такие изменения всё-равно откатит (а вот CloudFormation, увы — нет).
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Не открывайте порты в мир — вас поломают (риски)