できるの知らなかった。。。
https://win2012r2.com/2021/07/24/windows-netsh-trace/
→netshを使う方法
https://milestone-of-se.nesuke.com/knowhow/wireshark/pktmon/
→pktmonコマンドを使う方法
NISTガイドラインでの要求事項の度合いの記載について
SHALL/SHALL NOT
→しなければならない、してはならない。
ガイドラインに準拠するために厳格に従うべき
SHOULD/SHOULD NOT
→すべきである、すべきでない
いくつかの選択肢では推奨されるが必須でない
推奨しないが、禁止もしない
MAY/NEED NOT
→してもよい、しなくてもよい
★ポイント★
SHALLは厳格
MAYはどっちもオッケー
SHOULDは中間 ※必須でない
セキュリティ用語メモ
任意アクセス制御 discretionary access controll
→所有者にアクセス制御管理を委ねる
強制アクセス制御 mandatory access controll
→管理者が強制
セキュアOSは強制アクセス制御
→selinux等
ダウングレード攻撃
→通信主体者間で決定される暗号アルゴリズムを、脆弱なものに強制変更させる攻撃
主体認証の要素は3つあり。
知識
所持
身体的な特性
2つの要素を使った認証を２要素認証
2つ以上の要素を使った認証を多要素認証
同一要素で複数使うのは２要素認証ではない
同一要素を2回にわけて使うのが2段階認証
2段階認証より、2要素認証の方が、使う要素の種類が多いので強度は高い
2段階認証の例）パスワード認証後にメール等の確認コードで認証など。どちらも知識認証。ショートメッセージの場合は、所有認証の要素も入るので、2要素認証になる。
OOB認証
out of band認証
インターネットを使わない認証。ショートメッセージ等
インターネットのみで２要素やるよりセキュア
パスワードとパスフレーズとPINの違い
パスフレーズはパスワードより長い文字列（20文字程度）
PINはpersonal identification numberの略で、パスワードとの違いは、PINで入力した情報がネットワークを流れない点。PINを入力したデバイス内で認証される。ケースによっては、端末内部で認証され、その認証機能により生成された認証情報がネットワークを流れる事はある。
PINは上記特性から、所持の要素があり、所持と知識の２要素認証となる為の、単純なID/PW認証よりセキュアとされる
https://www.itmedia.co.jp/news/spv/1902/20/news014.html
〜引用ここから〜
ATMでキャッシュカードやクレジットカードを使う場合は、カードに内蔵されたICチップの中にあるPIN情報との照合を、ATM端末を通じて行う
この照合の結果、合致すれば端末・ICカード内のデジタルな認証情報が取り出され、その情報だけがネットワークを通じてサーバに伝達され、サーバ上で再度認証が行われる。
認証情報だけが伝達される仕組みなので、PINそのものは端末からネットワークに流出しない
〜引用ここまで〜
メモリハード関数とは？
パスワード解読の攻撃コストを高くする為のハッシュ関数
例）
https://mining.cryptech.co.jp/media/uncategorized/equihashu%EF%BC%88%E3%82%A4%E3%82%AF%E3%82%A4%E3%83%8F%E3%83%83%E3%82%B7%E3%83%A5%EF%BC%89%E3%82%A2%E3%83%AB%E3%82%B4%E3%83%AA%E3%82%BA%E3%83%A0%E3%82%92%E7%9F%A5%E3%81%A3%E3%81%A6%E5%8A%B9%E7%8E%87/1435.html
Windows OSの認証
以下2つのタイプがあり。
LM（LAN MANAGER）
NTLM（NT LAN MANAGER ）
共にDES（共通鍵暗号）を使って不可逆変換をしている。※仕組みは不明
NTLMv2は、hmac-md5（ハッシュ生成）も使っている。
LMはサーバーからのchallenge/responseのみ
NTLMv2はサーバーからのchallenge/responseに加え、クライアントからchallenge/responseもあり。
windows NT4.0以降はNTLMv2
レインボーテーブルとは？
あらかじめ計算済みのハッシュテーブルを用いて、高速にハッシュを解析するツール
単純なハッシュ値と平文文字列の対応表でなく還元関数という特殊な関数を利用して、対応表のサイズを圧縮している。
ＷireShark便利機能メモ
➀ "統計"→"TCPストリームグラフ"
➁パケットロス確認
tcp.analysis.lost_segment
tcp.analysis.ack_lost_segment
tcp.analysis.flags && !tcp.analysis.window_update
https://troushoo.blog.fc2.com/blog-entry-165.html
https://hirotanoblog.com/wireshark-filter/8191/
③統計→フローグラフ→TCP Flows
④列の追加
⑤csv出力
PDFファイルにデジタル署名をつけるで悩んだ
参考
完全図解！PDFファイルに電子署名をする方法！
証明書ベースの署名、Adobe Acrobat
Adobe Acrobat の証明書署名について
悩んだ点
PDFに電子署名をつける仕組みについて悩んだ。
完全図解！PDFファイルに電子署名をする方法！
上記読み、以下理解をした。
・送信側は自分用の証明書を発行してもらってる。(秘密鍵 & 公開鍵含む証明書)
・送信側は秘密鍵でPDFファイルにデジタル署名を付与する。
・送信側は公開鍵を含む証明書を、エクスポートして事前に受信側に渡す。
・受信側は証明書をインポートする事で、公開鍵をゲットでき、PDFに付与されたデジタル署名の検証ができる。
この考えだと、証明書発行機関や、組織のPKIシステムが発行する証明書を使ったとしても、受信側に送信側の公開鍵をインポートする必要がある。
こんな不便な仕組み？？？なわけない！でも、仕組みはどうなってるの？と悩んだ。
ポイント！！
証明書ベースの署名を適用すると、Acrobat はハッシュアルゴリズムを使用してメッセージダイジェストを生成し、署名者の秘密鍵を使用し それを暗号化しますAcrobat は、この暗号化されたメッセージダイジェストを、証明書の詳細、署名の画像、および署名された時点での文書のバージョンと共に、PDF に埋め込みます。
→「証明書の詳細」の中に、公開鍵も含まれる！なので、公開鍵もPDFに付与されるって事！
では、以下URLの「受信側で、この証明書を「信頼済みルートとして使用」とする。」は何か？
完全図解！PDFファイルに電子署名をする方法！
公開鍵を渡すことと誤解してた。公開鍵はPDFについてるので渡す必要なし。
公開鍵を渡すのでなく、証明書を信用する為に、ルート証明書を渡す操作だった。
受信側が署名付PDFを検証するときは、以下をしてるのだろう。
・PDFに付与された証明書は信用できる？証明書のデジタル署名を検証しよう！(シグニチャが複号できるか？)
・信頼済ルート登録済みなら、複号できるので信用する。
・証明書の中の公開鍵の情報を使って、PDFに付与されたデジタル署名を検証する。(シグニチャが複号できるか？)
・複号できたら、信用できる。ハッシュチェックして改ざんもチェック
上記は自己署名の場合。
証明書発行機関や、組織のPKIシステムが発行する証明書を使ってる場合は、以下になる。
・ユーザーA,Bは、それぞれ自分用の証明書を発行してもらってる。(秘密鍵 & 公開鍵含む証明書)
ユーザーAが送信側、ユーザーBが受信側だとする。
・ユーザーAがPDFファイルに秘密鍵で署名をする。(自分の公開鍵含む証明書も付与)
・ユーザーBは署名付PDFファイルについてる証明書を検証する。同じPKIから発行された証明書なので、自分の信頼できるルートで検証成功。
・証明書を信用できるので、その中の公開鍵を使って、PDFの署名を検証する！
この流れだろう！組織のPKIの場合、PDFソフトウェアの信頼できるルートにデフォルトでは登録されてないので、最初にルート証明書の登録が必要。
デジタル署名の考え
暗号化技術メモ - pikesaku’s blog
・メッセージをハッシュアルゴリズムでハッシュ化し、秘密鍵で暗号化したものがシグニチャ
・メッセージ、ハッシュアルゴリズム、シグニチャこの3点の情報で改ざん検知をする
・メッセージが改ざんされても、受信側でシグニチャ見て改ざん検知できる。
ただ、中間者攻撃で、3点情報全て書き換えられると検知できない。
・シグニチャが複号できる=信頼する。なので、3点全て書き換えられた場合、シグニチャが複号できない＝信用できない=改ざんって判断になる。
・デジタル署名的に、シグニチャ複号できるは必須なのだろう。
・証明書は公開鍵を安全に配布する仕組み。「安全に」はデジタル署名によるもの。
・証明書には以下情報が含まれる。
証明書情報(公開鍵含む) ※デジタル署名の考え的には、メッセージ
ハッシュアルゴリズム
シグニチャ(メッセージをハッシュアルゴリズムでハッシュ化したデータを証明書の発行者の秘密鍵で暗号化)
・証明書を配布する時に、受信者はシグニチャが複号できる=信頼できる発行機関からのものと判断する。あと証明書自体の改ざんチェックもする。
IPSEC-VPN経由のスループット検証メモ(QoS設定時)
参考
26.2 クラス分けのためのフィルター設定
トンネルインタフェースでのQoS
http://www.rtpro.yamaha.co.jp/china/support/download/manual/Rev.9.00.20/Cmdref_j.pdf
※RT107e は帯域制御は未対応。優先制御は対応。
動作確認
PingのRTT
# ping -s 1472 192.168.100.251 -c 1 > /dev/null 2>&1 ; ping -s 1472 192.168.100.251 -c 50 | tail -2 50 packets transmitted, 50 received, 0% packet loss, time 49070ms rtt min/avg/max/mdev = 25.276/25.383/25.554/0.058 ms
# iperf3 -c 192.168.100.251 -l 1252 -u -b 70M -t 30 | grep -B4 "iperf Done." warning: UDP block size 1252 exceeds TCP MSS 1228, may result in fragmentation / drops [ ID] Interval Transfer Bitrate Jitter Lost/Total Datagrams [ 5] 0.00-30.00 sec 250 MBytes 70.0 Mbits/sec 0.000 ms 0/209659 (0%) sender [ 5] 0.00-30.45 sec 3.32 MBytes 913 Kbits/sec 0.125 ms 206806/209583 (99%) receiver iperf Done.
QoS動作確認
以下動作を確認
①ホストAからホストBにiperfでTCP通信発生させ、1Mb/s前後のスループットを確認。
②①実行中にホストAからホストBにiperfでUDP通信を発生させる。
③①のTCPは転送されなくなり、②で1Mb/s前後のスループットを確認。
ルータコンフィグ
ルーターA
login password * administrator password * login user pike * console character ascii login timer 300 ip route 192.168.100.0/24 gateway tunnel 1 ip lan1 address 192.168.0.1/24 speed lan2 1m queue lan2 type priority ip lan2 address 192.168.200.1/24 provider lan1 name LAN: tunnel select 1 ipsec tunnel 101 ipsec sa policy 101 1 esp aes-cbc sha-hmac anti-replay-check=off ipsec ike keepalive log 1 off ipsec ike keepalive use 1 on heartbeat ipsec ike local address 1 192.168.200.1 ipsec ike pre-shared-key 1 * ipsec ike remote address 1 192.168.200.2 queue tunnel class filter list 1 ip tunnel tcp mss limit auto tunnel enable 1 ipsec auto refresh on queue class filter 1 4 ip 192.168.0.250 * udp * * dhcp service server dhcp server rfc2131 compliant except remain-silent dhcp scope 1 192.168.0.11-192.168.0.150/24 sshd service on sshd host key generate *
⭐️ポイント⭐️
queue class filter 1 4 ip 192.168.0.250 * udp * *
上記の4はクラスを示す。フィルタにマッチしない通信は2になる。クラスが高いのが優先される。
最初1にして動確できず、ちょいはまりした。。。
ルーターB
login password encrypted * administrator password encrypted * login user pike * console character ascii login timer 300 ip route 192.168.0.0/24 gateway tunnel 1 ip lan1 address 192.168.100.1/24 speed lan2 1m queue lan2 type priority ip lan2 address 192.168.200.2/24 tunnel select 1 ipsec tunnel 101 ipsec sa policy 101 1 esp aes-cbc sha-hmac anti-replay-check=off ipsec ike keepalive log 1 off ipsec ike keepalive use 1 on ipsec ike local address 1 192.168.200.2 ipsec ike pre-shared-key 1 * ipsec ike remote address 1 192.168.200.1 queue tunnel class filter list 1 tunnel enable 1 ipsec auto refresh on queue class filter 1 4 ip 192.168.100.251 * udp * * dhcp service server dhcp server rfc2131 compliant except remain-silent dhcp scope 1 192.168.100.2-192.168.100.191/24 sshd service on sshd host key generate *
postgresバックアップ
参考
https://www.fujitsu.com/jp/products/software/resources/feature-stories/postgres/backup-recovery/
https://www.postgresql.jp/document/9.1/html/continuous-archiving.html
https://qiita.com/bwtakacy/items/65260e29a25b5fbde835
https://lets.postgresql.jp/documents/technical/backup/3
→詳しくて分かり易い
自分の解釈
・論理と物理バックアップがあり。
・論理はpg_dumpとか
・物理はファイルシステムバックアップ
・物理バックアップの場合、バックアップ所要時間があり、整合性を確保する仕組みが必要。
・それを継続的アーカイブで実現するのがオンラインバックアップ
・継続的アーカイブは以下
WALはテーブルスペースに反映されたら、適当なタイミングで削除される。
削除されるタイミングで、アーカイブする。
※別ディレクトリにコピー。postgres機能でやってくれる。
archive_command = 'cp %p /archive/%f'
# WALアーカイブ処理時に使われるコマンド
上記が継続的アーカイブの設定
・継続的アーカイブによるオンラインバックアップの流れ
※事前に継続的アーカイブ設定済みである必要あり。
1.バックアップモード（PG_START_BACKUP）にする。
※バックアップモードにするとチェックポイント（未反映WALのテーブルスペースへの反映）が作成される。
2.DB止めずにデータディレクトリをcpコマンドとかでバックアップ
3.バックアップモードを解除
https://www.postgresql.jp/document/9.1/html/continuous-archiving.html
より引用
postgreSQLは常に、クラスタのデータディレクトリ以下のpg_xlog/ディレクトリ内で先行書き込みログ（WAL）を管理しています。 このログはデータベースのデータファイルに行われた全ての変更を記録します。 このログは主にクラッシュ時の安全性を目的としています。 システムがクラッシュしたとしても、最後のチェックポイント以降に作成されたログ項目を"やり直し"することで、データベースを整合性を維持した状態にリストアすることができます。
https://lets.postgresql.jp/documents/technical/backup/3
より引用
1. PG_START_BACKUP()の発行
本節の冒頭で述べたとおり、オンライン・バックアップで取得したベースバックアップには、取得中に発生したWALも必要になります。どこからどこまでのWALが必要になるのかを、PostgreSQLに教える関数を発行する必要があります。これを行うのが、pg_start_backup() 及び pg_stop_backup() 関数です。それぞれ、ベースバックアップの取得前後に発行することになります。ベースバックアップの取得前に発行するpg_start_backup() 関数には、バックアップを示すラベルを指定します。ラベルはユーザの任意で自由に記述できます。典型的には、"いつ"バックアップが開始されたかを示す時間を打つと良いでしょう。
