저는 Debian 기반 VPS (Linux vps 2.6.32-042stab092.3 # 1 SMP Sun Jul 20 13:27:24 MSK 2014 x86_64 GNU / Linux)를 실행 중입니다. 새 연결이 설정 될 때마다 PTR 조회를 수행합니다.
원격 컴퓨터의 Python 스크립트가 VPS의 페이지를 지속적으로 가져 오는 포트 80에서 몇 가지 성능 테스트를 실행하고 있습니다. 모든 페이지 요청에 대해 새로운 PTR 조회가 이루어지며 수천 개의 활성 DNS 요청으로 끝납니다.
나는 이것을 tcpdump -n port not 22 and host not MY_REMOTE_IP. 따라서 -n조회를 방지하는 것입니다.
나는 또한으로 모니터링하고 ntop있는데 -n도 사용됩니다.
멈춰서 ntop보면 tcpdump룩업이 나온다. 중지 tcpdump하고 시작 ntop하면 나도 가져옵니다. 따라서 그들 중 어느 것도 조회를 일으키지 않는다고 가정하는 것이 공정 할 수 있습니다.
또한 xinetd분명히 PTR 조회를 사용하는 백그라운드에서 실행 중입니다. 그러나 해당 서비스를 중지해도 조회는 계속 발생합니다.
그리고 /usr/sbin/rsyslogd -c5살해 당해도 상황을 바꾸지 않는.
동일은 간다 rabbitmq-server와 erlangs epmd. authbind또한 책임이없는 것처럼 보이며 일반적으로 서버로 실행되는을 screen중지 openvpn해도 아무런 차이가 없습니다.
지구상의 Wuaht가 이것을 일으킬 수 있습니까?
다음은 프로세스 트리입니다.
init
`- SCREEN -AmdS py-http authbind python server.py ---scr:py-http
| `- python server.py ---scr:py-http
`- /sbin/getty 38400 tty2
`- /sbin/getty 38400 console
`- /bin/sh /usr/sbin/rabbitmq-server
| `- /usr/lib/erlang/erts-5.9.1/bin/beam.smp -W w -K true -A30 -P 1048576 -- -root /usr/lib/erlang -progname erl -- -home /var/lib/rabbitmq -- -pa /us
t start_sasl -config /etc/rabbitmq/rabbitmq -kernel inet_default_connect_o
| `- inet_gethost 4
| | `- inet_gethost 4
`- /usr/lib/erlang/erts-5.9.1/bin/epmd -daemon
`- /usr/sbin/ntop -d -L -u ntop -P /var/lib/ntop --access-log-file /var/log/ntop/access.log -i venet0:0 -p /etc/ntop/protocol.list -O /var/log/ntop
`- /usr/bin/mongod --config /etc/mongod.conf
`- /usr/sbin/cron
`- /usr/sbin/xinetd -pidfile /var/run/xinetd.pid -stayalive -inetd_compat -inetd_ipv6
`- /usr/sbin/sshd
| `- sshd: user [priv]
| `- sshd: user@pts/0
| `- -bash
| `- htop
`- sendmail: MTA: accepting connections
`- /usr/sbin/openvpn --writepid /var/run/openvpn.server.pid --daemon ovpn-server --cd /etc/openvpn --config /etc/openvpn/server.conf
`- /usr/sbin/saslauthd -a pam -c -m /var/run/saslauthd -n 2
| `- /usr/sbin/saslauthd -a pam -c -m /var/run/saslauthd -n 2
`- /usr/sbin/rsyslogd -c5
`- upstart-socket-bridge --daemon
`- /sbin/udevd --daemon
| `- /sbin/udevd --daemon
| `- /sbin/udevd --daemon
`- upstart-udev-bridge --daemon
최신 정보
이 조회는 모든 새로운 연결에서 발생합니다. 포트 80이나 22, 어떤 포트 든 상관 없습니다.
하나의 HTTP 요청에 대한 Strace의 결과
sendto(10, "C~\1\0\0\1\0\0\0\0\0\0\0016\00270\003168\003192\7in-add"..., 43, MSG_NOSIGNAL, NULL, 0) = 43
print statement in server.py -> request #5 from client 192.168.70.6
sendto(10, "\23\372\1\0\0\1\0\0\0\0\0\0\0016\00270\003168\003192\7in-add"..., 43, MSG_NOSIGNAL, NULL, 0) = 43
sendto(9, "HTTP/1.1 200 OK\r\nDate: Fri, 24 O"..., 146, 0, NULL, 0) = 146
VPS에 설치할 수 없으므로 Sysdig를 사용할 수 없습니다.
iptables 로깅 결과 다음 항목이 생성됩니다. 새 ssh 연결의 경우 :
Oct 24 06:06:11 vps kernel: [6547020.638594] DNS Traffic match:IN= OUT=venet0 SRC=VPS_IP_ADDRESS DST=8.8.8.8 LEN=99 TOS=0x00 PREC=0x00 TTL=64 ID=56490 DF PROTO=UDP SPT=50366 DPT=53 LEN=79 UID=0 GID=0
새 http 연결의 경우 :
Oct 24 06:06:53 vps kernel: [6547062.417763] DNS Traffic match:IN= OUT=venet0 SRC=VPS_IP_ADDRESS DST=8.8.8.8 LEN=71 TOS=0x00 PREC=0x00 TTL=64 ID=32702 DF PROTO=UDP SPT=59091 DPT=53 LEN=51 UID=1000 GID=1000
ss 결과
ESTAB 0 0 VPS_IP_ADDRESS:42414 8888:53 users:(("python",2375,10))
먼저, 공유 한 프로세스 트리에서 ntop을 호출하면 -n플래그 가없는 것 같습니다 .
/usr/sbin/ntop -d -L -u ntop -P /var/lib/ntop --access-log-file /var/log/ntop/access.log -i venet0:0 -p /etc/ntop/protocol.list -O /var/log/ntop
그러나 나는 ntop이 죽어도 계속되는 쿼리에 대한 귀하의 진술을 고려할 때 문제가 아니라고 가정합니다. 또한 명확히하기 위해 조회를 수행하는 머신이 포트 80에서 요청을 처리하는 동일한 머신이라고 가정합니다.
다음은 몇 가지 디버깅 아이디어입니다.
문제의 프로그램이 한동안 소켓을 유지하는 경우 ss, -p플래그 와 함께 (또는 netstat)를 사용 하여 tcpdump에서 볼 소스 포트의 소유자를 찾을 수 있습니다.
첫 번째 용의자는 요청을 처리하는 애플리케이션이어야합니다. 화면에서 실행되는 다음 파이썬 프로세스가 테스트중인 응용 프로그램이라고 가정하고 있습니다.
`- SCREEN -AmdS py-http authbind python server.py ---scr:py-http
| `- python server.py ---scr:py-http
이 프로세스를 strace에서 실행하고 DNS 트래픽을 생성하는지 확인할 수 있습니다. 예를 들면 다음과 같습니다.
strace -e trace=sendmsg,sendto -f YOUR_PROGRAM_HERE
그런 다음 포트 53으로 전송 된 것처럼 보이는 메시지의 출력을주의 깊게 살펴 봅니다.
[pid 3367] sendmsg(20, {msg_name(16)={sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("192.168.1.254")}, msg_iov(1)=[{"\31\322\1\0\0\1\0\0\0\0\0\0\0014\0014\0018\0018\7in-addr\4arp"..., 38}], msg_controllen=0, msg_flags=0}, 0) = 38
문제의 프로그램이 소켓을 빠르게 닫는다면 ss 또는 netstat에서 정보를 얻기 어려울 수 있습니다.
그러나 한 가지 가능성은 ss명령을 반복적으로 폴링하는 스크립트를 작성하는 것입니다 . 당신은 조회 중 하나를 잡을만큼 운이 좋다고 베팅 할 것입니다.
while true; do ss -p -n -u | tail -n +2; done
ss 명령에 필터를 추가하여 해당 시스템에 다른 UDP 트래픽이 많이 표시되는 경우 범위를 좁힐 수 있습니다. 이것이 작동하는지 여부는 당신이 운이 좋다는 것에 달려 있습니다.
비교적 새로운 sysdig유틸리티를 사용하여 모든 sendmsg 또는 sendto 시스템 호출을 볼 수 있습니다.
sudo sysdig evt.type=sendmsg or evt.type=sendto | grep ':53'
출력에는 프로세스 이름 (이 경우 nslookup)이 있습니다.
47852 01:15:33.454946732 4 nslookup (3349) > sendmsg fd=20(<4>) size=38 tuple=0.0.0.0:49847->192.168.1.254:53
iptables를 사용하면 패킷을 생성 한 프로세스의 사용자 ID를 기록 할 수 있습니다. 대부분의 서비스가 동일한 사용자로 실행되는 경우 이는별로 도움이되지 않지만 서비스 별 사용자가있는 경우에는 그럴 수 있습니다. 다음과 같은 일련의 iptable 규칙 :
iptables -N LOGGING
iptables -A OUTPUT -p udp --dport 53 -j LOGGING
iptables -A LOGGING -j LOG --log-prefix="DNS Traffic match:" --log-uid
관련된 UID와 함께 모든 아웃 바운드 DNS 트래픽을 기록합니다. 로깅 설정에 따라 kmesg를 통해 또는 syslog 메시지가 이동하는 모든 위치에서 찾을 수 있으며 출력은 다음과 같습니다.
Oct 24 01:09:53 localhost.localdomain kernel: DNS Traffic match:IN= OUT=enp0s3 SRC=10.0.2.15 DST=192.168.1.254 LEN=66 TOS=0x00 PREC=0x00 TTL=64 ID=35264 PROTO=UDP SPT=51767 DPT=53 LEN=46 UID=1000 GID=1000
이 출력에서 문제의 프로세스의 UID가 1000이라는 것을 알 수 있으며, 이는 적어도 검색 범위를 좁 힙니다.
이 기사는 인터넷에서 수집됩니다. 재 인쇄 할 때 출처를 알려주십시오.
침해가 발생한 경우 연락 주시기 바랍니다[email protected] 삭제
몇 마디 만하겠습니다