Comments 14
Статический сайт и безызвестность — лучшая защита от DDOS.
(половина шутки юмора)
(половина шутки юмора)
Известность — лучше защита чем безызвестность — детские атаки не отличишь от случайного всплеска активности пользователей, а взрослые ну очень дорогие.
Меня пока только «школьники» докучали. Судя по логам, брутфорсили вордпресс… А у меня сайт не на вордпрессе.) Не знаю, считается ли это DDoS'ом, но php работать из-за нагрузки перестал, но статические страницы грузились без проблем. А вот от «взрослых» на моём тарифе сайт задохнётся.(
Мне кэширование не помогло бы в любом случае. Единственная php страница считает загрузки, так что её кэшировать нельзя. А остальное итак плоский html.
Мне кэширование не помогло бы в любом случае. Единственная php страница считает загрузки, так что её кэшировать нельзя. А остальное итак плоский html.
А что мешает хранить все ID в дешевом «кэше», отдавать 404, если его там нет, и обращаться к серверу приложений, если ID есть, но данных в кэше нет?
Поправьте меня, если я ошибаюсь:
Смысл «подписывания» ID в том, чтобы злоумышленники не смогли нагенерировать миллиард разных реальных запросов, и положить проект, если бы все ответы на эти запросы не были в кэше.
т.е. это актуально если мы не можем позволить себе такой большой кэш?
Смысл «подписывания» ID в том, чтобы злоумышленники не смогли нагенерировать миллиард разных реальных запросов, и положить проект, если бы все ответы на эти запросы не были в кэше.
т.е. это актуально если мы не можем позволить себе такой большой кэш?
А что мешает вытащить все урлы сайта и начать по ним активно "ходить"? То есть перебирать все корректные урлы. В этом случае данная проверка только увеличит нагрузку ведь.
Если API к непубличному ресурсу, то достаточно реализовать быструю авторизацию.
Если к публичному — то либо идентификаторы генерируются пользователем, но тогда у атакующего, как и у легального пользователя, должна быть возможность делать корректную подпись к интересующим его идентификаторам.
Либо эти идентификаторы недоступны к генерации пользователем (т.е. они системные), но тогда их достаточно шифровать шифром с коротким блоком, например, для 32-х битных идентификаторов шифрование 56-битным DES увеличит представление идентификатора меньше чем в два раза, а вероятность попадания в нужный диапазон (после расшифровки) будет меньшей 2**(56-32)=2**24, т.е. меньше одной шестнадцатимиллионной.
Если к публичному — то либо идентификаторы генерируются пользователем, но тогда у атакующего, как и у легального пользователя, должна быть возможность делать корректную подпись к интересующим его идентификаторам.
Либо эти идентификаторы недоступны к генерации пользователем (т.е. они системные), но тогда их достаточно шифровать шифром с коротким блоком, например, для 32-х битных идентификаторов шифрование 56-битным DES увеличит представление идентификатора меньше чем в два раза, а вероятность попадания в нужный диапазон (после расшифровки) будет меньшей 2**(56-32)=2**24, т.е. меньше одной шестнадцатимиллионной.
Лично делал хранение в кэше только реально существующих страниц (на основе карты сайта и ряда страниц исключений, которые не должны присутствовать в карте сайта).
Но проблема всё равно оставалась, т.к. на сайте все данные передаются по API и его я кэшировать не могу. API завязан на данные пользователя и ответ в некоторых случаев разный для разных пользователей. Вот что с API делать — загадка.
Но проблема всё равно оставалась, т.к. на сайте все данные передаются по API и его я кэшировать не могу. API завязан на данные пользователя и ответ в некоторых случаев разный для разных пользователей. Вот что с API делать — загадка.
Сделать ключом кэша не только адрес ресурса, но и идентификатор пользователя?
А потом пытаться на кончиках пальцев контролировать все изменения данных, текущих условий и т.д.?
Когда много динамики в выдаче (эти блоки мы ему уже показывали, сегодня покажем эти), это контролирвоать очень трудно. Отсюда и кэш плодится, как незнамо кто…
Пока доверяю простым запросам к БД, которые должны сами по себе кэшироваться и простой шаблонизации/сериализации, но только для AJAX запросов. Основные страницы всё же из кэша.
А так да, можно сделать составные ключи, но я вот чувствую, что работать с ними слишком больно…
Когда много динамики в выдаче (эти блоки мы ему уже показывали, сегодня покажем эти), это контролирвоать очень трудно. Отсюда и кэш плодится, как незнамо кто…
Пока доверяю простым запросам к БД, которые должны сами по себе кэшироваться и простой шаблонизации/сериализации, но только для AJAX запросов. Основные страницы всё же из кэша.
А так да, можно сделать составные ключи, но я вот чувствую, что работать с ними слишком больно…
Sign up to leave a comment.
Подписывание идентификаторов ресурсов и защита API от DDoS-атак