IP 주소를 기반으로 특정 페이지를 제공 할 수 있습니까?

8

나는 내가 소유 한 2 개의 워드 프레스 사이트에 대한 무차별 대입 공격의 대상이었다. 공격자는 오래된 XML-RPC를 사용하여 무차별 암호 공격을 증폭시키고 있습니다. 운 좋게도 잘 생성 된 암호를 가지고 있기 때문에 그가 어디에서나 얻을 수있을 것입니다.

나는 단지 그가 (항상 같은 가상 클라우드 공급자) 다시 나올 때마다 그의 요청을 차단하기 위해 iptables를 사용 해왔다,하지만 난 차라리 그렇게 자신의 IP 주소를 요청할 때마다하는 서버를 수정하는 것입니다 어떤 페이지를, 그가 그에게 말하고 응답을 얻는다 인생을 얻을 수 있습니다. 대부분의 요청은 POST이므로 "다음 번에 더 나은 행운"을 포함하도록 응답 헤더를 수정하는 것이 이상적입니다. 또는 똑같이 만족하는 것.

이것이 가능한가? 나는 아파치 전문가와는 거리가 멀기 때문에 이것이 구현하기가 얼마나 어려운지 확신하지 못한다. 그러나 시간이 걸리더라도 만족할만한 가치는 없을 것입니다.

참고로 Wordpress 4.7.3을 호스팅하는 Apache 2.4.18과 함께 Ubuntu 16.04.2 LTS를 실행하고 있습니다.

apache-2.4 http-headers

— 아우렐리우스
소스

"항상 동일한 가상 클라우드 제공 업체로부터" OVH? 나는 어떤 이유로 그들의 서비스를 사용하는 많은 스크립트 키즈를 발견했습니다.

— hd.

아니, online.net ... 그들은 지금까지 내 학대 보고서 중 하나에 응답하지 않았습니다. 또한 처음으로 악용 사례 요청을 보내면 고객에게 불만 사항이 자동으로 전달된다는 사실을 알게되었습니다. 그래서 그는 어떻게 내 개인 웹 사이트를 찾았습니다. 잘 했어. online.net ....

— Aurelius

25

적절한 감옥에 fail2ban 을 설치 하고 완료하십시오. 결코 보이지 않을 가능성이 높기 때문에 사용자 정의 응답을 주저하지 마십시오.

— EEAA
소스

1

확실 해요 그러나 이것은 내가 항상 원했던 것입니다. 그가 그것을 보지 못하더라도, 그 가능성 때문에 나는 거의 울기 힘들 정도로 웃게됩니다.

— Aurelius

14

글쎄 : 1) IMHO는 스크립트 키디에 사소한 모욕을 표시하는 방법을 알아내는 것은 여기서 주제가 아닙니다. 2) 그렇게하면 아파치 리소스가 여전히 소비되지만 fail2ban / iptables는 요청을 업스트림으로 차단하므로 응용 프로그램이 처리 할 필요가 없습니다.

— EEAA

1

아 물론 이죠 그러나 나는 영구 금지 전에 약간의 재미를 갖고 싶다. 사소한 지 여부에 관계없이, 나는 단지 웃기를 원합니다. 그리고 이것은 비즈니스를 수행하는 사람이 서버를 사용하도록 요청합니다.

— Aurelius

4

@ Aurelius, IP를 알고 있다면이 사람이 그것을 가리지 않습니다.이 경우 앱 자체 에서이 작업을 수행하지 않는 이유는 무엇입니까? ip xx.xx.xx.xx인지 확인하고 응답으로 스크립트를 죽이는 지 확인하십시오.die("blah blah");

— Miguel

대부분 fail2ban에 대해 알지 못했기 때문에 대답으로 받아 들여 졌으므로 일반적으로 도움이됩니다. 위의 Miguel의 답변과 아래의 BlackWebWolf의 답변은 모두 내가 살펴볼 것입니다!

— Aurelius

5

가능한 공격이 있으며, 가능한 공격을 취소하기 위해 많은 노력을 기울였습니다. iptables를 사용하여 클라우드 공급자 (주소 범위)를 다른 포트로 리디렉션하고 일반 헤더에서도 공격자에게 응답을 제공합니다.

Apache에서는 예를 들어 헤더를 수정할 수 있습니다.

Header set GetOut "Better luck next time!"

— 블랙 웹 울프
소스

헤 헤헤 !! 이것이 바로 제가 말하는 것입니다. 좋은 생각! 이것에 대해 살펴 보겠습니다.

— Aurelius

5

이 전략은 아마도 공격자가 작동하는 것과 그렇지 않은 것을 알 수 있기 때문에 응답을 역효과를 줄 것입니다. 요청에 아무 것도 자동으로 전달하고 봇 공격 소프트웨어의 경보 플래그를 트립하지 않는 것이 훨씬 좋습니다. 예를 들어 요청 된 페이지의 html을 반환하는 것이 이상적입니다. 그들은 당신이 그들을 붙 잡았다는 것을 결코 알지 못하고 아무 일도 일어나지 않으며 사이트가 더 안전합니다. 그들에게 알려 주려는 충동을 저항하십시오. 그것이 항상 실수입니다. 단순히 문제를 디버깅하는 데 도움이됩니다. 귀하의 경우 단순히 더 많은 동적 IP 범위 등으로 전환하면 문제를 해결하기가 더 어려워집니다.

— Lizardx

1

당신이 옳습니다, 그것은 권장되지 않습니다-심지어 위험 할 수도 있습니다. 허니팟을 이용한 전략은 항상 더 좋지만 질문은 분명합니다. 공격자를 트롤하는 방법 :)

— BlackWebWolf

실수인지 신경 쓰지 않습니다. fail2ban을 설치하면 어쨌든 금지됩니다. 나는 그가 실제로 어디에나 갈 것이라는 점을 의심한다. 내가 아는 한, WordPress의 최신 릴리스는 실제로이 보안 버그를 수정 했습니까? 말할 것도없이, 20 자 이상의 암호를 무차별 적으로 적용하는 것은 .... 예, 우리 우주의 생애에서는 일어나지 않습니다.

— Aurelius

blackwebwolf는 PHP의 더 이상 사용되지 않는 mysql_ extension을 구현하는 방법을 묻는 사람과 비슷하지만 기술적으로 그 질문에 대답 할 수는 있지만 실제 대답은 예를 들어 mysqli_ 대신 또는 xpdo를 사용하여 올바르게 수행해야하기 때문에 그 대답은 잘못되었습니다. 그것은 우리가 과거에도했던 것처럼, 트롤링과 같은 어떤 방식 으로든 반응하는 것은 커다란 부정적인 것 이외의 다른 것입니다. 그것은 심각한 실수이기 때문에 고쳐야합니다. 그 실수는 그 질문이 왜 틀렸는 지 즉시 이해할 것입니다.

— Lizardx

3

Apache 용 타사 WAF 모듈 인 ModSecurity를 사용하면 매우 쉽습니다. 규칙 언어 구문을 배우는 것이 포함되지만.

ModSecurity를 사용하여 전혀 응답하지 않고 연결을 끊을 수도 있습니다.

다른 사람들이 제안했듯이 ModSecurity를 설치하면 응답이 무시 될 수 있습니다.

— 배리 폴라드
소스

2

fail2ban을 사용하여 알려진 남용 위치에서 요청을 삭제합니다. 공격자의 서비스 제공 업체가 책임을지지 않는다고 생각되면 공격을 악용 이메일 주소로보고하십시오.

공격자가 느려질 수있는 무언가를 만드는 데 시간을 보내고 싶다면 타르 핏을 만들어보십시오 . 먼저 공격의 출처를 알아야합니다. 그런 다음 아파치를 사용하여 요청을 ip (범위?)에서 특정 스크립트로 리디렉션 할 수 있습니다. 이것은 내가 그것을 자신을 시도하지 않은 있지만 트릭을 할 수 있습니다. 그런 다음 15 초마다 점 (또는 / dev / null에서 무언가)을 인쇄하여 공격자의 연결을 무한정 열린 상태로 유지하는 스크립트를 구현하십시오.

공격자는 스크립트를 사용하여 사이트를 공격 할 가능성이 높기 때문에 연결이 모두 활성화 된 것처럼 보이기 때문에 시간이 초과되지 않고 요청이 즉시 거부되지 않습니다.

문제는 더 중요한 관심사 인 로그인 보안과 같이 도움이되지 않는 시간과 리소스를 투자하는 것입니다. 공격 할 위치를 모르면 공격하기가 어렵습니다. 다음 중 일부를 고려하십시오.

로그인 페이지에 대한 액세스를 제한하십시오 (인트라넷? ip 범위? vpn? 기타?).
reCaptcha 또는 기타 확인 질문을 추가 하여 로그인하십시오.
사용하는 다중 요소 인증을 .
로그인 페이지를 숨기십시오. 가능하면 메인 페이지에서 링크하지 말고 / login 또는 다른 명백한 위치를 사용하지 마십시오.

— 커뮤니티
소스

정보에 대해서 감사드립니다! 따라서 문제를 해결하기 위해 A) 로그인 할 수있는 두 명의 사용자가 임의로 생성 된 긴 비밀번호를 가지고 있습니다. B) 로그인 페이지에 일종의 보안 문자가 있습니다. C) 해당 페이지에 대한 액세스를 방지하기 위해 .htaccess가 작동하려고합니다. 그러나 .htaccess의 표준이 여러 번 변경 된 것 같습니다. 어디서나 다른 구문을 보았으며 지금까지 htaccess는 거의 작동하지 않습니다.

— Aurelius

또한 모든 공격을 online.net에보고했습니다.

— Aurelius

htaccess에 대한 유용한 팁 : stackoverflow.com/questions/6441578/… (다이제스트 인증을 강력히 권장합니다).

이 페이지의 의견을 보면 다이제스트는 좋은 생각처럼 보이지 않습니까? httpd.apache.org/docs/2.4/mod/mod_auth_digest.html

— 아우렐리우스

1

당신은 저를 거기에 데려 갔다. 예, 다이제스트 인증을 사용했을 때부터 우리는 https가 없었습니다. htacces 암호를 사용하지 않는 이유는 장기적인 해결책이 아니기 때문입니다. 게시하기 전에 일주일 동안 무언가를 숨기려면 사용하는 것이 좋지만 일상적인 사용에는 다른 수준의 암호를 원하지 않습니다. 훨씬 더 안전하지도 않습니다. 퍼블릭 인터넷에 전혀 표시되지 않는 리소스가 있으면 올바른 방향에 있습니다.