Forwarded from Useful Tools | Linux | DevOps (Dmitry Malinin)
Кучно пошло на тему инфобеза, вернее нестандартных приемов!
Еще один забавный метод - прокси, которая разбирает хендшейки протоколов и в зависимости от - пробрасывает в нужный сервис.
https://github.com/yrutschle/sslh
Подсказаал: @infras123
#ssh #security #proxy
Еще один забавный метод - прокси, которая разбирает хендшейки протоколов и в зависимости от - пробрасывает в нужный сервис.
SSH
и HTTPS
на одном порту :) Эдакий черный вход "для своих" :)https://github.com/yrutschle/sslh
Подсказаал: @infras123
#ssh #security #proxy
GitHub
GitHub - yrutschle/sslh: Applicative Protocol Multiplexer (e.g. share SSH and HTTPS on the same port)
Applicative Protocol Multiplexer (e.g. share SSH and HTTPS on the same port) - yrutschle/sslh
Forwarded from linkmeup
Ещё одна попытка объяснить на пальцах, как контейнеры работают с сетью.
Но что именно здесь круто сделано – интерактивность объяснения. Слева читаешь – справа в консольке буковки бегают.
https://labs.iximiuz.com/tutorials/container-networking-from-scratch
Но что именно здесь круто сделано – интерактивность объяснения. Слева читаешь – справа в консольке буковки бегают.
https://labs.iximiuz.com/tutorials/container-networking-from-scratch
iximiuz Labs
How Container Networking Works: a Docker Bridge Network From Scratch | iximiuz Labs
Begin with the basics to understand Docker and Kubernetes networking: learn how to create and interconnect Linux network namespaces using only command-line tools.
Forwarded from Код и Капуста
GoHome - это просто мастхев штука для хостинга #golang пакетов на своем домене.
Максимально актуальная тулза. Контора не очень хороших людей github взяла привычку блокировать разработчиков. С помошью GoHome можно хостить библиотеки независимо от github. Сейчас приходится заморочиться, чтобы сделать вот так, например https://gitflic.ru/project/getapp/boosty (там в ридми написано как устанавливать)
Звучит так, что нужно писать статью как это сделать правильно
https://petersanchez.com/easily-host-go-modules-on-your-domain/
Максимально актуальная тулза. Контора не очень хороших людей github взяла привычку блокировать разработчиков. С помошью GoHome можно хостить библиотеки независимо от github. Сейчас приходится заморочиться, чтобы сделать вот так, например https://gitflic.ru/project/getapp/boosty (там в ридми написано как устанавливать)
Звучит так, что нужно писать статью как это сделать правильно
https://petersanchez.com/easily-host-go-modules-on-your-domain/
Forwarded from Гороскоп Деплоя
Эта информация адресована тем, кто планирует деплоить в прод в ближайшее время. Специально для нашего ресурса астролог Ксения Тимуровна Рогова высчитала наиболее подходящие даты календаря для этой процедуры всем знакам зодиака (см. таблицу).
Forwarded from disasm.me channel
CVE-2024-6387 - regreSSHion: Remote Unauthenticated Code Execution Vulnerability in OpenSSH server
Debian Security
Зарепортили Qualyz Threat Research Unit, новость от них
Уязвимость в openssh server, занесённая коммитом, который рефакторил систему логирования. Под угрозой версии, начиная с 8.5.p1 исключительно до 9.8p1 (вышла 7 часов назад) .
Проверить, какая у вас сейчас версия:
Определить версию вашего удалённого сервера:
Security-патчи уже есть в репозиториях Ubuntu и Debian:
Как пропатчиться из сорсов (используйте только в случае, если вы знаете, что до вас обновление не долетит, так как способ нарушает принцип управления пакетами):
На всякий случай сделал инструкцию по установке 9.8p1 на Debian-based (Debian, Ubuntu, Mint, ...):
apt-get update
apt-get install build-essential zlib1g-dev libssl-dev libpam0g-dev libselinux1-dev
wgethttps://github.com/openssh/openssh-portable/archive/refs/tags/V_9_8_P1.tar.gz
tar -xzf V_9_8_P1.tar.gz
cd openssh-portable-V_9_8_P1
./configure
make
make install
mv /usr/sbin/sshd /usr/sbin/sshd.bak
ln -s /usr/local/sbin/sshd /usr/sbin/sshd
mkdir -p /usr/local/etc && for file in /etc/ssh/*; do [ -f "$file" ] && ln -s "$file" /usr/local/etc/; done
systemctl restart sshd
———
Сейчас гуляет архив с poc от 7etsuo, он лежал здесь: https://github.com/7etsuo/cve-2024-6387-poc/ - но сейчас тут 404. Один из последних коммитов гласил, что "poc нерабочий, но для начала сойдёт"
В статье Qualyz Threat Research Unit есть ссылка на технические детали эксплуатации, поэтому не затягивайте с апдейтом.
Debian Security
Зарепортили Qualyz Threat Research Unit, новость от них
Уязвимость в openssh server, занесённая коммитом, который рефакторил систему логирования. Под угрозой версии, начиная с 8.5.p1 исключительно до 9.8p1 (вышла 7 часов назад) .
Проверить, какая у вас сейчас версия:
sshd -V
Определить версию вашего удалённого сервера:
nc
ip-or-domain 22
Security-патчи уже есть в репозиториях Ubuntu и Debian:
apt update
sudo apt install --upgrade openssh-server openssh-client
Как пропатчиться из сорсов (используйте только в случае, если вы знаете, что до вас обновление не долетит, так как способ нарушает принцип управления пакетами):
На всякий случай сделал инструкцию по установке 9.8p1 на Debian-based (Debian, Ubuntu, Mint, ...):
apt-get update
apt-get install build-essential zlib1g-dev libssl-dev libpam0g-dev libselinux1-dev
wget
tar -xzf V_9_8_P1.tar.gz
cd openssh-portable-V_9_8_P1
./configure
make
make install
mv /usr/sbin/sshd /usr/sbin/sshd.bak
ln -s /usr/local/sbin/sshd /usr/sbin/sshd
mkdir -p /usr/local/etc && for file in /etc/ssh/*; do [ -f "$file" ] && ln -s "$file" /usr/local/etc/; done
systemctl restart sshd
———
Сейчас гуляет архив с poc от 7etsuo, он лежал здесь: https://github.com/7etsuo/cve-2024-6387-poc/ - но сейчас тут 404. Один из последних коммитов гласил, что "poc нерабочий, но для начала сойдёт"
В статье Qualyz Threat Research Unit есть ссылка на технические детали эксплуатации, поэтому не затягивайте с апдейтом.
Forwarded from linkmeup
И снова о немного странном, но интересном и кому-то даже важном. ktunnel – тула, поднимающая туннельчик от кубового кластера до локальной машины и делай с ним что хочешь. Почувствуй себя нодой, так сказать.
https://github.com/omrikiei/ktunnel
https://github.com/omrikiei/ktunnel
GitHub
GitHub - omrikiei/ktunnel: A cli that exposes your local resources to kubernetes
A cli that exposes your local resources to kubernetes - omrikiei/ktunnel
Forwarded from linkmeup
От проектов странных к вещам понятным и полезным в хозяйстве: SSH over HTTPS. Особо великой науки в этом нет, просто пара ловких пассов руками на стороне клиента и сервера. Зато как только ты оказываешься в сети, где параноидально закрыто всё кроме 80/443 и 53, ты на коне.
P.S. Повесить SSH на 443 порт слишком просто. Нужно больше инкапсуляций!
https://trofi.github.io/posts/295-ssh-over-https.html
P.S. Повесить SSH на 443 порт слишком просто. Нужно больше инкапсуляций!
https://trofi.github.io/posts/295-ssh-over-https.html
Forwarded from Записки админа
This media is not supported in your browser
VIEW IN TELEGRAM
📡 impala - интересный tui для настройки wifi в системе. Использует iwd для взаимодействия системы с беспроводными сетями...
https://github.com/pythops/impala
P. S. И да, я знаю что есть nmtui, но всё же.
#wifi #network #tui
https://github.com/pythops/impala
P. S. И да, я знаю что есть nmtui, но всё же.
#wifi #network #tui
Forwarded from Николай Хитров
Редактор Zed теперь и на linux
Самый быстрый хайповый смузи редактор, написанный на
https://zed.dev/linux
https://github.com/zed-industries/zed/releases/tag/v0.143.6
Самый быстрый хайповый смузи редактор, написанный на
Rust
теперь можно запустить на linux
. Кто уже успел затестить?https://zed.dev/linux
https://github.com/zed-industries/zed/releases/tag/v0.143.6
Zed
Zed on Linux is here!
We've stabilized our Linux build, download it today!
Forwarded from Записки админа
🛠 Proxmox vs FreeBSD: Which Virtualization Host Performs Better? Сравнительные тесты Proxmox и Bhyve...
https://it-notes.dragas.net/2024/06/10/proxmox-vs-freebsd-which-virtualization-host-performs-better/#conclusion
#virtualization #proxmox #bhyve
https://it-notes.dragas.net/2024/06/10/proxmox-vs-freebsd-which-virtualization-host-performs-better/#conclusion
#virtualization #proxmox #bhyve
Forwarded from Код и Капуста
Если у вас есть статичный сайт, который лежит в публичном репозитории, то как вы будете его сервить? Очевидно, склонировать в публичную папку и настроить nginx
Но, на самом деле, клонить не обязательно, если репа и так публичная. Об этом подходе автор рассказывает в статье
Обожаю такие решения. Очевидные, но гениальные. Пример кода, кстати, на #rust
Serving a Website From a Git Repo Without Cloning It
https://mediocregopher.com/posts/git-proxy
Но, на самом деле, клонить не обязательно, если репа и так публичная. Об этом подходе автор рассказывает в статье
Обожаю такие решения. Очевидные, но гениальные. Пример кода, кстати, на #rust
Serving a Website From a Git Repo Without Cloning It
https://mediocregopher.com/posts/git-proxy
Forwarded from Useful Tools | Linux | DevOps (Dmitry Malinin)
awesome-tunneling
- коллекция селфхостед туннелей на любой случай. Сгруппировано по областям применения и возможностям. https://github.com/anderspitman/awesome-tunneling
#tunnel #security #network
GitHub
GitHub - anderspitman/awesome-tunneling: List of ngrok/Cloudflare Tunnel alternatives and other tunneling software and services.…
List of ngrok/Cloudflare Tunnel alternatives and other tunneling software and services. Focus on self-hosting. - anderspitman/awesome-tunneling
Forwarded from Технологический Болт Генона
Возможность доступа к коммитам по хэшу во всех связанных форками репозиториях вызвано тем, что GitHub в целях оптимизации и исключения дубликатов хранит вместе все объекты из основного репозитория и форков, лишь логически разделяя принадлежность коммитов. Подобное хранение позволяет просмотреть в основном репозитории любой коммит из любого форка, явно указав его хэш в URL. Например, пользователь может создать форк репозитория "/torvalds/linux" и добавить в него любой код, после чего этот код станет доступен по прямой хэш-ссылке в репозитории "/torvalds/linux". В случае удаления репозитория, если имеется хотя бы один публичных форк, данные из удалённого репозитория остаются доступны по хэшу коммита.
Предлагается три сценария, представляющих угрозу безопасности:
- Первый сценарий затрагивает ситуации, когда разработчики создают форки публичных репозиториев, добавляют в них изменения, экспериментируют, а затем удаляют. Помимо утечки кода, который не предназначен для публикации, опасность представляет ситуация, когда в экспериментах в код файлов с примерами добавляются рабочие ключи доступа к API. В этом случае атакующий может получить доступ к изменению по хэшу коммита, адресуемому после удаления форка через основной репозиторий. Например, предложенным способом исследователи смогли определить 30 рабочих ключей доступа к API, изучив три связанных с машинным обучением репозитория с большим числом форков.
- Второй сценарий касается возможности получения доступа к данным после удаления первичного репозитория, если для этого репозитория были созданы форки. В качестве примера приводится случай, когда в публичном репозитории одной компании были случайно опубликованы закрытые ключи одного из сотрудников, позволяющие получить полный доступ ко всем репозиториям данной компании на GitHub. Компания удалила репозиторий через который была утечка, но ключи по-прежнему остались доступны для извлечения через обращения по хэшу коммита в репозиториях с форками.
- Третий сценарий связан с моделью разработки проектов, которые развивают базовую открытую версию в публичном репозитории и расширенную проприетарную версию в приватном. Если компания изначально развивала проект в приватном репозитории, а затем после открытия кода проекта перевела его в разряд публичных, но продолжила разработку закрытой внутренней или расширенной версии в приватном форке, имеется возможность доступа к добавленным в приватный форк изменениям по хэшам коммитов через публичный репозиторий. При этом доступ возможен только к изменениям, добавленным в приватный форк до перевода основного репозитория в разряд публичных (хранилища приватных и публичных репозиториев разделяются, но, когда два репозитория были приватными, коммиты хранились совместно, поэтому остались в репозитории после его перевода в разряд публичных).
. . .
Подобрать хэш коммита, формируемый на базе алгоритма SHA-1 и включающий 32 символа, не реально, но оказалось, что это и не требуется. GitHub поддерживает сокращённую форму обращения к коммитам, позволяющую адресовать изменения по нескольким первым символам хэша, если отсутствуют пересечения с другими коммитами. Минимальное число символов для сокращённой адресации хэша - 4, что соответствует перебору всего 65 тысяч комбинаций (16^4). При этом перебор может и не потребоваться, так как API GitHub позволяет подключать обработчики для перехвата событий, которые используются сторонними проектами, ведущими архив с полным логом всех операций, в котором информация о хэшах коммитов остаётся и после удаления репозиториев.
Доступ к данным из удалённых и приватных репозиториев на GitHub, имеющих форки
https://www.opennet.me/opennews/art.shtml?num=61605
+
Оригинал
Anyone can Access Deleted and Private Repository Data on GitHub
https://trufflesecurity.com/blog/anyone-can-access-deleted-and-private-repo-data-github
Forwarded from ITTales :(){ :|:& };:
Ещё одна проблема с которой сегодня столкнулся и для которой понадобился экстренный фикс - это если
Ситуация маслом на полотне:
При этом поды запуститься не могут из-за того что не могут спулить новый image. Пришлось повозитсья с bind mounts чтобы вынести их на общий раздел.
/var/lib/kubelet
и /var/lib/containerd
находятся на разных разделах, то в Kubernetes не работает нормально garbage collection.Ситуация маслом на полотне:
/var/lib/containerd
переполнен, а кубелет смотрит себе под ноги в /var/lib/kubelet
и говорит что всё нормально: "ещё целых 95% свободного места".При этом поды запуститься не могут из-за того что не могут спулить новый image. Пришлось повозитсья с bind mounts чтобы вынести их на общий раздел.