sdnv's funk-hole
Open in Telegram
425
Subscribers
No data24 hours
+27 days
+1830 days
Posts Archive
Repost from Кавычка
Короч, чтоб тебя всякие shodan, censys и прочие умники не сканировали, а еще и не попадать под их поисковую выдачу, рекомендую такой дефолтный конфиг для nginx:
server {
listen 80 default_server;
listen [::]:80 default_server;
listen 443 ssl http2 default_server;
listen [::] 443 ssl http2 default_server;
ssl_reject_handshake on;
server_name _;
location / {
return 444;
}
}
Че тут делаем?
Слушаем 80 и 443 на ipv4 и ipv6.
Для 443 откланяем все операции SSL handshake, если имя сервера отлично от тех, что есть в других конфигах.
И если соединие установить удалось (и для 80 порта) - рвем соединение (ответ 444 обладает такой фичей).
>Иногда мне нужно глянуть какие есть свободные IP-адреса в докер-сети
Написал небольшой однострочник, чтобы можно было удобно посмотреть отсортированные IP
┌[sdnv@hostname]-(~)
└> docker network inspect my_network | grep IPv4Address | awk '{print $2}' | sort -t. -n +3.0
"10.0.0.8/24",
"10.0.0.9/24",
"10.0.0.10/24",
"10.0.0.13/24",
"10.0.0.23/24",
Если у вас сеть с маской меньше, чем 24:
┌[sdnv@hostname]-(~)
└> docker network inspect my_network | grep IPv4Address | awk '{print $2}' | sort -t . -k 1,1n -k 2,2n -k 3,3n -k 4,4n
"10.1.0.2/8",
"10.2.0.5/8",
"10.2.0.10/8",
"10.3.0.4/8",
Если хочется вывод покрасивее - добавьте в конец команды | sed -e "s/\"//g" -e "s/\,//g":
┌[sdnv@hostname]-(~)
└> docker network inspect my_network | grep IPv4Address | awk '{print $2}' | sort -t. -n +3.0 | sed -e "s/\"//g" -e "s/\,//g"
10.0.0.8/24
10.0.0.9/24
10.0.0.10/24
10.0.0.13/24
10.0.0.23/24
#шпаргалкиСегодня вечером в 23:20, Oracle Cloud схлопнул мою бесплатную виртуалку с лицензионным CHR спустя 3 года ;(
Халява кончилась :)
Только что тыкался в веб-морде своего продового VPN-сервера и, как полагается, не сделав предварительный бэкап.
Успешно выстрелив в ногу - пришлось идти вручную изменять SQLite БД
Для этого использую веб-админку в докере:
version: '3.1'
services:
sqliteweb:
image: tomdesinto/sqliteweb
ports:
- 127.0.0.1:8080:8080
volumes:
- ./dump.db:/db/my_database.db
command: my_database.db
Для любителей docker run:
docker run -d -p 127.0.0.1:8080:8080 -v $(pwd)/dump.db:/db/my_database.db tomdesinto/sqliteweb my_database.db
#шпаргалкиRepost from воркшоперная
вышла новая версия GNOME, астрологи объявили неделю отвалившихся плагинов.
как чинить:
· клонировать репозиторий.
· обновить версию гнома в metadata.json.
· собрать плагин (в readme обычно есть команды), перелогиниться.
· всё работает — отправляй PR автору. всё сломалось — создавай issue.
Repost from k8s (in)security
Исследователи из WIZ сделали небольшой онлайн CTF "Kubernetes LAN Party" на тему
Kubernetes Security. Он довольно обширно и нетривиально покрывает вопросы сетевой безопасности в Кубере. Разведка в скомпропетированном Pod, обход Istio и Lateral Movement с помощью Kyverno – всё это есть в этом CTF. Ничего дополнительно устанавливать не требуется, терминал доступен прямо из браузера.
Сами мы уже прошли челлендж, и однозначно рекомендуем пройти его всем, кто так или иначе имеет дело с безопасностью контейнеров и Kubernetes.
P.S – Хотите увидеть прохождение данного CTF от нас?Repost from N/a
Есть ли среди подписоты пользователи Tizen OS?
А конкретно смарт-ТВ под этой осью
Repost from Максим Цепков
#DevOpsConf Сергей Реусин из СберМаркет. Инженерия устойчивости как основной инструмент выживания вашей организации: история, подходы и примеры внедрения. Это был доклад первого дня, на который я забыл опубликовать конспект. Доклад концептуальный, он принципиально меняет точку зрения на ошибки и сбои: мы не стремимся уменьшить их до нуля, увеличив время между ошибками, а определяем допустимую зону и фокусируемся на способах быстрого восстановления в случае сбоев. И это дает устойчивость системы в целом. Это подход resilience engineering, основанного на работах ряда исследователей. В их числе Richard Cook, на работы которого Сергей много ссылался. Предлагается определить зону сбоев, которая является приемлемой, и держаться в ней, в том числе - за счет быстрого восстановления, а не только за счет снижения количества ошибок. Подробнее про подход можно посмотреть в stella.report. Идея состоит в том, что мы предусматриваем универсальные способы восстановления, которые сработают в широком спектре ситуаций. И что наоборот, частные способы могут перестать работать. Например, практика канареечных релизов, при которой новые фичи сначала предоставляются малому числу пользователей для проверки работоспособности, могут перестать выполнять свою функцию, если разработчики начнут применять feature toggle, включаемые сразу и для всех, а не постепенно - сначала релиз раскатят на всех, а потом этот флаг возьмут и включат, и проблемы посыпятся.
Это - интересный взгляд. Потому что в погоне за высокой доступностью часто применяют сложные и дорогие технические решения, и несут неоправданные затраты. В то время как альтернативные способы могут быть гораздо легче. Я тут поделюсь своим опытом. В свое время мы проектировали систему розничного магазина для Спортмастера, и спросили их - а могут же быть разные проблемы с работой системы: электричество, сеть и так далее. А они рассказали, что на этот случай есть план-Б: автономный сканер ШК (ТСД), в который загружен каталог с актуальными ценами, и который умеет фиксировать продажи, сканируя ШК, и простая дешевая касса, на которой можно пробивать чеки в автономном режиме и которая работает от обычного бесперебойника, и в результате при любых проблемах магазин 6 часов способен вести продажи. Что позволяет не слишком заморачиваться с доступностью именно информационной системы. И аналогичный подход у них дальше применялся при переходе на централизованную систему лояльности: при сбоях интернета владельцам карт предоставлялась специальная скидка, размер которой их обычно удовлетворял, так что проблемы не вызывали негатива. И как побочный эффект такое решение снижало требования к доступности централизованной системы лояльности - план-Б со специальной скидкой работал и в этом случае.
Repost from Технологический Болт Генона
Бывшая «дочка» Сбербанка SberDevices распространила прошивку для своих смарт-ТВ, которая искусственно снизила разрешение их экрана. Пользователи в ярости, но производитель, судя по всему пока не планируют выпускать исправление. . . . В SberDevices заявили изданию, что «оптимизировали разрешение отображаемых элементов интерфейса. В понимании разработчиков, по всей видимости оптимизация – это лишение россиян возможности смотреть контент в Full HD и подмена разрешения на существенно более низкое. Проблема затронула недорогие модели телевизоров Sber с экранами на 32 и 43 дюйма по диагонали. Разработчики заявляют, что такая «оптимизация» продиктована стремлением увеличить скорость отклика телевизоров.Крупный российский производитель смарт-ТВ удаленно и без предупреждения ухудшил разрешение на телевизорах россиян. https://www.cnews.ru/news/top/2024-03-04_pretsedentkrupnyj_rossijskij За наводку спасибо @theaftertimes
Гайс, я тут свой страт решил продать (тот что слева)
2000 г.р., скалопированный гриф, новые лады, рельсовый хамбакер в бридже, велкро для слайда и держатель медиаторов на голове грифа (как у Стиви Вая), экранировка графитом
27К вечно деревянных (обмен тоже возможен)
