Asterisk13での、INVITEによるBrute force攻撃
件名の通りの話をまとめるけど、イマイチ情報がなくて・・・。
voip-infoでの、INVITEによるBrute force攻撃
の話は、Asterisk-1.4.40、1.6系、1.8系についてです。
うちのは、Asterisk13です。この点で、対応が遅れた。
まずは、いまいち、inviteって分からないから、調べる。
insecure=port, invite
peerとの接続に関する設定のようです。 portを設定しておくと、どのポートからのアクセスでも許可するようになります。invite を設定しておくと着信時の認証が不要になるようです。
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