Comments 71
Здесь можно проверить свой крутой универсальный пароль, не засветился ли он в слитой базе.
Очень хороший способ засветить в ту базу ещё и свой пароль, автор вроде как косит под безопасника, но даёт такие советы, как мило :)
Я побуду адвокатом дьявола, а вы попробуйте доказать свою точку зрения.
Берём систему двухлетней давности. Это Debian Jessie, причём я буду строг — используется 8.7 (релиз 2017-01-14). 0 апдейтов по сравнению с установочным CD.
Ставится nginx, который раздаёт статику, ssh/sftp, который используется для администрирования.
Это хороший пример «поставили и забыли». Попробуйте показать хоть одну CVE, которая даст RCE на такой системе.
В контексте linux/nginx, я хочу посмотреть на slow lori и syn-flood. nginx отлично с slow lori справляется, а syn флуд получает куки и на этом всё. Голая задница линукса не такая нежная, как её рисуют в гламурных журналах.
(Если вы можете amplification в такой конфигурации показать, покажите — это тоже будет засчитано за аргумент).
Не стоит забывать и о том, что если уязвимость не известна на данный момент — это не означает, что её нет. Вот, например, уязвимость в 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.
Когда вам забьют под полку входящий канал будет не важно закрыты у вас порты или нет
Рассмотрим кейс – веб сайт. Арендуем VPS-ку, получаем SSH, разворачиваем web-приложение с SSL на 443 порт. Через какое-то время ваш 443-ий порт индексируется Shodan'ом вместе с баннером, где виден ваш домен. Даже если вы спрячете web-приложение за CDN, хакер найдет в Shodan'e ваш сервер и будет его DDoS'ить.
Я предлагаю, после получения сервера, сразу сделать white-list, тогда Shodan вас не проиндексирует и хакер не сможет найти сервер.
А письма ваш сервер не рассылает? А у вас там точно нет уязвимостей через которые IP таки можно получить?
Очень наивно полагать что достаточно поставить CDN и реальный IP никто и никогда не узнает.
Если захотят — узнают.
Присуждаю вам значок «почётный помощник Капитана Очевидность»
Спасибо, кэп ©
Вы утверждаете что с помощью WL можно защититься от DDoS путем того что оригинальный IP никогда не найдут, а я говорю нет.
Так что значек оставьте себе.
Снова и снова, после проведения аудита, на мои рекомендации спрятать порты за white-list'ом встречаюсь со стеной непонимания.
White-list по IP не самая хорошая идея. Разрабы могут не иметь статики (static IP) и выходить в Инет с разных мест.
Если хотите повышать реальную безопасность лучше прислушаться к рекомендациям Microsoft и весь доступ к внутренним сервисам открывать только через remoate access vpn.
Да, VPN однозначно лучше white-list, т.к. добавляет шифрование. Но если нет возможности поднять VPN, то white-list гораздо лучше, чем ничего.
VPN — ровно такое же сетевое приложение, как и nginx, (В зависимости от протокола «как и openvswitch»), и с точки зрения защиты от DoS'а нет разницы, что сервер DoS'ят, что его VPN.
Да, если VPN на этом же сервере. В этом случае торчащий VPN немногим лучше торчащего SSH. Под 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
Веб-сервер, к примеру, должен обрабатывать практически бесконечное количество вариаций запросов, в том числе динамических, запускать по запросам исполнимый код, передавать ему параметры. Это принципиально другой уровень потенциальной уязвимости.
DoS-ить случайный адрес в интернете вряд ли кому-то нужно. Если речь идёт о VPN-сервере — ну пусть даже DoS-ят, подключаемся через резервный на другом канале, если доступ для нас критичен, либо ждём, пока бессмысленный DoS закончится, если не критичен и резервного сервера и канала нет.
Последний раз, когда я сравнивал толщину RFC для http и ipsec, их толщины были несравнимы. Не то, чтобы я сильно возражал, но опять же, ещё на этапе согласования шифров можно столько кормить, что отдать файл по http самому медленному лорри будет проще.
В целом, VPN будет надёжнее, чем самописное приложение, но размеры спецификаций у многих протоколов такие, что иногда периметр атаки становится больше, а не меньше.
IKEv2 обменяется 2-6 пакетами с клиентом, у которого нет нужного сертификата. Пакеты не такие уж сложные, можно руками разобрать, если в них что-то серверу не нравится — просто отсылает в ответ ошибку. Это очень небольшая attack surface.
1. Защищайте периметр.
2. Выставляя сервис наружу позаботьтесь о защите от несанкционированного доступа.
3. Защищайте периметр и от атак изнутри тоже.
Из опыта, обновления из официального репозитория крайне редко ломают прод.
Я конечно улыбнулся, когда попытался эту фразу проецировать на 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 terminal / точку банка etc каким нибудь маршрутизатором с vpn и авторизацией по radius который вела бы на централизированую базу юзеров типа ldap?
Клиенту тоже будет хорошо только в том случае, если шлюз будет встроен в POS. Вряд ли кто-то захочет мучиться со сторонним сетевым оборудованием в своей сети. Да и за динамическими адресами часто стоит магазинчик с одним продавцом в штате. Сложное техническое решение туда не загонишь.
В итоге рынок захватит тот, кто предложит более простое решение (одну коробку, которая будет просто работать, не втягивая клиента в технические детали этой работы). И белый список здесь будет работать против бизнеса. Максимум, до уровня региона можно ужать, опять же.
В случае если все это сделано на одной железке. Иначе множатся точки отказа.В корне с вами не соглашусь — все напрямую наоборот. Если вы не вкурсе что такое High Availability то это системы с несколькими точками выполняющими одну и ту же функцию для отказоустойчивости и балансировки нагрузки.
В итоге рынок захватит тот, кто предложит более простое решение (одну коробку, которая будет просто работать, не втягивая клиента в технические детали этой работы)Мы живем не в сказке, а в реальном мире. Решения «одна волшебная коробка» и все работает без отказов и без доп. настройки — просто либо лож, либо не гибкое/на дежное решение. Что вы подразумеваете под «клиентом» тоже не ясно. Если вы считаете «клиентом» технического спеца — то мне за вас стыдно. А если конечным «клиентом» считать работника удаленного магазина «касира» — то ему ничего настраивать не нужно. Все «коробки» как и рабочие места подготавливаются в центральном офисе (или где у вас там сидят ИТшники): настраиваются, упаковываются и едут устанавливатся на «точку». На всяк случай перед отправкой — на железках еще в офисе включается «удаленное управление» для кейсов если что то пойдет не так.
VPN сервер для подключения клиентов — 1, может быть с несколькоми IP\шлюзами, а может быть и 2 (например на освнове gw-office.company.com — так можно будет без перенастройки клиентов изменить IP если что)
Радиус сервер — 2 шт внутри приватной сети офиса — например на самих AD DC что бы не плодить сервера с 0 нагрузкой. Если что их слушает только VPN сервер, а не клиенты.
У клиента на его «точку продаж» стоит 1 шлюз аля mikrotik либо что у вас там в распоряжении с IPsec/OpenVPN клиентом. Зачем «шлюз будет встроен в POS»? Это фантастика, причем опасная. Точке нужен доступ в сеть не только для POS (нет?), но и для ПК или что у него там у вас.
Вряд ли кто-то захочет мучиться со сторонним сетевым оборудованием в своей сетиВот этого я вообще не понял. Что вы пытались сказать этим? Я это могу прочитать только так: «Вряд ли кто-то захочет мучиться с сетевым оборудованием.»
И мой вам ответ: значит вы работаете не на той должности на которой должны, оставьте работу системному администратору.
И белый список здесь будет работать против бизнеса.Я что то сказал про белый список? facepalm…
1) Мы разговаривали в ключе белых списков.
2) Если бы я был администратором сети компании, я бы не хотел, чтобы мне в режиме High Availability банк ставил два своих VPN-шлюза в сеть только ради того, чтобы клиенты могли расплачиваться с использованием карты. И никакой мелкий магазин не согласится. Да и банки не будут так делать. Вот о чем я писал.
или
Предположим чисто теоритически вы админ этого банка или наоборот клиент не суть важна. Со стороны клиента есть областной или ценральный офис и куча «точек» (у кого 3g, у кого ethernet, у кого wifi-мост, не суть важна). Клиент подключает все «точки» к себе в областной (или ценральный) по VPN который маршрутизирует только трафик к банку через VPN. Таким образом клиент предоставляет банку только IP-аддресс(а если их несколько) от ценрального офиса, а не все статики/динамики всех своих точек. Вопрос закрыт.
Но по факту — это бред, треш и угар. Банк не может требовать такого — пусть делает нормальные публичные интерфейсы, а если требует — бегите в другой банк.
а без последовательности простукивания все порты будут качественно закрыты.
пинг-кнокинг потребует ответа на пинг из тырнета (что есть возможность дырки), но он нужен лишь для винды, где элементарно реализуем на любой версии винды обычным батником без доп.бинарников.
Имхо — тут мало вариантов ответов…
У нас торчат 80 и 443 с Allow All — что отвечать? «Всегда»?
Плюс у нас торчат 22 с Allow from the Office, т.е. за фаерволом — что отвечать? Какой вариант выбрать? «Иногда»?
Ну и так далее — 3306 на некоторые реплики.
А вообще — VPN, и все ресурсы спрятаны в приватных сетях. Доступы — через Bastion и/или AWS LoadBalancer (мы живём в AWS).
Помимо «временно в security group открыл доступ к 3306 отовсюду, а не только изнутри» и забыл, еще и куча шансов, что девопс приассайнит EIP не к тестовому серверу, а продуктивному…
> временно в security group открыл доступ к 3306 отовсюду, а не только изнутри
Конкретно у нас 3306 открыт к некоторым репликам RDS с определённых IP (Tableau Cloud ходит к ним для сбора данных для своих графиков для команды дата-аналитики).
> куча шансов, что девопс приассайнит EIP не к тестовому серверу, а продуктивному
Тоже не сильно актуально, мне так кажется.
Кто же руками сейчас такое делает? Всё вписано в автоматизацию, в шаблоны того же CloudFormation или Terrafrom, так что руками такую ошибку допустить будет достаточно затруднительно.
Тоже самое, кстати, касается и SecurityGroups — правила добавляются и удаляются в CloudFormation или Terrafrom. Руками это делать, даже на Dev — «плохая примета» :-)
К счастью — Terrafrom такие изменения всё-равно откатит (а вот CloudFormation, увы — нет).
Не открывайте порты в мир — вас поломают (риски)