ssh の brute force アタックパケットの制限 -- DOS 的パケットをフィルタリングする : DSAS開発者の部屋
KLab はコンテンツの開発と共に運用も日々担っていますが，その活動の全ての拠点は社内のシステムです．そのため，社のシステムにはいつでも外からアクセスできる必要があります．システムへのアクセスは ssh を使うのですが，この ssh へのアクセスは前記の理由で世界中からアクセスできる必要があります．こういった公開されている ssh のポートへは日々飽きもせずに brute force アタックが繰り返されています．sshd はこのような成功するはずのないアタックであっても律儀にログを出力してくれます．しかしながら，無意味なログの羅列は，重要なログが埋もれる結果になって嬉しくありません．それに，アタックによるログインの試行のために CPU 時間を無駄に費やすのもばかばかしいことです． ログの出力や CPU 時間の浪費を低減するには，これらの攻撃パケットをフィルタリングしてやればいいのですが，
(ひ)メモ - ipt_recent
補足：いまならrecentじゃなくてhashlimitを使った方がよさげ。 以下の文章はrecentについてなので、hashlimitについて追記した id:hirose31:20060421 を見てもらった方がいいと思うす。 SSHのbrute forceアタックがうざいので、iptablesで悪い子はDROPするようにする。 OpenSSHのログをみて、 一定時間に一定回数連続でアクセスに失敗しているやつはDROPするようにして、 atで然るべき時間が経ったら解除するように しようかなぁと思ったら、iptablesにはipt_recentなんて便利がものがあるのがわかった。 Debian GNU/Linux 3.1(sarge)運用ノート SuSE Security mailinglist: Re: [suse-security] SSH attacks. iptables(8) ↑を
mixi Engineers’ Blog » Linux Programming、epollの話
お久しぶりです、初めての日本の夏に圧倒されているトールマエサカです。 今日はLinuxにおけるネットワークプログラミング関連のネタです。分散データベースサーバの開発過程で最近よくLinuxのepollというイベントハンドリング機能を使っています。これがまた優秀な機能なので紹介します。 このContextでいうイベントハンドラーはサーバがクライエントのリクエストを処理するためのメカニズムです。イベントの感知と通知は大雑把にいうと以下の三つの処理で構成されています： 一つもしくは複数のディスクリプタを監視 ディスクリプタの準備が整うまでハチ公のごとくひたすら待ち続ける 準備が整ったディスクリプタの通知 アプリケーションでの実装は一昔までselect(2)、もしくはpoll(2)というシステムコールで行われていました。二つとも役目は同じですがselect(2)の場合、kernelをいじらない限り
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
