web-dev-qa-db-ja.com

ejabberdをブルートフォース攻撃から保護する方法は？

これをログに書き込みます。

=INFO REPORT==== 2012-03-14 17:48:54 ===
I(<0.467.0>:ejabberd_listener:281) : (#Port<0.4384>) Accepted connection {{10,254,239,2},51986} -> {{10,254,239,1},5222}

=INFO REPORT==== 2012-03-14 17:48:54 ===
I(<0.1308.0>:ejabberd_c2s:784) : ({socket_state,tls,{tlssock,#Port<0.4384>,#Port<0.4386>},<0.1307.0>}) Failed authentication for USERNAME

=INFO REPORT==== 2012-03-14 17:48:54 ===
I(<0.1308.0>:ejabberd_c2s:649) : ({socket_state,tls,{tlssock,#Port<0.4384>,#Port<0.4386>},<0.1307.0>}) Failed authentication for USERNAME

失敗したIPは書き込みません。
そして、文字列「Acceptedconnection」と「Failedauth ..」は、fail2banを使用できるように、近くに立っていない場合もあります（負荷の高いサーバーで考えているように）。
何をすべきか？また、Jabberサーバー（ejabberdを使用）はどのように保護されていますか？

brute-force-attacksejabberd
2
Sergey

Iptablesを使用して、IPアドレスが試行できる1分あたりの接続試行回数を制限できます。これらは自動化された攻撃であるため、ほとんどの場合、スクリプトはブロックされると別のターゲットを見つけるために移動します。

この例はtcpポート22（ssh）用であり、そのIPアドレスからパケットをドロップする前に1分あたり3回の接続試行を許可します。

iptables -A INPUT -p tcp --dport 22 --syn -m limit --limit 1/m --limit-burst 3 -j ACCEPT
iptables -A INPUT -p tcp --dport 22 --syn -j DROP
2
3dinfluence

fail2banは、iptablesの上に便利な追加のロジックレイヤーを提供します。 ejabberdのサイトでのリクエストlog_modsessionを使用して、fail2banを使用できるようにするための可能なアプローチを提案しました。 ejabberd-modules に含まれています。

失敗した認証の試行をログに記録するには、ejabberdのコアにパッチを適用する必要があります。幸い、log_modsessionはそのパッチに付属しているので、それを適用してejabberdを再コンパイルする必要があります。

0
giavac

もう1つの方法は、fail2banで使用されているのと同じアプローチを使用することです。ファイル変更モニター（fam）ライブラリを使用するため、ejabberdログファイルを監視し、fail2banと互換性のある形式で出力するカスタムデーモンを作成できると思います。 pythonおよびそのためのPerlバインディング。

場合によっては、別のプログラムのソースをニーズに合わせて調整すると、ダウンロード/パッチ/コンパイルの追加作業が追加されるため、ディストリビューションのセキュリティ更新の恩恵を受けることができません。その作業を行う必要があります。反対側では、パッチを送信できます。 ejabberdを担当する著者に、彼らが価値があり、コミュニティ全体が利益を得ることができるとわかったら、彼らの答えを待ちます。

しかし、私はカスタムデーモンを使用します。

0
nestor diaz