Comments 139
чА-щА
странно на первое правило в консоль плюнуло iptables: Unknown error 4294967295
Посмотрите, может у вас отсутствует модуль hashlimit.
не подскажите как ??? на самом деле iptables начал не так давно администрировать
# iptables -m hashlimit
iptables v1.3.5: You have to specify --hashlimit
Try `iptables -h' or 'iptables --help' for more information.
# iptables -m hashlimit
iptables v1.3.5: You have to specify --hashlimit
Try `iptables -h' or 'iptables --help' for more information.
используйте recent, см ниже. Он точно должен быть.
Здесь немного написано про настройку hashlimit: www.protocols.ru/Papers/iptables-tbf.shtml
«Я использую модуль iptables под названием hashlimit»
у Вас его может ещё не быть
у Вас его может ещё не быть
У меня запрещён рут, и в настройках ssh стоит отлуп после двух неудачных попыток. Судя по логам долбят всяких стандартных юзеров, типа john, alex и тп, причём каждый логин меняется при каждом подключении. Так что я думаю танцы с iptables излишни и 20 секунд блокировки вполне спасут от перебора.
От перебора изумительно защищает аутентификация по ключу.
Иногда доступ к серваку нужен из самых неожиданных мест :)
Не всегда есть возможность вставить флешку с ключем, с другой стороны файл можно украсть.
Но есть можно украсть файл, то можно и пароль перехватить.
Но есть можно украсть файл, то можно и пароль перехватить.
Согласитесь, что и украсть файл с ключом, и собрать кейлоггером пароль — труднее, нежели сделать что-то одно из этого?
В теории да, а на практите это может делаться после порутания машины — после чего все одинаково просто :)
Я скорее к тому, что если мне срочно нужно зайти откуда-то (будучи в гостях, например) на сервер по ssh, то я предпочту на чужой машине не просто вводить пароль, а вводить пароль к ключу на той же флешке. Именно с точки зрения практики — это лучше. С точки зрения теории — понятно, что как раз всё равно ;)
Да, психологически так чувствуешь себя спокойнее :)
А еще можно сделать так:
— К главному серверу доступ только по ключу.
— Ключ от главного сервера только на втором сервере о котором никто не знает кроме админа.
— Доступ на второй сервер по паролю возможен.
Как итог — можно зайти на главный сервер по паролю через другой. но никто не знает где этот другой и существует ли он вообще.
— К главному серверу доступ только по ключу.
— Ключ от главного сервера только на втором сервере о котором никто не знает кроме админа.
— Доступ на второй сервер по паролю возможен.
Как итог — можно зайти на главный сервер по паролю через другой. но никто не знает где этот другой и существует ли он вообще.
Если пароль не банальный и его составитель хоть немного запарился (а это обязаны контролировать некоторые люди), то перебор по ssh невозможен. Недавно кто-то из Германии пытался подобрать пароль. Никакого fail2bun / задержки на компьютере не стояло. Атака на компьютере длилась 55 минут, то есть 3300 секунд. За это время было попробывано 15846 паролей, для моего пользователя (с крайне секретным названием "user") - 125. Получается 125 паролей за 3300 секунд, то есть 0,04 пароля в секунду. Да даже если учесть, что все попытки были в моего пользователя, а не в воздух (а это, по факту, очень маловероятно), то получается 4.8 паролей в секунду. Удачи с такой скоростью найти что-то к тепловой смерти вселенной.
а напишите, что то подобное для FreeBSD =)
тут неплохой мануал настройки защиты с использованием порта sshit
Конкретно для ipfw =)
bruteforceblocker-1.2.3 Checks for SSH bruteforce and blocks given IPs
Если честно, давно не работал с фрей, последнее время больше с линуксом.
У iptables дико много разных модулей: некоторые конечно совсем странные, но некоторые позволяют легко делать интересные вещи.
У iptables дико много разных модулей: некоторые конечно совсем странные, но некоторые позволяют легко делать интересные вещи.
sshguard еще есть
Можно использовать 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 —
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 —
А зачем такие сложности? Тем более, что… мм… немного ненадежно вешать логику контроля ssh на iptables. Посмотрите в сторону sshguard. Очень простая штука — парсит лог sshd и банит ip, с которых приходит много безуспешных попыток залогиниться.
Может тогда использовать denyhosts, а еще лучше denyhosts и iptables
юзаю fail2ban, вполне сухо и комфортно
UFO just landed and posted this here
решению достаточно много времени, в тот момент с помощью одного recent не удавалось настроить такой «вечный» бан.
Мда немного странно, по правилу recent, если ломимся быстрее 20 секунд, вас блокируют.
Если вы опять ломитесь, вас опять блокируют :)
Чем вам не бан?
Если вы опять ломитесь, вас опять блокируют :)
Чем вам не бан?
Тем, что бан протухает через 20 секунд после первой неудачной попытки. После чего мне дают вторую попытку подбора и так далее. То есть подбор идет, только чуть медленнее. Вы можете увеличить интервал до минуты, то тем самым себе создадите больше проблем в случае опечаток. Поэтому и выбрано автором значение 20 секунд.
Здесь, я могу поставить интервал в 2-3 минуты, не создав себе проблем, т.к. имею 4 попытки подключения и я могу подождать нужное время.
Вся соль в том, что брутфорсер не ждет, он нагло долбится и не получает ровным счетом ничего. Вот было у него 4 изначальных попытки и все. Он после этого может долбиться год, не получив ни одного нового шанса.
Здесь, я могу поставить интервал в 2-3 минуты, не создав себе проблем, т.к. имею 4 попытки подключения и я могу подождать нужное время.
Вся соль в том, что брутфорсер не ждет, он нагло долбится и не получает ровным счетом ничего. Вот было у него 4 изначальных попытки и все. Он после этого может долбиться год, не получив ни одного нового шанса.
>Вся соль в том, что брутфорсер не ждет, он нагло долбится и не получает ровным счетом ничего.
вообще то на дворе 21 век, брутфорсер-ы поумнели…
вообще то на дворе 21 век, брутфорсер-ы поумнели…
Они могут адаптивно подбирать время между подключениями?
Хотелось бы подробнее узнать про это.
Хотелось бы подробнее узнать про это.
С другой стороны я могу поставить интервал в 5 минут. Чтобы его найти брутеру потребутся какое-то время.
Но, конечно, если атака идет с разных ип, то тут трудно выловить.
Но, конечно, если атака идет с разных ип, то тут трудно выловить.
тут вот читал www.opennet.ru/opennews/art.shtml?num=24276 и примерно в тоже время заметил похожую активность в логах, ip практически не повторялись…
Да с разных хостов ловить трудно.
спасибо за ссылку, нашел хороший вариант port knocking: habrahabr.ru/blogs/sysadm/88461/?reply_to=2653368#comment_2653463
спасибо за ссылку, нашел хороший вариант port knocking: habrahabr.ru/blogs/sysadm/88461/?reply_to=2653368#comment_2653463
Кто мешает боту так же ждать в вашем случаи?
Никто не мешает. Вопрос в том — сколько ждать?
Если много, то это делает перебор неэффективным (кому нужен брутфорс с одним паролем в 5 минут?), если мало, то он вообще останавливается.
Можно конечно опытным путем подобрать интервал, скажем, если брутфорсер заметил, что попал в бан, то увеличивать интервал в 2 раза.
Если много, то это делает перебор неэффективным (кому нужен брутфорс с одним паролем в 5 минут?), если мало, то он вообще останавливается.
Можно конечно опытным путем подобрать интервал, скажем, если брутфорсер заметил, что попал в бан, то увеличивать интервал в 2 раза.
В общем общие мнение думаю такое, нужно все же или усложнять правило или ставить дополнительное средство.
Да хорошая мысль.
Есть еще вариант, после этого правила поставить другое правило с увеличенным до 1 часа минут интервалом. Он будет накапливать попытки подключения и сбрасывать их гораздо медленнее, тогда как только его предел превысится, он надолго залочит пользователя. Наврядли имеет смысл делать больше часа. 100 паролей в день — это не брутфорс. Таким образом за год можно проверить всего 35 тысяч, а за это время админ должен успеть поменять пароль.
Есть еще вариант, после этого правила поставить другое правило с увеличенным до 1 часа минут интервалом. Он будет накапливать попытки подключения и сбрасывать их гораздо медленнее, тогда как только его предел превысится, он надолго залочит пользователя. Наврядли имеет смысл делать больше часа. 100 паролей в день — это не брутфорс. Таким образом за год можно проверить всего 35 тысяч, а за это время админ должен успеть поменять пароль.
Тем, что бан протухает через 20 секунд после первой неудачной попытки.Если точнее, то с момента последней, т.к. стоит --update. И recent так же позволяет допускать несколько попыток с помощью опции --hitcount и свободно изменять срок бана.
Можно и так.
Просто когда это делалось в 2006 году я не нашел опции --update.
В любом случае здесь главное идея. Фильтрация не на основе ip-адреса, а на основе наглости лезущего :)
Просто когда это делалось в 2006 году я не нашел опции --update.
В любом случае здесь главное идея. Фильтрация не на основе ip-адреса, а на основе наглости лезущего :)
Так ведь и recent детектит активность атакующего, не учитывая ip.
как не учитывая? Тогда весь смысл теряется.
Хы. Не поняли друг друга.
Хотел сказать, что, принимая решение о бане, recent оценивает активность с конкретного адреса, а не то, каков адрес.
Hashlimit же у Вас делает то же самое?
Хотел сказать, что, принимая решение о бане, recent оценивает активность с конкретного адреса, а не то, каков адрес.
Hashlimit же у Вас делает то же самое?
Да, тоже самое, отбор по активности, скорее даже по продолжению активности после попадания в бан. «Добропорядочный» заранее извещен об этом и должен прекратить попытки, а «злой» предполагается будет лезть дальше.
А вот тут еще мысль возникла: банить без бана. То есть не блокировать новые попытки подключения, а направлять на фейковый ssh, который на любую попытку будет отвечать «неверный пароль». Таким образом атакующий не должен понять, что его «забанили», но продолжением своей чрезмерной активности будет продлевать свой бан.
А вот тут еще мысль возникла: банить без бана. То есть не блокировать новые попытки подключения, а направлять на фейковый ssh, который на любую попытку будет отвечать «неверный пароль». Таким образом атакующий не должен понять, что его «забанили», но продолжением своей чрезмерной активности будет продлевать свой бан.
В любом случае здесь главное идея. Фильтрация не на основе ip-адреса, а на основе наглости лезущего :)Все понял, этими словами Вы не противопоставляете принцип hashlimit принципу recent, а выделяете их на фоне остальных средств.
Тяжелый у меня был день =)
И много наподбираете с паузой в 20 секунд между попытками?
Посчитайте. 3*60*24 = 4320 подключений в день. За одно подключение несколко паролей.
:)) Не смешите. Полтора миллиона комбинаций в год. Даже перебор шестизначного пароля требует около 308 миллионов комбинаций.
308 миллионов — это количество разных 6-значных паролей, а не количество комбинаций, которы надо перебрать. Практика показывает, что их гораздо меньше.
Если бы все было так хорошо, то все бы жили с 6значными паролями и никто бы не страдал от подбора. Однако на практике периодически случаются взломы именно подбором пароля.
Например, на серваке может быть аккаунт пользователя, которые как правило менее параноидальны в выборе паролей.
Если бы все было так хорошо, то все бы жили с 6значными паролями и никто бы не страдал от подбора. Однако на практике периодически случаются взломы именно подбором пароля.
Например, на серваке может быть аккаунт пользователя, которые как правило менее параноидальны в выборе паролей.
У меня негативный опят общения с ним. Имеет свойство неожиданно вылетать без всяких видимых причин.
Ну их много разных. Сейчас я на подопечных хостах ставлю sshguard. Если вдруг больше понравится denyhosts, то буду ставить его :-)
Мне наоборот понравилось, что все в одном месте, не хочется, чтобы работа фаервола зависела от сторонних программ, мало ли в них какая ошибка — и привет.
Тем более моментальная реакция на события, прямо в момент возникновения, а не когда логи будут прочитаны.
Тем более моментальная реакция на события, прямо в момент возникновения, а не когда логи будут прочитаны.
Слишком поднаверчено, на мой вкус.
Альтернативно можно использовать технику «port knocking».
Кстати, вот нашел симпатичный вариант:
простейший 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
хорош тем что инструмен «стучания» обычно доступен
отсюда
простейший 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
хорош тем что инструмен «стучания» обычно доступен
отсюда
UFO just landed and posted this here
как вариант использовать Vuurmuur habrahabr.ru/blogs/linux/86844/
Все остальное (GUI именно) очень ограниченны в настройках.
Все остальное (GUI именно) очень ограниченны в настройках.
Подобную штуку писал в техзадании на админку одного магазина ;)
На веб-морду?
Чем реализовывали?
Чем реализовывали?
Реализовывали без меня, я только составлял требования и ТЗ. Думаю, что делали средствами php — смотрели, с какого IP идет попытка, были ли до этого неудачные и т.п.
Я бы делал так: при третьей, скажем, неудачной попытке с одного IP вносил бы в базу IP и таймстамп.
При попытке залогиниться проверял бы, есть ли в базе такой IP и не истекло ли время «прощения». Если истекло — сбрасываем, если не истекло — продлеваем.
Еще бы, конечно, паттерны сканирования с разных IP предусмотреть.
Я бы делал так: при третьей, скажем, неудачной попытке с одного IP вносил бы в базу IP и таймстамп.
При попытке залогиниться проверял бы, есть ли в базе такой IP и не истекло ли время «прощения». Если истекло — сбрасываем, если не истекло — продлеваем.
Еще бы, конечно, паттерны сканирования с разных IP предусмотреть.
> Еще бы, конечно, паттерны сканирования с разных IP предусмотреть.
Достаточно делать сложные пароли, замучаются ip-адреса покупать (а самые мощные ботнеты вроде ограничены сотнями тысяч адресов).
Достаточно делать сложные пароли, замучаются ip-адреса покупать (а самые мощные ботнеты вроде ограничены сотнями тысяч адресов).
Есть ботнеты из миллионов машин. Кроме того, если это ботнет из домашних компов, то у них могут быть динамические ip.
> то у них могут быть динамические ip.
Обычно у провайдера небольшое кол-во динамических IP. Кроме того, из ботнета, например, вполне возможно, многие компьютеры имеют общий IP, что уменьшает колисчество.
А так — можно например, после первой неправильной попытки спрашивать капчу. Причем капча включается для всех IP сразу. Миллион подборов в таком случае обойдется взломщикам в пару тысяч долларов.
Кстати. подход с капчей можно применить и к ssh: чтобы получить доступ к ssh с опр. IP, надо сначала ввести с этого IP капчу. Всяко лучше, чем руками адрес в конфиг прописывать, а потом обнаружить что провайдер сменил IP.
Обычно у провайдера небольшое кол-во динамических IP. Кроме того, из ботнета, например, вполне возможно, многие компьютеры имеют общий IP, что уменьшает колисчество.
А так — можно например, после первой неправильной попытки спрашивать капчу. Причем капча включается для всех IP сразу. Миллион подборов в таком случае обойдется взломщикам в пару тысяч долларов.
Кстати. подход с капчей можно применить и к ssh: чтобы получить доступ к ssh с опр. IP, надо сначала ввести с этого IP капчу. Всяко лучше, чем руками адрес в конфиг прописывать, а потом обнаружить что провайдер сменил IP.
> Обычно у провайдера небольшое кол-во динамических IP. Кроме того, из ботнета, например,
> вполне возможно, многие компьютеры имеют общий IP, что уменьшает колисчество.
Зависит от масщтаба провайдера. У таких как Корбина масса ипешников. Тем более идти будет из разных подсетей. Вот так по чуть-чуть и наберется громадное кол-во.
Вариант дл всех IP плох тем, что всегда кто-то долбится — т.е. этот режим будет всегда.
> вполне возможно, многие компьютеры имеют общий IP, что уменьшает колисчество.
Зависит от масщтаба провайдера. У таких как Корбина масса ипешников. Тем более идти будет из разных подсетей. Вот так по чуть-чуть и наберется громадное кол-во.
Вариант дл всех IP плох тем, что всегда кто-то долбится — т.е. этот режим будет всегда.
В случае с такими большими ботнетами становится актуальным анекдот про неуловимого Джо. :)
UFO just landed and posted this here
у себя везде использую вот такую конструкцию, само собой на нестандартном порту:
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
Если использовать авторизацию по открытому ключу, отключив авторизацию по паролю, то перебор паролей становится бессмысленным.
Для SSH — да. Но аналогичную технику можно использовать для любого другого сервиса, где частые попытки подключения могут говорить про атаку.
Самое смешное, что в локальных сетях иногда крадут ключ, и начинается игра поймай трояна :)
Лично я для хранения закрытых ключей от ssh использую eToken. Так что украсть его почти нереально.
Отлично! Можете забацать статью про етокены и ssh :) как раз интересовался этой темой + интересно иметь backup такого ключа (имеется ввиду прова на вход в систему) если один потеряется.
Заинтересовало. Напишете?
Было бы интересно посмотреть на статью о е-токенах применительно к ssh
собственно вот: core.habrahabr.ru/blog/88540/
Для меня и перебор пароля не опасен, но я не люблю лишней фигни от каких-то мудаков-спамеров.
UFO just landed and posted this here
чем это лучше fail2ban, которого можно настроить на отслеживание брутфорса и других потенциально опасных действий в отношении любого сервиса, имеющего лог файл?
UFO just landed and posted this here
Я использую ключи замест паролей и да по root доступ запрещен.
Я конечно извиняюсь но меня брутфорсили с разных сетей, медленно и ip адреса не повторялись в течении часа, как поможет предложенный вами вариант против такого вида атаки?
Я по логам заметил, что мой сервер долбят раз в десять-двадцать минут. То есть редко и рандомом. По двадцать-сорок заходов в день. Так что хрен чем защитишься, кроме сертификатов — их я не видел чтобы подбирать пытались (:
Да. Но это уже не назовешь брутфорсом, очень он мягкий и вежливый.
И очень, сука, эффективный, в глобальных масштабах, когда у взломщиком ботнет на миллион рабов и они могут спокойно одновременно обрабатывать сотни тысяч хостов. Думаю за месяц работы они много новых «друзей» себе заводят.
Я могу сказать за свои хосты — прямых переборов стало очень мало, когда с одного ипа пытаются подобрать вход. Сейчас с одного ипа делается 1-2 попытки, но таких подбирателей очень много.
Так что метод немножко устарел.
Так что метод немножко устарел.
Кстати, у меня вопрос.
Линукс позиционируют как надежную и безопасную систему. С другой стороны, все выставленные в интернет хосты, как мы знаем, постоянно брутятся. С третьей стороны, пользователи могут ставить относительно простые пароли (для которых например хватит 10000 попыток). Вопрос, почему в популярные дистрибутивы изначально не встроена защита от этого?
Да потому, что безопасная она только на словах, а как доходит до дела —пользователь остается один на один с врагом.
Линукс позиционируют как надежную и безопасную систему. С другой стороны, все выставленные в интернет хосты, как мы знаем, постоянно брутятся. С третьей стороны, пользователи могут ставить относительно простые пароли (для которых например хватит 10000 попыток). Вопрос, почему в популярные дистрибутивы изначально не встроена защита от этого?
Да потому, что безопасная она только на словах, а как доходит до дела —пользователь остается один на один с врагом.
>Вопрос, почему в популярные дистрибутивы изначально не встроена защита от этого?
Так ведь встроена. Убунта на даёт устанавливать пользователям пароли короче 6ти символов.
Так ведь встроена. Убунта на даёт устанавливать пользователям пароли короче 6ти символов.
> Да потому, что безопасная она только на словах, а как доходит до дела —пользователь остается один на один с врагом.
Ну вас сейчас за такое покусают :)
На самом деле абсолютно защищенных систем нет, вот буквально сегодня пришло в твиттере:
macradar.ru/news/mac-os-x-is-not-so-safe-anymore/
На сегодня самое слабое звено в защите — человек. Плохой пароль, передачи пароля третьим лицам и прочее — от этого полностью не защитишься. Неважно насколбко у тебя хороший замок на двери, если ты его не закрываешь.
Меры принимаются, например, система предупреждает о слабых паролях. От брута есть различные методики защиты, системы типа снорта и пр.
Ну вас сейчас за такое покусают :)
На самом деле абсолютно защищенных систем нет, вот буквально сегодня пришло в твиттере:
macradar.ru/news/mac-os-x-is-not-so-safe-anymore/
На сегодня самое слабое звено в защите — человек. Плохой пароль, передачи пароля третьим лицам и прочее — от этого полностью не защитишься. Неважно насколбко у тебя хороший замок на двери, если ты его не закрываешь.
Меры принимаются, например, система предупреждает о слабых паролях. От брута есть различные методики защиты, системы типа снорта и пр.
> Меры принимаются, например, система предупреждает о слабых паролях.
Это такие же меры, как наше правительство принимает по броьбе с коррупцией. Почему нет встроеннной защиты от перебора? Потому что пользователям дается возможность спасаться как хотят.
Спасибо, хоть по дефолту не ставят кучу дырявых сервисов с открытыми портами, как в винде, ибо система, которой без фаерволла пользоваться нельзя, это вообще позор разработчика.
Это такие же меры, как наше правительство принимает по броьбе с коррупцией. Почему нет встроеннной защиты от перебора? Потому что пользователям дается возможность спасаться как хотят.
Спасибо, хоть по дефолту не ставят кучу дырявых сервисов с открытыми портами, как в винде, ибо система, которой без фаерволла пользоваться нельзя, это вообще позор разработчика.
Есть встроенная защита. Дескотоп после нескольких попыток начинает очень медленно принимать пароли.
Мы с вами говорим о разных вещах. Я говорю, что любая выставденная в инет ВПСка брутится, а вы про десктоп. Да там и замедлений не надо, у вас раньше руки отвалятся пароли вводить.
Да, есть такое что приходится отдельно ставить защиту. Но тут нет одной «серебряной пули», которая бы решала все проблемы, поэтому каждый защищается по своему, так как видит более правильно.
На сегодня есть какой-т программный продукт, который бы автоматически защищал от брутов?
На сегодня есть какой-т программный продукт, который бы автоматически защищал от брутов?
> На сегодня есть какой-т программный продукт, который бы автоматически защищал от брутов?
Понятия не имею, но то, что Линукс абсолютно не защищен от банального брута, никак не вяжется с декларируемой защищенностью.
Понятия не имею, но то, что Линукс абсолютно не защищен от банального брута, никак не вяжется с декларируемой защищенностью.
Как-то все очень абстрактно.
Что такое «декларированная надежность»?
Ничег абсолютно надежного нет. Сейчас в бизнесе надежной системой считается та, которую сломать дороже, чем ценность информации в ней. В военном деле — та, в которой актуальность секретов потеряется раньше, чем будет взломана.
Даже тут рзные критерии.
Линукс вам дает все инструменты, ваша задача — сделать систему надежной настолько насолько нужно именно вам.
Что такое «декларированная надежность»?
Ничег абсолютно надежного нет. Сейчас в бизнесе надежной системой считается та, которую сломать дороже, чем ценность информации в ней. В военном деле — та, в которой актуальность секретов потеряется раньше, чем будет взломана.
Даже тут рзные критерии.
Линукс вам дает все инструменты, ваша задача — сделать систему надежной настолько насолько нужно именно вам.
1) Хорошо, какая система защищена? Все познается в сравнении.
2) Всегда есть возможность решить эту проблему радикально.
Достаточно запретить вход по паролю. Оставить только ключи.
Ну и ключи без паролей не создавать, конечно.
2) Всегда есть возможность решить эту проблему радикально.
Достаточно запретить вход по паролю. Оставить только ключи.
Ну и ключи без паролей не создавать, конечно.
Может быть я обделён врождённой паранойей, но мне кажется, что лучшая защита от брутфорса — это длинный и сложный пароль. А если пароль утёк, то никакие нестандартные порты и задержки не помогут… Храните пароли в надёжном месте, и всё будет хорошо (:
Эти меры помогут бороться с нецеленаправленными массовыми атаками, когда ваш сервер просто тупо долбят, авось что-нибудь да и подберется.
Если пароль утек, то его подбирать не надо.
Если пароль утек, то его подбирать не надо.
Тогда уж лучше ключ =)
Утекший пароль это бо́льшая опасность, нежели брутфорс, конечно, но от брутфорса тоже как-то надо защищаться. Кроме того, вряд ли кому-то нравится разгребать 50-мегабайтовые логи, из которых 49,5Mb — сообщения о неудачных логинах.
Утекший пароль это бо́льшая опасность, нежели брутфорс, конечно, но от брутфорса тоже как-то надо защищаться. Кроме того, вряд ли кому-то нравится разгребать 50-мегабайтовые логи, из которых 49,5Mb — сообщения о неудачных логинах.
ну добавьте ещё в плюсы —
в отличие от sshguard-подобных штук — ваш метод не засирает iptables блокирующими правилами,
а хранит забаненные IP внутри. причом только те, которые активны.
в отличие от sshguard-подобных штук — ваш метод не засирает iptables блокирующими правилами,
а хранит забаненные IP внутри. причом только те, которые активны.
denyhosts
Я юзаю ossec и доволен… кого надо забанит, кого надо разбанит… следит за всем, и все про всех знает…
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).
UFO just landed and posted this here
denyhost рещает часть задач.
большинство из указанных в статье модулей iptables просто отсутствуют в CentOS
Конкретно про CentOS сказать не могу, но recent весьма распространен, его можно встретить в разных дистрах на основе RH.
Кроме того, есть такой замечательный проект patch-o-matic, где просто кладезь различных модулей для iptables.
Кроме того, есть такой замечательный проект patch-o-matic, где просто кладезь различных модулей для iptables.
отличный рецепт
#iptables --list пожалуйста.
не могу разобраться с последним правилом и как настроить фаервол(убунта)
не могу разобраться с последним правилом и как настроить фаервол(убунта)
На бубунте стандартные список цепочек:
# 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
втыкайте в инпут.
К сожалению, нет сейчас убунты, выставленной наружу.
# 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
втыкайте в инпут.
К сожалению, нет сейчас убунты, выставленной наружу.
# 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.
Пффф. Непростая это тема, долго надо курить ман
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.
Пффф. Непростая это тема, долго надо курить ман
Отличный метод! Спасибо!
Sign up to leave a comment.
Защищаем SSH от брутфорса на любом порту