前回に続き、今回も Cisco Switch のお話です。前回は、何の設定もないところからスイッチとして動かすところまでをご紹介しました。スイッチ単体のネットワークではほとんどすることはありません。スイッチとしては動くようになっていますが、セキュリティに関しては何も行っていません。そこで、今回はデバイスローカルでのセキュリティを高めてゆきましょう。こちらがデバイスへのアクセス関連の設定部分です。設定をきれいさっぱりリセットしたので、デフォルトだと思います。この状態はと言えば、
AAA
- コンソール: パスワードなしでログイン可
- vty 0-4: デフォルトのトランスポートプロトコルでログイン可
- vty 5-15: デフォルトのトランスポートプロトコルでログイン可
AAA を新しい形態に切り替えます。一旦切り替えると、基本的に元に戻ることはできません。
スイッチに telnet でログインしてみましょう。telnet で接続すると、ユーザ名を聞いてきます。スイッチローカルに誰もユーザは作っていないので、ログインできません。
AAA for vty access
そこで、aaa コマンドでどのログイン方法を試して行くかを指定します。
vty ラインにパスワードをセットしますので、それを使用するようにします。aaa コマンドの引数には local や group、enable などを全てとることができます。複数指定した場合は最初のオプションから利用可能か調べてゆき、利用可能なものを使用して認証を行います。よく誤解するのは、最初のオプションが失敗したときに2つ目のオプションが使われるのではないかと考えられることがあるのですが、１つ目の認証が失敗したら、それで終わりです。２つ目のオプションは試しません。ですので、オプションを “line enable” と指定したら、vty ラインにセットしたパスワードでの認証のみが試されます。しかし、このラインパスワードを消してしまうと、ラインパスワードでの認証は行われず、enable パスワードでの認証のみが試されます。
では telnet で期待通り動くか試してみます。相変わらず、ユーザ名を聞いてきます。
実は vty ラインの最初のセッション番号は 0 なので、0 から 4 までが抜け落ちています。0-4 にも 5-15 同様の設定を入れます。因みに line vty 0 15 と指定しても、0-4 と 5-15 に分かれて保存されます。
では改めて telnet で確かめてみましょう。今回はパスワードだけの入力を求められました。aaa コマンドで指定したように、line パスワードを入力してみます。
AAA for enable access
認証にパスして、プロンプトが見えました。ただ、管理者レベルの権限を得ることはできません。
コンソールと異なり、パスワードなしで管理者レベルの権限を得ることはできなくなっています。ですので、enable パスワードをセットします。
コンソールでセットした enable パスワードを使用して、telnet で管理者権限を得てみましょう。
AAA for console access
これで、ネットワークからも管理者権限を得ることができることが確認されました。次はコンソールの設定を変えてゆきましょう。コンソールの設定をいじって管理者になれなくなってしまうと、ネットワークからの接続だけが頼りです 🙂
コンソールの設定も空っぽのままですので、vty ラインと同じパスワードをセットしてみましょう。そして、ログイン方式 “console” を作成して、コンソールラインの認証の指定を “console” とします。
一旦ログアウトしてログインしなおします。今回はパスワードを聞かれます。aaa コマンドで指定した通り、ラインパスワードを入力します。期待通りの動作です。enable コマンドも期待通り動きます。
これで、コンソールもネットワークも最低限のセキュリティの確保ができましたので、一旦設定を保存しておきます。
enabling ssh access
続いて、ssh の設定を行います。telnet では全てがクリアテキストで送られてしまいますので、暗号化できる ssh の使用が推奨されます。まず、ssh で接続してみましょう。
ssh のハンドシェークに問題があるようです。共通の鍵交換方式が無いようなので、FreeBSD 側の ssh クライアントの設定に cisco デバイスで使用できる方式を追加します。/etc/ssh/ssh_config を変更しても構わないのですが、一般のユーザには通常の ssh を使用してもらいたいので、個人的な設定のみに追加します。
初めて接続する ssh サーバなので、フィンガープリントを見たことが無いとメッセージを表示しています。問題はないので、受け付けます。
接続のプロトコルが telnet から ssh に変わっただけなので、telnet で使用したパスワードをそのまま入力します。telnet 接続の設定時に、ラインパスワードの入力を期待するように aaa コマンドを変更しました。ssh と共通です。
enable パスワードも受け付けてくれたので、設定的にはこれで OK のはずです。AAA 関係の設定はこんな感じです。
disabling telnet access
これで ssh 接続も確認できましたので、telnet の利用は停止しておき、ssh のみで CLI の利用ができるようにします。
確認です。telnet で接続してみます。期待通りです。
問題ないはずですが、ssh も確認しておきます。つながらないような間抜けでないことも確認です 🙂
disabling web access
最後に初心者向けに WEB のインターフェースも提供されており、デフォルトで利用できるようになっています。
初心者ではないので止めておきます 🙂
これらも止まったことを確認しておきます。
unknown tcp/udp ports
最後に、スイッチに対しての tcp/udp 接続を確認しておきます。syslog の 514 は既知です。ntp の 123 も既知です。見慣れぬポートは 10002 と 2228 ですが、スイッチのマニュアルを読み漁ると記述がありました。2228 は L2 traceroute に使われるそうです。10002 はクラスタ構成で使用されるそうです。
マニュアルを読む限り、ポート 2228 を閉じることはできなさそうです。ポート 10002 はクラスタを止めればなくなるそうです。
これで、怪しそうな口は開いていませんので OK 牧場！です 🙂
設定を保存して終了です。
rental server
元々ワードプレスを使い始めたのは家庭内の FreeBSD 上に作った日記サーバでした。自分の FreeBSD に必要な変更を root 権限で行えるので、何のストレスもなく日記のページが増えてきたのですが、日記はあくまで日記、あまりにも個人的な内容が書かれていますので、とても公開できるような内容ではありません。でも、公開できる部分は公開して FreeBSD や Cisco デバイス、Linux に関して何か書いておけば、知りたいと思う方々が訪れてきたときに参考になるかなと思って書き始めたのがこのブログです。別記事でも書きましたが最初は自宅のファイバにぶら下げて公開なども考えたのですが、最終的にレンタルサーバを借りることにしました。これも別記事で書きましたが、M$ Azure データセンタを使い始めるまでは、とある国内のデータセンターにラック１本借りて VMware サーバでアジア各オフィス向けにサービスを提供していました。まぁ、ネットワークや OS を全て自由に使用できるので柔軟性は非常に高かったのですが、国外どこでも同様の柔軟性を得るためには Azure や AWS などのクラウド上のデータセンタを使う必要がありました。一方、個人で WEB サイトを公開するのにそこまで必要か？と考えた場合、データセンタではなくてもサーバで十分、しかもニッチな内容なので、共有サーバで十分という結論に至り、とある ISP さんのレンタルサーバをお借りすることになりました。前回の記事をお読みいただいた方でしたら、どこのレンタルサーバを借りているかは簡単に突き止めることができるのではないかと思います 🙂 秘密にする必要もないのですが、逆に公開する必要もありません。知る人ぞ知るでいいと思います 🙂
レンタルサーバを借りる時に何を基準にしたかというと、OS が何か、地理的な場所、それと SSH などによるシェルアクセスができるかどうかの３点をメインに決めました。OS は BSD か Linux が must で、Windows は無し。これは職業病で、ソースコードの見えない OS は使わない。裏で何してるのかわからないので 🙂 場所は大阪市内、できれば北区にあるネットワーク的な距離が近いところにあるサーバ。まぁ、自分が快適に更新することができるロケーションを選びました。なぜなら NSPIXP-3 が以前使用していたデータセンタ内にあったので、ISP 跨いでの接続でもそれなりに快適につかえると考えたからです。事実、ping による計測で、IPv4/IPv6 ともに、3ms 弱程度の距離で、非常に快適に使わせてもらっています。最後に、使わせてもらっている OS は FreeBSD 13 amd64 で、SSH でログインしてログなどの情報を取ってきたり、.htaccess ファイルや robots.txt などを手動で編集したりできるので、WEB サーバとしての使い心地も十分に満足できるものです。唯一の不満としては、ログインシェルとして csh しか使えないので、自分でコンパイルした ksh を使って、手動でシェルを変えないといけないことくらいです 🙂
使い始めた当初どこにしようかなとあちこちのサイトを漁っていたのですが、まぁ選択肢の多いこと 🙂 オールインワンで、何も知らなくても使えるサイトから、それなりにサーバへのアクセスも許してくれる平均的なレンタルサーバ、同じレンタルサーバでも専用サーバであったり、ロードバランサを使用したクラウド対応であったり、様々な特徴がありました。勿論本格的な仕様のサーバであれば高額なのはわかるのですが、安いほうの価格がゼロ円からというのもありました。どこで利益を得ているのかと、いらぬ心配をしてしまうこともありました 🙂 コンテンツ、対象、ボリュームなども考慮してどこにするかを決めるのも楽しかったと記憶しています。
以下広告
コメント