私は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からそのプログラムに関する情報を取得するのが難しい場合があります。
しかし、1つの可能性は、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であることがわかります。これは少なくとも検索範囲を絞り込む。