> С 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 практически не работал, поэтому пара вопросов: не работал - это понятно. но вот доку почему не почитал?
> 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) - юзер не войдёт :)
> > 4. Что будет быстрее: брутофорсить SSH, или HTTP через > > CGI-скрипт? И насколько будет медленнее перебор, если > > вместо http используется HTTPS ? > что значит "http через cgi"?
Что пароли проверяет CGI скрипт по HTTP-протоколу.
> соображения насчет http vs > https такие же, как насчет ssh vs telnet.
Ясно.
А в процентах, или слишком ничтожная разница?
> > Длина ключа у SSH, как и у HTTPS предполагается 128 Bit > тебе хватит ;)
В данном случае длинны пароля важна не с точки зрения криптографии, а лишь как "избыток" по сравнению с telnet/HTTP.
> > Интересно оценить защиту системы теоретически.
> Смотрел. > Мне же нужна была инфа людей из опыта, в доках этого нет. есть. но не в тех ;)
> > тобой ограницения на коннект к определенному порту (в > > данном случае - 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
> > есть. но не в тех ;) > > Где можно взять "не те"? я имею ввиду, что чтение док только на 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 забили бы :)
По конкретной ситуации смотри ссылку ниже, я забыл её привести.
> > их может стартануть одновременно (на каждый входящий > > коннект стартует свой подпроцесс). кстати, если ты о > вебе, > > Почему 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? а > не слабо настроить, да еще на такой косяк сессий?
> 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 которая редиректит на ссылку на форуме :)
Это была не простая ссылка на форум :), но внизу я поставил ссылку на то, что я имел в виду в качестве прототипа, т.е. как теоретически возможную систему для атаки.
Точнее тамсоздаютсясистемы для атаки :)
> > тему. не бывает 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 легко организуешь ;)
> > разным количеством компов, а потом коррелировать эти > данные > > с возможностями сервера? > > Расчётные таблицы я построить могу. > Но я ни имею ни малейшего практического представления, > сколько соединений примет сервер. легко проверяется практически - открывай соединения, пока принимает. хакать при этом совсем не обязательно ;)
подробно о проекте
Анализ криптографических сетевых...
новое сообщение
закрытая нитка
новое сообщение
в закрытой нитке
старое сообщение
