Pull to refresh

Comments 138

Спасибо. Вычитывал опечатки, а такую глупость прямо в заголовке и не заметил.
странно на первое правило в консоль плюнуло 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.
используйте recent, см ниже. Он точно должен быть.
«Я использую модуль iptables под названием hashlimit»

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

Как итог — можно зайти на главный сервер по паролю через другой. но никто не знает где этот другой и существует ли он вообще.
а напишите, что то подобное для FreeBSD =)
тут неплохой мануал настройки защиты с использованием порта sshit
bruteforceblocker-1.2.3 Checks for SSH bruteforce and blocks given IPs
Если честно, давно не работал с фрей, последнее время больше с линуксом.
У iptables дико много разных модулей: некоторые конечно совсем странные, но некоторые позволяют легко делать интересные вещи.
Можно использовать 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 —
А зачем такие сложности? Тем более, что… мм… немного ненадежно вешать логику контроля ssh на iptables. Посмотрите в сторону sshguard. Очень простая штука — парсит лог sshd и банит ip, с которых приходит много безуспешных попыток залогиниться.
Может тогда использовать denyhosts, а еще лучше denyhosts и iptables
юзаю fail2ban, вполне сухо и комфортно
Не, так неинтересно. У нас же любят изобретать велосипед :)
решению достаточно много времени, в тот момент с помощью одного recent не удавалось настроить такой «вечный» бан.
Мда немного странно, по правилу recent, если ломимся быстрее 20 секунд, вас блокируют.
Если вы опять ломитесь, вас опять блокируют :)
Чем вам не бан?
Тем, что бан протухает через 20 секунд после первой неудачной попытки. После чего мне дают вторую попытку подбора и так далее. То есть подбор идет, только чуть медленнее. Вы можете увеличить интервал до минуты, то тем самым себе создадите больше проблем в случае опечаток. Поэтому и выбрано автором значение 20 секунд.
Здесь, я могу поставить интервал в 2-3 минуты, не создав себе проблем, т.к. имею 4 попытки подключения и я могу подождать нужное время.

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

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

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

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

У меня негативный опят общения с ним. Имеет свойство неожиданно вылетать без всяких видимых причин.
странно, с базовым конфигом он работает как часы
Ну их много разных. Сейчас я на подопечных хостах ставлю sshguard. Если вдруг больше понравится denyhosts, то буду ставить его :-)
Мне наоборот понравилось, что все в одном месте, не хочется, чтобы работа фаервола зависела от сторонних программ, мало ли в них какая ошибка — и привет.
Тем более моментальная реакция на события, прямо в момент возникновения, а не когда логи будут прочитаны.
Вы не правы. Дважды. Во-первых, sshguard вешается как обработчик на syslog-ng (в моем случае) и читает логи без всякой задержки. Во-вторых, поскольку в линуксе нет такой отдельной активной сущности как «файервол», то настраивать правила блокировки следует как раз сторонними программами :-)
Альтернативно можно использовать технику «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

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

отсюда
UFO landed and left these words here
Подобную штуку писал в техзадании на админку одного магазина ;)
На веб-морду?
Чем реализовывали?
Реализовывали без меня, я только составлял требования и ТЗ. Думаю, что делали средствами php — смотрели, с какого IP идет попытка, были ли до этого неудачные и т.п.

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

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

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

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

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

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

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

Вариант дл всех IP плох тем, что всегда кто-то долбится — т.е. этот режим будет всегда.
В случае с такими большими ботнетами становится актуальным анекдот про неуловимого Джо. :)
UFO landed and left these words 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
Для меня и перебор пароля не опасен, но я не люблю лишней фигни от каких-то мудаков-спамеров.
чем это лучше fail2ban, которого можно настроить на отслеживание брутфорса и других потенциально опасных действий в отношении любого сервиса, имеющего лог файл?
Делается внутренними средствами фаервола, не требует внешних программ.
Так называется дефолтная цепочка фаервола в RedHat/Fedora, в которую попадает трафик из INPUT. Можно прямо в INPUT поместить, важен только порядок правил.
Не подскажите, как в убунте будет выглядеть аналогичная, подходящая под эти два другие правила цепочка фаервола?
В убунте можно сразу в INPUT вставить.
Я использую ключи замест паролей и да по root доступ запрещен.
Хорошее дело.
Но так можно защищать не только SSH, но и некоторые другие сервисы.
Я где-то видел использование hashlimit для снижения эффекта от ДОС.
Я конечно извиняюсь но меня брутфорсили с разных сетей, медленно и ip адреса не повторялись в течении часа, как поможет предложенный вами вариант против такого вида атаки?
От такой атаки не спасет, т.к. ориентирован противодействие другому виду атак — когда с одного ip или подсети долбят.
Я по логам заметил, что мой сервер долбят раз в десять-двадцать минут. То есть редко и рандомом. По двадцать-сорок заходов в день. Так что хрен чем защитишься, кроме сертификатов — их я не видел чтобы подбирать пытались (:
Да. Но это уже не назовешь брутфорсом, очень он мягкий и вежливый.
И очень, сука, эффективный, в глобальных масштабах, когда у взломщиком ботнет на миллион рабов и они могут спокойно одновременно обрабатывать сотни тысяч хостов. Думаю за месяц работы они много новых «друзей» себе заводят.
А какое примерно общее число запросов?
Ну вот сегодня за семь часов 30 попыток. Пытаются подобрать разных юзеров (: Два раза пытались какой-то древний эксплоит прокатать, ничё не вышло (:
4 попытки в час — это очень мало. В пределах фона, как говорится. :)
Эксплойт на ssh?
ну там в логах есть пару записей, что вместо аутентификации пришла белиберда. наверное что-то пытались сделать…
Я могу сказать за свои хосты — прямых переборов стало очень мало, когда с одного ипа пытаются подобрать вход. Сейчас с одного ипа делается 1-2 попытки, но таких подбирателей очень много.

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

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

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

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

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

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

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

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

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

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

Ну и ключи без паролей не создавать, конечно.
Может быть я обделён врождённой паранойей, но мне кажется, что лучшая защита от брутфорса — это длинный и сложный пароль. А если пароль утёк, то никакие нестандартные порты и задержки не помогут… Храните пароли в надёжном месте, и всё будет хорошо (:
Эти меры помогут бороться с нецеленаправленными массовыми атаками, когда ваш сервер просто тупо долбят, авось что-нибудь да и подберется.
Если пароль утек, то его подбирать не надо.
Тогда уж лучше ключ =)
Утекший пароль это бо́льшая опасность, нежели брутфорс, конечно, но от брутфорса тоже как-то надо защищаться. Кроме того, вряд ли кому-то нравится разгребать 50-мегабайтовые логи, из которых 49,5Mb — сообщения о неудачных логинах.
ну добавьте ещё в плюсы —
в отличие от sshguard-подобных штук — ваш метод не засирает iptables блокирующими правилами,
а хранит забаненные IP внутри. причом только те, которые активны.
Чем это лучше?
Оно потом чистит мусор в /etc/hosts.deny?
Я юзаю 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 landed and left these words here
большинство из указанных в статье модулей iptables просто отсутствуют в CentOS
Конкретно про CentOS сказать не могу, но recent весьма распространен, его можно встретить в разных дистрах на основе RH.
Кроме того, есть такой замечательный проект 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
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.
Пффф. Непростая это тема, долго надо курить ман
Больше чем на 60 и не должен — он должен ставиться в заданное значение.
Случайные прыжки — это скорее всего кто-то еще пытался подключиться — у меня было так.
Only those users with full accounts are able to leave comments. Log in, please.