WordPress 스팸 댓글이 WordPress 블로그 충돌 및 서버 중단을 방지하는 방법

우선, 이 기사는 댓글을 스팸으로 감지하고 플래그 지정하는 방법에 관한 것이 아니라는 점을 분명히 하고 싶었습니다. WordPress 플러그인 Akismet은 이미 전통적인 WordPress 스팸 댓글을 선별하고 필터링하는 작업을 꽤 잘 수행하고 있습니다.

대신 이 게시물은 댓글 스팸 및 기타 악성 활동으로 인해 서버가 다운되고 블로그가 다운 되는 것을 방지하는 방법에 관한 것입니다.

사진 제공: BoxChain

지난 기사에서 언급했듯이 내 블로그의 트래픽은 지난 1년 동안 두 배로 증가했습니다.

그리고 불행하게도 그 기간 동안 스팸 댓글의 양도 10배나 증가했습니다.

아이디어를 제공하기 위해 12월에는 몇 초마다 20개 이상의 스팸 댓글이 쏟아지는 며칠을 보냈습니다.

네, 맞습니다. 대시보드를 새로 고칠 때마다 Akismet 필터에 20개 이상의 스팸 댓글이 표시됩니다. 실제로 스팸의 양으로 인해 내 서버의 모든 웹 사이트는 그 기간 동안 매우 느리거나 액세스할 수 없었습니다.

WordPress의 문제

이제 정상적인 작동에서 내 블로그는 WP Super Cache라는 플러그인으로 인해 트래픽이 많은 상황에서 꽤 잘 작동합니다.

기본적으로 이 플러그인은 최종 사용자에게 매우 빠르게 제공될 수 있도록 내 블로그에 있는 모든 기사의 정적 버전을 만듭니다.

그러나 이 플러그인은 댓글을 하나씩 처리하기 위해 서버에서 매번 WordPress를 호출해야 하기 때문에 엄청난 댓글 유입에는 무력합니다.

그리고 WordPress는 리소스를 많이 사용하기 때문에 전용 서버에 있고 캐싱 플러그인을 사용하는 경우에도 스팸 댓글이 많이 유입되면 블로그가 쉽게 다운될 수 있습니다.

세계 최고의 댓글 스팸 필터를 사용하더라도 문제가 되지 않습니다. 모든 스팸 댓글은 서버 리소스를 많이 차지하는 WordPress에서 처리해야 합니다.

스팸봇의 특징

이제 느리거나 액세스할 수 없는 블로그를 갖는 것이 한 가지이지만 댓글 스팸은 허용할 수 없는 동일한 서버에서 실행되는 다른 사이트에도 영향을 미칩니다. 스팸 봇에 대해 조사한 후 몇 가지 사실을 발견했습니다.

• 스팸 봇은 일반적으로 쿠키를 허용하지 않습니다.
• 스팸 봇은 몇 초 만에 댓글 스팸을 남길 수 있습니다.
• 스팸 봇은 일반적으로 자바스크립트를 실행하지 않습니다.

그래서 이것은 무엇을 의미합니까? 비기술적인 용어로 스팸 봇은 웹 브라우저에서 일반 사용자처럼 작동하지 않습니다. 그리고 내 문제를 해결하는 열쇠는 스팸 봇을 즉시 감지하고 WordPress를 실행하는 대신 오류 페이지로 안내하는 것입니다.

위에서 설명한 특성을 기반으로 사용자 컴퓨터에 쿠키를 설치하거나 페이지 로드 후 몇 초 동안 댓글을 비활성화하거나 일부 자바스크립트 코드를 만들어 스팸 봇을 감지하여 스팸 봇을 감지할 수 있습니다.

내 댓글 스팸 문제 해결

많은 고민 끝에 내 블로그의 페이지에 액세스할 때마다 사용자 컴퓨터에 비밀리에 쿠키를 삽입하는 수정 사항을 생각해 냈습니다. 그런 다음 주석이 통과하도록 허용하기 전에 사용자 컴퓨터에서 이 쿠키를 찾을 수 있습니다.

스팸 봇은 일반적으로 쿠키를 허용하지 않기 때문에 봇을 쉽게 감지하여 정적 오류 페이지로 안내할 수 있습니다.

원래는 자바스크립트로 작성한 이 블로그 항목에 내 소스 코드를 게시할 계획이었으나(궁금하시면 기꺼이 보내드리겠습니다), 몇 명의 동료 블로거와 이야기한 후 동일한 작성자가 WP Super Cache의 Donncha는 내가 방금 작성한 것과 본질적으로 동일한 작업을 수행하는 Cookies For Comments라는 플러그인을 이미 작성했습니다.

그의 플러그인은 내 자바스크립트 플러그인보다 훨씬 더 우아하게 작성되었으므로 다운로드하는 것이 좋습니다.

그러나 Donncha의 Cookies For Comments 플러그인을 사용할 계획이라면 플러그인의 설치 지침과 다른 .htaccess를 다음과 같이 변경해야 합니다.

이 두 줄은 무엇을합니까? 기본적으로 이 코드 줄은 사용자 컴퓨터에 삽입된 비밀 쿠키의 존재를 감지합니다. 쿠키가 없으면 사용자 또는 스팸 봇은 WordPress의 404 페이지 또는 "페이지를 찾을 수 없음"으로 연결됩니다.

이제 이 기본 설정의 문제는 여전히 많은 서버 리소스가 필요한 404 페이지를 처리하기 위해 WordPress가 계속 호출된다는 것입니다.

여기서 차이점은 스팸 봇이 완전히 정적 오류 페이지로 연결되어 WordPress가 완전히 로드되지 않는다는 것입니다.

문제 해결됨??? 좀 빠지는

그래서 위에서 설명한 변경 사항으로 내 댓글 스팸 문제가 해결되었지만 며칠 동안 원활하게 실행된 후 내 서버가 다시 충돌하기 시작했습니다! 내 서버 로그를 살펴보면 다음을 발견했습니다.

mywifequitherjob.com GET /oxvumirserver33.rar
mywifequitherjob.com GET /oxvumirserver33.rar
mywifequitherjob.com GET /oxvumirserver33.rar

기본적으로 일부 불량 컴퓨터는 계속해서 내 서버에 존재하지 않는 동일한 파일에 액세스하려고 시도하여 사이트가 충돌했습니다. 이제 일반 웹사이트에서는 이러한 악성 액세스가 서버에 전혀 영향을 미치지 않습니다.

그러나 WordPress는 존재하지 않는 파일에 대한 모든 액세스를 처리하고 사용자를 WordPress의 사용자 지정 404 또는 "페이지를 찾을 수 없음" 웹페이지로 보냅니다.

WordPress가 리소스 호그라고 언급했습니까? 필요한 것은 이러한 가짜 액세스의 무리이며 사용하는 캐싱 플러그인에 관계없이 서버가 계속 다운됩니다.

이 문제를 푸는 비결은 내 댓글 스팸 문제와 비슷하다. 이상적으로는 서버 리소스를 절약하기 위해 WordPress를 완전히 방정식에서 제외하고 불량 사용자를 완전히 정적 오류 페이지로 보내는 것이 좋습니다.

이 모든 코드는 무엇을 합니까? 기본적으로 위의 유형 중 하나와 일치하는 파일이 내 서버에서 요청되면 내 서버가 WordPress를 완전히 우회하기를 원합니다. 파일이 없으면 사용자는 404.html이라는 정적 오류 페이지로 이동합니다.

다시 한 번, WordPress를 우회하는 것이 충돌 문제를 해결하는 열쇠입니다. 내 서버 로그의 불량 프로세스가 .rar 파일에 액세스하고 있기 때문에 이제 이 악의적인 사용자를 리소스를 전혀 사용하지 않는 내 오류 페이지로 리디렉션합니다.

이것이 내 모든 문제를 해결합니까?

그래서 저는 몇 주 동안 위의 2가지 변경 사항으로 실행해 왔으며 제 서버는 속도 저하 없이 챔피언처럼 실행되고 있습니다. 불행히도 WordPress의 작성 방식은 모든 악성 액세스로 인해 서버가 충돌하는 것을 방지할 수 없습니다.

예를 들어, 누군가 내 블로그에 없는 기사에 액세스하려고 할 때마다 WordPress는 여전히 로드됩니다. 따라서 이론적으로 누군가가 MyWifeQuitHerJob.com 또는 WordPress 블로그를 중단하려는 경우 사이트에 존재하지 않는 페이지에 계속해서 액세스하기만 하면 됩니다.

그러나 그 동안에는 모든 것이 안정적으로 보입니다. 바라건대 앞으로 WordPress는 이러한 서버 문제를 해결하기 위해 패치될 수 있습니다.