저는 최근 회사 서버 중 일부를 Google의 Compute Engine으로 마이그레이션하기 시작했습니다. 이 외에도 2노드 Elasticsearch 클러스터도 설정했습니다.
오늘 저는 노드 중 하나에서 top 명령을 실행하고 있었는데 몇 가지 의심스러운 프로세스를 발견했습니다.
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
11995 elastics 20 0 424m 25m 400 S 533.0 0.1 877:26.82 gg
30494 elastics 20 0 23.4g 16g 116m S 0.8 56.7 2:49.61 java
20148 newrelic 20 0 244m 5824 2872 S 0.5 0.0 9:34.29 nrsysmond
42 root 20 0 0 0 0 S 0.3 0.0 0:41.16 events/7
4 root 20 0 0 0 0 S 0.1 0.0 0:54.41 ksoftirqd/0
38 root 20 0 0 0 0 S 0.1 0.0 0:22.52 events/3
39 root 20 0 0 0 0 S 0.1 0.0 0:20.27 events/4
2876 root 20 0 15152 1312 928 R 0.1 0.0 0:00.10 top
7022 elastics 20 0 424m 16m 380 S 0.1 0.1 1:10.45 freeBSD
1 root 20 0 19340 1312 952 S 0.0 0.0 0:02.38 init
2 root 20 0 0 0 0 S 0.0 0.0 0:00.12 kthreadd
3 root RT 0 0 0 0 S 0.0 0.0 0:01.44 migration/0
5 root RT 0 0 0 0 S 0.0 0.0 0:00.00 stopper/0
ID 11995와 7022의 프로세스가 의심스러워서 좀 더 자세히 살펴보기로 했습니다.
이 프로세스에서 lsof를 실행하면 이미 중국이나 홍콩과 연결되어 있음이 나타납니다.
아래에서 샘플 스니펫을 찾으세요.
[root@elastic-prd-node-01 fail2ban]# lsof -p 11995
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
gg 11995 elasticsearch cwd DIR 8,1 4096 2 /
gg 11995 elasticsearch rtd DIR 8,1 4096 2 /
gg 11995 elasticsearch txt REG 8,1 1415201 16117 /tmp/gg (deleted)
gg 11995 elasticsearch mem REG 8,1 99154480 4784 /usr/lib/locale/locale-archive
gg 11995 elasticsearch 0u CHR 1,3 0t0 3881 /dev/null
gg 11995 elasticsearch 1u CHR 1,3 0t0 3881 /dev/null
gg 11995 elasticsearch 2u CHR 1,3 0t0 3881 /dev/null
gg 11995 elasticsearch 3u IPv4 10615541 0t0 TCP myservername.c.myproject.internal:54431->103.206.22.224:28099 (ESTABLISHED)
gg 11995 elasticsearch 4u IPv4 10656374 0t0 UDP *:49882
gg 11995 elasticsearch 5u IPv4 10656375 0t0 UDP *:41943
gg 11995 elasticsearch 6u IPv4 10656376 0t0 UDP *:49792
gg 11995 elasticsearch 7u IPv4 10656377 0t0 UDP *:32849
gg 11995 elasticsearch 8u IPv4 10656378 0t0 UDP *:35841
gg 11995 elasticsearch 9u IPv4 10656379 0t0 UDP *:52037
gg 11995 elasticsearch 10u IPv4 10656380 0t0 UDP *:45405
gg 11995 elasticsearch 11u IPv4 10656381 0t0 UDP *:55345
gg 11995 elasticsearch 12u IPv4 10656382 0t0 UDP *:49990
gg 11995 elasticsearch 13u IPv4 10656383 0t0 UDP *:34888
gg 11995 elasticsearch 14u IPv4 10656384 0t0 UDP *:46642
gg 11995 elasticsearch 15u IPv4 10656385 0t0 UDP *:38881
gg 11995 elasticsearch 16u IPv4 10656386 0t0 UDP *:38455
gg 11995 elasticsearch 17u IPv4 10656387 0t0 UDP *:47360
gg 11995 elasticsearch 18u IPv4 10656388 0t0 UDP *:40310
gg 11995 elasticsearch 19u IPv4 10656389 0t0 UDP *:44127
gg 11995 elasticsearch 20u IPv4 10656390 0t0 UDP *:46064
gg 11995 elasticsearch 21u IPv4 10656391 0t0 UDP *:55830
gg 11995 elasticsearch 22u IPv4 10656392 0t0 UDP *:43110
gg 11995 elasticsearch 23u IPv4 10656393 0t0 UDP *:58793
나는 또한 다음을 실행했습니다.
[root@elastic-prd-node-01 tmp]# ls -al /proc/11995/exe
lrwxrwxrwx. 1 elasticsearch elasticsearch 0 May 8 12:48 /proc/17525/exe -> /tmp/gg
/tmp해당 디렉토리에서 gg, freeBSD 또는 syn2016이라는 이름의 의심스러운 파일을 발견했습니다 .
그런 다음 전체 /tmp 디렉토리를 타르 처리하고 의심스러운 프로세스를 모두 종료하고 /tmp에서 의심스러운 파일을 모두 삭제하고 서버를 종료했습니다.
다음에 무엇을 해야 합니까? 이게 정상으로 보이나요? 공격처럼 보이나요? 앞으로 이런 일이 다시 발생하지 않도록 하려면 어떻게 해야 합니까? 진실을 알아내기 위해 어떤 조치를 취할 수 있나요?
p.s. 저는 elasticsearch 1.6.2를 실행하고 CentOS 6있으며 elasticdump를 사용하여 인덱스를 마이그레이션하고 있습니다.
답변1
이것은 확실히 공격이다. 누군가 관리했다
a) drop a file onto your server (possibly via poorly configured apache)
b) execute that file
당신이 해야 할 일:
a) mount the /tmp partition with the noexec - option
b) reboot the server
c) run a malware scan on the complete host while offline
d) if that does not help : REINSTALL from scratch
그것을 깊이 이해하려면 다음을 수행하십시오.
a) check the gg file's creation date
b) look into the httpd-logs at that time.
따라서 어떤 스크립트가 파일을 삭제했는지 확인할 수 있습니다. 또 다른 가능성은 비밀번호가 잘못된 권한 있는 FTP 계정입니다. 이 로그도 검색해 보세요...
답변2
그런데 Elasticsearch는 인터넷에 공개되어 있으면 안전하지 않습니다. 당신의 것이 맞는지 확실하지 않지만 지적해야한다고 생각했습니다.
"항상 방화벽을 사용하는 것이 중요합니다. Elasticsearch http 모듈은 인증을 제공하지도 않고 인증 메커니즘도 제공하지 않기 때문에 신뢰할 수 없는 네트워크에 노출되도록 설계되지 않았습니다. 기본적으로 Elasticsearch는 두 개의 포트(9200/ tcp(안정적인 API) 및 9300/tcp(Java 노드/전송 클라이언트와 클러스터의 노드 간 통신용)" (https://groups.google.com/forum/#!topic/ica-atom-users/zkZqqTULvn4)