Ваше изначальное утверждение, что решение основанное на Redis недостаточно гибко/масштабируемо/надежно итд.
Я показал пример, что Redis в качестве бэкенда для MQ достаточно серьезное решение, используемое Github, где совсем не: «очень простые очереди с небольшим количеством неважных задач». К примеру Redis-Resque и RabbitMQ вполне конкурирующие системы.
Данные в очередях (которые durable) ПЕРЕЖИВАЮТ РЕСТАРТ RMQ, вот в редисе так точно нельзя
Конечно можно, Redis умеет складывать данные в файловую систему и подхватывать в случае рестарта/поломки. Кроме того, есть репликация.
Система не сможет расти без мэйнстрим траффика.
Это платежные системы, работающие с биткоин, это какие-то магазины подключающие биткоин, это открывающиеся Bitcoin автоматы по всему миру. Это куча стартапов, выросших вокруг BitCoin и получившие инвестиции.
В результате это те же новости на крупных новостных порталах, дающие глоток кислорода в виде нового притока пользователей.
Чем меньше ей будут пользоваться массово и чем меньше система будет подходить под мэйнстрим, тем труднее со временем будет завести/вывести биткоины, поскольку все больше сервисов закроется (а это неудобно для черного рынка).
Соответственно это путь в никуда.
Во время атаки один из майнинг пулов BitFury (16% от всей системы) так и сделали.
Как я понял, они понизили размер блока до 135KB, тем самым повысив минимальную планку комиссии:
Текущий технический потолок системы в 7 транзакций/секунду (7, Карл!) — это курам на смех.
Если не решат эту проблему, — система так и останется бухтой для чернухи и крипто-романтиков, а значит постепенно умрет.
Если же система выкрутится и найдут какое-то элегантное Scalability решение, позволяющее системе стать массовой для использования (очень много надо менять в протоколе) — будет интересно!
Текущий технический потолок системы в 7 транзакций/секунду (7, Карл!) — это курам на смех.
Если не решат эту проблему, — система так и останется бухтой для чернухи и крипто-романтиков, а значит постепенно умрет.
Если же система выкрутится и найдут какое-то элегантное Scalability решение, позволяющее системе стать массовой для использования — будет интересно!
Visa рассчитана на что-то около 60к транзакций/секунду, при обычной нагрузке в 2к транзакций/секунду.
Можно говорить о том, насколько сеть подготовлена к нагрузке.
Bitcoin потолок при текущем размере BlockChain — 7 транзакций/секунду. Достаточно превысить этот пул мусорными транзакциями.
Так что +1,
гипотетическая эффективная атака на Visa обойдется не в тысячи, а в лимоны. Две большие разницы.
И другие замечательные вещи, которые нужно долго и правильно настраивать
Какие еще есть техники/приемы применимые на практике?
Те что можно реально улучшить/как дополнительно защититься, оставив непопулярную парольную политику в качестве крайней меры?
Не всегда даже самые крупные сервисы уделяют достаточное внимание защите от создания простых паролей, а значит, и безопасности аккаунтов пользователей.
У меня немного другое мнение. Раздражают сервисы с подобной политикой:
ваш пароль должен содержать 8+ символов
8? ок, теперь в пароле должна быть заглавная буква
есть заглавная? Теперь добавьте спец-символ
добавили? ок, ок, теперь должна быть хотя бы одна цифра
прошло 6 месяцев, теперь поменяйте пароль снова
Верные методы распугать всех пользователей. И такие методы чаще используются в рунете, чего не скажешь про западный рынок.
Мое утверждение такое: сервис изначально должен работать так, чтоб его было очень-очень сложно/неэффективно брутофорсить (Rate limiting, распознавание/блок опасной активности итд) и система защиты должна быть достаточно стойкой без необходимости раздражать пользователя слишком строгой парольной политикой. В итоге хорошо давать рекомендации (strong/weak), но нельзя заставлять пользователя устанавливать пароль, который он в итоге забудет.
Хорошо работающая система безопасности практически невидима для пользователя!
Защита пароля от перебора — это проблема сервиса, а не проблема пользователя!
Очень важно соблюсти баланс.
Вот пример как Yii2 Framework выкрутился, просто добавили свою надстройку для PSR-2:
github.com/yiisoft/yii2-coding-standards/blob/master/Yii2/ruleset.xml#L6
github.com/yiisoft/yii2-coding-standards/blob/master/Yii2/Sniffs/Properties/PrivatePropertiesUnderscoreSniff.php
Все самое хорошее от PSR-2, плюс несколько своих оптимизаций.
Меня радует вцелом тенденция, движение в сторону каких-то общих стандартов и договоренностей, когда большинство участников только выигрывает.
Я б еще добавил 2 пункта:
— Использование PSR, как минимум PSR-2 внутри команды/проекта как единого стиля.
— Использование PHPDoc для всего. Хорошо не только в целях документации, но и для лучшей поддержки IDE Autocomplete и подсветки ошибок в случае неверных типов данных.
> Вы правильно используете современные системы контроля версий
> * Всё должно быть в git-е
> * Всё — это значит всё! И даже конфиги приложения
Здесь уместно добавить примечание: все, кроме паролей и токенов.
Проблема действительно большая, владельцам бизнесов надо на их языке объяснять вред и потенциальные последствия той или иной уязвимости.
Очень часто сталкиваюсь с отношением владельцев когда буквально говорят: «Adding new features is more priority than fixing security. We don't need that.»
Когда начинаешь разъяснять возможный ущерб, — лучше приходит понимание, но обычно все равно со скрипом.
Вы правы, это сугубо субъективная оценка и наверное планка слишком высока.
Здесь главное не впадать в крайности. Это можно применять к tech-компаниям с 10+ человек в команде, где уже какие-то тех. процессы устоялись и обычно кто-то занимается серверами. Конечно, бесмысленно говорить об очень маленьких компаниях вроде «2 человека и собака» и конечно есть исключения из правил.
Приведу пример:
Западный стартап, с помощью которого можно заказать чартер/частный самолет. $6к+ средняя транзакция. Полный букет брешей в SSL тесте — первый плохой знак.
Смотрим глубже — PHP 5.3 светится в хедерах. Дальше — domain.com/blog/readme.html — старая дырявая версия Wordpress.
Можно ли уже сказать что-то о технической части проекта? Спрашиваем овнера: «Что происходит?». Оказывается работают индусы за копейки :)
Не обязательно содержать инфобезника, должен быть баланс, когда программист хоть немного интересуется что происходит нового в IT мире, а уж тем более тот кто занимается серверами.
Просто это не единственный фактор, это часть паттерна, некий звоночек.
Особенно важно выделить огромную работу на публику: Конференции, DockerCon, доклады. Отсюда и куча людей, которые начали его пробовать и нести свой вклад в проект через GitHub (1К contributors!)
Коммьюнити
Для большинства из нас Docker появился внезапно, многие узнали о нем уже будучи популярным. Но вся эта популярность благодаря OpenSource экосистеме и работе с коммьюнити (ну и $150M инвестиций :)
Это ли не революция? Новый подход при создании приложений
Разница между Committer vs Contributor описана здесь:
Хоть бы пост-фактум видео на Youtube увидеть..
Ваше изначальное утверждение, что решение основанное на Redis недостаточно гибко/масштабируемо/надежно итд.
Я показал пример, что Redis в качестве бэкенда для MQ достаточно серьезное решение, используемое Github, где совсем не: «очень простые очереди с небольшим количеством неважных задач». К примеру Redis-Resque и RabbitMQ вполне конкурирующие системы.
Конечно можно, Redis умеет складывать данные в файловую систему и подхватывать в случае рестарта/поломки. Кроме того, есть репликация.
По функционалу — пройдитесь по списку resque плагинов и их описанию. Заодно статья за 2009 год будет полезна почему Github написали свой велосипед, перепробовав кучу других MQ:
highscalability.com/blog/2009/11/6/product-resque-githubs-distrubuted-job-queue.html
Я в корне не согласен с трактовкой что Redis как бэкенд для MQ (пример resque) не подходит для серьезных задач и нагрузок. И по функционалу и по скорости (~100K сообщений/секунду на ядро одинаково достижимы как для resque так и для RabbitMQ) и по надежности (миллионы сообщений в сутки не проблема вообще ни для какой MQ).
У рубистов есть Resque, который использует Redis в качестве бэкенда.
Resque сделан в GitHub и используется ими в качестве основного MQ. И он действительно быстрый и нагрузку он держит.
Есть очень много имплементаций на других языках и очень хорошая web паель управления (в лучших традициях GitHub).
+1, даже несмотря на субьективно негативное отношение к К.
Это платежные системы, работающие с биткоин, это какие-то магазины подключающие биткоин, это открывающиеся Bitcoin автоматы по всему миру. Это куча стартапов, выросших вокруг BitCoin и получившие инвестиции.
В результате это те же новости на крупных новостных порталах, дающие глоток кислорода в виде нового притока пользователей.
Чем меньше ей будут пользоваться массово и чем меньше система будет подходить под мэйнстрим, тем труднее со временем будет завести/вывести биткоины, поскольку все больше сервисов закроется (а это неудобно для черного рынка).
Соответственно это путь в никуда.
Как я понял, они понизили размер блока до 135KB, тем самым повысив минимальную планку комиссии:
www.reddit.com/r/Bitcoin/comments/3cnrt8/bitfury_pool_16_of_hashrate_drops_their_max_block
en.bitcoin.it/wiki/Scalability
blog.bitcoinfoundation.org/a-scalability-roadmap
Текущий технический потолок системы в 7 транзакций/секунду (7, Карл!) — это курам на смех.
Если не решат эту проблему, — система так и останется бухтой для чернухи и крипто-романтиков, а значит постепенно умрет.
Если же система выкрутится и найдут какое-то элегантное Scalability решение, позволяющее системе стать массовой для использования (очень много надо менять в протоколе) — будет интересно!
en.bitcoin.it/wiki/Scalability
blog.bitcoinfoundation.org/a-scalability-roadmap
Текущий технический потолок системы в 7 транзакций/секунду (7, Карл!) — это курам на смех.
Если не решат эту проблему, — система так и останется бухтой для чернухи и крипто-романтиков, а значит постепенно умрет.
Если же система выкрутится и найдут какое-то элегантное Scalability решение, позволяющее системе стать массовой для использования — будет интересно!
Можно говорить о том, насколько сеть подготовлена к нагрузке.
Bitcoin потолок при текущем размере BlockChain — 7 транзакций/секунду. Достаточно превысить этот пул мусорными транзакциями.
Так что +1,
гипотетическая эффективная атака на Visa обойдется не в тысячи, а в лимоны. Две большие разницы.
Какие еще есть техники/приемы применимые на практике?
Те что можно реально улучшить/как дополнительно защититься, оставив непопулярную парольную политику в качестве крайней меры?
У меня немного другое мнение. Раздражают сервисы с подобной политикой:
Верные методы распугать всех пользователей. И такие методы чаще используются в рунете, чего не скажешь про западный рынок.
Мое утверждение такое: сервис изначально должен работать так, чтоб его было очень-очень сложно/неэффективно брутофорсить (Rate limiting, распознавание/блок опасной активности итд) и система защиты должна быть достаточно стойкой без необходимости раздражать пользователя слишком строгой парольной политикой. В итоге хорошо давать рекомендации (strong/weak), но нельзя заставлять пользователя устанавливать пароль, который он в итоге забудет.
Хорошо работающая система безопасности практически невидима для пользователя!
Защита пароля от перебора — это проблема сервиса, а не проблема пользователя!
Очень важно соблюсти баланс.
Вот пример как Yii2 Framework выкрутился, просто добавили свою надстройку для PSR-2:
github.com/yiisoft/yii2-coding-standards/blob/master/Yii2/ruleset.xml#L6
github.com/yiisoft/yii2-coding-standards/blob/master/Yii2/Sniffs/Properties/PrivatePropertiesUnderscoreSniff.php
Все самое хорошее от PSR-2, плюс несколько своих оптимизаций.
Меня радует вцелом тенденция, движение в сторону каких-то общих стандартов и договоренностей, когда большинство участников только выигрывает.
— Использование PSR, как минимум PSR-2 внутри команды/проекта как единого стиля.
— Использование PHPDoc для всего. Хорошо не только в целях документации, но и для лучшей поддержки IDE Autocomplete и подсветки ошибок в случае неверных типов данных.
> Вы правильно используете современные системы контроля версий
> * Всё должно быть в git-е
> * Всё — это значит всё! И даже конфиги приложения
Здесь уместно добавить примечание: все, кроме паролей и токенов.
Очень часто сталкиваюсь с отношением владельцев когда буквально говорят: «Adding new features is more priority than fixing security. We don't need that.»
Когда начинаешь разъяснять возможный ущерб, — лучше приходит понимание, но обычно все равно со скрипом.
Из доков:
Интерактивная инфографика со средней температурой по интернету для топ 1М сайтов:
www.trustworthyinternet.org/ssl-pulse
Здесь главное не впадать в крайности. Это можно применять к tech-компаниям с 10+ человек в команде, где уже какие-то тех. процессы устоялись и обычно кто-то занимается серверами. Конечно, бесмысленно говорить об очень маленьких компаниях вроде «2 человека и собака» и конечно есть исключения из правил.
Приведу пример:
Западный стартап, с помощью которого можно заказать чартер/частный самолет. $6к+ средняя транзакция. Полный букет брешей в SSL тесте — первый плохой знак.
Смотрим глубже — PHP 5.3 светится в хедерах. Дальше — domain.com/blog/readme.html — старая дырявая версия Wordpress.
Можно ли уже сказать что-то о технической части проекта? Спрашиваем овнера: «Что происходит?». Оказывается работают индусы за копейки :)
Не обязательно содержать инфобезника, должен быть баланс, когда программист хоть немного интересуется что происходит нового в IT мире, а уж тем более тот кто занимается серверами.
Просто это не единственный фактор, это часть паттерна, некий звоночек.
Сыграло все:
Особенно важно выделить огромную работу на публику: Конференции, DockerCon, доклады. Отсюда и куча людей, которые начали его пробовать и нести свой вклад в проект через GitHub (1К contributors!)
Для большинства из нас Docker появился внезапно, многие узнали о нем уже будучи популярным. Но вся эта популярность благодаря OpenSource экосистеме и работе с коммьюнити (ну и $150M инвестиций :)