vpsおよびクラウドシステムに於けるsshの安全性(仕様に於ける脆弱性)について
■ 問題の原点 まず、世に存在するvpsやクラウドシステムには、基本的には2種類の構成が存在している。このうちコンテナ型と呼ばれる構成では、予め必要とされてるsshやメールなどの基本的な内容が初期段階より構成されており、コンテナを選択するだけですぐにシステムの構築が出来る、手軽さが売りになっている。このコンテナには、予めsshが組み込まれていることが多く、そのため管理者のpasswordがデフォルトで決めうちになっている場合も多い。管理者のpasswordをデフォルトで放置していた場合、外部からの攻撃によって、あっさりと侵入を許してしまうことがある。 本題は、ここからだ。このsshが最初からインストールされている＝ホストキーが最初から入っている＝同じコンテナを使う限りホストキーは変わらない。ということになる。 また、vpsやクラウドシステムが大規模になればなるほど、この傾向は強まり、/16
Improving the security of your SSH private key files — Martin Kleppmann’s blog
Published by Martin Kleppmann on 24 May 2013. Update (July 2015): This post is now rather outdated, and the procedure for modifying your private key files is no longer recommended. A better solution is to use ssh-keygen -o. Ever wondered how those key files in ~/.ssh actually work? How secure are they actually? As you probably do too, I use ssh many times every single day — every git fetch and git
公開SSHサーバの安全性を高める5つの設計 - GeekFactory
出先からサーバをメンテナンスするには、SSHサーバをインターネットに公開する必要があります。SSHはデフォルトではIDとパスワードだけでログインできてしまうため、狙われやすい侵入経路の一つです。 ここではSSHサーバの安全性を高める設計を挙げてみます。 公開するポートを22番から変更する。 他サーバから独立したネットワーク（DMZ）にSSHサーバを配置する。 SSHサーバの表裏にファイアウォールを設置し、裏側を通って他サーバにログインする。 ログインシェルをchroot-jailで実行し、可能なことを制限する。 認証ログを監視する。 定期的にセキュリティアップデートを適用すること、推測されにくいIDやパスワードを使うことは言うまでもありません。地道な運用作業は重要です。 VMにおける実現方式 自宅サーバのようにスペースや静音性に制約がある環境では、独立したサーバを設置するのは困難です。また
Top 20 OpenSSH Server Best Security Practices
OpenSSH is the implementation of the SSH protocol. OpenSSH is recommended for remote login, making backups, remote file transfer via scp or sftp, and much more. SSH is perfect to keep confidentiality and integrity for data exchanged between two networks and systems. However, the main advantage is server authentication, through the use of public key cryptography. From time to time there are rumors
Brian-Holt/server-shield · GitHub
README.md Server Shield v1.0.6 Server Shield is a lightweight method of protecting and hardening your Linux server. It is easy to install, hard to mess up, and makes your server instantly and effortlessly resistant to many basic and advanced attacks. Automatic security updates are enabled by default, including the self-updating of Server Shield. If you are running a modified version of Server Shie
SSH への総当たり攻撃(brute force attack)と防衛 - World Wide Walker
SSH への総当たり攻撃(brute force attack)と防衛 Posted by yoosee on Debian at 2005-11-08 23:42 JST1 SSHに対するブルートフォース攻撃への対策sshd へのパスワード総当たり攻撃は今年の前半くらいから非常に増えていて、「実際に guest や test などのアカウント名を乗っ取られた」と言うケースも実はそこそこの頻度で聞いている。仕事では既に防御スクリプトを仕込んでいるサーバもあるが、無防備なサーバに実際にどれくらいの攻撃が来ているのか、ログを見てみた。2 存在しないユーザへの攻撃sshd へのアクセスが失敗すると、少なくとも FreeBSD や Debian では /var/log/auth.log にメッセージが残る。上が存在しないユーザ、下が存在するユーザへの総当たり攻撃ログの例Nov 8 11:29:47
Main Page - Scponly wiki
What is scponly? scponly is an alternative 'shell' (of sorts) for system administrators who would like to provide access to remote users to both read and write local files without providing any remote execution priviledges. Functionally, it is best described as a wrapper to the tried and true ssh suite of applications. A typical usage of scponly is in creating a semi-public account not unlike the
sshを制限してsftpだけ許可する - GeekFactory
ファイル転送用のアカウントでは、sshを制限してsftpのみ許可したい場合があります。ログインシェルを/sbin/nologinに変更すると、sshだけでなくsftpも制限されてしまいます。そのような場合はsshd_configのForceCommandを使います。 例えば、 # /etc/ssh/sshd_config #... # override default of no subsystems Subsystem sftp /usr/lib64/misc/sftp-server Match User hoge ForceCommand /usr/lib64/misc/sftp-server と書くと、ユーザhogeはsftpしか使えなくなります。sshクライアントから接続しようとしても、セッションがsftp-serverに流れるのでbashは使えません。
OpenSSH 4.9がリリース - chroot環境を正式サポート | エンタープライズ | マイコミジャーナル
The OpenBSD Projectは30日、オープンソースによるSSHプロトコル実装の最新版「OpenSSH 4.9」をリリースした。LinuxやMac OS Xなど、OpenBSD以外のOSを対象とした配布物の最新版 (OpenSSH 4.9p1) も、あわせてリリースされている。 OpenBSD以外のプラットフォーム向けでは約半年ぶりとなる今回のリリースでは、SSHデーモン (sshd) がchrootをサポート。リモートユーザをホームディレクトリより上位の階層にアクセスできないようにするこの機能は、これまでパッチは公開されていたもののOpenSSH本体には取り込まれず、バージョンアップのつど手動でパッチを適用するしかなかったが、今回の正式サポートにより新しい設定項目「ChrootDirectory」で制御可能となった。なお、この機能はOpenBSD向けのみ公開された「OpenSS
第6回 OpenSSHの公開鍵をLDAPで管理 | gihyo.jp
公開鍵管理の概要 読者の皆さんの多くはリモートメンテナンスのために、各サーバでsshデーモンを動作させているはずです。しかしtelnetではなくsshにすればそれだけで安心安全、というわけではありません。共通鍵認証ではそれぞれの通信自体は暗号化されているとはいえ、近年では総当たり攻撃のターゲットとなっているケースも非常に多くセキュリティ的に安心できるものではないためです。皆さんはちゃんとRSAやDSAによる公開鍵認証を利用されていますか？ 公開鍵認証のメリットは、共通鍵認証と比較して、より安全な認証を実現することができる点にあります。その一方、クライアント側には秘密鍵ファイルと多くの場合はパスフレーズが、サーバ側には公開鍵ファイルが必要になるため、デメリットとしてユーザ数が多いとそれらの管理も煩雑になることが挙げられます。 たとえば管理対象のサーバが100台あるとすれば、あるユーザの入社時
ウノウラボ Unoh Labs: 専用サーバを構築するときにまず行う４つの設定
こんばんは、最近寒い夜が続いていて自転車通勤がつらくなってきた naoya です。 ウノウでは、フォト蔵や社内システムなどは、すべて専用サーバを構築して運用をしています。 今日は、専用サーバを構築するときに、僕がウノウで学んだ専用サーバでまず行う４つの設定を紹介します。 なお、今回の設定はすべて Fedora Core 5 をもとにしています。 (1) sudo を使えるようにする sudo コマンドを使えるようにします。sudo コマンドは、別のユーザとしてコマンドを実行できるコマンドです。 sudo コマンドを使えるようにするには、/etc/sudoers に sudo を許可するグループを追加します。次の例は、unoh グループを追加する例です。 %unoh ALL = (ALL) ALL, !/bin/su, /bin/su postgres, /bin/su * postgres
sshguard――OpenSSHを保護するツール | OSDN Magazine
もし辞書を使って力ずくで攻撃されたら――SSHに対するこの種の攻撃は珍しくないため、そう心配する人は多いだろう。しかし、こうした攻撃からSSHを守ってくれる新しいツールsshguardが登場した。まだベータ段階だが、十分に使えそうだ。 TelnetやFTPなどといった第1世代のネットワーク・プロトコルでは、ログイン手順は平文で処理される。したがって、そのセキュア版としてOpenSSHが登場したのは当然だろう。だが、Telnetの代わりにSSHを使っているからといって十分とはいえず、慎重に用いるべき点は同じだ。SSHに使うパスワードが弱いと、辞書を利用した力ずくの攻撃で、パスワードを平文で送ったのと同じくらいやすやすと解読されてしまうからだ。 そのポート22を力ずくの攻撃から保護しようと考え出されたのがsshguardだ。このツールはSSHへのログイン要求を監視し、攻撃があるとそのIPアドレ
SSHのログイン制限を確認しよう
暗号化によるシェルログインが可能なSSH。そのセキュリティが確保される手段を使用していても，設定によっては危ういホールになってしまう可能性がある。 次に挙げる設定は，SSHを利用する上でぜひとも設定しておきたい。 # vi /etc/ssh/sshd_config ........... PermitRootLogin no PermitEmptyPasswords no PasswordAuthentication no AllowUsers hoge CheckHostIP yes 上から3項目は，すべて「no」にしておこう。上から順に，「rootでのログイン手段を許すか」，「パスワードが設定されていないユーザーでのパスワード無しのログインを許すか」，「RSAによる暗号化ログインを必須とするか」である。 AllowUsers行は必須ではないものの，ログインできるユーザーを限定させるため
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Hardening ssh Servers
＠IT：sshでパスワード認証を禁止するには
https://www.unixuser.org/~euske/doc/openssh/jman/