오늘 DigitalOcean으로부터 DDoS 공격을 받고 있었기 때문에 거기에 있는 내 Droplet의 연결이 끊어졌다는 통보를 받았습니다.
그들은 나에게 원인을 조사하고 알아내라고 요청했습니다.
이것은 Ubuntu 14였고 거기에는 6개의 Apache VirtualHost가 있었습니다. 모두 라이브였습니다.
내 사이트 중 하나는 몇 가지 플러그인이 포함된 WordPress 설치였습니다.
다른 사이트에는 Google Maps API 코드가 포함되어 있었습니다.
나머지에는 내 원본 코드만 들어 있었습니다.
아직 서버에 들어가지 않았습니다. 그런 다음 이 문제를 일으키는 소프트웨어를 올바르게 찾는 프로세스는 무엇입니까?
내 비밀번호로 SSH 키를 사용하지 않았기 때문에 이런 일이 발생한 것으로 의심됩니다.
답변1
먼저, 이런 일을 겪게 된 데 대해 애도를 표합니다. 하지만 이것을 정리할 수 있습니다. 먼저 이 문제를 해결해야 합니다.
내 비밀번호로 SSH 키를 사용하지 않았기 때문에 이런 일이 발생한 것으로 의심됩니다.
99%는 그렇지 않다고 확신합니다. 20년 이상의 경험을 통해 제가 개인적으로 처리하고 정리한 거의 모든 웹 서버 손상은 애플리케이션 수준의 결함과~ 아니다SSH 또는 SFTP에 연결된 모든 것. 실제로 대부분의 웹 개발자/관리자는 SSH/SFTP 수준 손상을 결코 처리하지 않습니다. 전면 코드의 결함은 공개 웹 시스템에 대한 많은 맬웨어 및 부당한 침입의 주요 진입점입니다.
그리고 귀하의 경우에는 다음과 같이 진술합니다.
이것은 Ubuntu 14였고 거기에는 6개의 Apache VirtualHost가 있었습니다. 모두 라이브였습니다.
내 사이트 중 하나는 몇 가지 플러그인이 포함된 WordPress 설치였습니다.
다른 사이트에는 Google Maps API 코드가 포함되어 있었습니다.
내 생각에는 WordPress 업데이트/패치를 최신 상태로 유지하지 않는 한 WordPress 설치가 취약한 것 같습니다. 핵심 WordPress뿐만 아니라 플러그인도 마찬가지입니다.
기존 코드베이스, 데이터베이스 및 구성을 백업합니다.
제가 가장 먼저 할 일은 index.php해당 사이트의 각 루트 인덱스에 "Down for Maintenance"라는 문구를 설정하여 Apache 가상 호스트를 중성화하는 것입니다. 또한 TAR/Gzip 아카이브를 통해 각 가상 호스트 설치의 복사본을 만들고 잠재적인 법의학을 위해 다운로드합니다. 이는 MySQL 데이터베이스 덤프 및 관련 구성 파일을 포함하여 모든 Apache 가상 서버에 대해 수행되어야 합니다.
/tmp/감염 징후가 있는지 디렉토리를 확인하십시오 . 필요하다면 날려버리세요.
다음으로 권장할 사항은 /tmp/서버에서 디렉터리를 덤프하고 다시 만드는 것입니다. 그 이유는 Linux 웹 서버에서 많은 악성 코드 감염이 해당 페이로드의 상당 부분을 /tmp/디렉터리에 배치하기 때문입니다. 난 더 깊이 들어가여기 이 답변에서그러나 그것은 다음을 수행하는 것으로 귀결됩니다.
먼저 /tmp/디렉토리를 살펴보고 거기에 있으면 안 되는 것이 있는지 확인하십시오. Linux 시스템의 악성 코드 10개 중 9개는 /tmp/.
무엇이 들어가야 하는지, 없어야 하는지 확실하지 않은 경우에는 /tmp/쉽지만 극단적인 방법으로 나쁜 것을 제거할 수 있습니다. 명령줄에서 온라인으로 실행하세요.
rm -rf /tmp && mkdir /tmp && chown root:root /tmp && chmod 1777 /tmp
또는 다음과 같이 각 명령을 개별적으로 실행합니다.
sudo rm -rf /tmp
sudo mkdir /tmp
sudo chown root:root /tmp
sudo chmod 1777 /tmp
그런 다음 서버를 재부팅하여 문제가 해결되었는지 확인하세요. 그렇다면 축하드립니다! 그러나 원래 시스템을 유발한 것이 무엇이든 여전히 시스템에 침투할 수 있기 때문에 아직 숲에서 나온 것은 아닙니다. 그들이 당신을 다시 감염시키는 것은 시간 문제일 뿐입니다. 즉, 시스템의 약점으로 인한 혼란을 정리하지만 그 약점이 무엇인지 찾아 강화해야 합니다.
Bash "shellshock" 취약점 검사.
bash그리고 다른 답변에서는 "쉘쇼크" 취약성을 확인하는 방법에 대한 팁을 제공합니다 .이 사이트는 좋은 테스트 도구를 제공합니다bash귀하의 서버가 "shellshock" 공격 에 취약한지 확인하십시오 . 솔직히 이것은 발견된 이후 패치해야 했던 가장 일반적인 보안 허점 중 하나였습니다. 따라서 이것이 서버에서도 약점이 될 가능성이 높습니다. 취약점이 발견된 경우 수정하는 방법은 bash모든 OS 수준 구성 요소를 업그레이드/패치하는 방법에 대한 아래 섹션을 참조하세요. 그렇게 하고 bash업그레이드/패치도 해야 합니다.
모든 OS 수준 구성 요소를 업그레이드/패치합니다.
이제 그것이 어렵게 들릴 수도 있지만 현실은 Linux 시스템에 대한 보안 패치가 항상 릴리스된다는 것입니다. Ubuntu 또는 CentOS와 같은 표준화된 Linux 설치를 사용하는 경우 이와 같이 패키지 설치 프로그램을 통해 간단히 업데이트/업그레이드를 실행할 수 있습니다. 우분투에서는 이렇게 하세요:
sudo apt-get update
sudo apt-get upgrade
이제 한동안 시스템을 업데이트하지 않았다면 처리해야 할 수많은 패치와 업데이트가 표시될 수 있습니다. 당황하지 말 것! 그것은 정상입니다. updateand 를 실행 upgrade하고 기다리면 됩니다. 나중에 재부팅해야 할 수도 있지만 완료되면 핵심 OS가 완전히 패치되고 최신 상태여야 합니다.
Apache 가상 서버 코드 시스템의 코드베이스를 평가합니다. WordPress 및 Google API 관련 자료입니다.
자신을 보호하십시오. 이것은 더 추악한 부분입니다. 이전에 작성된 코드베이스를 다운로드하고 평가해야 합니다.잠재적으로감염된. 한두 개의 사이트만 손상되었으면 좋겠습니다. 이를 해결하는 방법은 설정마다 다르지만 일반적으로 해야 할 일은 각 사이트를 개발 환경에 로드하고 WordPress 코어를 업그레이드하고 플러그인을 업그레이드하고 모든 것이 제대로 작동하는지 확인한 다음 해당 코드를 깨끗하게 고려하는 것입니다. /안정적인.
이제 나는 이 단계를 지나치게 단순화했습니다. 그러나 현실은 패치와 업그레이드를 수행한 후에도 WordPress 코어에 악성 코드가 여전히 남아 있을 수 있다는 것입니다. 따라서 당신이 할 수 있는 또 다른 일은 각 WordPress 사이트를 처음부터 다시 구축하는 것입니다. 데이터베이스와 템플릿을 유지하고 기본적으로 새롭고 깨끗한 WordPress 코어에서 사이트를 다시 구축하세요.
예, 많은 작업처럼 들리지만, 서로 다른 코드베이스를 가진 가상 서버가 그렇게 많으면 선택의 여지가 없습니다.
사후 조언.
이것이 모든 사람에게 효과가 있는 것은 아니지만 다음과 같이 말하고 싶습니다. 깨끗한 코드베이스를 위한 백업 및 어쩌면 GitHub 저장소도 위에 있는 지저분한 마지막 "평가" 단계 없이 혼란을 정리할 수 있는 방법입니다.
내가 하는 일은 내가 작업하는 모든 데이터베이스 드라이브 사이트에서 정기적으로 MySQL 덤프를 실행하고 깨끗한 핵심 코드베이스가 GitHub에 있는지 확인하는 것입니다. 그런 다음 맬웨어 감염이 발생하면 MySQL 백업을 조사하고 GitHub에서 깨끗한 코드를 다시 배포하여 코드베이스가 깨끗한지 확인할 수 있습니다. 그리고 서버 자체가 믿음을 넘어서는 것이라면? 감염된 시스템을 덤프하고, 새로운 Linux 시스템을 재구축하고, 코드를 배포하고, 데이터베이스를 가져오고, 구성을 조정하고, 하루만 지나면 됩니다.
모든 웹사이트의 99%는 단지 데이터베이스, 코드베이스 및 구성 세트일 뿐이라는 점을 기억하세요. 감염되지 않은 코드와 MySQL 데이터베이스의 백업을 "동결"하거나 백업할 수 있는 확실한 방법이 있다면 구성 작업만 처리하면 됩니다. 처음부터 코드를 정리하는 것과 비교하면 사소한 고통입니다.