Част 4: Сигурност и права
(SSH, sudo, iptables)

1. Как мисля за сигурността

Преди години, когато за първи път инсталирах собствен сървър, сигурността ми се струваше като нещо, което "се прави накрая". Бързо разбрах, че това е грешка. Сигурността започва още при първата конфигурация.

В работата ми с железопътни спирачки има едно правило, което пренасям и в IT: никога не допускай човек до системата, ако не знаеш какво точно може да направи. В Linux това означава: контролирай достъпа, минимизирай привилегиите, следи за нередности.

2. SSH – първата линия на защита

SSH е вратата към сървъра. Ако тази врата не е добре заключена, всичко останало няма значение. Ето как конфигурирам SSH на сървърите си.

# Променя стандартния порт (за да намаля автоматичните атаки)
Port 2222

# Забранявам root вход през SSH
PermitRootLogin no

# Изисквам публични ключове (без пароли)
PubkeyAuthentication yes
PasswordAuthentication no

# Разрешавам само конкретни потребители
AllowUsers fedia deploy

# Забранявам празни пароли
PermitEmptyPasswords no

# Ограничавам опитите за вход
MaxAuthTries 3
MaxSessions 5

3. SSH ключове – вместо пароли

Паролите се отгатват, открадват или подхлъзват. Публичните ключове са много по-сигурни. Ето как ги използвам.

# Генериране на ED25519 ключ (по-бърз и сигурен от RSA)
ssh-keygen -t ed25519 -C "[email protected]"

# Копиране на публичния ключ към сървъра
ssh-copy-id -p 2222 fedia@srv01

4. sudo – контролирани привилегии

Не всеки потребител трябва да има root права. И дори тези, които ги имат, не трябва да ги използват за всичко. sudo ми дава инструмент за прецизен контрол.

# Позволявам на потребител fedia да рестартира само nginx
fedia ALL=(ALL) /usr/bin/systemctl restart nginx

# Позволявам на deploy да изпълнява само определени скриптове
deploy ALL=(ALL) /usr/local/bin/deploy.sh

# Забранявам използването на shell
fedia ALL=(ALL) !/bin/bash

Редактирам /etc/sudoers само с visudo, защото той проверява синтаксиса преди да запише. Една грешка в sudoers може да те заключи извън системата.

5. Firewall – iptables и nftables

Firewall е втората врата. Ако SSH е входната врата, firewall е оградата около целия имот. В миналото използвах iptables. В днешно време преминах към nftables.

# Позволявам SSH (на порт 2222)
nft add rule inet filter input tcp dport 2222 accept

# Позволявам HTTP и HTTPS
nft add rule inet filter input tcp dport 80 accept
nft add rule inet filter input tcp dport 443 accept

# Позволявам връзки от локалния интерфейс
nft add rule inet filter input iif lo accept

# Позволявам вече установени връзки
nft add rule inet filter input ct state established,related accept

# Всичко останало се отхвърля
nft add rule inet filter input drop

# Запазване на правилата
nft list ruleset > /etc/nftables.conf

6. Fail2ban – автоматична защита

Дори и с ключове, опитите за вход продължават. fail2ban автоматично блокира IP адреси, които правят твърде много неуспешни опити.

# Инсталиране на fail2ban
apt install fail2ban

# Копиране на конфигурацията
cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local

# Редактиране на jail.local
nano /etc/fail2ban/jail.local

[sshd]
enabled = true
port = 2222
filter = sshd
logpath = /var/log/auth.log
maxretry = 3
bantime = 3600  # 1 час

7. Права на файловете – chmod, chown, chattr

В Linux всичко е файл. И правата на тези файлове определят кой какво може да прави. Това не е просто теория – това е основният механизъм за сигурност.

# Собственик и група
chown fedia:www-data /var/www/app
chown -R fedia:www-data /var/www/app

# Права за четене/запис/изпълнение
chmod 755 /var/www/app      # rwx r-x r-x
chmod 640 /etc/nginx/nginx.conf  # rw- r-- ---

# Защита от промяна (дори от root)
chattr +i /etc/nginx/nginx.conf  # става immutable
chattr -i /etc/nginx/nginx.conf  # връщане

8. Логове – сигурността започва с наблюдение

Без логове не мога да разбера какво се е случило. /var/log/auth.log и journalctl са моите очи.

# Неуспешни опити за вход
grep "Failed password" /var/log/auth.log

# Успешни входове
grep "Accepted" /var/log/auth.log

# sudo команди
grep "sudo" /var/log/auth.log

# Всичко в journalctl
journalctl -u sshd -f

9. Аудит на системата – lynis и rkhunter

Периодично използвам инструменти за сканиране на системата – lynis и rkhunter. Те проверяват за слаби места, неправилни конфигурации и следи от компрометиране.

# Инсталиране на lynis
apt install lynis

# Изпълнение на сканиране
lynis audit system

# Инсталиране на rkhunter
apt install rkhunter

# Изпълнение на проверка
rkhunter --check

10. Практически правила, които следвам

11. Най-честите грешки

• Оставяне на SSH на порт 22 с паролен достъп;
• Работа като root за ежедневни задачи;
• Забрава за актуализиране на пакетите;
• Отваряне на твърде много портове в firewall-а;
• Пренебрегване на логовете;
• Използване на едни и същи пароли за различни сървъри;
• Доверие на "сигурността по подразбиране".

12. Заключение

Сигурността в Linux не е сложна, но изисква дисциплина. Това не са само команди – това е начин на мислене. Всеки допълнителен потребител, всяка отворена услуга, всяка промяна – всичко това трябва да бъде обмислено.

В тази статия споделих как подхождам към сигурността на сървърите си. Това не е изчерпателен списък, а основата, върху която надграждам.

В следващата част ще се потопим в скриптовете и автоматизацията – как пиша bash скриптове, които спестяват време и гарантират, че нищо не се забравя.