BufWriter<Master<'_>> – Telegram
BufWriter<Master<'_>>
105 subscribers
451 photos
28 videos
34 files
1.7K links
https://www.patreon.com/alxe_master

Видео/статьи. Конспект и мои вольные комментарии по инженерии. тут только то, что считаю полезным для себя или других =)

#os, #cloud, #rust, #golang, #python, #javaScript, #cpp, etc
Download Telegram
Если бы эту статью никто не написал. То ее я написал бы сам. #management

https://habr.com/ru/post/511868/

А вот это прямо в точку:
Человек, который боится потерять работу, работает менее эффективно — он не рискует, отмалчивается. Отказывается от повышения, потому что переживает, что не справится и потеряет работу.
https://thepacketgeek.com/rust/tcpstream/lines-codec/ реализация простейшего кодека для TCP стрима на #rust LinesCodec
https://www.google.com/alerts
Как узнать что вас начали инфу пробивать в интернете - выставить алерт на ваш ник или фио или почту
тут есть уже немного устаревшая инфа. бо #rust уже умеет в линукс кернел и в асинхронное программирование.

- Mutex
- RwLock, подводные камни, он тормозит всеже изза самого лока данных, если надо много частых чтений. и есть вариант ускорить
- UNSAFE !!! but be careful =)
- нельзя взять и сделать Дереф рав поинтера
- без локов можно, нужен счетчик ридеров. и врайтер ждет 0. НО есть проблема если ридер живет долго. опять же все решить можно

это решено в пакете evmap https://crates.io/crates/evmap

люблю смотреть выступления и стримы Jon Gjengset. он шикарен

https://www.youtube.com/watch?v=s19G6n0UjsM
RaspberryPi4B. Шикарная штука. По ходу я выкину свой старый ноут и будет у меня нормальная медиамашинка для видео в зале. Вообще не занимает места. Мощная вещь в отличие от предыдущих версий. Прям то что нужно для медиа.

- 4 core (ARM v8) 64-bit SoC @ 1.5GHz
- 4GB LPDDR4
- 5.0 GHz Wifi , Gigabit Ethernet

Но конечно я не для этого брал. Была идея возобновить свой проект с чертилко/гравировкой чпу. Но по ходу надо брать вторую. #iot #raspberrypi
тут соберу нормальные ссылки по #consul #service_discovery , которые просили
- Service Discovery в распределенных системах на примере Consul. Александр Сигачев (Inventos)
https://www.youtube.com/watch?v=IYWsZ8HFrCw
- официальный туториал https://www.consul.io/intro https://learn.hashicorp.com/consul
- How To Secure Consul with TLS Encryption
https://www.digitalocean.com/community/tutorials/how-to-secure-consul-with-tls-encryption-on-ubuntu-14-04

- Consul Часть 1 https://habr.com/ru/post/278085/
- Consul Часть 2 https://habr.com/ru/post/278101/
- Простой service discovery в Prometheus через Consul https://habr.com/ru/company/citymobil/blog/503246/
- Свой облачный хостинг за 5 минут. Часть 2: Service Discovery https://habr.com/ru/post/262397/
- Свой облачный хостинг за 5 минут. Часть 3: Consul, Registrator, Consul-Template https://habr.com/ru/post/264269/
- Наш опыт знакомства с Docker https://habr.com/ru/company/southbridge/blog/278939/
- Очень легкая система мониторинга с Телеграмом и Консулом https://habr.com/ru/post/335166/
- Consul: Service Discovery это просто, или прощаемся с конфиг-файлами https://habr.com/ru/post/266139/
- Service Discovery в распределенных системах на примере Consul. https://habr.com/ru/post/487706/
- A Consul Client Library #python https://github.com/gmr/consulate
https://raft.github.io/ нашел крутую интерактивную визуализацию #raft алгоритма

а пэйпер тут https://raft.github.io/raft.pdf
https://m.habr.com/ru/post/503284/
если коротко то любой публичный интерфейс взаимодействия между клиентом и сервером это дыра в безопасности. рест не исключение

небольшое оглавление базовых ляпов
- Недостатки контроля доступа к объектам или Небезопасные прямые ссылки на объекты
- Недостатки аутентификации пользователей
- Разглашение конфиденциальных данных
- Отсутствие проверок и ограничений
- Недостатки контроля доступа на функциональном уровне
- Небезопасная десериализация
- Некорректная настройка параметров безопасности
- Внедрение
- Недостатки управления API
- Недостатки журналирования и мониторинга
- Небезопасные Cookies и Local Storage
- Небезопасные HTTP заголовки
- Неправильное использование CORS
- Подмена кликов

неплохая памятка, или даже чеклист
небольшая подборка лицензий под open-source проекты
https://choosealicense.com/licenses/
- GNU AGPLv3
- GNU GPLv3
- GNU LGPLv3
- Mozilla Public License 2.0
- Apache License 2.0
- MIT License
- Boost Software License 1.0
- The Unlicense
Circuit Breaker Pattern

https://medium.com/@kirill.sereda/%D1%81%D1%82%D1%80%D0%B0%D1%82%D0%B5%D0%B3%D0%B8%D0%B8-%D0%BE%D0%B1%D1%80%D0%B0%D0%B1%D0%BE%D1%82%D0%BA%D0%B8-%D0%BE%D1%88%D0%B8%D0%B1%D0%BE%D0%BA-circuit-breaker-pattern-650232944e37

https://bool.dev/blog/detail/circuit-breaker-pattern

суперкоротко:
прокси между сервисами, если ошибочные ответы валятся от сервиса в течении времени дольше чем установлено, то отдавать сразу ошибку, не тратя ресурсы, через некоторое время проверить разок, если все так же, то попрежнему отдавать ошибку, если все опдуплилось - просто слать на сервис напрямую, ровно как должно быть.

слайды доклада
https://digitalvarys.com/what-is-circuit-breaker-design-pattern/


- Circuit Breaker Pattern
https://medium.com/@soumendrak/circuit-breaker-design-pattern-997c3521c1c4

немного #python
- Circuit Breakers in Python
https://everttimberg.io/blog/python-circuit-breaker/
https://github.com/danielfm/pybreaker
https://github.com/fabfuel/circuitbreaker
неочевидные атаки на веб сервис:

Birthday attack = атака на хэш функцию, с попыткой найти такой же хэш только своими силами
- солить хэши
- длинные хэши

Недостаточное Логгирование и мониторинг = сокрытие действий пользователя, так как они нигде не трэкаются и не видны
- подпись логов айдишником юзверя
- ускорение доставки логов, централизация хранения, долгое время хранения, поиск
- audit trail (для того что бынельзя было подделать, или удалить)
- алерты
https://bool.dev/blog/detail/common-and-not-common-attacks-on-website
12 factors application

1) Codebase
- one single repo for service
- several environments
2) Dependencies
- isolated
- declarative
3) Configuring
- centralized layer of configuration the service
4) Backing services
- service as attached resource
5) Build, release, run
- strictly separated stages
6) App as stateless processes
- share nothing
- memory of app as cache of single operation unit
7) Port binding
8) Concurrency
scaling with processes
9) Disposability
- fast startup and graceful shutdown
10) Staging and Production = must be very very similar
11) Logs
- as event stream
- parsable format (as fast as possible)
12) Admin processes
- split and isolate service and admin processes

https://12factor.net/
13) Observable
- current health and metrics
14) Schedulable
- expected resource constraints
15) Upgradable
- versioning and compatibility of dataformats
- previous version compatibility
16) Least privilege (for particular process/container/node)
17) Auditable
- what, when, who, and where for all operations
- operation id
- user id
- sub operation
18) Securable
- isolation of resources and network between
- use vpn and permission grid for admin access and so on
19) Measurable
- Cost predictive running of service

https://www.ibm.com/cloud/blog/7-missing-factors-from-12-factor-applications
Forwarded from Кавычка (Sergey Belov)
Один из классических вопросов на собеседование AppSec специалисту - "Как хранить пароли?". И тут будет потрясающим ответ - "пароли хранить не надо, потому что в 2020 мы не должны запускать сервисы с паролями!". За это можно получить хороший плюс. Но если все-таки вернуться к вопросу, то ожидается ответ в духе:
- Давайте использовать Argon2, PBKDF2, Bcrypt, Scrypt с оптимальным количеством раундов
- И харденинг - например использовать HSM (тут долгие холивары в каком режиме), "pepper" и т.д.

Ответы хранить соленный md5/sha1/sha256/sha512 автоматически ставят жирный минус.

Но также есть еще один вопрос, сложный, и ответ на него мало кто знает - *”А как нам хранить пароли так, что если атакующий получит RCE на бэкендах, в т.ч. root привилегии, то не сможет дампнуть табличку с хэшами?”*

Вопрос ставит в тупик, можно начинать придумывать "security through obscurity" решения, но не надо. Есть очень легкий, понятный и технически верный путь, как решить поставленную задачу. Нам нужно отозвать права "select" у бэкенд юзера на таблицу с хэшами и написать 2 хранимых SQL процедуры:

getSalt(user_id)

Вернет «соль» пароля на бэкенд по userId, который пытается войти. Бэкенд возьмет введенный юзером пароль и получит хэш с солью из базы

checkPassword(user_id, hashed_password)

Возвращает true/false на проверке хэша пароля на предыдущем шаге у user_id

Еще нужна процедура на создание пользователя и смену пароля, но они также не позволяет select'нуть хэши паролей пользователей. Хорошая статья по теме(но там не всё): https://www.secjuice.com/secure-password-handling/

Странно, что ни в одном современном решении - типа WordPress или Django это не реализовано. Да и не надо уже, давайте лучше откажемся от паролей!