10 мифов о Linux, которые портят всем жизнь
Linux - не серебряная пуля. Его тоже можно поставить криво, настроить как попало и удивляться, почему все лезут без спроса. Вот главные заблуждения, из-за которых горят сервера.
"Linux безопасен по умолчанию"Реальность: Свежая установка Ubuntu/Debian с открытым SSH на 22 порту и разрешённым рутовым логином по паролю - это подарок хакерам.# Проверь себя:sudo grep "^PermitRootLogin\|^PasswordAuthentication" /etc/ssh/sshd_config
"Контейнеры Docker изолируют всё"Реальность: Запуск контейнера от root без кап-дропов и не-привилегированного режима = дать ключи от хоста.docker run --privileged -v /:/mnt alpine sh # Теперь ты root на всей системе
"Брандмауэр не нужен, у меня нет открытых портов"Реальность: ss -tuln покажет обратное. MySQL на 0.0.0.0:3306? Redis на всех интерфейсах? Добро пожаловать.sudo ss -tulpn | grep -E ':(3306|6379|5432)'
"Апдейты можно ставить раз в год"Реальность: Устаревшие пакеты - это уже не фичи, а дыры. apt list --upgradable - это список твоих проблем.sudo apt list --upgradable 2>/dev/null | grep -v "^Listing" | wc -l
"SUID-бинарники - это нормально"Реальность: Любой левый бинарь с SUID-флагом может стать трояном. GTFOBins - библия для эксплуатации.find / -perm -4000 -type f 2>/dev/null | grep -v "^/usr/bin"
"Логи сами всё запишут"Реальность: По умолчанию LogLevel в SSH - INFO. Проваленные логины могут и не попасть в /var/log/auth.log.sudo grep "LogLevel" /etc/ssh/sshd_config
"В Cron можно писать любые скрипты"Реальность: Мировые права на файл крон-задачи (o+w) позволяют любому пользователю системы её подменить.find /etc/cron* -perm -o+w -type f 2>/dev/null
"SELinux/AppArmor только мешают"Реальность: Это последний серьёзный барьер после взлома приложения. Выключил - упростил жизнь атакующему.sudo sestatus 2>/dev/null || aa-status 2>/dev/null || echo "Ничего не включено"
"Пароли в переменных окружения безопасны"Реальность: Любой процесс, запущенный от того же пользователя, может их прочитать. ps auxfww покажет все секреты.ps auxfww | grep -E "(API_KEY|SECRET|PASSWORD)"
"Мой VPS никто не найдёт"Реальность: Shodan, Censys и прочие сканеры постоянно обшаривают весь интернет. Твой IP с портом 22 уже в базе.# Попробуй найти себя:curl -s "https://api.shodan.io/shodan/host/search?key=YOUR_KEY&query=port:22+os:linux" | jq .
Быстрая проверка на идиотизм:#!/bin/bashecho "[?] Проверяем стандартные косяки..."echo "SSH на 22 порту?"sudo netstat -tlnp | grep ":22 "echo "Рут по SSH разрешён?"sudo grep "PermitRootLogin yes" /etc/ssh/sshd_configecho "Открытые порты для всех?"sudo ss -tuln | grep "0.0.0.0:" | grep -v ":22"echo "Готово. Если что-то выше есть - ты в группе риска."
Итог:95% взломов происходят из-за человеческого фактора и веры в мифы, а не из-за нуледей в ядре. Безопасность - это процесс, а не галочка.
CodeGuard: Linux | Чат
Linux - не серебряная пуля. Его тоже можно поставить криво, настроить как попало и удивляться, почему все лезут без спроса. Вот главные заблуждения, из-за которых горят сервера.
"Linux безопасен по умолчанию"Реальность: Свежая установка Ubuntu/Debian с открытым SSH на 22 порту и разрешённым рутовым логином по паролю - это подарок хакерам.# Проверь себя:sudo grep "^PermitRootLogin\|^PasswordAuthentication" /etc/ssh/sshd_config "Контейнеры Docker изолируют всё"Реальность: Запуск контейнера от root без кап-дропов и не-привилегированного режима = дать ключи от хоста.docker run --privileged -v /:/mnt alpine sh # Теперь ты root на всей системе "Брандмауэр не нужен, у меня нет открытых портов"Реальность: ss -tuln покажет обратное. MySQL на 0.0.0.0:3306? Redis на всех интерфейсах? Добро пожаловать.sudo ss -tulpn | grep -E ':(3306|6379|5432)' "Апдейты можно ставить раз в год"Реальность: Устаревшие пакеты - это уже не фичи, а дыры. apt list --upgradable - это список твоих проблем.sudo apt list --upgradable 2>/dev/null | grep -v "^Listing" | wc -l "SUID-бинарники - это нормально"Реальность: Любой левый бинарь с SUID-флагом может стать трояном. GTFOBins - библия для эксплуатации.find / -perm -4000 -type f 2>/dev/null | grep -v "^/usr/bin" "Логи сами всё запишут"Реальность: По умолчанию LogLevel в SSH - INFO. Проваленные логины могут и не попасть в /var/log/auth.log.sudo grep "LogLevel" /etc/ssh/sshd_config "В Cron можно писать любые скрипты"Реальность: Мировые права на файл крон-задачи (o+w) позволяют любому пользователю системы её подменить.find /etc/cron* -perm -o+w -type f 2>/dev/null "SELinux/AppArmor только мешают"Реальность: Это последний серьёзный барьер после взлома приложения. Выключил - упростил жизнь атакующему.sudo sestatus 2>/dev/null || aa-status 2>/dev/null || echo "Ничего не включено" "Пароли в переменных окружения безопасны"Реальность: Любой процесс, запущенный от того же пользователя, может их прочитать. ps auxfww покажет все секреты.ps auxfww | grep -E "(API_KEY|SECRET|PASSWORD)" "Мой VPS никто не найдёт"Реальность: Shodan, Censys и прочие сканеры постоянно обшаривают весь интернет. Твой IP с портом 22 уже в базе.# Попробуй найти себя:curl -s "https://api.shodan.io/shodan/host/search?key=YOUR_KEY&query=port:22+os:linux" | jq .Быстрая проверка на идиотизм:#!/bin/bashecho "[?] Проверяем стандартные косяки..."echo "SSH на 22 порту?"sudo netstat -tlnp | grep ":22 "echo "Рут по SSH разрешён?"sudo grep "PermitRootLogin yes" /etc/ssh/sshd_configecho "Открытые порты для всех?"sudo ss -tuln | grep "0.0.0.0:" | grep -v ":22"echo "Готово. Если что-то выше есть - ты в группе риска."
Итог:95% взломов происходят из-за человеческого фактора и веры в мифы, а не из-за нуледей в ядре. Безопасность - это процесс, а не галочка.
CodeGuard: Linux | ЧатСуицидальный Redis с привязкой к 0.0.0.0: как выкладывают сессионные токены и ключи в публичный доступ
Кто-то ставит Redis на продакшн, думая "база в памяти - быстрая хрень". Через час его сервер уже в Shodan с паролями от базы на продакшене. Вот как это происходит каждый божий день.
Redis на 0.0.0.0 и без пароля - классика дебилизма# Конфиг по умолчанию:bind 0.0.0.0protected-mode no# requirepass foobared ← закомментировано
# Злоумышленник подключается за секунду:redis-cli -h 185.xxx.xxx.xxx -p 6379KEYS
GET session:user:4521
Фикс (30 секунд):
sudo nano /etc/redis/redis.conf
bind 127.0.0.1 # или внутренний IP
protected-mode yes
requirepass ваш_очень_сложный_пароль_тут
sudo systemctl restart redis
sudo ufw deny 6379/tcp
Ворующий сессии через CONFIG и DUMP
# Даже с паролем, если bind 0.0.0.0:
AUTH слабый_пароль
CONFIG SET dir /tmp
CONFIG SET dbfilename dump.rdb
SAVE
# Атакующий скачивает файл дампа по HTTP/FTP
# Или просто читает всё:
KEYS GET api:keys:stripeGET user:sessions:*
Фикс:# В конфиге:rename-command CONFIG ""rename-command FLUSHALL ""rename-command SHUTDOWN ""rename-command DEBUG ""
# И firewall, блин!sudo ufw deny out to any port 6379
Docker-образы с публичным Redis (проклятие DevOps)# В Dockerfile каждого второго стартапа:FROM redis:alpineEXPOSE 6379# Пароль? Не, не слышали.
# Запуск:docker run -p 6379:6379 redis# Теперь вся сеть видит ваши сессии
Фикс для Docker:# Используйте пароль через переменную:docker run -p 127.0.0.1:6379:6379 \ -e REDIS_PASSWORD=секрет \ redis:alpine \ redis-server --requirepass ${REDIS_PASSWORD}
# Или лучше в docker-compose:services: redis: image: redis:alpine command: redis-server --requirepass ${REDIS_PASSWORD} ports: - "127.0.0.1:6379:6379"
Ключи приложений в plain text (Elasticache тоже виноват)# В коде:redis = Redis.new(host: 'cache.amazonaws.com', port: 6379)# Никакого TLS, никакого AUTH.
# Shodan запрос:redis port:6379 country:ru "amazonaws.com"# Результат - сотни инстансов с данными:1) "staging:database:url"2) "production:jwt:secret"3) "queue:failed:jobs"
Фикс для облаков:# AWS ElastiCache: ВКЛЮЧИТЕ Encryption in-transit.# И используйте Security Groups - не открывайте порт всему миру.
# Проверка:aws elasticache describe-cache-clusters \ --show-cache-node-info \ --query "CacheClusters[?TransitEncryptionEnabled==\`false\`]"
Мониторинг? Какой ещё мониторинг?# Никто не смотрит логи:sudo tail -f /var/log/redis/redis-server.log# Пусто, потому что логи по умолчанию в syslog.
# А в это время:185.231.154.12 [1] "AUTH"185.231.154.12 [1] "CONFIG"185.231.154.12 [1] "KEYS"
Фикс мониторинга:# Включите детальное логирование:sudo nano /etc/redis/redis.confloglevel verboselogfile /var/log/redis/redis.log
# Простая проверка вторжения:sudo grep -E "(CONFIG|SLAVEOF|FLUSHALL)" /var/log/redis/redis.log
# Prometheus + redis_exporter для алертов.
Чек-лист "Не отдай Redis хакерам": Конфиг: bind 127.0.0.1, protected-mode yes, requirepass (сложный!)
Firewall: Закрой порт 6379 на входящие извне. Всегда.
Команды: Переименуй или отключи CONFIG, FLUSHALL, DEBUG.
Docker: Не пробрасывай порт на 0.0.0.0. Используй пароль через env.
Облака: Включи шифрование трафика. Настрой Security Groups/VPC.
Логи: Включи verbose логирование. Мониторь подозрительные команды.
Резервные копии: Делай дампы, но храни их в безопасном месте.
Бонус: скрипт для быстрой проверки уязвимости#!/bin/bashecho " Проверка Redis на суицидальные настройки"sudo netstat -tlnp | grep 6379sudo grep -E "^(bind|protected-mode|requirepass)" /etc/redis/redis.conf | grep -v "^#"echo "---"echo "Если видишь 'bind 0.0.0.0' и 'protected-mode no' - тебя уже взломали."
Интересный факт:По данным BinaryEdge, более 70 000 инстансов Redis в интернете доступны без пароля и принимают команды CONFIG. Иди фиксить.
CodeGuard: Linux | Чат
Кто-то ставит Redis на продакшн, думая "база в памяти - быстрая хрень". Через час его сервер уже в Shodan с паролями от базы на продакшене. Вот как это происходит каждый божий день.
Redis на 0.0.0.0 и без пароля - классика дебилизма# Конфиг по умолчанию:bind 0.0.0.0protected-mode no# requirepass foobared ← закомментировано# Злоумышленник подключается за секунду:redis-cli -h 185.xxx.xxx.xxx -p 6379KEYS
GET session:user:4521
Фикс (30 секунд):
sudo nano /etc/redis/redis.conf
bind 127.0.0.1 # или внутренний IP
protected-mode yes
requirepass ваш_очень_сложный_пароль_тут
sudo systemctl restart redis
sudo ufw deny 6379/tcp
Ворующий сессии через CONFIG и DUMP# Даже с паролем, если bind 0.0.0.0:
AUTH слабый_пароль
CONFIG SET dir /tmp
CONFIG SET dbfilename dump.rdb
SAVE
# Атакующий скачивает файл дампа по HTTP/FTP
# Или просто читает всё:
KEYS GET api:keys:stripeGET user:sessions:*
Фикс:# В конфиге:rename-command CONFIG ""rename-command FLUSHALL ""rename-command SHUTDOWN ""rename-command DEBUG ""
# И firewall, блин!sudo ufw deny out to any port 6379
Docker-образы с публичным Redis (проклятие DevOps)# В Dockerfile каждого второго стартапа:FROM redis:alpineEXPOSE 6379# Пароль? Не, не слышали.# Запуск:docker run -p 6379:6379 redis# Теперь вся сеть видит ваши сессии
Фикс для Docker:# Используйте пароль через переменную:docker run -p 127.0.0.1:6379:6379 \ -e REDIS_PASSWORD=секрет \ redis:alpine \ redis-server --requirepass ${REDIS_PASSWORD}
# Или лучше в docker-compose:services: redis: image: redis:alpine command: redis-server --requirepass ${REDIS_PASSWORD} ports: - "127.0.0.1:6379:6379"
Ключи приложений в plain text (Elasticache тоже виноват)# В коде:redis = Redis.new(host: 'cache.amazonaws.com', port: 6379)# Никакого TLS, никакого AUTH.# Shodan запрос:redis port:6379 country:ru "amazonaws.com"# Результат - сотни инстансов с данными:1) "staging:database:url"2) "production:jwt:secret"3) "queue:failed:jobs"
Фикс для облаков:# AWS ElastiCache: ВКЛЮЧИТЕ Encryption in-transit.# И используйте Security Groups - не открывайте порт всему миру.
# Проверка:aws elasticache describe-cache-clusters \ --show-cache-node-info \ --query "CacheClusters[?TransitEncryptionEnabled==\`false\`]"
Мониторинг? Какой ещё мониторинг?# Никто не смотрит логи:sudo tail -f /var/log/redis/redis-server.log# Пусто, потому что логи по умолчанию в syslog.# А в это время:185.231.154.12 [1] "AUTH"185.231.154.12 [1] "CONFIG"185.231.154.12 [1] "KEYS"
Фикс мониторинга:# Включите детальное логирование:sudo nano /etc/redis/redis.confloglevel verboselogfile /var/log/redis/redis.log
# Простая проверка вторжения:sudo grep -E "(CONFIG|SLAVEOF|FLUSHALL)" /var/log/redis/redis.log
# Prometheus + redis_exporter для алертов.
Чек-лист "Не отдай Redis хакерам":
Конфиг: bind 127.0.0.1, protected-mode yes, requirepass (сложный!) Firewall: Закрой порт 6379 на входящие извне. Всегда. Команды: Переименуй или отключи CONFIG, FLUSHALL, DEBUG. Docker: Не пробрасывай порт на 0.0.0.0. Используй пароль через env. Облака: Включи шифрование трафика. Настрой Security Groups/VPC. Логи: Включи verbose логирование. Мониторь подозрительные команды. Резервные копии: Делай дампы, но храни их в безопасном месте.Бонус: скрипт для быстрой проверки уязвимости#!/bin/bashecho "
Проверка Redis на суицидальные настройки"sudo netstat -tlnp | grep 6379sudo grep -E "^(bind|protected-mode|requirepass)" /etc/redis/redis.conf | grep -v "^#"echo "---"echo "Если видишь 'bind 0.0.0.0' и 'protected-mode no' - тебя уже взломали."Интересный факт:По данным BinaryEdge, более 70 000 инстансов Redis в интернете доступны без пароля и принимают команды CONFIG. Иди фиксить.
CodeGuard: Linux | Чат Port 21 (FTP) Port 22 (SSH) Port 23 (Telnet) Port 25 (SMTP) Port 53 (DNS) Port 80 (HTTP) Port 443 (HTTPS) Port 3074 (Xbox Live) Port 5060 (SIP) Port 8080 (Proxy) Port 135 (RPC) Port 139 (NetBIOS) Port 1433 (MSSQL) Port 1521 (Oracle) Port 1723 (PPTP) Port 1900 (UPnP) Port 2302 (DayZ) Port 3389 (RDP) Port 3306 (MySQL) Port 4000 (Elasticsearch) Port 4444 (Metasploit) Port 5000 (Python Flask) Port 5555 (Android Debug Bridge) Port 5900 (VNC) Port 6667 (IRC) Port 6697 (IRC SSL) Port 8000 (HTTP Alt) Port 8081 (HTTP Proxy) Port 9100 (Printer) Port 9090 (Web Debugging) Port 445 (SMB) Ports 5985/5986 (WinRM) Port 6379 (Redis) Port 6666 (IRC) Port 993 (IMAP SSL) Port 995 (POP3 SSL) @DataLeakHub_nixA