人力検索はてな
ﾓﾊﾞｲﾙ版を表示しています｡PC版はこちら
i-mobile
SSHのｸﾗｲｱﾝﾄ制限について

SSHｻｰﾊﾞを運用しており､特定のｸﾗｲｱﾝﾄﾎｽﾄにのみSSHの機能を提供しようとしています｡SSHｻｰﾊﾞはOpenSSH 5.9です｡現在､以下の制限を設けています｡
* 公開鍵認証のみ許可(ｸﾗｲｱﾝﾄﾎｽﾄで作成した公開鍵をSSHｻｰﾊﾞに登録)
* ｸﾗｲｱﾝﾄﾎｽﾄのIPを/etc/hosts.allowやiptablesで制限

この構成上で､以下の2点について､お教えいただければと思います｡
(1) さらにｾｷｭﾘﾃｨを高める方法がもしあれば(MACｱﾄﾞﾚｽで制限するなど)
(2) ｸﾗｲｱﾝﾄﾎｽﾄがDHCPでIPを設定している場合､IP制限をどのように代替すればよいか

よろしくお願い致します｡
●質問者: takihiro
●ｶﾃｺﾞﾘ:ｺﾝﾋﾟｭｰﾀ ｲﾝﾀｰﾈｯﾄ
○ 状態 :終了
└ 回答数 : 3/3件
▽最新の回答へ
▽1 ● kodairabase
●20ﾎﾟｲﾝﾄ

(1) さらにｾｷｭﾘﾃｨを高める方法がもしあれば

ﾜﾝﾀｲﾑﾊﾟｽﾜｰﾄﾞにしてはどうでしょう｡
OpenSSHにはChallengeResponseAuthenticationｵﾌﾟｼｮﾝがあります｡

(2) ｸﾗｲｱﾝﾄﾎｽﾄがDHCPでIPを設定している場合､IP制限をどのように代替すればよいか

なりすましを排除したいなら､そもそもDHCPでIPｱﾄﾞﾚｽを取得するようなｸﾗｲｱﾝﾄを接続すべきでは無いと思います｡

takihiroさんのｺﾒﾝﾄ
ご回答ありがとうございます｡ (1)について､公開鍵認証のみの運用のため､記載頂いたｵﾌﾟｼｮﾝはnoにしておりました｡ (2)について､ご指摘ありがとうございます｡ただ､運用上､DHCPでIPを取得するｸﾗｲｱﾝﾄから接続することもありますので､できる範囲でｾｷｭﾘﾃｨを高めたいと考えています｡
▽2 ● y-kawaz
●140ﾎﾟｲﾝﾄ

質問内容から察するに同一LAN内からのｱｸｾｽ制限ですね？
であればMACｱﾄﾞﾚｽは偽装できますしIPｱﾄﾞﾚｽも変更できるのでそれで制限をかけるのは本質的には余り意味が無いかもしれません｡

それよりもまず基本は公開鍵認証用の各人の秘密鍵をきちんと守ることでしょうね｡
鍵の運用ﾎﾟﾘｼｰとして､ﾊﾟｽﾌﾚｰｽﾞは必ず設定するとか､鍵長は長め(4096ﾋﾞｯﾄ以上)にするなどのﾙｰﾙを作って定期的に監査するのが有効だと思います｡

ｻｰﾊﾞ側でできることとしてはProtocolは2のみ(今時はﾃﾞﾌｫﾙﾄがこうだと思う)､ﾊﾟｽﾜｰﾄﾞ認証は無効にする｡
あとは､ｳｨﾙｽなどによる内部からの自動攻撃の対策としてはﾎﾟｰﾄ番号をﾃﾞﾌｫﾙﾄの22以外にするのも意外に有効だったりします｡

あと更に基本的なことですが鍵付きの部屋やﾗｯｸ内におくことによる物理的なｱｸｾｽ制限は必須ですね｡
ｻｰﾊﾞへの物理的な接触ができたらrootﾛｸﾞｲﾝも簡単だしｻｰﾊﾞごとHDDを盗むことも簡単で､全ての対策が無意味になりますから｡

takihiroさんのｺﾒﾝﾄ
ご回答ありがとうございます｡ 同一LANからではなく､ｲﾝﾀｰﾈｯﾄ上のでSSHｻｰﾊﾞについての質問でした｡SSHｻｰﾊﾞのﾄﾞﾒｲﾝ登録はせず､ｸﾗｲｱﾝﾄﾎｽﾄのみにSSHｻｰﾊﾞのIPを通知して運用しています｡ 鍵の運用ﾎﾟﾘｼｰ､SSHのﾌﾟﾛﾄｺﾙ制限､ﾎﾟｰﾄ番号変更について､参考にさせて頂きます｡ありがとうございます｡
y-kawazさんのｺﾒﾝﾄ
ｸﾞﾛｰﾊﾞﾙIPが動的になるのであれば､そのISPのIPｱﾄﾞﾚｽ範囲を大体ﾈｯﾄﾏｽｸで指定して制限すればよいかと｡ISP側の都合でIP帯が変わる可能性はありますがそこは運用でのりきると割りきるくらいかな｡ DNSの逆引きでの制限はやめたほうが良いですね｡DNSの逆引きは誰でも好きなﾎｽﾄ名を名のれますから｡
JULYさんのｺﾒﾝﾄ
>DNSの逆引きは誰でも好きなﾎｽﾄ名を名のれますから｡ 逆引きの結果が当てにならないのは事実ですが､｢誰でも｣というのは違和感があります｡ DNS ｷｬｯｼｭﾎﾟｲｽﾞﾆﾝｸﾞやｸﾗｲｱﾝﾄの hosts ﾌｧｲﾙの書き換え､参照先 DNS ｻｰﾊﾞを悪意のあるｻｰﾊﾞへ向ける､といった､｢参照する側の問題｣が無い限り､DNS の逆引きの結果を設定できるのは､その IP ｱﾄﾞﾚｽの逆引きｿﾞｰﾝに関して､権威ｻｰﾊﾞを持っている人だけです｡通常であれば､ISP や､ISP から固定 IP の割り当てを受けている組織で､｢誰でも｣と言える訳ではありません｡
takihiroさんのｺﾒﾝﾄ
追加のご回答ありがとうございます｡ やはりIPｱﾄﾞﾚｽ範囲での制限になってしまうのですね｡単一ﾎｽﾄに制限できる方法があれば…と思っておりました｡ DNSの逆引き制限とはhosts.allowやPAMでの制限のことで合っていますでしょうか｡動的IPでのﾄﾞﾒｲﾝ制限は､DNSのｷｬｯｼｭの影響を受けないか､心配な気がします｡ DNSのｾｷｭﾘﾃｨについても､解説頂きありがとうございました｡
y-kawazさんのｺﾒﾝﾄ
> 逆引きの結果が当てにならないのは事実ですが､｢誰でも｣というのは違和感があります｡ > その IP ｱﾄﾞﾚｽの逆引きｿﾞｰﾝに関して､権威ｻｰﾊﾞを持っている人だけです｡ 逆引きのｿﾞｰﾝ転送を行なってくれるISPは普通にありまし､正引きのAﾚｺｰﾄﾞ設定の確認もせずに逆引きの名前を設定させてくれる緩いVPSやﾚﾝﾀﾙｻｰﾊﾞも実際に存在します｡ 月数百円?数千円程度で固定IPと逆引き設定が手に入れられる今の世の中では十分に｢誰でも｣といえるんじゃないでしょうか？
y-kawazさんのｺﾒﾝﾄ
まぁ､実際にはそれなりにお金もかかって面倒なので普通の人はそこまでしないと思うので､それなりの制限としては使えはします｡なので､ > DNSの逆引きでの制限はやめたほうが良いですね｡ というのは言い過ぎで､それに頼り切らない方が良いです､くらいのﾆｭｱﾝｽです｡ でもさらに言えばそもそも動的IPのｱﾄﾞﾚｽ範囲での制限というのも､許可されている人と同じISPに加入すれば同じIPｱﾄﾞﾚｽ帯のIPを自分が使うことができてしまう､というとても単純な穴があります｡ 固定IPをくれるISPなんていくらでもあるので､ｾｷｭﾘﾃｨを考えるなら接続元に固定IPを取得してもらうのが一番でしょうね｡
JULYさんのｺﾒﾝﾄ
>月数百円?数千円程度で固定IPと逆引き設定が手に入れられる >今の世の中では十分に｢誰でも｣といえるんじゃないでしょうか？ 私が｢誰でも｣という言葉に違和感を感じたのは､｢任意の IP ｱﾄﾞﾚｽに対して｣誰もが逆引きを設定出来る､という印象にならないかなぁ､と思った次第です｡ ... という事を､y-kawaz のｺﾒﾝﾄで認識出来ました(^^;｡ 例え数百円でも､ある IP ｱﾄﾞﾚｽを｢買った｣状態であれば､その IP ｱﾄﾞﾚｽに対する上位ｿﾞｰﾝの持ち主が許可すれば､逆引きを設定出来ますが､例えば､19.194.106.59.in-addr.arpa の PTR ﾚｺｰﾄﾞを､全くの第3者が設定出来る訳ではありません(ちなみに､今､www.hatena.ne.jp を正引きした結果の IP です｡で､この逆引きには PTR ﾚｺｰﾄﾞは設定されていませんでした)｡ 今､ﾎﾟｲﾝﾄになっているのが｢つないで来た相手の IP ｱﾄﾞﾚｽが､本当に想定しているﾕｰｻﾞの物か？｣という点なので､｢全く別な人が､その人が固定的に使っている IP ｱﾄﾞﾚｽにの逆引きに､同じﾄﾞﾒｲﾝ名を設定する事が可能なので当てにならない｣という点で､y-kawaz さんの言う通りです｡ 私が違和感を感じたのは､より広い意味で｢逆引きなんて無法地帯で､誰でも好き勝手に出来ちゃうんだから｣という雰囲気に読んでしまったためでした｡ 逆引きを使うなら､UseDns を yes にすれば､逆引きして得られたﾄﾞﾒｲﾝ名を正引きして得られた IP ｱﾄﾞﾚｽと､元の IP ｱﾄﾞﾚｽが合っているかを確認する､という動きになるので､y-kawaz さんが心配されているｹｰｽは､これで防げる事になります｡もし､それでもなお､つないで来た相手が第3者だったとしたら､本来の持ち主の DNS ｻｰﾊﾞがやられちゃっていることになります｡ http://www.unixuser.org/~euske/doc/openssh/jman/sshd_config.html
▽3 ● JULY
●140ﾎﾟｲﾝﾄ ﾍﾞｽﾄｱﾝｻｰ

あと思いつくのは AllowUsers ぐらいかな｡

順番に考えていきましょう｡

まず､接続元となるｸﾗｲｱﾝﾄを制限したい､ということであれば､すでに実践されているようですが､ｸﾗｲｱﾝﾄ側の IP ｱﾄﾞﾚｽが特定できないのであれば､y-kawaz さんの回答にあるように､ある程度大きな単位で許可せざるを得ません｡

たとえば､geoip を使って､国外からの接続を拒否する､というのをやっている例があります｡
GeoIPでSSHに接続できる国を制限する - ts1の日記

ﾎﾟｰﾄ番号をﾃﾞﾌｫﾙﾄの物から変える､というのも一定の効果はあります｡ただし､takihiro さんが誰かに狙われていない場合(^^;｡多くのﾎﾟｰﾄｽｷｬﾝは､何か使えるﾎｽﾄがないかを探すだけなので､22 番以外で ssh ｻｰﾊﾞが動いていても素通りされます｡ただ､もし本当に狙われている場合だと､ある TCP ﾎﾟｰﾄが開いている事は分かる訳ですから､そのﾎﾟｰﾄで何が動いているのかを詮索されると､SSH ｻｰﾊﾞである事が分かってしまう事になります｡ﾎﾟｰﾄ番号を変更するのは､あくまでも｢目くらまし｣としての効果です｡

あとは､そのﾕｰｻﾞが信用できるか､ですが､ﾕｰｻﾞの認証方式として公開鍵認証のみであれば､後は運用が大切､というは y-kawaz さんと同意見です｡

で､公開鍵認証にﾌﾟﾗｽαするとしたら､PermitRootLogin が No であることは当然として､AllowUsers で制限しておけば､不用意にﾕｰｻﾞが認証可能な状態になってしまう事を防げます｡

あと､公開鍵認証のみにしている場合では問題ないのですが､ssh ｻｰﾊﾞが動いている､と分かると､ﾌﾞﾙｰﾄﾌｫｰｽｱﾀｯｸがしつこく行われます｡Red Hat 系であれば､/var/log/secure に､その記録が大量に残ります｡このﾛｸﾞは､ﾊﾟｽﾜｰﾄﾞ認証を無効にしていても出力されます､で､接続の頻度を iptables で制限する事が可能です｡

-A INPUT -m state --state NEW -m tcp -p tcp --dport 22 -m hashlimit --hashlimit-name ssh --hashlimit-mode srcip --hashlimit 20/hour --hashlimit-burst 5 --hashlimit-htable-expire 3600000 -j ACCEPT

上記の設定は､同一ﾎｽﾄから1時間に 20 回､一時的には連続5回までで､制限に達した場合､3,600,000 msec = 1時間､接続を受け付けなくなります｡ﾊﾟﾗﾒｰﾀは用途や運用状況によって変更する必要があると思いますが､こうしておくと､5回試しただけで､後はあきらめてくれるようになります｡

takihiroさんのｺﾒﾝﾄ
ご回答､ありがとうございました｡ GeoIPや/etc/hosts.allowでのaclexec設定など､初めて知りました｡ありがとうございます｡ ﾎﾟｰﾄ番号については､nmapなどで簡単に検出できることは存じておりました｡ ﾌﾞﾙｰﾄﾌｫｰｽｱﾀｯｸの対応についても､ﾃﾞｨｽｸ溢れを防ぐのに重要そうですね｡参考にさせて頂きます｡ありがとうございます｡
関連質問
●質問をもっと探す●

0.人力検索はてなﾄｯﾌﾟ
8.このﾍﾟｰｼﾞを友達に紹介
9.このﾍﾟｰｼﾞの先頭へ
□対応機種一覧
□お問い合わせ
□ﾍﾙﾌﾟ/お知らせ
□ﾛｸﾞｲﾝ
□無料ﾕｰｻﾞｰ登録
□はてなﾄｯﾌﾟ