Серверное администрирование *

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

Сегодня мы рассмотрим, как закрыть или открыть порт в таких дистрибутивах Linux, как Ubuntu/Debian и CentOS/RHEL, используя файрволы ufw, firewalld и iptables. 

В статье мы будем использовать два дистрибутива Linux: Ubuntu версии 22.04 и CentOS 9 версии. Все команды из данной статьи будут работать на любых Debian-based- и RHEL-based-дистрибутивах, включая Astra Linux, AlmaLinux, Arch Linux и другие.

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

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

Меня зовут Дмитрий Литвиненко, я Data Scientist в IT-компании ProofTech IT, и в этой статье мы погрузимся в увлекательный мир причинности, рассматривая параллели между тем, как наш мозг устанавливает связи между событиями, и тем, как современные инструменты помогают в этом специалистам по мониторингу.

У пользователей в РФ возникли затруднения с доступом к YouTube. Причины известны, как и варианты решения. Однако это битва кота и мыши: ТСПУ эволюционируют, и популярные инструменты часто перестают работать.

Чуть надёжнее использовать свою инфраструктуру в зарубежном дата-центре. Так можно скачать контент с YouTube на свой сервер, а оттуда раздать трафик внутри РФ любым удобным способом без всяких «замедлений».

Получается что-то вроде зарубежного прокси для YouTube. И это совершенно легально (пока).

Привет! В этом посте мы расскажем про то, почему вообще выбрали именно Zabbix для мониторинга, для чего его используем, и как решились обновиться сразу с версии 4.4 до 6.0.

Около трёх лет у меня возникали проблемы с моим обучающим сайтом Mess With DNS: периодически у него заканчивалась память и он перезагружался по OOM.

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

Путь был сложным, и в процессе я многому научилась.

Многие компании не успевают оперативно устранять уязвимости. При этом время эксплуатации уязвимости после ее раскрытия сокращается. Существуют различные варианты попыток защиты\сокрытия сервисов от "любопытных глаз". Основные: использование нестандартного порта, fail2ban, ACL и tarpit (и их сочетание).
Есть ещё port knocking: как дополнительный фактор защиты - может снизить обнаружение сервиса, а не пытаться бороться с последствиями (брутфорс, эксплуатация), когда сервис уже обнаружен. Но, очень часто эта технология оказывается не используемой. Где-то из-за незнания технологии (хотя, статей хватает). Но, чаще из-за проблем на практике, которые мешают её внедрению:

‣ сложности использования технологией неподготовленным пользователям;
‣ фильтрация трафика (как на стороне клиента, так и сервиса);
‣ "раздувание" сгенерированных правил;
‣ несогласованность с другими отделами безопасности (трафик для port knocking может считаться зловредным).

Часто игнорирование port knocking приводит к тому, что задачи по безопасности пытаются решать другими технологиями. Что приводит к решениям, простота и эффективность которых вызывает вопросы. Усугубляется это частым отсутствием знаний в области наступательной безопасности: непониманием как атакующие могут обходить средства защиты. Я за годы работы пентестером и архитектором безопасности очень полюбил port knocking и нашёл варианты решить самые частые проблемы с его использованием. Ими и хочу поделиться.

Исходная задача: уменьшить количество несанкционированных обращений к сервису (в идеале - исключить полностью). При этом не мешая легитимным обращениям.

В статье обсудим:

‣ зачем (и как) пытаться убрать сервис из базы поисковиков (Censys, Shodan);
‣ использование нестандартного порта, fail2ban, ACL, tarpit и какие подходы используют атакующие для попытки обхода этих мер;
‣ варианты port knocking и практические проблемы их использования;
‣ "прозрачный" port knocking (не требующий от пользователей дополнительных действий, не подверженный фильтрафии трафика и согласующийся с сетевыми мерами безопасности);
‣ port knocking в docker контейнере: когда полезен и как его сделать;
‣ использование ipset для повышения эффективности port knocking;
‣ некоторые спорные практики защиты.

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

Под катом рассказываем во всех подробностях.

Встречайте! Вышла Grafana 11.3, являющая публике дашборды на основе библиотеки Scenes — а это основа того, каким мы видим будущее дашбордов Grafana.

Но и без этого Grafana изменилась весьма заметно! Улучшен пользовательский интерфейс, включая возможность вызывать API из любого элемента на холсте с помощью новой опции «Действия» во многих визуализациях. Также появились правила записи для управляемых Grafana алертов, и теперь все могут использовать Explore Logs, часть набора приложений Explore в Grafana, представленного на ObservabilityCON, который быстро и легко извлекает аналитику из ваших данных — без каких-либо сложных языков запросов.

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

В статье рассмотрим способ переноса системного раздела ОС Linux на другое блочное устройство и необходимые изменения в UEFI загрузчике.

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

Эта статья ориентирована на тех, кто только начинает заниматься администрированием и защитой Linux-серверов и планирует изучить базовые техники создания укреплённой линукс-среды, устойчивой к различным угрозам.

Недавно увидел рекламу от FirstVDS, что у них появились серверы в Нидерландах — стало интересно и захотелось протестировать предложение. Но чтобы было проще ориентироваться на местности, я также решил протестировать серверы нескольких других хостеров, которые также предоставляют свои услуги в Нидерландах. А их оказалось немало: это и привычные RUVDS с Timeweb, и не бывавшие ранее в моих тестах VPS1 и VDSKA. Под катом — несколько тестов на производительность и сравнение предложений между собой.

Я кратко познакомлю с инструментом шифрования age (кратко - потому что он простой в использовании - там просто нечего долго объяснять, при этом шифрует по современным стандартам шифрования). Мы научимся в одну простую команду шифровать как личные бэкапы, так и корпоративные (для нескольких асимметричных ключей, не храня ключ на сервере), а затем поспорим на тему того, почему openssl такой плохой инструмент и не пригоден для практического применения обычными пользователями/админами, чье представление о криптоалгоритмах примерно выражено на КДПВ.

Для опытного администратора очевидно, что аварии на главном сервере резервного копирования или на серверах хранения при отсутствии стратегии аварийного восстановления комплекса СРК могут привести к серьёзным последствиям, включая потерю ценных данных и простои в работе компании. И пока ИТ в России во многом — удел самоучек, поскольку гособразование строится только на базовых, причём устаревших понятиях, сисадминам приходится учиться на внештатных ситуациях прямо на работе. Сегодня пресейл-инженер Тринити СРК Михаил Старцев решил поделиться примером такой ситуации в учебных целях, а также рассказать о существующих стратегиях аварийного восстановления СРК. Эти стратегии — ключевой инструмент успешного функционирования критических ИТ-инфраструктур, а значит и подспорье в развитии карьеры специалистов ИТ-отделов на таких предприятиях.   

Так как я любитель selfhosted, у меня есть домашняя инфраструктура:

Orange Pi - медиасервер;

Synology - файлопомойка;

Neptune 4 - 3д принтер с веб интерфейсом и видео с камеры. И хотелось бы иметь безопасный доступ к ней снаружи через телефон и ПК, но при этом иметь выход в интернет не в РФ. Раньше для этих нужд я использовал OpenVPN, но теперь на него полагаться не стоит. Поэтому я начал изучать документацию к отличному инструменты от китайских товарищей - Xray!

Что понадобится:

Сервер с внешним IP с инфраструктурой. У меня - Orange Pi, далее - Bridge

Сервер, к которому хотим получить доступ - Server

Сервер вне РФ для выхода в интернет. Далее - Proxy

Клиент на ваш вкус. Далее - Client

Клиент и сервер на Linux - Xray-core, который можно поставить через оффициальный скрипт установки Xray

Клиент на андроид - v2rayNG

Еще клиенты можно найти в репозитории Xray-core

За базу берем файл конфигурации VLESS-TCP-XTLS-Vision-REALITY и начинаем читать документацию к Xray

Маршрутизация происходит на клиенте. Если клиент обращается к домену xray.com, например, то направляем траффик в Bridge, а для всех остальных соединений - в Proxy. Затем Bridge направляет траффик к Server, если клиент обращался к server.xray.com.
Выглядит так:

Первая часть посвящена серверной стороне облачного гейминга, вторая часть — клиентской, а третья RDP :)

Если у вас на машине стрелочка показывает, что у вас осталась половина бака, то у вас точно осталась половина бака? На самом деле больше, так как современные машины врут и топлива еще немного есть, даже когда стрелка на нуле - забота об альтернативно одаренных водителях. А если сервер показывает 50% cpu, то сколько ресурсов у нас осталось?

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