zuntan02のはてなブログ

備忘録的なものです。時々職場の技術者ブログにも転記してますが、メインはこちらで。

（メモ）Apacheでダイジェスト認証

【参照】

qiita.com

曰く

Basic認証はユーザ名とパスワードをBase64エンコードしたものを使う認証で、
Digest認証はユーザ名とパスワードをMD5でハッシュ化したものを使う。

なるほどDigestのほうがよさそう。

【手順】

1)モジュールの確認
apachectl -M | grep digest

で auth_digest_module (shared)　が出てればOK.
→無いときはhttpd.confでいかがコメントアウトされていないか、とか
# LoadModule auth_digest_module modules/mod_auth_digest.so
/etc/httpd/modules の下あたりを確認する
2)htdigestコマンドでパスワードファイルを作成
htdigest [-c] パスワードファイル名 領域名 ユーザー名
  • オプション：初回のみ-cで作成。追加する場合はオプションなし。
  • 領域（レルム）名：下記confで「AuthName」に指定する文字列を設定

例）

htdigest -c /etc/httpd/conf/.htdigest 'Secret Zone' hogeuser
3)ApacheのconfファイルにDigest認証の設定を追記

ユーザー認証によるアクセス制限をかけるディレクトリ

/var/www/html/member

の場合、Apacheの設定ファイル(/etc/httpd/conf.d/hoge.confなど）

<Directory "/var/www/html/member">
    AuthType Digest
    AuthName "Secret Zone"
    AuthUserFile /etc/httpd/conf/.htdigest
    Require valid-user
</Directory>

# もしくは

<Location />
    AuthType Digest
    AuthName "Secret Zone"
    AuthUserFile /etc/httpd/conf/.htdigest
    Require valid-user
</Location>
4)Apacheを再起動して再起動。

2020年04月版：10万円以下のPC、迷ったらこれを買え！メモ

[課題]

エンジニア向けに配布するPC、10万円以下でどれがいい？
→開発環境をローカルで立てることが多くなった（Dockerで開発）のでCPUの性能とメモリが最優先。

[具体的なスペック]

  • CPU 4Core8Thread以上のCPU

具体的には、CinebenchR15で single=150 Multi=750 以上

  • メモリ 16GB以上
  • ストレージ 512GB以上のSSD

※CPUベンチは以下のサイトを参照のこと：
https://chimolog.co/bto-cpu-list/

[上記を踏まえた2020年お勧めノート]

Lenovo IdeaPad C340

※10万円未満だとこれが一番マシかな……という感じ。


  • CPU、i7-10510U(4C8T)、メモリ16GB、ストレージ1TB
  • 税込：96,800
  • メリット：そこそこの性能。大変コスパがよい。タッチパネルも案外使える。
  • デメリット：納期が4週間～。急ぎの時はNG。必要十分な入出力だが、LANポートがないのでほしかったら別途USB-C有線LANアダプタとか買う必要がある。
（参考）ホントはこれくらいほしい

DELL XPS13

  • CPU、i7-10710U(6C12T)、メモリ16GB、ストレージ512GB(NVMe)
  • 税込：168,325

DNS「逆引き」に関する俺理解メモ

以前
http://zuntan02.hateblo.jp/entry/2017/03/17/112857
という記事を書いたが、そもそもメールサーバで設定する「逆引き」とは何なのか。
今朝もう一回調べて以下の腹落ちに達したので自分のためにメモを残します。

【メール送信元サーバが逆引き設定されていないとどんなことが起こるか】

この記事を書くに至った原因、2019年12月、それまで5年以上問題なく送信を受けてくれていたGmailサーバから突然はじかれるようになった。

以下qmailのsendログより：

2019-12-xx xx:xx:xx.xxxxxxxxxx delivery xxxxxxx: failure: 64.233.189.27_failed_after_I_sent_the_message./Remote_host_said:_550-5.7.26_This_message_does_not_have_authentication_information_or_fails_to/550-5.7.26_pass_authentication_checks._To_best_protect_our_users_from_spam,_the/550-5.7.26_message_has_been_blocked._Please_visit/550-5.7.26__https://support.google.com/mail/answer/81126#authentication_for_more/550_5.7.26_information._xxxx_-_gsmtp/

上記参照URLによれば以下の設定が必要

IP のガイドライン
    送信元 IP には PTR レコード（送信元 IP の逆引き DNS）が必要です。また、PTR レコードで指定されているホスト名の DNS の正引き解決によって取得した IP と一致している必要があります。
    送信元ドメインは、SPF チェックまたは DKIM チェックにパスする必要があります。

spfレコードは設定してあったが、逆引きが設定されていないサーバであったため、レンタルサーバ会社に逆引き申請を実施
※さくらの専用サーバの場合：https://help.sakura.ad.jp/206252881/#ac02

逆引きが設定された直後にエラーは止まり、Gmailへのメールが届く様になった。
逆引き重要ですね！

【注意】

ここではメール送信に関する狭義での「正引き・逆引き」についてメモしています。
勉強中のため不正確な記述があり、また不定期に追記・修正あります.

【基本情報】

https://ja.wikipedia.org/wiki/%E9%80%86%E5%BC%95%E3%81%8D
http://akisoftware.com/pmsrv/help/revdns.html

【正引き・逆引きとは】

  • 正引き：ホスト名（ドメイン名）からIPアドレスを引き出すこと
  • 逆引き：IPからホスト名を引き出すこと

【確認方法】

# 正引き
nslookup ホスト名
または
dig ホスト名

# 逆引き
nslookup IPアドレス
または
dig -x IPアドレス

【DNS逆引きレコード(PTRレコード)登録方法】

  • （前提）正引きレコード正引きレコード(Aレコード)でmail.hoge.com　が逆引きしたいIPで登録されている

通常、サーバホスティング業者(AWSの上限緩和申請やさくらのクラウドのコンパネなど)の方で逆引き設定申請パスがあり、申請時に正引き設定されていれば逆引き設定がなされる。
※具体的にはipアドレスを逆に並べた後.in-addr.arpaを付けたアドレスのPTRレコードが生成される
例）

# 正引き
dig mail.hoge.com
mail.hoge.com.       xxxx    IN      A       xxx.xx.xxx.xx

# 逆引き
dig -x xxx.xx.xxx.xx
xxx.xx.xxx.xx.in-addr.arpa. xxxx IN     PTR     mail.hoge.com.

【なんでメール送信元は逆引きできるといいのか】

  • 逆引きはメール送信元サーバ（IP)の信頼性を高める作業

逆引きが出来るホストからのメールの送信のみを受け付け、それ以外からは受け付けないようにすると、身元が不明な（DNS に登録されていない） IP からメールの受信を拒否することにより 一定量の spam を防げる、という発想

【さくらのレンタルサーバー】メールサーバ（サイトと同一ドメイン）がさくら以外のものを利用していた場合に、サーバからのメールが届かない

【問題】

・Wordpressサイト（www.hoge.jp）：さくらのレンタルサーバ
・DNSレジストラ：さくらインターネット管理の独自ドメイン(お名前などで取得した場合は以下対応不可なので注意）
・メールサーバ（hoge.jpのMXレコード向き先）：G Suiteなど外部メールサーバ
といったような環境で、Wordpressからcontact@hoge.comへのメールを飛ばそうとするとメールが届かない。
下記参照記事より、同一ドメインの場合にMXレコードを見てくれず、外部のメールサーバに到達できない問題があることが判明。

【対応】

さくらのレンタルサーバー管理画面にて

 [ドメイン/SSL設定]
→[hoge.jp]-[変更]
→[3. メール利用をお選びください]
→[このドメイン宛のメールは別のサーバで受信する （上級者向け）]にチェックを入れて反映

でOK

【参照URL】

https://www.evoworx.co.jp/blog/domain-mail-problem/
https://web-memo.net/domein/sakura-form-mail/
https://help.sakura.ad.jp/206078622/

【注意】

ドメインをお名前.comなどで取得していた場合は、上記

[このドメイン宛のメールは別のサーバで受信する （上級者向け）]

にチェックを入れることができないため対応不可能。解決方法あれば追記します。

3-8.cosmofield.com

以上。

【gitlab】gitlabに特定のIPから接続しようとするとForbiddenになったのでホワイトリスト対応したメモ

【サマリ】

AWS　EC2上で運用していたgitlabサーバに、特定のIPからのみ接続できない、Forbiddenになる、一度Forbiddenになると2時間くらい接続できない、との指摘あり。
Dos攻撃対策が効きすぎていた模様。ホワイトリストに乗せて回避する。

【参照】

https://qiita.com/smallpalace/items/fe6144fe9b981b62742c
GitlabがFobbiden表示で見られなくなったら
https://press.crazy-nakada.fun/git/26/
Gitlabがforbidden　アクセス不可に

【詳細】

/var/log/gitlab/gitlab-rails/production.log

Rack_Attack: blacklist <問題のIP> GET /hoge/fuga?service=git-upload-pack
Rack_Attack: blacklist <問題のIP> GET /hoge/fuga?service=git-upload-pack

→Dos攻撃対策としてブラックリスト登録されてはじかれている模様

# gitlab.rbのホワイトリストを有効化してTMの関連IPを追加

diff /etc/gitlab/gitlab.rb /etc/gitlab/gitlab.rb_org

285,291c285,291
< gitlab_rails['rack_attack_git_basic_auth'] = {
<   'enabled' => true,
<   'ip_whitelist' => ["127.0.0.1","<接続元IP1>","<接続元IP2>"],
<   'maxretry' => 10,
<   'findtime' => 60,
<   'bantime' => 3600
< }
---
> # gitlab_rails['rack_attack_git_basic_auth'] = {
> #   'enabled' => true,
> #   'ip_whitelist' => ["127.0.0.1"],
> #   'maxretry' => 10,
> #   'findtime' => 60,
> #   'bantime' => 3600
> # }

# 反映
gitlab-ctl reconfigure

以上

AWS Client VPN使ってみた

筆者の理解の度合い

PC→AWS VPCへの接続をVPNできるもの
料金（https://aws.amazon.com/jp/vpn/pricing/）日本で$115/月～になるっぽい。安くはない

参考

[AWS]踏み台をワンチャンなくせる！？VPC接続にClient VPNを使ってみよう ｜ Developers.IO
クライアント VPN の使用開始 - AWS Client VPN
AWS Client VPNでAWS以外への通信をローカルに流す(openvpn、TunnelBlick) ｜ Developers.IO

上記の手順通りにやってみた。

以下TunnelBlickに詳しくないのでその辺追記していますがほぼそのままです

作業メモ

■作業環境：macOS
■VPN接続ソフト：Tunnelblick

ステップ 1: サーバーおよびクライアント証明書とキーの生成
# easy-rsaで証明書作成していく
git clone https://github.com/OpenVPN/easy-rsa.git
cd easy-rsa/easyrsa3
./easyrsa init-pki

# 認証機関 (CA) を構築
./easyrsa build-ca nopass
Common Name (eg: your user, host, or server name) [Easy-RSA CA]:zuntan02

# サーバ証明書とクライアント証明書を作成
./easyrsa build-server-full server nopass
./easyrsa build-client-full client1.domain.tld nopass

# openVPN設定ファイル用dkimディレクトリを作成して諸々配置
mkdir ~/Desktop/zuntan02.dkim/
cp pki/ca.crt ~/Desktop/zuntan02.dkim/
cp pki/issued/server.crt ~/Desktop/zuntan02.dkim/
cp pki/private/server.key ~/Desktop/zuntan02.dkim/
cp pki/issued/client1.domain.tld.crt ~/Desktop/zuntan02.dkim/
cp pki/private/client1.domain.tld.key ~/Desktop/zuntan02.dkim/

# キーをACMに登録する
※サーバー証明書は AWS Certificate Manager (ACM) でプロビジョニングする必要がある
[CertificateManager]-[プライベートCA]-[証明書のインポート]
サーバー証明書

  • 証明書本文：server.crt
  • 証明書のプライベートキー：server.key
  • 証明書チェーン：ca.crt

の中身を貼り付ける

クライアント証明書

  • 証明書本文：client1.domain.tld.crt
  • 証明書のプライベートキー：client1.domain.tld.key
  • 証明書チェーン：ca.crt

の中身を貼り付ける

ステップ 2: クライアント VPN エンドポイントを作成する

[VPC]-[クライアント VPN エンドポイント]-[クライアント VPN エンドポイントの作成]
[名前]：てきとう
[Client IPv4 CIDR (クライアント IPv4 CIDR)]192.168.0.0/16（例）
[Server certificate ARN (サーバー証明書 ARN)]
→上記でACMに登録したサーバー証明書を指定
さらに[Use mutual authentication (相互認証の使用)] を選択、
[クライアント証明書 ARN]
→上記でACMに登録したクライアント証明書を指定

あとは初期値のままで[クライアント VPN エンドポイントの作成]

ステップ 3: クライアントの VPN 接続を有効にする

[VPC]-[クライアント VPN エンドポイント]-VPN エンドポイントを選択
[関連付け]-[関連付ける]-[VPC]
接続するVPC を選択

ステップ 4: クライアントのネットワークへのアクセスを承認する

[VPC]-[クライアント VPN エンドポイント]
承認ルールを追加する クライアント VPN エンドポイントを選択し、
[Authorization (承認)]-[Authorize ingress (受信を承認する)]
[Destination network (送信先ネットワーク)]
例）172.31.0.0/16
[For grant access to (アクセス許可の付与)] で [Allow access to all users (すべてのユーザーにアクセスを許可する)]

ステップ 5: (オプション) 追加のネットワークへのアクセスを有効にする

省略

ステップ 6: クライアント VPN エンドポイントの設定ファイルをダウンロードする

[VPC]-[クライアント VPN エンドポイント]-[Download Client Configuration (クライアント設定のダウンロード)]
→ovpnファイルが得られるので先ほど作成したdkimディレクトリの中に配置

# ovpnファイルの編集
~/Desktop/zuntan02.dkim/client-config.ovpn

# 以下を追記

cert client1.domain.tld.crt
key client1.domain.tld.key

pull-filter ignore redirect-gateway
route 172.31.0.0 255.255.0.0   #接続先VPCのCIDR

（参考）https://dev.classmethod.jp/cloud/aws/aws-client-vpn-other-network/

dkimフォルダをダブルクリックすることでtunnelblickに追加されるので接続してみる
→OK!

追加

さいしゅうてきにはNATGWをつけてすべての送出をClientVPN経由で出ていくというのもあり。
料金とかどうなるかな・・・
[AWS Client VPN] VPC を経由して固定のIPでインターネットへアクセスする ｜ Developers.IO