????????????????????¨????°???¨??§????????°???????¨??????¬???????????°?????±??????????????§??????

【至急】iptables設定について、下記の点をどなたかご教示いただけませんか？

????????? 2014/04/20 07:44 ????????? begin すみません、少々急ぎなので、どなたかご教示いただけませんでしょうか？ うまくいかずに困っています。 ■実現したいこと ブルートフォース攻撃対策で「60秒間に5回以上sshアクセスしてきたら、その後正しいID/PWでアクセスでも、送信元が同一IPなら10分間アクセス拒否」とする ■質問 URL（http://www2s.biglobe.ne.jp/~nuts/labo/inti/ipt_recent.html）を参考に、 下記iptables設定をして見たのですが、 teratermで60秒間に5回以上sshアクセスして6回目試行後、 「サーバに次の理由で切断されました. 'Too many authentication failures for [ユーザID]」 とポップアップが表示されても、 「/proc/net/xt_recent/sshconn」にアクセス元IPが記録され、 「/proc/net/xt_recent/badSSH 」に記録されず、即再試行可能です。 どのようにすれば、上記のようにアクセスされた場合、「/proc/net/xt_recent/badSSH 」に記録され、 任意の時間（今回は600秒間）アクセス禁止にできるでしょうか？ ログでも「evil SSH user: 」と記録され、識別できるようにしたいのですが。 messegeログでも特に「evil SSH user: 」は見当たりませんでした。 ■環境 RHEL6.2?6.5 CentOSの同バージョンになる可能性あり iptables-1.4.7-4.el6.x86_64 ■iptables設定 *filter :INPUT ACCEPT [1:40] :FORWARD ACCEPT [0:0] :OUTPUT ACCEPT [1:172] :SSH - [0:0] :SSH-evil - [0:0] -A INPUT -i virbr0 -p udp -m udp --dport 53 -j ACCEPT -A INPUT -i virbr0 -p tcp -m tcp --dport 53 -j ACCEPT -A INPUT -i virbr0 -p udp -m udp --dport 67 -j ACCEPT -A INPUT -i virbr0 -p tcp -m tcp --dport 67 -j ACCEPT -A INPUT -p tcp -m tcp --dport 22 -m state --state NEW -j SSH -A SSH -p tcp -m tcp ! --tcp-flags FIN,SYN,RST,ACK SYN -m state --state RELATED,ESTABLISHED -j ACCEPT -A SSH -p tcp -m tcp --tcp-flags FIN,SYN,RST,ACK SYN -m recent --rcheck --seconds 600 --name badSSH --rsource -j REJECT --reject-with icmp-port-unreachable -A SSH -p tcp -m tcp --tcp-flags FIN,SYN,RST,ACK SYN -m recent --rcheck --seconds 60 --hitcount 5 --name sshconn --rsource -j SSH-evil -A SSH -p tcp -m tcp --tcp-flags FIN,SYN,RST,ACK SYN -m recent --set --name sshconn --rsource -A SSH -p tcp -m tcp --tcp-flags FIN,SYN,RST,ACK SYN -j ACCEPT -A SSH-evil -m recent --set --name badSSH --rsource -j LOG --log-prefix "evil SSH user: " --log-level 7 -A SSH-evil -j REJECT --reject-with icmp-port-unreachable COMMIT

■ コンテンツ関連情報

Re: 【至急】iptables設定について、下記の点をどなたかご教示いただけませんか？ ( No.1 )
????????? 2014/04/21 15:02 ????????? begin 補足です。 設定後の動作確認の流れは下記です。 ⇒確認の仕方が間違っているのかも、どなたかご教示いただけますと幸いです。 ■動作確認の流れ 　≪環境≫ 　　デスクトップPC：１台（192.168.0.2） 　　ノートPC 　：１台（192.168.0.3） 　≪動作確認の流れ≫ １．デスクトップPCからサーバへ、teratermでのsshアクセスしてiptables設定 iptablesサービスリスタート ２．ノートPC（192.168.0.3）からサーバへ、「60秒間に5回以上、適当なID/PW」でsshアクセス 6回目アクセス試行後、teratermのポップアップで下記メッセージが表示され切断される ---- 「サーバに次の理由で切断されました. 'Too many authentication failures for [ユーザID]」 ---- ３．「proc/net/xt_recent/sshconn」をcatすると、「アクセス元IPアドレス」等が記録されている。 　　⇒なお、正常なID/PWでログイン試行しても、不正なID/PWでログイン試行しても、 　　　いづれも「/proc/net/xt_recent/sshconn」にログが記録されてしまう。 　　　しかし、「proc/net/xt_recent/badSSH」には何も記録されておらず、 　　　その後ノートPC（192.168.0.3）からサーバへ再ログインを試すと、即アクセス可能で、 　　　正常なID/PWであるなしにかかわらず、ログイン試行可能であるため、設定が有効になっていない？ （ただし「/proc/net/xt_recent/sshconn」にはログが記録されるため、一部の設定が機能していないのかも？） 以上です、 よろしくお願いいたします。
Re: 【至急】iptables設定について、下記の点をどなたかご教示いただけませんか？ ( No.2 )
????????? 2015/08/10 15:51 ????????? のんたろう 元記事から大分時間が経っていますが、最近、私も似たような話で嵌まりましたので。 一旦 ssh handshake を成立させたあと、password 認証失敗を 「5回/60秒」以上繰り返しても badSSH に flag が立たない、ということでしょうかね。この iptables 設定ですと、--hitcount が増えるのは認証失敗が発生したしたときではありません。制限時間内に同一 IP から sshポートを叩かれたサーバが sshd handshake を繰り返し成立させたときです。認証の成功・失敗は関係ありあません。 これは、/etc/ssh/sshd_config で LogLevel VERBOSE にして sshd 再起動し、色々試しながら sshd が吐く /var/log/secure と /proc/net/xp_recent/badSSH, sshcon の様子を見比べると分かります。同一 IP からのssh 接続をを、5回/60秒以上のレートで複数並行して立ち上げてやれば、6回目以降は /proc/net/xt_recent/badSSH に flag 立つのも見え、対応して、ssh handshake も拒否されるようになる筈です。 いっぽう、一旦 ssh handshake を成立してしまえば、その中でどのようなレートで何回 認証失敗を起こしてもそれを拒否るのは sshd のほうのなせる業です。その状態下ではこの iptables rule にはお構いはありません。そうしたタイプの認証失敗を攻撃試行であると看做してこの iptables rule で排除するのは無理な相談、ということになります。 と言うわけで、一旦立ち上げた ssh connection の中で多数回の認証失敗が発生、という場合も含めて、 throttling したい、ということでしたら、sshguard を使った方が良いです。 話を戻してこの iptables rule で進める場合、message log については、syslog の所定の level で log が記録されるように /etc/rsyslog.conf と iptables を整合してを設定する必要があります。warning にしておくなら、iptables では、--log-level 4 とし、rsyslog.conf では kern.warning /var/log/iptables.log とでもしておけば良いでしょう。
Re: 【至急】iptables設定について、下記の点をどなたかご教示いただけませんか？ ( No.3 )
????????? 2015/08/11 12:17 ????????? Johann うーん、そもそもこういう仕組みを導入する意図が分からないのですが。 外から攻撃されてはいけないシステムであれば、回数の制限をかける以前にネットワーク的に届かないように設定する方がはるかに安全です。 もしどうしてもということであれば、fail2banというソフトウェアがすでに開発されています。 http://www.fail2ban.org
黒倍王 ( No.4 )
?????? ?????????????????£???????????????????????? ??????

■ その他