TOMOYO LinuxでSSH総当たりアタックから防御するユーザー認証 41
ストーリー by kazekiri
ちとぐぐっときた 部門より
ちとぐぐっときた 部門より
jonykatz曰く、"NTTデータが、セキュアOS「TOMOYO Linux」を利用し、 SSH総当たりアタックから防御できる利用者認証方式を開発したと ITmediaが伝えている。 SSHブルートフォースは、SSHサービスのパスワードを 総当たりで割り出して侵入する手法であるが、 新開発の利用者認証方式では、仮に総当たりで侵入されたとしても TOMOYO Linuxの「強制アクセス制御機能」を用いることで、 SSHログインしてきたユーザーに回避不能な追加認証を強制させるという。
プロトタイプでは、パスワード文字列をキーボードから入力する際の速度や 打鍵タイミングによる認証と、事前登録した携帯電話に送信した ワンタイムパスワード入力による認証の2種類を実装しているとのこと。 この成果は11月をめどに「 TOMOYO Linuxプロジェクト」で公開されるらしい。"
とりあえず過去記事 (スコア:3, 参考になる)
TOMOYO Linux Ver.1.0 Released [srad.jp]
ちなみに名前の由来は「Task Oriented Management Obviates Your Onus on Linux」ですからね。
I think I can
追加情報 (スコア:2, 参考になる)
I think I can
Re:追加情報 (スコア:1)
その通りです。リリースの原案では書いてあったのですが、広報室と調整の過程でカットされてしまいました。
tsh
Re:とりあえず名前 (スコア:0)
なんとかうまいごろあわせで
NUIGURUMI か OFUROSPONGE に変更できないものか。
Re:とりあえず名前 (スコア:0)
#なんの頭文字かはわからんが。
Re:とりあえず名前 (スコア:1)
そもそも使わないとか言われたら、このネタが崩壊する訳ですが。
#名前の由来は同じケルベロスやね
Re:とりあえず名前 (スコア:0)
名前をつける(変える)べき対象が存在しない。
Re:とりあえず過去記事 (スコア:0)
ぜってー後付けだ。
俺も良くやるが、同類の臭いがビンビンするぜぇ~
Re:とりあえず過去記事 (スコア:1, 参考になる)
> This project was very inspired by the comic "Card Captor SAKURA", one of the CLAMP's masterworks.
> The names SAKURA and TOMOYO and SYAORAN were borrowed from the comic
> with the heartfelt thanks to CLAMP.
後付で由来を隠すようなヘタレ野郎とは違って堂々としてますよ。
“由来”はカードキャプターさくらで、正式名称が「Task Oriented Management Obviates Your Onus on Linux」でしょう。
Re:とりあえず過去記事 (スコア:1, すばらしい洞察)
SSH総当たりアタックから防御できる利用者認証方式 (スコア:2, 興味深い)
公開鍵認証(限定)でいいじゃん。
==========================================
投稿処理前プレビュー確認後書込処理検証処理前反映可否確認処理後……
Re:SSH総当たりアタックから防御できる利用者認証方式 (スコア:2, すばらしい洞察)
> 一方、ICカードやバイオメトリクス認証、公開鍵認証ではより強固な本人確認が可能だが、コストや導入の手間がかかる点がネックとなっている。
と書いてあります。
ちょっと昔なら「脅威に対してコストが高すぎる」と言えたかもしれませんが、
今となっては脅威が十分に大きくなっていますから、
まだ「コストが」なんて言ってる人 (会社) は認識を改めるべきでしょう。
だいたい、素人考えでは、
社員全員にパスワード配布するのと秘密鍵を配布するのでは、
それほど変わらないように思えるのですが、どうなのでしょう。
少なくとも携帯電話まで巻き込むシステム構築よりは楽ですよね。
ていうか、TOMOYO 導入のコストやリスクはどうなのか。
# 雰囲気的に SELinux よりは「センがいい」ように感じていますけど、品質とは別ですし。
Re:SSH総当たりアタックから防御できる利用者認証方式 (スコア:2, 参考になる)
>それほど変わらないように思えるのですが、どうなのでしょう。
「総当りされても平気(なはず)」程度ですね。結局盗まれればおわり。
クセは盗まれにくい。たぶん、銀行口座へのサイン証明ぐらいには強度がある。
(無作為なユーザーへの認証程度は弾けそうだ)
そういえば昔
RS232Cにキーアダプタ刺して認証させるのがあったような?
でもこの考え方を進める限りは、手持ちの認証システムをPCに付けちゃダメなんだろうな。
最近銀行が発行してるワンタイムパスワード認証みたいに
完全にPCと隔離したところにシステムを持ってこなきゃいけないか。
直ぐに発行できて、
紛失しても、直ぐに認証無効化できて。
なおかつ再発行が容易であるもの。
……難しいね。
ちょっと財布の中に入ってる紙幣番号が使えないかとか考えちゃいました。
==========================================
投稿処理前プレビュー確認後書込処理検証処理前反映可否確認処理後……
Re:SSH総当たりアタックから防御できる利用者認証方式 (スコア:1, すばらしい洞察)
(デフォルト6)
Re:SSH総当たりアタックから防御できる利用者認証方式 (スコア:1, すばらしい洞察)
Re:SSH総当たりアタックから防御できる利用者認証方式 (スコア:1, 興味深い)
Re:SSH総当たりアタックから防御できる利用者認証方式 (スコア:1)
携帯電話に送られてくるメイルを読むために,生体認証を必要とすれば良いのかな?
Re:SSH総当たりアタックから防御できる利用者認証方式 (スコア:1)
それにしたって、MIみたいに虹彩を移植したり、24みたいに指を切り取って認証されたら万全ではないですよね?
セキュアOSであれば、ssh通過後にお手製の認証手段を多段組み合わせ、強制させることができる。それにより普通のOSでパスワードだけの認証だけの状態を改善できるというのが、リリースの意図です。携帯電話については追加する認証手段のアイデアのサンプルにすぎませんし、それで万全とは書いていないのです。
tsh
Re:SSH総当たりアタックから防御できる利用者認証方式 (スコア:1)
tsh
Re:SSH総当たりアタックから防御できる利用者認証方式 (スコア:0)
攻撃者がたくさんのIPアドレスを用意すれば、偶然1発目で的中してしまう可能性があります。
公開鍵認証を使う方式では、公開鍵を盗まれるかもしれません。
また、認証を行うプログラムの脆弱性によって回避されるかもしれません。
ゼロディアタックにも対処できません。
既存のログイン認証後に追加認証を行う方式は、偶然にもゼロディアタックにも同時に対抗できるという点が既存のブルートフォース対策とは違います。
また、最
Re:SSH総当たりアタックから防御できる利用者認証方式 (スコア:0)
ワロタ。ここは素人の来るところじゃないよ。
> また、認証を行うプログラムの脆弱性によって回避されるかもしれません。
> ゼロディアタックにも対処できません。
はあ。ともよちゃんには脆弱性もないしゼロディもアリエナイよと。
> 既存のログイン認証後に追加認証を行う方式は、偶然にも
> ゼロディアタックにも同時に対抗できるという点が既存の
> ブルートフォース対策とは違います。
意味わかんね。
Re:SSH総当たりアタックから防御できる利用者認証方式 (スコア:1, 参考になる)
> ゼロディアタックにも同時に対抗できるという点が既存の
> ブルートフォース対策とは違います。
それは恐らく切るところを間違っている。
多分元コメントはこう。
> 既存のログイン認証後に追加認証を行う方式は、
> 偶然にもゼロディアタックにも
> 同時に対抗できるという点が
> 既存のブルートフォース対策とは違います。
更に「既存のブルートフォース対策」は恐らく「既存の『ブルートフォース対策』」で、言いたかった事はきっと
> 二重にログイン認証すれば、偶然一つ目のパスワードを当てられてしまった場合にも二つ目のパスワードで防御できる。
> また、一つ目の認証機構にゼロデイ攻撃の危険がある脆弱性が存在しても、二つ目の認証機構に同時にゼロデイが存在しない限り安全である。
> 以上の二点が既存の認証機構強化策とは違う。
こんな感じ?
Fail2ban (スコア:2, 参考になる)
何度か認証に失敗したIPアドレスからの接続を一定時間拒否できます。
Re:Fail2ban (スコア:1)
iptablesのバージョンが古いと使えないのがネックではありますが。
Re:Fail2ban (スコア:1)
その場合、こんな方法も。
http://blog.so-net.ne.jp/fullcover/2005-08-28 [so-net.ne.jp]
Re:Fail2ban (スコア:1)
BlockSSHD [sourceforge.net]つうのもあります。
Re:Fail2ban (スコア:0)
http://www.freebsdwiki.net/index.php/Block_repeated_illegal_or_failed_... [freebsdwiki.net]
にあります。
shell scriptを廻すだけなので細かい制御はできないかもしれませんが汎用性は高そう。
Re:Fail2ban (スコア:1)
# 一度でも認証に失敗したら数秒で発動し、3日間はIPアドレスごと無視されるという...。
ネーミングについて必見 (スコア:1)
で、自ら「TOMOYO Linux プロジェクト」のネーミングについての解説があります。 [sakura.ne.jp]
必見。
Re:ネーミングについて必見 (スコア:1)
# できすぎ。
Re:ネーミングについて必見 (スコア:0)
ちなみに、ここのドメイン取るとき
******.sakura.ne.jpのところが自由に決められるんだけど
cardcaptor.sakura.ne.jp
kinomoto.sakura.ne.jp
cc.sakura.ne.jp
とかは当然のこと
shinguji,yoshino,matou,tangeなどめぼしいのは
片っ端から取られててたので
私は、かなり苦し紛れに別のキャラにしました。
Re:ネーミングについて必見 (スコア:0)
Re:ネーミングについて必見 (スコア:0)
Re:ネーミングについて必見 (スコア:0)
打鍵タイミングまで見ますか (スコア:1)
鈍い私には突破できそうにありません。
リリースのオリジナル情報 (スコア:1)
tsh
なんで携帯? (スコア:0)
Re:なんで携帯? (スコア:0)
プロトタイプだから
折角入力時間を計るなら(-1:余計なモノ) (スコア:0)
でも出題して、社員の脳活性度をチェックしてみては。
#Ctrl^Cしてしまいそうなので、AC
新しい防御手段 (スコア:0)
(#1038757)> ここに書くのもなんだけど、Xiaolangじゃないのかなあ。
CCさくら第2巻P57を見ましょう。小狼君は SYAORAN なのです。
(#1038846)> 公開鍵認証を使う方式では、公開鍵を盗まれるかもしれません。
ほぇ~。書き間違えた~。(笑)
(#1038860)> はあ。ともよちゃんには脆弱性もないしゼロディもアリエナイよと。
カーネルに脆弱性が無いというのは前提なんでしょうね。
SELinux でも LIDS でも TOMOYO でも Windows でも・・・。
(#1038916)>こんな感じ?
そうです。ありがとうございます。
(#1039013)> # 一度でも認証に失敗したら数秒で発動し、3日間はIPアドレスごと無視されるという...。
それってDHCPみたいな環境だと困りますね。
攻撃者が試行して ban されたIPアドレスがその後正規の利用者に割り当てられたら
正規の利用者でも接続できなくなってしまいます。
「認証に失敗したらアカウントをロックするべきか否か」という話もありますが、
ログイン後に追加認証を行う方式なら最初の認証に失敗しても
アカウントのロックやIPアドレスの ban をしないで大丈夫です。
もっとも、最初から接続元IPアドレスが固定されているなら iptables で
フィルタすればいいのでしょうけど。
(#1039199)> #Ctrl^Cしてしまいそうなので
C-c というのは100マス計算のほうですよね?
追加認証は C-c で回避することはできませんよ。
認証に成功したら新しいプログラム(シェル)を起動するだけですから。
で、ここからが本題です。
SSH サービスを保護する手段はいろいろあるでしょう。
接続元ポート番号による制限をすれば攻撃者に1回も認証をさせないことが可能です。
http://kumaneko-sakura.sblo.jp/article/1275428.html [kumaneko-sakura.sblo.jp]
論文では適用不能と考えられていた scp や sftp に対する適用も
制約が増えるものの適用可能だということが判りました。
http://kumaneko-sakura.sblo.jp/article/1450568.html [kumaneko-sakura.sblo.jp]
今回開発されたプロトタイプのソースではありませんが、
論文発表時に使用したプロトタイプのソースは既に公開されています。
ソースは http://osdn.dl.osdn.jp/tomoyo/21579/ccs-tools-1.2-20060903.tar.gz [osdn.jp] です。
http://kumaneko-sakura.sblo.jp/article/372199.html [kumaneko-sakura.sblo.jp] から始まる
一連の投稿で使い方を紹介しています。
強制アクセス制御が無いと「強制」はできませんが、追加認証の柔軟さを体感できるでしょう。
Re:新しい防御手段 (スコア:1)
長いですねぇ。(笑)
それはともかく、実はセキュスタ2004で今回のリリースに近い状態を実現しています。下記のリンク先にあるレポートをたどっていただけば、リリースの意味が理解しやすいかもしれません。(本当はそこまでしなくてもオリジナルのリリースと図を見てもらえば意味が通じると思うのですが)
http://www11.plala.or.jp/tsh/ss2004.html [plala.or.jp]tsh