SELinux有効化後 cgiが動かなくなった

自分のサーバで掲示板のようなcgiを動かしているのだが、SELinux有効化後に投稿したらInternal Server Errorになった。 特に何も変更していないので、すぐに「SELinuxのせいだ!」と思い、/var/log/messagesを見る。
Apr 30 05:16:08 god setroubleshoot[243206]: 
SELinux is preventing post.cgi from write access on the file temp.txt.
#012
#012*****  Plugin catchall (100. confidence) suggests   **************************
#012
#012If you believe that post.cgi should be allowed write access on the temp.txt file by default.
#012Then you should report this as a bug.
#012You can generate a local policy module to allow this access.
#012Do
#012allow this access for now by executing:
#012# ausearch -c 'post.cgi' --raw | audit2allow -M my-postcgi
#012# semodule -X 300 -i my-postcgi.pp
#012
cgiがファイルに書き込むことが許可されていない。 そして、それを許可するようにする方法も書かれている。 ausearchで問題が起きているcgiファイルを探して、パイプで audit2allowに渡してmoduleを作成し、 semoduleでそれをinsallする、ということのようだ。
# ausearch -c 'post.cgi' --raw | audit2allow -M my-postcgi
******************** 重要 ***********************
このポリシーパッケージを有効にするには、以下を実行して下さい:

semodule -i my-postcgi.pp

言われたとおりに

# semodule -i my-postcgi.pp

messagesには

semodule -X 300 -i my-postcgi.pp

と書いてあるが、-Xというのはpriorityを指定するオプションのようだ。

が、-Xなしで実行し、同様のcgiがもう一個あったのでそれも同様にすると、掲示板に投稿できるようになった。

そもそもなんでこのcgiがSELinuxで止められたかであるが、それにはちょっと心当たりがあって、 このcgiを作った時にファイルに書き込みができないということが起きて、権限の問題だろうということで、 よくわからないのでとにかくなんでもありの権限や所有者設定にしたのを覚えている。 おそらくそういう適当な権限設定のファイルを扱ったのでSELinuxが止めたのだと思う。

多分、cgi実行ユーザとファイル所有者が違う、とかいうことじゃないかと思うが、今回はめんどくさいのでこのまま許可してしまう。

SELinux始めました

 SELinuxなんか無効にするのが当たり前となって10年くらいたった。(自分の中で)

さくらのVPSも、conohaのVPSも、SELinuxはデフォルトで無効じゃないか?

自分で無効にした覚えがないから。


初めてCentOSをさわった頃、たしか4か5の頃、なんかおかしいなと思ってSELinuxを無効にしたらうまくいった、ということがあって、そのうち最初から無効にするようになった。

私がLinuxを使うのはほとんどが実験や検証的な場合だったのでそれでよかった。


だが、セキュリティについていろいろとうるさくなってきた昨今、

「めんどくさいからオフる」

という思考回路を改めた方がいいのでは?と感じている。


そこで、とりあえず自分が使っているcentos8のSELinuxを有効にしてみた。


参考

https://access.redhat.com/documentation/ja-jp/red_hat_enterprise_linux/6/html/security-enhanced_linux/sect-security-enhanced_linux-working_with_selinux-enabling_and_disabling_selinux


いまSELinuxが有効かどうかは

getenforce

でわかる。

disabled

になっている。

Enforcingだと有効、Permissiveだとポリシーをチェックするが動作は止めない、disabledだとポリシーもチェックしない無効な状態である。

enforcing/permissiveの切り替えは setenforceコマンドでできるが、

disabledにする、disabledから再度有効にするには、

/etc/selinux/config

を書き換える必要がある。

有効にするなら

SELINUX=enforcing

上記のRedHatの情報を見ると、SELinuxが無効の状態から有効にするときにはいったんpermissiveにして再起動し、ログをチェックして問題がないことを確認してからenforcingにする、と書いてあった。


また、必要なSELinuxのパッケージをインストールしておく必要がある。

(私の場合は事前になんでもかんでも突っ込んでいた)


その通りにやってみると、私の場合sshdに関する以下のようなログが記録された。

Apr 29 03:03:12 god setroubleshoot[1550]: 
SELinux is preventing /usr/sbin/sshd from name_bind access 
on the tcp_socket port xxxxx. 
For complete SELinux messages run: 
sealert -l 78b09f6f-3440-421f-976d-55edb0af1088

port xxxxx の xxxxx は実際には数字が記録されていて、この数字はsshで使用するポートをデフォルトの22から変更したポート番号である。

「SELinuxが有効だとsshのポート変えられないのか!じゃあ無効にしよう!」

ではなく、

SELinuxの設定でもsshで使用するポートを変更あるいは追加すればよいのだ。

semanage port --list

で現在の設定が表示される。

sshでgrepすると

# semanage port --list | grep ssh
ssh_port_t     tcp      22

追加するには

# semanage port --add --type ssh_port_t --proto tcp xxxxx

dnssecはじめました(2)

参考

https://www.nic.ad.jp/ja/dns/dnssec/dnssec-startup-guide.html

centos8で

/home/dnssec

というフォルダを作り、そこへ移動

ZSK (Zone Signing Key) の生成

# dnssec-keygen -a RSASHA256 -b 1024 -n ZONE monqy.net
Generating key pair............................+++++ ............................+++++ 
Kmonqy.net.+008+47608

KSK (Key Signing Key) の生成

# dnssec-keygen -a RSASHA256 -b 2048 -n ZONE -f KSK monqy.net
Generating key pair..........................................................+++++ ...........+++++ 
Kmonqy.net.+008+36227
zoneファイルのあるフォルダへ移動
# cd /var/named

zoneファイルに署名

# dnssec-signzone -S -K /home/dnnssec/ monqy.net.zone
Fetching ZSK 31795/RSASHA256 from key repository.
Fetching KSK 3160/RSASHA256 from key repository.
Verifying the zone using the following algorithms: RSASHA256.
Zone fully signed:
Algorithm: RSASHA256: KSKs: 1 active, 0 stand-by, 0 revoked
                      ZSKs: 1 active, 0 stand-by, 0 revoked
monqy.net.zone.signed

zoneファイルの後ろに ".signed"がついたファイル "monqy.net.signed" ができる。

前回のエントリではゾーンファイル名に.zoneを付けていたが、 今回はドメイン名をそのままゾーンファイル名にした。 (なんか.zoneがついてるとうまくいかなかった気がしたが気のせいかもしれない)

これはテキストファイルで中身を見ることができるが、 RRSIG, NSEC, DNSKEYなどが追加されているのがわかる。

そして /etc/named.conf のゾーンファイル名を、 署名付きのものに変更して、namedを再起動する。

zone "monqy.net" {
        type master;
        file "monqy.net.signed";
};
で、dig
# dig @localhost monqy.net DNSKEY +dnssec +multi

とやると、なにやらずらずらと引ける。

この後、DSレコードを上位サーバに登録する必要があるらしい。

参考にしたサイトだと「DSレコードをJPNICに登録します」とあるが、 これは例がJPNICの管理しているIPアドレスの逆引きゾーンだからで、 私がやっている .net のドメインだとどこになるのか?

後で調べます。

dnssecはじめました(1)

 dnssecについて勉強しているが実感がわかないので実際に設定してみようと思った。

vpsを2台持っているので、まずはそれぞれにbindをインストールする。


1台はcentos8、もう一台はUbuntu 18.04.5 LTS

bindについて調べていたら、centos8が今年で終わるということを知った。


まあなんかしらの後継が出るのだろうから、それはさておき


centosとubuntuでbindのインストール・設定方法が違うのでまずそれを書く。


まずcentos8

# rpm -q bind bind-chroot bind-utils
パッケージ bind はインストールされていません。
パッケージ bind-chroot はインストールされていません。
bind-utils-9.11.20-5.el8_3.1.x86_64

# dnf install bind bind-chroot bind-utils

(略)

基本設定

# cat /etc/named.conf

options {
        listen-on port 53 {
                                127.0.0.1;
                                xx.xx.xx.xx;
        };
//      listen-on-v6 port 53 { ::1; };
        directory       "/var/named";
        dump-file       "/var/named/data/cache_dump.db";
        statistics-file "/var/named/data/named_stats.txt";
        memstatistics-file "/var/named/data/named_mem_stats.txt";
        secroots-file   "/var/named/data/named.secroots";
        recursing-file  "/var/named/data/named.recursing";
        allow-query     {
                        localhost;
                        yy.yy.yy.yy;
        };

recursion yes;

        dnssec-enable yes;
        dnssec-validation yes;

        managed-keys-directory "/var/named/dynamic";

        pid-file "/run/named/named.pid";
        session-keyfile "/run/named/session.key";

        /* https://fedoraproject.org/wiki/Changes/CryptoPolicy */
        include "/etc/crypto-policies/back-ends/bind.config";
};

logging {
        channel default_debug {
                file "data/named.run";
                severity dynamic;
        };
};




zone "." IN {
        type hint;
        file "named.ca";
};

include "/etc/named.rfc1912.zones";
include "/etc/named.root.key";

zone "monqy.net" {
        type master;
        file "monqy.net.zone";
};

dnssec-enable yes; dnssec-validation yes; がデフォルトで書いてある。

デフォルトからの変更箇所

まずlistenするipアドレス。xx.xx.xx.xxは自身のIPアドレス。

        listen-on port 53 {
                                127.0.0.1;
                                xx.xx.xx.xx;
        };

queryを許可するアドレス。とりあえず確認のため、localhostともう一台のbindを動かすサーバーのIPアドレスyy.yy.yy.yyだけを許可する。

        allow-query     {
                        localhost;
                        yy.yy.yy.yy;
        };

zoneファイルの情報。こっちをmasterにする。

zone "monqy.net" {
        type master;
        file "monqy.net.zone";
};

zoneファイル。ns01.monqy.netが自身のfqdnである。 参考にした情報だと、fqdnのAレコードとホスト名のみのAレコードが両方あったのでとりあえずマネする。

# cat /var/named/monqy.net.zone
$TTL 3600
@       IN      SOA     ns01.monqy.net. root.monqy.net. (
        2021042801      ;Serial
        3600            ;Refresh
        300             ;Retry
        360000          ;Expire
        86400   )       ;Negative

                        IN      NS      ns01.monqy.net
ns01.monqy.net          IN      A       xx.xx.xx.xx
ns01                    IN      A       xx.xx.xx.xx
www2                    IN      A       xx.xx.xx.xx
www3                    IN      A       yy.yy.yy.yy

named-checkconfと named-checkconf -zをやって設定に問題がないことを確認。

# named-checkconf
(問題がなければ何もでない)


# named-checkconf -z
zone localhost.localdomain/IN: loaded serial 0
zone localhost/IN: loaded serial 0
zone 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.arpa/IN: loaded serial 0
zone 1.0.0.127.in-addr.arpa/IN: loaded serial 0
zone 0.in-addr.arpa/IN: loaded serial 0
zone monqy.net/IN: loaded serial 2021042801

firewallについては省略。 queryを許可したyy.yy.yy.yyからdigで名前解決できることを確認する。

~$ dig @xx.xx.xx.xx www2.monqy.net

(略)
;; ANSWER SECTION:
www2.monqy.net.         3600    IN      A       xx.xx.xx.xx
(略)

今度はubuntu。パッケージ名(だっけ?)がcentosと違う。

sudo apt-get install bind9

ubuntuの方は、named.confの中にincludeが書いてあって、設定ファイルが分かれている。

/etc/bind/named.conf.options
/etc/bind/named.conf.local
/var/cache/bind/monqy.net.zone ※作る

/etc/bind/named.options は、listen-onとallow-queryを書く。

$ sudo cat /etc/bind/named.conf.options
[sudo] password for clebriz:
options {
        directory "/var/cache/bind";

        listen-on port 53 { localhost; yy.yy.yy.yy; };
        allow-query { localhost; xx.xx.xx.xx; };

        dnssec-validation auto;

        auth-nxdomain no;    # conform to RFC1035
        listen-on-v6 { any; };
};

/etc/bind/named.conf.local は、zone情報を書く。自身をslaveとして、masterのIPアドレスを書く。

ゾーンファイルはmasterからコピーされることになると思う。masterと同じ名前でいいと思うが、一応変えておく。

$ sudo cat /etc/bind/named.conf.local
zone "monqy.net" IN {
        type slave;
        file "monqy.net.slave.zone";
        masters { xx.xx.xx.xx; };
};

/var/cache/bind/monqy.net.slave.zone がゾーンファイル。

これはmasterからコピーされるので中身はなくてもいいのか?でも動作確認のため書いておく。

(後でゾーンファイルの中身を見ようとcatとかすると文字化けして表示できない。これは直接見ちゃいけないファイルなのか?)

bindを起動する。

sudo systemctl enable bind9
sudo systemctl start bind9
sudo systemctl status bind9

statusを見てみると... 動いてはいるのだが、パーミッションがなくてzoneファイルを更新できないというメッセージが。

sudo systemctl status bind9
(略)
zone monqy.net/IN: transfer: could not set file modification time of 'monqy.net.slave.zone': permission denied
(略)

chownでownerとグループを bindに変える。

$ sudo chown bind:bind /var/cache/bind/monqy.net.slave.zone
$ ls /var/cache/bind/ -l
total 16
-rw-r--r-- 1 bind bind 821 Apr 28 02:35 managed-keys.bind
-rw-r--r-- 1 bind bind 512 Apr 28 02:35 managed-keys.bind.jnl
-rw-r--r-- 1 bind bind 525 Apr 28 02:33 monqy.net.slave.zone

dnssec-validation auto; という設定があるが、dnssec-enable yes; は、ない。


$ sudo cat /etc/bind/named.conf

include "/etc/bind/named.conf.options";
include "/etc/bind/named.conf.local";
include "/etc/bind/named.conf.default-zones";


$ sudo cat /etc/bind/named.conf.local
zone "monqy.net" IN {
        type slave;
        file "monqy.net.slave.zone";
        masters { xx.xx.xx.xx; };
};


$ sudo cat /etc/bind/named.conf.options
options {
        directory "/var/cache/bind";

        listen-on port 53 { localhost; yy.yy.yy.yy; };
        allow-query { localhost; xx.xx.xx.xx; };

        dnssec-validation auto;

        auth-nxdomain no;    # conform to RFC1035
        listen-on-v6 { any; };
};

dnssec-enable yes; を書くだけじゃダメだよね。鍵を作ったり署名したりしないと... (続く)

Dell PowerEdge R620 のセットアップにまつわる騒動

ヤフオクで中古のDellサーバ PowerEdge R620を購入した。

目的はCMLを使うことである。

今は自宅のWindowsPCで動かしているが、ややスペック不足なのと、

外部から常にアクセスできるようにしておきたいと思った。


スペックは

メモリ32GB

ディスクは900GBが2個

CPUはXeonの8coreのが2個


ディスプレイ出力がVGAなのでVGA-HDMI変換アダプタを買った。

単なる形状変換ではなく、8000円ほどした。

HDMIインターフェースからVGAに出力するケーブルは2000円弱で売っていて、

最初はそれを買ってしまった。

買ってから箱に「VGA -> HDMI の変換はできない」と書いてあることに気づいた。

そんなバカなと思いつつ開封してつないでみたが、

つなぎながら、『でもわざわざ箱に書いてあるくらいだからダメなのかな』と思い始め、

やはりダメだった。

(このVGA-HDMI接続がトラブルの発端であった...)


変換アダプタとVGAケーブルを買ってHDMIのモニタにつないで起動する。

しばらく何も表示されない。1分や2分ではなかった気がする。


Dellのロゴが表示される。BIOS Setupとかに入れる画面だ。

OSは消去済みとは聞いていたが、とりあえずそのまま起動させてみる。


ロゴが消えるとまたしばらく真っ暗になる。

やはり数分待つと、system initialization(うろ覚え)

みたいな文字が表示される。


それが消えて、どうなったか忘れたが、

OSがないとかどうとか何も表示されなかった気がする。


いったん再起動してBIOSセットアップを起動して、

メモリが32GB認識されていること、

ディスクが2個認識されていることなどを確認。


外付けDVDドライブをUSBポートに接続し、

BIOS設定でブートデバイスのトップをDVDドライブにする。

ESXiのインストールディスクをDVDに焼いてセットし再起動する。


再起動は時間がかかったがESXiのインストーラが起動しインストールが始まった。

が、ディスクを選ぶところで何も出てこない。


ESXiが7.0.0だったので、古いRAIDコントローラを認識しないとかいう問題かと思い、

(そういう経験があった)

centosのインストーラを起動してみたが、同様にディスクを認識しない。


そうこうしているうちに、再起動しても画面が真っ暗な状態で何もでなくなってしまった。

Dellのロゴも出ないし、initializationがどうのこうのも出ない。


キーボードで ctl+alt+delを押すとリブートする。

リブートしていることは筐体前面にある小さなLCDに「system is rebooting....」とか表示されるのでわかる。

即リブートするので、システムがハングアップしているという感じではない。


筐体前面のディスプレイの横にボタンがあり、

iDRACというポートのIPアドレスが設定できることがわかったので設定してアクセスしてみた。


ブラウザでアクセスでき、ユーザ認証があるがデフォルト設定で入れた。

その管理画面で見る限りは特に異常はなさそうだ。


いったん電源を落とし、コンセントも抜いて、

メモリを外して付け直した。


8GBのメモリが4枚入っている。

メモリ装着スロットが24スロットもある。

そのうちの4つを、とびとびに使用している。

未使用のスロットにはフィラーのようなものがついている。


CPUは確かに2個ついている。


NICのポートが4つある。

そんなにいらないが...


WEBで軽く調べた結果、どうもPOSTで失敗しているようだ。

(実はそうではなかったのだが)


メモリか、ディスクか、CPUか、マザーボードか....

故障しそうなのはディスクかメモリだが、

挙動からしてもっと根幹がイカれている感じがする。


POSTしてるなら「POSTしてます」みたいなメッセージを出せよ、そもそも。

で、失敗したら「何のPOSTで失敗しました」と出せよ。


そういうのも出せないところで失敗しているのか...

でも、最初になんとか起動していた時は何も出なかった。


3万円だからな...

安いなとは思ったのだが...


4枚ついているメモリを1枚だけ残し、2台ついているHDDを外して起動したが、

挙動は変わらず。

外したデバイスが原因ではないということだ。

(もしかしたらそれらも故障しているかもしれないが、それが原因で起動できないのではない。)


残るは、メモリ1、CPU1、CPU2、マザーボード、電源、RAIDコントローラ、NIC、か。


NICがだめでも起動はするだろう....

ディスクが選べなくても起動はしたからRAIDコントローラも違うかな...


ディスクはiDRACで見ると物理的には認識していたのだが、

iDRACで設定を消そうとしたりしていたら物理的にも見えなくなってしまった。


iDRACで接続できるので動いていることは動いていると思っていたが、

iDRACは電源オフの状態でも電源ケーブルが接続されていればアクセスできて、

要はリモートから電源のオフだけでなくオンもできるという機能であった。


電源オフでもアクセスできるのだから、

iDRACに接続できてもあまり意味がない。


あとできることは...

・マザーボードの外観チェック(コンデンサが破裂してないかとか)

・まだ外してないメモリを外して残り3枚のメモリ1枚ずつで起動してみる

・マザーボードの電池を交換してみる

・NVRAMクリアしてみる

・CPUを1個ずつにして起動してみる


すぐにはできないが...

・メモリを別のPCにさしてみる

・CPUを別のPCにさしてみる

・マザーボード交換

・電源ユニット交換


ヤフオクなんかじゃなくてotto認定中古品とかを買えばよかったかなと思う。

同等品は10万円くらいする。



翌朝。


カバーを開けて破裂や液漏れしているコンデンサはないか見てみる。

内部は非常にきれいで、ホコリや汚れもほとんどなく、部品が壊れている形跡はない。

メモリスロットの番号を見て、A1が一番端ではないことに気づいた。

この前1枚だけさして起動したのはB1だった。

A1だけにさして試すがやはり画面に何も表示されない。


シャーシのカバーを開けて起動して確認していた。

「カバーを開けたまま5分以上運用するな」と書いてあったので、

『ということは開けたままでも動くんだな』と思って。


前面LCDに「intrusion detected」というメッセージが出るので

もしかしてカバーをつけないと起動しないのかと思いカバーをするが同じ。


再びカバーを外して起動する。

すると、シャーシの真ん中あたりにある小さなLEDが点滅しているのに気付いた。


調べるとRAIDコントローラだった。

これか!とほとんど確信して外して起動してみるが、同じ。

外すときにロックしているプラスチックの部品が折れてしまった。

付け直して起動する。


CPUを1個外してみようかと思いドライバーでカバーを止めている2本のねじをゆるめて

カバーを外してみる。グリスもついているし、どうしてもCPUだとは思えず、

カバーを戻す。


また電源を入れてiDRACを見る。


「仮想コンソール」みたいな機能があって表示するとファイルがダウンロードされてしまうので見ていなかったのだが、調べると何かの設定を「html」にするとブラウザで開けるとのことだった。

htmlにしてコンソールを表示してみると....


普通に起動している!


OSがないというメッセージが出ている。


試しに再起動したら、Dellのロゴも表示されるし随時メッセージも表示される!


何も問題なく起動している!!!


ディスプレイに表示されていないだけだった!!!!!


なんだろう?


サーバのVGA機能がおかしいのか、VGA-HDMI変換アダプタがおかしいのか。

一時は表示されていたから、それはないと思っていたのだが.....


メモリ、RAIDコントローラ、ディスク等全部つけて起動する。

BIOSセットアップ画面に入って状態を見る。


全部問題ない。


起動させると「virtualディスクがないけど設定しますか」

みたいなメッセージが出てyesとか答えるとユーティリティが起動する。


よくわからなかったがほとんどデフォルト設定のまま、

RAID 0でディスクを作り「初期化する」だけを有効にする。


作成後、ユーティリティを終了する方法がわからず、

ctrl+alt+deleteで再起動する。


iDRACで(仮想)ディスクができたことを確認



ESXiのインストールも無事に完了し、

CMLの仮想マシンも動いた。


CML起動後の初期画面でなぜかEnterが効かないのだが....

まあこれは大した問題じゃないでしょ。



というわけで、PowerEdgeはiDRACが使えれば、

ディスプレイもキーボードもつけずにセットアップできるということがわかった!!


VGAからモニタに映せない理由は不明だが、もうどうでもいい....


ケルベロス認証を完全に理解する

ケルベロス認証という名前は何度も聞いたことがある。

Windowsサーバーの認証で使用されていると聞いている。


Windowsサーバーの認証というのは、

Windowsサーバーにログインする際の認証ではなく、

Windowsサーバーが管理しているユーザーの認証のことである。


ケルベロス認証はよく聞く言葉ではあるが、

認証といえばケルベロスというほどメジャーでもない。




認証といえば、無線のpsk,

WPAパーソナル、WPAエンタープライズ

RADIUSサーバー

oauth

などがある。



私が把握している認証方式にRADIUS認証がある。


radiusではサプリカントとクライアントとサーバがいて、


サプリカントがクライアントにアクセスすると、

クライアントがサーバと通信して認証要求を出して許可を得る。




ケルベロスとradiusは何が違うのだろうか?

そしてなぜwindowsではケルベロス認証を使用しているのか?


まずケルベロスという名前にヒントがあるだろうと考えられる。

というか、認証方式の特徴をあらわすのにちょうどいいからケルベロスと呼んだのだろう。


ケルベロスというのは、頭が3つある番犬である。


おそらく、認証する際に3つのことなる役割を持つ機能があって、

その3つの役割とユーザが交渉というか検査というか、なんらかのやり取りをするだろうと予想できる。



Key Distribution Center (KDC) データベース

Authentication Server (AS) 認証サーバー

Ticket Granting Server (TGS) チケット発行サーバー

Ticket Granting Ticket (TGT) チケット


3つのアタマとは、KDC, AS, TGSをさすのだろう。


チケットというのが、ほかの認証では出てこない考えである。


チケットは何のために発行されどのように認証に使用されるのか?



---

1. ASに対してユーザー認証情報を送信

2. KDCによってユーザー情報とサーバー利用資格をチェック

3. 問題なければASからTGTチケットを払いだす

4. TGTチケットをTGSに送信し、利用したいサーバー用のチケットを要求

5. TGSから利用したいサーバー用のチケットを発行

6. 利用したいサーバーに対して、TGSから発行されたチケットを送信

7. チケットに問題がなければサーバーが利用可能となる

---


https://cybersecurity-jp.com/column/38350 より


1.は問題ない。

どんな認証方式でもこれは行われるだろう。


2.も必須だ。


3.がケルベロス特有である。チケットを払い出す。なんだこれは?

払い出すのはどこに対して?ユーザー?TGS?



4.の、送信する主体は誰だろう?

ユーザー?チケットをTGSに送信する。


5.TGSがチケットを発行したらそのチケットは誰に与えられる?


6.これも誰がどこへがわからない。



infraexpertを参照



1.ユーザがAG/TGSに対して認証要求を送信

2.AG/TGSが要求を許可すると、

3.AG/TGSがTGTをユーザへ送信

4.ユーザがチケットを保管する。

5.TGTを使用してアクセスしたいサーバ用のチケットを要求

6.AS/TGSがチケットの内容を確認

7.AS/TGSがユーザがアクセスしたいサーバ用のチケットを送信

8.ユーザがアクセスしたいサーバ用のチケットを入手

9.ユーザがアクセスしたいサーバにチケットを提出

10.ユーザがアクセスしたいサーバはチケットを確認してアクセスを許可する。




上記を参考にさっきのシーケンスを書き直す


---

1. ユーザが認証サーバに対して認証情報を送信する。

2. 認証サーバのASがKDCによってユーザー情報とサーバー利用資格をチェックする。

3. 問題なければ認証サーバの[TGS]がTGTチケットをユーザに払いだす。

4. ユーザはTGTチケットを認証サーバに送信し、利用したいサーバー用のチケットを要求する。

5. 認証サーバのTGSが、ユーザが利用したいサーバー用のチケットを発行してユーザに送信する。

6. ユーザが利用したいサーバーに対して、TGSから発行されたチケットを送信する。

7. チケットに問題がなければサーバーが利用可能となる

---



ユーザが認証を要求し許可をもらうのは頭が3つある番犬である。


ユーザにとって認証してもらう相手は一人というか一頭であるが、その相手に頭が3つあって、

役割がわかれているのである。



そして役割をわけているのはチケットを発行するためなのがわかる。

チケットを発行する理由は、いったんチケットを発行したらそのチケットが有効である間は

再度認証を受ける必要がないということである。


これが他の認証と違うところである。


また、これをする必要があるのは、複数のアクセス対象に対して認証が必要だからである。


たとえるなら、ディズニーランドで入場時にフリーパスを買えば、個々のアトラクション利用時に入場券を買う必要がない、みたいなことだろうか。

さくらのVPSをubuntuにする

 ubuntuにする。

初期ログインをrootでしようとしたら入れない。

ubuntuで入る。


ubuntuってrootになれないんだっけ。

なんかするときは sudo しないといけない。

めんどくさいな...


まずユーザを作り、su権限を付ける。

sshのポート番号を変える。

さくらのVPSのパケットフィルタを無効にする。


apache2をインストールする。


firewallはデフォルトで無効。

有効にする。


80とsshのポートを開ける。

pingはデフォルトで返すのか。

拒否するにはちょっとめんどくさそうなのでそのまま。


Implementing Cisco Enterprise Network Core Technologies (350-401 ENCOR)



 CCNPを更新した。


コロナウイルス流行の影響で、更新期限が半年延長された。

最初は本来の期限までに更新しようと思っていたが、

新試験になって参考書や問題集がなかなか出ず、受験に踏み切れずにいて結局延長した期限の2か月くらい前に更新することになった。

この試験は新しいCCNP試験(の一部)であるとともに、いままでCCIE筆記試験と呼ばれていた試験の後継でもある。

前回は、CCNP更新しようかCCIE筆記にしようか迷っていたが試験制度が変わってCCNP更新とCCIE筆記試験が同じ試験になった。

CCNPはこのENCORプラス1科目をとれば認定されるようになった。

参考書はciscopressから出ている英語の本しかないのでそれを買った。

紙の本を買ったが、電子版も買った。(少し割引される)


試験範囲は非常に広く、ルーティング・スイッチングはもちろん、無線、仮想化、自動化、セキュリティ、QoS、マルチキャスト、なんでもかんでもある。


本を読んでいるだけでは到底頭に入ってこないので、CMLを買い、ヤフオクで中古のシスコ機器も何台か買った。


CMLというのはVIRLと呼ばれていたシスコ機器を仮想環境で操作できるものだ。

DynamipsとかGNSとか使ってきたが、CMLになってとても使いやすくなった。

BGP等複数台のルータの構成を検証するにはなくてはならないものだ。


勉強期間は実質3か月くらいで、そんなにしっかり勉強したわけではない。

試験に関する情報が少なく、難しくなったという噂を聞いていたが、まあ大したことないだろうと思っていた。


1回落ちて、2回目でようやく受かった。


1回目は試験終了後結果表示がされなかった。

以前にもSWITCH試験か何かでそういうことがあった。


2回目の受験後、やはり結果が表示されず愕然として受付にもどって結果レポートをもらうと、試験前にとった顔写真がでかでかと印刷された下に「Pass」と書いてあった。


試験は英語で受験した。

時間が50分かな?延長されたのだが、目いっぱい使った。10分程度残していた。



LISP 実際に設定した

 


CMLで。


xTR1

interface LISP0
!
interface GigabitEthernet0/0
 ip address 192.168.1.254 255.255.255.0
!
interface GigabitEthernet0/1
 ip address 10.0.1.1 255.255.255.0
!
router lisp
 database-mapping 192.168.1.0/24 IPv4-interface GigabitEthernet0/1 priority 1 weight 100
 ipv4 itr map-resolver 10.0.3.3
 ipv4 itr
 ipv4 etr map-server 10.0.3.3 key password
 ipv4 etr
 exit
!
router ospf 1
 network 10.0.1.0 0.0.0.255 area 0


xTR2

interface LISP0
!
interface GigabitEthernet0/0
 ip address 192.168.2.254 255.255.255.0
!
interface GigabitEthernet0/1
 ip address 10.0.2.2 255.255.255.0
!
router lisp
 database-mapping 192.168.2.0/24 IPv4-interface GigabitEthernet0/1 priority 1 weight 100
 ipv4 itr map-resolver 10.0.3.3
 ipv4 itr
 ipv4 etr map-server 10.0.3.3 key password
 ipv4 etr
 exit
!
router ospf 1
 network 10.0.2.0 0.0.0.255 area 0


MS/MR

interface GigabitEthernet0/0
 ip address 10.0.3.3 255.255.255.0
!
router lisp
 locator-set RLOC01
  IPv4-interface GigabitEthernet0/0 priority 1 weight 100
  exit
 !
 site SITE1
  authentication-key password
  eid-prefix 192.168.1.0/24
  exit
 !
 site SITE2
  authentication-key password
  eid-prefix 192.168.2.0/24
  exit
 !
 ipv4 map-server
 ipv4 map-resolver
 exit
!
router ospf 1
 network 10.0.3.0 0.0.0.255 area 0


確認
 
MSMR#show lisp site
LISP Site Registration Information
* = Some locators are down or unreachable
# = Some registrations are sourced by reliable transport

Site Name      Last      Up     Who Last             Inst     EID Prefix
               Register         Registered           ID       
SITE1          00:23:26  yes#   10.0.1.1                      192.168.1.0/24
SITE2          00:21:03  yes#   10.0.2.2                      192.168.2.0/24




xTR1#show ip lisp map-cache 
LISP IPv4 Mapping Cache for EID-table default (IID 0), 3 entries

0.0.0.0/0, uptime: 00:29:04, expires: never, via static send map-request
  Negative cache entry, action: send-map-request
192.168.2.0/24, uptime: 00:20:41, expires: 23:39:18, via map-reply, complete
  Locator   Uptime    State      Pri/Wgt
  10.0.2.2  00:20:41  up           1/100
192.168.10.0/24, uptime: 00:13:20, expires: 00:01:40, via map-reply, self, forward-native
  Negative cache entry, action: forward-native
xTR1#
xTR1#


xTR2#show ip lisp map-cache 
LISP IPv4 Mapping Cache for EID-table default (IID 0), 2 entries

0.0.0.0/0, uptime: 00:22:13, expires: never, via static send map-request
  Negative cache entry, action: send-map-request
192.168.1.0/24, uptime: 00:21:02, expires: 23:38:57, via map-reply, complete
  Locator   Uptime    State      Pri/Wgt
  10.0.1.1  00:21:02  up           1/100
---- 

192.168.1.111 のPCから ping 192.168.2.222 を実行したときの
Map requestはカプセル化されていた。

IP src(外): 10.0.1.1 ※ ITRの外側IPアドレス
IP dst(外): 10.0.3.3 ※ MRのIPアドレス
IP src(内): 192.168.2.222
IP dst(内): 192.168.2.222

ITR-RLOC Address: 10.0.1.1
Map-Request RecordのPrefix: 192.168.2.222
Map-Reply RecordのPrefix: 192.168.1.0/24




 














Map-Replyは、

IP src: 10.0.2.2
IP dst: 10.0.1.1
Mapping Record - EID Prefix: 192.168.2.0
Mappping Record - Locator Record - Local RLOC: 10.0.2.2



そしてicmp echo requestは

IP src(外): 10.0.1.1 ※ ITRの外側IPアドレス
IP dst(外): 10.0.2.2 ※ ETRの外側IPアドレス
IP src(内): 192.168.1.111
IP dst(内): 192.168.2.222

となっていた。

Map-RegisterとMap-Notifyは、etrを設定したときに送受信されるようだ。
もしくはdatabase mappingを設定したときか。

10.0.1.1 -> 10.0.3.3 に送信される。

この構成ではITR/ETR、MS/MRが同じなのでわからないが、

Map-Requestは
ITR -> MR

Map-Registerは
ETR -> MS

である。

Map-Requestは、「マッピングの解決要求」である。
『マッピングしてください』ではない。



LISPについて整理

EID1からEID2宛の通信が行われるとする。

まず、EID1→EID2への送信


(前提)
①ETR(RT2)がMap RegisterをMSに送信
②MSがマッピングを登録

(EID1からEID2への送信)
③EID1がパケットを送信
④ITR(RT1)がMRにMap Requestを送信
⑤MRがMSにMap Requestを転送
⑥MSがETR(RT2)にMap Requestを転送
⑦ETR(RT2)がITR(RT1)にMap Replyを送信
⑧ITR(RT1)がパケットをカプセル化して⑨ETR(RT2)に転送
⑩ETR(RT2)がカプセル化を解除して⑪EID2に転送



EID2からEID1への戻りの通信

(前提)
①ETR(RT1)がMap RegisterをMSに送信
②MSがマッピングを登録

(EID2からEID1への通信)
③EID2がパケットを送信
④ITR(RT2)がMRにMap Requestを送信
⑤MRがMSにMap Requestを転送
⑥MSがETR(RT1)にMap Requestを転送
⑦ETR(RT1)がITR(RT2)にMap Replyを送信
⑧ITR(RT2)がパケットをカプセル化して⑨ETR(RT1)に転送
⑩ETR(RT1)がカプセル化を解除して⑪EID1に転送

青の矢印が制御通信、緑がデータ通信、オレンジがマッピング通信(これも制御通信)


戻りの通信については、

RT1(ITR)からMap Requetを受信することによって送信元MappingがRT2(ETR)にわかるので、RT2からMSへのMap Requestは送信されずに即encap&パケット転送が行われるのではないかと思う。


これは実際に確認した通信ではなく聞いた話を整理したものである。

整理してわかったのは、IngressとEgressが、通常の通信と逆であるということである。

通常は拠点のルータはLANからWAN向けの通信がEgress, WANからLAN向けの通信がIngressとなるが、LISPにおいては方向が逆になる。

GRE tunnel

 

  
RT2


interface Loopback0
 ip address 22.22.22.22 255.255.255.255
end
!
interface Tunnel1
 ip address 7.7.7.1 255.255.255.252
 tunnel source 10.10.0.1
 tunnel destination 10.20.0.1
end


ip route 10.20.0.0 255.255.255.0 10.10.0.2
ip route 33.33.33.33 255.255.255.255 Tunnel1
RT3


interface Loopback0
 ip address 33.33.33.33 255.255.255.255
!
interface Tunnel1
 ip address 7.7.7.2 255.255.255.252
 tunnel source 10.20.0.1
 tunnel destination 10.10.0.1
end

ip route 10.10.0.0 255.255.255.0 10.20.0.2
ip route 22.22.22.22 255.255.255.255 Tunnel1




time-rangeでSaturday Sunday 0:00 to 23:59 とすると

 衝撃の事実....

ciscoルータやswitchで、time-rangeという設定がある。

これを使うと、例えば週末だけ特定の通信を拒否するとか許可するとかの設定ができる。


time-rangeというコマンドなのだが


たとえば、


time-range TEST
periodic Monday 9:00 to 18:00

とすると、月曜日の9時から18時になる。

そして、拡張aclで、そのtime-rangeを指定することができる。

access-list 1 permit 192.168.1.0 0.0.0.255
access-list 100 permit ip host 192.168.1.1 host 100.0.0.1 time-range TEST

timerangeでは、曜日のほかに、daily, weekdays, weekendなどが指定できる。 ここまでは、「へー、そんな機能があるんだ」で済む話だ。 

問題はこれからだ。 


この機能を使って、週末だけ特定の通信を拒否することにした。 

weekendという設定があるのでそれを使えばよいとは思ったが、 

 「土曜日の0:00~日曜日の23:59」という風に定義した方が間違いないと思い、

time-range Shumatsu
periodic Saturday Sunday 0:00 to 23:59

という設定を入れた。「weekendとかいらないじゃん」


後日、後輩から、「先輩、time-rangeでweekendなんて使えるんですね」 と言われて、

そんな設定したおぼえはないとshow runをして愕然とした。

time-range Shumatsu
periodic weekend 0:00 to 23:59


Saturday Sunday とすると、weekendに置き換わるのだ.....