Пользователь
0,2
рейтинг
22 марта 2010 в 16:57

Администрирование → Защищаем SSH от брутфорса на любом порту

Сегодня меня заинтересовал опрос надо ли перевешивать SSH на нестандартный порт. Сам опрос не так интересен как способ автора zivot_je_cudo защищать SSH от подбора пароля: после неверной попытки подключения блокировать новые попытки в течение 20 секунд. Задержка, видимо, выбрана эмпирически, исходя их двух противположных пожеланий: чтобы не заблокировать в случае опечатки себя надолго, и в тоже время усложнить жизнь подбиральщика. Я хочу поделиться своим способом противодействия брут-форсу, который применяю уже несколько лет. Он имеет два преимущества:
— дает мне больше попыток для набора правильного пароля
— но при этом блокирует брутфорсеров «навечно».

Как можно достичь этих двух противоположных целей?


Я использую модуль iptables под названием hashlimit, который умеет подсчитывать кол-во пакетов в определенный промежуток времени и через некоторое время сбрасывать счетчик.
Все делается тремя правилами:
iptables -A INPUT -p tcp -m tcp --dport 22 -m state --state NEW -m hashlimit --hashlimit 1/hour --hashlimit-burst 2 --hashlimit-mode srcip --hashlimit-name SSH --hashlimit-htable-expire 60000 -j ACCEPT

iptables -A INPUT -p tcp -m tcp --dport 22 --tcp-flags SYN,RST,ACK SYN -j DROP

iptables -A RH-Firewall-1-INPUT -p tcp -m state --state NEW -m tcp --dport 22 -j ACCEPT


Что делает второе и третье правило понятно. Все самое интересное в первом: оно разрешает 2 попытки подключения в течение часа. Как только вы превышаете 2 попытки за указанное время, правило с -j ACCEPT перестает работать, пользователь вместо этого попадает в следующее правило с -j DROP (точно также можно поставить TARPIT). После этого вы не сможете подключиться, и начинается обратный отсчет 60 000 миллисекунд, после которых информация о вашей попытке «протухает» (параметр --hashlimit-htable-expire). То есть реально вам придеся ждать не 1 час, а всего 1 минуту. Вся военная хитрость состоит в том, что если вы не дождетесь этого времени и попробуете еще раз подключиться, то пакет будет убит, а счетчик снова сброшен в начальное состояние — 1 минуту! Таким образом, если вы нетерпеливый брутфорсер и будете тупо долбать порт после блокировки, то вы с каждой попыткой будете продлевать свой бан! То есть забаните себя навечно!
Добропорядочный же пользователь наборот имеет несколько попыток подключения без ожидания между ними прежде чем попадет в «баню».
Модуль hashlimit сохраняет свое состояние в /proc — поначалу там пусто:
# cat /proc/net/ipt_hashlimit/SSH

после первой попытки подключения туда попадает инфа:
# cat /proc/net/ipt_hashlimit/SSH
55 ХХ.ХХ.ХХ.ХХ:0->0.0.0.0:0 11533000 230400000 115000000

первое число — кол-во оставшихся секунд, можно смотреть как оно равномерно тикает:
# cat /proc/net/ipt_hashlimit/SSH
20 ХХ.ХХ.ХХ.ХХ:0->0.0.0.0:0 117429000 230400000 115000000

После того как я это сделал, мне очень захотелось проверить. И надо же! На ловца зверь бежит! Меня тут же начал брутфорсить какой-то китаец. Первые 4 попытки прошли, а дальше он в течение часа (!) тупо долбился в закрытую дверь. За весь этот час ему удалось проверить всего 4 пароля! Дальше, видимо, надоело.

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

Что делать, если вы вдруг с нескольких попыток не смогли ввести пароль? Не суетиться — подождать спокойно минуту и попробовать еще несколько раз.
А если уж снова не смогли — то лучше пойти проспаться, в таком состоянии в консоль лучше не лазить :))

Успехов.

P.S. И да, чуть не забыл — у меня SSH на нестандартном порту :)

UPD: Немного про настройку hashlimit.
UPD2: Как достичь того же самого с помощью более распространенного модуля recent: раз, два.
UPD3: Само собой способ годится не только для защиты от подбора пароля по SSH, но может быть использован и для различных других сервисов, где слишком частое подключение сигнализирует о чем-то неладном.
UPD4: Ограничение подключений с помощью самого SSHD.
Евгений Лисицкий @el777
карма
229,5
рейтинг 0,2
Пользователь
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Реклама

Самое читаемое Администрирование

Комментарии (138)

  • +3
    чА-щА
    • +3
      Спасибо. Вычитывал опечатки, а такую глупость прямо в заголовке и не заметил.
  • 0
    странно на первое правило в консоль плюнуло iptables: Unknown error 4294967295
    • +1
      Посмотрите, может у вас отсутствует модуль hashlimit.
      • 0
        не подскажите как ??? на самом деле iptables начал не так давно администрировать
        # iptables -m hashlimit
        iptables v1.3.5: You have to specify --hashlimit
        Try `iptables -h' or 'iptables --help' for more information.
        • 0
          используйте recent, см ниже. Он точно должен быть.
        • 0
          Здесь немного написано про настройку hashlimit: www.protocols.ru/Papers/iptables-tbf.shtml
    • 0
      «Я использую модуль iptables под названием hashlimit»

      у Вас его может ещё не быть
  • 0
    У меня запрещён рут, и в настройках ssh стоит отлуп после двух неудачных попыток. Судя по логам долбят всяких стандартных юзеров, типа john, alex и тп, причём каждый логин меняется при каждом подключении. Так что я думаю танцы с iptables излишни и 20 секунд блокировки вполне спасут от перебора.
    • +3
      От перебора изумительно защищает аутентификация по ключу.
      • 0
        Иногда доступ к серваку нужен из самых неожиданных мест :)
        • 0
          Не всегда есть возможность вставить флешку с ключем, с другой стороны файл можно украсть.
          Но есть можно украсть файл, то можно и пароль перехватить.
          • 0
            Согласитесь, что и украсть файл с ключом, и собрать кейлоггером пароль — труднее, нежели сделать что-то одно из этого?
            • 0
              В теории да, а на практите это может делаться после порутания машины — после чего все одинаково просто :)
              • 0
                Я скорее к тому, что если мне срочно нужно зайти откуда-то (будучи в гостях, например) на сервер по ssh, то я предпочту на чужой машине не просто вводить пароль, а вводить пароль к ключу на той же флешке. Именно с точки зрения практики — это лучше. С точки зрения теории — понятно, что как раз всё равно ;)
                • 0
                  Да, психологически так чувствуешь себя спокойнее :)
                • 0
                  А еще можно сделать так:
                  — К главному серверу доступ только по ключу.
                  — Ключ от главного сервера только на втором сервере о котором никто не знает кроме админа.
                  — Доступ на второй сервер по паролю возможен.

                  Как итог — можно зайти на главный сервер по паролю через другой. но никто не знает где этот другой и существует ли он вообще.
  • –1
    а напишите, что то подобное для FreeBSD =)
    • 0
      тут неплохой мануал настройки защиты с использованием порта sshit
    • +1
      Конкретно для ipfw =)
      • 0
        sshit прекрасно работает в свзяке з IPFW2 :-)
    • 0
      bruteforceblocker-1.2.3 Checks for SSH bruteforce and blocks given IPs
    • 0
      Если честно, давно не работал с фрей, последнее время больше с линуксом.
      У iptables дико много разных модулей: некоторые конечно совсем странные, но некоторые позволяют легко делать интересные вещи.
    • 0
      sshguard еще есть
  • +2
    Можно использовать recent

    iptables -A INPUT -p tcp -m state --state NEW --dport 22 -m recent --update --seconds 20 -j DROP

    iptables -A INPUT -p tcp -m state --state NEW --dport 22 -m recent --set -j ACCEPT

    ДО:

    Dec 6 11:03:11 artur sshd[2177]: Invalid user test from 193.220.141.151

    Dec 6 11:03:11 artur sshd[2177]: Failed password for invalid user test from 193.220.141.151 port 46079 ssh2

    Dec 6 11:03:15 artur sshd[2180]: Failed password for root from 193.220.141.151 port 46144 ssh2

    Dec 6 11:03:16 artur sshd[2183]: Invalid user admin from 193.220.141.151

    Dec 6 11:03:16 artur sshd[2183]: Failed password for invalid user admin from 193.220.141.151 port 46377 ssh2

    после

    После введения этого правила логи становятся девтственно чистыми.

    Dec 10 15:24:42 artur — MARK — Dec 10 15:44:42 artur — MARK — Dec 10 15:49:06 artur sshd[21819]: Did not receive identification string from 85.93.9.31

    Dec 10 16:02:10 artur sshd[21824]: Invalid user shell from 85.93.9.31

    Dec 10 16:02:10 artur sshd[21824]: Failed password for invalid user shell from 85.93.9.31 port 40288 ssh2

    Dec 10 16:24:43 artur — MARK — Dec 10 16:44:43 artur — MARK — Dec 10 17:04:43 artur — MARK —
  • +1
    А зачем такие сложности? Тем более, что… мм… немного ненадежно вешать логику контроля ssh на iptables. Посмотрите в сторону sshguard. Очень простая штука — парсит лог sshd и банит ip, с которых приходит много безуспешных попыток залогиниться.
    • +1
      Может тогда использовать denyhosts, а еще лучше denyhosts и iptables
      • +4
        юзаю fail2ban, вполне сухо и комфортно
        • 0
          Не, так неинтересно. У нас же любят изобретать велосипед :)
          • 0
            решению достаточно много времени, в тот момент с помощью одного recent не удавалось настроить такой «вечный» бан.
            • 0
              Мда немного странно, по правилу recent, если ломимся быстрее 20 секунд, вас блокируют.
              Если вы опять ломитесь, вас опять блокируют :)
              Чем вам не бан?
              • 0
                Тем, что бан протухает через 20 секунд после первой неудачной попытки. После чего мне дают вторую попытку подбора и так далее. То есть подбор идет, только чуть медленнее. Вы можете увеличить интервал до минуты, то тем самым себе создадите больше проблем в случае опечаток. Поэтому и выбрано автором значение 20 секунд.
                Здесь, я могу поставить интервал в 2-3 минуты, не создав себе проблем, т.к. имею 4 попытки подключения и я могу подождать нужное время.

                Вся соль в том, что брутфорсер не ждет, он нагло долбится и не получает ровным счетом ничего. Вот было у него 4 изначальных попытки и все. Он после этого может долбиться год, не получив ни одного нового шанса.
                • 0
                  >Вся соль в том, что брутфорсер не ждет, он нагло долбится и не получает ровным счетом ничего.

                  вообще то на дворе 21 век, брутфорсер-ы поумнели…
                  • 0
                    Они могут адаптивно подбирать время между подключениями?
                    Хотелось бы подробнее узнать про это.
                  • 0
                    С другой стороны я могу поставить интервал в 5 минут. Чтобы его найти брутеру потребутся какое-то время.
                    Но, конечно, если атака идет с разных ип, то тут трудно выловить.
                • 0
                  Кто мешает боту так же ждать в вашем случаи?
                  • 0
                    Никто не мешает. Вопрос в том — сколько ждать?
                    Если много, то это делает перебор неэффективным (кому нужен брутфорс с одним паролем в 5 минут?), если мало, то он вообще останавливается.
                    Можно конечно опытным путем подобрать интервал, скажем, если брутфорсер заметил, что попал в бан, то увеличивать интервал в 2 раза.
                    • 0
                      В общем общие мнение думаю такое, нужно все же или усложнять правило или ставить дополнительное средство.
                      • 0
                        Да хорошая мысль.
                        Есть еще вариант, после этого правила поставить другое правило с увеличенным до 1 часа минут интервалом. Он будет накапливать попытки подключения и сбрасывать их гораздо медленнее, тогда как только его предел превысится, он надолго залочит пользователя. Наврядли имеет смысл делать больше часа. 100 паролей в день — это не брутфорс. Таким образом за год можно проверить всего 35 тысяч, а за это время админ должен успеть поменять пароль.
                        • –1
                          Не уверен, что админу потребуется даже через миллион лет менять такой, например, пароль:

                          ugb0wO@mQPp4q\TKDU9Hp@eV/q;78?#=)
                          • 0
                            Вы забываете вариант при котором пароль могут спереть, еще более вероятен вариант когда сопрут часть пароля, например, подсмотрят, какой-то блок в памяти не будет затерт и так далее. Вот если останется от вашего сверхнадежного пароля всего 3 неизвестных символа, и он сломается за день.
                • 0
                  Тем, что бан протухает через 20 секунд после первой неудачной попытки.
                  Если точнее, то с момента последней, т.к. стоит --update. И recent так же позволяет допускать несколько попыток с помощью опции --hitcount и свободно изменять срок бана.
                  • 0
                    Можно и так.
                    Просто когда это делалось в 2006 году я не нашел опции --update.
                    В любом случае здесь главное идея. Фильтрация не на основе ip-адреса, а на основе наглости лезущего :)
                    • 0
                      Так ведь и recent детектит активность атакующего, не учитывая ip.
                      • 0
                        как не учитывая? Тогда весь смысл теряется.
                        • 0
                          Хы. Не поняли друг друга.
                          Хотел сказать, что, принимая решение о бане, recent оценивает активность с конкретного адреса, а не то, каков адрес.
                          Hashlimit же у Вас делает то же самое?
                          • 0
                            Да, тоже самое, отбор по активности, скорее даже по продолжению активности после попадания в бан. «Добропорядочный» заранее извещен об этом и должен прекратить попытки, а «злой» предполагается будет лезть дальше.

                            А вот тут еще мысль возникла: банить без бана. То есть не блокировать новые попытки подключения, а направлять на фейковый ssh, который на любую попытку будет отвечать «неверный пароль». Таким образом атакующий не должен понять, что его «забанили», но продолжением своей чрезмерной активности будет продлевать свой бан.
                        • 0
                          В любом случае здесь главное идея. Фильтрация не на основе ip-адреса, а на основе наглости лезущего :)
                          Все понял, этими словами Вы не противопоставляете принцип hashlimit принципу recent, а выделяете их на фоне остальных средств.
                          Тяжелый у меня был день =)
                          • 0
                            Да. приницп общий: фильтрация по настойчивости.
                            > Тяжелый у меня был день =)
                            Да я тоже что-то под вечер не очень четко выражаю мысли :)
                • 0
                  И много наподбираете с паузой в 20 секунд между попытками?
                  • 0
                    Посчитайте. 3*60*24 = 4320 подключений в день. За одно подключение несколко паролей.
                    • 0
                      :)) Не смешите. Полтора миллиона комбинаций в год. Даже перебор шестизначного пароля требует около 308 миллионов комбинаций.
                      • 0
                        308 миллионов — это количество разных 6-значных паролей, а не количество комбинаций, которы надо перебрать. Практика показывает, что их гораздо меньше.
                        Если бы все было так хорошо, то все бы жили с 6значными паролями и никто бы не страдал от подбора. Однако на практике периодически случаются взломы именно подбором пароля.
                        Например, на серваке может быть аккаунт пользователя, которые как правило менее параноидальны в выборе паролей.

        • 0
          У меня негативный опят общения с ним. Имеет свойство неожиданно вылетать без всяких видимых причин.
          • 0
            странно, с базовым конфигом он работает как часы
      • 0
        Ну их много разных. Сейчас я на подопечных хостах ставлю sshguard. Если вдруг больше понравится denyhosts, то буду ставить его :-)
    • 0
      Мне наоборот понравилось, что все в одном месте, не хочется, чтобы работа фаервола зависела от сторонних программ, мало ли в них какая ошибка — и привет.
      Тем более моментальная реакция на события, прямо в момент возникновения, а не когда логи будут прочитаны.
      • 0
        Вы не правы. Дважды. Во-первых, sshguard вешается как обработчик на syslog-ng (в моем случае) и читает логи без всякой задержки. Во-вторых, поскольку в линуксе нет такой отдельной активной сущности как «файервол», то настраивать правила блокировки следует как раз сторонними программами :-)
  • 0
    Слишком поднаверчено, на мой вкус.
  • +4
    Альтернативно можно использовать технику «port knocking».
    • +3
      Кстати, вот нашел симпатичный вариант:

      простейший portknock'ер работающий по icmp
      -A INPUT -p icmp --icmp-type 8 -m length --length 153 -m recent --name pk --rsource --set -j ACCEPT
      -A INPUT -p icmp --icmp-type 8 -m length --length 154 -m recent --name pk --rsource --update --hitcount 1 -j ACCEPT
      -A INPUT -p icmp --icmp-type 8 -m length --length 155 -m recent --name pk --rsource --update --hitcount 2 -j ACCEPT
      -A INPUT -p tcp --dport 22 -m recent --name pk --rsource --rcheck --hitcount 3 -j ACCEPT
      -A INPUT -p tcp --dport 22 -j DROP
      для того чтобы открыть 22 порт достаточно и необходимо
      ping -s 125 -c 1 адрес
      ping -s 126 -c 1 адрес
      ping -s 127 -c 1 адрес

      количество пакетов регулируется через --hitcount
      сами числа передаются через длину icmp-echo

      хорош тем что инструмен «стучания» обычно доступен

      отсюда
  • НЛО прилетело и опубликовало эту надпись здесь
  • 0
    Подобную штуку писал в техзадании на админку одного магазина ;)
    • 0
      На веб-морду?
      Чем реализовывали?
      • 0
        Реализовывали без меня, я только составлял требования и ТЗ. Думаю, что делали средствами php — смотрели, с какого IP идет попытка, были ли до этого неудачные и т.п.

        Я бы делал так: при третьей, скажем, неудачной попытке с одного IP вносил бы в базу IP и таймстамп.

        При попытке залогиниться проверял бы, есть ли в базе такой IP и не истекло ли время «прощения». Если истекло — сбрасываем, если не истекло — продлеваем.

        Еще бы, конечно, паттерны сканирования с разных IP предусмотреть.
        • 0
          > Еще бы, конечно, паттерны сканирования с разных IP предусмотреть.

          Достаточно делать сложные пароли, замучаются ip-адреса покупать (а самые мощные ботнеты вроде ограничены сотнями тысяч адресов).
          • 0
            Есть ботнеты из миллионов машин. Кроме того, если это ботнет из домашних компов, то у них могут быть динамические ip.
            • 0
              > то у них могут быть динамические ip.

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

              А так — можно например, после первой неправильной попытки спрашивать капчу. Причем капча включается для всех IP сразу. Миллион подборов в таком случае обойдется взломщикам в пару тысяч долларов.

              Кстати. подход с капчей можно применить и к ssh: чтобы получить доступ к ssh с опр. IP, надо сначала ввести с этого IP капчу. Всяко лучше, чем руками адрес в конфиг прописывать, а потом обнаружить что провайдер сменил IP.
              • 0
                > Обычно у провайдера небольшое кол-во динамических IP. Кроме того, из ботнета, например,
                > вполне возможно, многие компьютеры имеют общий IP, что уменьшает колисчество.
                Зависит от масщтаба провайдера. У таких как Корбина масса ипешников. Тем более идти будет из разных подсетей. Вот так по чуть-чуть и наберется громадное кол-во.

                Вариант дл всех IP плох тем, что всегда кто-то долбится — т.е. этот режим будет всегда.
            • 0
              В случае с такими большими ботнетами становится актуальным анекдот про неуловимого Джо. :)
  • НЛО прилетело и опубликовало эту надпись здесь
  • –1
    у себя везде использую вот такую конструкцию, само собой на нестандартном порту:
    iptables -A INPUT -p tcp –dport 3522 -m recent –set –name SEC –syn -m state –state NEW -j ACCEPT
    iptables -A INPUT -p tcp –dport 3522 -m recent –update –seconds 60 –hitcount 3 –rttl –name SEC -j LOG –log-prefix “BRUTE FORCE“
    iptables -A INPUT -p tcp –dport 3522 -m recent –update –seconds 60 –hitcount 3 –rttl –name SEC -j DROP

  • +2
    Если использовать авторизацию по открытому ключу, отключив авторизацию по паролю, то перебор паролей становится бессмысленным.
    • 0
      Для SSH — да. Но аналогичную технику можно использовать для любого другого сервиса, где частые попытки подключения могут говорить про атаку.
    • 0
      Самое смешное, что в локальных сетях иногда крадут ключ, и начинается игра поймай трояна :)
      • +1
        Лично я для хранения закрытых ключей от ssh использую eToken. Так что украсть его почти нереально.
        • +2
          Отлично! Можете забацать статью про етокены и ssh :) как раз интересовался этой темой + интересно иметь backup такого ключа (имеется ввиду прова на вход в систему) если один потеряется.
        • 0
          Заинтересовало. Напишете?
        • 0
          Было бы интересно посмотреть на статью о е-токенах применительно к ssh
    • 0
      Для меня и перебор пароля не опасен, но я не люблю лишней фигни от каких-то мудаков-спамеров.
  • 0
    Красиво!
  • 0
    чем это лучше fail2ban, которого можно настроить на отслеживание брутфорса и других потенциально опасных действий в отношении любого сервиса, имеющего лог файл?
    • –1
      Делается внутренними средствами фаервола, не требует внешних программ.
  • 0
    А что за RH-Firewall-1-INPUT? Нельзя ли просто написать INPUT?
    • 0
      Так называется дефолтная цепочка фаервола в RedHat/Fedora, в которую попадает трафик из INPUT. Можно прямо в INPUT поместить, важен только порядок правил.
      • 0
        Не подскажите, как в убунте будет выглядеть аналогичная, подходящая под эти два другие правила цепочка фаервола?
        • 0
          В убунте можно сразу в INPUT вставить.
  • +1
    Я использую ключи замест паролей и да по root доступ запрещен.
    • 0
      Хорошее дело.
      Но так можно защищать не только SSH, но и некоторые другие сервисы.
      Я где-то видел использование hashlimit для снижения эффекта от ДОС.
  • 0
    Я конечно извиняюсь но меня брутфорсили с разных сетей, медленно и ip адреса не повторялись в течении часа, как поможет предложенный вами вариант против такого вида атаки?
    • 0
      От такой атаки не спасет, т.к. ориентирован противодействие другому виду атак — когда с одного ip или подсети долбят.
  • 0
    Я по логам заметил, что мой сервер долбят раз в десять-двадцать минут. То есть редко и рандомом. По двадцать-сорок заходов в день. Так что хрен чем защитишься, кроме сертификатов — их я не видел чтобы подбирать пытались (:
    • 0
      Да. Но это уже не назовешь брутфорсом, очень он мягкий и вежливый.
      • 0
        И очень, сука, эффективный, в глобальных масштабах, когда у взломщиком ботнет на миллион рабов и они могут спокойно одновременно обрабатывать сотни тысяч хостов. Думаю за месяц работы они много новых «друзей» себе заводят.
        • 0
          А какое примерно общее число запросов?
          • 0
            Ну вот сегодня за семь часов 30 попыток. Пытаются подобрать разных юзеров (: Два раза пытались какой-то древний эксплоит прокатать, ничё не вышло (:
            • 0
              4 попытки в час — это очень мало. В пределах фона, как говорится. :)
              Эксплойт на ssh?
              • 0
                ну там в логах есть пару записей, что вместо аутентификации пришла белиберда. наверное что-то пытались сделать…
  • 0
    Я могу сказать за свои хосты — прямых переборов стало очень мало, когда с одного ипа пытаются подобрать вход. Сейчас с одного ипа делается 1-2 попытки, но таких подбирателей очень много.

    Так что метод немножко устарел.
    • 0
      Ну, я его внедрил в 2006 году :)
      На полном серьезе, был бы рад услышать более свежие идеи :)
  • –3
    Кстати, у меня вопрос.

    Линукс позиционируют как надежную и безопасную систему. С другой стороны, все выставленные в интернет хосты, как мы знаем, постоянно брутятся. С третьей стороны, пользователи могут ставить относительно простые пароли (для которых например хватит 10000 попыток). Вопрос, почему в популярные дистрибутивы изначально не встроена защита от этого?

    Да потому, что безопасная она только на словах, а как доходит до дела —пользователь остается один на один с врагом.
    • 0
      >Вопрос, почему в популярные дистрибутивы изначально не встроена защита от этого?
      Так ведь встроена. Убунта на даёт устанавливать пользователям пароли короче 6ти символов.
    • 0
      > Да потому, что безопасная она только на словах, а как доходит до дела —пользователь остается один на один с врагом.
      Ну вас сейчас за такое покусают :)
      На самом деле абсолютно защищенных систем нет, вот буквально сегодня пришло в твиттере:
      macradar.ru/news/mac-os-x-is-not-so-safe-anymore/

      На сегодня самое слабое звено в защите — человек. Плохой пароль, передачи пароля третьим лицам и прочее — от этого полностью не защитишься. Неважно насколбко у тебя хороший замок на двери, если ты его не закрываешь.
      Меры принимаются, например, система предупреждает о слабых паролях. От брута есть различные методики защиты, системы типа снорта и пр.
      • –1
        > Меры принимаются, например, система предупреждает о слабых паролях.

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

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

        • 0
          Есть встроенная защита. Дескотоп после нескольких попыток начинает очень медленно принимать пароли.
          • 0
            Мы с вами говорим о разных вещах. Я говорю, что любая выставденная в инет ВПСка брутится, а вы про десктоп. Да там и замедлений не надо, у вас раньше руки отвалятся пароли вводить.
            • 0
              Да, есть такое что приходится отдельно ставить защиту. Но тут нет одной «серебряной пули», которая бы решала все проблемы, поэтому каждый защищается по своему, так как видит более правильно.
              На сегодня есть какой-т программный продукт, который бы автоматически защищал от брутов?
              • –1
                > На сегодня есть какой-т программный продукт, который бы автоматически защищал от брутов?

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

                • 0
                  Как-то все очень абстрактно.
                  Что такое «декларированная надежность»?
                  Ничег абсолютно надежного нет. Сейчас в бизнесе надежной системой считается та, которую сломать дороже, чем ценность информации в ней. В военном деле — та, в которой актуальность секретов потеряется раньше, чем будет взломана.
                  Даже тут рзные критерии.
                  Линукс вам дает все инструменты, ваша задача — сделать систему надежной настолько насолько нужно именно вам.
                • 0
                  1) Хорошо, какая система защищена? Все познается в сравнении.

                  2) Всегда есть возможность решить эту проблему радикально.
                  Достаточно запретить вход по паролю. Оставить только ключи.

                  Ну и ключи без паролей не создавать, конечно.
  • 0
    Может быть я обделён врождённой паранойей, но мне кажется, что лучшая защита от брутфорса — это длинный и сложный пароль. А если пароль утёк, то никакие нестандартные порты и задержки не помогут… Храните пароли в надёжном месте, и всё будет хорошо (:
    • 0
      Эти меры помогут бороться с нецеленаправленными массовыми атаками, когда ваш сервер просто тупо долбят, авось что-нибудь да и подберется.
      Если пароль утек, то его подбирать не надо.
    • 0
      Тогда уж лучше ключ =)
      Утекший пароль это бо́льшая опасность, нежели брутфорс, конечно, но от брутфорса тоже как-то надо защищаться. Кроме того, вряд ли кому-то нравится разгребать 50-мегабайтовые логи, из которых 49,5Mb — сообщения о неудачных логинах.
  • +1
    ну добавьте ещё в плюсы —
    в отличие от sshguard-подобных штук — ваш метод не засирает iptables блокирующими правилами,
    а хранит забаненные IP внутри. причом только те, которые активны.
    • 0
      спасибо.
  • 0
    denyhosts
    • 0
      Чем это лучше?
      Оно потом чистит мусор в /etc/hosts.deny?
      • 0
        и много больше
  • 0
    Я юзаю ossec и доволен… кого надо забанит, кого надо разбанит… следит за всем, и все про всех знает…
  • +3
    MaxAuthTries,MaxSessions, и конечно, MaxStartups:
                 Specifies the maximum number of concurrent unauthenticated con-
                 nections to the SSH daemon.  Additional connections will be
                 dropped until authentication succeeds or the LoginGraceTime
                 expires for a connection.  The default is 10.
    
                 Alternatively, random early drop can be enabled by specifying the
                 three colon separated values ``start:rate:full'' (e.g.
                 "10:30:60").  sshd(8) will refuse connection attempts with a
                 probability of ``rate/100'' (30%) if there are currently
                 ``start'' (10) unauthenticated connections.  The probability
                 increases linearly and all connection attempts are refused if the
                 number of unauthenticated connections reaches ``full'' (60).
    
    • 0
      Спасибо. Добавил к статье.
  • 0
    Я использую вот этот метод: la-samhna.de/library/brutessh.html#5

    Он требует, чтобы sshd был скомпилирован с tcp_wrappers (т.е. работал с /etc/hosts.*). Вдобавок к этому скрипту доступ стоит только определённым юзерам и только по public key, а блокировка – после одной неверной попытки. Три года так живу, полёт нормальный :) Этот метод разрешает неограниченый доступ с конкретного адреса, а для всех других блокирует после определённого числа попыток (1 в моём случае).

    Может, кому–то поможет…
  • 0
    denyhost рещает часть задач.
  • 0
    большинство из указанных в статье модулей iptables просто отсутствуют в CentOS
    • 0
      Конкретно про CentOS сказать не могу, но recent весьма распространен, его можно встретить в разных дистрах на основе RH.
      Кроме того, есть такой замечательный проект patch-o-matic, где просто кладезь различных модулей для iptables.
  • +1
    отличный рецепт
  • 0
    #iptables --list пожалуйста.
    не могу разобраться с последним правилом и как настроить фаервол(убунта)
    • 0
      На бубунте стандартные список цепочек:

      # iptables --list
      Chain INPUT (policy ACCEPT)
      target prot opt source destination

      Chain FORWARD (policy ACCEPT)
      target prot opt source destination

      Chain OUTPUT (policy ACCEPT)
      target prot opt source destination

      втыкайте в инпут.
      К сожалению, нет сейчас убунты, выставленной наружу.
      • 0
        # iptables --list
        Chain INPUT (policy ACCEPT)
        target prot opt source destination
        ACCEPT tcp — anywhere anywhere tcp dpt:ssh state NEW limit: up to 1/hour burst 2 mode srcip htable-expire 60000
        DROP tcp — anywhere anywhere tcp dpt:ssh flags:SYN,RST,ACK/SYN
        ACCEPT tcp — anywhere anywhere state NEW tcp dpt:ssh

        «Счетчик» в /proc/net… появляется. Но работает кривовато (попробовал 10 раз неправильно логиниться по ssh — больше чем на 60 счетчик не увеличивается, а при обратном отсчете может как-то случайным образом прыгнуть обратно на 60сек). Ну и соответственно даёт логиниться, т.е. фаерволом не блочится ip.
        Пффф. Непростая это тема, долго надо курить ман
        • 0
          Больше чем на 60 и не должен — он должен ставиться в заданное значение.
          Случайные прыжки — это скорее всего кто-то еще пытался подключиться — у меня было так.
  • 0
    Отличный метод! Спасибо!

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