web-dev-qa-db-ja.com

iptablesを使用したスパイクnetstatの「失敗した接続試行」のデバッグ

http://farm4.static.flickr.com/3305/4588110530_a60c934289_o.png

このグラフはムニン収集netstat -s出力。

接続がどこから来ているのかを確認したいと思います。 Wiresharkのダンプには明らかなものは何もありません。

Iptablesで何か凝ったことをしてから、しばらく経ちました。これらをログに記録するにはどうすればよいですか？

ありがとう

-s

iptablesnetstatwiresharkmunin
1
someara

接続がどこから来ているかを判断するには.... SSHトラフィックをログに記録する例を次に示します。カーネルログでの形式は次のようになります

MONTH DAY TIME SERVERNAME kernel: [IPTABLES] : IN=eth0 OUT= MAC=00:00:00:00:00:00:00:00:00:00:00:00:00:00 SRC=REMOTEIP DST=SERVERIP LEN=00 TOS=0x00 PREC=0x00 TTL=# ID=# DF PROTO=TCP SPT=# DPT=22 WINDOW=# RES=0x00 SYN URGP=0 OPT (#)

ここでは、MyLOGという新しいチェーンを作成します

# iptables -N MyLOG

万が一に備えて新しいチェーンを洗い流してください

# iptables -F MyLOG

tcpポート22でログ機能を作成し、ログをアラートに設定し、見やすい「[IPTABLES]」文字列をログ行の先頭に設定します。

# iptables -A MyLOG -i eth0 -p tcp --dport 22 -j LOG --log-level alert --log-tcp-options --log-ip-options --log-prefix '[IPTABLES] : '

myLOGチェーンを入力チェーンに接続します

# iptables -A INPUT -i eth0 -j MyLOG

これにより、ログがカーネルログに送信されます（ただし、Linuxの一部のフレーバーでは結果が異なる場合があります）。カーネルログを調整することで、ログをテストできます。

# tail -f /var/log/kern.log

コンソールを使用していて、画面全体に大量のデータが飛び散っているのに気付いた場合は、コンソールログ出力を次のように設定してみてください。

dmesg -n 1

「統計」を取得したい場合は、実行できます

# iptables -nvxL

出力には、チェーンが作成された時点から送信されたパケットとバイトの量が表示されます。

Chain MyLOG (1 references)
    pkts      bytes target     prot opt in     out     source               destination
      61     4416 LOG        tcp  --  eth0   *       0.0.0.0/0            0.0.0.0/0

ここにスクリプトがあります http://www.hilands.com/code-Shell-fw.html これは、特定のポートアクティビティをログに記録し、serverstats serverstats（berliosからダウンロード可能）のデータを収集するために使用しました。 NATの設定、ポート転送、ポートスキャンの中断を試み、ドロップの代わりにtcp-rejectsを使用します。

Serverstatsは理解するのが難しい場合があります。 RRDToolを使用するPHPスクリプトのセット。シェルスクリプトを使用してiptables出力をトリガーします。文字化けしたメモでは、構成配列を次のように変更する必要があると言われています。実行

'ssh-traffic' => array(
        'used' => true,
        'chains' => array('MyLOG'),
        'graphs' => array(
            'combined_bps' => array('used' => true, 'title' => 'Combined (bps)'),
            'single_bps' => array('used' => true, 'title' => '%s (bps)'),
            'combined_count' => array('used' => true, 'title' => 'Combined (count)'),
            'single_count' => array('used' => true, 'title' => '%s (count)')
        )
    ),
1
The-Phil

返信してくれてありがとう。

ここでの私の目標は、グラフのスパイクが規則的で周期的である理由を理解し、それらを停止させることです。これらはゆっくりと（一度に5つほど）入ってくる。 tcp接続が何らかの理由で失敗することは理解していますが、その規則性のために明らかに何かが進行中です。どこかでcronジョブ、ロードバランサーの設定ミス、または監視デバイスが原因であると思われます。

私はUTSLアプローチを採用することにしました。これが、これまでのところです。

netstat -sは、/ proc/net/snmpから統計を取得します。

すごい。したがって、カーネルは、接続の試行が失敗するたびにSNMPカウンターを更新します。

Idが達成したいのは、接続に失敗するたびに、このカウンターを更新するだけでなく、「$ timestampのIP $ fooからの接続試行の失敗」もログに記録することです。

では...接続試行の失敗と見なされるものは何ですか？

カーネルソースをダウンロード把握私が探しているカウンターはTCP_MIB_ATTEMPTFAILSであると結論付けます

2.6.18ソースツリーをgrepすると、これが参照されている場所が2つ見つかりました。

./net/ipv4/tcp_minisocks.c：

453 struct sock *tcp_check_req(struct sock *sk,struct sk_buff *skb,
454                            struct request_sock *req,
455                            struct request_sock **prev)
456 {

592                 if (flg & (TCP_FLAG_RST|TCP_FLAG_SYN)) {
593                         TCP_INC_STATS_BH(TCP_MIB_ATTEMPTFAILS);
594                         goto embryonic_reset;
595                 }

640 }

...そして、include/net/tcp.h

915 static inline void tcp_done(struct sock *sk)
916 {
917         if(sk->sk_state == TCP_SYN_SENT || sk->sk_state == TCP_SYN_RECV)
918                 TCP_INC_STATS_BH(TCP_MIB_ATTEMPTFAILS);
919 
920         tcp_set_state(sk, TCP_CLOSE);
921         tcp_clear_xmit_timers(sk);
922 
923         sk->sk_shutdown = SHUTDOWN_MASK;
924 
925         if (!sock_flag(sk, SOCK_DEAD))
926                 sk->sk_state_change(sk);
927         else
928                 inet_csk_destroy_sock(sk);
929 }

カウンターの更新を生成する条件がこれらの2つだけであることに少し驚いていますが、それは何でもです。

最初のブロックはかなり明白なようです。 「RSTフラグとSYNフラグの両方が設定されたTCPパケットが表示された場合は、TCP_MIB_ATTEMPTFAILSカウンターを更新し、接続をリセットしてください」。

これらをキャッチするために、次のiptablesルールを設定しました

iptables -A INPUT -p tcp -m tcp --tcp-flags SYN,RST SYN,RST -j LOG
iptables -A OUTPUT -p tcp -m tcp --tcp-flags SYN,RST SYN,RST -j LOG

待機…..何もありません。 =（

2番目のブロックはもう少し不思議ですが、これは「ソケットを破棄するときにソケットが特定の状態にある場合は、TCP_MIB_ATTEMPTFAILSカウンターを更新する」ことを意味すると推測して想定します。

これ、これをテストする方法がわかりません。

私の質問は今です：1）私はこのグラフをどういうわけか誤解していますか？ 2）私は正しい方向に進んでいますか？ 3）カーネルモジュールを作成する以外に（私はそれを行うのに十分なスキルがありません）、どうすればロギングの目標を達成できますか？

ありがとう

-s

1
someara

Iptablesが必要なものかどうかはわかりません。アクティブなままで、netstatが使用するのと同じシステムコールをポーリングするツールがあるかもしれません。あるいは、それを書くこともできます。

iptablesはパケットに反応して、パケットを処理します。あなたが見ているのは、基本的にすべてのアクティブなソケットの割り当てテーブルです。

さて、これらが実際に何であるかに応じて、これらの接続でパケットをキャッチできる可能性があります。

あまり印象的ではない状態のソケットがたくさんあり、長い間、ますます多くの数に増え続けている場合は、netstat -anp、iircの出力にもっと関心があります。プログラム。多分誰かがソケットを漏らしています。

それは私を非常に推測しています。そのグラフの変化を見たいものについて詳しく説明するのはどうですか。

私は自分自身についてコメントしましたが、表示されなかったので、編集します-他の投稿は、iptablesを使用して、wiresharkで表示できるはずのトラフィックをログに記録する方法を完全に明確に説明しています。パケットではなく、ソケットについて質問しているように聞こえます。追跡が難しいソケットは、通常、パケットを送受信していません。これは、リソースの浪費を示している場合があります。

0
Justin Alan Ryan