さて、前回までは TACACS を使うより前の段階の初期設定ということで、Cisco スイッチを触ってきましたが、今回は FreeBSD を TACACS のサーバに仕立て上げようと思います。/usr/ports 配下を調べると TACACS は２つあることがわかります。ディレクトリ内の記述を読んでみると、tacacs の方が tac_plus4 の上位互換であるようなことが書かれています。しかし、コンパイル後にインストールが失敗することがわかりましたので、tac_plus4 を使用するようにします。ドキュメントには tac_plus4 プラスアルファであると書かれているので、プラスアルファの部分を使用しないといけなくなった場合に tacacs を使ってみたいと思います。そのころにはインストールの問題が解決されている事を期待します 🙂 ということで、tac_plus4 ディレクトリで make install clean します。
tac_plus4 compilation
インストールが完了すると、このようなメッセージが表示されます。
指示通り、/etc/rc.conf に変数を加えます。
tac_plus4 configuration
設定ファイルを見てみると、サンプルユーザが2人あることがわかります。これらのサンプルは例として、後程見るかもしれません。今回はスクラッチから作ってみます。
まず、key 変数を定義します。コメント部に書いたように Cisco デバイスの tacacs サーバの定義部分の key と一致させる必要があります。そうでないと、お互いに暗号化されたトラフィックを復号できません。つまり、TACACS サーバを利用できないということになります。
まずは一番わかりやすい TACACS ローカルのユーザを作ってみます。ユーザ名 local-account でそのパスワードは 1234567890 です。使えるコマンドは “show xxxxx” のみが指定されています。
AAA for tacacs access control
今作った TACACS サーバを使用するためのスイッチ側の設定です。基本必要なのは IP アドレスと、パスワードです。その他オプションが各種ありますが、これら以外は問題が起きたときに見ていくことで大丈夫です。
続いて、TACACS サーバは複数使用することができます。そのためにサーバグループを作ります。例によって、JF3VQB グループとします。そのメンバーとして使用できる TACACS サーバは現在 dhcp さんのみですので、dhcp さんを追加します。
次に vty ラインのアクセスコントロールに TACACS を使用するとスイッチに教えてやらなければなりません。前回までに line と enable を使用すると aaa コマンドで指定しましたが、そのオプションに TACACS グループを追加します。重要なのは TACACS グループが他の選択肢よりも先に指定されている必要があります。前回も書いたように、指定された順番に試して行きます。
これで local-account ユーザでスイッチにログインできるはずです。やってみましょう。ユーザ指定で ssh を起動します。
失礼しました。TACACS サーバが起動していませんでした 🙁 起動します。
そして、TACACS 設定ファイルで指定したパスワードをもう一度試してみます。
通りました 🙂 管理者にもなることができました。この場合のパスワードはローカルの enable secret で指定したパスワードです。
AAA for tacacs accounting
次はアカウンティングを行えるようにします。tac_plus のマニュアルページから動作関係のログは tac_plus.log に、アカウンティング関係のログは tac_plus.acct ファイルにそれぞれ出力されるとあります。ただし、”-d” オプションでどのレベルまで出力するかを指定する必要があります。とりあえず、”-d 16″ で認証と認可関係のログまで記録することができます。このオプションを /etc/rc.conf に追加して、空のログファイルを作って TACACS を再起動します。
tac_plus.log は再起動などの情報が記録されているのが確認できます。では、アカウンティングの設定を追加してみます。
aaa コマンドを追加したにもかかわらず、tac_plus.acct はスイッチで何をどうしても内容が増えず、空のままでした。
ちょっと調べてみると、tac_plus は tacacs ユーザの権限で動いているようなので、tac_plus.acct ファイルのオーナーを tacacs に変更すると、ログが増えてゆくようになりました。
ファイルの中身は普通のテキストで、誰が何時何を行ったかが記録されます。
AAA for enable access
次に enable パスワードも TACACS で管理するようにしてみます。以下の aaa コマンドを追加します。これは console でも vty ラインでも同じにしたいので、デフォルトとしての設定を行います。
enable コマンドを実行して、ローカルで指定したパスワードを入力してみます。そうすると、そのパスワードは通らなくなります。aaa コマンドで指定した通り、enable パスワードは TACACS を最初に試します。この場合、 TACACS は利用できないのではなく、パスワードが異なる ( 実際は user unknown のはず ) とエラーを返しているはずです。ですので、失敗するのです。
Cisco の TACACS 関係のマニュアルを読むと、enable コマンドで使用するパスワードは enabl + privilege level のアカウントのパスワードが使用されます。ですので、管理者レベルであれば $enabl15$ ユーザを作りパスワードをセットする。
そうすると、管理者レベルのアクセス権限を得ることができます。
サポートレベルの privilege level 7 であれば $enabl7$ ユーザを作りパスワードをセットすることで、”enable 7″ コマンドを使用することができます。
enable コマンドのデフォルトの privilege level は 15 ですので、引数として privilege level を指定します。勿論パスワードは $enabl7$ ユーザで指定したパスワードを入力します。
AAA for authorization
authentication, accounting, enable 関連の設定が続きましたが、TACACS の一番面白い部分が authorization の部分です。コマンドの認可も TACACS を使用すると aaa で指定します。
これで、何もしなければ show interface xxx コマンドは使用することができます。なぜなら “show xxx” は実行可能だと TACACS の設定ファイルに書かれているからです。誤解されるかもしれませんが、現在の local-account ユーザの privilege level は 1 なので、privilege level 1 の権限で実行できる “show xxxx” コマンドという意味です。例えば、”show running-configuration” などは privilege level 1 では実行できません。ですので、TACACS で “show xxx” が使えるよと書かれていても、実行できないコマンドは当然あります。この辺りのコマンドの実行権限レベルの変更はスイッチの privilege コマンドで変更できます。例えば、”show running-configuration” が privilege level 1 で実行できるようにスイッチで変更されていたら、TACACS の設定通りに “show running-configuration” の実行の可否を TACACS で管理できます。
TACACS の設定に細工をして、interface コマンドを使えなくしてみます。
すると、さっきまで動いていた “show interface xxx” コマンドは動かなくなります。でも、それ以外の “show clock” などは普通に動きます。
もう少し細工を細かくして、GigabitEthernet0/1 の情報のみ見せたくない場合はこのように指定します。
GigabitEthernet0/2 の情報は見えますが、同じコマンドを GigabitEthernet0/1 に対して実行すると拒否されます。
tacacs users
ここまで TACACS ローカルのユーザを使ってきましたが、FreeBSD の OS から見えるユーザで TACACS を使いたくなりませんか？その場合に PAM でユーザの取り扱いができればこの pokemon ユーザのように OS のパスワードが使用できます。ただし、OS のユーザ誰でもが TACACS を使えるわけではなく、TACACS のユーザとして登録されており、そのパスワードを PAM 経由で確認するとなっている場合に限られます。OS のアカウントと言えど、あくまでも TACACS にユーザがあるかどうかが最初に試されます。無ければ User Unknown となります。
TACACS のユーザができたので、pokemon ユーザでログインしてみます。当然パスワードは OS のパスワードです。
ログインできましたが、コマンドの実行に難があります。そこで便利な機能がグループです。例えば各ユーザで共通の設定を適用したい場合はこの例のようにグループを作成して、共通の設定をしておきます。デフォルトでどのコマンドでも使えるようにしてみます。
先ほどは使えなかったコマンドが使えるようになりました。
私は privilege level 1 のユーザを普段使用して、管理作業を行うときに enable で権限を得ます。日々のメンテナンスでログインしているときに不用意にコピペしたコマンドでスイッチへのアクセスが途切れたり、設定が変わってしまうなど悪夢でしかありません 🙂 でも、最初から管理者権限を与えたい場合もないとは限りません。そのようなときには privilege level が 15 のユーザであると指定してやると enable コマンドを実行せずとも管理者レベルの権限を与えることができます。グループの設定部分でも同じことになります。
おっと、失礼しました。privilege level も TACACS に従うと aaa コマンドを入れてやる必要がありました。こんな感じです。
tacacs 冗長性
さて、dhcp さんは物理マシンなので常時稼働していることからプライマリサーバとして使用したいのですが、逆に物理マシンであるからこそ冗長性が欲しくなります。ディスクが飛ぶなどして動かなくなったらスイッチにアクセスできなくなります。そこで、バックアップサーバとして pokemon さんに全く同じ設定ファイルをコピーして tac_plus を起動します。
スイッチ側での冗長性の設定は簡単で、dhcp さん同様に tacacs server を作り、それを JF3VQB グループに追加してやります。これで完了です。
設定ファイルでは dhcp さんが先に記述されています。この場合、スイッチは dhcp さんの TACACS を試してみて、返答がなければ、pokemon さんの TACACS に同じ問い合わせを行います。
もし、プライマリとセカンダリを入れ替えたい場合は、単に順番を変えれば OK です。後から追加したほうが後ろに追加されてゆきます。
このようになっていると、pokemon の TACACS が先に試されます。
さて、こちらが私が使用している aaa 関係の設定です。ご参考まで。
IOS update
実は友人が新しいスイッチを買ったということで、それまで使用していた Catalyst 2960G が不要になったと酒の席で話していました。そこで、不要になった 2960G ２台を安価に分けてもらいました。都合３台の 2960G が家庭内で動いています。これまで 100M の馬鹿ハブでつながっていたリビングルームの WiFi も 1G でインターネットにつなぐことができるようになりました 🙂 それはそれとして、Cisco さんの 2960 関係のマニュアルを読み漁り、2960G で使用できる最新の IOS も cisco.com から落としてきて、中古のスイッチをプロダクションにする前にアップデートしておきました。こちらが元々あった 2960G の IOS 情報です。
こちらが利用可能な最新版を突っ込んだ中古の 2960G の IOS 情報です。この IOS は FreeBSD の tftp を使用してアップデートしたのですが、このスイッチは元のスイッチと同じ方法では芸がないので、スイッチの tftp 機能を使用して FreeBSD なしでアップデートしてみます。
フラッシュの中身を見てみて、tftp-server コマンドにファイル名を指定して実行します。とりあえず IPv4 でアクセスしてみます。
tftp を使用してスイッチ間で IOS をコピーしてきます。
ブート時にどのファイルを使用するかを指定します。
設定を保存して、夜中に再起動するようにコマンドをセットします。OS は可能な限り最新版を使用しましょう。毎日のように新しいセキュリティホールが発見されています 🙂
TACACS は元々 Cisco 独自のプロトコルで、たくさんあるネットワーク機器のベンダーの多くは部分的にサポートしているというのが実情のようです。RADIUS の代わりに TACACS でデバイスアクセスのみを制御しようとするのであれば多くの場合動くと思います。しかし痒いところに手が届く動きが必要なのであれば他のベンダのインプリメントはイマイチと言わざる負えません。
以前の記事で、私の会社は4つの別々であった事業部が合併して１つの事業部になったと書いたことがあったと思います。他の事業部で使用されていたスイッチの設定を見て愕然としたことを覚えています。スイッチアクセスはローカルユーザのみ、ほとんどのポートはデフォルトのまま、比較的大きなスイッチネットワークでもどのスイッチも同じスイッチプライオリティ。変更しているのはホスト名と SNMP のコミュニティ程度でした。言い換えると、ただ置いただけと言っても言い過ぎとは思わない状況でした。さすがに時間は NTP を使っていたようです。SNMP で取得した情報の時間がおかしかったのでしょう 🙂 単にネットワークトラフィックのスイッチングだけを行うのであればどこのベンダーさんのスイッチでも普通に動くと思います。でも本当にネットワーク管理をご存じの方はスイッチング以外の部分を鑑み、多くの場合 Cisco を使いたくなるんだろうと思います。
以下広告
コメント