Можно ли обслуживать определенные страницы на основе IP-адреса?


8

Я был целью атаки методом перебора на двух сайтах WordPress, которыми я владею. Злоумышленник использует старый добрый XML-RPC для усиления атаки паролем. К счастью, у нас очень хорошо сгенерированные пароли, поэтому я очень сомневаюсь, что он когда-нибудь будет.

Я только что использовал iptables для блокировки его запросов всякий раз, когда он снова появляется (всегда от того же провайдера виртуального облака), но я бы предпочел изменить сервер так, чтобы всякий раз, когда его IP-адрес запрашивал какую-либо страницу, он получал ответ, сообщающий ему чтобы получить жизнь. Большинство запросов являются сообщениями POST, поэтому в идеале я хотел бы просто изменить заголовок ответа так, чтобы он включал что-то вроде «Удачи в следующий раз!» или что-то в равной степени удовлетворяющее.

Это возможно? Я далеко не эксперт по Apache, поэтому я не уверен, насколько сложно это реализовать. Но даже если это займет у меня несколько часов, удовлетворение будет бесценным.

Для справки, я использую Ubuntu 16.04.2 LTS, с Apache 2.4.18 и Wordpress 4.7.3.


"всегда от одного и того же виртуального облачного провайдера" OVH? Я заметил, что многие сценаристы по каким-то причинам пользуются их услугами.
HD

Нет, online.net ... они до сих пор не ответили ни на один из моих сообщений о злоупотреблениях. Кроме того, когда я впервые отправил запрос о нарушении, я обнаружил, что они автоматически направляют жалобу клиенту. Отсюда и как он нашел мой личный сайт. Хорошая работа, online.net ....
Аврелий

Ответы:


25

Просто установите fail2ban с соответствующим джейлом и покончите с этим. Не пытайтесь дать индивидуальный ответ, так как, скорее всего, его никогда не увидят.


1
Точно. Но это определенно то, что я всегда хотел сделать. Даже если он никогда этого не увидит, просто возможность заставить меня смеяться так сильно, что я чуть не плачу.
Аврелий,

14
Ну что ж: 1) ИМХО выяснить, как отобразить мелкое оскорбление для детектива-сценария, здесь не по теме. 2) Это все равно будет потреблять ваши ресурсы apache, тогда как fail2ban / iptables блокирует запросы в восходящем направлении, поэтому вашему приложению никогда не придется иметь дело с этим.
EEAA

1
О точно. Но я хочу немного повеселиться перед вечным запретом. Будь это мелкое или нет, я просто хочу посмеяться, и это по просьбе человека, который бизнес использует сервер.
Аврелий,

4
@Aurelius, если вы знаете ip, и этот человек не маскирует его, почему бы вам не сделать это в самом приложении, php в этом случае. Просто убедитесь, что это ip xx.xx.xx.xx, и если это просто убить сценарий с ответом,die("blah blah");
Мигель

Принято как ответ, главным образом потому, что я не знал о fail2ban, и это действительно полезно в целом. Ответ Мигеля выше, а также ответ BlackWebWolf ниже, это обе вещи, которые я собираюсь рассмотреть!
Аврелий,

5

Существует возможность, и мы сделали это довольно много, чтобы отменить возможные атаки. Используйте iptables, чтобы перенаправить облачного провайдера (диапазон адресов) на другой порт, и злоумышленник получит ответ, даже в простых заголовках.

В Apache вы можете изменить заголовки, например:

Header set GetOut "Better luck next time!"

Hehehe !! Вот об этом я и говорю. Хорошая идея! Я посмотрю на это.
Аврелий,

5
эта стратегия, вероятно, будет иметь обратный эффект в ответ, потому что она позволяет злоумышленнику узнать, что работает, а что нет, гораздо лучше просто молча пропустить запрос и не отключать какие-либо флаги оповещения в его программном обеспечении для атаки ботов. В идеале, например, возвращение html запрашиваемой страницы. они никогда не узнают, что вы их поймали, ничего не происходит, и ваш сайт безопаснее. Не поддавайтесь желанию дать им знать, это ОШИБКА, всегда. Это просто помогает им отладить проблему. В вашем случае, просто переключитесь на более динамические диапазоны IP-адресов и т. Д., Делая проблему НАМНОГО сложнее решить.
Lizardx

1
Вы правы, это не рекомендуется - это даже возможно опасно. Стратегия с honeypot всегда лучше, но вопрос был ясен - как троллить атакующего :)
BlackWebWolf

Мне все равно, если это ошибка - я установил fail2ban, и он все равно будет забанен. Я очень сомневаюсь, что он действительно куда-нибудь доберется; Насколько я знаю, последние выпуски WordPress действительно исправили эту ошибку безопасности? Не говоря уже о взломе паролей длиной более 20 символов ... да, не происходит во время существования нашей вселенной.
Аврелий,

blackwebwolf, это похоже на то, как кто-то спрашивает, как реализовать устаревшее расширение mysql_ в php, в то время как на этот вопрос можно ответить технически, этот ответ неправильный, потому что реальный ответ означает сделать все правильно, в этом случае, например, используя вместо этого mysqli_ или xpdo. Это просто понятие, которое многие из нас сделали в прошлом, что реагирование любым способом, как троллинг, это что-то кроме огромного негатива, должно быть исправлено, потому что это серьезная ошибка, и если кто-то когда-либо страдал из-за эта ошибка, можно сразу понять, почему вопрос был неправильным.
Lizardx

3

Это очень просто с ModSecurity, который является сторонним WAF-модулем для Apache. Хотя это включает в себя изучение синтаксиса языка правил.

Вы также можете использовать ModSecurity, чтобы просто разорвать соединение, а не отвечать вообще.

Сказать, что установка ModSecurity как раз для этого, когда, как другие предлагали, вполне вероятно, что ответы будут проигнорированы, может быть излишним.


2

Я бы пошел с fail2ban и отбрасывал запросы из известных мест злоупотреблений. И если вы чувствуете, что поставщик услуг злоумышленника не виноват, сообщите об атаках на его адрес электронной почты.

Если вы хотите потратить время на создание чего-то, что замедлит атакующего, вы можете попробовать сделать тарпит . Сначала вы должны, конечно, знать, откуда происходят атаки. Затем вы можете использовать apache для перенаправления запроса из ip (range?) В конкретный скрипт. Это может помочь, хотя я сам не пробовал. Затем просто реализуйте скрипт, который, например, выводит точку (или что-то из / dev / null) каждые 15 секунд, чтобы соединение злоумышленника оставалось открытым бесконечно долго.

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

Проблема в том, что вы посвящаете свое время и ресурсы чему-то, что, вероятно, не будет столь же полезным, как более важная задача: защита вашего логина. Трудно атаковать, когда ты не знаешь, где атаковать. Рассмотрим некоторые из следующих:

  • ограничить доступ к странице входа (только ваша интрасеть? ip range? vpn? other?).
  • добавить reCaptcha или другой вопрос проверки для входа в систему.
  • использовать многофакторную аутентификацию .
  • скрыть страницу входа Если возможно, не делайте ссылки на него со своей главной страницы и не используйте / login или другое очевидное местоположение.

Спасибо за информацию! Итак, чтобы прояснить ситуацию, A) два пользователя, которые могут войти в систему, имеют случайно сгенерированные длинные пароли. Б) На странице входа есть своего рода капча. C) Я пытаюсь заставить работать .htaccess, чтобы предотвратить доступ к этой странице. Однако кажется, что стандарты для .htaccess менялись много раз - я везде вижу разный синтаксис, и пока что htaccess практически не работает.
Аврелий,

Кроме того, я сообщил обо всех атаках на online.net без ответа.
Аврелий,

Некоторые полезные советы для htaccess: stackoverflow.com/questions/6441578/… (я настоятельно рекомендую дайджест-аутентификацию).

Глядя на комментарии на этой странице, дайджест не кажется хорошей идеей? httpd.apache.org/docs/2.4/mod/mod_auth_digest.html
Аврелий,

1
Тут ты меня подловил. Да, я вспомнил это с того времени, когда я использовал дайджест-проверку подлинности, и тогда у нас не было везде https. Причина, по которой мы не используем пароли htacces, заключается в том, что это не долгосрочное решение. Можно использовать это, чтобы скрыть что-то за неделю до публикации, но для повседневного использования вам не нужен другой уровень паролей. Это даже не намного безопаснее. Когда ресурс на месте, который вообще не отображается в публичном Интернете, мы на правильном пути.
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.