Настройка Linux *

Может ли ядро Linux при всей своей гибкости обеспечивать гарантированное время отклика при работе с приложениями?

Ядро Linux является универсальным и приспособлено к работе как с крошечными встраиваемыми устройствами, так и с титаническими серверами… а также со всем спектром машин между этими крайностями! Но может ли такое поразительно адаптивное ядро обеспечить гарантированную скорость отклика для приложения, работающего на всех этих платформах? Если в вашем приложении допустимая задержка при отклике укладывается в 200 микросекунд — то уверенно отвечаем на этот вопрос «да»! (Кстати, для Linux такая планка совсем не высока, но, чтобы её держать, потребуется тщательно подбирать аппаратное обеспечение и, возможно, обратиться за консультацией к специалисту по системам Linux, работающим в режиме реального времени).

Итак, почему же в приложении, работающем под Linux, иногда могут возникать задержки свыше 200 микросекунд? Универсальность ядра Linux требует сбалансировать пропускную способность, время отклика и честность распределения процессорной мощности, чтобы соответствовать требованиям такой универсальности. Если по одному из этих аспектов предъявляются жёсткие требования, то необходимо тонко настраивать как само ядро, так и поведение приложения. В этом посте рассмотрим 10 основных пунктов, которые необходимо учитывать при разработке системы Linux, к которой предъявляются строгие требования по работе в режиме реального времени. По каждому пункту также упомяну, в каком аспекте легко засыпаться разработчику-новичку, только приступающему к программированию систем реального времени под Linux.

Привет, Хабр! В современном мире сети растут крайне быстро, устройств становится всё больше, в связи с чем растёт и количество уязвимых мест. Ручной мониторинг открытых портов, сервисов и дыр в безопасности — схоже с поиском иглы в стоге сена, когда в кармане лежит магнит.

Чем полезна автоматизация и какие проблемы она решает:
— Время — сканирование сотен IP вручную может занять часы
— Человеческий фактор — пропустить критичный порт или уязвимость очень легко
— Регулярность — безопасность требует постоянного контроля и мониторинга, а не разовых проверок

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

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

Тем более что сейчас единственным слабым звеном в моём умном доме остается Яндекс Алиса — которая требует постоянного интернет‑соединения даже для выполнения простейших команд управления локальными устройствами.

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

Сегодня использование HTTPS стало практически обязательным для большинства веб‑приложений. Angie позволяет эффективно обрабатывать HTTPS‑трафик, обеспечивая при этом высокий уровень безопасности. В новых протоколах HTTP/2 и HTTP/3 использование защищённого соединения обязательно. Однако, как обычно, есть много деталей в конфигурации, которые мы последовательно разберём в этой статье.

Привет, Хабр! Давно я ничего не писал, но сегодня я хочу поделиться со всеми вами историей о сборке рабочего места на базе смартфона, мышки и клавиатуры на берегу Красного моря. В этой статье речь пойдет о непредвиденных обстоятельствах, российских технологиях (которые на удивление меня выручили), а также о смекалке, об удачном стечении обстоятельств, и о том, каким может стать будущее российских ИТ. Заинтриговал? Тогда давайте под кат, расскажу как все было!

Данная публикация - перевод серии статей от Pepe Berba - Hunting for Persistence in Linux.

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

Продолжаем разбираться в работе лайвпатчей для ядра Linux. В примере из первой части этой статьи мы загрузили лайвпатч и он каким-то магическим образом настроил все так, чтобы ядро Linux использовало не свою функцию nf_tproxy_laddr4(), а ее исправленный вариант.

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

В этой части статьи будет и несколько вопросов-заданий для читателя. Ответы и подсказки — в конце.

🧠 Что скрывается под капотом Synology NAS? Мы привыкли считать его удобным и простым решением «всё‑в-одном», но на самом деле это сложная система с десятками собственных слоёв, интерфейсов и оптимизаций. Рассмотрим его возможности!

Привет, Хабр! Давно хотел начать тему российских импортозамещающих аналогов доменной структуры от Windows. Да, от самих компаний были уже материалы: как настраивать, как «поднимать», а мне захотелось узнать историю этих систем и посмотреть, куда они движутся. Ну и первая на очереди — компания «Ред Софт» и система «Ред Адм».

Как появилась система управления рабочими машинами и серверами от «Ред софта», какие были open source наработки, как от них отказались и какими операционными системами можно управлять с помощью «Ред Адм» — об этом мы поговорили с директором разработки инфраструктурных решений «Ред Софт» Ильёй Чижовым и продукт-оунером Владом Цынским. Приятного чтения!

Сегодня компьютером на x86-совместимом процессоре едва ли можно кого-то удивить с гиковской точки зрения. Другое дело — обучающий ноутбук для детей, который работает на интересном и необычном ARM-процессоре от небезызвестной компании VIA. И хотя для запуска произвольных программ его необязательно было хакать — всем гикам известно, надо было ставить Linux!

К чему приводит давняя детская мечта об обучающем ноутбуке, что скрывается внутри устройства за 500 рублей и как на всё это накатить Linux с дуалбутом в родную систему — читайте в сегодняшней подробной статье!

Статья покажет простой rsync скрипт для инкрементального бекапа (с использованием хардлинков из предыдущего бекапа) и про использование btrfs сжатия в zstd.

В локальной сети используется локальный named для того, чтобы задать имена для локальных серверов. Все остальные запросы форвардятся на DNS-сервер провайдера и на сервер Гугля.
Ну, можно сказать, стандартная ситуация.

Но несколько дней назад внезапно некоторые внешние DNS-имена перестали ресолвится, вообще. При этом DNS-сервер от Гугля вообще перестал быть доступен.
Однако точно такой же named на удаленном сервере продолжал работать как обычно.

Простое сопоставление A и B как бы намекает, что у местного провайдера что-то сломалось.

-- Это ж-ж-ж неспроста! - сказала паранойя - надо что-то делать!

Если сервер у провайдера ломается, а сервер Гугля внезапно устаревает - надо решать проблему иначе.

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

Но как быть, если нужно устранить критические уязвимости или другие серьезные ошибки в ядре Linux? Об одном из способов сделать это без перезагрузки системы и пойдет речь в этой статье.

Меня зовут Евгений, я работаю в компании YADRO. Задачами, связанными с разработкой и анализом компонентов ядра Linux, я занимаюсь уже около 15 лет.

Я расскажу, что такое livepatching, как такая технология появилась и как она применяется. А также покажу на примере, как можно самому сделать лайвпатч, чтобы исправить реальный баг в ядре Ubuntu 22.04 Server.

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

В основном речь пойдет о системах с архитектурой x86 и RISC-V (хотя технология работает и для ARM64, PowerPC, s390x).

В статье вы найдете краткий обзор подсистемы регистрации событий - собственной разработки команды ОС Astra Linux.

Всё, что будет описано ниже, актуально для самой новой на момент написания статьи версии Astra Linux Special Edition - 1.8.2.

Поехали!

Пару месяцев назад я купил Nanoleaf Pegboard Desk Dock — последнее слово в технологиях USB-хабов с RGB-светодиодами и крючками для устройств. К сожалению, это чудо инженерной мысли поддерживает только гейминговые операционные системы — Windows и macOS, поэтому возникла необходимость в драйвере для Linux.

В своих постах я уже настраивал Windows VM с пробросом USB и пытался выполнить реверс-инжиниринг официальных драйверов. При этом я задумался, а нельзя ли написать производителю и попросить у него спецификации или документацию его протокола. К моему удивлению, техподдержка Nanoleaf ответила мне всего через четыре часа, предоставив полное описание протокола, используемого Desk Dock, а также полосами RGB-светодиодов. Документация по большей мере подтвердила то, что я обнаружил самостоятельно, но также я нашёл в ней пару других мелких подробностей (например, управление питанием и яркостью), которые были мне неизвестны.

Сегодня мы попробуем написать драйвер на основании протокола (который я изучил реверс-инжинирингом), параллельно сверяясь с официальной документацией. Однако здесь есть одна небольшая проблема: раньше я ни разу не писал драйверов для устройств под Linux, а с USB-устройствами взаимодействовал только как пользователь.

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

Можно создать в сети несколько VLAN и на точке доступа WiFi на каждую создать свой SSID (имя точки) и иметь несколько "виртуальных" WiFi точек с разными маршрутами и тоннелями.

Здесь мы рассмотрим настройку такой схемы с роутером на pfSense, точкой доступа на OpenWRT и отдельным линуксом для тоннеля в VM на Proxmox. Эти идеи можно использовать и в других комбинациях железа и софта.

Привет, Хабр!

Помните то блаженное время, когда для доступа к любому ресурсу хватало простого WireGuard до сервера в Германии? Я тоже помню. Но эта эпоха закончилась. Недавно я заметил, что мой верный VPN стал лагать, рвать соединение и вести себя так, будто его кто‑то целенаправленно «душит». Это был тот самый момент, когда я понял: игра изменилась. Системы глубокого анализа трафика (DPI) стали умнее, и мой трафик для них был как на ладони.

Это стало моим личным вызовом. Я отправился в путешествие по миру современных средств обхода блокировок, наступил на множество граблей (чего только стоит осознание, что «двойное шифрование» — это миф!), но в итоге нашел свое сокровище — рабочую и относительно устойчивую схему на базе VLESS+Reality и Multi‑hop.

Эта статья — не «серебряная пуля». Это честный, подробный и, надеюсь, полезный гайд по постройке сложной VPN‑цепочки. Мы разберем ее архитектуру, честно поговорим о рисках и соберем все по шагам.

Привет, Хабр!

В первой части нашего путешествия мы превратили голый VPS в маленькую крепость. Мы создали пользователя с sudo, настроили вход по SSH‑ключам, выставили на стражу файрвол UFW и наняли вышибалу Fail2ban. Теперь лобовые brute‑force атаки и автоматические сканеры разбиваются о наши стены, не доставляя хлопот. Мы победили, верно?

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

Здесь нам нужна «сигнализация». Система, которая станет нашими глазами и ушами, и поднимет тревогу при малейшем подозрительном движении. Сегодня мы установим именно такую — Maltrail.

Приветствую всех, кто заглянул на огонек! Меня зовут Роман, и я занимаюсь исследованием безопасности Linux (и всякого другого, связанного с ним) в экспертном центре безопасности в Positive Technologies.

Мне периодически приходится сталкиваться с вопросами клиентов или коллег из смежных отделов по поводу оптимизации работы различных компонентов журналирования внутри Linux. Поэтому в какой-то момент возникла идея обрисовать как минимум для самого себя целостную картину их взаимодействия и влияния друг на друга. Результатом работы стала довольно компактная схема, которая помогает оперативнее и эффективнее отвечать на возникающие вопросы для решения проблем. В статье я постараюсь вкратце описать каждый ее блок. Не ручаюсь за то, что будут затронуты все тонкости, известные лишь узкому кругу специалистов. Но на большую часть вопросов я отвечу.

Привет, Хабр! В данной статье хочу разобрать auditd - полезный инструмент аудита в Linux, который записывает каждое действие, а скрипт превратит логи в читаемые отчёты и алерты.

Linux-сервер без мониторинга активности пользователей — как дом с открытыми окнами. Проблемы, которые помогает решить auditd:

• Несанкционированный доступ (кто и когда использовать, например, sudo)
• Подозрительные команды (rm -rf, изменение прав, доступ к каким-либо файлам)
• Расследование инцидентов (кто что натыкал перед падением сервера)
• Соответствие корпоративным стандартам (возможно, ИБ требует логирования действий или вы любите контроль)

Решение: auditd + Python-скрипт для анализа и алертов.