解決策 1:
私は本当にtcpdumpを取得しようとします。そうは言っても、IP に対して特定の接続が存在するかどうかを確認するためのいくつかの代替手段は次のとおりです。
トレース:
[[email protected]: ~] strace -e trace=network nc 1.2.3.4 1234
...
socket(PF_INET, SOCK_STREAM, IPPROTO_TCP) = 3
connect(3, {sa_family=AF_INET, sin_port=htons(1234), sin_addr=inet_addr("1.2.3.4")}, 16) = -1 EINPROGRESS (Operation now in progress)
lsof:
[[email protected]: ~] nc 1.2.3.4 1234 &
[1] 11434
[[email protected]: ~] lsof -p 11434
....
nc 11434 kbrandt 3u IPv4 4543149 0t0 TCP 10.7.0.78:58886->1.2.3.4:search-agent (SYN_SENT)
ネット統計:
[[email protected]: ~] nc 1.2.3.4 1234 &
[1] 11486
[[email protected]: ~] sudo netstat -a -p | grep 11486
tcp 0 1 10.7.0.78:58891 1.2.3.4:search-agent SYN_SENT 11486/nc
解決策 2:
きっとあなたは python を持っています ?
from socket import *
from struct import unpack
import sys
INTERFACE = "eth0"
TARGET = "8.8.8.8"
if __name__ == "__main__":
sock = socket(AF_PACKET, SOCK_DGRAM, 0x0800)
sock.bind((INTERFACE, 0x0800))
while True:
data = sock.recvfrom(1500, 0)[0]
ip = inet_ntop(AF_INET, data[12:16])
if ip == TARGET:
print "GOT TARGET"
sys.exit(1)
これは「GOT TARGET」で終了し、戻ってくる IP アドレスが一致します。 TCP はハンドシェイク中に何かを送り返す必要があるため、これは特定のターゲット アドレスから何かをキャッチする必要があります。ただし、プロトコルが TCP であるか UDP であるかは気にしません (チェックもしません)。
TARGET と INTERFACE を変更することを忘れないでください。
解決策 3:
iptables にはデバッグ機能があり、トラフィック分析にも使用できます。
下記URLに解決方法が記載されています。
iptables でのルールのデバッグ
次の URL を読んで、選択したファイルへのトレース出力のログを設定することもお勧めします。
http://backreference.org/2010/06/11/iptables-debugging/
このソリューションが tcpdump と同等であるとは考えていませんが、Centos の最小インストールを使用して実行できます。 tcpdump はディスクの使用効率がはるかに高いため、ディスクがログでいっぱいにならないように注意する必要があります。不要な場合はログをオフにしてください。
以下をスクリプトの基本テンプレートとして使用できます。
# Logging
log(){
SOURCE=a.b.c.d (IP address)
$IPT -A INPUT -s $SOURCE -m limit --limit 50/minute -j LOG --log-level 7 --log-prefix "In: "
$IPT -A OUTPUT -s $SOURCE -m limit --limit 50/minute -j LOG --log-level 7 --log-prefix "Out: "
$IPT -A FORWARD -s $SOURCE -m limit --limit 50/minute -j LOG --log-level 7 --log-prefix "Fw: "
$IPT -t nat -A POSTROUTING -m limit --limit 50/minute -j LOG --log-level 7 --log-prefix "Nat: "
}
#log (remove comment to enable)
trace(){
iptables -t raw -A PREROUTING -p tcp -j TRACE
iptables -t raw -A OUTPUT -p tcp -j TRACE
}
#trace (remove comment to enable)
解決策 4:
仕事をするために特定のソフトウェアが必要なのに、それが許可されていない場合は、良いビジネス ケースを作成していないかのどちらかです またはあなたのアイデアを適切な人に売り込む...または あなたはこのシステムを制御できません...
私が何かをする任務を負っており、この場合に必要な種類のデバッグ/トラブルシューティング情報が必要な場合は、適切なツールを使用します.おそらく tcpdump です または tshark .はい、これらはソフトウェアの一部ですが、より不可欠なユーティリティだと思います .実際、それらはシステムに一時的にインストールまたはロードして問題なく削除できるユーティリティです (リムーバブル メディアはオプションですか?...ヒント )
しかし要点は、会社のポリシーに対するぎこちない回避策は、おそらくこのユースケースの承認を得るよりも多くの労力を必要とするということです.
解決策 5:
カイルはいくつかの素晴らしいオプションを提供しました。もう1つは iptables を使用することです :
[[email protected] ~]$ sudo iptables -I OUTPUT -d 1.2.3.4/32
...
[[email protected] ~]$ sudo iptables -L OUTPUT -n -v
Chain OUTPUT (policy ACCEPT 105 packets, 35602 bytes)
pkts bytes target prot opt in out source destination
87 33484 LOG all -- * * 0.0.0.0/0 1.2.3.4 LOG flags 0 level 4
これは本質的に会計規則です。明示的にトラフィックを許可または拒否しないため、OUTPUT チェーンのデフォルト ポリシーが使用されます (デフォルトは ACCEPT です)。ただし、パケットが一致すると、ルールのカウンターが増加します。
-j LOG を使用して、オプションでパケットに関する詳細をログに記録することもできます オプション:
[[email protected] ~]$ sudo iptables -I OUTPUT -d 1.2.3.4/32 -j LOG
...
[[email protected] ~]@ dmesg | grep 1.2.3.4 | tail -1
IN= OUT=eth0 SRC=192.168.1.1 DST=1.2.3.4 LEN=100 TOS=0x10 PREC=0x00 TTL=64 ...
ログはカーネル ロギング機能に送られるため、Red Hat 派生物では /var/log/messages に、Debian 派生物では /var/log/kern.log に表示されるはずです。 dmesg の出力にも表示されます 、示されているように。 tcpdump とは異なります