LAMP Ubuntu 10.04 서버가 있습니다. 많은(>140) 사용자와 다양한 웹 PHP 사이트(사용자 정의, 다양한 PHP 프레임워크, CMS 등)가 있습니다.
문제는 때때로 서버가 "스팸"을 보내는 것입니다. 그리고 로컬 Exim은 이에 사용되지 않습니다. 다음과 같은 이상한 활동을 발견했습니다.
/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 - 여기 여기에 링크 설명을 입력하세요
상위 프로세스를 찾으려고 했습니다. 15179의 상위 pid는 15176입니다.
/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
이는 거의 발생하지 않으며(2일에 한 번) 몇 분 동안 지속됩니다. 그래서 더 많은 정보를 얻기가 어렵습니다. 이 모든 정보는 smtp 연결을 모니터링하는 cron 작업을 사용하여 기록됩니다. 이러한 프로세스를 누가 실행하는지, 어떻게 실행하는지 식별하는 방법을 모릅니다. 그들을 찾는 전술이 있나요?
답변1
표시한 데이터에는 이미 많은 정보가 포함되어 있습니다. 사용자의 UID는 33이며 내 시스템에서는www-데이터, 귀하가 표시한 소켓이 다음에 속하기 때문에 귀하의 시스템에도 동일하게 적용될 가능성이 가장 높다고 생각합니다.www-데이터.
또한 명령줄이 더 많은 정보를 제공할지는 의문입니다. Perl 프로그램의 PPID는 15176이지만 15176의 PPID는 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
그냥 아이디어입니다. 아파치 로그를 살펴보세요. 시간이 있다면 메일이 발송되었을 때 메일을 쉽게 찾을 수 있습니다. 특히 Perl 스크립트를 찾아보세요.
답변3
사용자 확보
일반적으로UID필드는UID프로세스를 시작한 사용자.
귀하의 경우 이것은 다음과 같은 iser가 될 것입니다.UID 33.
getent passwd 33사용자의 이름을 보려면 사용합니다 .
사용자 추적
작은 C 데몬을 사용하여 사용자의 활동을 쉽게 관찰하고 기록할 수 있습니다.
사용하여이것/proc/pid/status파일을 읽고 사용자를 검색 하는 작은 라이브러리입니다 .
이렇게 하면 서버 런타임 문제를 방지하는 데 도움이 될 수 있습니다.
kill(데몬이 이러한 프로세스를 수행하도록 할 수도 있습니다 )