cleantalk.org сделан на собственные деньги, отложенные с зарплаты и в момент запуска не было возможности вложиться в покупку правильного домена под коммерцию. Со временем стало ясно, что клиентов не волнует TLD домена, соответственно сейчас нет мотивации на переезд в "коммерческий" TLD или полной смены имени домена.
Качество продукта, техническая поддержка и цена решают. Имя, дизайн, упаковка вторичны.
Бутылки покупают только клиенты компании после контакта с рекламными носителями во время взаимодействия с продуктом компании. Амазон это только техническая площадка (маркетплейс) для осуществления сделки, получения денег и доставки бутылки до клиента.
Конечно не было расчета, что с поиска Амазона будут покупать по запросу "CleanTalk", но был расчет (План Б) на продажи по запросу "32oz Water Bottle", т.е. если не сработать на продвижение бренда среди своих клиентов, то хотя бы окупить эксперимент классической коммерцией.
Смена IP адреса приведет к повторной выдачи стоп-страницы, что не приятно, но не критично для посетителя.
Пустая страница не информативна, будет не понятна пользователям, а следовательно повлияет на сценарий работы с сайтом, в плоть до обращения в тех. поддержку.
Статичные ресурсы отдаются веб-сервером, а его производительность на порядки выше чем PHP бекенда. Т.е. в условия DDoS атаки менее 1к пакетов в секунду, это не будет проблемой.
Опять же Nginx хорошо, но не все его используют, либо не все имеют доступ к его настройкам.
1. В случаи небольших DDoS атак возможности веб-серверов по количеству одновременных соединений выше количества атакуемых.
2. Не спорю, этот вариант с JS кодом не сложен. Но тем не менее позволит выиграть время.
3. 1 секунду и менее показывать не правильно с точки зрения посетителя сайта, т.к. он не успеет понять почему он вдруг мельком увидел какую-то другую страницу вместо ожидаемой.
4. Одно другому не мешает.
Ничего не мешает, но это усложняет техническую реализацию атаки, т.к. есть привязка куки к IP адресу атакующего.
Приведенную выше схему можно рассматривать как один из элементов защиты от DDoS, если включить в начале атаки, то выиграете время на усиления анти DDoS защиты.
В таком случаи можно рекоммендовать не оставлять свой Email в подозрительных местах, а тем более избегать сайтов, которые публикуют ваш Email на своих страницах. Это моветон, честно говоря, со стороны владельца веб-сайта, т.к. он подставляет своих пользователей.
Что мешает спам-боту вписывать в поля адреса собранные на страницах профилей того же самого форума (они же все равно, в таком случае, не проверяются)? С точки зрения стороннего сервиса это будет валидный постинг?
В смысле пытаться постить от имени других пользователей сайта? Для этого надо иметь доступ к акаунтам пользователей, а это уже вопрос безопасности сайта.
Не все пользователи готовы разгадывать капчи, кто-то просто уходит с формы, т.е. вы теряете полезный трафик. Количество false/postive на капче считаете?
У нас false/negative 0.0008%, false/positive 0.0002% на 2млн. спам атак в сутки.
Т.е. перейдя с капчи на аналитику, можно уменьшить время заполения формы на сайте и повысите удобство работы с сайтом, что приведет к росту полезных POST запросов, без потери в качестве фильтрации спам-трафика.
Смысл в том, чтобы отправлять ссылку для активации акаунта только на существующие Email адреса, тем самым вы исключите опечатки в email адресах, т.е. повысите качество ваших веб-приложений и снизите количество не активных акаунтов, не подтвержденных Email адресов.
1. Скорость сканирования на тысячу файлов выше в 3-4 раза, зависит от хостинга.
2. Нет избыточного сканирования (картинки, стили и т.д.).
3. Есть сканирование по расписанию.
4. Есть облачное управление FireWall (распространение правил по группе сайтов через одну Панель управления).
5. Есть автоматическая защита от DoS.
6. Хранение журналов в облаке (о чем выше отписал AleksandrRazoR).
Редирект cleantalk.org(http) -> cleantalk.org(https) настроен давно и работает. А вот cleantalk.ru(https) -> cleantalk.org(https) не настроен, т.к. давненько уже перевели весь трафик на cleantalk.org.
cleantalk.org сделан на собственные деньги, отложенные с зарплаты и в момент запуска не было возможности вложиться в покупку правильного домена под коммерцию. Со временем стало ясно, что клиентов не волнует TLD домена, соответственно сейчас нет мотивации на переезд в "коммерческий" TLD или полной смены имени домена.
Качество продукта, техническая поддержка и цена решают. Имя, дизайн, упаковка вторичны.
Бутылки покупают только клиенты компании после контакта с рекламными носителями во время взаимодействия с продуктом компании. Амазон это только техническая площадка (маркетплейс) для осуществления сделки, получения денег и доставки бутылки до клиента.
Конечно не было расчета, что с поиска Амазона будут покупать по запросу "CleanTalk", но был расчет (План Б) на продажи по запросу "32oz Water Bottle", т.е. если не сработать на продвижение бренда среди своих клиентов, то хотя бы окупить эксперимент классической коммерцией.
Кроме того, стоп-страницу можно использовать для информирования клиентов о произошедшем, и о том что делать, и что не делать.
Пустая страница не информативна, будет не понятна пользователям, а следовательно повлияет на сценарий работы с сайтом, в плоть до обращения в тех. поддержку.
Статичные ресурсы отдаются веб-сервером, а его производительность на порядки выше чем PHP бекенда. Т.е. в условия DDoS атаки менее 1к пакетов в секунду, это не будет проблемой.
Опять же Nginx хорошо, но не все его используют, либо не все имеют доступ к его настройкам.
И никто не мешает усложнить JavaScript код под конкретный сайт.
Был опыт преднамеренного усложнения JavaScript кода в целях исчерпать ресурсы атакующих?
Решение с 1 include в index.php проше и универсальнее.
2. Не спорю, этот вариант с JS кодом не сложен. Но тем не менее позволит выиграть время.
3. 1 секунду и менее показывать не правильно с точки зрения посетителя сайта, т.к. он не успеет понять почему он вдруг мельком увидел какую-то другую страницу вместо ожидаемой.
4. Одно другому не мешает.
Приведенную выше схему можно рассматривать как один из элементов защиты от DDoS, если включить в начале атаки, то выиграете время на усиления анти DDoS защиты.
cleantalk.org/blacklists/johnd530@gmail.com
В таком случаи можно рекоммендовать не оставлять свой Email в подозрительных местах, а тем более избегать сайтов, которые публикуют ваш Email на своих страницах. Это моветон, честно говоря, со стороны владельца веб-сайта, т.к. он подставляет своих пользователей.
В смысле пытаться постить от имени других пользователей сайта? Для этого надо иметь доступ к акаунтам пользователей, а это уже вопрос безопасности сайта.
У нас false/negative 0.0008%, false/positive 0.0002% на 2млн. спам атак в сутки.
Т.е. перейдя с капчи на аналитику, можно уменьшить время заполения формы на сайте и повысите удобство работы с сайтом, что приведет к росту полезных POST запросов, без потери в качестве фильтрации спам-трафика.
Велкам,
github.com/CleanTalk/php-antispam
2. Нет избыточного сканирования (картинки, стили и т.д.).
3. Есть сканирование по расписанию.
4. Есть облачное управление FireWall (распространение правил по группе сайтов через одну Панель управления).
5. Есть автоматическая защита от DoS.
6. Хранение журналов в облаке (о чем выше отписал AleksandrRazoR).
Но обязательно проверим https для cleantalk.ru.
*** Forbidden. Enable JavaScript. Anti-spam service cleantalk.org. ***
Либо в настройках Панели управления можете указать свое собственное сообщение для отвергнутых форм,
https://cleantalk.org/my/service?action=edit
По алгоритмам есть пояснения здесь,
https://habrahabr.ru/company/cleantalk/blog/282586/
https://habrahabr.ru/company/cleantalk/blog/283300/