@usr_bin_linux

Безопасность системы Linux: как предотвратить «плохие действия» других пользователей на общем сервере

2026-03-01T21:21:02.549Z

Это перевод оригинальной статьи Linux System Security: How To Prevent Others From Doing “Bad Things” on a Shared Server.

Подписывайтесь на телеграм-канал usr_bin, где я публикую много полезного по Linux, в том числе ссылки на статьи в этом блоге.

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

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

Понимание модели безопасности в Linux

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

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

Учитывая критическую важность безопасности ядра в Linux, стоит ли нам вкладывать значительные усилия в её защиту? На самом деле, подобно тому, как мы не слишком беспокоимся о деталях операционной системы при разработке приложений (особенно при использовании языков высокого уровня, таких как Java), нам не нужно уделять слишком много внимания безопасности ядра при рассмотрении безопасности Linux. Вместо этого следует сосредоточиться в первую очередь на безопасности пользовательского уровня. Для безопасности уровня ядра достаточно следовать рекомендациям по защите от известных уязвимостей, например, использовать официальные образы и регулярно их обновлять.

Поскольку большинство взаимодействий происходит на пользовательском уровне, давайте рассмотрим операции на этом уровне. В Linux все операции пользовательского уровня можно абстрагировать в следующий процесс: «Субъект -> Запрос -> Объект». Например, в операции «open /etc/passwd» субъект — это сам пользователь, запрос — операция чтения, а объект — файл /etc/passwd.

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

Как золотое правило применяется в системах Linux?

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

1. Механизмы аутентификации в Linux

Linux — многопользовательская операционная система, которая управляет и хранит пользовательскую информацию с помощью простых текстовых файлов. В этом контексте два важнейших файла: /etc/passwd и /etc/shadow.

В Linux файл /etc/passwd доступен для чтения всем пользователям и не хранит пароли напрямую из соображений безопасности. Вместо этого в поле пароля используется символ 'x' как заглушка. Информация о пароле пользователя хранится в файле /etc/shadow, доступном для чтения только пользователю ROOT.

Файл /etc/shadow содержит не только зашифрованные пароли, но и другие политики управления паролями, такие как количество дней, в течение которых пароль действителен, или количество дней до истечения срока действия пароля, по истечении которых должно быть выдано предупреждение. Мы можем изменить эти политики управления паролями с помощью команды chage. Например, следующая команда chage заставляет тестового пользователя менять пароль каждые 60 дней, тем самым снижая вероятность утечки пароля:

chage -M 60 test

Поскольку аутентификация — это функция, предоставляемая ядром Linux, проблема безопасности, на которой необходимо сосредоточиться на уровне пользователя, — это утечка идентификационной информации из-за слабых паролей. Для решения этой проблемы можно настроить соответствующие политики паролей в файле /etc/shadow. Кроме того, можно использовать такие инструменты, как John the Ripper, для обнаружения слабых паролей в Linux, используя известные базы данных слабых паролей. Следующая команда демонстрирует, как использовать John the Ripper для обнаружения слабых паролей:

unshadow /etc/passwd /etc/shadow > mypasswd
john mypasswd
john --show mypassw

2. Механизм авторизации в Linux

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

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

Помимо этих стандартных разрешений, Linux предоставляет дополнительные теги разрешений для более детального управления. Например, Linux предлагает атрибуты файлов для дополнительной защиты. Установив бит неизменяемости с помощью chattr +i /etc/passwd, вы можете запретить любому пользователю изменять файл. Подробнее об атрибутах файлов можно найти в Википедии.

Ещё одна функция Linux — это «sticky bit», который в первую очередь используется для предотвращения манипуляций пользователей с файлами других пользователей. Например, команда chmod +t /tmp может запретить пользователям удалять файлы в директории /tmp, принадлежащем другим пользователям.

Это механизмы самозащиты при авторизации Linux, но как мы можем активно обеспечить безопасность этого процесса?

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

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

Давайте рассмотрим одну из самых распространённых проблем безопасности в системах Linux: неправильное использование прав ROOT. Многие пользователи, входя в систему Linux, первым делом запускают команду su чтобы получить полноценную оболочку ROOT-пользователя. Таким образом, им не придётся каждый раз временно повышать привилегии до уровня ROOT с помощью команды sudo для выполнения каждой операции.

Однако следует отметить важный момент: в среде ROOT-оболочки все запущенные процессы также имеют привилегии ROOT. Если вы запустите быстровозвращающийся процесс, например, cat, это не создаст особых проблем. Но если это длительный процесс, это может легко привести к злоупотреблению привилегиями.

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

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

Принцип наименьших привилегий критически важен в системах Linux. Вы можете спросить: при таком количестве операций в Linux, для каждой из них нужна индивидуальная настройка прав доступа? К счастью, это не так. Мы часто используем известные инструменты для реализации принципа наименьших привилегий при запуске резидентных процессов, и ваша задача — правильно запустить или настроить эти инструменты.

Например, вы можете запустить службу MySQL, используя mysqld, которая выделяет процессы MySQL пользователю "mysql" и запускает демон под ROOT-аккаунтом. Вот как это выглядит на практике:

root     297353  0.0  0.0 115432  1360 ?        S    Aug12   0:00 /bin/sh /usr/local/mysql/bin/mysqld_safe --datadir=/var/lib/mysql --pid-file=/var/lib/mysql/mysql.pid
mysql    297553 31.3  4.3 11282756 5729572 ?    Sl   Aug12 22593:40 /usr/local/mysql/bin/m

Аналогично, при запуске Nginx, Nginx будет запускать рабочие процессы от имени пользователя «nobody». Конкретный эффект будет следующим:

root       7083  0.0  0.0  61032  5324 ?        Ss   Aug12   0:01 nginx: master process nginx
nobody   331122  0.0  0.0  90768 31776 ?        S    11:44   0:00 nginx: worker process
nobody   331123  0.0  0.0  90768 32720 ?        S    11:44   0:00 nginx: worker process
nobody   331124  0.0  0.0  90768 31776 ?        S    11:44   0:00 nginx: worker process

Конечно, некоторые инструменты не предоставляют возможности переключения на пользователя с минимальными привилегиями. Например, при запуске Redis напрямую с помощью redis-server, нам необходимо самостоятельно управлять переключением удостоверений пользователей. Итак, как же переключить удостоверения пользователей?

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

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

При запуске Redis с помощью redis-server мы можем использовать следующую команду для запуска redis-serverот имени пользователя «nobody» (при условии, что мы соответствующим образом настроили каталоги для журналов и PID, чтобы гарантировать возможность записи от имени пользователя «nobody»):

su -s /bin/redis-server nobody

Применяя принцип «наименьших привилегий», мы можем повысить безопасность авторизации системы Linux.

3. Механизм аудита в Linux

Как мы уже обсуждали ранее, аудит в контексте «золотых правил» в основном включает в себя ведение журнала и анализ. Итак, какие типы журналов существуют в системе Linux? В Linux информация системного журнала обычно хранится в каталоге /var/log, и некоторые приложения также регистрируют соответствующую информацию в этом каталоге. Системные журналы в основном делятся на три категории: журналы входа пользователей, журналы специальных событий и журналы процессов.

Журналы входа пользователей — это,в основном, файлы /var/log/wtmp и /var/run/utmp, в которых хранится информация, связанная с входами пользователей. Журналы входа пользователей представляют собой двоичные файлы и не могут быть просмотрены напрямую в текстовом формате, но к ним можно получить доступ с помощью таких команд, как who, users, ac, last и lastlog.

Журналы специальных событий включают в себя /var/log/secure и /var/log/message. В /var/log/secure в основном регистрируются записи, связанные с аутентификацией и авторизацией. Например, если кто-то попытается взломать SSH методом подбора пароля, этот журнал предоставит информацию о таких попытках. Файл /var/log/message поддерживается демоном syslogd, который предоставляет стандартный механизм записи специальных событий и сообщений. Другие приложения могут использовать этот демон для сообщения о специальных событиях.

Журналы процессов: Когда управление системными процессами выполняется с помощью accton, создается файл, называемый pacct, в котором записываются команды пользователя.

По умолчанию Linux использует logrotate для управления стратегиями хранения журналов (такими как ротация журналов и удаление старых журналов). Политики хранения для различных журналов можно изменить, настроив /etc/logrotate.conf.

Итак, как же нам отслеживать журналы? Я рекомендую два распространённых инструмента для анализа журналов: ELK и Zabbix. Эти инструменты можно использовать для мониторинга журналов безопасности Linux. Настроив соответствующие правила на этих аналитических платформах (например, обнаружение более трёх неудачных попыток входа по SSH), мы можем оперативно выявлять попытки вторжения со стороны хакеров и оперативно генерировать оповещения. Затем мы можем вручную проверять журналы для решения конкретных проблем.

Заключение

Безопасность систем Linux можно считать платформой с наилучшими практиками для принципа «минимальных привилегий», особенно когда несколько пользователей совместно используют и обслуживают один сервер. Правильная настройка прав доступа в таких ситуациях может быть довольно сложной. Для решения этой проблемы необходимо строго ограничить использование привилегий ROOT. Кроме того, реализация контроля доступа с помощью iptables также может обеспечить существенную защиту от уязвимостей процессов.

Помимо механизмов самозащиты системы Linux, существуют различные инструменты безопасности, обеспечивающие дополнительные уровни защиты (например, антивирусное ПО и системы обнаружения вторжений на уровне хоста).

На этом все! Спасибо за внимание! Если статья была интересна, подпишитесь на телеграм-канал usr_bin, где будет еще больше полезной информации.

Каждый баг, который я когда-либо исправлял, начинал иметь смысл только после того, как я понял эти 7 уровней

2026-03-01T21:12:56.156Z

Это перевод оригинальной статьи Every Bug I Ever Fixed Made Sense Only After I Understood These 7 Layers.

Спустя три года работы я потратил две недели на отладку причин, по которым наш API случайным образом возвращал ошибки 502. Логи были чистыми. Приложение работало исправно. Все указывало на то, что проблем нет.

Затем мимо проходил сетевой инженер и спросил: «А ты проверял, совпадает ли таймаут keepalive у балансировщика нагрузки с таймаутом сервера приложения?»

Изображение, сгенерированное искусственным интеллектом

Тогда меня осенило. Я занимался отладкой не на том уровне.

Семь уровней, которые действительно имеют значение

Модель OSI — это не какое-то академическое упражнение, которое нужно заучивать наизусть для собеседований. Это ментальная модель, которая позволяет не тратить дни, копаясь не там, где нужно.

Layer 7: Application    [HTTP, DNS, SSH]
Layer 6: Presentation   [TLS, Compression]
Layer 5: Session        [Auth, Connections]
Layer 4: Transport      [TCP, UDP]
Layer 3: Network        [IP, Routing]
Layer 2: Data Link      [Ethernet, MAC]
Layer 1: Physical       [Cables, Signals]

Вот что на самом деле происходит при обращении к API:

User Request
    |
    v
[Application Layer] - Parse HTTP request
    |
    v
[Transport Layer]   - Establish TCP connection
    |
    v
[Network Layer]     - Route packets via IP
    |
    v
[Data Link Layer]   - Frame data for physical transmission
    |
    v
[Physical Layer]    - Transmit bits over wire

Уровень 7: Прикладной уровень

Здесь работает большинство разработчиков. Коды состояния HTTP, ответы API, запросы к базе данных. Но вот чего они не говорят: большинство «ошибок в приложениях» на самом деле не являются ошибками приложения.

Реальная ошибка: Пользователи жаловались, что эндпоинт загрузки файлов «не работает». API возвращал 200 OK, но файлы не отображались.

// The problematic code
func uploadHandler(w http.ResponseWriter, r *http.Request) {
    file, _, err := r.FormFile("file")
    if err != nil {
        http.Error(w, err.Error(), http.StatusBadRequest)
        return
    }
    defer file.Close()
    
    // Processing happens here
    w.WriteHeader(http.StatusOK)
    json.NewEncoder(w).Encode(map[string]string{"status": "success"})
}

В чём проблема? Большие файлы (свыше 50 МБ) тихо отклонялись nginx ещё до того, как запрос доходил до приложения. Код 200 приходил от другого запроса, который успешно обработался.

Исправление находилось на три уровня ниже:

# /etc/nginx/nginx.conf
client_max_body_size 100M;

Уровень 4: Транспортный уровень

TCP против UDP. Таймауты соединения. Исчерпание портов. Этот уровень разрушил бесчисленное количество карьер.

Классический сценарий: приложение перестаёт отвечать под нагрузкой, но показатели процессора и памяти в норме.

# Check current connections
ss -s

# Output showing the problem
TCP: 28547 (estab 1034, closed 27500, orphaned 12, timewait 27488)

27 488 соединений находятся в состоянии TIME_WAIT. Ядру не хватило доступных портов.

// Before (bad) - Creates new connection every time
func fetchUsers(userIDs []string) error {
    for _, id := range userIDs {
        resp, err := http.Get(fmt.Sprintf("https://api.example.com/user/%s", id))
        if err != nil {
            return err
        }
        defer resp.Body.Close()
        // Process response
    }
    return nil
}

// After (good) - Reuses connections
var client = &http.Client{
    Timeout: 10 * time.Second,
    Transport: &http.Transport{
        MaxIdleConns:        100,
        MaxIdleConnsPerHost: 10,
        IdleConnTimeout:     90 * time.Second,
    },
}

func fetchUsers(userIDs []string) error {
    for _, id := range userIDs {
        resp, err := client.Get(fmt.Sprintf("https://api.example.com/user/%s", id))
        if err != nil {
            return err
        }
        defer resp.Body.Close()
        // Process response
    }
    return nil
}

Результаты теста производительности: использование пула соединений снизило время запроса с 340 мс до 12 мс под нагрузкой (1000 запросов).

Уровень 3: Сетевой уровень

Маршрутизация IP-адресов, маски подсети, разрешение DNS. Если ваш сервис не может связаться с другим сервисом, именно здесь следует искать причину.

# Trace the actual route packets take
traceroute api.internal.company.com

# Check if DNS is lying to you
nslookup api.internal.company.com

История из практики: соединения с базой данных периодически прерывались из-за таймаута. База данных работала исправно. Приложение работало исправно. Сетевая команда настаивала, что всё в порядке.

# This revealed the truth
mtr --report --report-cycles 100 db.internal.company.com

# Packet loss at hop 4: 23%

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

Уровень 2: Канальный уровень

MAC-адреса, коммутаторы, VLAN. Отладка здесь, вероятно, будет нечастой, но когда она всё-таки потребуется, всё остальное перестанет иметь значение.

В облачных средах это проявляется как «перегрузка сетевого интерфейса». Для экземпляра EC2 существует жесткое ограничение на количество пакетов в секунду, зависящее от типа экземпляра.

# Check interface stats
ip -s link show eth0

# Look for TX/RX errors or drops

Процесс отладки, который действительно работает

Перестаньте гадать. Начните мыслить уровнями.

1. Application logs clean?        -> Go down one layer
2. TCP connections normal?         -> Go down one layer  
3. Can you ping the destination?   -> Go down one layer
4. Is the cable plugged in?        -> Go outside and touch grass

Реальная сессия отладки:

# Layer 7: Application
curl https://api.example.com/health
# Returns 503

# Layer 4: Transport
telnet api.example.com 443
# Connection refused

# Layer 3: Network
ping api.example.com
# Host unreachable

# Layer 2: (Skipped in cloud)
# Resolution: DNS was returning wrong IP
nslookup api.example.com

# Pointed to decommissioned server

Паттерн, который вы увидите повсюду.

После того, как вы поймете, что такое уровни, вы начнете замечать их повсюду:

Сетевое взаимодействие в Kubernetes:

Взаимодействие между модулями: уровень 3 (IP)
Сервис для пода: Уровень 4 (TCP/UDP + порты)
Входящий трафик: Уровень 7 (маршрутизация HTTP)

Проблемы с балансировщиком нагрузки:

Connection refused: Уровень 4 (неверный порт/протокол)
502 Bad Gateway: Layer 7 (upstream timeout)
Connection timeout: Уровень 3 (маршрутизация/брандмауэр)

Что изменилось для меня

Я перестал говорить «сеть не работает» и начал спрашивать «на каком уровне произошла поломка?». Я перестал отлаживать систему интуитивно и начал отлаживать методом исключения.

Та ошибка 502, что была с самого начала? У балансировщика нагрузки (уровень 7) был keepalive 60 секунд. У сервера приложений (уровень 4) — 65 секунд. Когда балансировщик нагрузки закрывал соединение, приложение всё ещё считало, что оно открыто. Следующий запрос попадал в неактивный сокет.

// The fix
server := &http.Server{
    Addr:              ":8080",
    Handler:           router,
    ReadTimeout:       15 * time.Second,
    WriteTimeout:      15 * time.Second,
    IdleTimeout:       50 * time.Second, // Less than LB's 60s
    ReadHeaderTimeout: 5 * time.Second,
}

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

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

Инструменты DevOps с открытым исходным кодом, о которых я хотел бы узнать раньше.

2026-03-01T21:06:21.392Z

Это перевод оригинальной статьи Open-Source DevOps Tools I Wish I Knew About Sooner.

Когда я только начинал работать в DevOps, я думал, что всё должно быть дорогим.
Мониторинг? Платный. CI/CD? Платный. Логирование? Платное.
Даже такие простые вещи, как проверка доступности, стоили денег.

Мне потребовалось несколько болезненных счетов, чтобы осознать одну вещь:

Практически у каждого крупного DevOps-инструмента есть open-source альтернатива, и многие из них на самом деле лучше.

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

1. Portainer → Графический интерфейс Docker, о необходимости которого я даже не подозревал.

https://www.portinaer.io/

Ссылка: https://www.portinaer.io/

Раньше я управлял Docker исключительно с помощью командной строки.
Всё было хорошо… пока у меня не появились десятки контейнеров, стеков, сетей и томов.

Portainer предоставляет вам:

Визуальная панель мониторинга
Логи и статистика контейнеров
Развертывание в один клик
Шаблоны стека
Контроль доступа пользователей

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

2. Jenkins→ Моя первая настоящая свобода в области CI/CD

https://www.jenkins.io/

Ссылка: https://www.jenkins.io/

До появления Jenkins я в значительной степени полагался на SaaS-инструменты для непрерывной интеграции.
Они удобны, но бесплатные ограничения просто ужасны.

Jenkins предоставляет:

Неограниченное количество пайплайнов
Кастомные агенты
Огромная экосистема плагинов
Полный контроль над сборкой.

Однажды я собрал пайплайн, который:

Запускал тесты
Генерировал Docker-образы
Деплоил в Kubernetes
Отправлял уведомления в Slack

Всё работает на сервере за 10 долларов. Никаких ограничений. Никаких неожиданностей.

3. Prometheus + Grafana → Замена облачного мониторинга

Ссылки:
Prometheus: https://prometheus.io/
Grafana: https://grafana.com/

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

Prometheus обрабатывает метрики.
Grafana великолепно их визуализирует.

Где это меня выручило:
я развернул их в кластере Kubernetes — и внезапно у меня появилось:

Панели мониторинга ЦП/памяти
Графики состояния Pod’ов
Пользовательские оповещения
Метрики производительности узлов

И всё это бесплатно.

4. Alertmanager → Оповещения без оплаты

https://prometheus.io/

Ссылка: https://prometheus.io/docs/alerting/latest/alertmanager/

Уведомления по электронной почте… бесплатно.
Уведомления в Slack… бесплатно.
Уведомления Webhook… бесплатно.

До того, как я открыл для себя Alertmanager, я полагался на платные инструменты только для получения уведомлений.

После настройки с помощью Prometheus я смог:

Получать оповещения о перезапуске подов.
Отслеживать высокую загрузку ЦП.
Выявлять сбои при развертывании

Никакого спама в SMS-сообщениях/уведомлениях, никаких скрытых платежей.

5. Loki → Инструмент логирования, который следовало использовать с самого первого дня.

https://grafana.com/oss/loki/

Ссылка: https://grafana.com/oss/loki/

Раньше я перенаправлял логи в случайные папки и “cat”-ил их как пещерный человек.
Потом появился Loki — инструмент агрегации логов с открытым исходным кодом от Grafana.

Это как Elasticsearch, но легче и проще в использовании.

Где это помогло:
Логи срабатывали на:

Циклических сбоях Node.js
Ошибки подключения к базе данных
Неожиданные ошибки 500

И всё это можно было искать в одном дашборде.

6. Argo CD → GitOps: правильный подход

https://argo-cd.readthedocs.io/

Ссылка: https://argo-cd.readthedocs.io/

Если вы работаете с Kubernetes, Argo CD кажется почти волшебным инструментом.

Он за вашим Git-репозиторием и автоматически синхронизирует ваш кластер с манифестами.

Значение:

Нет необходимости вручную выполнять kubectl apply
Автоматический откат
мониторинг состояния приложения
развертывание с контролем версий

После того, как я настроил его в среде микросервисов, развертывание стало выглядеть следующим образом:

git push

Вот и всё. Argo позаботился обо всём остальном.

7. Traefik → Обратный прокси, который наконец-то стал понятным.

https://traefik.io/

Ссылка: https://traefik.io/

Конфигурации NGINX заставили меня возненавидеть жизнь.
А потом я открыл для себя Traefik.

Traefik автоматически:

Обнаруживает контейнеры
Генерирует правила маршрутизации
Выдает SSL-сертификаты
Управляет балансировкой нагрузки

Пример:
я развернул несколько микросервисов с метками Docker, и Traefik мгновенно их обнаружил с действительным HTTPS-соединением — без необходимости вручную настраивать файлы конфигурации.

8. MinIO → Open-Source хранилище S3

(Бесплатное использование прекращено, но исходный код доступен по ссылке : https://github.com/minio/minio )

Ссылка: https://min.io/

AWS S3 — отличный сервис, но не всегда дешевый.

MinIO предоставляет вам:

Объектное хранилище
S3-совместимые API
Высокую производительность
Свободу самостоятельного хостинга

Я использовал его для хранения:

Логов
Резервных копий
Медиафайлов
Ресурсов приложений

С тех пор я использую MinIO для локальной разработки, тестовых окружений и даже некоторых производственных задач.

9. K9s → Терминальный интерфейс для Kubernetes

https://k9scli.io/

Ссылка: https://k9scli.io/

kubectl — мощный… но иногда мучительный.

K9s предоставляет вам интерактивную панель управления терминала:

Pods
Логи
Доступ к оболочке
События
Развертывания

Это как «htop», но для вашего кластера.

Я использую его ежедневно — он значительно ускоряет отладку.

10. Gitea → Самостоятельно размещаемая альтернатива GitHub

Ссылка: https://about.gitea.com/

Для небольших команд и внутренних репозиториев GitHub может быть излишним.

Gitea предоставляет вам:

Git-хостинг
Issues (задачи)
Запросы на слияние
интеграции CI
Использование серверов с минимальными затратами ресурсов

Я настроил её для внутреннего корпоративного проекта, и разработчики оценили, насколько быстро и удобно всё работает.

Заключительные мысли

DevOps не обязательно должен быть дорогим.
Для большинства инструментов, которые профессионалы используют ежедневно, уже существуют мощные версии с открытым исходным кодом.

А самое главное?

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

Если вы прокачиваете навыки DevOps или модернизируете стек, начните с этих инструментов.
Они сэкономят вам деньги — и сделают вас лучшим инженером.

Лайфхаки по написанию скриптов на Bash, которые должен знать каждый разработчик

2026-03-01T21:04:23.373Z

Это перевод оригинальной статьи Bash Scripting Hacks Every Developer Should Know.

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

Введение: Bash — это навык, который вы, сами того не зная, игнорировали.

Большинство разработчиков «знают» Bash так же, как и Git: ровно столько, чтобы справляться. Несколько команд в памяти. Скрипт скопирован со Stack Overflow. Молитва перед нажатием Enter.

Но Bash — это не просто язык программирования для энтузиастов Linux или специалистов по DevOps. Это невидимая сила, стоящая за автоматизацией, отладкой, деплоями, обработкой данных и бесчисленным количеством повседневных задач. Разница между медленным разработчиком и пугающе эффективным часто сводится к тому, насколько хорошо он владеет shell’ом.

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

Давайте прокачаем вашу интуицию.

1. Всегда запускайте скрипты в «строгом режиме».

Большинство скриптов Bash завершаются с ошибкой без предупреждения. Это опасно.

Первый полезный совет, который должен знать каждый разработчик, — это включение строгого режима в начале скриптов:

set -euo pipefail

Вот что делает эта единственная строка:

-e: В случае сбоя команды немедленно завершить работу.
-u: Cчитает необъявленные переменные ошибкой
-o pipefail: пайплайн считается упавшим, если любая команда завершилась с ошибкой.

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

Считайте это превращением runtime-ошибок в compile-time-ошибки для Bash.

2. Используйте `"$@"` вместо `$*` (Да, это важно)

Если ваш скрипт принимает аргументы, эта деталь может сэкономить вам часы отладки.

Всегда используйте:

"$@"

Вместо:

$*

Почему? Потому что "$@" сохраняет границы аргументов. Пробелы остаются неизменными. Имена файлов не распадаются на части. Ваш скрипт работает корректно, когда пользователи передают строки в кавычках.

Это одно из тех правил Bash, которое кажется излишне педантичным — пока из-за них не ломается что-то важное в продакшене.

3. Давайте своим переменным точные имена

В Bash нет типов, но имена — это ваша система безопасности.

Плохо:

x=10
y="file.txt"

Лучше:

MAX_RETRIES=10
INPUT_FILE="file.txt"

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

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

4. Используйте `$(...)` вместо обратных кавычек.

Если вы всё ещё используете обратные кавычки, пора от них отказаться.

Старый вариант:

files=`ls`

Современный вариант:

files=$(ls)

Замена команд с помощью $(...) выглядит следующим образом:

Легче читать
Легче вкладывается
Менее подвержен ошибкам

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

5. Быстро выявляйте ошибки с помощью явных сообщений об ошибках.

Если что-то пошло не так, в вашем скрипте должно быть указано, почему.

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

command || {
  echo "❌ Failed to run command"
  exit 1
}

А ещё лучше — оберните это в функцию:

die() {
  echo "Error: $1" >&2
  exit 1
}

Теперь ваши скрипты не просто терпят неудачу — они умеют доносить информацию. И вы в будущем поблагодарите себя в настоящем за эту ясность.

6. Используйте функции (даже в небольших скриптах).

Многие разработчики избегают использования функций в Bash, считая их излишними.

Нет.

Функции позволяют вам:

Избегать дублирования
Инкапсулировать логику
Сделать скрипты читаемыми от начала до конца.

Пример:

cleanup() {
  rm -rf /tmp/my_app
}

Вам не нужен объектно-ориентированный Bash. Вам нужна лишь структура. Функции — это самый простой способ добиться успеха.

7. Перехватывайте сигналы как профессионал

Случалось ли вам когда-нибудь сталкиваться с тем, что скрипт оставляет незавершенные файлы после нажатия Ctrl+C?

Это потому, что вы не перехватили сигналы.

trap cleanup EXIT INT TERM

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

Ловушки необходимы для:

Временных файлов
Файлов блокировки
Фоновых процессов

Они превращают сценарии, в которых "надеемся, ничего не пойдет не так", в сценарии, в которых "готовы к хаосу".

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

В Bash не заключенные в кавычки переменные — это мины замедленного действия.

Плохой:

rm $file

Хороший:

rm "$file"

Если переменная $file содержит пробелы, символы шаблона или пуста, отсутствие кавычек может привести к потере данных.

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

Одна эта привычка предотвращает одни из самых страшных shell-багов, каких только можно себе представить.

9. Используйте массивы вместо строк, разделённых пробелами.

Bash поддерживает массивы. Используйте их.

Вместо:

files="a.txt b.txt c.txt"

Сделайте следующее:

files=("a.txt" "b.txt" "c.txt")

Массивы сохраняют структуру, безопасно работают с пробелами и ведут себя предсказуемо.

Циклы становятся безопаснее:

for file in "${files[@]}"; do
  echo "$file"
done

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

10. Читайте файлы построчно правильно.

Это классическая ловушка.

Неправильно:

for line in $(cat file.txt); do

Верно:

while IFS= read -r line; do
  echo "$line"
done < file.txt

Правильный подход:

Сохраняет пробелы
Не зависает при работе со специальными символами.
Эффективно работает с большими файлами

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

11. Используйте `set -x` для тонкой отладки

Когда скрипт работает некорректно, догадки не помогут.

Включить трассировку выполнения:

set -x

Bash выводит каждую команду перед её выполнением. Это бесценно для:

Падений в CI
Неожиданных значений переменных
Логических ошибок

Вы даже можете включить его временно:

set -x
# debug section
set +x

Это встроенный отладчик Bash. Используйте его.

12. Предпочитайте [[ ... ]] вместо [ ... ]

Тестовые выражения старого образца ненадежны.

Используйте:

if [[ "$a" == "$b" ]]; then

Вместо:

if [ "$a" = "$b" ]; then

Почему?

Без разделения слов
Более безопасное сравнение строк
Поддержка регулярных выражений
Меньше проблем с кавычками

[[ ... ]] — это одно из лучших улучшений Bash. Воспользуйтесь им.

13. Используйте Here-Docs для корректного многострочного ввода.

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

Here-docs это исправляет:

cat <<EOF > config.yaml
port: 8080
env: production
EOF

Они идеально подходят для:

Шаблонов
Docker-конфигураций
Встроенной документации

Читаемый Bash — это поддерживаемый Bash.

14. Делайте скрипты самодокументируемыми

Добавьте --help флаг.

Серьезно.

if [[ "$1" == "--help" ]]; then
  echo "Usage: script.sh [options]"
  exit 0
fi

Даже короткое описание использования резко повышает удобство — для коллег и для вас из будущего.

Профессиональные скрипты объясняют себя сами.

15. Относитесь к скриптам Bash как к настоящему программному обеспечению.

Это самый главный хак.

Большинство скриптов Bash не работают не потому, что Bash плох, а потому, что мы относимся к скриптам как к одноразовому коду.

Сделайте следующее:

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

Bash поощряет дисциплину. Игнорируйте её, и он даст отпор.

Вывод: Bash — это инструмент, многократно увеличивающий эффективность.

Bash-скриптинг — это не про то, чтобы стать рок-звездой терминала. Bash-скриптинг — это про то, чтобы сделать вашу рабочую жизнь проще. Отправка сообщения в Slack. Загрузка случайной шутки в ваши сообщения. Поиск случайной картинки для добавления в ваши сообщения.

Вам не обязательно быть экспертом во всех аспектах Bash. Всё, что вам нужно, — это несколько полезных навыков и уверенность в их применении.

Терминал — это место, где выполняются команды, но именно там сосредоточено влияние.

Если вы достаточно хорошо освоите программирование на Bash, ваш компьютер начнет работать на вас, а не наоборот.

Шпаргалка по SSH

2026-03-01T20:57:17.546Z

Это перевод оригинальной статьи SSH Cheat Sheet.

Практическое, удобное для копирования и вставки руководство по SSH для инженеров Linux, системных администраторов, администраторов баз данных и SRE-специалистов.

Часть 1 — Основы SSH (для всех)

Основные принципы использования SSH

ssh user@server_ip

Подключитесь к удалённому серверу, используя стандартный порт 22.

ssh hostname

Используются параметры из ~/.ssh/config, если они определены.

SSH с пользовательским портом и пользователем

ssh -p 2222 user@server_ip

Укажите нестандартный порт SSH.

ssh user@hostname

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

Аутентификация по SSH-ключу

Сгенерируйте SSH-ключ

ssh-keygen -t ed25519

Скопируйте открытый ключ на сервер.

ssh-copy-id user@server_ip-copy-id user@server_ip

После этого ввод пароля при подключении больше не требуется.

Советы по работе с конфигурационными файлами SSH (настоятельно рекомендуется)

Редактировать конфигурацию:

nano ~/.ssh/config

Пример:

Host prod-db
  HostName 10.10.10.20
  User postgres
  Port 22
  IdentityFile ~/.ssh/id_ed25519

Подключение:

ssh prod-db

# Cleaner
# Faster
# Less mistakes

SSH-туннелирование и переадресация портов

Локальная переадресация портов

ssh -L 5432:localhost:5432 user@server_ip

Получите доступ к удаленной базе данных PostgreSQL так, будто он запущен локально.

Удалённая переадресация портов

ssh -R 9000:localhost:3000 user@server_ip

Предоставьте удаленному компьютеру доступ к локальному сервису.

Динамическая переадресация портов (SOCKS-прокси)

ssh -D 8080 user@server_ip

Полезно для безопасного просмотра веб-страниц и настройки прокси-серверов.

Копирование файлов с помощью SCP и RSYNC

Копирование файла на удаленный сервер

scp file.txt user@server_ip:/path/

Копирование директории

scp -r mydir user@server_ip:/path/

Более быстрый и надёжный способ (рекомендуется)

rsync -avz file.txt user@server_ip:/path/

Отладка SSH-подключений

ssh -v user@server_ip

Ещё больше деталей:

ssh -vvv user@server_ip

Проверьте, какой ключ используется:

ssh -i ~/.ssh/mykey user@server_ip

Лучшие практики безопасности

Отключить аутентификацию по паролю
Использовать SSH-ключи
Сменить стандартный порт
Использовать Fail2Ban
Ограничить доступ пользователей черезAllowUsers

Пример (sshd_config):

PasswordAuthentication no
PermitRootLogin no

Перезапустите SSH:

sudo systemctl restart sshd

Часть 2 — Объяснение параметров SSH (от новичка до продвинутого)

В этом разделе простыми словами объясняются параметры командной строки SSH. Для понимания этой части вам не потребуются предварительные знания SSH.

Напоминание о базовом синтаксисе

ssh [options] user@host

user → имя пользователя удаленного Linux
host → IP-адрес или имя хоста сервера
options → параметры поведения SSH (что мы объясним ниже)

Основные и наиболее часто используемые опции (необходимо знать)

`-p` → Порт

ssh -p 2222 user@server

Подключение к пользовательскому SSH-порту.
Порт SSH по умолчанию = 22.
Часто меняется из соображений безопасности

Представьте, что порт — это номер двери на сервере.

`-l` → Имя пользователя

ssh -l postgres server_ip

Указывает, от имени какого пользователя следует войти в систему. То
же самое, что и:

ssh postgres@server_ip

`-i` → Файл идентификации (SSH-ключ)

ssh -i ~/.ssh/id_ed25519 user@server

Указывает SSH, какой закрытый ключ использовать.
Полезно, когда у вас несколько ключей SSH.

`-v`, `-vv`, `-vvv` → Подробный режим / Режим отладки

ssh -v user@server

Отображает этапы подключения.
Помогает отлаживать:

проблемы аутентификации
неправильные ключи
сетевые ошибки

Чем больше v, тем больше деталей.

`-F` → Пользовательский файл конфигурации

ssh -F myconfig user@server

Используйте нестандартный файл конфигурации SSH.
По умолчанию используется:

~/.ssh/config

Параметры аутентификации и безопасности

`-o` → Пользовательская опция SSH

ssh -o StrictHostKeyChecking=no user@server

Передайте любые расширенные настройки SSH вручную.
Эквивалентно параметрам из ssh_config

Частые примеры:

-o PasswordAuthentication=no
-o ConnectTimeout=5

`-A` → Переадресация агента SSH

ssh -A user@server

Переадресация локальных SSH-ключей на удаленный сервер.
Используется для промежуточных серверов.

Использовать с осторожностью (риск безопасности на ненадежных серверах).

`-a` → Отключить переадресацию агента

ssh -a user@server

Более безопасный вариант по умолчанию:
Явно отключает переадресацию ключей.

`-K` → Аутентификация GSSAPI

ssh -K user@server

Используется в средах Kerberos / корпоративных средах.

Переадресация и туннелирование

`-L` → Переадресация локальных портов

ssh -L 5432:localhost:5432 user@server

Доступ к удалённому сервису локально.
Очень распространён в:

PostgreSQL
MySQL
Веб-приложения

`-R` → Удалённая переадресация портов

ssh -R 8080:localhost:3000 user@server

Предоставить удалённому серверу доступ к локальному сервису

`-D` → Динамическая переадресация портов (SOCKS-прокси)

ssh -D 1080 user@server

Создает SOCKS-прокси.
Используется для:

безопасного просмотр
туннелирования трафика

`-W` → Переадресация стандартного ввода/вывода

ssh -W host:port user@server

В основном используется с ProxyJump.

Jump-хосты и несколько серверов

`-J` → Jump Host (Bastion Server)

ssh -J user@jumpserver user@target

Подключение через другой сервер.
Современная альтернатива сложным туннелям.

Управление сессией

`-N` → без выполнения команд

ssh -N -L 5432:localhost:5432 user@server

Только открытый туннель.
Доступ к оболочке запрещен.

`-T` → Отключить псевдо-TTY

ssh -T user@server

Используется в скриптах.
Нет интерактивного терминала.

`-t` → Принудительно включить TTY

ssh -t user@server "sudo systemctl restart postgresql"

Необходимо для sudo.

Фон и управление

`-f` → Фоновый режим

ssh -f -N -L 5432:localhost:5432 user@server

Запуск SSH в фоновом режиме.
Идеально подходит для туннелей.

`-S` → control socket

ssh -S /tmp/ssh.sock user@server

Используется при совместным использованием соединений.

`-O` → Команды управления

ssh -O exit user@server

Управление существующим SSH-соединением

Шифрование и алгоритмы

`-c` → Шифр

ssh -c aes256-gcm@openssh.com user@server

Выберите алгоритм шифрования

`-m` → MAC-алгоритм

ssh -m hmac-sha2-256 user@server

алгоритм аутентификации сообщений

`-Q` → Запрос поддерживаемых алгоритмов

ssh -Q cipher
ssh -Q mac

Выводит список поддерживаемых алгоритмов.

Параметры сетевого уровня

`-B` → Привязка к сетевому интерфейсу

ssh -B eth0 user@server

Принудительно направляет SSH-трафик через указанный сетевой интерфейс.

`-b` → Исходный адрес

ssh -b 192.168.1.10 user@server

Использует конкретный локальный IP-адрес в качестве источника соединения.

Золотое правило (совет для новичков)

Если команда SSH кажется длинной или пугающей, перенесите её в ~/.ssh/config и упростите себе жизнь.

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

Как разобраться c сетевыми настройками Linux, не читая 500-страничную книгу

2026-03-01T20:49:49.177Z

Это перевод оригинальной статьи Understanding Linux Networking Without Reading a 500-Page Book.

Раньше я замирал, как только слышал: «Проблема с сетью».
Процессор? Диск? Хорошо. Но когда я слышал: «Сеть», мой мозг отключался, а сердцебиение учащалось.

Этот страх вполне обоснован. Сетевые возможности Linux — это то, что большинство из нас делает вид, что знает… до тех пор, пока не сталкивается с реальной проблемой…

Единственная реальная проблема, о которой никто не говорит

Проблема не в том, что работа с сетями в Linux сложна. Проблема в том, что мы пытаемся изучать её как теоретический материал. OSI-слои. Диаграммы. Стрелки. Замысловатые термины. Но когда сервер не может подключиться к интернету, ничто из этого не помогает. Я усвоил это после множества ошибок.

Моя первая сетевая ошибка

Я был новичком, не очень опытным. У меня были хорошие знания Linux, но сети — это то, чего я боялся. В любом случае это была новая работа, и я обрёл уверенность. В тот день приложение выдало сообщение: «Сервер не может подключиться к базе данных».

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

Сервис работает
Firewall «выглядит нормально»
Перезапустил сетевой сервис (большая ошибка).

Сеть не восстановилась. SSH пропал.
Я в панике позвонил сеньору, рассказал обо всем, и он поспешил в офис. Через 10 минут сеньор посмотрел на меня и задал один простой вопрос:

«Вы вообще проверяли маршрут?»

Я этого не делал.

В тот день я понял важную вещь:
Нетворкинг — это не теория. Это поток.

Сначала разрушим это распространённое заблуждение.
«Если есть IP-протокол, то сеть работает нормально».
«Пинг работает, значит, всё работает».
«Это проблема с брандмауэром».
Нет. Прекратите так думать.

Сеть ломается в реальности, а не в учебниках.

Как я теперь понимаю Linux-сеть

Никаких книг на 500 страниц. Никаких диаграмм на стене.
Только пять проверок, всегда в таком порядке.

Начните с интерфейса (а не с Google).

ip addr show

Задайте себе вопрос:

Интерфейс активен?
У него правильный IP-адрес?
Это тот интерфейс, который вы себе представляете?

Однажды я потратил 30 минут на отладку eth0.
А реальный трафик шёл через ens192.

Урок усвоен.

Проверьте маршрут

ip route

Большинство проблем скрывается здесь.

Нет default route?
Неправильный gateway?
Несколько маршрутов конфликтуют друг с другом?

Если Linux не знает, куда отправлять пакеты, то неважно, насколько вы умны.

Не стоит слепо доверять пингу.

Да, пинг полезен.
Но ложные ответы случаются часто.

ping -c 3 8.8.8.8

Если работает:

IP-маршрутизация работает

Если это не поможет:

Перестаньте винить DNS
Перестаньте трогать firewall
Сначала исправьте маршрутизацию.

DNS — это скучно… пока он всё не ломает.

cat /etc/resolv.conf

Однажды я увидел:

nameserver 127.0.0.1

Служба DNS не запущена.

Проверка простая, эффект огромный.

Проверьте это:

nslookup google.com

Если IP-адреса работают, а имена — нет, добро пожаловать в ад DNS.

Только теперь смотрите фаервол (в последнюю очередь, не в первую).

iptables -L -n
# or
firewall-cmd --list-all

Чаще всего в первую очередь винят брандмауэр.
На самом деле он чаще всего оказывается последним в списке причин. Если маршрут настроен неправильно — брандмауэр ни при чём.

Что сеньоры делают иначе

Они мысленно отслеживают путь пакета.

Интерфейс → Маршрут → Gateway → DNS → Firewall

Каждый. Раз.

Почему это меня зацепило

Я перестал пытаться изучить сеть. Я начал следить за трафиком. Пакеты не интересуются вашими сертификатами. Им важна только правильная направленность.

Для Linux-администраторов в 2026 году

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

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

Я до сих пор не всё знаю о сетях, но теперь, по крайней мере, я их не боюсь. И это всё меняет.

Практическое руководство по IPTABLES: правила, примеры и лучшие практики безопасности

2026-03-01T20:45:00.627Z

Это перевод оригинальной статьи Linux IPTABLES Firewall Practical Guide: Rules, Examples & Security Best Practices (Linux Firewall).

Брандмауэр на уровне ядра с объяснением правил, кейсов и шпаргалкой для админов

📖 Что такое IPTables?

IPTables — это брандмауэр на уровне ядра в Linux, построенный на фреймворке Netfilter. Он фильтрует, модифицирует, разрешает или блокирует сетевой трафик на уровне ОС, что делает его одним из самых мощных и гибких инструментов для защиты Linux.

⚠️ Примечание: IPTables — это программный брандмауэр, а не аппаратный (хотя он выполняет аналогичные функции безопасности).

🎯 Какую проблему решает IPTables?

Без брандмауэра:

Любой хост может получить доступ к вашему серверу.
Сервисы открыты в интернет
Системы уязвимы к brute-force и DoS-атакам.
Отсутствует контроль над входящим/исходящим трафиком.

IPTables позволяет:

Блокировать неавторизованный доступ
Контролировать порты входящего и исходящего трафика
Предотвращать подмену IP-адреса
Защищать от DoS-атак
Обеспечивать безопасность Linux-серверов (физических, виртуальных, облачных)

🧠 Основные понятия (важно для администраторов и DevOps)

Основы работы с IPTables

iptables → Команда / утилита / инструмент
Rules → Хранятся в оперативной памяти (временно, если не сохранены).
Chains → INPUT, OUTPUT, FORWARD
Tables → filter, nat, mangle, raw
Targets → ACCEPT, DROP, REJECT, LOG, DNAT, SNAT

📦 Проверка установки и состояния IPTables

rpm -qa | grep -i iptables
/etc/init.d/iptables status
which iptables

🧩 IPTables работает на 3-4 уровнях модели OSI

Сетевой уровень (уровень 3) — IP
Транспортный уровень (уровень 4) — TCP / UDP / ICMP

🔗 Таблицы IPTables

1️⃣ filter (по умолчанию)

INPUT → Входящий трафик
OUTPUT → Исходящий трафик
FORWARD → Маршрутизированный трафик

2️⃣ nat

PREROUTING → Переадресация портов (DNAT)
POSTROUTING → SNAT / MASQUERADE
OUTPUT → Локальный NAT

3️⃣ mangle

Модификация заголовков пакетов
Изменения QoS, TTL, TOS

4️⃣ raw

Отключение отслеживания соединений (NOTRACK)

🔁 Общие действия

🧪 Базовые команды IPTables

Просмотр правил

iptables -L
iptables -L -n -v
iptables -n -L -v --line-numbers

Очистка правил (временно):

iptables -F
iptables -X

Сохранение правил (постоянно)

service iptables save

🚫 Блокировка всего трафика (аварийная ситуация)

iptables -A INPUT -s 0.0.0.0/0 -j REJECT

⚠️ Временно (только в оперативной памяти) — сохраните, чтобы изменения сохранились.

🔐 Блокировка конкретного IP

iptables -A INPUT -s 192.168.1.94 -j DROP

🌐 Блокировка подсети

iptables -A INPUT -s 192.168.8.0/24 -j DROP

🚪 Блокировка порта

iptables -A INPUT -p tcp --dport 80 -j DROP

🎯 Блокировка порта для конкретного IP-адреса

iptables -A INPUT -s 192.168.1.10 -p tcp --dport 80 -j DROP

🔄 Разрешение SSH (безопасное правило)

iptables -A INPUT -p tcp --dport 22 -m state --state NEW,ESTABLISHED -j ACCEPT
iptables -A OUTPUT -p tcp --sport 22 -m state --state ESTABLISHED -j ACCEPT

🛑 Политика по умолчанию Drop (рекомендации для продакшена)

iptables -P INPUT DROP
iptables -P FORWARD DROP
iptables -P OUTPUT ACCEPT

📡 Контроль ICMP (Ping)

Блокировка Ping

iptables -A INPUT -p icmp --icmp-type echo-request -j DROP

Разрешение Ping из внутренней сети

iptables -A INPUT -s 192.168.1.0/24 -p icmp -j ACCEPT

🧯 Предотвращение подмены IP

iptables -A INPUT -i eth1 -s 10.0.0.0/8 -j DROP
iptables -A INPUT -i eth1 -s 192.168.0.0/16 -j DROP

📝 Логирование и блокировка пакетов

iptables -A INPUT -s 10.0.0.0/8 -j LOG --log-prefix "IP_SPOOF: "
iptables -A INPUT -s 10.0.0.0/8 -j DROP

Логи отображаются в:

/var/log/messages

⏱️ Ограничение скорости (защита от DoS-атак)

iptables -A INPUT -p tcp --dport 80 -m limit --limit 25/minute --limit-burst 100 -j ACCEPT

🔁 Диапазон разрешенных портов

iptables -A INPUT -p tcp --dport 7000:7010 -j ACCEPT

🔀 Порт-форвардинг (DNAT)

iptables -t nat -A PREROUTING -p tcp --dport 422 -j DNAT --to 192.168.1.10:22

🧠 Реальные сценарии использования (Admin & DevOps)

📌 Рекомендации по использованию IPTables

✔ Всегда разрешайте SSH перед DROP
✔ Сохраняйте правила после тестирования
✔ Используйте stateful правила
✔ Ведите логирование перед DROP
✔ Документируйте правила
✔ Предпочитайте nftables на новых дистрибутивах

⚠️ Важное примечание (для современных версий Linux)

IPTables устарел на новых системах.
nftables — это будущее
IPTables всё ещё широко используется в RHEL 6/7, в legacy-системах и на интервью

IPTables — это мощный, низкоуровневый фаервол, который должен глубоко понимать каждый:

Администратор Linux
DevOps-инженер
Cloud инженер

Освоение IPTables даст вам:

Надёжные основы безопасности
Уверенность при инцидентах в продакшене
Более глубокое понимание понимание облачных фаерволов

Как создать безопасный сервер Linux

2026-03-01T20:35:30.303Z

Это перевод оригинальной статьи How to Build a Secure Linux Server.

Безопасность не обязательно должна быть сложной.

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

#1. Начните с минимальной установки.

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

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

Меньшее количество пакетов = меньше уязвимостей = меньшая поверхность атаки.

Проверьте прослушиваемые порты:

sudo ss -tulpn

Эта команда выводит список всех прослушиваемых портов TCP и UDP в системе, а также процессов, которые ими владеют. Она очень полезна для проверки того, какие службы запущены и какие порты они используют.

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

# Check enabled services:
systemctl list-unit-files --type=service | grep enabled

# Disable and stop service
sudo systemctl disable service_name
sudo systemctl stop service_name

# Remove unused packages
apt autoremove --purge

#2. Защитите SSH

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

Отключить вход в систему от имени root и вход по паролю.

Запретите прямой доступ root по SSH. Всегда входите в систему как обычный пользователь и используйте sudo вместо этого.

Отредактируйте файл конфигурации SSH ( /etc/ssh/sshd_config)

PermitRootLogin no
PasswordAuthentication no

Отключите вход в систему с правами root и по паролю через SSH, чтобы снизить риск атак методом перебора (brute-force).

Измените стандартный порт SSH

Порт SSH по умолчанию — 22. Изменение его на нестандартный порт может сократить количество автоматизированных атак.

Fail2ban

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

#3. Включите брандмауэр (даже в облаке)

Брандмауэр контролирует, каким портам, протоколам и IP-адресам разрешено взаимодействовать с нашим сервером.

Основной принцип прост:

Блокируйте все входящие соединения, кроме конкретных сервисов, которые мы используем.

Если вы размещаете веб-сервер, разрешите порты 80 и 443. Для SSH разрешите только наш собственный порт SSH и, в идеале, ограничьте доступ определенными IP-адресами, если у вас статическое подключение.

#4. Поддерживайте систему в актуальном состоянии.

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

Включите автоматические обновления безопасности

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

# On Ubuntu / Debian
sudo apt install unattended-upgrades
sudo dpkg-reconfigure unattended-upgrades

# On Rocky Linux / AlmaLinux / CentOS
sudo dnf install dnf-automatic
sudo systemctl enable --now dnf-automatic.timer

Важно:
не забывайте о перезагрузке! Некоторые обновления (например, исправления ядра) работают только после перезагрузки.

# Check if a reboot is needed
# Ubuntu
if [ -f /var/run/reboot-required ]; then echo "Reboot needed"; fi

# RHEL-based systems
sudo needs-restarting -r

#5. Используйте принцип наименьших привилегий для пользователей и сервисов

Запускать всё с правами администратора root опасно. Если что-то пойдёт не так, это приведёт к серьёзным последствиям. Сервисы и пользователи должны иметь только те права доступа, которые им действительно необходимы, и ничего больше. Это ограничивает масштабы ущерба в случае компрометации учётной записи или сервиса.

Не запускайте сервисы от имени root

Большинство современных сервисов поддерживают запуск от имени собственного пользователя, например:

nginx
www-data
postgres
docker

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

Используйте Sudo только для административных задач

Пользователи должны входить в систему как обычные пользователи и использовать sudo только при необходимости.

Отключите прямой вход от имени root.
Используйте sudo для внесения изменений в систему.
Ограничьте административный доступ доверенными пользователями

Предоставляйте только необходимые разрешения

Не каждому пользователю необходим полный доступ с правами sudo. Мы можем разрешить только выполнение определённых команд.

sudo visudo

# deploy user can restart nginx, but can’t run other admin commands.
deploy ALL=(ALL) NOPASSWD: /bin/systemctl restart nginx

#6. Мониторинг логов

Логи показывают, что происходит в нашей системе. Мониторинг логов помогает выявлять подозрительную активность.

Получайте ежедневные сводки логов.

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

Примечание:
Для более сложного мониторинга рекомендуется настроить централизованное логирование с помощью таких инструментов, как Elasticsearch и Kibana.

#7. Настройте правильное резервное копирование и восстановление

Как бы ни была защищена наша система, сбои все равно случаются: проблемы с оборудованием, случайные удаления, неудачные деплои или инциденты безопасности. Резервные копии — это последняя линия защиты.

Автоматизация резервного копирования

Резервное копирование должно выполняться автоматически и регулярно. Можно использовать rsync с cron, инструменты резервного копирования, такие как BorgBackup или Restic, либо снапшоты облачного провайдера.

Следуйте правилу 3–2–1

Простая и эффективная стратегия:

3 копии данных
2 разных типа хранения
1 копия вне офиса

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

Делайте резервные копии того, что важно.

Сосредоточьтесь на данных, которые сложно восстановить:

Базы данных
Данные приложения
Загрузки пользователей
Файлы конфигурации
Секреты (хранящиеся безопасно)

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

# 8. Мониторинг целостности файлов

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

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

Установите и настройте такие инструменты, как AIDE(Advanced Intrusion Detection Environment), для мониторинга целостности файлов. Эти инструменты создают базу данных важных системных файлов и оповещают, когда критически важные файлы изменяются неожиданным образом.

#9. Усильте защиту сетевых сервисов

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

Веб-серверы должны использовать HTTPS с современными конфигурациями TLS.
Базы данных не должны прослушивать публичные интерфейсы, если это не является необходимым.
Фреймворки приложений должны работать с минимальными привилегиями

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

Заключительные мысли

Идеальной безопасности не существует, но хорошей безопасности можно достичь. Создание защищенного сервера — это не внедрение всех возможных мер безопасности. Это формирование мышления, ориентированного на безопасность.

Задайте себе следующие вопросы:

Зачем нужен этот сервис? Кому необходим доступ к этому ресурсу? Что произойдет, если этот компонент будет скомпрометирован?

Шпаргалка по Systemd и Journalctl

2026-03-01T20:27:48.027Z

Это перевод оригинальной статьи Systemd & Journalctl Cheat Sheet.

Практическое, удобное для копирования и вставки руководство по освоению systemd и journalctl для специалистов DevOps, системных администраторов и разработчиков.

Оглавление

Часть 1 — Управление сервисами (повседневная деятельность)

Управление состоянием сервиса ( start, stop, restart, reload)
Загрузка и состояние системы ( enable, disable)
Проверка состояния и устранение неполадок ( status, is-active)
Список служб

Часть 2 — Освоение логов с помощью Journalctl

Мониторинг в реальном времени (-f)
Фильтрация по времени и услугам (-u, --since)
Журналы ядра и загрузки (-k, -b)
Ведение журнала (--vacuum)

Часть 3 — Расширенные навыки работы с Systemd (для опытных пользователей)

Анализ производительности загрузки ( blame, critical-chain)
Создание пользовательской службы (шаблона)
Таймеры Systemd против Cron

Часть 1 — Управление услугами (повседневная деятельность)

Большинство дистрибутивов Linux (Ubuntu, Debian, CentOS, RHEL) теперь работают на Systemd. Вот основные команды, которые используются в 90% случаев.

1. Базовое управление сервисом

Замените postgresqlна название вашей службы (например, nginx, docker, ssh).

# Немедленный запуск службы
sudo systemctl start postgresql

# Немедленная остановка службы
sudo systemctl stop postgresql

# Перезапуск службы (остановка + запуск)
sudo systemctl restart postgresql

# Перезагрузка конфигурации без разрыва соединений (если поддерживается службой)
sudo systemctl reload postgresql

2. Загрузка и состояние системы

Управление автозапуском.

# Включить запуск службы при загрузке системы
sudo systemctl enable postgresql

# Отключить запуск службы при загрузке системы
sudo systemctl disable postgresql

# Проверить, включена ли служба
systemctl is-enabled postgresql

3. Проверка состояния (первый шаг отладки)

Команда statusвыводит идентификатор процесса, объем используемой памяти и последние несколько строк лога.

# Проверка статуса
systemctl status postgresql

# Проверка только активности (возвращает "active" или "inactive")
systemctl is -active postgresql

# Проверка наличия сбоя службы 
systemctl is -failed postgresql

4. Проверка статусов служб

Узнайте, какие программы запущены в системе.

# Вывод списка всех запущенных служб
systemctl list -units --type =service --state=running

# Вывод списка всех служб (включая неактивные)
systemctl list -units --type =service --all

# Поиск конкретной службы (например, связанной с брандмауэром)
systemctl list -units --type =service | grep fire

Часть 2 — Освоение логирования с помощью Journalctl

Прекратите использовать tail -f /var/log/syslog`.` journalctl— это современный, структурированный способ обработки логов.

1. Просмотр и отслеживание логов

# Отслеживание логов в  реальном времени ( как tail -f )
journalctl -f

# Отслеживание логов только для КОНКРЕТНОЙ службы ( стандартная команда)
journalctl -u postgresql -f

# Просмотр логов в обратном порядке ( сначала самые новые )
journalctl -r

2. Фильтрация по времени

Отлично подходит для постмортемов.

# Отображение логов с момента последней перезагрузки
journalctl -b

# Отображение логов за последний час
journalctl --since " 1  час назад"

# Отображение логов за определенный период времени
journalctl --since "2025-12-20 14:00:00" --until "2025-12-20 15:00:00"

3. Логи ядра и ошибок

# Отображать только сообщения ядра (эквивалент dmesg)
journalctl -k

# Отображать только сообщения с критичностями Error, Critical и Alert
journalctl -p err

4. Ведение логов

Если ваш диск заполняется, безопасно очистите журналы событий.

# Проверка объема дискового пространства, занимаемого логами
journalctl --disk-usage

# Сохранять только последние 1  ГБ логов
journalctl --vacuum-size=1G

# Сохранять только последние 2 дня логов
journalctl --vacuum - time=2d

Часть 3 — Расширенные навыки работы с Systemd (для опытных пользователей)

Превратите свои навыки из "оператора" в "инженера".

1. Анализ производительности загрузки

Ваш сервер загружается медленно? Найдите причину.

# Список всех служб , отсортированных по времени инициализации
systemd - analyze blame

# Визуализация в виде дерева
systemd - analyze critical - chain

systemd-analyze plot > boot.sv

2. Создание пользовательской службы

Хотите запустить скрипт на Python или исполняемый файл Go в качестве службы? Создайте файл по адресу /etc/systemd/system/myapp.service:

[Unit]
Description=My Custom Application After =network.target

[Service]
# Пользователь, запускающий скрипт
User=ubuntu
# Рабочий каталог
WorkingDirectory=/home/ubuntu/app
# Команда запуска
ExecStart=/usr/bin/python3 /home/ubuntu/app/main.py
# Автоматический перезапуск при сбое
Restart=always
RestartSec=5

[Install]
WantedBy=multi-user.target

После создания файла запустите команду, sudo systemctl daemon-reloadа затем sudo systemctl start myapp.

3. Таймеры Systemd (современный Cron)

Таймеры Systemd часто предпочтительнее cron, поскольку они могут зависеть от других служб и обеспечивают более качественное логирование.

# Вывести список всех активных таймеров
systemctl list-timers

Золотое правило (совет для начинающих)

Прекратите щуриться, разглядывая усеченные лог. Если systemctl statusотображает сообщение об ошибке, но важные строки с ошибками обрезаются (потому что они слишком длинные), не стоит гадать .Запустите journalctl -u [service_name] -e .Фильтры -u отображает только нужную службу и сразу переходят к концу (самым последним записям). Это самый быстрый способ выяснить причину, не пролистывая тысячи строк.

9 хитростей Linux

2026-02-17T07:45:37.793Z

Это перевод оригинальной статьи 9 Linux Tricks.

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

Это не просто команды; это инструменты выживания. Вот 9 продвинутых трюков Linux, которые помогут вам превратиться из пользователя в мастера :)

Охота за привидениями: поиск удаленных файлов, занимающих место на диске (lsof)
Путешествие во времени: перемещение запущенного процесса в screen (reptyr)
Рентген: отладка процессов без логов (strace)
Шпионаж за конфигурацией: чтение окружения запущенного процесса (/proc)
Кнопка паники: мгновенное освобождение дискового пространства для пользователя Root (tune2fs)
Турбо-режим SSH: Мультиплексирование соединений (ControlMaster)
Быстрое исправление: мгновенное исправление опечаток (^old^new)
Современный сетевой анализ: netstat мертв, да здравствует ss !
Мышечная память: sudo!! и !$

1. Охота на привидений: `lsof +L1`

Ситуация: df -h показывает 100% загрузку диска, но вы только что удалили гигабайты файлов логов. Причина: если какой-либо процесс (например, Apache или Postgres) продолжает запись в удаленный файл, операционная система не освобождает место (inode). Файл становится «зомби-файлом».

Решение:

lsof +L1
# Look for files marked as (deleted) but still held by a PID.
# You must reload/restart that specific PID to free the space.

2. Путешествие во времени: `reptyr`

Ситуация: Вы запустили долгий скрипт, он работает уже 4 часа, но вы забыли запустить screen или tmux. Вам нужно отключиться, но закрытие терминала прервет выполнение скрипта.

Решение: Используйте reptyr, чтобы «перехватить» процесс и перенести его на новый экран.

# 1. Background the process: Ctrl+Z, then type 'bg'
# 2. Disown it from current shell: 'disown <PID>'
# 3. Open a new screen/tmux and pull it in:
reptyr <PID>

3. Рентген: `strace`

Ситуация: Процесс завис. Нет логов. Нет загрузки ЦП. Ожидает ли он подключения к сети? Или ему отказано в доступе? Решение: Не гадайте. Наблюдайте за системными вызовами в реальном времени.

strace -p <PID>
# You will see exactly what the kernel is doing: 
# open(), connect(), read()... 
# This is the ultimate debugging weapon.

4. Шпионаж за конфигурацией: файловая система `/proc`

Ситуация: Разработчик утверждает: «У меня всё работает», но производственный сервис не запускается. Вы подозреваете, что он получил неверный пароль к базе данных или ключ API из окружения.
Решение: Считывать данные из памяти запущенного процесса напрямую.

cat /proc/<PID>/environ | tr '\0' '\n'
# This dumps every environment variable the process was started with.
# No more guessing.

5. Кнопка паники: `tune2fs`

Ситуация: Работа системы приостановлена. Диск заполнен на 100%. Вы даже не можете автодополнить команды, потому что нет места для временных файлов. Решение: Linux по умолчанию резервирует 5% блоков для root пользователя. В экстренной ситуации вы можете установить это значение на 0%, чтобы мгновенно получить гигабайты свободного места.

tune2fs -m 0 /dev/sdX
# Warning: Set it back to 5% once you clean up!

6. Турбо-режим SSH: `ControlMaster`

Ситуация: Запуск Ansible или открытие нескольких вкладок с одним и тем же сервером происходит медленно из-за процесса установления SSH-соединения. Решение: Включить мультиплексирование соединений. Первое соединение проходит аутентификацию; последующие соединения мгновенно проходят через существующий туннель.

# In your ~/.ssh/config:
Host *
    ControlMaster auto
    ControlPath ~/.ssh/sockets/%r@%h-%p
    ControlPersist 600

7. Быстрое решение: `^old^new`

Ситуация: Вы ввели длинную команду с опечаткой. systemctl restart nginxx Решение: Не нажимайте стрелку вверх и не прокручивайте назад.

^nginxx^nginx
# Bash automatically runs: systemctl restart nginx

8. Современный сетевой анализ: `ss`

Ситуация: Вы всё ещё используете netstat.
Решение: netstat устарел, работает медленно и обрезает вывод. ss(Статистика сокетов) взаимодействует напрямую с ядром и работает невероятно быстро.

ss -tulpn
# -t: TCP, -u: UDP, -l: Listening, -p: Process, -n: Numeric
# See everything listening on your server in milliseconds.

9. Мышечная память: `sudo !!` и `!$`

sudo !!: Вы ввели команду, но забыли sudo.
Действие: Введите sudo !!(выполняет последнюю команду от имени root).
!$: Вы создали директорию и теперь хотите в неё перейти.

mkdir -p /var/www/html/project/v2 cd !$  
# '!$' expands to the last argument of the previous command

Заключение

Эти приёмы предназначены не просто для демонстрации мастерства; они придут на помощь, когда стандартные инструменты окажутся неэффективными. Освоив их, вы превратите терминал в продолжение своего разума, а не просто в чёрный экран.

@usr_bin_linux

Безопасность системы Linux: как предотвратить «плохие действия» других пользователей на общем сервере

Понимание модели безопасности в Linux

Как золотое правило применяется в системах Linux?

1. Механизмы аутентификации в Linux

2. Механизм авторизации в Linux

3. Механизм аудита в Linux

Заключение

Каждый баг, который я когда-либо исправлял, начинал иметь смысл только после того, как я понял эти 7 уровней

Семь уровней, которые действительно имеют значение

Уровень 7: Прикладной уровень

Уровень 4: Транспортный уровень

Уровень 3: Сетевой уровень

Уровень 2: Канальный уровень

Процесс отладки, который действительно работает

Паттерн, который вы увидите повсюду.

Что изменилось для меня

Инструменты DevOps с открытым исходным кодом, о которых я хотел бы узнать раньше.

1. Portainer → Графический интерфейс Docker, о необходимости которого я даже не подозревал.

2. Jenkins→ Моя первая настоящая свобода в области CI/CD

3. Prometheus + Grafana → Замена облачного мониторинга

4. Alertmanager → Оповещения без оплаты

5. Loki → Инструмент логирования, который следовало использовать с самого первого дня.

6. Argo CD → GitOps: правильный подход

7. Traefik → Обратный прокси, который наконец-то стал понятным.

8. MinIO → Open-Source хранилище S3

9. K9s → Терминальный интерфейс для Kubernetes

10. Gitea → Самостоятельно размещаемая альтернатива GitHub

Заключительные мысли

Лайфхаки по написанию скриптов на Bash, которые должен знать каждый разработчик

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

Введение: Bash — это навык, который вы, сами того не зная, игнорировали.

1. Всегда запускайте скрипты в «строгом режиме».

2. Используйте "$@" вместо $* (Да, это важно)

3. Давайте своим переменным точные имена

4. Используйте $(...) вместо обратных кавычек.

5. Быстро выявляйте ошибки с помощью явных сообщений об ошибках.

6. Используйте функции (даже в небольших скриптах).

7. Перехватывайте сигналы как профессионал

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

9. Используйте массивы вместо строк, разделённых пробелами.

10. Читайте файлы построчно правильно.

11. Используйте set -x для тонкой отладки

12. Предпочитайте [[ ... ]] вместо [ ... ]

13. Используйте Here-Docs для корректного многострочного ввода.

14. Делайте скрипты самодокументируемыми

15. Относитесь к скриптам Bash как к настоящему программному обеспечению.

Вывод: Bash — это инструмент, многократно увеличивающий эффективность.

Шпаргалка по SSH

Часть 1 — Основы SSH (для всех)

Основные принципы использования SSH

SSH с пользовательским портом и пользователем

Аутентификация по SSH-ключу

Сгенерируйте SSH-ключ

Скопируйте открытый ключ на сервер.

Советы по работе с конфигурационными файлами SSH (настоятельно рекомендуется)

SSH-туннелирование и переадресация портов

Локальная переадресация портов

Удалённая переадресация портов

Динамическая переадресация портов (SOCKS-прокси)

Копирование файлов с помощью SCP и RSYNC

Копирование файла на удаленный сервер

Копирование директории

Более быстрый и надёжный способ (рекомендуется)

Отладка SSH-подключений

Лучшие практики безопасности

Часть 2 — Объяснение параметров SSH (от новичка до продвинутого)

Напоминание о базовом синтаксисе

Основные и наиболее часто используемые опции (необходимо знать)

-p → Порт

-l → Имя пользователя

-i → Файл идентификации (SSH-ключ)

-v, -vv, -vvv → Подробный режим / Режим отладки

-F → Пользовательский файл конфигурации

Параметры аутентификации и безопасности

-o → Пользовательская опция SSH

-A → Переадресация агента SSH

-a → Отключить переадресацию агента

-K → Аутентификация GSSAPI

Переадресация и туннелирование

2. Используйте `"$@"` вместо `$*` (Да, это важно)

4. Используйте `$(...)` вместо обратных кавычек.

11. Используйте `set -x` для тонкой отладки

`-p` → Порт

`-l` → Имя пользователя

`-i` → Файл идентификации (SSH-ключ)

`-v`, `-vv`, `-vvv` → Подробный режим / Режим отладки

`-F` → Пользовательский файл конфигурации

`-o` → Пользовательская опция SSH

`-A` → Переадресация агента SSH

`-a` → Отключить переадресацию агента

`-K` → Аутентификация GSSAPI

`-L` → Переадресация локальных портов

`-R` → Удалённая переадресация портов

`-D` → Динамическая переадресация портов (SOCKS-прокси)

`-W` → Переадресация стандартного ввода/вывода

`-J` → Jump Host (Bastion Server)

`-N` → без выполнения команд

`-T` → Отключить псевдо-TTY

`-t` → Принудительно включить TTY

`-f` → Фоновый режим

`-S` → control socket

`-O` → Команды управления

`-c` → Шифр

`-m` → MAC-алгоритм

`-Q` → Запрос поддерживаемых алгоритмов

`-B` → Привязка к сетевому интерфейсу

`-b` → Исходный адрес