Повышаем безопасность

Частенько системные администраторы не отдают должное безопасности, а зря. Пусть даже это не важный сервер, но тем не менее, однажды он может стать зомби в каком-нибудь ботнете, который будет кого-то DDoS’ить или распространять malware.

Предлагают вашему вниманию рассмотреть какие следует предпринять меры для предотвращения этого:

1) Логгирование всех попыток подключиться по ssh

Очень удобно и всегда будешь знать кто и когда зашёл на сервер. Сами попытки логгируются в /var/log/auth.log, но можно сделать так, что бы при каждом логине приходил email на почту. Для этого создаём файл /etc/ssh/sshrc такого содержания:

echo -e "Successfuly login via ssh on $(hostname)\n\nDate:\t\t$(date +%d.%m.%Y\ %H:%M:%S)\nRemote connection :\t$SSH_CONNECTION\nUser:\t\t$USER\nShell:\t\t$SSH_TTY" | /usr/bin/mail -s "[SSH] Login on $(hostname)" root@domain.com

Почтовый ящик желательно указывать внешний, а можно даже указать несколько таких строк для отправки на несколько ящиков. Вообще /etc/ssh/sshrc — это обычный shell скрипт, поэтому можно смело использовать все преимущества shell’a

2) Установка блокировщика паролей

Здесь стоит подумать не только о подборе паролей ssh, но так же и попытки подобрать пароль к почте или ftp. Очень удобным в этой ситуации будет fail2ban, который имеет много разных шаблонов.

Так же, если вам не подходит fail2ban, можно использовать блокировщики паролей ssh: sshit, bruteblock

3) Защита на уровне файервола

Есть файерволы, которые могут ограничивать попытки подключения и заносить виновников в бан. Но не все файерволы это могут. Вот пример для pf’a:

#bruteforce
block drop in quick on $ext_if from <badhosts> to any label "ssh bruteforce"
block drop out quick on $ext_if from any to <badhosts> label "ssh bruteforce"
pass in quick on $ext_if proto tcp from any to ($ext_if) port 22 flags S/SA keep state (max-src-conn-rate 1/60, overload <badhosts> flush global)

В данном случае имеет защиту от подбора: если в течении 60 секунд будет неправильная одна сессия подбора (в данном случае имеется ввиду одна сессия в которой может быть попыток MaxAuthTries; по умолчанию 6)

4) Установка IDS

Немаловажным фактором будет установка всякого рода realtime анализаторов аномалий сервера. К ним относятся rkhunter, chkrootkit, snort

5) Рекомендации по защите ssh

— перевесить на другой порт
— запретить безпарольный вход, по возможности и вход только по ключам
— запретить доступ root’a
— уменьшить MaxAuthTries
— установить Protocol 2

Повышаем безопасность: 3 комментария

  1. Bootmen

    Настроил fail2ban . По простому. Только не понял один ньюанс:
    findtime = 600 Это время через которое утилита проверяет лог например постфикса?
    Или она проверяет чаще. Если поставлю: findtime = 1800
    то тогда злодей успеет напихать мне попыток очень много. за 30 минут
    а fail2ban проверив этот отрезок и сравнив его с maxretry = 2
    запоздало всетаки забанит вредителя. Может я заблуждаюсь.

    1. skeletor Автор записи

      Это время (в секундах) за которое просматривается журнал на наличие maxretry записей о попытках для блокировки нападающего. Его рекомендуется ставить не более 5 минут. По умолчанию 10.

  2. evgeny

    советую ограничить время между повторами доступа к порту:
    -A INPUT -i eth0 -p tcp -m tcp —dport 22 -m state —state NEW -m recent —update —seconds 120 —hitcount 1 —name DEFAULT —rsource -j DROP
    -A INPUT -i eth0 -p tcp -m tcp —dport 22 -m state —state NEW -m recent —set —name DEFAULT —rsource

    —например, это стоит у меня в правилах. дается одна попытка за 120 секунд. одна неудачная попытка -бан)))

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *