sleep(5) и возможная нагрузка на сервер.

[storng]

sleep(5) и возможная нагрузка на сервер.

Здравствуйте, уважаемые

В скрипте авторизации, чтобы как-нибудь защитить пользователя от подбора (брута) пароля без блокирования за n-число попыток и т.п. я использую sleep(5) т.е. 5-ти секундную задержку в скрипте, который возвращает флаг - прошёл логин и пароль или нет.
Сбрутить теперь пароль стало практически нереально (т.к. требует огромное количество времени), но вот начал волновать вопрос нагрузки на сервер.
Подскажите, пожалуйста, вообще нормально использовать sleep в таких целях, и сильно ли увеличивает этот оператор нагрузку на сервер?

 

[fixxxer]

задосил сам себя. молодец. =)

запусти у себя на компе 1000 раз
# php -r 'sleep(100);'

и поймешь

пиши в базу время последней попытки и счетчик за последние N минут.

 

[storng]

Автор оригинала: fixxxer
задосил сам себя. молодец. =)

запусти у себя на компе 1000 раз
# php -r 'sleep(100);'

и поймешь

пиши в базу время последней попытки и счетчик за последние N минут.

Спасибо за инфо.

ps: вот ведь а =)

 

[Farsh]

Re: sleep(5) и возможная нагрузка на сервер.

Автор оригинала: storng
чтобы как-нибудь защитить пользователя от подбора (брута) пароля без блокирования за n-число попыток и т.п. я использую sleep(5)

А если я открою пару сотен коннектов, как твой слип поможет ?

 

[storng]

Re: Re: sleep(5) и возможная нагрузка на сервер.

Автор оригинала: Farsh
А если я открою пару сотен коннектов, как твой слип поможет ?

угу, понял - тупая была идея

-~{}~ 11.04.10 19:27:

Автор оригинала: Farsh
А если я открою пару сотен коннектов, как твой слип поможет ?

А если также запустить пару сотен потоков, и будет столько же обращений к БД, не узкое ли будет это место?

 

[no_santa]

в сессии ловить наверное тоже не стоит - ведь взломщик может "сбрасывать" идентификатор?

 

[Farsh]

Re: Re: Re: sleep(5) и возможная нагрузка на сервер.

Автор оригинала: storng
А если также запустить пару сотен потоков, и будет столько же обращений к БД, не узкое ли будет это место?

В данном случае я хотел сказать, что слип тут вообще бесполезен.
А насчет узкое место или неузкое - тут совершенно другая тема - дос/ддос .

 

[vovanium]

А если также запустить пару сотен потоков, и будет столько же обращений к БД, не узкое ли будет это место?

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

А что касается ddos, то имхо это не самое узкое место, так как для той же главной страницы зачастую более сложные запросы используются, чем для проверки авторизации.
Да и как говорится, было бы желание. Был опыт когда сайт одного из клиентов заддосили, так все эти ухищрения до лампочки, так как тупо запросы шли в таких количествах, что забивали 100 Мбитный канал, там до php даже дело не доходило Помог только антиддос сервис, который держал удар до 500 Мбит, с пиками до гигабита.

 

[no_santa]

Автор оригинала: vovanium Помог только антиддос сервис, который держал удар до 500 Мбит, с пиками до гигабита.

Будь другом, расскажи подробнее?

И какой именно сервис, если не секрет.

 

[storng]

Автор оригинала: no_santa
в сессии ловить наверное тоже не стоит - вещь взломщик может "сбрасывать" идентификатор?

Хм, а как он сможет его сбросить?
скажем, изначально в сессию писать какой-нибудь ключ, далее внутри скрипта уже если сессии нет или пустая то дальше не пускаем.
А вот сам факт интересен, как пользователь может сбросить определенную сессионную переменную?

-~{}~ 11.04.10 20:38:

Автор оригинала: Farsh
В данном случае я хотел сказать, что слип тут вообще бесполезен.
А насчет узкое место или неузкое - тут совершенно другая тема - дос/ддос .

понятно, согласен

-~{}~ 11.04.10 20:38:

Автор оригинала: vovanium
Имхо лучше в файл

О, вот это уже интересно ) спасибо за инфо

 

[Wicked]

Хм, а как он сможет его сбросить?

не передавать cookie, не?

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

все, кто пришел в первый раз - бреются

 

[no_santa]

О, вот это уже интересно

На чтение - да. Но суть проблемы в том, что нам надо писать в файл при каждом обращении, а это уже более ресурсоемко.

 

[storng]

Может подскажет кто-нибудь теперь по поводу сессий ещё.

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

 

[fixxxer]

Автор оригинала: no_santa
Будь другом, расскажи подробнее?

И какой именно сервис, если не секрет.

Сдается в аренду использование подобной штуки
http://www.cisco.com/en/US/products/ps5888/

Вообще если надо было бы очень серьезно подойти к вопросу, и затраты времени были бы осмысленными, я бы хранил в shared memory какой-нибудь radix tree со списком ip и счетчиками. Но мне кажется тебе хватит обычной heap таблицы в mysql %) а дальше уже если сертьезный ддос то все равно канал забьют.

 

[no_santa]

Из решений - там где разрешают, можно делать авторизацию по OpenID. Но слишком часто заказчики возражают, поэтому и возникают такие вопросы.

-~{}~ 11.04.10 20:43:

Автор оригинала: fixxxer
Сдается в аренду использование подобной штуки
http://www.cisco.com/en/US/products/ps5888/

Спасибо!!!

 

[storng]

Автор оригинала: Wicked
не передавать cookie, не?


все, кто пришел в первый раз - бреются

Прошу прощение, не понял фразу )

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

 

[no_santa]

Во! А если так:
- если нет данных - ставим ключ в сессию (если его там нет)
- если есть данные - ТРЕБУЕМ ключ из сессии
- если есть данные, но нет ключа - нас ломают, или сессия умерла

Для "поддержания" сессии - каждые n минут JS запрашиваем пустышку с сервера, с session_start. Также, как актуализирует данные gmail

-~{}~ 11.04.10 20:48:

Автор оригинала: storng
Прошу прощение, не понял фразу )

Это старая джедайская подколка

Автор оригинала: storng
Я имел ввиду в скрипте проверять факт наличия своей уникальной сессионной переменной, которую писать всем посетителям при заходе на сайт.
Собственно если сессия была потёрта или ещё что-нибудь произошло, то до переменной своей-ключа мы не достучимся, ну и дальше обслуживать посетителя не будем.

Кстати, да. Отдавать статичную страничку со ссылкой на страничку с формой - вариант?

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

-~{}~ 11.04.10 20:51:

Автор оригинала: storng
Может подскажет кто-нибудь теперь по поводу сессий ещё.

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

Более 25 хостов с пыхом в секунду - многовато для типичного сервера. А меньше - не критично. Сессии-то создаются скомпилированной программой, т.е. это условно "быстро".

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

<?php
session_start();
echo 'Go <a href="/someway">Back</a>';

И, если вообще ничего не отдавать - вариант?

 

[storng]

Автор оригинала: no_santa

И, если вообще ничего не отдавать - вариант?

Интересно, стоит подумать над этим вариантом


Всё-таки смущает в первом варианте то, что всем пользователям нужно открывать сессию, и если будет 500 человек онлайн и все с сессиями ,то сервер может пасть смертью храбрых

 

[Farsh]

Автор оригинала: storng
и если будет 500 человек онлайн и все с сессиями ,то сервер может пасть смертью храбрых

А если 5000 ? А если хватит мечтать ? =)
Но даже если зашла речь о 500 одновременных коннектах, то сессии в любом случае не будут самым узким местом в приложении ( тем более их можно перенести на какой-нить memcached )

 

[no_santa]

...а вот это как раз не забота разработчика. Хоть 50000, хоть 500000 сессий будет - не проблема, если есть нормальный админ.

оффтоп
От инфобокса я ушел именно по этой причине - переполнилась директория с сессиями на виртуалке. Написал в саппорт - "что за хня?" Пишут - вот вам скрипт, вот вам крон, чистите сами. Пишу "Дануна? Неужели юзверьское дело - сессии да логи подчищать?" Ответили - "да". Типа, у них все 100рублевые клиенты сами это делают Еще месяцок подождал для приличия, еще раз переспросил, да и свалил оттуда...

-~{}~ 11.04.10 21:13:

"виртуалка" - имею в виду "обычный" виртуальный хостинг, а не ВДС