Wordpress에서 약 25개의 사이트를 호스팅하는 내 서버에서 토요일 오후부터 급제동이 시작되었습니다. 이전의 공격( , )을 눈치채지 못한 채 살아남았기 때문에 무엇이 잘못되었는지 즉시 이해하지 못했습니다.
알아냈을 때 비밀번호 검색 + XMLRPC에 대한 많은 요청이 있는 것으로 나타났습니다.
결과적으로 즉시는 아니지만 모든 것을 차단할 수 있었습니다. 고양이 3으로 간단한 리셉션그것을 피하는 방법.
이 기술은 모든 사람에게 가장 잘 알려져 있지만 설명에서 찾지 못한 몇 개의 갈퀴를 밟았습니다. 갑자기 이것은 누군가의 시간을 절약해 줄 것입니다.
1. 제한 로그인 시도 플러그인 열거를 중지합니다. 예를 들어 다음을 사용할 때 다른 보호 기능이 서버를 크게 중단시키기 때문에 정확히 넣습니다. 플러그인 로그인 Security Solution 서버가 30분 만에 죽고 플러그인이 데이터베이스를 많이 로드합니다.
설정에서 "프록시용" 확인란을 선택하십시오. 그렇지 않으면 모든 사람의 서버 IP를 결정하고 자동으로 모든 사람을 차단합니다.
업데이트, 감사합니다. 자세한 내용은 아래 설명에 있습니다. "직접 연결"이 활성화되어 있을 때 정의가 작동하지 않는 경우에만 "프록시용" 확인란을 활성화합니다.
2. XML-RPC 비활성화 - 플러그인 XML-RPC 비활성화(활성화만 하면 끝).
3. wp-login.php 닫기 - ip를 통해 사이트에 액세스하면 플러그인이 작동하지 않고 선택 도구가 사이트를 계속 망치게 됩니다. 이를 방지하려면 .htaccess에 추가하십시오.
wp-login 파일을 복사하고 poletnormalny.php와 같은 이상한 이름으로 이름을 변경하고 파일 내에서 자동 수정에 의해 모든 wp-login.php 비문을 poletnormalny.php로 변경합니다.
모든 것, 이제 파일로만 관리자 패널에 액세스할 수 있습니다.
이 간단한 3단계 후에 사이트가 다시 날아오르기 시작했고 평화가 찾아왔습니다.
글쎄, 갑자기 재미있다.
옵션 중 하나는 공격을 받고 있는지 확인하는 방법입니다. 이것은 nginx 로그에서 볼 수 있습니다(예를 들어, 여기에 Debian /var/log/nginx access.log 파일의 경로가 있습니다).XML-RPC 소개
웹에는 사용자에게 특정 정보를 제공하는 다양한 리소스가 있습니다. 이는 일반적인 정적 페이지를 의미하는 것이 아니라 예를 들어 데이터베이스 또는 아카이브에서 검색된 데이터를 의미합니다. 이것은 재무 데이터(환율, 주식 시세 데이터), 날씨 데이터 또는 뉴스, 기사, 포럼 메시지와 같은 보다 방대한 정보의 아카이브가 될 수 있습니다. 이러한 정보는 예를 들어 요청에 대한 응답으로 양식을 통해 페이지 방문자에게 제공되거나 매번 동적으로 생성될 수 있습니다. 그러나 어려움은 그러한 정보가 종종 최종 사용자, 즉 사람이 아닌 다른 시스템, 계산 또는 기타 요구 사항에 이 데이터를 사용하는 프로그램에 필요하다는 것입니다.
실제 예: 통화 시세를 표시하는 은행 사이트의 페이지. 다음과 같이 페이지에 액세스하면 일반 사용자, 브라우저를 통해 모든 페이지 디자인, 배너, 메뉴 및 검색의 진정한 목적을 "프레임"하는 기타 정보를 볼 수 있습니다. 이러한 인용문을 온라인 상점에 입력해야 하는 경우 필요한 데이터를 수동으로 선택하고 클립보드를 통해 웹사이트로 전송하는 것 외에 다른 방법이 없습니다. 그리고 이것을 매일 해야 합니다. 정말 탈출구가 없는 걸까요?
문제를 정면으로 해결하면 솔루션이 즉시 제안됩니다. 데이터가 필요한 프로그램(사이트의 스크립트)은 "일반 사용자"로 서버에서 페이지를 수신하고 수신된 html 코드를 구문 분석(파싱)하고 추출합니다. 그것에서 필요한 정보. 그것은 할 수 있습니다 또는 정상 정규식, 또는 html 파서로. 접근 방식의 복잡성은 비효율성에 있습니다. 첫째, 데이터의 작은 부분을 얻으려면(통화에 대한 데이터는 문자 그대로 12자 또는 2자임) 전체 페이지를 가져와야 하며, 이는 최소 수십 킬로바이트입니다. 둘째, 페이지 코드가 변경되면(예: 디자인이 변경되거나 다른 항목이 변경됨) 구문 분석 알고리즘을 다시 실행해야 합니다. 예, 리소스를 적절하게 선택합니다.
따라서 개발자는 결정에 이르렀습니다. 투명하고 (프로토콜 및 전송 매체 수준에서) 모든 위치에 있고 모든 언어로 작성할 수있는 프로그램간에 쉬운 데이터 교환을 허용하는 일종의 보편적 인 메커니즘을 개발해야합니다. 그리고 아래에서 실행 운영 체제모든 하드웨어 플랫폼에서. 이러한 메커니즘은 이제 "웹 서비스"(웹 서비스), "SOAP", "서비스 지향 아키텍처"(서비스 지향 아키텍처)라는 유명한 용어로 불립니다. 데이터 교환을 위해 공개되고 오랜 시간 테스트된 표준이 사용됩니다. 메시지 전송에는 HTTP 프로토콜이 사용됩니다(예를 들어 SMTP와 같은 다른 프로토콜을 사용할 수 있지만). 데이터 자체(이 예에서 환율)는 XML 문서 형태로 플랫폼 간 형식으로 포장되어 전송됩니다. 이를 위해 SOAP라는 특별한 표준이 발명되었습니다.
예, 이제 웹 서비스, SOAP 및 XML이 모든 사람의 입술에 있고 적극적으로 구현되기 시작했으며 IBM 및 Microsoft와 같은 대기업은 웹 서비스의 전체 구현을 돕기 위해 설계된 신제품을 출시하고 있습니다.
하지만! 은행 웹사이트에서 온라인 상점 엔진으로 이체해야 하는 환율의 경우 이러한 솔루션은 매우 어려울 것입니다. 결국 SOAP 표준에 대한 설명만 15000페이지에 불과하고 그게 다가 아닙니다. 실제로 사용하려면 타사 라이브러리 및 확장(PHP 5.0부터 SOAP 작업을 위한 라이브러리 포함)으로 작업하고 수백, 수천 줄의 코드를 작성하는 방법도 배워야 합니다. 그리고 몇 개의 문자와 숫자를 얻기 위한 이 모든 것은 분명히 매우 무겁고 비합리적입니다.
따라서 정보 교환을 위한 대안 표준인 XML-RPC가 하나 더 있습니다. UserLand Software Inc가 Microsoft의 참여로 개발했으며 인터넷을 통한 응용 프로그램 간의 통합 데이터 전송을 위해 설계되었습니다. 실제 웹 서비스의 모든 "엔터프라이즈" 기능이 필요하지 않은 단순 서비스를 구축할 때 SOAP를 대체할 수 있습니다.
XML-RPC의 약어는 무엇을 의미합니까? RPC는 원격 프로시저 호출 - 원격 프로시저 호출을 나타냅니다. 이는 응용 프로그램(서버의 스크립트 또는 일반 응용 프로그램의 클라이언트 컴퓨터) 물리적으로 구현되어 다른 컴퓨터에서 실행되는 방법을 투명하게 사용할 수 있습니다. 여기서 XML은 전송된 데이터를 설명하기 위한 범용 형식을 제공하는 데 사용됩니다. 전송으로서 HTTP 프로토콜은 메시지를 전송하는 데 사용되므로 라우터, 방화벽, 프록시 서버와 같은 모든 네트워크 장치를 통해 데이터를 자유롭게 교환할 수 있습니다.
따라서 이를 사용하려면 하나 이상의 메소드를 제공하는 XML-RPC 서버, 올바른 요청을 형성하고 서버 응답을 처리할 수 있는 XML-RPC 클라이언트, 성공을 위해 필요한 서버 매개변수도 알아야 합니다. 작업 - 주소, 메서드 이름 및 전달된 매개변수.
XML-RPC에 대한 모든 작업은 "요청-응답" 모드에서 이루어지며, 이는 트랜잭션의 개념과 지연된 호출을 만드는 기능이 모두 있는 기술과 SOAP 표준 간의 차이점 중 하나입니다(서버가 요청을 저장하고 미래의 특정 시간에 응답). 이것들 추가 기능강력한 기업 서비스에 더 유용하기 때문에 서버 개발 및 지원이 크게 복잡해지고 클라이언트 솔루션 개발자에게 추가 요구 사항이 적용됩니다.
XML-RPC로 작업하는 절차는 요청의 형성으로 시작됩니다. 일반적인 요청은 다음과 같습니다.
POST/RPC2 HTTP/1.0
사용자 에이전트: eshop-test/1.1.1(FreeBSD)
호스트: server.localnet.com
콘텐츠 유형: text/xml
콘텐츠 길이: 172
첫 번째 줄은 표준 HTTP POST 요청 헤더를 형성합니다. 필수 매개변수에는 호스트, 데이터 유형(MIME 유형)(텍스트/xml이어야 함) 및 메시지 길이가 포함됩니다. 표준은 또한 사용자 에이전트 필드를 채워야 하지만 임의의 값을 포함할 수 있다고 명시합니다.
다음은 XML 문서의 일반 헤더입니다. 요청의 루트 요소 -
선
다음으로 전달된 매개변수가 설정됩니다. 이를 위해 섹션
모든 매개변수를 설명한 후 닫는 태그가 뒤따릅니다. XML-RPC의 요청과 응답은 일반적인 XML 문서이므로 모든 태그를 닫아야 합니다. 그러나 XML 표준에는 존재하지만 XML-RPC에는 단일 태그가 없습니다.
이제 서버 응답을 분석해 보겠습니다. HTTP 응답 헤더는 정상이며 요청이 성공적으로 처리되면 서버는 HTTP/1.1 200 OK 응답을 반환합니다. 요청과 마찬가지로 MIME 유형, 메시지 길이 및 응답이 생성된 날짜를 올바르게 지정해야 합니다.
응답 본문은 다음과 같습니다.
이제 루트 태그 대신
요청을 처리하는 동안 오류가 발생한 경우 대신 응답에는 요소가 있습니다.
이제 XML-RPC의 데이터 유형을 간단히 살펴보겠습니다. 데이터 유형은 단순 유형 7개와 복합 유형 2개 총 9가지가 있습니다. 각 유형은 고유한 태그 또는 태그 세트(복합 유형의 경우)로 설명됩니다.
단순 유형:
정수- 태그
부울 유형- 태그
아스키 문자열- 태그로 설명
부동 소수점 숫자- 태그
날짜와 시간- 태그로 설명
마지막 단순 유형은 base64로 인코딩된 문자열, 태그로 설명
복합 유형은 구조와 배열로 표현됩니다. 루트 요소에 의해 정의된 구조
배열에는 이름이 없으며 태그로 설명됩니다.
물론 누군가는 그러한 데이터 유형 목록이 매우 열악하고 "확장할 수 없다"고 말할 것입니다. 예, 복잡한 개체 또는 많은 양의 데이터를 전송해야 하는 경우 SOAP를 사용하는 것이 좋습니다. 그리고 작고 요구되지 않는 응용 프로그램의 경우 XML-RPC가 매우 적합하며, 그 기능이 너무 많은 것으로 판명되는 경우가 많습니다! 배포 용이성, 거의 모든 언어 및 플랫폼에 대한 매우 많은 수의 라이브러리, PHP의 광범위한 지원을 고려할 때 XML-RPC는 경쟁자가 없는 경우가 많습니다. 보편적 인 솔루션으로 즉시 조언하는 것은 불가능하지만 각각의 경우 상황에 따라 결정해야합니다.
XML-RPC 기술은 핑백, 트랙백, 관리자 영역에 로그인하지 않고 원격 사이트 관리 등과 같은 다양한 멋진 기능을 위해 WordPress 시스템에서 사용됩니다. 불행히도 공격자는 이를 웹사이트에 대한 DDoS 공격에 사용할 수 있습니다. 즉, 자신을 위해 또는 주문을 위해 아름답고 흥미로운 WP 프로젝트를 만들고 동시에 의심하지 않고 DDoS 봇넷의 일부가 될 수 있습니다. 수만, 수십만 개의 사이트를 연결하여 악의적인 사람들은 피해자에게 강력한 공격을 가합니다. 귀하의 사이트도 고통을 겪고 있지만. 로드는 호스팅되는 호스팅으로 이동합니다.
이러한 나쁜 활동의 증거는 다음 행을 포함하는 서버 로그(nginx의 access.log)일 수 있습니다.
103.238.80.27 - - "POST /wp-login.php HTTP/1.0" 200 5791 "-" "-"
그러나 다시 XML-RPC 취약점으로 돌아갑니다. 시각적으로 서버에서 사이트가 느리게 열리거나 사이트를 전혀 로드할 수 없는 경우(502 Bad Gateway 오류) 나타납니다. 내 FASTVPS 호스트의 기술 지원에서 내 추측을 확인하고 다음과 같이 조언했습니다.
- 다음으로 워드프레스 업데이트 최신 버전플러그인과 함께. 일반적으로 팔로우하면 최신 4.2.3을 설치해야 한다는 내용을 읽었을 수 있습니다. 보안 비판으로 인해(마치 이전 버전). 요컨대 업데이트가 좋습니다.
- XML-RPC Pingback 비활성화 플러그인을 설치합니다.
WordPress에서 XML-RPC 비활성화
이전에는 XML-RPC를 활성화/비활성화하는 옵션이 시스템 설정 어딘가에 있었지만 지금은 찾을 수 없는 것 같습니다. 따라서 이를 제거하는 가장 쉬운 방법은 적절한 플러그인을 사용하는 것입니다.
Disable XML-RPC Pingback을 찾아 다운로드하거나 시스템 관리자 패널에서 직접 설치합니다. 추가로 구성할 필요가 없으며 모듈이 즉시 작동하기 시작합니다. XML-RPC 인터페이스에서 pingback.ping 및 pingback.extensions.getPingbacks 메서드를 제거합니다. 또한 HTTP 헤더에서 X-Pingback을 제거합니다.
블로그 중 하나에서 XML-RPC 비활성화를 제거하는 몇 가지 옵션을 더 찾았습니다.
1. 템플릿에서 XML-RPC를 비활성화합니다.
이를 위해 테마의 functions.php 파일에 다음 줄이 추가됩니다.
나는 개인적으로 마지막 두 가지 방법을 사용하지 않았습니다. Disable XML-RPC Pingback 플러그인을 연결했습니다. 충분할 것 같습니다. 추가 설정이 싫은 분들을 위해 대안을 제시했습니다.