👍6
Если предыдущий пример вам показался простым и очевидным, то попробуйте догадаться, что сделает этот пример:
ssh -D 8080 -R 127.1:8080:127.1:8080 user@8.8.8.8 ssh -R 127.1:8080:127.1:8080 user@10.1.1.2Если вы офицер безопасности, задача которого запретить использование интернета на сервере
10.1.1.2, то можете начинать 10.1.1.2 посредством сокс-прокси, запущенного на компьютере «А». 192.168.0/24» не отличим от обычного трафика компьютера А.#Socks #Proxy
Please open Telegram to view this post
VIEW IN TELEGRAM
👍14
Please open Telegram to view this post
VIEW IN TELEGRAM
🤣10👍2🔥2
This media is not supported in your browser
VIEW IN TELEGRAM
Сетевые протоколы работают на разных уровнях модели OSI, это важно знать.
1. 𝗧𝗖𝗣/𝗜𝗣 — базовый метод передачи информации между устройствами в Интернете. В то время как IP отвечает за адресацию и маршрутизацию пакетов данных, TCP заботится о сборке данных в пакеты, а также о надежной доставке.
2. 𝗛𝗧𝗧𝗣 — играет решающую роль при доступе к веб-сайтам. Он отвечает за получение и доставку веб-контента с серверов конечным пользователям.
3. 𝗛𝗧𝗧𝗣𝗦 — усовершенствованная версия HTTP, HTTPS объединяет протоколы безопасности (а именно TLS) для шифрования данных, обеспечивая безопасный и конфиденциальный обмен между браузерами и веб-сайтами.
4. 𝗙𝗧𝗣 — Как следует из названия, FTP используется для передачи файлов (загрузки и скачивания) между компьютерами в сети.
5. 𝗨𝗗𝗣 — более оптимизированный аналог TCP, UDP передает данные без накладных расходов на установление соединения, что приводит к более быстрой передаче, но без гарантии, что данные будут доставлены или будут в порядке.
6. 𝗦𝗠𝗧𝗣 — движущая сила обмена электронной почтой, которая управляет форматированием, маршрутизацией и доставкой писем между почтовыми серверами.
7. 𝗦𝗦𝗛 — криптографический сетевой протокол, который обеспечивает безопасную передачу данных по незащищенной сети.
- Он обеспечивает безопасный канал, гарантируя, что хакеры не смогут интерпретировать информацию путем подслушивания
#Protocol #cheatsheet |
Please open Telegram to view this post
VIEW IN TELEGRAM
👍8🤨4
OpenSSH позволяет использовать сервера в качестве плацдарма для подключения к другим серверам, даже если эти сервера недоверенные и могут злоупотреблять чем хотят.
Допустим, мы хотим подключиться к серверу
10.1.1.2, который готов принять наш ключ. Но копировать его на 8.8.8.8 мы не хотим, ибо там проходной двор и половина людей имеет sudo и может шариться по чужим каталогам. — Компромиссным вариантом было бы иметь «другой» SSH-ключ, который бы авторизовывал
user@8.8.8.8 на 10.1.1.2, но если мы не хотим пускать кого попало с 8.8.8.8 на 10.1.1.2, то это не вариант (тем паче, что ключ могут не только поюзать, но и скопировать себе «на чёрный день»).Вызов выглядит так:
ssh -A user@8.8.8.8 ssh user2@10.1.1.2Удалённый SSH-клиент (на 8.8.8.8) может доказать
10.1.1.2, что мы это мы только если мы к этому серверу подключены и дали SSH-клиенту доступ к своему агенту авторизации (но не ключу!).#SSH #Authorization |
Please open Telegram to view this post
VIEW IN TELEGRAM
Telegraph
Схема
🔥26👍2
выбор замены minio.png
612.8 KB
Технологический радар и принятие изменений
Когда вы уже достаточно выросли из штанишек и компания насчитывает большое количество продуктов и команд, наступает момент когда пора останавливать внедрение новых технологий на "просто потому что". Каждая крупная технология должна пройти через оценку ее применения в компании, рассматриваться с разных сторон и разными людьми, которые работают в не связанных друг с другом командах и имеют абсолютно разный опыт работы с технологией. Так мы можем обоснованно принять какую-то технологию в технологический радар и получить максимальную унификацию.
А как у вас происходит выбор применяемых технологий? и кто уже что для себя решил чем заменить minio?
Когда вы уже достаточно выросли из штанишек и компания насчитывает большое количество продуктов и команд, наступает момент когда пора останавливать внедрение новых технологий на "просто потому что". Каждая крупная технология должна пройти через оценку ее применения в компании, рассматриваться с разных сторон и разными людьми, которые работают в не связанных друг с другом командах и имеют абсолютно разный опыт работы с технологией. Так мы можем обоснованно принять какую-то технологию в технологический радар и получить максимальную унификацию.
В иллюстрации пример выбора замены minio - как вы знаете с недавнего времени они стали полностью коммерческим продуктом, уйдя из поля open source.
А как у вас происходит выбор применяемых технологий? и кто уже что для себя решил чем заменить minio?
👍9
Forwarded from STEIN: ИБ, OSINT
OWASP AGENTIC SKILLS.pdf
5.9 MB
Свежак от OWASP (~66 стр., август 2026) — про security agentic skills: SKILL.md, ClawHub/skills.sh и весь этот зоопарк, который агенты тащат к себе в контекст.
ТОП-10 рисков:
• Malicious Skills — зловред под видом легитимного скилла (см. кейс ClawHavoc, 1000+ вредоносных скиллов с общим C2);
• Supply Chain Compromise — реестры без нормальной проверки происхождения;
• Over-Privileged Skills — скиллу для прогноза погоды выдают доступ ко всем API-ключам разом;
• Insecure Metadata — YAML/JSON-фронтматтер как рабочий вектор атаки, а не просто описание;
• Untrusted External Instructions — агент тянет внешний URL и слепо исполняет как инструкцию;
• Weak Isolation — скилл живёт в том же контексте, что и хост-агент, песочниц нет;
• Update Drift — обновления без пиннинга и подписи, «патч» может завезти новый пейлоад;
• Poor Scanning — сканеры ловят curl в скрипте, но не ловят то же самое, сказанное прозой;
• No Governance — никто не считает, кто что установил и с какими правами;
• Cross-Platform Reuse — манифест с ограничениями теряется при переносе между площадками.
По каждому пункту — описание, пруфы из реальных инцидентов, сценарии атак и митигации. Годнота для всех, кто уже тащит агентов в прод.
Please open Telegram to view this post
VIEW IN TELEGRAM
👍9🔥2
22 октября встречаемся в Москве: Kuber Conf уже совсем скоро!
Что будет на конференции:
– доклады про эксплуатацию Kubernetes, observability, AI и облачную инфраструктуру;
– обсуждение Service Mesh, безопасности и экономики платформ;
– темы про bare metal, железо и инфраструктуру ЦОДов;
– активности партнеров и общение с участниками.
В программе — практические кейсы и темы, которые помогут посмотреть на инфраструктуру с разных сторон: от управления кластером с помощью AI-агента и доставки системного софта в managed K8s до мультитенантности в Kubernetes-платформе.
А еще обсудим спорные вопросы индустрии: действительно ли Kubernetes — король оркестраторов, подходит ли он для всех инфраструктурных задач и как изменится наша работа в мире, где ИИ всё активнее берет на себя привычные задачи?
После основной программы можно будет продолжить общение на афтепати, познакомиться с коллегами из индустрии и обсудить конференцию уже в более неформальной обстановке
📍 Москва, 5-й Донской проезд, 17, Connect
📅 22 октября, 10:00–21:00
👉 Программа, билеты и подробности — на сайте Kuber Conf от АОТ
Что будет на конференции:
– доклады про эксплуатацию Kubernetes, observability, AI и облачную инфраструктуру;
– обсуждение Service Mesh, безопасности и экономики платформ;
– темы про bare metal, железо и инфраструктуру ЦОДов;
– активности партнеров и общение с участниками.
В программе — практические кейсы и темы, которые помогут посмотреть на инфраструктуру с разных сторон: от управления кластером с помощью AI-агента и доставки системного софта в managed K8s до мультитенантности в Kubernetes-платформе.
А еще обсудим спорные вопросы индустрии: действительно ли Kubernetes — король оркестраторов, подходит ли он для всех инфраструктурных задач и как изменится наша работа в мире, где ИИ всё активнее берет на себя привычные задачи?
После основной программы можно будет продолжить общение на афтепати, познакомиться с коллегами из индустрии и обсудить конференцию уже в более неформальной обстановке
📍 Москва, 5-й Донской проезд, 17, Connect
📅 22 октября, 10:00–21:00
👉 Программа, билеты и подробности — на сайте Kuber Conf от АОТ
🔥3
This media is not supported in your browser
VIEW IN TELEGRAM
Заморочились 😀
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥14👍1
Вместо проверок «после релиза» всё встроено в пайплайн: код проходит SAST, контейнеры сканируются, инфраструктура проверяется на комплайенс. В итоге релизы выходят быстрее и при этом безопаснее.
Этому и учит курс DevSecOps от Академии Codeby на практике:
Инженеры, которые умеют встраивать безопасность в CI/CD, сегодня в дефиците на стыке ИБ и DevOps — компании поняли, что «сначала сделать, потом чинить» обходится дороже.
Бесплатная консультация — @CodebyAcademyBot
Please open Telegram to view this post
VIEW IN TELEGRAM
👍3⚡1🔥1
This media is not supported in your browser
VIEW IN TELEGRAM
Вы же не пустите его в VLAN с серверами просто потому, что оно хорошо представилось? В жизни то же самое. Новый человек написал: «Ты мне нравишься». Красивый hostname, аватарка как с обложки, а что внутри, неизвестно.
Сетевики это знают: пинг прошёл ≠ можно доверять.
Zero trust работает не только на периметре: сверь номер телефона, пробей фото через обратный поиск, проверь электронную почту.
Доверяй, но проверяй. Сначала в карантинный VLAN, потом в доверенную сеть — okosearch.com
Please open Telegram to view this post
VIEW IN TELEGRAM
👍6👎1