Защита 22го порта сервера - ssh

Многие недооценивают опасность от автоматического подбора паролей на 22м порту — это, который ssh.

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

Ну то есть, вчера я мог на него зайти, а сегодня — уже не пускает! И чем он там занимается, под руководством новых хозяев, в каком ботнете учавствует — мне не ведомо. Хорошо, что к этому серверу у меня был физический доступ, и я смог сбросить пароль через LiveCD.

Заодно посмотрел в /var/log/auth.log и ужаснулся: десятки тысяч попыток логина с разных китайских айпишников, под разными именами, типа root, user, ftp, www-data и пр.

Собственно, с тех пор я и выработал свои правила защиты 22го порта.

Запрет входа для root


Необходимо запрещать вход для юзеров, чьи имена известны любому боту. Это root, ftp, www-data и подобные. После установки Ubuntu на сервер, обычно есть только root.

Поэтому нужно создать нового юзера, если увас его еще нет
adduser petrov

добавить его в группу sudo
adduser petrov sudo

и запретить вход root, путём редактировани /etc/ssh/sshd_config
PermitRootLogin no

Перезапуск ssh
sudo service ssh restart

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

Защита через iptables


Многие совутуют менять стандартный порт 22 на любой другой, но мне это решение не нравится по двум причинам:
— Это неудобно. В каждом приложении нужно настраиввать отдельно порт для коннекта.
— Не даёт ничего. Любое сканирование портов сразу покажет, на каком порту живёт ssh, а дальше бот будет ломиться уже в него.

Значит, нужно защитить стандартный порт 22 через iptables. Есть много решений, типа fail2ban, но мне нравится самое простое — запоминать тех, кто слишком часто отваливается и не пускать их больше в течении n секунд.

Вот как это задать:
#!/bin/bash

# Очистка цепочек правил
iptables -F INPUT
iptables -Z INPUT
iptables -P INPUT ACCEPT

iptables -F OUTPUT
iptables -Z OUTPUT
iptables -P OUTPUT ACCEPT

iptables -F FORWARD
iptables -Z FORWARD
iptables -P FORWARD ACCEPT

# Защита порта ssh, время блокировки - 30 секунд
iptables -A INPUT -p tcp -m state --state NEW --dport 22 -m recent --update --seconds 30 -j DROP
iptables -A INPUT -p tcp -m state --state NEW --dport 22 -m recent --set -j ACCEPT

Это нужно сохранить в скрипт /root/iptables и добавить вызов скрипта в /etc/rc.local, чтобы он стартовал при загрузке сервера.

Время блокировки можно подбирать самостоятельно. Дело в том, что 30 секунд — это довольно много, и разные приложения, типа редакторов или ftp-клиентов не всегда могут разобатать с этим правилом, если подключаются слишком часто.

Тогда можно заменить 30 секунд на 10 или даже 5. Но чем больше блокировка — тем меньше шансов у бота.

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


Неудачные попытки подбора паролей очень просто смотреть в /var/log/auth.log таким скриптом:
sudo cat /var/log/auth.log* | grep 'Failed password' | grep sshd | awk '{print $1,$2}' | sort -k 1,1M -k 2n | uniq -c

Вот результаты на сервере, с блокировкой в одну секунду:
1873 Jan 13
2037 Jan 14
2851 Jan 15
3733 Jan 16
4941 Jan 17
1595 Jan 18
Несколько тысяч подборов паролей в сутки!

А вот мой сервер, блокировка 30 секунд:
4 Jan 13
6 Jan 14
2 Jan 15
9 Jan 16
3 Jan 17
3 Jan 18
Нормальный бот с такой с такой скоростью работать не сможет, конечно.

Вот и всё. 2 простейших правила, и ваш сервер становится гораздо более защищён от подбора пароля по ssh.
Дело 5 минут, не ленитесь настроить прямо сейчас!

Также предлагаю публиковать в комментариях количество неудачных авторизаций у вас на сервере — очень интересно сравнить.
Василий Наумкин
18 января 2013, 07:19
modx.pro
1
9 858
0

Комментарии: 16

Andrei Kilin
18 января 2013, 11:41
0
У меня такие же цифры, т.к. пользую твои настройки сервера =)
    Alex Vakhitov
    18 января 2013, 13:52
    0
    Да тылы это самое главное (:

    Сам посмотрел и удивился числу попыток авторизации на серваке где вход по паролю

    35 Jan 6
    604 Jan 7
    496 Jan 8
    279 Jan 9
    925 Jan 10
    456 Jan 11
    643 Jan 12
    19 Jan 13
    139 Jan 15
    458 Jan 16
    176 Jan 17
    357 Jan 18

    Но думаю случайно генерированное имя и пароль в 42 случайных символа займут слишком много времени на подбор
      Василий Наумкин
      18 января 2013, 14:13
      0
      Тут уже другая опасность — 42 символа никто не запоминает, а хранит где-то.

      Пару раз разбирался со взломанным хостингом, когда утекали пароли из-за вирусни на компе.
        Alex Vakhitov
        18 января 2013, 14:18
        0
        Ну тут тоже опасность не велика, у меня мак следовательно вирусы отпадают. А пароли в шифрованой базе и контакта с ними кроме как через буфер обмена системы я не имею.
    Жуковский Антон
    18 января 2013, 14:55
    0
    0 попыток после того, как три года назад поменял порт. Сервер, правда, не для веба, но, тем не менее, до смены порта были тысячи попыток в день.
      Василий Наумкин
      18 января 2013, 15:41
      0
      Какие-то ленивые боты у тебя =)
        Жуковский Антон
        18 января 2013, 19:41
        0
        Скорее всего поиск жертв с открытым 22 портом эффективнее, чем полное сканирование портов. Для эксперимента я поменял сегодня порт ssh на домашнем роутере на 22. Через 3 часа пришел и полна жопа огурцов в логе куча записей о неудачной авторизации.
    Григорий
    19 января 2013, 03:32
    0
    597 Jan 6
    708 Jan 7
    79 Jan 8
    627 Jan 9
    3018 Jan 10
    2800 Jan 11
    2683 Jan 12
    1742 Jan 13
    555 Jan 14
    5848 Jan 15
    584 Jan 16
    819 Jan 17
    1246 Jan 18
    9 Jan 19
      Іван Клімчук
      25 января 2013, 00:00
      0
      409 Jan 1
      838 Jan 2
      795 Jan 3
      218 Jan 4
      153 Jan 5
      971 Jan 6
      706 Jan 7
      445 Jan 8
      155 Jan 9
      762 Jan 10
      889 Jan 11
      589 Jan 12
      982 Jan 13
      632 Jan 14
      587 Jan 15
      584 Jan 16
      517 Jan 17
      357 Jan 18
      345 Jan 19
      581 Jan 20
      459 Jan 21
      212 Jan 22
      223 Jan 23
      411 Jan 24

      Стучатся, ироды. :)

      P.S. Сервак, где modx.by крутится-вертится.
        Евгений Борисов
        12 мая 2013, 17:52
        0
        А вариант с переопределением порта не рассматривался?
          Василий Наумкин
          12 мая 2013, 18:02
          0
          Говорят, хорошо помогает, но я предпочитаю решать проблему надежно.
          Ведь, подбирать пароль может не только бот, но и живой человек, который просканирует порты и найдёт, куда ломиться.

          К тому же, не очень хочется во всех клиентских приложениях прописывать другой порт.
          Aleksey Nikitin
          13 мая 2013, 07:08
          0
          Привет. Я юзаю denyhosts с небольшими исправлениями дефолтных установок (зависят от моей злобности) — банит япошек-китаешек сотнями. Попробуйте
            Влад
            21 октября 2013, 01:00
            0
            Настроил авторизацию по ключу, чего и всем желаю.
              Авторизуйтесь или зарегистрируйтесь, чтобы оставлять комментарии.
              16