Asterisk13での、INVITEによるBrute force攻撃

件名の通りの話をまとめるけど、イマイチ情報がなくて・・・。

voip-infoでの、INVITEによるBrute force攻撃
の話は、Asterisk-1.4.40、1.6系、1.8系についてです。

うちのは、Asterisk13です。この点で、対応が遅れた。

まずは、いまいち、inviteって分からないから、調べる。

http://yyatsuo.com/?p=1001

insecure=port, invite
peerとの接続に関する設定のようです。 portを設定しておくと、どのポートからのアクセスでも許可するようになります。invite を設定しておくと着信時の認証が不要になるようです。

http://www.voip-info.jp/index.php/SIP-Fail2ban#INVITE.E3.81.AB.E3.82.88.E3.82.8BBrute_force.E6.94.BB.E6.92.83.E3.81.B8.E3.81.AE.E5.AF.BE.E7.AD.96

 INVITEによるBrute force攻撃への対策

REGISTERメッセージによる攻撃以外に、INVITEによるBrute force攻撃も確認されています。

実は、ずっと、うちのサーバーが攻撃されていて、Registerで来るのは、自動でファイアーウォールでブロックするように組み込んでいるんだけど、ブロックできないのがあって。
うえに書いた、Inviteでの攻撃も知ってはいたけど、記録されるログ形式が違って、イマイチ判断が付かなかった。
しかも、上のサイトの対応方法は、ソースコードを変更して、コンパイルしないといけないので、手間だなと思い、後回し。

そして、今回、改めて調べたところ、

asteriskserver*CLI> sip show channels
Peer             User/ANR         Call ID          Format           Hold     Last Message    Expiry     Peer
23.239.65.10     3208             fb7eee554026b10  (nothing)        No       Rx: INVITE                 <guest>
23.239.65.10     3208             ceaf791ca12e0da  (nothing)        No       Rx: INVITE                 <guest>
23.239.65.10     3209             4b4911701752dc5  (nothing)        No       Rx: INVITE                 <guest>
3 active SIP dialogs

INVITEって書いてあるでしょ。古い記憶を呼び起こし、voip-infoに書いている攻撃かなと思ったわけ。

ただ、ログの記述方法も違う。

voip-infoでは、

Failed to authenticate user "Anonymous" <sip:anonymous@192.168.1.2>;tag=as105e401c 

となっている。発信元のIPが出ないから、ソースコードを変更してコンパイルをしようという、話の流れだったの。

うちのAsterisk13への攻撃者のログは、

[2015-05-22 12:17:18] SECURITY[4639] res_security_log.c: SecurityEvent="ChallengeSent",EventTV="2015-05-22T12:17:18.420+0900",Severity="Informational",Service="SIP",EventVersion="1",AccountID="sip:3200@myIPaddress",SessionID="0x7fbbcc03b298",LocalAddress="IPV4/UDP/myIPaddress/5060",RemoteAddress="IPV4/UDP/23.239.65.10/5100",Challenge="1f1a28d¥c"

そして、自分が使う正常なアクセスは、下記の通り。

[2015-05-22 11:58:44] SECURITY[4639] res_security_log.c: SecurityEvent="ChallengeSent",EventTV="2015-05-22T11:58:44.543+0900",Severity="Informational",Service="SIP",EventVersion="1",AccountID="内線番号",SessionID="0x7fbbcc001a78",LocalAddress="IPV4/UDP/myIPaddress/5060",RemoteAddress="IPV4/UDP/222.10.37.232/2956",Challenge="0bedc001"

ほとんど違いは無く、AccountIDの部分が、
攻撃者は、AccountID=”sip:3200@myIPaddress”
正常なのは、AccountID=”内線番号”
という風に、IPアドレスが含まれているかどうか。
このIPアドレス、クライアントの設定によっては、入りそうな気もするから、これだけでは判断が出来ない。

Registerの場合は、存在する内線番号なのかどうか、ログに書きだしてくれた気がする。
今のところ、対処方法が無い。
検索したけど、同様の場合の対処方法をまとめているサイトが見つからないので(海外も含めて)

今回は、調査のみで、未解決。

しばらく解決方法がなかったら、内線にIPアドレスが入っていたら、BANするルールにすることにする。

とりあえず、攻撃者のIPアドレスは、分かっているので、iptableに追加して置く。

iptables -D INPUT  -s 23.239.65.10 -j REJECT
としたけど、イマイチ防いでくれない。

よくよく考えて、最後に追加するのではなく(-D)、最初に追加することにする(-A)

iptables -I fail2ban-ASTERISK  -s 23.239.65.10 -j REJECT
ルールの先も、一般的なINPUTじゃなく、fail2banのAsteriskのところにする

攻撃者のIPアドレスを変えてきたら、意味がないけど。

http://www.unix-power.net/linux/iptables.html

iptables -D INPUT  -s 23.239.65.10 -j REJECT

参考になった方、誤りを見つけた等、コメントを残してくれるとうれしいです。

Loading Facebook Comments ...

コメントを残す

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です