Для вопроизводимости важно получить те же выходные результаты на тех же самых входных данных. Если тег переписан так чтобы это свойство сохранялось — проблем нет. В ином случае автору научной статьи не выгодно переписывать теги — результаты работ могут быть подвергнуты сомнению из-за того, что не получается воспроизвести.
Пользуясь случаем поделюсь своим проектом о воспроизводимости. Идея — сделать так, чтобы воспроизвести результат работы распределённой задачи можно было с помощью одной не очень длинной команды. Например, такой:
Внутри используется докер, который умеет интегрироваться с популярными технологиями, используемыми на кластерах: MPI, самой популярной технологией распараллеливания, и Slurm'ом, одним из самых популярных менеджеров ресурсов.
Сейчас все прокси сервера для телеграм устроены так, чтобы маскироваться под https. Для качественной маскировки они незаметно проксируют всех "плохих" клиентов на заданный сторонний сайт, чтобы ответы прокси-сервера на любый запросы не отличались от ответов обычного сайта.
Возможно, кто-то из владельцев популярного прокси-сервера указал адрес этого облачного провайдера, чтобы туда проксировались "плохие" запросы. И, например, сменил секрет, чем вызвал всплеск плохих клиентов.
В статье по ссылке написано про 5 000 запросов в секунду в пике, что примерно соответствует 25 мегабитам/сек в пике. Это сложно назвать целенаправленной DDoS-атакой.
Сталкивался с такой ситуацией у своего мобильного оператора (Мотив). Приехал в соседнюю область, выключил передачу данных на Iphone X, а баланс кончается. Зашёл в выписку и увидел следующее:
То есть они тарифицируют каждые 50-500 байт по рублю, из-за чего каждый мегабайт получается примерно по 10 000 рублей. Написал им в поддержку, говорят всё нормально, ничего необычного.
Самый быстрый способ — использовать утилиту screen. Тогда будет работать до следующей перезагрузки. Как сделать чтобы работало и после перезагрузки зависит от ОС. Обычно это написание специального unit-файла для systemd. Планирую описать это подробнее в гитхабовской wiki.
Если запускать рекомендуемым способом, через docker-compose, то запуск после перезагрузки происходит автоматически.
Rootless режим. Полезен в hpc-кластерах, чтобы пользователи могли использовать контейнеры для воспроизведения результатов вычислительных экспериментов. Правда, чтобы добавить поддержку MPI пришлось написать скрипт https://github.com/alexbers/mpiexec-docker.
Боюсь обещать, зависит от нескольких непредсказуемых факторов.
Кстати, сегодня, после двух недель тестирования и ~50 коммитов, вышел стабильный релиз прокси-сервера. Хотел бы поблагодарить людей, которые писали отличные идеи в комментарии, в личку, слали pull request'ы, рассказывали о своём опыте работы и багах с которыми они встречались.
С багами отдельная история. Так, например, один баг оказался в реализации TCP в ядре Linux. Другой — в реализации PyPy. Третий — в реализации некоторых клиентов Telegram. В предыдущих версиях баги находились в реализации asyncio и в модуле криптографии. Осталось ещё в сервере Telegram найти багу и получится полный комплект :)
Добавил более заметные сообщения о дефолтных настройках. В сообщении про секрет теперь предлагается рандомный секрет, оказалось что, многие люди не меняли секрет, из-за того, что не знали как его сгенерировать. Надеюсь, меньше людей будут игнорировать смену секрета.
Готово. Набор TLS extensions оказался одним и тем же у большинства tls 1.3. Хотел ещё незашифрованные сертификаты из tls 1.2 поддержать, но клиенты Telegram, как выяснилось, поддерживают только зашифрованные.
Смотря как заходить браузером. Если заходить по ip-адресу или по другому имени, то заругается, а если по правильному имени, то не заругается. Самый простой способ зайти браузером "правильно" — прописать google.com в /etc/hosts или аналогичный файл.
Думаю, стоит периодически опрашивать https-сервер за ним и сохранять ответы на handshake (extensions и сертификат). Причём делать несколько запросов, чтобы понять какие части extensions случайные, а какие — нет. Возможно добавлю и это тоже
Спасибо за отличные мысли. Воплотил их в коде. Теперь прокси-сервер маскируется как tls 1.3 и отдаёт 1024-4096 случайных байт под видом зашифрованного сертификата.
Пока не придумал хорошего решения для этого. С одной стороны хочется чтобы прокси как можно проще поднимался, с другой, чтобы форсились рекомендованные настройки.
Кстати можно несколько прокси-серверов на одном и том же порту запускать если нужна суперскорость. В этом случае, если машина многоядерная, будут использоваться все ядра. А если много оперативной памяти то можно размеры буферов увеличить, TO_CLT_BUFSIZE и TO_TG_BUFSIZE в конфиге.
В качестве неофициальной демки поднял модель как бота в Telegram, если ему написать текст, допишет продолжение: @gpt3_rus_bot
На случай хабраэффекта вот исходник бота: https://colab.research.google.com/drive/1-GWqrITKBuS9RtZx9yGXttzkZnX0tvKM?usp=sharing. Ему надо только токен прописать от @BotFather.
Для вопроизводимости важно получить те же выходные результаты на тех же самых входных данных. Если тег переписан так чтобы это свойство сохранялось — проблем нет. В ином случае автору научной статьи не выгодно переписывать теги — результаты работ могут быть подвергнуты сомнению из-за того, что не получается воспроизвести.
Пользуясь случаем поделюсь своим проектом о воспроизводимости. Идея — сделать так, чтобы воспроизвести результат работы распределённой задачи можно было с помощью одной не очень длинной команды. Например, такой:
Внутри используется докер, который умеет интегрироваться с популярными технологиями, используемыми на кластерах: MPI, самой популярной технологией распараллеливания, и Slurm'ом, одним из самых популярных менеджеров ресурсов.
https://github.com/alexbers/mpiexec-docker.
У себя на кластере мы используем Podman вместо Docker'а, в нём есть киллер-фича — rootless-mode.
Сейчас все прокси сервера для телеграм устроены так, чтобы маскироваться под https. Для качественной маскировки они незаметно проксируют всех "плохих" клиентов на заданный сторонний сайт, чтобы ответы прокси-сервера на любый запросы не отличались от ответов обычного сайта.
Возможно, кто-то из владельцев популярного прокси-сервера указал адрес этого облачного провайдера, чтобы туда проксировались "плохие" запросы. И, например, сменил секрет, чем вызвал всплеск плохих клиентов.
В статье по ссылке написано про 5 000 запросов в секунду в пике, что примерно соответствует 25 мегабитам/сек в пике. Это сложно назвать целенаправленной DDoS-атакой.
Сталкивался с такой ситуацией у своего мобильного оператора (Мотив). Приехал в соседнюю область, выключил передачу данных на Iphone X, а баланс кончается. Зашёл в выписку и увидел следующее:
То есть они тарифицируют каждые 50-500 байт по рублю, из-за чего каждый мегабайт получается примерно по 10 000 рублей. Написал им в поддержку, говорят всё нормально, ничего необычного.
Самый быстрый способ — использовать утилиту screen. Тогда будет работать до следующей перезагрузки. Как сделать чтобы работало и после перезагрузки зависит от ОС. Обычно это написание специального unit-файла для systemd. Планирую описать это подробнее в гитхабовской wiki.
Если запускать рекомендуемым способом, через docker-compose, то запуск после перезагрузки происходит автоматически.
Rootless режим. Полезен в hpc-кластерах, чтобы пользователи могли использовать контейнеры для воспроизведения результатов вычислительных экспериментов. Правда, чтобы добавить поддержку MPI пришлось написать скрипт https://github.com/alexbers/mpiexec-docker.
Боюсь обещать, зависит от нескольких непредсказуемых факторов.
Кстати, сегодня, после двух недель тестирования и ~50 коммитов, вышел стабильный релиз прокси-сервера. Хотел бы поблагодарить людей, которые писали отличные идеи в комментарии, в личку, слали pull request'ы, рассказывали о своём опыте работы и багах с которыми они встречались.
С багами отдельная история. Так, например, один баг оказался в реализации TCP в ядре Linux. Другой — в реализации PyPy. Третий — в реализации некоторых клиентов Telegram. В предыдущих версиях баги находились в реализации asyncio и в модуле криптографии. Осталось ещё в сервере Telegram найти багу и получится полный комплект :)
Добавил более заметные сообщения о дефолтных настройках. В сообщении про секрет теперь предлагается рандомный секрет, оказалось что, многие люди не меняли секрет, из-за того, что не знали как его сгенерировать. Надеюсь, меньше людей будут игнорировать смену секрета.
В application data заворачиваются все данные, которое посылает приложение, их должно быть не один или два, а много.
Реальный гугл:
Прокси-сервер:
Ключ не посылается в пакетах. Прокси не отвечает что ключ не верный. Если всё-таки отвечает, то это бага в проксе.
Активному сканеру, как и клиенту Telegram, нужно знать secret для того, чтобы подключиться к прокси-серверу
Готово. Набор TLS extensions оказался одним и тем же у большинства tls 1.3. Хотел ещё незашифрованные сертификаты из tls 1.2 поддержать, но клиенты Telegram, как выяснилось, поддерживают только зашифрованные.
Смотря как заходить браузером. Если заходить по ip-адресу или по другому имени, то заругается, а если по правильному имени, то не заругается. Самый простой способ зайти браузером "правильно" — прописать google.com в /etc/hosts или аналогичный файл.
Аналогично ведёт себя и настоящий google.com.
Думаю, стоит периодически опрашивать https-сервер за ним и сохранять ответы на handshake (extensions и сертификат). Причём делать несколько запросов, чтобы понять какие части extensions случайные, а какие — нет. Возможно добавлю и это тоже
Спасибо за отличные мысли. Воплотил их в коде. Теперь прокси-сервер маскируется как tls 1.3 и отдаёт 1024-4096 случайных байт под видом зашифрованного сертификата.
Пока не придумал хорошего решения для этого. С одной стороны хочется чтобы прокси как можно проще поднимался, с другой, чтобы форсились рекомендованные настройки.
С гитхаба ещё можно.
Кстати можно несколько прокси-серверов на одном и том же порту запускать если нужна суперскорость. В этом случае, если машина многоядерная, будут использоваться все ядра. А если много оперативной памяти то можно размеры буферов увеличить, TO_CLT_BUFSIZE и TO_TG_BUFSIZE в конфиге.
Поменял код, чтобы в ссылках на прокси не использовался base64. Верну обратно когда пофиксят.