[UFW BLOCK] 300 попыток соединения с разных IP за полчаса

>Что ещё можно сделать для того чтобы меня перестали спамить?
1 - Используешь ли ты сервер для своих нужд? Jabber? Почта? Персональная страничка или FTP?
2 - Если IP не постоянный, не юзаешь ли ты DDNS? Или если постоянный не прицеплен ли какой нибудь домен?
3 - Есть ли стандартные открытые порты? SSH например или VPN?

Все попытки входа идут с разных IP

Это боты на виндовых машинах.

Что делать с осевшим в логах списком IP адресов?

Если у тебя нет на локале своего репозитория и прочих ценных данных, то удаляй.
Ну а если есть хоть малейший шанс, что ломают целенаправленно - схорони.

Мне показалось, что их привлекает разрешённый ICMP.

Ещё их привлекает если в подсети светится имя хоста (nmap -sL X.X.X.* -P0)

А вообще если ты не интересная цель, то переноса сервисов на нестандартные порты вполне хватит.

denyhosts

Короче говоря, проскань ближние компы в твоем диапазоне IP, и сделай так, чтобы твоя машина вообще ничем не выделялась.
Т.е порты должны быть именно закрыты (closed) а не отфильтрованы.

Чем это полезно?

Все кто ставят на ssh пароли которые реально сбрутить - ССЗБ.
По хорошему авторизация может быть только на сертификатах.

Ну а смысла банить толпы ботов тоже нет, т.к IP у большинства динамический.

Не не не — я не интересная цель)) Спасибо за быстрый ответ. Проверил nmap'ом — вроде никак не выделяюсь.

Все кто ставят на ssh пароли которые реально сбрутить - ССЗБ.
По хорошему авторизация может быть только на сертификатах.

любые пароли и сертификаты можно сбрутить, разница только во времени, которое на это понадобится.

любая попытка авторизации отнимает ресурсы, а закрыв большинство хостов из ботнетов можно избавится от этой утечки ресурсов.

Ну а смысла банить толпы ботов тоже нет, т.к IP у большинства динамический.

это у какого такого большинства?

4899

radmin

>любые пароли и сертификаты можно сбрутить, разница только во времени, которое на это понадобится.
Ога, давай ты мне расскажешь сколько триллионов лет будут брутить мой 8192 битный RSA ключ?
При наличии настроенного под это дело fail2ban :)

любая попытка авторизации отнимает ресурсы, а закрыв большинство хостов из ботнетов можно избавится от этой утечки ресурсов.

Чтобы избавиться от случайного сканинга достаточно просто унести ssh на нестандартный порт выше 10000, хотя и какой нибудь тоже 1011 подойдет.
От намеренного сканирования тебя никакой блек лист не спасет.

это у какого такого большинства?

Да у 90% ботов вообще, кроме тех которые намеренно составляются чисто из серваков.
А от брутов с серверных мини-ботнетиков (те, что скрипты заливают и прут дальше брутить 12345 на руте) смена портов спасает на 100.0000%

А вот выходные ноды TOR/i2P/etc ты сто процентов таким образом забанишь, о чем сильно пожалеешь если тебе надо будет залезть на свой сервак из страны/провайдера, откуда доступ к подсети закрыт, ну или SSL забанен.

> По хорошему авторизация может быть только на сертификатах.

Глубоко пофигу какая аутентификация, если настроен какой-нибудь fail2ban и, к примеру, ещё port-knocking. А сертификат это не панацея.

>А сертификат это не панацея.
Ну вот говоришь - напиши почему, может я чего не знаю.
Чем нибудь кроме того, что асимметричная криптография может быть когда нибудь взломана.

PS: Большинство софта без проблем работает с RSA ключами до 8192 бит.

ubuntu? ничего не делать, это просто мусор, который и так блокирован. т.ч. расслабься и не обращай внимания.

Причём здесь асимметричная криптография? Ты путаешь взлом сессии и подбор пароля. Ещё раз, брутфорс никто не отменял. Сертификаты сами по себе не панацея. Сертификаты тупо увеличивают длину пароля. В смысле подбора пароля это количественная мера, а не качественная. Всякие port-knocking, tarpit'ы, fail2ban'ы - это качественная мера.

К тому же, запоминая пароли, разрабатываешь память ;-).

>Сертификаты тупо увеличивают длину пароля.

тупо увеличивают длину пароля.

Причём здесь асимметричная криптография?

При том, что ты кажется не понимаешь как работает авторизация по ключам.

http://www.ietf.org/rfc/rfc4252.txt
Информацию о цифровой подписи RSA сам найдешь.

port-knocking, tarpit'ы, fail2ban'ы

Это одна из мер обеспечения безопасности, я о них тоже упомянул.

Ты делаешь мне смешно.

//Всё прокомментировали до меня

> При том, что ты кажется не понимаешь как работает авторизация по ключам.

Ну, расскажи же мне в чём принципиальная разница механизма аутентификации по ключу и по паролю. Может, правда я не в курсе. И раз ты такой умный, то научись уже различать авторизацию от аутентификации. Сам найдёшь где почитать?

http://www.ietf.org/rfc/rfc4252.txt
Информацию о цифровой подписи RSA сам найдешь.

Ты опять не о том.

>И раз ты такой умный, то научись уже различать авторизацию от аутентификации. Сам найдёшь где почитать?
Тыкнул в неверный термин - спасибо, ибо моя речь и писанина ими заполнены чуть более, чем полностью.

Но вот свою позицию ты никак не обосновал, и мне реально интересно её узнать.
Если не прав буду рад узнать почему.

Ну, расскажи же мне в чём принципиальная разница механизма аутентификации по ключу и по паролю.

Во первых:
При парольной аутентификации передается ключевая фраза, которая будучи перехваченной может повторно использована.
Даже если используется хэш с уникальной солью, например, то и сервер и клиент эту соль должны знать.
В ssh пароль передается открытым текстом, и на клиенте никак не может быть защищен.

Аутентификация по ключам не требует передачи закрытого ключа серверу.
Его можно разместить на токене, который будет подписывать необходимую информацию.

Во вторых:
Я честно говоря не знаю чем именно является подпись в ssh обмене, но наверняка там реализовано так, чтобы подпись созданная (но не использованная, например) для предыдущей сессии аутентификации была не актуальна для следующей.
Например сервер может давать клиенту случайную строку которую тот должен подписать.
При этом время на ответ у клиента ограничено (в ssh точно есть), и число попыток тоже (3, вроде), после этого сессия рвется.
Новая сессия - новая строка и соответственно подпись.

Пароль же постоянно один (пока не сменили :3), и по этой причине рано или поздно его можно сбрутить.
За многими серверами не следит, а за другой частью следят люди которые не смотрят в логи.
Иногда можно целый год брутить пароль, а это уже очень сильно повышает шансы.
3 попытки, реконнект, ещё три попытки, рипит.

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

Вариант же с подбором закрытого ключа тоже почти исключен, т.к у злоумышленника не может быть открытого (он ведь как и обычный пароль передается только по SSL).

>>И раз ты такой умный, то научись уже различать авторизацию от аутентификации. Сам найдёшь где почитать?

Тыкнул в неверный термин - спасибо, ибо моя речь и писанина ими заполнены чуть более, чем полностью.

Здесь нечем гордиться. Такие вещи позволительно путать пользователям, а не тем, кто рассуждает о механизмах ssh.

Ну, расскажи же мне в чём принципиальная разница механизма аутентификации по ключу и по паролю.

Во первых:

При парольной аутентификации передается ключевая фраза, которая будучи перехваченной может повторно использована.

Есть только один адекватный способ её перехватить и это не очень просто сделать обычно. Знаешь как?

Даже если используется хэш с уникальной солью, например, то и сервер и клиент эту соль должны знать.

При чём тут хэш, salt? Ты опять не о том. Я не пойму, ты просто приплетаешь умные словечки не в попад? Здесь мало девчонок, которые могли бы это увидеть, сразу говорю.

В ssh пароль передается открытым текстом, и на клиенте никак не может быть защищен.

При чём тут защита на клиенте? Зачем его защищать на клиенте, _вообще_? Как это соотносится с безопасностью соединения? Ничего не понял.

Т.е. ты правда думаешь, что при аутентификации по паролю ssh работат как telnet, передавая чистый пароль вот так вот просто? Как тогда, вообще, отличается, в твоём понимании, ssh от telnet'а и что привело к его признанию в своё время и всеобщему использованию по сей день?

Аутентификация по ключам не требует передачи закрытого ключа серверу.

Его можно разместить на токене, который будет подписывать необходимую информацию.

А это тут при чём?

Во вторых:

Я честно говоря не знаю чем именно является подпись в ssh обмене, но наверняка там реализовано так, чтобы подпись созданная (но не использованная, например) для предыдущей сессии аутентификации была не актуальна для следующей.

Например сервер может давать клиенту случайную строку которую тот должен подписать.

При этом время на ответ у клиента ограничено (в ssh точно есть), и число попыток тоже (3, вроде), после этого сессия рвется.

Новая сессия - новая строка и соответственно подпись.

Это, вообще, чушь какая-то. Не понимаю, что ты хотел этим сказать. При чём тут кол-во попыток при аутентификации? Что там меняется?

Пароль же постоянно один (пока не сменили :3), и по этой причине рано или поздно его можно сбрутить.

За многими серверами не следит, а за другой частью следят люди которые не смотрят в логи.

Иногда можно целый год брутить пароль, а это уже очень сильно повышает шансы.

3 попытки, реконнект, ещё три попытки, рипит.

OMG...

Ну и вывод:

Так что с точки зрения брутфорс атаки: сертификат это пароль который имеет длинну X, меняется при этом каждые Y секунд, и ограничивает число попыток до Z.

Т.е энтропия такого «пароля» не просто выше обычного, а чрезвычайно выше, что делает способ подбора бессмысленным.

А вот это феерический пиздец уже. Тебя даже не смутило, что _сертификат_ меняется каждые несколько секунд по твоей версии. Как в этом случае ты залогинишься в следующий раз?

Ты в курсе, вообще, что ассиметричное шифрование используется _всегда_ (именно поэтому ssh рулит и педалит против telnet)? С парой ключей сервера и только на этапе установления соединения? Что это осуществляется только для выбора ключей для симметричных шифров, которые используются для шифрования последующего соединения? Потому, что ассиметричное шифрование ресурсо-затратно и если его использовать для всего соединения, то отклик будет как будто шелл работает через спутник на орбите марса. И разница лишь в том, что в одном случае в зашифрованной сессии передаётся пароль, а в другом - цифровая подпись.

А, ведь, ещё есть ssh protocol 1 и ssh protocol 2 и некоторые замечательные их различия.

В общем, рекомендую тебе добавить в набор умных, но не понятных слов ещё несколько: diffie-hellman, mac, hmac. Девчонок это впечатляет ;-). Очень рекомендую всё таки почитать про совершенно замечательный алгоритм diffie-hellman (а не как с rfc'шкой, на которую ты сослался, но не читал). Это производит разрыв шаблона у таких людей, когда выясняется, что можно получить ключ для симметричного шифрования сессии, вовсе, не прибегая к всесильному ассиметричному шифрованию.

Диалог это замечательно. Диалог помогает приблизится ближе к пониманию чего-то. Но я боюсь, что этот диалог приблизил к пониманию работы ssh тебя, а не меня. Мне ты пока ничего нового не сообщил. Я жду, потому что хочу тоже почерпнуть что-нибудь интересное для себя.

P.S. почитай уже, хотя бы, man sshd и прекрати писать чушь.

Я лично простым языком разложил своё понимание аутентификации sshd.
Без учета SSL который идет по верх, без учета двух протоколов, без умных словечек, именно потому, что у меня нет желания лезть в термины.
Мы тут не на симпозиуме самых крутых умов земного шара, чтобы простые вещи объяснять сложными словами :D

А свои понты кидай кому нибудь ещё, с неадекватными людьми общаться нет никакого желания.

Какой мы нежный цветочек.

Вместо нормального ответа какие-то эмоции. Что за молодёжь пошла...

1. Ты простым языком разложил какую-то чушь полную.
2. Понтовался здесь как раз ты. Я сказал, что public key не панацея, а ты сказал, что я нихрена не понимаю в этом деле. Набежали девчёнки (Chaser_Andrey) и начали рукоплескать твоим умным словечкам. А теперь оказалось, что нихрена не смыслишь ты. И всё скатилось к тому, что ты меня назвал букой. Ты какой-то скучный.

Извини, что обидел. Жаль, что разговора не получилось. Я б с радостью послушал про внутреннее устройство ssh и всё такое.

Близко к сердцу, видимо, тут принимаешь все это ты, имхо.
Я просто ответил так, как все понимаю.

Отлично изложил по какой причине по цифровой подписи выходит безопаснее.

Во вторых:

Я честно говоря не знаю чем именно является подпись в ssh обмене, но наверняка там реализовано так, чтобы подпись созданная (но не использованная, например) для предыдущей сессии аутентификации была не актуальна для следующей.

Например сервер может давать клиенту случайную строку которую тот должен подписать.

При этом время на ответ у клиента ограничено (в ssh точно есть), и число попыток тоже (3, вроде), после этого сессия рвется.

Новая сессия - новая строка и соответственно подпись.

Чего я тут не объяснил? Зачем придираться к словам?

> Я просто ответил так, как все понимаю.

Из разряда «так я вижу мир»?

Отлично изложил по какой причине по цифровой подписи выходит безопаснее.

Да, сам себя не похвалишь - никто не похвалит.

Чего я тут не объяснил?

Ты не объяснил, что делает в твоих глазах аутентификацию по паролю _принципиально_ мега-отстойней, чем по публичному ключу. Поришь чушь и показываешь полное не знание, вообще, смысла ассиметричного шифрования.

Давай, я тебе приоткрою дверь в мир ассиметричного шифрования. Основная идея его в том, что не надо боятся потери публичного ключа, в отличии от shared secret.

Пример из жизни. В рассылке разработчиков сообщаю, что ПО несколько странно себя ведёт и прошу оказать помощь, предлагая в свою очередь шелл разрабам, как помощь в поимке бага в среде, где он возникает. Разраб даёт мне свой публичный ключ (оставляя приватный из пары у себя), я его прописываю и он ко мне чудесненько попадает. И только он, а не весь список рассылки. С shared secret такое бы не прокатило.

Вот в чём плюшка ассиметричного шифрования. Рубишь?
Это ЭЦП. Про механизм установки защищённого соединения с помощью public key рассказывать не буду. Сам почитаешь, если будет желание прокачать skill.

А если я сделаю пароль 4096 бит, то его стойкость по брутфорсу будет такой же как и 4096-битных ключей, при прочих равных условиях. Вот о чём я говорил.

А минус, таки, принципиальный у пароля есть (правда и его можно исключить) и если б ты действительно понимал как работает ssh (или умел пользоваться Интернетом), ты б мне его озвучил уже.

Было б интересно услышать что-то новенькое про минусы паролей, но ты мне так ничего и не сказал. Жаль.

Зачем придираться к словам?

Все чего-то не знают, но ты понтуешься без меры. Сделал кашу. И хэш, и salt примешал и ещё кучу всего. Просто пипец. Я, вот, как раз изложил всё простыми словами, без умничанья (надеюсь, тебя не смутило shared secret).

Я тебе расскажу один случай, который мне поведал институтский препод. Дело было давно, поэтому детали не помню, но суть передать попытаюсь. Как-то, когда он был студентом, к ним приехал читать лекцию какой-то доктор наук по чему-то, вроде, матана или типа того. И тема была достаточно сложная. Этот доктор им умудрился объяснить эту сложную тему очень просто, без заумных слов, хотя, надо думать он их знал в избытке. И разница между ним и молодыми кандидатами наук, преподававшими там же, была как раз в этом. Молодые да горячие, очевидно, пытаясь произвести впечатление, заворачивали простые идеи в сложные фразы и формулировки, в непонятные слова, скрывая смысл. В общем-то, такую фигню и я замечал. Человек умничает, когда либо выёбывается, либо не знает сути.

Надо вообще учитывать, что у разных людей разный уровень знания чисто технических терминов и определений. Понты тут совершенно не причем.
Чем оперирую в жизни тем и пользуюсь в письменной речи, именно «так я вижу мир».

А минус, таки, принципиальный у пароля есть

Ну ты показал, что ты знаешь как работает аутентификация по ключам.

Ещё раз - мне совершенно по барабану на стойкость того или иного метода в вакууме.
Мне важно как оно на деле на 90% серверов с ssh, об этом я и писал.
Именно поэтому и говорил о перехвате пароля и токенах.
Пароль проще украсть, он часто бывает явно не рендомным, он часто одинаков на куче хостов, его проще удаленно брутить - для это меня факты которыми я оперирую.

Поэтому если хочешь написать ещё один пост в стиле тех что выше - не трать время.
Мне интересны реальные факты как упростить задачу взлома сервера с теми или иными параметрами, и все.

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

Не может быть. Не знал.
Не знаешь терминов - не употребляй.

Понты тут совершенно не причем.

А это что:
[UFW BLOCK] 300 попыток соединения с разных IP за полчаса (комментарий)

Чем оперирую в жизни тем и пользуюсь в письменной речи, именно «так я вижу мир».

Это-то и пугает.

Ну ты показал, что ты знаешь как работает аутентификация по ключам.

Не уверен, что знаю как она работает в точности, просто, знаю больше тебя.

...

Ты прав, но извини, ты дурак? Ты принимаешь решения без знания не то, что аутентификации по ключу, а даже без знания главной особенности ассиметричного шифрования! Хотя, для этого достаточно залезть в википедию. Ещё и гордишься этим. Чистый эникейщик.

Рекомендую меньше тусить на форуме и больше читать доков, хотя бы тех, на которые сам же даёшь ссылки. Это офигено прокачает твою икспу и повысит уважение не только среди девочек, но и среди специалистов. Инженегр должен знать как вещи устроены. Глядишь, может, через время ты мне расскажешь что-нибудь интересное о чём-нибудь и поможешь понять тонкости какого-нибудь механизма. А пока, я зря потратил своё бесценное время.

Удачи.

P.S. И брось уже эту бабскую привычку. Что за необходимость сказать последнее слово в разговоре? Уже ж всё выяснили. Форум повеселили.

Если даю ссылку на доку, то всегда предварительно читаю.
C моей точки зрения на главный вопрос ты так и не ответил, а просто развел кукую то демагогию о том чего _я_ знаю/не знаю, хотя разговор тут про пароли а не про меня. :)
Спасибо, поржал.

Ога, давай ты мне расскажешь сколько триллионов лет будут брутить мой 8192 битный RSA ключ?

man debian+openssl, от ошибок в реализации никто не застрахован.

Именно поэтому и говорил о перехвате пароля и токенах.

я к сожалению не знаю, как работает аутентификация в ssh, но в других протоколах как-то умудрились сделать аутентификацию без передачи паролей в открытом виде - man cram-md5, к примеру.

> 300 попыток соединения с разных IP за полчаса

Что ещё можно сделать для того чтобы меня перестали спамить?

Я обычно наливаю большую кружку зелёного чая, нажимаю Alt+F12 (логи у меня идут на /dev/ttyvb) и сажусь смотреть. Если сильно надоедает есть nmap и metasploit. Можно прекратить баловство.


А вообще порт кнокинг.

Вопрос в том, что так или иначе, пароль «светится» на тачке откуда исходит авторизация.
Ещё раз - теоретические возможности взлома SSL меня мало интересуют, только практика :)

Вопрос в том, что так или иначе, пароль «светится» на тачке откуда исходит авторизация.

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

Ещё раз - теоретические возможности взлома SSL меня мало интересуют, только практика :)

так это самая что ни на есть практика взлома RSA-ключей.

Если сильно надоедает есть nmap и metasploit. Можно прекратить баловство.

Спасибо за совет :) надо будет как-нибудь попробовать

>Я просто ответил так, как все понимаю.

да ты как монашка преклонных лет - православный хрен от обреза не отличаешь.