Forwarded from Russian OSINT
Британский национальный центр кибербезопасности (UK's National Cyber Security Center) поделился публично коллекцией скриптов NMAP для проверки сетей на уязвимости, чтобы помочь ИБ специалистам в различных организациях закрыть слабые места в защите. Проект назвали SME (Scanning Make Easy).
"The i100 and NCSC's noscript package is based on the industry-standard NSE framework that has been in development for decades and can be used to write simple noscripts and automate network tasks"
https://github.com/nccgroup/nmap-nse-vulnerability-noscripts
"The i100 and NCSC's noscript package is based on the industry-standard NSE framework that has been in development for decades and can be used to write simple noscripts and automate network tasks"
https://github.com/nccgroup/nmap-nse-vulnerability-noscripts
Debug Istio please? What is Isteyo?
Пожаловались, что не работает один endpoint на при обращении в UI к API.
А также не получают никаких ошибок в системе логирования.
Получают ошибку 503 при изменении количества товаров.
По ошибке с присланного скриншота сразу предположил, что запрос до API не доходит, так как это похоже на ошибку на сетевом уровне, а не прикладном.
А значит проблема, предположительно, в Istio. Но я вообще ничего не знаю про Istio... Ладно, поехали!
Итак, начнем с воспроизведения проблемы: вытащим запрос и “покурлим”
Итого: не работает в сценарии, когда в сессии браузера выполняется POST запрос сам на себя через интернет и получает ошибку 503.
Подключимся к istio-proxy контейнеру:
Единственное, что подозрительное мне попалось на глаза перед каждым проблемным вызовом, это:
Пожаловались, что не работает один endpoint на при обращении в UI к API.
А также не получают никаких ошибок в системе логирования.
Получают ошибку 503 при изменении количества товаров.
По ошибке с присланного скриншота сразу предположил, что запрос до API не доходит, так как это похоже на ошибку на сетевом уровне, а не прикладном.
А значит проблема, предположительно, в Istio. Но я вообще ничего не знаю про Istio... Ладно, поехали!
Итак, начнем с воспроизведения проблемы: вытащим запрос и “покурлим”
curl -X 'POST' \Все работает! А почему не работает из браузера? Оказывается, чтобы избежать конфигурации CORS, в контейнере с UI работает Node.js сервер, который проксирует запросы в API 🤦♂️ Но это тема отдельного поста.
'https://backend.xxx.yyy/api/products/b789f971-a5a9-49a2-bda1-bc6a3d7bd21e/items/' \
-H 'accept: application/json' \
-H 'Content-Type: application/json' \
-d '{"id": "b789f971-a5a9-49a2-bda1-bc6a3d7bd21e","num": 1}'
Итого: не работает в сценарии, когда в сессии браузера выполняется POST запрос сам на себя через интернет и получает ошибку 503.
Подключимся к istio-proxy контейнеру:
k port-forward frontend 15000:15000
Включим debug-логи: curl -XPOST http://127.0.0.1:15000/logging?level=debug
Выполним парочку запросов, получив ошибку 503, и запомним id в HTTP запросе, чтобы легче было искать место в логах, так как логи траффика довольно обширные. Выгрузим логи в файл для более удобного поиска: k logs frontend -c istio-proxy > /tmp/logs.txtЕдинственное, что подозрительное мне попалось на глаза перед каждым проблемным вызовом, это:
{
"level": "debug",
"time": "2022-01-26T18:29:47.345924Z",
"scope": "envoy client",
"msg": "[C28620] Error dispatching received data: http/1.1 protocol error: both 'Content-Length' and 'Transfer-Encoding' are set."
}
Погуглив, предлагается решение:apiVersion: networking.istio.io/v1alpha3
kind: EnvoyFilter
metadata:
name: allow-chunked-length-filter
namespace: istio-system
spec:
configPatches:
- applyTo: CLUSTER
match:
context: ANY
patch:
operation: MERGE
value:
http_protocol_options:
allow_chunked_length: true
GitHub
Request with Transfer-Encoding: chunked and Content-Length is valid per RFC, but rejected with protocol error: http/1.1 protocol…
If you are reporting any crash or any potential security issue, do not open an issue in this repo. Please report the issue via emailing envoy-security@googlegroups.com where the issue will be triag...
👍2
Мой первый коммит в Open Source в kubeflow / pipelines
Не мог выполнить сборку Container image из Dockerfile через Kubeflow pipelines, используя gcr.io/kaniko-project/executor:debug: постоянно возникала ошибка на попытке сменить права на файл
Как видно по логам, проблема начинается после смены пользователя. Так как Dockerfile и контекст для сборки генерится на лету в пайплайне фреймворком BentoML, то поиск проблемного места несколько затруднялся. Для проверки гипотезы добавили в пайплайн замену строки в Dockerfile через костыль:
После чего все завелось. Сразу же был создан PR в BentoML, чтобы сборка выполнялась независимо от окружения и права в контейнере не блокировали выполнение.
Теперь осталось дождаться, пока фиксы будут выпущены вместе с новыми версиями BentoML и Kubeflow pipelines.
Не мог выполнить сборку Container image из Dockerfile через Kubeflow pipelines, используя gcr.io/kaniko-project/executor:debug: постоянно возникала ошибка на попытке сменить права на файл
bash
...
INFO[0056] USER bentoml
INFO[0056] cmd: USER
INFO[0056] No files changed in this command, skipping snapshotting.
INFO[0056] RUN chmod +x ./docker-entrypoint.sh
INFO[0056] cmd: /bin/sh
INFO[0056] args: [-c chmod +x ./docker-entrypoint.sh]
INFO[0056] util.Lookup returned: &{Uid:1034 Gid:1034 Username:bentoml Name: HomeDir:/home/bentoml}
INFO[0056] performing slow lookup of group ids for bentoml
INFO[0056] Running: [/bin/sh -c chmod +x ./docker-entrypoint.sh]
error building image: error building stage: failed to execute command: starting command: fork/exec /bin/sh: permission denied
F0121 10:26:36.836271 21 main.go:50] Failed to execute component: exit status 1
Error: exit status 1
Как видно по логам, проблема начинается после смены пользователя. Так как Dockerfile и контекст для сборки генерится на лету в пайплайне фреймворком BentoML, то поиск проблемного места несколько затруднялся. Для проверки гипотезы добавили в пайплайн замену строки в Dockerfile через костыль:
python
# swap some lines in dockerfile
with open(output_tar_path + '/Dockerfile', 'r') as f:
s = f.readlines()
df = pd.DataFrame({'Text': s})
df.Text = df.Text.str.strip()
first_lines = df.Text.str.contains('USER bentoml')
second_lines = df.Text.str.contains('RUN chmod') & df.Text.str.contains('./docker-entrypoint.sh')
df.Text.loc[first_lines], df.Text.loc[second_lines] = df.Text[second_lines].tolist(), df.Text[first_lines].tolist()
with open(output_tar_path + '/Dockerfile', 'w') as f:
f.writelines('\n'.join(df.Text.tolist()))
После чего все завелось. Сразу же был создан PR в BentoML, чтобы сборка выполнялась независимо от окружения и права в контейнере не блокировали выполнение.
Теперь осталось дождаться, пока фиксы будут выпущены вместе с новыми версиями BentoML и Kubeflow pipelines.
GitHub
fix(backend): set correct permissions for local directory (#7212) · kubeflow/pipelines@6b7adfa
Machine Learning Pipelines for Kubeflow. Contribute to kubeflow/pipelines development by creating an account on GitHub.
Кубертатный период
Debug Istio please? What is Isteyo? Пожаловались, что не работает один endpoint на при обращении в UI к API. А также не получают никаких ошибок в системе логирования. Получают ошибку 503 при изменении количества товаров. По ошибке с присланного скриншота…
Пришлось поменять
k describe <POD>
Выяснилось, что контекст ANY отвечает за роутинг не только на стороне sidecar, но и gateways.
Для корректной работы фронтенда достаточно оказалось SIDECAR_INBOUND, чтобы не аффектило istio-proxy
context: ANY на context: SIDECAR_INBOUND, так перестали работать readiness probes на контейнере с istio-proxyk describe <POD>
Warning Unhealthy 5m28s (x13 over 5m52s) kubelet Readiness probe failed: HTTP probe failed with statuscode: 503k logs <POD> -c istio-proxy
{"level":"warn","time":"2022-01-27T17:01:39.820683Z","msg":"Envoy proxy is NOT ready: config not received from Pilot (is Pilot running?): cds updates: 0 successful, 1 rejected; lds updates: 1 successful, 0 rejected"}
EnvoyFilter позволяет управлять конфигурацией получаемой от Istio Pilot. Выяснилось, что контекст ANY отвечает за роутинг не только на стороне sidecar, но и gateways.
Для корректной работы фронтенда достаточно оказалось SIDECAR_INBOUND, чтобы не аффектило istio-proxy
Пришел коллега, говорит: “выпустили публичные сертификаты с wildcard, давай поменяем в Kubernetes секреты”. Мы поправили
Затем решили обновить сертификат для одного сервиса. После обновления все сломалось, постоянные редиректы с ошибкой 500 о невалидности сертификатов.
Я подумал, вдруг это проблема с сертификатом Ingress Nginx, заменил там тоже и везде все разъезалось.
Как я уже разобрался после, единственный правильный сертификат, с которым все работало в исходной конфигурации, был на Ingress Nginx, который я удалил, не сохранив, будучи уверенным, что он не пригодится.
В итоге оказалось, что в CRT нужно класть целиком цепочку сертификатов в формате
kubectl edit secret, а также я обновил сертификаты в Vault, чтобы при деплое обратно не перезаписалось, так как я создание секретов добавил в пайплайн деплоя. Затем решили обновить сертификат для одного сервиса. После обновления все сломалось, постоянные редиректы с ошибкой 500 о невалидности сертификатов.
Я подумал, вдруг это проблема с сертификатом Ingress Nginx, заменил там тоже и везде все разъезалось.
Как я уже разобрался после, единственный правильный сертификат, с которым все работало в исходной конфигурации, был на Ingress Nginx, который я удалил, не сохранив, будучи уверенным, что он не пригодится.
В итоге оказалось, что в CRT нужно класть целиком цепочку сертификатов в формате
-----BEGIN CERTIFICATE-----
#Your GlobalSign SSL Certificate#
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
#GlobalSign Intermediate Certificate#
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
#GlobalSign Root Certificate#
-----END CERTIFICATE-----Forwarded from Deleted Account
This media is not supported in your browser
VIEW IN TELEGRAM
там это, 🍯 сняли документальное (!) кино про кубурнетис , аж в двух частях:
- https://youtu.be/BE77h7dmoQU
- https://youtu.be/318elIq37PE
из рабочего чата
- https://youtu.be/BE77h7dmoQU
- https://youtu.be/318elIq37PE
из рабочего чата
YouTube
Kubernetes: The Documentary [PART 1]
The official Kubernetes Documentary Part 1.
Inspired by the open source success of Docker in 2013 and seeing the need for innovation in the area of large-scale cloud computing, a handful of forward-thinking Google engineers set to work on the container…
Inspired by the open source success of Docker in 2013 and seeing the need for innovation in the area of large-scale cloud computing, a handful of forward-thinking Google engineers set to work on the container…
Forwarded from linkmeup
А вот Mozilla молодцы, Mozilla пишет интересные постмортемы.
https://hacks.mozilla.org/2022/02/retrospective-and-technical-details-on-the-recent-firefox-outage/
https://hacks.mozilla.org/2022/02/retrospective-and-technical-details-on-the-recent-firefox-outage/
Mozilla Hacks – the Web developer blog
Retrospective and Technical Details on the recent Firefox Outage
On January 13th 2022, Firefox became unusable for close to two hours for users worldwide. This post highlights the complex series of events and circumstances that, together, triggered a bug deep in the networking code of Firefox.
linkmeup
А вот Mozilla молодцы, Mozilla пишет интересные постмортемы. https://hacks.mozilla.org/2022/02/retrospective-and-technical-details-on-the-recent-firefox-outage/
Вкратце: Google сменил протокол на балансировщиках по-умолчанию на HTTP/3, а Mozilla пользовалась настройками по-умолчанию. Плюс ко всему библиотека viaduct приводила все буквы HTTP-заголовков к строчным, что нарушило работу API.
Выводы: не пользуйтесь настройками по-умолчанию
Выводы: не пользуйтесь настройками по-умолчанию
Forwarded from Experimental chill
Взаимодействие с другими процессами
В Linux исторически у одного процесса мало способов взаимодействовать на другие процессы после их создания. Все эти годы существовала только отправка сигналов и ptrace(). Оно не зря продержалось долгое время, -- не стоит миксовать абстракции, пока нет устоявшихся временем понятий и понимания, что ничего не поменяется в перспективе.
В последние годы в сообществе Linux увеличился сильный интерес к предоставлению процессам способов управления другими или обеспечения чуть больше контроля даже за структурами внутри. Скажем, для userfaultfd(2), который разрешает делать абсолютную грязь с pagefault в юзерспейсе, я могу придумать с десяток различных сценариев, что можно делать интересного с памятью -- сжимать, находить паттерны, следить за качеством и количеством, собирать статистику и прочее.
Не так давно (в Linux 5.13) наконец-то приняли в Linux системный process_madvise(). Эта история интересна сама по себе, в Linux разрешили управлять (ладно, не управлять, а "советовать") страницами памяти других процессов. Сделали изначалально достаточно консервативно. С другой стороны, удовлетворяют интересам сообщества Linux.
madvise(2) сам по себе предоставляет механизмы работы с памятью, когда можно посылать "советы" тем или иным страницам. В самом madvise(2) в Linux 5.4 добавили две опции MADV_COLD и MADV_PAGEOUT. Первая просит ядро поместить указанный диапазон страниц в "inactive list", говоря, что они давно не использовались. Эти страницы будут первыми для рассмотрения на вытаскивание, если ядру потребуется память для других целей. MADV_PAGEOUT является более сильным советом о том, что указанные страницы больше не нужны. Это приводит к их немедленной рекламации.
Чтобы осуществлять такие махинации, process_madvise(2) взял эти две опции и начал использовать вместе с недавним механизмом в ядре под названием pidfd_open(2), где нам c Linux 5.3 теперь можно работать с процессами как с файловыми дескрипторами. Теперь вам дают файловый дескриптор и можно с ним взаимодействовать. API у process_madvise(2) получается правильным, всё советую делать в OS через файловые дескрипторы.
Стоит отметить, что совсем недавно (Август 2021) process_madvise(2) добавил опцию MADV_WILLNEED, которая говорит, что скоро память понадобится процессу. Такой механизм отлично работает, если процесс стал проявлять активность, и хочется сделать prefetch всей остальной памяти.
Зачем это надо?
В очень разносторонних окружениях таких как серверы или телефоны, этим можно начинать пользоваться.
Скажем, Android начал использовать process_madvise для оптимизации памяти приложений, которые уходят в background. Вы выходите из chrome или spotify, вряд ли вы туда быстро вернётесь, можно память вытеснить на что-то более полезное. А как только начнёте пользоваться, можно сделать prefetch всей остальной памяти. В итоге лучше управление, быстрее говорим памяти, что делать, больше освобождаем место тому, кому это надо.
Если что, компакция памяти и такие оптимизации делаются уже в Android 12, и фиксы с оптимизациями оверхеда, чтобы это работало ещё шустрее происходят прям на этой неделе.
Это также может быть полезно serverless базам данных, скажем, по запросу мы можем угадать, какие паттерны памяти будут использоваться теми или иными хостами, но тут, конечно, надо изобрести что-то интересное.
Более простой пример, который приходит на ум -- попытаться сделать глобальный аллокатор на сервере, который рассуждает сам, кто просыпается, а кто засыпает, чтобы контролировать паттерны памяти.
Ещё, надеюсь, с развитием других опций, мы сможем применить MADV_DONTDUMP, которая говорит, что не надо в coredump страницы выкладывать и, если мы обрабатываем пользовательские данные или секреты, то их можно пометить таким флагом. И это может быть cloud решение, а не каждая программа сама писать.
Интересно очень, прям хоть начинай эпоху глобальных оптимизаторов памяти для хостов.
[1] process_madvise(2), madvise(2)
[2] pidfd_open(2)
[3] Оптимизации памяти Android с помощью process_madvise и ускорение
В Linux исторически у одного процесса мало способов взаимодействовать на другие процессы после их создания. Все эти годы существовала только отправка сигналов и ptrace(). Оно не зря продержалось долгое время, -- не стоит миксовать абстракции, пока нет устоявшихся временем понятий и понимания, что ничего не поменяется в перспективе.
В последние годы в сообществе Linux увеличился сильный интерес к предоставлению процессам способов управления другими или обеспечения чуть больше контроля даже за структурами внутри. Скажем, для userfaultfd(2), который разрешает делать абсолютную грязь с pagefault в юзерспейсе, я могу придумать с десяток различных сценариев, что можно делать интересного с памятью -- сжимать, находить паттерны, следить за качеством и количеством, собирать статистику и прочее.
Не так давно (в Linux 5.13) наконец-то приняли в Linux системный process_madvise(). Эта история интересна сама по себе, в Linux разрешили управлять (ладно, не управлять, а "советовать") страницами памяти других процессов. Сделали изначалально достаточно консервативно. С другой стороны, удовлетворяют интересам сообщества Linux.
madvise(2) сам по себе предоставляет механизмы работы с памятью, когда можно посылать "советы" тем или иным страницам. В самом madvise(2) в Linux 5.4 добавили две опции MADV_COLD и MADV_PAGEOUT. Первая просит ядро поместить указанный диапазон страниц в "inactive list", говоря, что они давно не использовались. Эти страницы будут первыми для рассмотрения на вытаскивание, если ядру потребуется память для других целей. MADV_PAGEOUT является более сильным советом о том, что указанные страницы больше не нужны. Это приводит к их немедленной рекламации.
Чтобы осуществлять такие махинации, process_madvise(2) взял эти две опции и начал использовать вместе с недавним механизмом в ядре под названием pidfd_open(2), где нам c Linux 5.3 теперь можно работать с процессами как с файловыми дескрипторами. Теперь вам дают файловый дескриптор и можно с ним взаимодействовать. API у process_madvise(2) получается правильным, всё советую делать в OS через файловые дескрипторы.
Стоит отметить, что совсем недавно (Август 2021) process_madvise(2) добавил опцию MADV_WILLNEED, которая говорит, что скоро память понадобится процессу. Такой механизм отлично работает, если процесс стал проявлять активность, и хочется сделать prefetch всей остальной памяти.
Зачем это надо?
В очень разносторонних окружениях таких как серверы или телефоны, этим можно начинать пользоваться.
Скажем, Android начал использовать process_madvise для оптимизации памяти приложений, которые уходят в background. Вы выходите из chrome или spotify, вряд ли вы туда быстро вернётесь, можно память вытеснить на что-то более полезное. А как только начнёте пользоваться, можно сделать prefetch всей остальной памяти. В итоге лучше управление, быстрее говорим памяти, что делать, больше освобождаем место тому, кому это надо.
Если что, компакция памяти и такие оптимизации делаются уже в Android 12, и фиксы с оптимизациями оверхеда, чтобы это работало ещё шустрее происходят прям на этой неделе.
Это также может быть полезно serverless базам данных, скажем, по запросу мы можем угадать, какие паттерны памяти будут использоваться теми или иными хостами, но тут, конечно, надо изобрести что-то интересное.
Более простой пример, который приходит на ум -- попытаться сделать глобальный аллокатор на сервере, который рассуждает сам, кто просыпается, а кто засыпает, чтобы контролировать паттерны памяти.
Ещё, надеюсь, с развитием других опций, мы сможем применить MADV_DONTDUMP, которая говорит, что не надо в coredump страницы выкладывать и, если мы обрабатываем пользовательские данные или секреты, то их можно пометить таким флагом. И это может быть cloud решение, а не каждая программа сама писать.
Интересно очень, прям хоть начинай эпоху глобальных оптимизаторов памяти для хостов.
[1] process_madvise(2), madvise(2)
[2] pidfd_open(2)
[3] Оптимизации памяти Android с помощью process_madvise и ускорение
👍1
Forwarded from Mops DevOps
Scaling Kubernetes to Over 4k Nodes and 200k Pods
Learn the challenges PayPal had to face when they started scaling the cluster to over 4000 nodes and 200k pods
👉 https://bit.ly/3LIVn9R
#kubernetes
Learn the challenges PayPal had to face when they started scaling the cluster to over 4000 nodes and 200k pods
👉 https://bit.ly/3LIVn9R
#kubernetes
Forwarded from addmeto (Grigory Bakunov 🧪)
В wired грустная статья о том, что кажется, Firefox умирает. Mozilla Corp. пытаются как-то крутиться, увеличивая диверсификацию своих доходов за счет персонализации и партнерств.
Каждый уважающий себя человек из айти, мне кажется, должен поддерживать Firefox, хотя бы потому что это последний существующий альтернативный движок для рендеринга html/css. В прошлый раз, когда мы были в подобной ситуации, — это было доминирование Internet Explorer, и мы получили остановку в развитии веба почти на 8 лет.
https://www.wired.com/story/firefox-mozilla-2022/
Каждый уважающий себя человек из айти, мне кажется, должен поддерживать Firefox, хотя бы потому что это последний существующий альтернативный движок для рендеринга html/css. В прошлый раз, когда мы были в подобной ситуации, — это было доминирование Internet Explorer, и мы получили остановку в развитии веба почти на 8 лет.
https://www.wired.com/story/firefox-mozilla-2022/
WIRED
Is Firefox OK?
Mozilla’s privacy-heavy browser is flatlining. What it does next is crucial for the future of the web.
Like unit testing, for performance
A modern load testing tool for developers and testers in the DevOps era.
A modern load testing tool for developers and testers in the DevOps era.