SIP iptablesを突破するUDPリクエスト
SIP= UDPトラフィックがiptablesで定義されたルールセットをどうにかして回避しているため、ルールに穴があると疑うようになったため、アドバイスを探しています。ローカルシステムの防御を強化する方法です。このサーバーの前にはファイアウォールがあり、改善できる可能性があります。ただし、この問題はローカルサーバーの防御、特にiptablesに直接関係するため、追加の対策を検討する前にこの問題を理解しておくことが重要と思われます。 。
SIPパケットにはSQLインジェクションの試みが含まれ始めており、直接対処しないと、最終的にアプリケーションが侵害される可能性があるのではないかと心配しています。現在、「発信者」は、サービスのアナウンスがないため、SIP会話がローカルサーバーで開始されました-理想的ではありません！
以下の詳細を一貫した編集スキームとともにコピーしましたが、追加情報が必要な場合は、以下にコメントしてください。
見てくれてありがとう、アドバイスをありがとう！
元のIP：185.107.83.35 SIPサーバーIP：200.200.114.207
私は攻撃的なSIPパケットの例から始めます：
INVITE sip:00*[email protected]:5060;transport=UDP SIP/2.0
Via: SIP/2.0/UDP 185.107.83.35:5060;branch=z9hG4bK-524287-1---i9aif7pifkudxkd8
Max-Forwards: 70
Contact: <sip:...hi'or...x...='x';@185.107.83.35:5060;transport=UDP>
To: <sip:00*[email protected];transport=UDP>
From: <sip:...hi'or...x...='x';@200.200.114.207;transport=UDP>;tag=gj0njz16
Call-ID: LztInRxh5KJSOAGxCOGB0T..
CSeq: 1 INVITE
Content-Type: application/sdp
User-Agent: Avaya one-X Deskphone
Allow-Events: presence, kpml, talk
Content-Length: 515
v=0
o=Avaya 0 0 IN IP4 185.107.83.35
s=Avaya
c=IN IP4 185.107.83.35
t=0 0
m=audio 8000 RTP/AVP 18 3 110 8 0 97 101
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=rtpmap:97 iLBC/8000
a=rtpmap:3 GSM/8000
a=rtpmap:98 AMR/8000
a=rtpmap:9 G722/8000
a=rtpmap:100 SPEEX/8000
a=rtpmap:99 AMR-WB/16000
a=rtpmap:102 SPEEX/16000
a=rtpmap:121 G7221/16000
a=fmtp:121 bitrate=24000
a=rtpmap:105 opus/48000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=sendrecv
ホストのIP構成：
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope Host lo
inet6 ::1/128 scope Host
valid_lft forever preferred_lft forever
2: em1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP qlen 1000
link/ether 00:11:22:33:44:7d brd ff:ff:ff:ff:ff:ff
inet 192.168.20.20/24 brd 255.255.255.255 scope global em1
inet6 aaaa::aaaa:aaaa:aaaa:aaaa/64 scope link
valid_lft forever preferred_lft forever
3: em2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP qlen 1000
link/ether 00:11:22:33:44:7f brd ff:ff:ff:ff:ff:ff
inet 200.200.114.207/26 brd 200.200.114.255 scope global em2
inet6 aaaa::aaaa:aaaa:aaaa:aaaa/64 scope link
valid_lft forever preferred_lft forever
4: em3: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN qlen 1000
link/ether 00:11:22:33:44:81 brd ff:ff:ff:ff:ff:ff
5: em4: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN qlen 1000
link/ether 00:11:22:33:44:83 brd ff:ff:ff:ff:ff:ff
これはiptables -v -n --listからの出力です
Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
4769K 538M ACCEPT icmp -- * * 0.0.0.0/0 0.0.0.0/0 /* 000 accept all icmp */
645M 276G ACCEPT all -- lo * 0.0.0.0/0 0.0.0.0/0 /* 001 accept all to lo interface */
11G 2946G ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 /* 002 accept related established rules */ state RELATED,ESTABLISHED
4036K 238M ACCEPT tcp -- em1 * 0.0.0.0/0 0.0.0.0/0 multiport ports 22 /* 101 accept SSH from internal interface */
36907 2036K ACCEPT all -- em1 * 192.168.4.0/24 0.0.0.0/0 /* 102 accept all traffic from site 1 LAN */
160K 6397K ACCEPT all -- em1 * 192.168.5.0/24 0.0.0.0/0 /* 103 accept all traffic from site 1 LAN */
8651K 527M ACCEPT all -- em1 * 192.168.20.0/24 0.0.0.0/0 /* 105 accept all traffic from site 2 LAN */
0 0 ACCEPT tcp -- em2 * 190.190.89.10 0.0.0.0/0 multiport ports 22 /* 106 accept SSH from WAN */
0 0 ACCEPT tcp -- em1 * 0.0.0.0/0 0.0.0.0/0 multiport ports 2812 /* 107 accept monit from LAN */
41878 19M ACCEPT udp -- em2 * 190.190.89.0/26 0.0.0.0/0 multiport ports 5060 /* 150 accept SIP from WAN */
144K 55M ACCEPT udp -- em2 * 200.200.114.192/26 0.0.0.0/0 multiport ports 5060 /* 152 accept SIP from WAN */
0 0 ACCEPT udp -- em2 * 180.180.63.32/27 0.0.0.0/0 multiport ports 5060 /* 201 accept SIP from carrier */
0 0 ACCEPT udp -- em2 * 180.180.63.32/27 0.0.0.0/0 multiport ports 8000:60000 /* 202 accept RTP from carrier */
0 0 ACCEPT udp -- em2 * 170.170.67.2 0.0.0.0/0 multiport ports 5060 /* 210 accept SIP from carrier */
0 0 ACCEPT udp -- em2 * 170.170.67.2 0.0.0.0/0 multiport ports 8000:60000 /* 211 accept RTP from carrier */
55M 8576M ACCEPT udp -- em2 * 0.0.0.0/0 0.0.0.0/0 multiport ports 16384:32768 /* 300 accept all RTP */
489K 219M REJECT all -- * * 0.0.0.0/0 0.0.0.0/0 /* 999 reject all other requests */ reject-with icmp-Host-prohibited
Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
0 0 REJECT all -- * * 0.0.0.0/0 0.0.0.0/0 /* 998 reject all FORWARD */ reject-with icmp-Host-prohibited
Chain OUTPUT (policy ACCEPT 12G packets, 3230G bytes)
pkts bytes target prot opt in out source destination
そのパケットのIPヘッダーを確認する必要があります。 TTL=値の直後は、プロトコルを示しているはずです。プロトコルが1つとして入ってくる場合は、それが問題になります。これは以前にこのようなものを見たことがあります。
プロトコル値1はICMPを示し、最初のルールとしてグローバルに許可します。これはpingが機能するために必要ですが、拒否するように構成された境界ファイアウォールがない限り、不正な形式のパケットを許可します。
有効なSIPパケットヘッダーでは、特定の構成に応じて、UDPの場合は17、TCPの場合は6を使用する必要があります。
攻撃者が不正な形式のSIPパケット（17ではなくプロトコル1に設定）を使用している場合、pingを除くすべてのタイプのICMPパケットをドロップするようにファイアウォールを設定できます。何でも受け入れる理由はほとんどありません。外部ホストからの有効なpingに加えて。
この場合、おそらくpcapファイルが助けになりますが、ここに、私が与えられた情報から何が起こっていると思いますか：
INVITEには送信元と宛先のIP 200.200.114.207、
To: <sip:00*[email protected];transport=UDP>
From: <sip:...hi'or...x...='x';@200.200.114.207;transport=UDP>;tag=gj0njz16
iNVITEが正しい場合、IPアドレスはあなたが思うルールの1つと一致しているようです。
144K 55M ACCEPT udp -- em2 * 200.200.114.192/26 0.0.0.0/0
あなたができることはポートルールで始めることです、5060と5061は通常のSIPポートであり、その後あなたのiptablesのIP範囲のために行きます。
チェーンの最初に関連/確立されたルールがあります（誰もがそうです）。 iptablesのsipモジュールが存在するかどうかを確認してください。
lsmod |grep -i sip
それがリークの原因である可能性があります。その場合は、SIPトラフィックに対してそれをバイパスしてみてください。
参考までに、私はこれとまったく同じ問題を抱えています。テストから、UDP接続追跡（RELATED、ESTABLISHEDルールで呼び出された）が、UDP/5060用に指定されたパケットを既存のセッションまたは関連するセッションの一部として識別しているようです。これを確認するには、接続追跡テーブルを調べ、UDP/5060でエントリ全体を検索します。問題のあるエントリには[ASSURED]フラグがあります。
私の推測では、connトラッカーはパケットを関連セッションの一部として認識し、パケットの通過を許可しています。次に、サーバーが応答し（通常はSIP INVALID応答）、これによりASSURED状態に送信されます。技術的には、関連部分は接続トラッカーヘルパー（SIP ALGヘルパーなど）によってのみ呼び出されることになっています。カーネルモジュールをロードしていないので、少しずれていて、関連しているとは思われませんが、実際には確立されたセッションです。その場合、それはさらに大きなバグです。
現在の回避策は、問題のあるIPからのパケットをブロックすることですprior ESTABLISHED/RELATEDルールにヒットするまで。これはそれを修正し、それほど多くはありませんが、それは非常に迷惑です。