Forwarded from NetDevOps Space
Еще одна вам статейка по автоматизации сети "Automate your network labs with Ansible and GNS3 (Part 1)"
На пальцах объясняется как подключить Ansible к GNS3, создание топологии и ну и как бонус полное уничтожение лабы после того, как по полной наиграетесь(жестоко, не?)
Люблю все крушить, пойду делать лабу!-💥
Эта лаба для самых маленьких, а я люблю, чтобы по-взрослому!-🤸♀️
Лабу жалко! - 😢
Знакомы с другими методами, как уничтожить то, что создали? Можете поделиться здесь- https://xn--r1a.website/automate_devnet
#automation #blog #ansible #gns3
На пальцах объясняется как подключить Ansible к GNS3, создание топологии и ну и как бонус полное уничтожение лабы после того, как по полной наиграетесь(жестоко, не?)
Люблю все крушить, пойду делать лабу!-💥
Эта лаба для самых маленьких, а я люблю, чтобы по-взрослому!-🤸♀️
Лабу жалко! - 😢
Знакомы с другими методами, как уничтожить то, что создали? Можете поделиться здесь- https://xn--r1a.website/automate_devnet
#automation #blog #ansible #gns3
Hashnode
Automate your network labs with Ansible and GNS3 (Part 1) - Hashnode
Intro
In Manage your GNS3 network labs programmatically with gns3fy I talked about the use of gns3fy python library to interact with GNS3 server REST API. On this blog post I will go one step further, using an ansible collections module to manipulate...
In Manage your GNS3 network labs programmatically with gns3fy I talked about the use of gns3fy python library to interact with GNS3 server REST API. On this blog post I will go one step further, using an ansible collections module to manipulate...
Forwarded from r0 Crew (Channel)
Extracting type-information from a Go binary
https://lekstu.ga/posts/extracting-go-types/
#go #internals #darw1n
https://lekstu.ga/posts/extracting-go-types/
#go #internals #darw1n
Forwarded from Cybershit
Неплохой консольный инструмент, способный немного скрасить будни SOC аналитика https://github.com/TheresAFewConors/Sooty
- прямой и обратный DNS lookup, Whois.
- проверка URL, IP и email по различным репутационным базам и сервисам.
- работа с VirusTotal, AbuseIPDB, URLScan, HaveIBeenPwned и пр.
- прямой и обратный DNS lookup, Whois.
- проверка URL, IP и email по различным репутационным базам и сервисам.
- работа с VirusTotal, AbuseIPDB, URLScan, HaveIBeenPwned и пр.
GitHub
GitHub - TheresAFewConors/Sooty: The SOC Analysts all-in-one CLI tool to automate and speed up workflow.
The SOC Analysts all-in-one CLI tool to automate and speed up workflow. - TheresAFewConors/Sooty
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 project went from being discussed on a por
Forwarded from Записки админа
ℹ️ Почему IPv6 лучше выделять минимум по /64 - полезно знать эту информацию, всё же: https://slash64.net/
#ipv6 #network #link
#ipv6 #network #link
rxd_txd
#pics
Более старая версия с саундтрэком)
https://youtu.be/A-mGhnsGkcU
https://youtu.be/A-mGhnsGkcU
YouTube
Gas - Microscopic - HD720p - V01
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-битного ключа до появления квантовых компьютеров нет. И после появления. Потому что один хер взломают.