LAMP Ubuntu 10.04 서버가 있습니다. 많은(140명 이상) 사용자와 다양한 PHP 웹사이트(맞춤형, 다양한 PHP 프레임워크, CMS 등)가 있습니다.
문제는 때때로 서버가 "스팸"을 보내는 것입니다. 현지 수출입 은행은 이러한 목적으로 사용되지 않습니다. 다음과 같은 이상한 활동을 발견했습니다.
/usr/bin/lsof -ni | grep smtp |grep -v ^exim4
perl 15177 www-data 510u IPv4 1101127040 0t0 TCP server_ip:46401->65.55.37.72:smtp (SYN_SENT)
perl 15178 www-data 510u IPv4 1101127059 0t0 TCP server_ip:51002->98.136.217.202:smtp (SYN_SENT)
perl 15179 www-data 510u IPv4 1101126982 0t0 TCP server_ip:39232->74.125.205.26:smtp (SYN_SENT)
perl 15180 www-data 510u IPv4 1101126975 0t0 TCP server_ip:53339->65.55.37.72:smtp (SYN_SENT)
perl 15181 www-data 510u IPv4 1101127014 0t0 TCP server_ip:45429->65.55.37.72:smtp (SYN_SENT)
perl 15182 www-data 510u IPv4 1101126984 0t0 TCP server_ip:49985->74.125.205.26:smtp (SYN_SENT)
perl 15183 www-data 510u IPv4 1101126971 0t0 TCP server_ip:42199->65.55.37.72:smtp (SYN_SENT)
..........
...........
perl 15184 www-data 510u IPv4 1101126968 0t0 TCP server_ip:36641->74.125.205.26:smtp (SYN_SENT)
perl 15186 www-data 510u IPv4 1101126979 0t0 TCP server_ip:57690->98.138.112.32:smtp (SYN_SENT)
...........
이러한 Perl 프로세스를 누가 실행하는지, 어떻게 실행하는지 알 수 없습니다. 나는 이러한 프로세스(예: pid 15179)를 분석하려고 합니다: /proc/15179/cmdline - 비어 있습니다.
/proc/15179/status
Name: perl
State: S (sleeping)
Tgid: 15179
Pid: 15179
PPid: 15176
TracerPid: 0
Uid: 33 33 33 33
Gid: 33 33 33 33
FDSize: 1024
Groups: 33
VmPeak: 10400 kB
VmSize: 10372 kB
VmLck: 0 kB
VmHWM: 8140 kB
VmRSS: 8092 kB
VmData: 6980 kB
VmStk: 88 kB
VmExe: 1200 kB
VmLib: 1980 kB
VmPTE: 32 kB
Threads: 1
SigQ: 0/16382
SigPnd: 0000000000000000
ShdPnd: 0000000000000000
SigBlk: 0000000000000000
SigIgn: 0000000000000080
SigCgt: 0000000180017427
CapInh: 0000000000000000
CapPrm: 0000000000000000
CapEff: 0000000000000000
CapBnd: ffffffffffffffff
Cpus_allowed: f
Cpus_allowed_list: 0-3
Mems_allowed: 1
Mems_allowed_list: 0
voluntary_ctxt_switches: 6431
nonvoluntary_ctxt_switches: 34
lsof -n -p 15179 - 여기 여기에 링크 설명을 입력하세요
상위 프로세스 pid가 15176인 상위 프로세스 15179를 찾으려고 합니다.
/proc/15176/cmdline - 비어 있음
그리고
/proc/15176/status
Name: perl
State: S (sleeping)
Tgid: 15176
Pid: 15176
PPid: 1
TracerPid: 0
Uid: 33 33 33 33
Gid: 33 33 33 33
FDSize: 1024
Groups: 33
VmPeak: 11116 kB
VmSize: 11116 kB
VmLck: 0 kB
VmHWM: 8712 kB
VmRSS: 8692 kB
VmData: 7772 kB
VmStk: 88 kB
VmExe: 1200 kB
VmLib: 1940 kB
VmPTE: 32 kB
Threads: 1
SigQ: 0/16382
SigPnd: 0000000000000000
ShdPnd: 0000000000000000
SigBlk: 0000000000000000
SigIgn: 0000000000010080
SigCgt: 0000000180007427
CapInh: 0000000000000000
CapPrm: 0000000000000000
CapEff: 0000000000000000
CapBnd: ffffffffffffffff
Cpus_allowed: f
Cpus_allowed_list: 0-3
Mems_allowed: 1
Mems_allowed_list: 0
voluntary_ctxt_switches: 14467
이는 거의 발생하지 않으며(이틀에 한 번) 몇 분 동안 지속됩니다. 그래서 더 많은 정보를 얻기가 어렵습니다. 이 모든 정보는 smtp 연결을 모니터링하는 cron 작업을 사용하여 기록됩니다. 누가 이러한 프로세스를 실행하고 있는지, 어떻게 실행되고 있는지 식별하는 방법을 모르겠습니다. 그들을 찾는 전략이 있나요?
답변1
표시되는 데이터에는 이미 많은 정보가 포함되어 있습니다. 사용자의 UID는 33이며 내 시스템에서는www-데이터, 귀하가 표시한 소켓이 다음에 속하기 때문에 이것이 귀하의 시스템에도 적용될 가능성이 가장 높다고 생각합니다.www-데이터.
또한 명령줄이 더 많은 정보를 제공할 것이라고 생각합니다. Perl 프로그램의 PPID는 15176이지만 PPID 15176은 1(즉,내부에). 그 사이에는 쉘이나 세션이 없습니다.
연락된 IP 주소는 특별히 걱정할 사항이 아닙니다. 해당 IP 주소는 Microsoft 및 Google에 속하며 이러한 사람들은 자신을 보호하는 방법을 알고 있습니다.
그렇다면 반칙의 증거는 어디에 있습니까? 나는 연결의 SYN_SENT 상태가 실제로 걱정할 사항이라는 점에 동의합니다. 이는 연결이 올바른 SYN/ACK를 수신하지 않았고 정지 상태에 있음을 의미하기 때문입니다.
그렇다면 더 많은 정보를 알아내기 위해 무엇을 할 수 있을까요? 사용자를 직접 식별하려고 시도할 수 없습니다. 귀하의 게시물에는 이미 사용자가 있음을 나타냅니다.www-데이터, 프로세스는 터미널이나 세션에 직접 연결되지 않습니다.
하지만 먼저 귀하의 IP가 블랙리스트에 있는지 확인할 수 있습니다.여기: 그렇다면 스팸의 증거입니다.
둘째, 메일 프로그램의 로그에서 특이한 사항이 있는지 확인해야 합니다. 블랙리스트에 등록되어 있기 때문에 사이트에서 연결을 거부하는 경우, 동일한 사이트에서 여러 번 연결하는 경우, 릴레이로 사용되는 증거 등…
셋째, 다음을 사용하여 포트를 모니터링할 수 있습니다.
ss -lntp
이는 특정 순간에 (TCP) 포트를 사용하는 프로세스의 pid를 알려주고 다중 연결을 다시 확인합니다. 매초마다 반복하고 출력을 저장하도록 위의 명령을 작성할 수 있습니다(아마도 다음과 같이).사용자) 및 타임스탬프를 사용하여 의심스러운 연결이 발생했을 때 무슨 일이 일어났는지 자세히 알아볼 수 있습니다. 이는 상관관계가 있을 수 있습니다.검시사용자가 로그인했거나 사이트에 연결되어 있습니다.
자세한 내용을 보려면 자주 발생하는 Microsoft 사이트에 모든 패킷을 덤프하면 됩니다.
nohup tcpdump -n -i eth0 host 65.52.0.0/14 -w outfile &
출력에 따르면 IP 주소 범위는 Microsoft에 속한 전체 블록입니다.세계보건기구 65.55.37.72;위 명령은 꽤 많은 출력을 생성할 수 있으므로 표현식 필터링 기술을 연마할 준비를 하십시오.라인샤크.
다른 모든 방법이 실패하면 사용자가 비밀번호를 변경하도록 강제할 준비를 하세요.
답변2
그냥 생각입니다. Grep은 아파치 로그를 탐색합니다. 시간이 있으면 이메일이 전송된 후 쉽게 찾을 수 있습니다. 특히 Perl 스크립트를 찾고 있습니다.
답변3
사용자 가져오기
대개UID필드 디스플레이UID프로세스를 시작한 사용자입니다.
귀하의 경우 이것은 다음과 같습니다.UID 33
.
getent passwd 33
사용자의 이름을 보는 데 사용됩니다 .
사용자 추적
작은 C 데몬을 사용하여 사용자 활동을 쉽게 모니터링하고 기록할 수 있습니다.
사용이것/proc/pid/status
파일을 읽고 사용자를 검색하기 위한 작은 라이브러리입니다.
이는 서버가 실행되는 동안 문제를 방지하는 데 도움이 될 수 있습니다.
kill
(데몬이 이러한 프로세스를 처리하도록 할 수도 있습니다 )