☰

봄 여름 시즌

tag-icon • tag-icon networking dns
봄 여름 시즌

저는 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-servererlangs 도 마찬가지입니다 epmd. authbind책임도 없는 것 같고, 서버로서의 screen정상적인 실행을 멈춰도 아무런 차이가 없습니다.openvpn

이 상황의 원인은 정확히 무엇입니까?

이것이 프로세스 트리입니다.

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 요청의 경우

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에 설치할 수 없기 때문에 사용할 수 없습니다.

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

봄 여름 시즌밝혀지다

ESTAB      0      0            VPS_IP_ADDRESS:42414         8888:53     users:(("python",2375,10))

답변1

먼저, 공유 프로세스 트리에서 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(또는 netstat) 및 이 -p플래그를 사용하여 tcpdump에서 볼 수 있는 소스 포트의 소유자를 찾을 수 있습니다.

스트레스

첫 번째 용의자는 요청을 처리하는 애플리케이션이어야 합니다. 화면 아래에서 실행되는 다음 Python 프로세스가 테스트 중인 애플리케이션이라고 가정합니까?

 `- 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 루프

문제의 프로그램이 소켓을 빠르게 닫는 경우 ss 또는 netstat에서 해당 프로그램에 대한 정보를 얻는 것이 어려울 수 있습니다.

그러나 한 가지 가능성은 ss폴링 명령을 반복하는 스크립트를 작성하는 것입니다. 다음 조회 중 하나를 잡을 만큼 운이 좋다고 확신할 수 있습니다.

while true; do ss -p -n -u | tail -n +2; done

해당 컴퓨터에서 다른 UDP 트래픽이 많이 발견되면 ss 명령에 필터를 추가하여 범위를 좁힐 수 있습니다. 이것이 작동할지 여부는 운에 달려 있습니다.

시스템 마이닝

비교적 새로운 것을 사용할 수 있습니다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

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임을 알 수 있습니다. 이는 최소한 검색 범위를 좁힙니다.

관련 정보