Bjornie
По iptables можно попробовать и с временными правилами, на всякий случай. Лично я не пользовался ими. Чтобы проверить что правило работает - нужно проверить что правило работает. Капитанство, но так и есть. То есть, если Вы закрыли какой-то порт, пробуйте на него постучаться (например, через telnet) и убедиться что он недоступен как надо.
Чтобы не влететь с SSH в начале - не трогайте его порт, пока не овладеете инструментом. На самом деле в iptables ничего сложного нет. Нужно просто открыть мануал и внимательно, усидчиво почитать, понять несложную концепцию блуждания трафика по цепочкам правил, и закрепить практикой, пока не прийдет полное понимание того, что Вы делаете и зачем, и как сделать то что Вам нужно. Возьмите, подымите на каком-то порту какой-то сервис, и развлекайтесь с этим портом. Наличие VPN, кстати, будет плюсом, так как параллельно сможете этот порт и по FORWARD цепочкам помучить.
6. Это не совсем настройка безопасности. Я просто это добавил как обязательный шаг при настройке любого сервера. Со временем любые часы начинают сбоить, и разница в пару секунд за пару месяцев может набежать легко. Пока у Вас один сервер - это, возможно, и не важно. А когда у Вас сервера уже два, и они как-то взаимодействуют активно, и у них расходятся часы, то приходит время всяких веселых багов. Не все приложения написаны идеально с точки зрения работы с временем. Далеко не все разработчики уделяют этому должное внимание. Например, сайт на PHP может генерировать timestamp'ы у себя прямо в скриптах и потом их записывать в БД в одном месте, а в другом месте он этот timestamp генерирует уже непосредственно в SQL-запросе. В результате вылезают забавные моменты, когда пользователь входит на сайт за 2 секунды до того как зарегистрируется. Бизнесу, правда, совершенно не забавно, особенно когда дело касается денег. Потому лучше чтобы часы были синхронизированы везде и тикали корректно.
igordata: то есть Вам из одного приложения нужно просто запускать другие в контейнерах на разных серверах по миру.
Из-коробочного, увы, ничего не подскажу, да ещё и такого, которое бы ещё и имело кастомные хуки при старте/остановке которые забирают/заливают файл из хранилища. Вот этот кастомный обвяз придется продумывать и реализовывать самостоятельно.
То, что у Вас в схеме есть master, который размещает приложения на worker нодах, очень само по себе напоминает контейнерную кластеризацию. Посмотрите на Docker Swarm и Kubernetes, к примеру. Возможно Вам подойдет какой-то распределенный Kubernetes-кластер, и небольшое свое приложение, работающее с его API и запускающее нужный Вам контейнер на нужном хосте в Pod'е с нужным обвязом. Там, к слову, в комплекте сразу идет и etcd хранилище распределенное.
Вообще говоря Kubernetes не советуют размазывать по нескольким датацентрам, но все как всегда зависит от задачи и деталей. В Вашем случае, если master ноды с etcd будут собраны в одном датацентре, а разные woker ноды раскиданы по миру - то должно быть вполне себе ОК, учитывая что Ваше приложение не требует постоянного и быстрого общения с другими нодами за пределами своего датацентра.
Клиент создает "приложение" или именно "сервер"? Если речь идет о некоем подобии IaaS и создании легковесных виртуальных серверов, то контейнеры тут не зайдут. Недостаточная изоляция по ресурсам.
Если же это именно экземпляр готового приложения, с которым клиент просто работает через интерфейс, не имея возможности менять что-то внутри, то подходит.
Сервера в разных частях планеты контролируются полностью Вами, либо это по-сути, чужие сервера, куда Вы просто отдаете отдаете контейнер с инструкцией запуска, и потом к нему доступа особо не имеете?
Распишите, пожалуйста, подробнее предполагаемую схему взаимодействия с клиентами. Какие обязанности у каждой из сторон? (в рамках рассматриваемой задачи, разумеется)
Юрий Чудновский: спасибо, что посвятили меня в тему сертификатов.
Любой шифр можно забрутфорсить обладая неограниченным ресурсом времени. Исключением является лишь одноразовый блокнот. Потому условие, что секрет нельзя подобрать за разумное время, и является решением почти всех криптографических задач. В этом задачи SSL и password hashing похожи, да. Но это не делает эти задачи эквивалентными нисколько.
Приватный ключ сертификата отличается от пароля в разрезе рассматриваемой схемы хотя бы тем, что приватным ключом сертификата обладает сервер, а паролем - клиент. У задач разные наборы секретов, и разные цели.
Юрий Чудновский: извините, но Ваши аналогии в корне не верны.
Не корректно сравнивать SSL и password hashing. Это 2 разные криптографические задачи, хотя бы потому, что в password hashing не предполагается передачи зашифрованной информации обратно на клиент. Также, разное кол-во секретов в схеме, да и цели банально разные.
Задача password hashing состоит не в том, чтобы положить пароль в сейф на замок и спрятать, а в том, чтобы получить уникальный цифровой отпечаток пароля, по которому бы можно было проверить валидность предоставляемого пароля, и который не раскрывает какой-либо информации о самом пароле. Сам по себе отпечаток не является секретом, и Вы можете вывесить его хоть на главную страницу сайта.
Конечно же, Вам ничего не мешает потом этот отпечаток дополнительно зашифровать/захэшировать ещё раз, с использованием приватный ключей/секретных параметров/чего угодно. Но это уже действия вне рамок задачи password hashing, и с точки зрения самой задачи - бессмысленны, так как раскрытие отпечатка пароля не несет угрозы самому паролю.
StynuBlizz: чтобы она гарантированно не входила в существующие радужные таблицы.
В ответе, на который, я сослался, разобран пример с солью "111", и детально расписано почему она плоха, будь она хоть 1000 раз индивидуальной.
Nwton: опять же, придумывать ничего не нужно. password_verify() все делает как нужно. Для случаев, когда речь идет не о хешировании пароля, есть hash_equals().
Nwton: и да, используйте уже готовые криптографические примитивы. Минимально - тот же bcrypt. Если речь о PHP: password_hash() для получения хеша, и password_verify() для проверки. Не вздумайте сравнивать хеши через == .
Nwton:
1) Да. Да и нам самим незачем знать пароли пользователей - это их дело.
2) Да, чтобы исключить вариант использования радужных таблиц.
(Немного занудства: термин "брут" происходит от "brute force", под которым имеют в виду полный перебор, то есть даже не по словарю, потому к радужным таблицам этот термин применять немного неуместно)
3) Да, чтобы увеличить вообще время генерации хеша, а значит и любого перебора, в том числе и по словарю.
Ещё, как писалось в моем ответе - самый лучший вариант, когда сами пользователи используют хорошие пароли. Потому можно предпринять какие-то меры дабы их на это образумить. Но это уже зависит от самого приложения, того как оно позиционируется, и соблюдения разумного баланса, чтобы не указывать пользователям слишком многое.
Анатолий Евладов ну вот если прямо все-все контейнеры пускать через сеть хоста, то, я думаю, проблемы очень быстро вылезут в конфликте контейнеров, если их используется много, ведь все слушается на стандартных портах, как правило.
Сеть хоста нужно использовать только тогда, когда Вам это действительно требуется. В остальных случаях - не заморачиваться.
Анатолий Евладов: чтобы ничего не ломалось, и не нужно руками лазать в nat таблицу. Лучше вообще не лазать, ибо это идет в обход идеологии и логики работы iptables. Под фильтрацию трафика выделена таблица filter, в рамках неё и нужно оставаться, если задача именно фильтровать трафик. А дальше - только ловкость рук в орудовании цепочками правил =)
По iptables можно попробовать и с временными правилами, на всякий случай. Лично я не пользовался ими. Чтобы проверить что правило работает - нужно проверить что правило работает. Капитанство, но так и есть. То есть, если Вы закрыли какой-то порт, пробуйте на него постучаться (например, через telnet) и убедиться что он недоступен как надо.
Чтобы не влететь с SSH в начале - не трогайте его порт, пока не овладеете инструментом. На самом деле в iptables ничего сложного нет. Нужно просто открыть мануал и внимательно, усидчиво почитать, понять несложную концепцию блуждания трафика по цепочкам правил, и закрепить практикой, пока не прийдет полное понимание того, что Вы делаете и зачем, и как сделать то что Вам нужно. Возьмите, подымите на каком-то порту какой-то сервис, и развлекайтесь с этим портом. Наличие VPN, кстати, будет плюсом, так как параллельно сможете этот порт и по FORWARD цепочкам помучить.
6. Это не совсем настройка безопасности. Я просто это добавил как обязательный шаг при настройке любого сервера. Со временем любые часы начинают сбоить, и разница в пару секунд за пару месяцев может набежать легко. Пока у Вас один сервер - это, возможно, и не важно. А когда у Вас сервера уже два, и они как-то взаимодействуют активно, и у них расходятся часы, то приходит время всяких веселых багов. Не все приложения написаны идеально с точки зрения работы с временем. Далеко не все разработчики уделяют этому должное внимание. Например, сайт на PHP может генерировать timestamp'ы у себя прямо в скриптах и потом их записывать в БД в одном месте, а в другом месте он этот timestamp генерирует уже непосредственно в SQL-запросе. В результате вылезают забавные моменты, когда пользователь входит на сайт за 2 секунды до того как зарегистрируется. Бизнесу, правда, совершенно не забавно, особенно когда дело касается денег. Потому лучше чтобы часы были синхронизированы везде и тикали корректно.