Легенда:
 новое сообщение
 закрытая нитка
 новое сообщение
 в закрытой нитке
 старое сообщение
|
- Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
- Новичкам также крайне полезно ознакомиться с данным документом.
|
Вопрос про SSH и его брутофорс 16.04.02 08:34 Число просмотров: 1447
Автор: cybervlad <cybervlad> Статус: Elderman
|
> С SSH практически не работал, поэтому пара вопросов:
не работал - это понятно. но вот доку почему не почитал?
> 1. Может ли SSH-сервер принимать одновременно несколько
> логонов на _одного и того же_ юзера?
> А на разные, но одновременно?
а где написано, что нельзя? количество обслуживаемых соединений обычно определяется мощностью сервера и толщиной канала. в принципе, средствами ОС можно ввести упомянутые тобой ограницения на коннект к определенному порту (в данном случае - 22). но нафига?
> 2. Сколько одновременных соединений обычно позволяют
> серверы к SSH? (С одного IP / вообще со всех адресов)
сколько выдержит сервер/канал.
> 3. Какова приблизительная скорость перебора паролей к
> логину, если предположить, что атакующий имеет толстый
> канал?
а причем тут пароль? ssh закрывает сессию путем шифрования. если атакующий установил соединение (зашифрованне) с сервером, то дальше его задача таже, что и при работе по обычному telnet. накладные расходы на установление защищенного соединения перед запросом пароля - ничто, по сравнению с паузой, возникающей после неправильного его ввода. про число попыток входа с неправильным паролем слышал? так что флаг в руки.
если вход настроен с аутентификацией по ключу, то флаг тебе в руки. почитай у меня на паге перевод на тему перебора: http://cybervlad.port5.com/faq-cle/index.html
> 4. Что будет быстрее: брутофорсить SSH, или HTTP через
> CGI-скрипт? И насколько будет медленнее перебор, если
> вместо http используется HTTPS ?
что значит "http через cgi"? соображения насчет http vs https такие же, как насчет ssh vs telnet.
> Длина ключа у SSH, как и у HTTPS предполагается 128 Bit
тебе хватит ;)
> Интересно оценить защиту системы теоретически.
теоретически вывод очевиден: "в лоб" (brute force) тут нечего делать.
|
|
<hacking>
|
Вопрос про SSH и его брутофорс 16.04.02 02:39
Автор: Renkvil <Boris> Статус: Member
|
С SSH практически не работал, поэтому пара вопросов:
1. Может ли SSH-сервер принимать одновременно несколько логонов на _одного и того же_ юзера?
А на разные, но одновременно?
2. Сколько одновременных соединений обычно позволяют серверы к SSH? (С одного IP / вообще со всех адресов)
3. Какова приблизительная скорость перебора паролей к логину, если предположить, что атакующий имеет толстый канал?
4. Что будет быстрее: брутофорсить SSH, или HTTP через CGI-скрипт? И насколько будет медленнее перебор, если вместо http используется HTTPS ?
Длина ключа у SSH, как и у HTTPS предполагается 128 Bit
Интересно оценить защиту системы теоретически.
Спасибо заранее,
Борис.
|
|
Вопрос про SSH и его брутофорс 16.04.02 08:34
Автор: cybervlad <cybervlad> Статус: Elderman
|
> С SSH практически не работал, поэтому пара вопросов:
не работал - это понятно. но вот доку почему не почитал?
> 1. Может ли SSH-сервер принимать одновременно несколько
> логонов на _одного и того же_ юзера?
> А на разные, но одновременно?
а где написано, что нельзя? количество обслуживаемых соединений обычно определяется мощностью сервера и толщиной канала. в принципе, средствами ОС можно ввести упомянутые тобой ограницения на коннект к определенному порту (в данном случае - 22). но нафига?
> 2. Сколько одновременных соединений обычно позволяют
> серверы к SSH? (С одного IP / вообще со всех адресов)
сколько выдержит сервер/канал.
> 3. Какова приблизительная скорость перебора паролей к
> логину, если предположить, что атакующий имеет толстый
> канал?
а причем тут пароль? ssh закрывает сессию путем шифрования. если атакующий установил соединение (зашифрованне) с сервером, то дальше его задача таже, что и при работе по обычному telnet. накладные расходы на установление защищенного соединения перед запросом пароля - ничто, по сравнению с паузой, возникающей после неправильного его ввода. про число попыток входа с неправильным паролем слышал? так что флаг в руки.
если вход настроен с аутентификацией по ключу, то флаг тебе в руки. почитай у меня на паге перевод на тему перебора: http://cybervlad.port5.com/faq-cle/index.html
> 4. Что будет быстрее: брутофорсить SSH, или HTTP через
> CGI-скрипт? И насколько будет медленнее перебор, если
> вместо http используется HTTPS ?
что значит "http через cgi"? соображения насчет http vs https такие же, как насчет ssh vs telnet.
> Длина ключа у SSH, как и у HTTPS предполагается 128 Bit
тебе хватит ;)
> Интересно оценить защиту системы теоретически.
теоретически вывод очевиден: "в лоб" (brute force) тут нечего делать.
|
| |
Вопрос про SSH и его брутофорс 16.04.02 20:16
Автор: Renkvil <Boris> Статус: Member
|
> > С SSH практически не работал, поэтому пара вопросов:
> не работал - это понятно. но вот доку почему не почитал?
Смотрел.
Мне же нужна была инфа людей из опыта, в доках этого нет.
> > 1. Может ли SSH-сервер принимать одновременно
> несколько
> > логонов на _одного и того же_ юзера?
> > А на разные, но одновременно?
> а где написано, что нельзя? количество обслуживаемых
> соединений обычно определяется мощностью сервера и толщиной
> канала. в принципе, средствами ОС можно ввести упомянутые
> тобой ограницения на коннект к определенному порту (в
> данном случае - 22). но нафига?
Т.е. на один логон могут одновременно приниматься одновременные попытки?
> > 2. Сколько одновременных соединений обычно позволяют
> > серверы к SSH? (С одного IP / вообще со всех адресов)
> сколько выдержит сервер/канал.
Я забыл выделить слово "обычно" - оно и есть суть этого вопроса :)
Т.е. на что рассчитывать - 10, 100, 1000 ... (однновременных коннектов)
> > 3. Какова приблизительная скорость перебора паролей к
> > логину, если предположить, что атакующий имеет толстый
> > канал?
> а причем тут пароль? ssh закрывает сессию путем шифрования.
> если атакующий установил соединение (зашифрованне) с
> сервером, то дальше его задача таже, что и при работе по
> обычному telnet.
Вопрос, конечно, имеет много общего с BF по telnet'у :)
> паузой, возникающей после неправильного его ввода.
Вот поэтому я и спрашиваю про одновременные соединения.
> про число попыток входа с неправильным паролем слышал?
И что происходит?
Банится IP? - это не самое страшное (разные компы)
На сколько секунд?
Если банится возможность залогиниться под атакованным юзером - им же хуже (такое на недавно нашли buggzy и 3APA3A в FTGate) - юзер не войдёт :)
> http://cybervlad.port5.com/faq-cle/index.html
Уже вчера читал :)
Кстати очень интересно!
> > 4. Что будет быстрее: брутофорсить SSH, или HTTP через
> > CGI-скрипт? И насколько будет медленнее перебор, если
> > вместо http используется HTTPS ?
> что значит "http через cgi"?
Что пароли проверяет CGI скрипт по HTTP-протоколу.
> соображения насчет http vs
> https такие же, как насчет ssh vs telnet.
Ясно.
А в процентах, или слишком ничтожная разница?
> > Длина ключа у SSH, как и у HTTPS предполагается 128 Bit
> тебе хватит ;)
В данном случае длинны пароля важна не с точки зрения криптографии, а лишь как "избыток" по сравнению с telnet/HTTP.
> > Интересно оценить защиту системы теоретически.
> теоретически вывод очевиден: "в лоб" (brute force) тут
^^^^^^^^^^^^
> нечего делать.
Во-во.
А если, положим, мне известна общая маска пароля, редуцируя количество необходимых итераций на тысячи?
Борис
З.Ы. Спасибо за ответы!
|
| | |
Вопрос про SSH и его брутофорс 17.04.02 09:25
Автор: cybervlad <cybervlad> Статус: Elderman
|
> Смотрел.
> Мне же нужна была инфа людей из опыта, в доках этого нет.
есть. но не в тех ;)
> > тобой ограницения на коннект к определенному порту (в
> > данном случае - 22). но нафига?
>
> Т.е. на один логон могут одновременно приниматься
> одновременные попытки?
что ты понимаешь под "логон"? аккаунт?
это можно ограничить. но это делается другими средствами ОС, ssh тут не причем...
> > > серверы к SSH? (С одного IP / вообще со всех
> адресов)
> > сколько выдержит сервер/канал.
>
> Я забыл выделить слово "обычно" - оно и есть суть этого
> вопроса :)
> Т.е. на что рассчитывать - 10, 100, 1000 ...
> (однновременных коннектов)
еще раз: зависит от компа и канала. p100 на диалапе - одна песня, Alpha GS на гигабитной оптике - другая, Sun 5000 на 10 мбит эзернете - третья.
> > про число попыток входа с неправильным паролем слышал?
>
> И что происходит?
зависит от ос/настройки. может полностью лочить аккаунт до вмешательства админа, начинать орать на пейджер, запускать баллистические ракеты.
> Банится IP? - это не самое страшное (разные компы)
> На сколько секунд?
> Если банится возможность залогиниться под атакованным
> юзером - им же хуже (такое на недавно нашли buggzy и 3APA3A
> в FTGate) - юзер не войдёт :)
угу. а если на время? как в нетвари, например ;) ты обломаешься подбирать, а юзер в худшем случае получит задержку.
> > > вместо http используется HTTPS ?
> > что значит "http через cgi"?
>
> Что пароли проверяет CGI скрипт по HTTP-протоколу.
бред.
> > соображения насчет http vs
> > https такие же, как насчет ssh vs telnet.
>
> Ясно.
> А в процентах, или слишком ничтожная разница?
https медленнее http на доли секунды. задержка после неправильного ввода - несколько секунд. потому и пишу "пренебрежимо мало по сравнению..."
> > > Длина ключа у SSH, как и у HTTPS предполагается
> 128 Bit
> > тебе хватит ;)
>
> В данном случае длинны пароля важна не с точки зрения
> криптографии, а лишь как "избыток" по сравнению с
> telnet/HTTP.
я рассматривал случай с предварительным распределением ключей/сертификатов, т.е. если тебе придется еще и ключ подбирать.
> А если, положим, мне известна общая маска пароля, редуцируя
> количество необходимых итераций на тысячи?
а самому посчитать перспективу брутфорса слабо? даже если задержка на каждый пароль 1 секунда (реально больше), одновременно ты открыл 100 сессий (реально врядли сможешь - попробуй запустить 100 телнетов), то скорость перебора получится 100 паролей в секунду. устроит?
|
| | | |
Вопрос про SSH и его брутофорс 17.04.02 23:29
Автор: Renkvil <Boris> Статус: Member
|
> > Смотрел.
> > Мне же нужна была инфа людей из опыта, в доках этого
> нет.
> есть. но не в тех ;)
Где можно взять "не те"?
> что ты понимаешь под "логон"? аккаунт?
Да.
> еще раз: зависит от компа и канала. p100 на диалапе - одна
> песня, Alpha GS на гигабитной оптике - другая, Sun 5000 на
> 10 мбит эзернете - третья.
По твоей терминологии беру сферического коня в вакууме - самый стандартный веб-сервер, без экзотики, Linux на паре мегабит.
> > И что происходит?
> зависит от ос/настройки. может полностью лочить аккаунт до
> вмешательства админа,
Это не есть хорошо ;-)
> начинать орать на пейджер,
На каждую попытку - сообщение? :-)))
> запускать баллистические ракеты.
Это уже лучше, принимая во внимание спуфинг - заодно и ракеты к кому-нибудь полетят :-)
> угу. а если на время? как в нетвари, например ;) ты
> обломаешься подбирать, а юзер в худшем случае получит
> задержку.
... А потом я снова возьмусь за аккоунт.
Юзер же до логина не доживёт :)
Задержка до-о-олгая получится :)
> > > > вместо http используется HTTPS ?
> > > что значит "http через cgi"?
> >
> > Что пароли проверяет CGI скрипт по HTTP-протоколу.
> бред.
При такой формулировке ответа мне не совсем ясно, что именно ты считаешь неправильным, хотя я конечно не исключаю, что где-то ошибаюсь.
> https медленнее http на доли секунды.
> задержка посленеправильного ввода - несколько секунд.
Всегда или есть приятные исключения?
> потому и пишу "пренебрежимо мало по сравнению..."
Ясно.
> > > > Длина ключа у SSH, как и у HTTPS
> предполагается
> > 128 Bit
> > > тебе хватит ;)
> >
> я рассматривал случай с предварительным распределением
> ключей/сертификатов, т.е. если тебе придется еще и ключ
> подбирать.
Я считал без пожбора ключа - он же не всегда нужен?
Здесь я могу ошибаться.
> а самому посчитать перспективу брутфорса слабо? даже если
Если бы я всё знал - не спрашивал бы :)
> задержка на каждый пароль 1 секунда (реально больше),
Если дейчтвительно аккоунт временно не блокируется :(
> одновременно ты открыл 100 сессий (реально врядли сможешь -
> попробуй запустить 100 телнетов), то скорость перебора
А если 10 (100) компов?
> получится 100 паролей в секунду. устроит?
Да.
Для меня это очень много, я рассчитывал на меньшее.
При таком раскладе 30 компов ломают 6-ти значный пароль за день.
{(26^6)/100/30/3600/24}
Борис
|
| | | | |
Вопрос про SSH и его брутофорс 18.04.02 10:32
Автор: cybervlad <cybervlad> Статус: Elderman
|
> > есть. но не в тех ;)
>
> Где можно взять "не те"?
я имею ввиду, что чтение док только на ssh не дает всех ответов. надо читать и смежные, про телнет и общую политику безопасности аккаунтов.
> > еще раз: зависит от компа и канала. p100 на диалапе -
> одна
> > песня, Alpha GS на гигабитной оптике - другая, Sun
> 5000 на
> > 10 мбит эзернете - третья.
>
> По твоей терминологии беру сферического коня в вакууме -
> самый стандартный веб-сервер, без экзотики, Linux на паре
> мегабит.
разброс в самых широких пределах. начиная с понятия "стандартный". кроме того, смотря сколько соединений уже открыто, как они нагружены. наблюдал как всего один клиент так нагружал Alpha, что остальне пару сотен просто вылетали. с другой стороны, линукс на обычном писюке выдерживает. прикинь сам: сколько памяти на сервере, сколько занимает один экземпляр apache - узнаешь, сколько их может стартануть одновременно (на каждый входящий коннект стартует свой подпроцесс). кстати, если ты о вебе, то причем тут ssh? ты его с ssl не перепутал?
> > > И что происходит?
> > зависит от ос/настройки. может полностью лочить
> аккаунт до
> > вмешательства админа,
>
> Это не есть хорошо ;-)
зависит от задач и модели угроз.
> > начинать орать на пейджер,
>
> На каждую попытку - сообщение? :-)))
ну зачем утрировать? можно ведь порог настроить, чтобы отличать случайную ошибку при наборе пароля от брутфорса..
> > угу. а если на время? как в нетвари, например ;) ты
> > обломаешься подбирать, а юзер в худшем случае получит
> > задержку.
>
> ... А потом я снова возьмусь за аккоунт.
> Юзер же до логина не доживёт :)
> Задержка до-о-олгая получится :)
ты такой всесильный, что точно опередишь юзера? уже залогированнго нормальная система не выбросит, она начнет ему жаловаться и админу. при таком кипеже сразу засуетятся, начнут тебя трассировать, лочить твой адрес. или еще проще: введут ограничения на адрес регистрации.
> > > Что пароли проверяет CGI скрипт по
> HTTP-протоколу.
> > бред.
>
> При такой формулировке ответа мне не совсем ясно, что
> именно ты считаешь неправильным, хотя я конечно не
> исключаю, что где-то ошибаюсь.
видимо, отвлекли и я не закончил мысль. сорри.
в http есть свои методы аутентификации, которые никак не связаны с CGI. если CGI еще дополнительно проверяет валидность юзера по какой-то своей схеме, то это никаким местом не http.
> > > > > Длина ключа у SSH, как и у HTTPS
> > предполагается
> > > 128 Bit
> > > > тебе хватит ;)
> > >
>
> > я рассматривал случай с предварительным распределением
> > ключей/сертификатов, т.е. если тебе придется еще и
> ключ
> > подбирать.
>
> Я считал без пожбора ключа - он же не всегда нужен?
тогда зачем вообще упоминание о размерностях?
> Здесь я могу ошибаться.
ты просто все смешал в кучу. если аутентификация по ключу - это олдна песня (очень сложная), если речь только о пароле - совсем другое дело
> > а самому посчитать перспективу брутфорса слабо? даже
> если
>
> Если бы я всё знал - не спрашивал бы :)
ну это же просто здравый смысл, у тебя были все исходные данные ;)
> > задержка на каждый пароль 1 секунда (реально больше),
>
> Если дейчтвительно аккоунт временно не блокируется :(
вот-вот ;)
> > одновременно ты открыл 100 сессий (реально врядли
> сможешь -
> > попробуй запустить 100 телнетов), то скорость перебора
>
> А если 10 (100) компов?
вот и ответь сам на этот вопрос. n компов по m телнетов на каждом - сколько получится? ;) N задай сам, M узнай экспериментально ;)
> > получится 100 паролей в секунду. устроит?
>
> Да.
> Для меня это очень много, я рассчитывал на меньшее.
скромные у тебя запросы ;) по мне - очень мало. тем более, что на практике после каждых трех попыток ты можешь еще поиметь паузу в 15 минут ;) а может, не после 3, а 5, и не 15, а 10. ответ будет одинаков: login error, и ты не узнаешь, пароль неправильный или это временная блокировка.
> При таком раскладе 30 компов ломают 6-ти значный пароль за
> день.
> {(26^6)/100/30/3600/24}
ну, во-первых, надо считать еще и подмножества 5, 4 и 3-символьных паролей, хотя на результате это скажется незначительно.
кроме того, ты что же всех за ламеров держишь? почему алфавит 26 символов? а регистр? а цифры? а доп. символы?
посмотри расчетные таблички для нетвари:
http://cybervlad.port5.com/nwpass/index.html
|
| | | | | |
Вопрос про SSH и его брутофорс 22.04.02 19:34
Автор: Renkvil <Boris> Статус: Member
Отредактировано 22.04.02 19:37 Количество правок: 2
|
> я имею ввиду, что чтение док только на ssh не дает всех
> ответов. надо читать и смежные, про телнет и общую политику
> безопасности аккаунтов.
Имею представление, но возникают вопросы.
> выдерживает. прикинь сам: сколько памяти на сервере,
> сколько занимает один экземпляр apache - узнаешь, сколько
> их может стартануть одновременно (на каждый входящий
> коннект стартует свой подпроцесс). кстати, если ты о вебе,
Почему Apache?
Я о SSH...
И сколько SSH-шек стартанёт на P4 на паре мегабит, если сервер вообщем не перегружен, и кроме твоих SSH сессий нет - может из опыта знаешь?
> то причем тут ssh? ты его с ssl не перепутал?
Нет, SSH.
смотри ссылку ниже.
> > > может полностью лочить аккаунт до вмешательства админа,
> > Это не есть хорошо ;-)
> зависит от задач и модели угроз.
Для какой модели это может быть хорошо?
DoS всегда плохо, зачем его форсировать?
> ну зачем утрировать? можно ведь порог настроить, чтобы
> отличать случайную ошибку при наборе пароля от брутфорса..
Ага. Если кто-то активно ошибается по 100 раз в секунду :)
> ты такой всесильный, что точно опередишь юзера? уже
> залогированнго нормальная система не выбросит, она начнет
> ему жаловаться и админу. при таком кипеже сразу засуетятся,
> начнут тебя трассировать, лочить твой адрес. или еще проще:
Есть прокси
> введут ограничения на адрес регистрации.
IP можно менять, можно использовать несколько компов из разных зон.
> видимо, отвлекли и я не закончил мысль. сорри.
> в http есть свои методы аутентификации, которые никак не
> связаны с CGI. если CGI еще дополнительно проверяет
> валидность юзера по какой-то своей схеме, то это никаким
> местом не http.
Я имел в виду, что свои результаты, CGI-скрипт возвращает по http
> ты просто все смешал в кучу. если аутентификация по ключу -
> это олдна песня (очень сложная), если речь только о пароле
> - совсем другое дело
Вношу ясность - аутентификация только по паролю, без ключа.
С ключом было бы нереально :)
> ну это же просто здравый смысл, у тебя были все исходные
> данные ;)
Из исходных данных у меня есть только секундомер - сказывается отсутствие практики :)
> вот-вот ;)
Т.е. 100 в секунду может накрыться :)
> > А если 10 (100) компов?
> вот и ответь сам на этот вопрос. n компов по m телнетов на
> каждом - сколько получится? ;) N задай сам, M узнай
> экспериментально ;)
Посчитать несложно, но сколько примет сервер - я ведь могу и 100 компов организовать - 10000 это же нереально :)
> скромные у тебя запросы ;) по мне - очень мало. тем более,
В данном случае неслабо, или ты знаешь как можно увеличить скорость перебора по SSH/telnet?
> что на практике после каждых трех попыток ты можешь еще
> поиметь паузу в 15 минут ;) а может, не после 3, а 5, и не
> 15, а 10. ответ будет одинаков: login error, и ты не
> узнаешь, пароль неправильный или это временная блокировка.
Вот это хуже всего, уж лучше бы скорость хромала.
> > При таком раскладе 30 компов ломают 6-ти значный
> > пароль за день.
> > {(26^6)/100/30/3600/24}
> ну, во-первых, надо считать еще и подмножества 5, 4 и
> 3-символьных паролей, хотя на результате это скажется
> незначительно.
Очень даже незначительно, но я не учитывал по другой причине (ссылка ниже)
> кроме того, ты что же всех за ламеров держишь? почему
> алфавит 26 символов? а регистр? а цифры? а доп. символы?
Если бы были доп. символы, регистры и цифры и 8 символов ~ 82^8 я и не только я, но и NSA забили бы :)
По конкретной ситуации смотри ссылку ниже, я забыл её привести.
> посмотри расчетные таблички для нетвари:
> http://cybervlad.port5.com/nwpass/index.html
Смотрел.
Но Нетварь этож не SSH.
Ссылка по теме
Исходный вопрос
|
| | | | | | |
Вопрос про SSH и его брутофорс 23.04.02 08:14
Автор: cybervlad <cybervlad> Статус: Elderman
|
> > их может стартануть одновременно (на каждый входящий
> > коннект стартует свой подпроцесс). кстати, если ты о
> вебе,
>
> Почему Apache?
> Я о SSH...
тогда каким местом к теме CGI и http?
> И сколько SSH-шек стартанёт на P4 на паре мегабит, если
> сервер вообщем не перегружен, и кроме твоих SSH сессий нет
> - может из опыта знаешь?
даже если бы и знал, то эта цифра, полученная с моего конкретного P4 в твоем конкретном случае совершенн не в тему. не бывает 2 абсолютно одинаковых условий, а при серьезных нагрузках (граничных значениях) любая мелочь влияет на результатсущественно
> > > Это не есть хорошо ;-)
> > зависит от задач и модели угроз.
>
> Для какой модели это может быть хорошо?
> DoS всегда плохо, зачем его форсировать?
например, для модели, в которой секретность имеет приоритет выше доступности. устроит?
> > ну зачем утрировать? можно ведь порог настроить, чтобы
> > отличать случайную ошибку при наборе пароля от
> брутфорса..
>
> Ага. Если кто-то активно ошибается по 100 раз в секунду :)
100 раз в секунду человек не может ошибиться физически. а пароль с 5 раза обычно вводят даже законченные дауны.
> > начнут тебя трассировать, лочить твой адрес. или еще
> проще:
>
> Есть прокси
>
> > введут ограничения на адрес регистрации.
>
> IP можно менять, можно использовать несколько компов из
> разных зон.
1. при смене ip ssh будет производить повторный обмен ключами
2. через какие прокси ты будешь юзать ssh? через socks? а не слабо настроить, да еще на такой косяк сессий?
3. лочить можно "от противного". т.е. сделать deny для src ip !=<current user address>.
> > валидность юзера по какой-то своей схеме, то это
> никаким
> > местом не http.
>
> Я имел в виду, что свои результаты, CGI-скрипт возвращает
> по http
выражайся по -русски, пожалуйста. "возвращает результаты" и "проводит аутентификацию" 2 большие разницы, как говорят в Одессе ;) естесвенно, что результаты пойдут только по http...
> Вношу ясность - аутентификация только по паролю, без ключа.
> С ключом было бы нереально :)
уверен? после первого захода юзера можно серверу объяснить, что адрес меняться не будет, а сервер помнит ключ для каждого ip. таким образом, сначала будет "проверка хоста", а потом уже аутентификация юзера по паролю. впрочем, это редко включают...
> > каждом - сколько получится? ;) N задай сам, M
> узнай
> > экспериментально ;)
>
> Посчитать несложно, но сколько примет сервер - я ведь могу
> и 100 компов организовать - 10000 это же нереально :)
замаешься скоординировано организовывать ;)
кроме того, кто тебе мешает построить расчетные таблицы с разным количеством компов, а потом коррелировать эти данные с возможностями сервера?
> В данном случае неслабо, или ты знаешь как можно увеличить
> скорость перебора по SSH/telnet?
я тебе уже объяснял, что это принципиально невозможно. через N попыток аутентификации (N - порог срабатывания блокировки) в течение T минут ты будешь получать auth failed, независимо от правильности введенного пароля. или ты думаешь, что те, кто придумывал подсистему безопасности ничего не знали про брутфорс? ;) именно потому и придуманы все эти ограничения и задержки...
> > ну, во-первых, надо считать еще и подмножества 5, 4 и
> > 3-символьных паролей, хотя на результате это скажется
> > незначительно.
>
> Очень даже незначительно, но я не учитывал по другой
> причине (ссылка ниже)
спасибо, по ссылкам на форум я не хожу принципиально.
> Смотрел.
> Но Нетварь этож не SSH.
правильно ;) там постановка вычислительной задачи сложнее, зато есть возможность обойти блокировки на подбор ;)
|
| | | | | | | |
Вопрос про SSH и его брутофорс 23.04.02 17:35
Автор: Renkvil <Boris> Статус: Member
|
> > Я о SSH...
> тогда каким местом к теме CGI и http?
А это я к слову спросил...
> даже если бы и знал, то эта цифра, полученная с моего
> конкретного P4 в твоем конкретном случае совершенн не в
> тему. не бывает 2 абсолютно одинаковых условий, а при
> серьезных нагрузках (граничных значениях) любая мелочь
> влияет на результатсущественно
Существенно - это 2, 10 или 100 раз?
И почему мелочи влияют существенно?
> > Для какой модели это может быть хорошо?
> > DoS всегда плохо, зачем его форсировать?
> например, для модели, в которой секретность имеет приоритет
> выше доступности. устроит?
Мне был интересен практический пример такой модели.
Обычно проще делать стойкие пароли.
> 100 раз в секунду человек не может ошибиться физически. а
Ну плохая у него память, зато эпилепсик он! :-))
> пароль с 5 раза обычно вводят даже законченные дауны.
Чем отличается хакер от юзера?
Юзер вводит пароль с 5-ого раза, а хакер с 3-его
(С) Анекдот.Ру
> 1. при смене ip ssh будет производить повторный обмен
> ключами
Факт.
> 2. через какие прокси ты будешь юзать ssh? через socks? а
> не слабо настроить, да еще на такой косяк сессий?
Канают только socks.
Насторить - действтельно проблема, требующая определённых умственных затрат.
> 3. лочить можно "от противного". т.е. сделать deny для src
> ip !=<current user address>.
Юзеры имеет динамические IP
Как такое осуществить?
> > Я имел в виду, что свои результаты, CGI-скрипт
> > возвращает по http
> выражайся по -русски, пожалуйста.
I do :-)
> "возвращает результаты" и
> "проводит аутентификацию" 2 большие разницы, как говорят в
> Одессе ;)
Я не знаю, что говорят в Одессе по поводу аутентификации :), но имхо аутентификцию CGI проводит локально на сервере, и возвращает результаты пользователю по протоколу HTTP.
Выражение "возвращает результаты" я неоднократно встречал в многочисленных книжках в России, в основном подразумевалась SUB-фунция, которая на входе получает какие-то данные и возвращает результаты. Работа CGI-скрипта в чём-то напоминает описанное.
> естесвенно, что результаты пойдут только по
> http...
Ну если мудрить, то есть всякие туннели...
> уверен? после первого захода юзера можно серверу объяснить,
> что адрес меняться не будет, а сервер помнит ключ для
> каждого ip. таким образом, сначала будет "проверка хоста",
> а потом уже аутентификация юзера по паролю. впрочем, это
> редко включают...
Я рассматриваю более упрощённую ситуацию.
IP - динамический, т.е. меняется каждый раз.
> > и 100 компов организовать - 10000 это же нереально :)
> замаешься скоординировано организовывать ;)
В каждой С-сетке есть пара расшаренных компов...
Это были бы зомби, постоянно сидящие в Инете на мощном канале.
Кому DDoS, кому брутофорс...
> кроме того, кто тебе мешает построить расчетные таблицы с
> разным количеством компов, а потом коррелировать эти данные
> с возможностями сервера?
Расчётные таблицы я построить могу.
Но я ни имею ни малейшего практического представления, сколько соединений примет сервер.
> > В данном случае неслабо, или ты знаешь как можно увеличить
> > скорость перебора по SSH/telnet?
> я тебе уже объяснял, что это принципиально невозможно.
Я ещё тогда понял :)
> через N попыток аутентификации (N - порог срабатывания
> блокировки) в течение T минут ты будешь получать auth
> failed, независимо от правильности введенного пароля. или
> ты думаешь, что те, кто придумывал подсистему безопасности
> ничего не знали про брутфорс? ;) именно потому и придуманы
> все эти ограничения и задержки...
Это и есть главная проблема.
Делающая задачу нерешаемой.
> > > ну, во-первых, надо считать еще и подмножества 5,
> 4 и
> > > 3-символьных паролей, хотя на результате это
> скажется
> > > незначительно.
> >
> > Очень даже незначительно, но я не учитывал по другой
> > причине (ссылка ниже)
> спасибо, по ссылкам на форум я не хожу принципиально.
Могу сделать страницу www.chat.ru/~bla.htm которая редиректит на ссылку на форуме :)
Это была не простая ссылка на форум :), но внизу я поставил ссылку на то, что я имел в виду в качестве прототипа, т.е. как теоретически возможную систему для атаки.
Точнее тамсоздаютсясистемы для атаки :)
https://ispserver.com/ru/support/demo/index.html
|
| | | | | | | | |
Вопрос про SSH и его брутофорс 24.04.02 13:04
Автор: cybervlad <cybervlad> Статус: Elderman
|
> > тему. не бывает 2 абсолютно одинаковых условий, а при
> > серьезных нагрузках (граничных значениях) любая мелочь
> > влияет на результатсущественно
>
> Существенно - это 2, 10 или 100 раз?
и в 2, и в 10, и в 100
> И почему мелочи влияют существенно?
вопрос философский ;) но на моем опыте - почти всегда так...
> > например, для модели, в которой секретность имеет
> приоритет
> > выше доступности. устроит?
>
> Мне был интересен практический пример такой модели.
не могу - подписка о неразглашении.
> Обычно проще делать стойкие пароли.
"совершенно отнюдь" (с) майор-топограф
1. если доверить делать пароли юзерам, они обязательно все изгадят
2. если генерировать программой - будут писать на бумажке.
при первом варианте хотябы часть делает правильно (а остальные выявляются и наказываются периодическими проверками), н в этом случае нужна подстраховка в виде ограничений и блокировок...
> > 100 раз в секунду человек не может ошибиться
> физически. а
>
> Ну плохая у него память, зато эпилепсик он! :-))
дело не в памяти ;) физическая природа распространения нервных импульсов и сокращений мышц не дает возможности 100 раз в секунду нажимать даже одну кнопку ;) случай с засыпанием лицом на клаве (скорость повтора ограничена лишь установкой auto repeat клавы) не рассматриваются ;)
> > пароль с 5 раза обычно вводят даже законченные дауны.
>
> Чем отличается хакер от юзера?
> Юзер вводит пароль с 5-ого раза, а хакер с 3-его
> (С) Анекдот.Ру
только хакер не вводит, а угадывает с третьего ;)
> > 3. лочить можно "от противного". т.е. сделать deny для
> src
> > ip !=<current user address>.
>
> Юзеры имеет динамические IP
> Как такое осуществить?
мы же говорим про конкретного юзера? в данный момент у него конкретный ip. в конце концов, можно ограничить сеткой, из которой динамика выдается
> > естесвенно, что результаты пойдут только по
> > http...
>
> Ну если мудрить, то есть всякие туннели...
нет, от CGI - именно по http. а вот http уже может быть в тоннеле ;)
> > каждого ip. таким образом, сначала будет "проверка
> хоста",
> > а потом уже аутентификация юзера по паролю. впрочем,
> это
> > редко включают...
>
> Я рассматриваю более упрощённую ситуацию.
> IP - динамический, т.е. меняется каждый раз.
вот потому и не включают. но если юзер хоть раз уже ходил на этот хост, у него уже есть открытый ключ сервера. все-таки на 1 итерацию меньше ;)
> > > и 100 компов организовать - 10000 это же
> нереально :)
>
> > замаешься скоординировано организовывать ;)
>
> В каждой С-сетке есть пара расшаренных компов...
> Это были бы зомби, постоянно сидящие в Инете на мощном
> канале.
> Кому DDoS, кому брутофорс...
вот ты накопи сперва такую команду рабов/зомби, а потом говори, что 10000 легко организуешь ;)
> > разным количеством компов, а потом коррелировать эти
> данные
> > с возможностями сервера?
>
> Расчётные таблицы я построить могу.
> Но я ни имею ни малейшего практического представления,
> сколько соединений примет сервер.
легко проверяется практически - открывай соединения, пока принимает. хакать при этом совсем не обязательно ;)
|
|
|
подробно о проекте
Анализ криптографических сетевых...
