アラートログファイルをsyslogサーバーに送信しない
サーバー、クライアント、ゲートウェイというUbuntuを実行する3つの仮想マシンをセットアップしました。クライアントからサーバーへの「攻撃」を監視するようにゲートウェイでSnortを設定する必要があります。 Snortは、サーバーにセットアップしたrsyslogサーバーにログファイルを送信することになっています。これらのログを送信するのに問題があります。
Snort.confファイルで、次のように設定しました。
output alert_syslog: LOG_AUTH LOG_ALERT
私は自分のiptablesをフラッシュし、テスト目的ですべてを開きました（nmapは514が実際に開いていることを示しています）。 Gatewayでrsyslog.confファイルを編集して追加しました：
*.* @192.168.50.5
サーバーのrsyslog.confファイルに、次のように追加しました。
*.* /var/log/snort.log
両方で次のコメントを外します：
$ModLoad imudp.so
$UDPServerRun 514
実行すると（eth2 =クライアント）：
snort -A console -i eth2 -c /etc/snort/snort.conf
クライアントからサーバーにpingを実行すると（ICMPをキャプチャするSnortルールがあります）、ゲートウェイの/var/log/snort/snort.log.xxxxxxxxxxにログファイルが作成されます。ただし、サーバーには何も表示されません。 Wiresharkでパケットを監視すると、Snortを開始すると2つのSyslogメッセージが表示され、終了するとさらに2つ（^ C）が表示されます。 AUTHPRIV.INFOは、「ユーザーrootに対して開いているセッション」と「ユーザーrootに対して閉じているセッション」とだけ言っています。
記録のために、私はこのチュートリアルをここで実行しようとしました：
誰が何が起こっているのか考えていますか？
アドバイスありがとうございます。
セッションの開閉に関するsyslogメッセージが届いている場合、rsyslogはおそらく両端で動作していると思います（ただし、loggerを使用してゲートウェイのsyslogに送信することで確認できます）。また、ログファイルがゲートウェイで作成されるという事実は、ログメッセージがチェーンプロセスの後半ではなく、ゲートウェイで誤って処理されていることを示しています。
Snortが実際にUDPをsyslogに送信していることを確認したいと思います。ゲートウェイのループバックインターフェイス上にあると思われるポート514に予期されるパケットがありますか？
ローカルのsyslogを回避して、サーバーのホストに直接アクセスできるようです。
出力alert_syslog：Host = 192.168.50.5：514、LOG_AUTH LOG_ALERT
それが魅力的でない場合、snortの出力を明示的にlocalhost：514に送信するとどうなりますか？または、そのホスト上の別のIPに。
ゲートウェイのポート514へのパケットをブロックする可能性のあるファイアウォールの問題はありますか？
新しい設定を取得するためにsnortを再起動しましたか？それはあなたがそうであると思う設定ファイルを読んでいますか？ （-cで明示的に指定するか、psで表示されるコマンドラインの一部であることを確認してください）。
（ある時点で、snortメッセージとして提出されるものを制限する必要がありますが、それは現在スタックされているものではありません）。
Ubuntu Snortでは、デフォルトでLOG_AUTH機能を使用してログを記録するため、tail -f /var/log/auth.log のではなく /var/log/syslog。しばらくこれにこだわった誰かからのメモ:)