rxd_txd
303 subscribers
521 photos
31 videos
22 files
2.8K links
Download Telegram
Forwarded from Security Wine (бывший - DevSecOps Wine) (Denis Yakimov)
On-Demand Container Scanning API

Прошлым летом ресечер Jerry Gamblin выложил на сайте vulnerablecontainers.org иформацию об уязвимостях 1000 самых популярных образов на Docker Hub. Не так давно по просьбе желающих он выпустил открытое API - scan.vulnerablecontainers.org на базе Trivy, Flask, Gunicorn и Nginx.

Как этим пользоваться можно почитать здесь:
https://jerrygamblin.com/2020/02/23/on-demand-container-scanning-api/

#tools #docker
Forwarded from linkmeup
Никаких шуток, всё на крайне серьёзных щщах!
Мега-удобный скрипт для обработки вывода nmap. Чтобы не рыться в простынях текста грепом, а сразу видеть только нужное.

https://github.com/ernw/nmap-parse-output
​​Browsh is a fully-modern text-based browser. It renders anything that a modern browser can; HTML5, CSS3, JS, video and even WebGL. Its main purpose is to be run on a remote server and accessed via SSH/Mosh or the in-browser HTML service in order to significantly reduce bandwidth and thus both increase browsing speeds and decrease bandwidth costs.

https://www.brow.sh/

#shell #js #go
​​Linux kernel manager and activity monitor written in #rust

kmon provides a text-based user interface for managing the Linux kernel modules and monitoring the kernel activities. By managing, it means loading, unloading, blacklisting and showing the information of a module. These updates in the kernel modules, logs about the hardware and other kernel messages can be tracked with the real-time activity monitor in kmon. Since the usage of different tools like dmesg and kmod are required for these tasks in Linux, kmon aims to gather them in a single terminal window and facilitate the usage as much as possible while keeping the functionality.

#devops
Ребята, это бомба. По ссылке - карта Земли с местными радиостанциями. Коснитесь любой зеленой точки и будет играть местное радио. Это просто улёт. Я зависла на Фаррерах, в Матере, Южно-Сахалинске, Руанде и дальше пойду:))

https://radio.garden/
Forwarded from linkmeup
Когда ребёнок на прогулке спросил "А как работает интернет?"
Очень важная уязвимость для тех, кто работает из дома

https://labs.unit221b.com/2020/04/04/wfh-security-advisory/
Forwarded from CTO On Live
🏗 Архитектура API и велосипеды (ч.1) 🚲

Самая успешная модель развития SaaS сервиса это наличие открытого API, так как именно оно помогает вашему сервису получить функции, которыми обладают другие и наоборот. Многие называют его REST API, сами правда не понимая, какие именно парадигмы и ограничения должны накладываться на такое API. За свою карьеру я поучаствовал во многих проектах и прорабатывал интеграции между различными сервисами или внутренними элементами системы (микросервисами). И к сожалению вынужден сказать, что подавляющее большинство разработчиков не считают необходимым посмотреть, а был ли уже изобретен велосипед до них и продолжают делать свои вариации протоколов взаимодействия с сервисом. Сказать по правде я и сам был таким, но возможно пост ниже поможет вам перешагнуть сразу через этот этап и открыть для себя стандарты.

💻 Разрабатывая API

Здесь я не буду писать о том, как надо проектировать базу и код, это отдельная огромная тема, но расскажу основные аспекты того, как могло бы работать ваше API

1. Всегда контролируйте код ответа. Не допускайте, чтобы сервис отвечал "200 OK", но при этом в теле ответа был допустим JSON { status: "error" } или вообще пустой ответ
2. Используйте правильные методы передачи данных (GET - выборка, POST - создание чего-либо и добавление файлов, PATCH/PUT - обновление, DELETE - удаление), это поможет вам самим гораздо правильнее роутить ваше приложение, а также проще отслеживать запросы по типам, через любой лог коллектор. Допустим пришел к вам запрос в ТП: "Аааа удалили важные данные, но мы не знаем когда". А у вас в логах все как POST /api/1.0/entity/123, что в этот момент происходило обновление или удаление? От какого метки надо восстановить данные? Правильный метод передачи вам поможет найти место гораздо быстрее
3. Не придумывайте свой формат ответов, а используйте стандарты. Если мы рассматриваем именно JSON over HTTP (что по факту сейчас стандарт отрасли, хотя как по мне лучше бы был gRPC+protobuf), то для меня лично самый удобный формат - это HAL в случае успешного ответа и Problem detail в случае какой-либо ошибки. Но стоит обратить сразу внимание, что некоторые статусы ответа не должны вообще содержать body, такие как например "204 No content"
4. Приложение должны быть stateless. Всю необходимую информацию для получения верного контекста запроса приложение должно получить из того же JWT токена
5. Не делайте универсальных методов, выгружающих все и сразу (если конечно это не какой-нибудь экспортер), а делайте ссылки от одного элемента в другой (смотри HAL)
6. В случае, если контент обновляемый, то не забывайте про заголовок ETag или Last-Modified, чтобы у того, кто запрашивает было ясное понимание, обновились данные или нет и надо ли запускать какие-то процессы у себя. Также как и заголовок If-Modified-Since с правильным ответом поможет сторонним командам обуздать ваше API легко и непринужденно
7. Крайне желательно потратить время и заиметь свой OAuth2-сервер для авторизации сторонних приложений
8. Ответ от вашего метода GET должен приниматься вашим же PATCH, то есть: Стороннее приложение запрашивает GET /api/1.0/entity/1, получает данные, как-то их модифицирует и отправляет обратно туже структуру на PATCH /api/1.0/entity/1, все проходит успешно и все счастливы и никаких конвертаций
9. Поддерживайте версионность API, либо через ссылку /api/{VERSION} или через обязательный заголовок, это избавит вас от огромного геморроя в будущем
10. Если в ответе есть дата и время, либо явно указывайте часовой пояс и сдвиг, либо используйте timestamp и работайте с utc.
Forwarded from CTO On Live
🏗 Архитектура API и велосипеды (ч.2) 🚲

11. По той же причине, что и в пункт 10 можно передавать обратно заголовок с используемой часовой зоной и текущим временем на сервере
12. Маркируйте ответ уникальным id в заголовке, чтобы было проще найти его в случае проблем
13. Крайне желательно отдавать реальное время отработки бекенда (можно также в заголовке) В этом случе риск, что к вам придут в ТП и будут говорить, что запрос долго отрабатывает (тогда как это не так) сойдут на нет.
14. Уберите из заголовков любое описание используемых технологий (заголовки Server/Powered-By) или же перебейте их кастомом
15. Лимитируйте запросы к API. Прекрасно для этих целей подходит nginx limit req module, а главное напишите это сразу в доку в ограничениях API
16. Исходя из пункта 15, не забудьте про документацию и пропишите регламент обновления документации по изменению API
17. Сделайте Zapier к своему сервису

На этому пока что всё, если у вас есть вопросы по теме, то всегда можете задать их мне лично @ea_realleo

🌐Ссылки по теме

- application/hal+json
- application/problem+json
- http status codes
- json web token
- ETag/Last-modified
- OAuth2
- ngx_http_limit_req_module
Forwarded from Мониторим ИТ
Одна из основных функций языка PromQL — агрегирование данных временных рядов в режиме реального времени. Эндрю Ньюдигейт, инженер в команде по инфраструктуре GitLab, рассказывает как этот язык можно использовать для обнаружения аномалий во временных рядах. А здесь можно посмотреть слайды презентации.
https://grep.app

Удобный поиск по опенсорсам