タグ付けされた質問 「tcpdump」

私tcpdumpはCtrl+ Cで中断し、この総括を得ました： 579204 packets captured 579346 packets received by filter 142 packets dropped by kernel 「カーネルによってドロップされたパケット」とは何ですか？なぜそれが起こるのですか？

50 kernel  tcpdump 

（OpenWrt 10.04ルーター上の）クライアントによるDNS要求をtcpdumpしたい場合、 root@ROUTER:/etc# tcpdump -n -i br-lan dst port 53 2>&1 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on br-lan, link-type EN10MB (Ethernet), capture size 96 bytes 22:29:38.989412 IP 192.168.1.200.55919 > 192.168.1.1.53: 5697+ A? foo.org. (25) 22:29:39.538981 IP 192.168.1.200.60071 > 192.168.1.1.53: 17481+ PTR? 150.33.87.208.in-addr.arpa. …

27 pipe  tcpdump 

だから、大学のITセキュリティチームと私は、休みなくこれについていろいろなことを繰り返してきました...誰もがこれについて考えています： 私は最近、専用のコンピューター（Intel Avoton C2550プロセッサ-必要に応じてハードウェア情報を提供してもかまいませんが、不要だと思います）でDebian 8.6を実行するラボに小さなファイルサーバーをセットアップしました。Debianは問題なくインストールされ、その時点でSamba、NTP、ZFS、およびpythonもインストールされました。物事はうまく機能しているように見えたので、数週間ラボの隅に座らせて実行させました。 約2週間前、ITチームから、サーバーが「侵害され」、NTP増幅/ DDoS攻撃（httpsで説明されているCVE-2013-5211を使用したNTP増幅攻撃で使用されている）に対して脆弱であるというメールを受け取りました。 //www.us-cert.gov/ncas/alerts/TA14-013A）。彼らが指し示したサインは、ポート123での大量のNTPv2トラフィックでした。奇妙なことに、彼らがこれを特定したIPアドレス（*.*.*.233）は、サーバーが設定され、ifconfig（*.*.*.77）で報告されたIPアドレスとは異なりました。それにもかかわらず、いくつかの基本的なトラブルシューティングは、私のコンピューターが実際にポート123でこのトラフィックを生成していることを明らかにしました（tcpdumpによって明らかにされたように）。 ここが奇妙さの始まりです。最初に、CVE-2013-5211に推奨される「修正」を実行しました（NTPをバージョン4.2.7の過去に更新すると同時に、monlist機能を無効にします）。どちらも交通の流れを妨げませんでした。次に、IPテーブルを介してUDP 123ポートをブロックしようとしました。 $ /sbin/iptables -A INPUT -o eth0 -p udp --destination-port 123 -j DROP $ /sbin/iptables -A OUTPUT -o eth0 -p udp --destination-port 123 -j DROP しかし、それもトラフィックには影響しませんでした。最終的にシステムからNTPを削除しようとしましたが、トラフィックにも影響しませんでした。今日の午後の時点で、nmapはまだ報告していました。 Starting Nmap 5.51 ( http://nmap.org ) at 2016-12-19 16:15 EST Nmap scan report for *.233 …

16 debian  ip  network-interface  tcpdump  ntp 

のmanページをtcpdump見ると、バッファがいっぱいになるとカーネルがパケットをドロップする可能性があります。私は疑問に思っていた： そのサイズは構成可能および/または ディストリビューションのサイズはどこで確認できますか？ manページから（簡単に参照できるように）： パケットが「カーネルによってドロップ」（これは、OSがアプリケーションにその情報を報告する場合、tcpdumpが実行されているOSのパケットキャプチャメカニズムによって、バッファスペースの不足によりドロップされたパケットの数です。そうでない場合は、0として報告されます。

16 kernel  networking  buffer  tcpdump 

すべての発信AレコードをRedHat PCに記録する必要があります。私は使用してみましたtcpdump： tcpdumpdns=OUTPUT-FILENAME-HERE nohup tcpdump -K dst port 53 -w $tcpdumpdns > /dev/null 2>&1 & 次のような出力ファイルを作成します。 19:26:12.185392 IP 172.16.0.6.57977 > google-public-dns-a.google.com.domain: 51198+ A? yahoo.com. (27) だから私はそれを取得するためにそれを処理する必要がありますyahoo.com： echo $tcpdumpdns | awk '/ A\? / {u = NF - 1; print $u}' | sed 's/^www.//g; s/.$//g' | sort -u すべての発信Aレコード要求を収集するためのより良いソリューションはありますか？ ps：DNS Aレコードを収集する必要があるのは、HTTPSを介して到達可能なWebサイトの最新リストを保持する場合のみです。したがって、HTTPSEverywhere …

15 tcpdump 

コマンドのネットワークアクティビティをトレースしたいのですが、成功せずにtcpdumpとstraceを試しました。 たとえば、パッケージをインストールしている場合、または特定のサイトに到達しようとするコマンドを使用している場合、そのネットワークアクティビティ（到達しようとしているサイト）を表示したいです。 tcpdumpを使用してこれを行うことができると思います。試しましたが、システムのすべてのネットワークアクティビティを追跡しています。複数のネットワーク関連コマンドを実行していて、特定のコマンドネットワークアクティビティのみを追跡したい場合、正確な解決策を見つけるのは困難です。 それを行う方法はありますか？ 更新： ネットワークインターフェースで行われるすべてを追跡したくありません。コマンド（#yum install -y vimなど）のネットワークアクティビティを追跡したいだけです。到達しようとするサイトなど。

13 linux  networking  tcpdump  strace  wireshark 

デバッグのために、Linux仮想インターフェイスでトラフィックをキャプチャしたいと思います。veth、tunおよびdummyインターフェイスの種類を試しています。3つすべてで、tcpdump何かを表示するのに苦労しています。 ダミーインターフェイスの設定方法は次のとおりです。 ip link add dummy10 type dummy ip addr add 99.99.99.1 dev dummy10 ip link set dummy10 up 1つの端末で、次のように監視しtcpdumpます。 tcpdump -i dummy10 すぐに、次の方法で試聴しますnc。 nc -l 99.99.99.1 2048 3番目では、次を使用してHTTP要求を作成しますcurl。 curl http://99.99.99.1:2048/ ターミナル2ではcurlリクエストからのデータを見ることができますが、からは何も表示されませんtcpdump。 A TUN / TAPチュートリアル明確化カーネルは実際には1つのローカルインターフェイス上で動作しているすべてのパケットを送信しないことがあり、いくつかの状況： tsharkの出力を見ると、何もありません。インターフェイスを通過するトラフィックはありません。これは正しいです。インターフェイスのIPアドレスにpingを送信しているため、オペレーティングシステムはパケットを「有線」で送信する必要がないと正しく判断し、カーネル自体がこれらのpingに応答しています。考えてみると、別のインターフェイスのIPアドレス（たとえばeth0）にpingを実行した場合に発生することです。パケットは送信されません。これは明白に聞こえるかもしれませんが、最初は混乱の原因になる可能性があります（私にとっては）。 ただし、これがTCPデータパケットにどのように適用されるかを確認するのは困難です。 たぶん、tcpdump別の方法インタフェースにバインドする必要がありますか？

12 networking  kernel  ip  tcp  tcpdump 

ここで障害のあるイーサネットコントローラーを修正するために無駄にしようとしていたので、マシンでtcpdumpを実行してみました。 tcpdumpは、pingアプリケーションが送信していると考えていたICMPパケットの一部が、同じマシン上で実行されていても、実際にはワイヤ上で送信されていなかったことを検出できることは興味深いことに気付きました。これらのtcpdumpの結果をここに再現しました。 14:25:01.162331 IP debian.local > 74.125.224.80: ICMP echo request, id 2334, seq 1, length 64 14:25:02.168630 IP debian.local > 74.125.224.80: ICMP echo request, id 2334, seq 2, length 64 14:25:02.228192 IP 74.125.224.80 > debian.local: ICMP echo reply, id 2334, seq 2, length 64 14:25:07.236359 IP debian.local > 74.125.224.80: ICMP …

12 linux  networking  tcp  ethernet  tcpdump 

呼び出すスクリプトがあります tcpdump -v src host <IP address> and port <port number> >>out.txt 2>>err.txt -w capture.cap スクリプトの他の部分がバックグラウンドでいくつかのトラフィックを開始する間、複数のIP-sで。パケットが戻ってくるかどうかを確認し、パッケージを受け取った場合のみ手動で調べます。tcpdumpのエラー出力は、最初はこれで問題ないように見えましたが、 問題は、主題が示唆しているように、「キャプチャされたパケット」と「フィルターによって受信されたパケット」の違いは何ですか？パケットを記録しなかったキャプチャがありますが、「0パケットがキャプチャされ、2パケットがフィルタによって受信されました」という出力が矛盾しているように聞こえます。最初は「フィルターが受信した0パケット」を探していましたが、パケットが受信されなかった場合は、常にエラー出力に書き込まれるわけではありません。では、これらの数字は何を示しているのでしょうか？ 応答パケットが受信されなかった場合にそれらのケースをフィルタリングしたい場合、何を探すべきかを知る必要があります。

11 ip  tcpdump 

特定のマルチキャストトラフィックをキャプチャするLinuxシェルスクリプトを書きたいのですが。特定のように、1つの特定のマルチキャストグループ/ポートのすべてのトラフィックを含むpcapファイルを作成します。 トラフィックを表示するために使用しているコマンドラインは次のとおりです。 tcpdump -nnXs 0 -i eth1 udp port 22001 and dst 233.54.12.234 これは、そのグループへのマルチキャストサブスクリプションがすでに確立されている限り、正常に機能します。たとえば、これを別のコンソールで実行した場合： mdump 233.54.12.234 22001 10.13.252.51 tcpdumpパケットが表示されます。mdumpが実行されていない場合、tcpdump何も表示されません。 キャプチャを開始する前にこれらのマルチキャスト結合を確立する標準のlinux-y方法はありますか？mdumpこれらの結合を確立するために使用することもできますがmdump、グループ上のすべてのデータを処理するので、それは無駄に見えますが、私はそれを捨てるつもりです。 私の特定の環境のため、インターフェースを無差別モードにすることはお勧めできません。実際には禁止されているかもしれません。

11 linux  shell-script  tcpdump  multicast 

ラップトップでDHCPをデバッグしようとしています（使用dhcpingしdhcdumpていて、DHCPサーバーが送り返すものを確認しています）。以下は私の/etc/dhcp/dhclient.confです。 option rfc3442-classless-static-routes code 121 = array of unsigned integer 8; send host-name = gethostname(); request subnet-mask, broadcast-address, time-offset, routers, domain-name-servers, interface-mtu, rfc3442-classless-static-routes; 私は、を除いて、これらのすべてのオプションが何を意味するのかを理解していますrfc3442-classless-static-routes。また、rfc3442-classless-static-routesDHCP応答に関連するものは何もありません。 どのような意味でrfc3442-classless-static-routes、どのような状況でそれを利用しますか？ （ドキュメントはまったく意味がありません）

10 networking  dhcp  tcpdump  isc-dhcpd 

localhost上のサーバーを初期化し、同じマシン上のこのローカルサーバーに接続するクライアントの起動と停止を含む数千のストレステストを実行するテストスイートがあります。クライアントからサーバーにRSTが送信された理由を見つけようとしています。 これは一連のイベントです： クライアントがSYNを初期化する サーバーがSYN、ACKを送り返す クライアントがRSTを送信する（ACKおよび接続の確立の代わりに） 多くの場合、サーバーは99％のCPUを実行していますが、数秒/分で通常に戻ります。 クライアントがTIME_WAIT状態にある以前に閉じられた接続のポートを使用しているため、最初はこれが原因であると考えました。サーバーがSYN、ACKを送信すると、クライアントはRSTを発行します。なぜクライアントがTIME_WAIT状態のポートを使用する必要があるのか​​疑問に思っていましたが、古いfedoraコア4を使用していて、TCP / IPの適切な実装がないのではないかと思っていました:-)。 上記の問題を修正するために行われたすべての調整が問題の緩和に役立たなかったので、今、私はそれが理由であるとは思わない。参考までに、私が試した変更は次のとおりです/etc/sysctl.conf。 net.ipv4.ip_local_port_range = 1024 65535 net.ipv4.tcp_fin_timeout = 15 net.ipv4.tcp_rfc1337 = 1 net.ipv4.tcp_tw_reuse = 1 もう1つ、この問題は一貫していません。実際、この問題を再現できるのは、サーバーを再起動してすべてのクライアントテストを実行する15〜35サイクルを経過した後でのみです。 私はこれがなぜ起こり得るのかについて考えることができるすべての理由を使い果たしたので、誰かが何が起こっているのかについて何か考えがあれば私に知らせてください。 パケット詳細 Date & Time No. Time Source Destination Protocol Length Source port Dest port Info 2014-06-25 14:49:45.378209 1032719 1858.494749 ::1 ::1 TCP 94 netview-aix-5 navisphere …

10 fedora  tcp  tcpdump  tcp-ip