トップページ⇒unix
1001コメント300KB

SSH その7

■ このスレッドは過去ログ倉庫に格納されています
0001名無しさん＠お腹いっぱい。2010/02/16(火) 21:23:37
SSHに関する情報交換のスレッドです。
FAQ、リンク集は >>2-5 あたり。

過去ログ
　Part1：http://pc.2ch.net/unix/kako/976/976497035.html
　Part2：http://pc.2ch.net/unix/kako/1028/10281/1028157825.html
　Part3：http://pc5.2ch.net/unix/kako/1058/10582/1058202104.html
　Part4：http://pc8.2ch.net/test/read.cgi/unix/1102242908/
　Part5：http://pc11.2ch.net/test/read.cgi/unix/1145484540/
　Part6：http://pc12.2ch.net/test/read.cgi/unix/1202782840/
0225名無しさん＠お腹いっぱい。2010/09/21(火) 01:49:39
20MB/sくらいはデルよ
0226名無しさん＠お腹いっぱい。2010/11/12(金) 23:54:21
authorized_keys と authorized_keys2 ってどういう違いがあるの？
バージョンや暗号化方式によって違うらしいけど
なんでそんなことするの？
0227名無しさん＠お腹いっぱい。2010/11/13(土) 00:38:50
authorized_keys に version2 のキー置いても問題なく動いてるけど
0228名無しさん＠お腹いっぱい。2010/11/13(土) 10:01:45
>226
openssh と本家で仕様が違ってる(or 違ってた; 最近の事情は知らない)
0229名無しさん＠お腹いっぱい。2010/11/13(土) 15:32:38
確かに本家とは仕様が違ってる/違ってたけど、authorized_keysとauthorized_keys2って違いじゃないはずだぞ。
0230名無しさん＠お腹いっぱい。2010/11/13(土) 20:43:41
結局authorized_keys2は互換性のために残っているんだっけ？
authorized_keysが使えない条件は何？
0231名無しさん＠お腹いっぱい。2010/11/13(土) 21:48:36
リンクしとけよ
0232名無しさん＠お腹いっぱい。2010/11/13(土) 22:31:54
【新世代】 Windows 7 Part70
ttp://hibari.2ch.net/test/read.cgi/win/1276868266/783

783 名前：名無し~3.EXE[sage] 投稿日：2010/11/10(水) 22:34:10 ID:Rr0vNFYE
Windows 7 クライアントだと Loopback でもポートがかちあって
ssh トンネル越しの Windows 共有 (SMB ove SSH) が自分はできてなかったが
良い解説を見つけてできるようになった

CIFS-over-SSH for Windows Vista/7
ttp://www.nikhef.nl/~janjust/CifsOverSSH/VistaLoopback.html

キーワード:
CIFS over SSH (445/tcp)
Microsoft Loopback Adapter
sc config smb start= demand
netsh interface portproxy add v4tov4
net start smb (後から実行)
445 じゃなく proxy ポートに接続

あとは cygwin の openssh でOK
0233名無しさん＠お腹いっぱい。2010/11/22(月) 21:44:26
鍵認証パスフレーズなしで長いことやってきたが
秘密鍵の保存場所って本気で考えると難しくないか？

普段入るサーバはsudo使えるやつが他にも数人いるし、
会社から提供されたPCもイントラチームにはdomain adminで筒抜け状態。
おいおい、いつ盗まれてもおかしくない状態！！・・・なんだけど
周りには「鍵認証って何？」って人しかいないから助かってるｗ

そもそも会社でパスフレーズなしは無謀？
しかし、パスワード毎回は面倒すぎる。

こういう場合はssh-agentかねやっぱ。
これはこれで面倒そうなんだよな。

皆どうしてるの？
0234名無しさん＠お腹いっぱい。2010/11/22(月) 21:52:07
パスなし鍵でどのホストに繋がるのかが判らないようにしておけばよい
さらに同様の鍵が複数(沢山)あるとセキュリティ効果うｐ
0235名無しさん＠お腹いっぱい。2010/11/22(月) 22:41:50
パスなし鍵をたくさん用意して、ホストごとに変えろってこと？
まあ、時間稼ぎにはなりそうだけど。。。
何百台もあるしなぁ。
0236名無しさん＠お腹いっぱい。2010/11/22(月) 23:33:27
(´-`).｡oO 周囲の人間が信用できないのにどうしてパス無し鍵を使うのだろう
0237名無しさん＠お腹いっぱい。2010/11/23(火) 00:30:37
セキュリティと利便性が相反するのはわかる。
しかし、日々数十回ssh,scpするのに毎回パス入力。。。耐えられん。
だからこそ、安全なパスなし鍵運用を追及したい。
0238名無しさん＠お腹いっぱい。2010/11/23(火) 00:39:49
なんのためにssh-agentがあると思ってるんだ?
0239名無しさん＠お腹いっぱい。2010/11/23(火) 01:08:00
ttp://webos-goodies.jp/archives/50672669.html
他人が root ユーザーとしてログインできるマシンでは ssh-agent は使うべきではありません。
ってのを読んで不安になったんで。
0240名無しさん＠お腹いっぱい。2010/11/23(火) 02:05:03
rootしか見れない場所に置くしかないけど
みんながrootで入れる環境だと意味ない罠
0241名無しさん＠お腹いっぱい。2010/11/23(火) 13:49:11
>>239
パスなし鍵の方がよっぽど危険

0242名無しさん＠お腹いっぱい。2010/11/23(火) 15:34:51
パスなし鍵（複数）をローカルに暗号化して保存しておいて
それらをssh-agentでひとつのパスワードで管理って出来ない？
0243名無しさん＠お腹いっぱい。2010/11/23(火) 17:39:16
> しかし、日々数十回ssh,scpするのに毎回パス入力。。。耐えられん。

こういう意識でいる限り何を言っても無駄だな
0244名無しさん＠お腹いっぱい。2010/11/23(火) 18:13:49
USBメモリに暗号化しておいとく
0245名無しさん＠お腹いっぱい。2010/11/23(火) 18:46:04
っていうか ssh-agent 使ってみれば
「一日一回」で済むってことが分かるのに
0246名無しさん＠お腹いっぱい。2010/11/23(火) 18:52:14
>>243
そこをなんとかｗ
業務委託が切られちゃったから、やらざるを得ないけど、
単調作業が嫌いなので、とにかく楽にしたい。

>>244
暗号化はすでにやってる。truecryptでイメージ保存してて
出社したら、.ssh/にマウントさせてる。
でも、マウントした時点でsudoもってる奴らには見えてしまう。
0247名無しさん＠お腹いっぱい。2010/11/23(火) 18:56:50
パスなしよりは安全だから、ssh-agentにしますわ。
ただ、
ttp://www.gcd.org/blog/2007/07/123/
にもあったけどやっぱ他人がroot使える環境では
安全とは言えないんだよね？
0248名無しさん＠お腹いっぱい。2010/11/23(火) 19:03:24
そんなの当然でしょ。
ssh信頼できないデバイスが信頼できな
0249名無しさん＠お腹いっぱい。2010/11/23(火) 19:06:33
すません、書き込み失敗した。
sshクラアントごと差し替えられたり、
キーロガーしこまれたりできるデバイスだったら
秘密鍵のパスフレーズだって抜けるでしょ。

0250名無しさん＠お腹いっぱい。2010/11/23(火) 19:23:24
そうですよね。。
ってことは俺の環境でパスなし鍵の安全性確保は難しそうだ。
vmwareで解決しそうだけど、禁止だし。。。
厳しいなぁ。
0251名無しさん＠お腹いっぱい。2010/11/23(火) 19:46:02
ん？>>247の引用URLはForwardAgentでの話か。
イントラチーム筒抜けとかいってたからローカルの話の
続きかと思った。この場合は秘密鍵そのものは覗き見できない。

まあ仮にクライアント側で秘密鍵の機密性が守れたとしても
ログイン先sshdに罠を仕込めるようなサーバ環境なら通信内容の
盗聴はできるよ。

とことん防衛するつもりならSSHクライアント／サーバ管理者以外にも
DNSサーバ管理者やIPルータ管理者の警戒もお忘れなく。。。
0252名無しさん＠お腹いっぱい。2010/11/23(火) 22:55:09
>>246
>暗号化はすでにやってる。truecryptでイメージ保存してて
>出社したら、.ssh/にマウントさせてる。
そうじゃなくて使う瞬間だけメモリ上で復号するんだよ
0253名無しさん＠お腹いっぱい。2010/11/23(火) 23:21:57
>>251
なるほど、盗まれることはないってことか。
まあ盗聴は気をつけるしかないかな。
今回は、パスなし秘密鍵はちゃんと管理せよってよく言うけど、
みんなはどうしてるのかなと思っただけだよ。

>>252
使うたびに複合は面倒じゃない？
ちなみにUSBは使えない。
0254名無しさん＠お腹いっぱい。2010/11/24(水) 00:26:21
正直マニュアルくらい読んでからにしてくれ…
0255名無しさん＠お腹いっぱい。2010/11/24(水) 10:28:49
社内の root が信用できないって、
どんな仕事やってんだ？
0256名無しさん＠お腹いっぱい。2010/11/24(水) 11:36:54
仕事じゃない内職だから社内の人を信用しないんじゃないか。
0257名無しさん＠お腹いっぱい。2010/11/24(水) 12:27:16
おまえはクビだ
0258名無しさん＠お腹いっぱい。2010/11/24(水) 12:39:33
お前が信用されてないから他人も信用しないってことか。
0259名無しさん＠お腹いっぱい。2010/11/24(水) 20:52:07
>>255
俺もそれ思ったw
信頼できないやつにroot権限与えてるのが
そもそも一番の問題なんじゃねーか。
それ前提だと何やっても無駄だろう。
0260名無しさん＠お腹いっぱい。2010/11/24(水) 22:15:00
俺も>>256と同意見、見られるとまずいことやってるんじゃないか？
0261名無しさん＠お腹いっぱい。2010/11/25(木) 12:46:55
どこぞのエロ掲示板のおじさんが
「職場でダウンローダセットしてゲットしました〜」
って書いてるようなそういう話じゃね?

もっとヤバい機密の横流しとかならパスワードを
打つくらいのは厭わないだろうし
0262名無しさん＠お腹いっぱい。2010/11/25(木) 21:46:29
うちは外部接続有りの実運用中の機器へのアクセスは
単独作業禁止、パスワードも再監者と確認しながら入力で
毎日他の担当者がアクセス履歴をチェックしてる。
当たり前のことだから別に面倒だとは思わんな
0263名無しさん＠お腹いっぱい。2010/11/25(木) 22:35:41
アクセス履歴が残ると思ってる時点で問題だけどな
02642332010/11/25(木) 22:45:30
なんか、大量レスどもです。
そんな重要作業ではなく、ほとんど監査がらみのログ収集とか
ldap未導入サーバのアカウント一覧取ったりとか、そんな依頼。
サーバ一覧渡されて、scpで取るだけだけど、楽したいじゃない。
とりあえずssh-agentに変えたから、これでパスなし鍵を置きっぱなしよりは
ましになったか。sudo可の奴らは信頼することにする。
0265名無しさん＠お腹いっぱい。2010/11/25(木) 22:55:49
> 1. ssh-agent を使うとパスフレーズ入力省略出来る。
> 2. ssh-agent を普通に使うだけでは便利性が高くない。
> 3. keychain は ssh-agent をもっと便利にしてくれるツール。
> 4. keychain を導入すればパスフレーズ入力が PC 起動につき一回で済む。
> 5. keychain を使えば複数 ssh-agent を起動する必要がなくなる。
0266マーフィ2010/11/28(日) 03:54:00
>>257
Thank you.
0267名無しさん＠お腹いっぱい。2010/11/28(日) 13:30:26
XPを使用しています。
ttp://www.gadgety.net/shin/tips/unix/ssh2.html
のインストール手順で詰んだのですが、スーパーユーザーで作業するにはどのような操作を行えば良いでしょうか。
0268名無しさん＠お腹いっぱい。2010/11/28(日) 14:56:13
su
0269名無しさん＠お腹いっぱい。2010/11/28(日) 15:22:11
XPってWindows XPのこと?
スーパーユーザーって何のことだ?
administratorのことか?

Windowsから別のOSにログインするって話なら
その相手が何でどういう設定になってて
何をやりたいのか書かんと
0270名無しさん＠お腹いっぱい。2010/11/28(日) 23:18:26
"su" is not Super User.
0271名無しさん＠お腹いっぱい。2010/11/28(日) 23:21:34
Substitute User
0272名無しさん＠お腹いっぱい。2010/11/30(火) 13:18:27
switch userだと思ってたｗ
0273名無しさん＠お腹いっぱい。2010/11/30(火) 18:47:41
super
0274名無しさん＠お腹いっぱい。2010/12/02(木) 08:10:56
http://www12.atwiki.jp/linux2ch/pages/86.html#id_e92bb50d
0275名無しさん＠お腹いっぱい。2010/12/02(木) 15:05:36
SSHのスレで延々引っ張るネタじゃないな
0276名無しさん＠お腹いっぱい。2010/12/11(土) 02:57:10
にょろん
0277名無しさん＠お腹いっぱい。2010/12/11(土) 19:10:00
>>265
パスフレーズ入力を何回かすることになってでも、俺は
gpg-agent --enable-ssh-supportの方がいいやｗ
0278名無しさん＠お腹いっぱい。2011/01/22(土) 11:01:24
ssh brute force attacksに対する防御で、
OpenSSHのsshdで同一ホストからInvalied userなログイン要求があった場合に
外部プログラムを起動したいんだけど、何か方法ある?

maxlogins.plのようにsyslogを読む方法はローカルなユーザがlogger使って
悪戯できるので、イヤです。
0279名無しさん＠お腹いっぱい。2011/01/23(日) 00:34:30
>同一ホストからInvalied userなログイン要求があった

現状これを把握するには log 見るしかないんじゃない？
0280名無しさん＠お腹いっぱい。2011/01/23(日) 00:59:47
>>278
ソースいじるしかないんじゃね？
その程度ならすぐ追加できそう
0281名無しさん＠お腹いっぱい。2011/01/23(日) 01:34:58
>>278
swatchかsyslog-ngあたりを使うのが普通では

syslogを読む、ってのはよく分からんが
syslogdが出力したlogファイルを読む、という意味か?
少なくとも後者なら「出力」ではなく「入力」に対応して
外部コマンド起動させることはできるよ
syslogdの置き換えだから

俺はsyslog-ngで
「同一ホストから1分間に3回ログイン失敗したら30分遮断」
なスクリプトを起動させてる
以前はswatch使ってたけど、時々変な挙動起こしてたんでやめた
0282名無しさん＠お腹いっぱい。2011/01/23(日) 01:47:03
> syslogを読む
syslog.confでパイプすることも含みます。

ローカルユーザーがloggerで悪戯できるということは、侵入者が
これを悪用して管理者のログインを邪魔することが可能になるの
で使いたくないのです。
(侵入されたときに制御を奪い返せなくなる)
0283名無しさん＠お腹いっぱい。2011/01/23(日) 01:51:22
あ、logger使って云々とあるから「出力」だけの話じゃねーのか。
と書こうとしたら既にw

sshdの設定変えてログ出力を非標準のfacilityに変えちゃえば
ルート権限持ってないユーザには分からんだろう。
そもそもそんな馬鹿にローカルから使わせるのがいけないんじゃね?
とも思うが。
0284名無しさん＠お腹いっぱい。2011/01/23(日) 02:26:50
> ローカルユーザーがloggerで悪戯できるということは、侵入者が
> これを悪用して

んんん??
馬鹿ユーザじゃなくて「侵入者」がローカルで操作するの?
「ローカル」ってのはリモートではなく実機のコンソールでの操作って意味だよね?
どういう状況を想定しているのかイマイチ分からない…

実機を直接いじれる侵入者(あるいはその協力者)を想定するんじゃ
24h常駐ガードマン雇う等の物理的なセキュリティを厳重にするしか
根本対策にならんように思えるが
0285名無しさん＠お腹いっぱい。2011/01/23(日) 02:34:35
侵入者(あなたはその協力者)

に見えた
頭腐って来てるかも・・・
0286名無しさん＠お腹いっぱい。2011/01/23(日) 02:53:18
> ssh brute force attacksに対する防御で、

防御ならパスワード認証不可にすれば解決では。
色々複雑な状況考えてる一方でノーガードに近いパスワード認証前提というのがチグハグに見える。
0287名無しさん＠お腹いっぱい。2011/01/23(日) 06:57:23
ログがうざいんぼるとだろ
0288名無しさん＠お腹いっぱい。2011/01/23(日) 08:53:42
制御取り返すなんて、一度侵入された時点でアウトだろ
0289名無しさん＠お腹いっぱい。2011/01/23(日) 12:27:56
pam_access.soとpam_tally2.so参考にPAMモジュール自作
0290名無しさん＠お腹いっぱい。2011/01/23(日) 21:15:19
>>284
侵入されて任意のコマンド実行可能な状態になったことをローカルユーザと
表現しました。

>>286
sshは公開鍵認証だけです。その上で侵入された場合を想定しています。

>>288
当該サーバが地理的に離れているので、侵入されたことが判明したら、
到着する前にシャットダウンできる備えはしておきたいのです。
0291名無しさん＠お腹いっぱい。2011/01/23(日) 21:25:22
>>290
侵入された時点で物理的に電源を切る以外何をやっても無駄。
そこまで心配するならSELinuxなどを使いなよ。
0292名無しさん＠お腹いっぱい。2011/01/23(日) 21:46:08
>>290
侵入の証跡取るためにはシャットダウンもよろしくないんだよね
うちだったら緊急時は接続してるSW側でport落とすかな
(そして俺が侵入者なら無通信になったらファイル消しまくるように
仕掛けるだろうｗ)
0293名無しさん＠お腹いっぱい。2011/01/23(日) 22:49:31
>>291
> 侵入された時点で物理的に電源を切る以外何をやっても無駄。
侵入されても、rootを取られてなければ奪還の可能性はあります。
たとえrootを取られても、ログインできればシャットダウン出来る
可能性はありますが、ログインできなければその可能性は0ですよね。

>>292
> 侵入の証跡取るためにはシャットダウンもよろしくないんだよね
放置するよりはシャットダウンを選びます。踏み台にされて犯罪に
使われたりしたら面倒ですから。

> うちだったら緊急時は接続してるSW側でport落とすかな
零細なんでリモートで落とぜるSWは無理です。
0294名無しさん＠お腹いっぱい。2011/01/23(日) 23:19:09
>>290
> sshは公開鍵認証だけです。その上で侵入された場合を想定しています。

どういう状況で「その上で侵入」が可能になるのか説明plz

・サーバは遠隔地にある……これは普通
・sshは公開鍵認証のみである……brute forceで破られる心配ゼロ
・それでも、もし入られたら制御を奪われる恐れがある……????

前提がそもそも成り立ってないでしょ。
公開鍵認証使っている以上、秘密鍵が漏洩しない限りsshでの侵入はない、というのが通常の前提。
それを突破してくるｽｰﾊﾟｰﾊｶｰを相手と想定してるなら、何やっても無駄だよ。
君の力の及ぶ相手ではないからあきらめろ、としか。
0295名無しさん＠お腹いっぱい。2011/01/24(月) 00:01:01
秘密鍵まで公開してるとか鍵長4bitとか
0296名無しさん＠お腹いっぱい。2011/01/24(月) 00:05:05
> どういう状況で「その上で侵入」が可能になるのか説明plz
sshdのバグ、httpdとか他の経路。クライアントへの攻撃。
0297名無しさん＠お腹いっぱい。2011/01/24(月) 00:08:19
Debianのウンコパッチが当たった状態で作った公開鍵もヤバイんだよな。

ま、それはともかく対策が過剰な気はする。
ipfw/iptablesなどで接続元を絞るとか、別のレイヤでの対策を考えるべき。
0298名無しさん＠お腹いっぱい。2011/01/24(月) 00:36:23
接続元はtcp wrapperでjp限定に絞ってあります。
jpからの攻撃に対する対策として、maxlogins.plを使おうとしたけど、
「待てよ、ログイン出来なくされる」と思い直しての質問です。
0299名無しさん＠お腹いっぱい。2011/01/24(月) 00:38:13
>>298
tcp wrapperで逆引きを使うとか、10年前の対策だな。
0300名無しさん＠お腹いっぱい。2011/01/24(月) 00:48:41
他にjpで絞る方法ありますか?
0301名無しさん＠お腹いっぱい。2011/01/24(月) 00:50:15
パケットフィルタはpfです。
0302名無しさん＠お腹いっぱい。2011/01/24(月) 01:19:40
いい加減スレ違いじゃないか?
全然sshの話じゃなくなってるぞ
「httpdとか他の経路」ってのは何なんだよw
0303名無しさん＠お腹いっぱい。2011/01/24(月) 01:48:10
>>298
> jpからの攻撃に対する対策として、maxlogins.plを使おうとしたけど、
> 「待てよ、ログイン出来なくされる」と思い直しての質問です。

「ある特定の条件に関しては遮断を行わない」ようなスクリプトにしとけばいいだけなんじゃないの?
管理者が直近のログインに使ったIPアドレスは除外する、とか
そこまでいろんなパターン考えてるわりに他人が作ったそのまま使うの前提ってのがよく分からん
自分に都合がいいのを自分で作りなよ
0304名無しさん＠お腹いっぱい。2011/01/24(月) 01:58:37
つか途中から>>278と質問が変わっとる
brute forceの話はどこへ行った? w
OSが何かも分からんし前提条件も途中で変わるのでは話が
0305名無しさん＠お腹いっぱい。2011/01/24(月) 08:09:36
質問者が侵入されroot盗られたというわけ
0306名無しさん＠お腹いっぱい。2011/01/24(月) 09:11:29
>>303
> 「ある特定の条件に関しては遮断を行わない」ようなスクリプトにしとけばいいだけなんじゃないの?
> 管理者が直近のログインに使ったIPアドレスは除外する、とか
自分の利用条件に合う方法が思いつきません。詳細を説明するのも面倒だし、
全部を網羅できず、条件後出しになる可能性が高いので、スクリプトの改造
に関する話題は、これ以上はやめます。
加えて、メッセージの全部を偽造可能なので、それを見破るのも面倒。

>>304
sshdに対する攻撃は
1) ユーザ名を辞書攻撃で得る。
2) そのユーザ名に対してパスワードを辞書攻撃。
という手順です。
1)の段階で検出できれば、2)が(sshdの穴をついて)公開鍵認証を突破する手法に
進化した場合にも防御することが可能です。
1)の段階でsshdの穴をつつかれる可能性は残りますが、対策する方がセキュア。

まとめます
・maxlogins.plに類する、syslogdに送られる情報を元に、sshdへの攻撃を防御する
　手法は非特権ユーザがサービス停止攻撃を実行可能。
・これに代わる確立された方法は現在のところ無し。
0307名無しさん＠お腹いっぱい。2011/01/24(月) 09:31:46
>>306
syslogdにネットワークからメッセージ送れますね。(設定されてれば)
しかも(UDPなので)IPアドレスも偽造できる。
0308名無しさん＠お腹いっぱい。2011/01/24(月) 14:08:18
ipfw/iptablesからキックして、syslogを参照すれば良いだけじゃないんかい？
まあ、多少作り込みは必要だろうけどそんなに難しい事だとは思わんけど。
0309名無しさん＠お腹いっぱい。2011/01/24(月) 15:07:03
それよりも、syslogd改造してメッセージ送信元のuid取ってくるのが
手っ取り早くて確実かと思いました。(solarisでいう)

で、それをsyslog-ngに組み込もうとしたらsysutils/syslog-ng*がコ
ンパイルできねーでやんの。(事情により今すぐportsを最新版にできない)
0310名無しさん＠お腹いっぱい。2011/01/24(月) 15:09:01
> (solarisでいう)
ゴミが残りました。気にしないでください。
0311名無しさん＠お腹いっぱい。2011/01/24(月) 15:17:26
### /etc/pam.d/sshd
auth sufficient pam_unix.so nullok try_first_pass
auth sufficient pam_exec.so /sbin/log_and_deny.sh

### /sbin/log_and_deny.sh
#!/bin/sh
x=/var/run/sshd-blacklist-$PAM_USER-$PAM_RHOST
if [ -f $x ] ; then
shutdown now $x
else
touch $x
fi
exit 1
0312名無しさん＠お腹いっぱい。2011/01/24(月) 18:22:16
>>311
わろうた
0313名無しさん＠お腹いっぱい。2011/01/24(月) 18:29:21
まぁどういう方法でもいいけど、プログラム実行はCPUやディスクI/Oのコストが高いから、ヘタするとそれ自身がDoSになる可能性があるので、気をつけてな。
0314名無しさん＠お腹いっぱい。2011/01/25(火) 00:23:01
>>306
> sshdに対する攻撃は
> 1) ユーザ名を辞書攻撃で得る。
> 2) そのユーザ名に対してパスワードを辞書攻撃。
> という手順です。
> 1)の段階で検出できれば、2)が(sshdの穴をついて)公開鍵認証を突破する手法に

1)の段階ではまだ突破されてないんだからloggerでどうのこうのってのは起こらない。
そして「1)の段階で検出」は既知の方法で十分対応可能。
1)の段階で「完全に遮断」すりゃその先の話は「まず起こり得ない物語」でしかない。
「まず起こり得ない物語」のために必死に対策打つのは
「まったく価値がない」とは言わんが、ちょいと馬鹿げてないか?
傍目には「空が落ちてきたらどうしよう」って悩んでる人と変わらんように見える。

大丈夫。
「公開鍵認証を突破する手法」とやらが広まる頃には、それに対するパッチもちゃんと出てるよw
0315名無しさん＠お腹いっぱい。2011/01/25(火) 00:30:28
>>314
> 1)の段階ではまだ突破されてないんだからloggerでどうのこうのってのは起こらない。
別経路からの侵入を想定と書いた。何度も書かせないでよ。面倒だな。
0316名無しさん＠お腹いっぱい。2011/01/25(火) 01:57:00
>>315
どれがお前さんの書き込みだか他人のチャチャだか分からんよ
名前欄に何も入れてない上にこの板はIDも出ないし
続けたいならコテハンにしたら?
本来なら「もっとふさわしいスレ」に移動すべきだろうと思うけど
0317名無しさん＠お腹いっぱい。2011/01/25(火) 02:17:43
もう面倒だから
「自分のアカウントがログイン不可にされてたら問答無用でネットワーク断」
になるように設定しとけば?
手法はいろいろ考えられると思うが
0318名無しさん＠お腹いっぱい。2011/01/25(火) 23:50:18
>>317
却下です。理由は… 面倒くさいから上の方読んで。
0319名無しさん＠お腹いっぱい。2011/01/26(水) 18:08:54
鍵認証のみで十分じゃん
0320名無しさん＠お腹いっぱい。2011/01/26(水) 18:18:28
> maxlogins.plのようにsyslogを読む方法はローカルなユーザがlogger使って
> 悪戯できるので、イヤです。

侵入者にルート権限を奪われていない状況で、これって本当に可能なんでしょうか?
管理者のユーザ名も使用しているIPアドレスも分からない状態ですよね?
もちろん「無差別に全部塞ぐ」は簡単だけど自力では「開け直す」ができないんだから
意味がないような気がするし。
0321名無しさん＠お腹いっぱい。2011/01/26(水) 18:19:34
それ以前に、踏み台等にすることを考えて侵入した場合
侵入していることが管理者に気づかれないようにするのが普通だと思うのだけど。

管理者を締め出すようなことしたら普通はすぐに対策取られちゃいますよね。
直接コンソール操作して。
苦労して侵入したのに、明かに「侵入してますよ〜」って言いふらすような
馬鹿なことをわざわざするかな。
0322名無しさん＠お腹いっぱい。2011/01/26(水) 20:06:18
>>318
で、結局のところどうするんだ？これでもまだ「自分の望む答えが出てない」と言うなら、
おそらく自分で方向性決められないので素直に鍵認証にしとけ。
0323名無しさん＠お腹いっぱい。2011/01/26(水) 20:43:24
>>320-321
他ユーザのログイン記録の管理は普通ルーズですよ。lastなどでわかる場合が多い。
maxlogins.plはホスト毎にアクセス制御なので、ユーザ名は不要ですね。

>>322
面倒だから上の方読んで。
0324名無しさん＠お腹いっぱい。2011/01/26(水) 21:40:13
>>322
やっぱりキミ頭弱いそうだから説明してあげる。
>>309(syslogd改造)が現在の結論。
0325名無しさん＠お腹いっぱい。2011/01/26(水) 22:04:55
>>324
全然結論になってないんだけど(笑)。
したり顔で言われたくないなぁ、馬鹿には。
■ このスレッドは過去ログ倉庫に格納されています