サイトマップ

サイトマップ » A

Apacheで、一部のコンテンツにホスト名(ダイナミックDNS)でアクセス制限したい
【結論】・条件 Apacheバージョンが2.4.19以上の場合Require forward-dnsが使えます。設定例） Require forward-dns test.example.jptest.example.jp のIPアドレスで制限をかける事が可能です。 WEBコンテンツで、一部の人にしか見せたくない、自分(管理者)だけしか見せたくない、アクセスさせたくないコンテンツがあります。特定の人だと、ユーザー/パスワード認証とか、クライアント証明書による認証とかになると思うのですが、IPアドレスレベルで良いと言った場合に、 Apacheの場合は、<Directory "/var/www/html/secret"> Options hogehoge AllowOverride foo Require ip 192.168.1.1 Require host test.example.jp</Diredctory>Require ip や Require host で制限を書いてきました。でも、アクセス元IPアドレスが動的IP（プロバイダからのグローバルIP配布）の場合は、Require
Azure RockyLinuxを初期構築直後、sshログインできない
Azureの仮想マシン構築時に、RockyLinux8を入れたつもりが、RockyLinux9でした。※ 色々試した訳ではないので、Microsoft側のOSイメージのリンクミスなのか、画像の表示ミスなのかは不明です ※ 2022/10/13 21:40(JST)現在、イメージは正しく差し変わりました。※ やはり、RockyLinux8で動かしたいと思ったので、再度イメージ確認していたところ、イメージ選択表示文言が変わっていたので、再インストールしてみたところ、RockyLinux8になりました！ RockyLinux9のイメージが変更されているか(RSA鍵でログインできるのか)未確認の為、一応、以下の情報は残しておきます。出来る限り安価にする為に、こちらを選択しました。インストール完了すると、 RockyLinux8を選択したのに、Linux (Rocky 9.0) と表示されている。しかも、TeratermでSSHログイン(鍵認証)を行ってもログイン出来ない！！【状況】 Teratermから鍵認証(仮想マシン構築時に作成)を使ってSSHログイン操作を行った。IDとパスフレーズ(なし)と鍵ファイルを指定してログインしようとしても、ログインが拒否される。再度、鍵ファイルを指定しなおしたり、TeraTermを終了して立ち上がなおし、再度ログイン操作を行うも、ログインが拒否される。初期構築後に1回もリモートログイン出来ない事態となった。【ログイン出来ないと調べようがないので・・・】このような状況に陥った方、結果的に方法はいくつかあります。(方法1) 仮想まシンを再構築する鍵認証で入れないのなら、「認証の種類」で「パスワード」を選択して再構築する。(方法2) RSAアルゴリズム以外の鍵を作成して、Azureの管理画面で、「SSH 公開キーのリセット」で置換する(方法3) Azureの管理画面で、パスワードでSSHログイン出来るように変更する。-「構成のみのリセット」を行い、「パスワードのリセット」を行う(方法4) Teratermではなく、別のSSHクライアントソフトを利用する。- 現段階(2022/10/09時点)での私の認識では、TeraTerm(4.106)は rsa-sha2-256/512に対応していないからではないかと想定- Linux(Rocky8)から、Azureの仮想マシンにログインしたらログインできました。Azureの管理画面で「パスワードのリセット」でパスワードを設定し、Azure管理画面のシリアルコンソールからログインして設定変更する方法もあります。【ログインしてみたら・・・】中身は、RockyLinux9になってました。SSHログイン出来ない理由として、/var/log/secureには、　　userauth_pubkey: key type ssh-rsa not in PubkeyAcceptedAlgorithms [preauth]と出てて、ググりました。 ssh-rsaが無効になるから、鍵ファイルの変更など行わないといけないよ～みたいな記事がHit。ただ、OpenSSHのバージョンは、openssh-server-8.7p1-8.el9鍵アルゴリズム ssh-rsaが使用出来なくなるのは、openssh
AntiVirusソフト(Dr.WEB Linux版)のライセンス(新規)登録について
RockyLinux8にて、Dr.WEBのトライアルライセンスを入手し利用してみたが、ソフト自体がリソースを圧迫するなどの事もなかったし、Linux対応のAntiVirusソフトが他に見つからなかった事もあり、Dr.WEBの正規ライセンスを購入した。 (1) オンラインストアからの購入 https://estore.drweb.co.jp/home/購入の仕方は、他社のオンラインストアでの操作方法と変わらない。オンラインストアにてクレジットカード等にて購入/決済が完了すると、購入時に登録したメールアドレスへ「シリアルコード」が記載されたメールが到着する。 ※ ここで登録するメールアドレスは、Dr.WEBの個人向けポータルサイトにログインしたり、 Dr.Webキーファイル入手の際にも使われるので、捨てアド（捨て垢）等は注意してください。 ※ 購入時に、ライセンス期間とPC台数を入力するが、例えば、1年、PC2台で購入すると、シリアルコードが１つ発行される。有効期限はシリアルコード毎となり、PC毎の有効期限では無い事に注意が必要。 → 1台目 : 2023/01/01 使用開始 2台目 : 2023/02/01 使用開始と、時期をずらしても有効期限は、2台とも 2024/12/31 となる。 (2) 使用開始日にDr.Webキーファイルの取得を行う。ソフト上にライセンスを付与する方法は、Dr.Webキーファイルを取り込む事で登録する。この、Dr.Webキーファイルを入手するhttps://products.drweb.co.jp/register/v4/ 上記URLより、メールで到着した「シリアルコード」を登録すると、Dr.Webキーファイルが発行される。Dr.Webキーファイルは、上記URLから登録直後に表示されるリンクからもダウンロード可能だが、登録したメールアドレスにも到着する。 ※「シリアルコード」を登録（ Dr.Webキーファイルを発行した）時点で、ライセンス使用開始となる。よって、「シリアルコード」は先行して購入していても問題ないが、ソフト使用開始直前に、「シリアルコード」を登録したほうが良い。 → ライセンス使用開始は、ソフトにDr.Webキーファイルをインポートした時点ではない！ (3)
AntiVirusソフト(Dr.WEB Linux版)のライセンス(更新)登録について
(1) オンラインストアからの購入 https://estore.drweb.co.jp/renew/更新を行う為のライセンスは、2通りの方法が存在する。・新規ライセンスを購入して、更新用ライセンスとして使用する → (新規登録操作ではなく) 特定の操作を行う事で、ライセンス期限が+150日追加される → 既存ライセンス有効期限が切れていないこと → 既存シリアルコートを入力する必要がある → 価格は新規ライセンス価格だが、150日追加されることで更新割引価格と同等の値段設定・更新用ライセンスを購入する → 既存ライセンス有効期限が切れていないこと→ 既存シリアルコートを入力する必要がある→ 購入価格は、更新割引価格(1年の場合、40%割引)が適用される。 → 更新用ライセンスは、既存シリアルコードをベースにする為、PC台数は変更出来ず、ライセンス期間のみ変更可能（1年/2年/3年）著者は、後者を選択。上記URLより、既存のシリアルコード、新規登録時に入力したメアドを入れて購入。メールに、新しいシリアルコードが到着した。 (2) 新しいシリアルコードの登録結果から先に言うと、この操作を行えばライセンス更新作業は終了する。Dr.Webキーファイルのダウンロード、メールでもDr.Webキーファイルが添付ファイルで受信したが、このファイルを使うことなく、ライセンス期間が延長された。 [状態]対象サーバーは、　　・ライセンス有効期限は切れていない状態・インターネットへ公開(外部へのアクセスが可能状態) https://products.drweb.co.jp/register/v4/にて、新しいシリアルコードを登録。次の画面にて、既存のシリアルコードがあるかどうか聞かれる。この画面にて、既存のシリアルコードを入れると、既存ライセンスの有効期限から、契約年数分が付与されたライセンス状態となる。・ Dr.Webキーファイルのダウンロード・メールでも、Dr.Webキーファイルが到着している事を確認著者の場合、有効期限が2023-09-07 で、2023-08-30に1年2台のライセンス購入。この作業を実施したところ、Dr.Webキーファイル内の有効期限は、2024-09-07 となっていた。既存のライセンス有効期間が反映されていた。 (3) Dr.Webキーファイルを差し替えしようと思ったら・・・念のため、作業前に#
apache2でHTTP PUTすると、405 Method Not Allowed
どのバージョンから規制されたのか不明ですが、以下の記事によるとdefault_handler()は、GET/POST/OPTIONS以外は、受け付けないようになっているらしい。https://www.softel.co.jp/blogs/tech/archives/5685 セキュリティの観点から、Limitディレクティブを使って、GET/POTのみ受け付けるように制限をかける事が言われていて、Googleと、それらの記事も多くHitする。ただ、どの記事も日付が古い。Apache(httpd)側で対策したから、わざわざ制限を加えなくても良いとの観点だろう。今回、ファイルをサーバー側に置いて処理させる要件が出て、HTTPかSCP/SFTPのどちらかで実装だろうな・・・と思っており、HTTP PUTのほうが単純で(実装が)楽じゃね？と思った次第。当初は、httpd.confでPUTメソッドを許可する設定を書けば良いと思っていた。だが、難航極まりない。結局、行き着いたのが上記URLで、設定では許可出来無さそうだった。その記事で「Scriptディレクティブで設定するのが簡単」とあったので、やってみた。 *** 注意 ***以下にサンプルスクリプトを掲載するが、あくまでサンプル。そのままコピペして公開サーバーで実装しないで欲しい。公開サーバーへ実装を予定されている場合は、実装予定のサーバーの環境に応じて、有識者がスクリプトのセキュリティ診断を行うなど対応が必要である。〇試した環境・ WEBサーバー (192.168.100.100) Debian GNU/Linux 11 Debian 5.10.197-1 (2023-09-29) x86_64 apache2 2.4.56-1~deb11u2 perl v5.32.1・クライアント (192.168.100.1) Rocky Linux 8.9 4.18.0-513.5.1.el8_9.x86_64