今さら聞けないセキュリティ　2020年10月21日

BlueTeamを勉強したいんじゃ！

守る側の勉強をしたいけど、情報が少ないのでまとめてみました。

## 練習サイトとデータセット
– [CyberDefenders](https://cyberdefenders.org/)
– 現在おすすめのサイトで、LABとChallengesがあり、LABは好き勝手使える専用のクラウド環境がある。だたし、購入はCRというクレジットを買う必要があります。（50CR：10ドル、100CR：18ドル、500CR：90ドルの3つから選択する)
– Challengesは無料でSplunkのBoss Of The SOC(V1~V3まで)、Malware Traffic Analysis、Flare-on、
Disk Forensicsの4種類のCTFが遊べます。
– 上記サイトはLABs、Challengesともにコンテンツは今後もどんどん追加する予定のこと。

– [malware-traffic-analysis.net](https://www.malware-traffic-analysis.net/)
– CyberDefendersのChallengesにある

民間企業の次期ネットワーク構想に向けて　第2話

#調査はしたけど急にコロナ！
ウチはオンプレのハードウェアとしてFW，IPS/IDS，仮想にプロキシサーバを利用しています。
年間どのぐらいのコストがかかっているのかを調査すべく，保守料，リプレースタイミング，リプレース費用などを調査しました。
機器ごとに契約は異なり，かなり煩雑になっていることも分かり，契約管理も大変だなぁ，と感じました。
一番のコストはやはりIPS/IDSで，今回のリプレースタイミングで何か打つ手はないかと考えていました。
#コロナ襲来！
調査を進める中，一旦手を止めなければならない事態が発生しました。
コロナです。
関東で猛威を振るい始める中，テレワーク環境の整備が急務となりました。
社外からの接続は「FortiGate」を使ってのVPN接続を利用していましたが，出張者を対象にしていた為，接続人数が大幅に増えた時，利用する業務アプリが増えた時どうなるかなどは検証していませんでした。
スタッフ部門がコロナ感染で出社できなくなった場合を想定して数百名単位の対策を講じる事になりました。
まず，FortiGateサーバがそれだけの負荷に耐えられるか，ネットワーク帯域は大丈

Microsoftに認定されなかった脆弱性？の話

## はじめに
Microsoftには製品やサービスの脆弱性を発見すると、報奨金を貰うことができる制度「Microsoft Bug Bounty Program」がある。本記事ではMicrosoftに認定されなかったものの、ユーザへのリスクとなり得る報告を置いておく。内容はMicrosoftが直ちに修正するに当たらないと判断したものであるため、ユーザ側での対策が必要となる。
[Microsoft Bug Bounty Program](https://www.microsoft.com/en-us/msrc/bounty)

**本記事はMicrosoftより公開許可を受けています。本記事の内容を験する場合、法律により処罰される可能性があります。**

## 脆弱性概要
本脆弱性はMicrosoft Formsへの投稿をMicrosoft Power Automateを用いて、Microsoft Teamsへ通知(転送)する場合に発生する。被害としては通知テンプレートの改竄、不正なリンクの埋め込み、DDoS攻撃への荷担などである。
### 設定情報
Microsoft Formsで次の

民間企業の次期ネットワーク構想に向けて　第1話

#まえがき
今，常駐している契約先にお世話になって2年半が経ちました。
今年の春から色々提案してきた案件がどんどん大きくなり，来年度は大きなプロジェクトとして動くことになりました。
私のフリーランスSE人生の中でも一番大きく，一つの集大成となるプロジェクトです。
どんなきっかけで，どんな話の流れでこんな話になったのか。
現在進行形のプロジェクトですが，忘れないうちに思い出しながら振り返りの記事を書こうと思います。
常駐型フリーランスSEの経験談も交えて書いてみようと思います。
拙い文章ですが，最終的にはリアルタイムで進む記事になりそうなので，気軽にお読み頂けたら幸いです。
製品名はそのまま書きますが，登場する会社名などは可能な限りぼかして書きますのでご了承ください。

#え？いるの？
世間ではローカルブレイクアウトやゼロトラストなど次世代のネットワーク技術や構成がどんどん出てきます。
日々，ウチにもベンダーさんが様々な提案を持ってこられます。
※ウチ＝常駐先。名刺も常駐先のものを使うので対外的には常駐先の人間となります。
私はネットワークのスペシャリストではありませんが，業界もそこそこ

安全なウェブサイトの作り方についてまとめてみた

#はじめに
IPAが出している『安全なウェブサイトの作り方』全115ページについて、まとめたものです。

以下はIPAのサイト
https://www.ipa.go.jp/security/vuln/websecurity.html

内容

1.SQLインジェクション
2.OSコマンド・インジェクション
3.パス名パラメータの未チェック/ディレクトリ・トラバーサル
4.セッション管理の不備
5.クロスサイト・スクリプティング
6.CSRF(クロスサイト・リクエスト・フォージェリ)
7.HTTPヘッダ・インジェクション
8.メールヘッダ・インジェクション
9.クリックジャッキング
10.バッファオーバーフロー
11.アクセス制御や認可制御の欠落

##1. SQLインジェクション
悪意のあるリクエストにより、データベースの不正利用を招く可能性があります。

例えば、入力フォームにSQL文を含んだ文字列を入力した場合、データ漏洩や改ざんが起る場合があります。
###解決策１
SQL文の組み立ては全てプレースホルダで実装する。
###解決策2
SQL文の組み立てを文字列連結により行う場合は

PHPセキュリティ入門【これだけはやろう】

セキュリティについて、
“安全なWebアプリケーションの作り方 第二版(徳丸浩著)”を読みましたので
アウトプットとして、
細かいところは置いといて
最低限の守るべきところをまとめました！

#### 1. POSTの値を使うときはfilter_inputをかける
#### 2. 外部からコードやファイル名を取り込むのは避け、どうしても使うときはエスケープする
#### 3. バリデーションはアプリケーション要件に沿って行うだけでも効果あり
#### 4. eval関数は使わない
#### 5. APIを呼ぶときはMIMEタイプを正しく指定する
#### 6. hiddenパラメータ、クッキーは書き換え可能という前提を持つ
#### 7. htmlspecialchars関数の文字コード指定は必須

Slackコマンドで社内APIを叩くときに気をつけたこと

# はじめに
遠い昔、緊急時などにサーバーへある設定を入れる必要があった際
`会社に来る→サーバにアクセスする→設定を入れる`
という流れを踏む必要がありました。
（当時は社内ネットワークが無く、このような方法を取らざるを得ませんでした）

この運用だと緊急にも関わらず、暫定対応ですら数時間後の対応となってしまい困っていました。

その解決のために、SlackとAPIを利用して設定を入れる方式を導入しました。
`Slackでコマンドを叩く → APIサーバーのAPIが叩かれる → 設定が入る。`

しかし、Slackから叩ける ＝ どこからでも叩けるサーバーになってしまうのでセキュリティをいかに担保するかが鍵になっていました。
今回は「どうやってセキュリティを担保したか」を説明していきます。

# 前提
– 対象サーバーがNode.jsで書かれていること（今回はNode.jsで実装したため、その説明になります）
– Slackのwebhook設定が完了しており、Slackからサーバーを叩けるようになっていること

【参考】[Slack での Incoming Webhook の利用](

HackTheBox[Nibbles] -Writeup-

# はじめに
HackTheBoxの攻略などを自分用にまとめたものです。
主に記録用として記しています.

GitHub(ペネトレーションテスト用チートシート):
https://github.com/yukitsukai47/PenetrationTesting_cheatsheet
Twitter:@yukitsukai1731

# Nibbles

HackTheBox公式より
Nibbles is a fairly simple machine, however with the inclusion of a login blacklist, i

ATECC608A-TNGTLS検証(AWS IoT Multi-Account Registration接続テスト)(ATECC608A-TNGTLS AWS IoT connection test by using Multi-Account Registration)

#はじめに#
以前、[NXP SE050検証(AWS IoT Multi-Account Registration接続テスト)](https://qiita.com/kmitsu76/items/b7bb4146117a9a59412e)で実施した内容をMicrochip社のATECC608AのTrust and Goという製品で追試する。

前回整理したように、自分のCAを構築して、それを登録、共通のCAで認証されたデバイスを接続させるJust In Time Registrationよりも簡素化した、Multi-Account-Registrationを利用し、チップメーカーのCAを利用してデバイスを認証させる流れとなる。

#ATECC608AのTrust and Go#
ATECC608Aは16個のスロットの役割、権限を個別に設定できるC

公開鍵暗号方式について

自分の備忘録のため投稿します。
[参考資料](https://www.amazon.co.jp/dp/B07L9QXX9J/ref=dp-kindle-redirect?_encoding=UTF8&btkr=1)

## 用語解説
#### 暗号化

データを第三者にわからないように変換。

#### 復号
暗号化したデータを元の状態に戻す。

#### 公開鍵

データの暗号化をする。世間に公開するための鍵だから公開鍵。

#### 秘密鍵

データを復号化する。他人に見られちゃいけないから秘密鍵。

## 公開鍵暗号方式の流れ

① Aさん（受信者）が公開鍵と秘密鍵を用意。

② 公開鍵を公開して「自分にデータを送るときはこの鍵で暗号化して送ってね」。

③ Bさん（送信者）は Aさんの公開鍵を利用してデータを暗号化。A さんに送信。

④ A さんは B さんから送られてきた暗号化されたデータを自分で持っている秘密鍵で復号化。

セキュリティの資格攻略法

#はじめに
資格の良し悪しは別として、入札などで資格保持者が必要になるケースはそれなりにあると思います。所属する組織によっては受験費用を負担してくれたり、報奨金が出る場合もありますね。ということで、私がこれまでに取得した資格について、資格試験の概要と勉強法についてまとめてみることにしました。なお、中にはかなり前に取得したものもありますので、現在の試験とは異なる可能性があります。
各試験の試験時間、問題数、試験形式、個人的な難易度、試験費用、更新費用をつけています。

#情報処理安全確保支援士
更新料が高いだの講習がめんどくさいだのと色々言われていますが、試験費用が安く、国家資格であるというのは他の資格に比べて優位性があると思います。ただし更新費用は非常に高額なので、所属する組織が更新費用を負担してくれる場合にのみ登録した方が良いでしょう。試験合格だけでも十分意味があると思います。
午前Ⅰ、Ⅱ、午後Ⅰ、Ⅱの4種類の試験すべてで60点以上を取る必要があります。午後Ⅰ、Ⅱは筆記試験です。
他の資格とは異なり、過去問が公開されているため対策はしやすいと思います。過去問を数年分解くだけでもかなり

CentOS8でしぶといIPv6を無効にする

#はじめに
掲題の件で、手間取って調べた時のメモ

#まずは王道
まずはよくあるパターンとして以下を実行してreboot

“`/etc/sysctl.conf
net.ipv6.conf.all.disable_ipv6=1
net.ipv6.conf.default.disable_ipv6=1
net.ipv6.conf.lo.disable_ipv6 = 1
net.ipv6.conf.enp0s3.disable_ipv6 = 1
“`

再起動後に“`ip a“`でチェックすると、しぶとく残っている。

“`
$sudo sysctl –all | grep disable_ipv6
net.ipv6.conf.all.disable_ipv6 = 1
net.ipv6.conf.default.disable_ipv6 = 1
net.ipv6.conf.enp0s3.disable_ipv6 = 0
net.ipv6.conf.lo.disable_ipv6 = 1
“`

#解決策
Network mangerで管理しているから、効かないらしい。
そこで

TomcatでAJP 1.3 Connectorの接続をローカルに限定する

#やり方
こんな感じでadress属性を指定するとよい。

“`server.xml

“`

#参考
https://qiita.com/polarbear08/items/f016a0675e6c9637e7b8

手当たり次第IPv6を無効にしてみる

#はじめに
最近は、いろんなサービスがIPv4, IPv6のいずれにも対応している。
今回そんなサービスたちをIPv4のみに限定してしまおう。

# Apache(http)
“`/etc/httpd/conf/httpd.conf
#Listen 80
Listen 0.0.0.0:80
“`

# Apache(https)
“`/etc/httpd/conf.d/ssl.conf
#Listen 443 https
Listen 0.0.0.0:443 https
“`

# ssh

/etc/ssh/sshd_config

“`
#AddressFamily any
AddressFamily inet
“`

# MySQL(v8)
“`/etc/my.cnf.d/mysql-server.cnf
[mysqld]
bind-address=127.0.0.1
mysqlx-bind-address = 127.0.0.1
“`

# PostgreSQL
“`pg_hba.conf
#host all all

耐火金庫をハック

ネットの世界でもセキュリティは大切ですが、元祖おうちのセキュリティの耐火金庫をハックして見ました。

対象は開いている状態で番号が分からなくなった金庫です。

閉まった状態で番号が分からない金庫は業者さんにお願いするしかないと思います。

扉の裏蓋を開けるとこのようなメカがあります。


左の円盤は四枚が重なっています。すべての円盤の切りかきが右にそろうと鍵で開けられる仕組みになっています。ダイアルを右に四回以上回すと一番奥の円盤が回るようになります。一番奥の円盤の切りかきが右になる位置を探します。見つかったら次に、左にダイアルを回して、手前の円盤の切りかきが同じように右になる位置を探します。二つ目も重なったら右回りにダイヤルを回して、手前の円盤も合わせます。最後に左回りに回して、一番手前の円盤の切りかきがあってすべ

今更聞けない！Runtime Application Self-Protection(RASP)とは？

ITが好きでやまない非技術職です。今回は初投稿ですが、私が今注目しているRASPと呼ばれるセキュリティ技術について紹介したいと思います。

#概要
アプリケーションを守る技術としてRASPというのがありますが、RASPとは何でしょうか。その名の通り、アプリケーションまたはアプリケーションを実行するランタイム環境で、セキュリティ機能を導入しリアルタイムでアプリケーションまたはアプリケーション実行環境を脅威から守るセキュリティ技術です。

#なぜRASP?
サーバ上で動くアプリケーションであれば、サーバに何かしらのウイルス対策ソフトをインストールし、なんとなくアプリケーションも守られていて、安心してしまいます。
昨今、クラウドやコンテナ技術が注目を浴び、クラウド環境であれば例えばAWSのfargateといった環境では、マネージドサービスでOSレイヤーを制御できない環境も普通になってきました。
マネージドサービスになると、サーバと同等なセキュリティ対策ができないことが多く、WAFでセキュリティ対策を済ませることも多々あります。
WAFは多くの場合ですと、見れるレイヤーが限られていて、対策で

Let’sEncryptでPre-loaded Public Key Pinningに対応しやすい証明書を発行する

# 最初に
本記事ではLet’sEncrypt, PublicKeyPinningに関する解説は省略します。

# 通常の証明書発行
通常、（certbotを使った場合）以下のように発行と更新を行うかと思います。

“`
# 初回
certbot certonly –server https://acme-v02.api.letsencrypt.org/directory -d “*.foo.com” –manual-public-ip-logging-ok –agree-tos

# 更新
certbot renew
“`

## 発生する問題
Pre-loaded Public Key Pinningを行いたい場合、クライアント側に公開鍵をもたせる必要があります。
`certbot renew`の場合、このクライアント側に持たせたい公開鍵を毎回作成し直してしまいます。
アプリなどの場合、こうなると証明書が更新されるたびにアプリの更新も必要かつ同時にやらなければPinningに失敗します。

# 公開鍵を固定にして証明書を発行
“`
certbot certonly —

「DDoS攻撃対策 トリロジー」最終回: HTTP(S)フラッド攻撃の対策

今回はこの「DDoS攻撃対策 トリロジー」最終回だ。正直、このシリーズは人気がないよう見った。しかし、DDoS攻撃は、今日のあらゆるインターネットサービスにとって主なセキュリティ上の脅威であり、緊急時に対応できるように、事前に何を想定しているかを知っておくことが重要だ。

好かれようが好かれまいが、今回は最終回だった。将来的には、私は多分DDoS攻撃に関連する経験記事をこれ以上書くべきではないだ。それらの多くは、商業秘密だからだ。

今回の記事は、「HTTP(S) フラッド攻撃」の対策ですが、しかし今回は前回の「一般的なDDoS攻撃の対策」よりほとんど簡単だった。まず「HTTP(S) フラッド攻撃」を対策ため、必要のお金は前回より安くだ、そして、規模はともかく、方法は同じいだ。つまり「HTTP(S) フラッド攻撃」の防衛理念は全部同じだ。

同じに、今回の記事は大体は防衛の方法そして理念を教えれだけだ、だから、それが取得してすぐに使用することができるコードやプログラムを提供してない。

では、そろそろ始めましょう。

———————————-