Даниэль Лемир – профессор Заочного квебекского университета (TÉLUQ), придумавший способ очень быстро парсить double – совместно с инженером Джоном Кайзером из Microsoft опубликовали ещё одну свою находку: валидатор UTF-8, обгоняющий библиотеку UTF-8 CPP (2006) в 48..77 раз, ДКА от Бьёрна Хёрманна (2009) – в 20..45 раз, и алгоритм Google Fuchsia (2020) – в 13..35 раз. Новость об этой публикации на хабре уже постили, но без технических подробностей; так что восполняем этот недочёт.

100 мегабит в секунду от предыдущего провайдера начал сильно замедлять рабочий процесс, поэтому я начал искать провайдера с нормальной скоростью. В моем доме, из быстрых был только МГТС, на чем я и остановился. Провели интернет быстро, два дня между заявкой и кабелем в квартире, оставили большую бухту оптики, за что спасибо…

А вы когда-нибудь записывали свои впечатления от изучения нового языка? Записывали все, что вам не понравилось, чтобы через пару недель изучения понять, насколько недальновидными и тупыми они были? 



На днях я понял F#, и попытаюсь описать словами мысль, стоящую за языком. 

Мы в RUVDS очень любим три вещи: сисадминов, байки и пиво.

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


Ммммм, сисадмин-техпод-байка-пиво

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

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



Раньше я работал в IT-отделе компании Samsung. Одному из сотрудников нужно было сбросить пароль, я сменил пароль на «Samsung1» и сказал ему об этом. Мне перезвонили через две минуты и сказали, что пароль не подходит. Я снова сбросил его, но он снова не сработал. Я подумал, что проблемы со стороны пользователя и решил зайти к нему.
Каково было мое удивление, когда я увидел, что он неправильно набирает пароль! Он печатал «Semsung1».
«Подсказываю! Это компания, в которой вы работаете, и ее название написано на мониторах, перед которыми вы сидите»

Питер Дж.

Remote Desktop Protocol — один из самых распространенных протоколов для удаленного управления, потому что он используется для работы с операционными системами Windows, которые часто незаменимы в корпоративной среде. Естественно, самый распространенный способ подключения к удаленной системе — использование средств встроенных в саму систему, но он не единственный и, более того, совершенно неприменимый, если используется другая ОС или сильно устаревшая Windows.

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

В предыдущих статьях, от RSagittarius, посвящённых ZeroTier было подробно рассмотрено практическое применение данного инструмента и его настройка. Настало время сравнить его с таким, набирающим популярность, решением как WireGuard, что бы понять — в каких случаях лучше выбрать ZeroTier, а в каких WireGuard. Так же, «на закуску», рассмотрим такую штуку как локалка RuVDS.

Недавно я шерстил Хабр и встретил комментарий от Inskin:


Я впервые познакомился в Windows Admin Center, когда в нем был только счетчик управления файлами и больше ничего. Сейчас все инструменты из RSAT потихоньку переезжают в Windows Admin Center.

Пока я не видел ни одного толковой русской статьи про настройку Windows Admin Center и решил написать ее сам. Под катом подробный обзор, две скрытые кайфовые фишки WAC, а также инструкции по установке и настройке.

Какие фичи реализованы на текущий момент?

Чуть больше года назад WAС был практически неюзабельным, в превью версии был только красивый дашборд и управление процессами.

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

В одной из статей я рассказывал о том, как скрипт кидди мешает жить нашим клиентам. В этой статье я хотел бы рассказать про решения: как мы будем пытаться с этим бороться.

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

Стандартные «решения»

Рассылать жалобы

Очень распространенный подход. При обнаружении вторжения в свою ИС занести атакующего в фаерволл (или не занести) и отправить автоматическую жалобу по почте, которую нашли во whois.
Мы получаем жалобы на наших клиентов от системы обнаружения вторжений разных банков, офисов, сайтов. Даже, вроде как, крупные организации просто накатывают fail2ban и на этом все.
Работать это все будет через раз, что, если атакующего не забанят? Да и неправильно это, давать возможность постучаться к себе в дверь, что, если кто-то установит пароль уровня solarwinds123 и его взломают с первой попытки?

Заставлять пользователей «делать правильно».

Можно сделать свою службу, почти малварь, как это сделали Godaddy, добавить еще одного пользователя под логином nydys и забыть отключить администратора cloud-init, как это сделали Godaddy, установить в систему 8 лишних сертификатов, как это сделали Godaddy.
Еще можно блокировать AD и другие «небезопасные порты», как это делали некоторые другие хостинги и вот это вот все.

Хабр точно знаком с парадоксом, а вот с некоторыми фичами павершелла, вероятно, нет, поэтому тут больше про него.

Journalctl — отличный инструмент для анализа логов, обычно один из первых с которым знакомятся начинающие администраторы linux систем. Встроенные возможности ротации, богатые возможности фильтрации и возможность просматривать логи всех systemd unit-сервисов одним инструментом очень удобны и заметно облегчают работу системным администраторам.

Эта статья рассматривает основные возможности утилиты journalctl и различные варианты ее применения. С помощью journalctl можно просматривать логи системы, чтобы решить возникшие проблемы на рабочей станции или сервере использующие дистрибутив linux с демоном инициализации systemd, де-факто уже ставшим стандартом в современных Linux-системах, например: RHEL, CentOS, Fedora, Debian и многих других.

Существует мнение, что systemd не так уж и хорош — он нагружает систему и это все еще предмет для споров на сегодняшний день, но нельзя отрицать, что он предоставляет прекрасный набор инструментов для управления системой и поиска проблем. Представьте, что вам приходится иметь дело с проблемным сервером, который даже не загружается — в таком случае можно загрузиться с live-дистрибутива, смонтировать системный раздел и просмотреть логи systemd, чтобы понять, в чем проблема.

Компьютеры всегда были полем боя. Вечная битва взлома и защиты началась с появления первого массового ПК и будет продолжаться пока существует человечество. Первые хакеры были исследователями, они искали способы оптимизировать вычисления, найти более эффективные режимы работы, выжать максимум из скудных возможностей компьютеров. Тогда еще не было термина “хакер”, людей, которые занимались “взломом”, сейчас бы назвали системными программистами и программистами микроконтроллеров, до сих пор бьющихся за каждый лишний байт и пишущих на низком уровне.

Сложно сказать, когда развлечение стало злонамеренным, а потом корыстным. Первоначально, порча данных или железа не приводила к выгоде, потому написание вирусов — был удел одиночек, любителей в хорошем смысле слова, людей не ищущих выгоды.

Все изменила сеть…

Предпосылки возникновения EDR

Очень долго, компьютерные вирусы были чрезвычайно специфическими программами. Им приходилось выживать в очень стесненных условиях слабых компьютеров с ограниченными ресурсами, авторы вирусов были гуру Ассемблера, досконально знали все тонкости работы компьютеров на низком уровне. Но компьютеры становились мощнее, их связала сеть и все это запахло большими деньгами. Взлом был поставлен на поток, теперь это серьезный и крупный бизнес, уязвимости продают за огромные деньги, основной трафик компьютерных сетей — DDoS. Таким же крупным бизнесом стала и защита от атак. Прошли те времена, когда антивирусные программы покупались на дискетах и защищали только один компьютер. Даже сами понятия “вирус” и “антивирус” уже устаревают, целью атак становятся целые организации, а занимаются этим уже не одиночки-энтузиасты.

В предыдущей статье речь шла о SELinux. Моё впечатление об этой системе безопасности двоякое. С одной стороны безопасности в ИТ много не бывает, и SELinux содержит все необходимое для защиты ОС и приложений от несанкционированного доступа. С другой же стороны он выглядит чересчур громоздким и неоправданно сложным, что делает его применение непрактичным. Не раз и не два в руководствах пользователя по установке коммерческого ПО я видел рекомендации выполнить setenforce 0 перед началом установки.

Решение, обладающее половиной функционала SELinux, но гораздо более простое в настройке и эксплуатации, может быть более надежной защитой хотя бы в силу того, что не страшно вникать во все эти домены, политики и роли. Это как раз то, что предлагает AppArmor.

Так же, как и SELinux AppArmor является реализацией системы Mandatory Access Control (MAC), основанной на архитектуре Linux Security Modules (LSM). Модель безопасности Apparmor заключается в привязке атрибутов контроля доступа не к пользователям, а к программам. AppArmor обеспечивает изоляцию с помощью профилей, загружаемых в ядро, как правило, при загрузке.

AppArmor отличается от остальных реализаций MAC в Linux принципом действия на основе путей, еще он позволяет смешивать профили принудительного исполнения и режима предупреждений. Кроме того AppArmor использует вложенные файлы для облегчения разработки и имеет гораздо более пологий барьер для входа, чем тот же SELinux.

1. Используйте относительные пути в конфигурации

Не задавайте абсолютный путь в settings.py, это будет полезно, если вы будете в дальнейшем запускать проект из разных расположений, например при развертывании на другом веб-сервере, у которого пути будут другими. Используйте следующий код в settings.py если ваши шаблоны и статические файлы расположены внутри каталога проекта Django:

# settings.py
import os
PROJECT_DIR = os.path.dirname(__file__)
...
STATIC_DOC_ROOT = os.path.join(PROJECT_DIR, "static")
...
TEMPLATE_DIRS = (
    os.path.join(PROJECT_DIR, "templates"),
)

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

Сейчас есть много IM-мессенджеров с end-to-end шифрованием, но вариантов, которые можно быстро развернуть на своем сервере гораздо меньше.

Изучая варианты, мой взгляд упал на Delta Chat, о котором на Хабре уже упоминали — мессенджер без централизованной серверной инфраструктуры, использующий почтовые сервера для доставки сообщений, что позволяет развернуть его, например, на своем домашнем сервере и общаться с устройств, в том числе не имеющих доступ в интернет.

Среди преимуществ этого подхода можно отметить:

• Вы сами управляете своей информацией, в том числе ключами шифрования.
• Вы не отдаете свою адресную книгу никому.
• Нет необходимости использовать телефонный номер для регистрации.
• Наличие клиентов под все популярные системы: Windows, Linux, Android, MacOS, iPhone.
• Дополнительное шифрование STARTTLS/SSL при передаче сообщений, обеспечиваемое почтовым сервером.
• Возможность настроить удаление старых сообщений с устройства (исчезающие сообщения).
• Возможность настроить удаление сообщений с сервера, при получении.
• Быстрая доставка, благодаря IMAP push.
• Групповые защищенные чаты.
• Поддержка передачи файлов, фото и видео.
• Сервер и клиент относятся к открытому ПО и совершенно бесплатны.

Возможные недостатки:

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

Интересный факт: Роскомнадзор уже требовал от разработчиков Delta Chat предоставить доступ к пользовательским данным, ключам шифрования и зарегистрироваться в государственном реестре провайдеров, на что Delta Chat ответили отказом, т.к. не имеют собственных серверов и не имеют доступа к ключам шифрования.

Can I just once again state my love for [WireGuard] and hope it gets merged soon? Maybe the code isn't perfect, but I've skimmed it, and compared to the horrors that are OpenVPN and IPSec, it's a work of art.

Linus Torvalds, on the Linux Kernel Mailing List

Уверен, что многие уже слышали про Wireguard. Некоторые даже щупали вживую. Мне он вполне понравился в продакшене как по производительности, так и по простоте настройки. Да, там нет миллиона загадочных конфигураций на все случаи жизни как у OpenVPN и XFRM+StrongSwan в IPSEC VPN. Он прост и лаконичен как в коде, так и в конфигах. Жирным и неповоротливым он станет еще нескоро. Короче, такой позитивный вариант сценария «сжечь легаси и написать все как надо».

Я решил не писать очередной гайд «как я поставил Wireguard», а поделиться некоторыми полезными утилитами. Некоторые с очень удачным, на мой вкус GUI, что уместно для сервисов со множеством пользователей. Разберем использование этого VPN для связи между нодами в разных кластерах Kubernetes, несколько web-GUI для генерации и пару полезных ресурсов.

В одной из недавних статей нашего блога: “Безопасные телефоны, градация прослушек, и методы защиты”, было обсуждение общих принципов атак на сотовые телефоны. Теперь поговорим одном из конкретных векторов, а именно — взломе на основе уязвимости в протоколе: SS7. Так ли страшен черт, как его малюют?

Есть очень крутой комбайн для совместного ведения проектов, LDAP-авторизацией, синхронизацией файлов с версионированием и чем-то вроде корпоративного мессенджера с видеоконференциями, которые прикрутили в последних версиях. Да, я про Nextcloud. С одной стороны, я сторонник Unix-way и четкого дробления приложений по отдельным функциям. С другой — этот продукт более чем устойчив, работает много лет в нескольких проектах без особых проблем и дополнительные свистелки особо не мешают ему работать. Если очень хочется, то туда можно прикрутить практически любую дичь. Коммьюнити живое и вполне допиливает различные плагины, которые доступны как отдельные приложения.

Сегодня мы будем его разворачивать. Я не буду давать полной пошаговой инструкции, но постараюсь упомянуть про ключевые моменты архитектуры, на которые стоит обратить внимание. В частности, разберем балансировку нагрузки, репликацию БД и регламентное обслуживание без прерывания сервиса.

Деплоить будем в отказоустойчивом варианте для небольшой компании в 150-1000 пользователей, но для домашних пользователей тоже пригодится.

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

При этом разные события имеют различные временные требования. Например, требование к задержке для антиблокировочной тормозной системы может составлять от 3-5 миллисекунд. То есть с момента, когда колесо впервые обнаруживает, что оно скользит, у системы, управляющей антиблокировочными тормозами, есть от 3-5 миллисекунд, чтобы отреагировать и исправить ситуацию.

Возможности ядра в реальном времени существует уже более десяти лет в экосистеме программ с открытым исходным кодом. Столько же времени доступна поддержка Red Hat Enterprise Linux (RHEL) для ядра реального времени. Тем не менее многие системные администраторы неверно истолковывают его основные концепции и фактическое рабочее поведение. В этой статье я опишу некоторые из его основных функций, отличия от стандартного ядра и шаги по установке.

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

Информационная безопасность не является исключением, на этом поле боя идет многовековая битва, пусть и не такая шумная, как военные действия, но не менее ожесточенная. Расхожая байка о том, как Натан Ротшильд сделал состояние на основе исключительного доступа к информации, породила крылатую фразу: «Кто владеет информацией — тот владеет миром»..

Значимость информации может быть разной, подавляющее большинство не представляет никакого интереса для окружающих, они не могут извлечь из нее корысть или прибыль, но иногда хочется некоторой конфиденциальности. Не обязательно для того, чтобы скрыть противоправные действия или что-то неприличное: “У меня от государства секретов нет” — любимая фраза для троллинга на тему приватности, а просто потому, что существует частная жизнь и ее очевидное правило: “Это не ваше дело”. А, поскольку смартфон уже давно является неотъемлемой частью человеческой личности («В нем вся моя жизнь!!!11расрас» ), то защита его от посягательств — давно является одной из самых актуальных личных проблем. Это касается как доступа к информации на нем, так и телефонных разговоров. О современных способах защитить свою приватность и будет сегодняшняя статья.

Современный подход к информационной безопасности

Люблю ИБ. С одной стороны бизнес часто требует выкатывать полусырые прототипы, с деплоем раз в час. С другой — суровая и неприступная твердыня сотрудников информационной безопасности. На них все держится. И даже разработки в области IoT, где S — это security становятся еще надежнее под их присмотром.

Ключевая проблема оценки диаметра дырок технологических отверстий в вашем продукте — это время. Я хочу еще раз немного поговорить о классической пирамиде тестирования, но уже в разрезе информационной безопасности. А еще попробую поделиться опытом в организации построения удобного процесса, когда разработчики не ожидают неделями одобрения от ИБ, а ПО при этом не светится всеми возможными уязвимостями во внешний мир. Спойлер: можно выкатывать и без одобрения.

И список. Все любят списки. Отдам свой небольшой набор нужного ПО, который сильно скрашивает мои будни.