https://www.cyberark.com/threat-research-blog/securing-kubernetes-clusters-by-eliminating-risky-permissions/
#k8s #kubernetes #rbac #permissions #security
#k8s #kubernetes #rbac #permissions #security
Cyberark
Securing Kubernetes Clusters by Eliminating Risky Permissions
In this blog post, we explain how permissions are built in Kubernetes with role-based access control (RBAC) and why you should use it carefully.
Forwarded from Go Дайджест
Джон поделился своей статьёй про плоскую структуру проекта. 🤓🧐
https://www.calhoun.io/flat-application-structure
https://www.calhoun.io/flat-application-structure
Calhoun.io
Flat Application Structure in Go - Calhoun.io
Rather than spending time trying to figure out how to break code into packages, an app with a flat structure would just place all of the go files in a single package. This sounds kinda crazy, but can actually be a great facilitator of learning and letting
Forwarded from linkmeup
Милоты и няшности всем в этом чати - представлен первый релиз Pwnagotchi. Проекта для Raspberry, который заточен для взлома WiFi, но выглядит как те самые тамагочи.
Вы думаете авторы наркоманы? Тогда не читайте дальше, там ещё веселее.
Ваш питомец будет находиться в режиме мониторинга и питаться сетевыми пакетами. Причём не всеми подряд, а хэндшейками. Потом она (он, оно) пытается разорвать текущую сессию, чтобы началось переподключение. Ну и по классике: копим базу пакетов с хэшами, подбираем ключи WPA. Тут ничего вау-нового.
Весь фикус проекта, кроме его высокой няшности, в использовани нейроночек и обучения с подкреплением т.е. ваш питомец будет натурально умнеть.
С нетерпением ждём следующих версий столь увлекательного девайса...
https://www.evilsocket.net/2019/10/19/Weaponizing-and-Gamifying-AI-for-WiFi-Hacking-Presenting-Pwnagotchi-1-0-0/
Вы думаете авторы наркоманы? Тогда не читайте дальше, там ещё веселее.
Ваш питомец будет находиться в режиме мониторинга и питаться сетевыми пакетами. Причём не всеми подряд, а хэндшейками. Потом она (он, оно) пытается разорвать текущую сессию, чтобы началось переподключение. Ну и по классике: копим базу пакетов с хэшами, подбираем ключи WPA. Тут ничего вау-нового.
Весь фикус проекта, кроме его высокой няшности, в использовани нейроночек и обучения с подкреплением т.е. ваш питомец будет натурально умнеть.
С нетерпением ждём следующих версий столь увлекательного девайса...
https://www.evilsocket.net/2019/10/19/Weaponizing-and-Gamifying-AI-for-WiFi-Hacking-Presenting-Pwnagotchi-1-0-0/
evilsocket
Weaponizing and Gamifying AI for WiFi Hacking: Presenting Pwnagotchi 1.0.0
This is the story of a summer project that started out of boredom and that evolved into something incredibly fun and unique. It is also the story of how that pr
Forwarded from Записки админа
ℹ️ Почему IPv6 лучше выделять минимум по /64 - полезно знать эту информацию, всё же: https://slash64.net/
#ipv6 #network #link
#ipv6 #network #link
Forwarded from Cybersecurity & Co. 🇺🇦
AES-128 или AES-256? Минутка истории и математики.
Многие из вас, скорее всего, замечали, что различный софт, использующий шифрование, как правило, использует самый распространенный и общепринятый симметричный алгоритм блочного шифрования AES с ключами в 128- и 256-бит. Наш VPN-сервис Connecto VPN использует AES с 128-битным ключом, в то время, как некоторые другие VPN-провайдеры предлагают шифрование аналогичным алгоритмом, но с 256-битным ключом. Давайте разберёмся, почему так и зачем.
AES изначально предлагает три стандартных варианта длины ключа шифрования (128, 192 и 256 бит). Многие люди, опираясь на это, убеждены, что чем больше ключ — тем безопаснее (особенно учитывая тот факт, что AES-256 примерно на 40% медленнее чем AES-128). На самом деле, для того, чтобы понять, почему у AES есть 3 варианта длины ключа, стоит обратиться к истории.
Алгоритм шифрования AES был выбран в качестве государственного, федерального алгоритма США для защиты данных правительством Соединенных Штатов, в т.ч., данных армии, ФБР и АНБ. Армия и спецслужбы США имеют довольно большую и долгую историю использования различных методов шифрования (еще до появление AES) и так сложилось исторически, что внутренние требования их ведомств предписывают иметь три уровня защиты (такие предписания появились еще до появления AES, да и вообще, компьютеров в целом).
Исходя из этих требований законодательных и иных регуляторов, NIST (Национальный Институт Стандартов и Технологий США) решили формально последовать требованиям бюрократов и сделали три варианта длины ключа шифрования, при этом, самый первый уровень, AES-128, всё равно не может быть взломан с использованием современных технологий. Просто предложить 256-битные ключи было проще, чем изменять нормативы.
Что касается нашего выбора — мы выбрали AES-128. Давайте представим, что нам удалось использовать всю доступную в атмосфере земли энергию солнца в размере 174000 TW (тераватт) и мы запитали с их помощью огромное количество NVIDIA GTX 1080, производительность которых близка к 52000 MFLOPS/W. Взяв 1000 FLOPS за стоимость одной итерации перебора ключа к AES-128 по радужной таблице (это еще я очень оптимистично смотрю на вещи) при энергоэффективности равной 10^3, мы переберем 2^128 комбинаций вариантов ключей чуть менее чем за:
(2^128/((52∗10^3∗174∗10^15)/1000))/60/60/24/365 = 1.19*10^6 = 1.2 миллиона лет
1200000 лет перебора значений при использовании актуальных сегодня технологий. Пиздец, да?
Ну и даже если предположить, что я обосрался с вычислениями (а по-любому обосрался где-то), и допустить, что я ошибся на один знак после запятой — наша планета до этого момента времени уже десять раз станет необитаемой, уже не говоря о том, что и сами вы сдохнете.
При этом, по сравнению с 256-битным ключом, выбранный нами 128-битный ключ предлагает гораздо большее быстродействие (примерно на 40% быстрее), при этом он так же предоставляет достаточный уровень защиты данных, который нельзя взломать с помощью современных средств.
Поэтому, мораль такая: хоть AES-256 сильнее, это вовсе не означает, что AES-128 не достаточно безопасен. Большинство компаний, заявляющих, что они используют AES-256 вместо AES-128, делают это исключительно из маркетинговых целей, предполагая, что пользователь не будет разбираться в вопросе детально. Практического смысла в использование 256-битного ключа до появления квантовых компьютеров нет. И после появления. Потому что один хер взломают.
Многие из вас, скорее всего, замечали, что различный софт, использующий шифрование, как правило, использует самый распространенный и общепринятый симметричный алгоритм блочного шифрования AES с ключами в 128- и 256-бит. Наш VPN-сервис Connecto VPN использует AES с 128-битным ключом, в то время, как некоторые другие VPN-провайдеры предлагают шифрование аналогичным алгоритмом, но с 256-битным ключом. Давайте разберёмся, почему так и зачем.
AES изначально предлагает три стандартных варианта длины ключа шифрования (128, 192 и 256 бит). Многие люди, опираясь на это, убеждены, что чем больше ключ — тем безопаснее (особенно учитывая тот факт, что AES-256 примерно на 40% медленнее чем AES-128). На самом деле, для того, чтобы понять, почему у AES есть 3 варианта длины ключа, стоит обратиться к истории.
Алгоритм шифрования AES был выбран в качестве государственного, федерального алгоритма США для защиты данных правительством Соединенных Штатов, в т.ч., данных армии, ФБР и АНБ. Армия и спецслужбы США имеют довольно большую и долгую историю использования различных методов шифрования (еще до появление AES) и так сложилось исторически, что внутренние требования их ведомств предписывают иметь три уровня защиты (такие предписания появились еще до появления AES, да и вообще, компьютеров в целом).
Исходя из этих требований законодательных и иных регуляторов, NIST (Национальный Институт Стандартов и Технологий США) решили формально последовать требованиям бюрократов и сделали три варианта длины ключа шифрования, при этом, самый первый уровень, AES-128, всё равно не может быть взломан с использованием современных технологий. Просто предложить 256-битные ключи было проще, чем изменять нормативы.
Что касается нашего выбора — мы выбрали AES-128. Давайте представим, что нам удалось использовать всю доступную в атмосфере земли энергию солнца в размере 174000 TW (тераватт) и мы запитали с их помощью огромное количество NVIDIA GTX 1080, производительность которых близка к 52000 MFLOPS/W. Взяв 1000 FLOPS за стоимость одной итерации перебора ключа к AES-128 по радужной таблице (это еще я очень оптимистично смотрю на вещи) при энергоэффективности равной 10^3, мы переберем 2^128 комбинаций вариантов ключей чуть менее чем за:
(2^128/((52∗10^3∗174∗10^15)/1000))/60/60/24/365 = 1.19*10^6 = 1.2 миллиона лет
1200000 лет перебора значений при использовании актуальных сегодня технологий. Пиздец, да?
Ну и даже если предположить, что я обосрался с вычислениями (а по-любому обосрался где-то), и допустить, что я ошибся на один знак после запятой — наша планета до этого момента времени уже десять раз станет необитаемой, уже не говоря о том, что и сами вы сдохнете.
При этом, по сравнению с 256-битным ключом, выбранный нами 128-битный ключ предлагает гораздо большее быстродействие (примерно на 40% быстрее), при этом он так же предоставляет достаточный уровень защиты данных, который нельзя взломать с помощью современных средств.
Поэтому, мораль такая: хоть AES-256 сильнее, это вовсе не означает, что AES-128 не достаточно безопасен. Большинство компаний, заявляющих, что они используют AES-256 вместо AES-128, делают это исключительно из маркетинговых целей, предполагая, что пользователь не будет разбираться в вопросе детально. Практического смысла в использование 256-битного ключа до появления квантовых компьютеров нет. И после появления. Потому что один хер взломают.
Forwarded from oleg_log (Oleg Kovalov)
Подкинули слайды от Brendan Gregg, того самого решателя проблем производительности в Netflix. Определенно стоит внимания.
https://www.slideshare.net/brendangregg/lisa2019-linux-systems-performance
Спасибо @golang_for_two
https://www.slideshare.net/brendangregg/lisa2019-linux-systems-performance
Спасибо @golang_for_two
Forwarded from Северное техно
На границе ноября меланхолия сменяется яркими всплесками ностальгии и светлой тоски об ушедшем. Так же скользят по водам Балтики отблески солнца, подгоняемые мертвыми ветрами. Волна рассыпается прежде, чем исчезнет её звук. Только камни стоят тысячи лет. До нас и после.
Именно такое настроение создают работы Greyscale. Это мультижанровое сообщество и лейбл, образованное 7 лет назад в прохладных пейзажах Литвы. Тандем DJ grad_u и фотографа Rima Prusakova порождают лёгкие, но глубокие работы. О них не стоит говорить много, чтобы не нарушить волшебства.
"Ошибка ткача, дрожание его рук делают рисунок неповторимым, что и соответствует бренности мира."
Эрнст Юнгер "Гелиополь"
https://scale-limited.bandcamp.com/album/stasis-grscl06
Именно такое настроение создают работы Greyscale. Это мультижанровое сообщество и лейбл, образованное 7 лет назад в прохладных пейзажах Литвы. Тандем DJ grad_u и фотографа Rima Prusakova порождают лёгкие, но глубокие работы. О них не стоит говорить много, чтобы не нарушить волшебства.
"Ошибка ткача, дрожание его рук делают рисунок неповторимым, что и соответствует бренности мира."
Эрнст Юнгер "Гелиополь"
https://scale-limited.bandcamp.com/album/stasis-grscl06
Scale Limited
Stasis [GRSCL06], by Faded
9 track album
Forwarded from Патчкорд
Для работы со множеством одинаковых хостов можно использовать почти традиционные инструменты, такие как Cluster SSH. Выглядит интересно - много окошек сессий
С сотней узлов, да даже с десятком такого не провернёшь, не говоря про тысячи, да и не надо там другие механизмы и подходы.
SSH в которые одновременно вводятся команды. Статья про то как поставить, настроить и начать работать.С сотней узлов, да даже с десятком такого не провернёшь, не говоря про тысячи, да и не надо там другие механизмы и подходы.
Putorius
Cluster SSH - Manage Multiple Linux Servers Simultaneously - Putorius
How to manage multiple Linux servers simultaneously with Cluster SSH. Learn how to create custom cluster and tag files, command line options and more.