Download as PDF, PPTX
![25
RDSのSQL監査ログ(2/3)
filter区はこんな感じ。次ページに続くｗ
filter {
xml {
source => "message"
store_xml => false
xpath => [
"/AuditRecord/Audit_Type/text()","Audit_Type",
"/AuditRecord/Session_Id/text()","Session_Id",
"/AuditRecord/StatementId/text()","StatementId",
"/AuditRecord/EntryId/text()","EntryId",
"/AuditRecord/Extended_Timestamp/text()","Extended_Timestamp",
"/AuditRecord/DB_User/text()","DB_User",
"/AuditRecord/OS_User/text()","OS_User",
"/AuditRecord/Userhost/text()","Userhost",
"/AuditRecord/OS_Process/text()","OS_Process",
"/AuditRecord/Terminal/text()","Terminal",
"/AuditRecord/Instance_Number/text()","Instance_Number",
"/AuditRecord/Object_Schema/text()","Object_Schema",
"/AuditRecord/Object_Name/text()","Object_Name",
"/AuditRecord/Action/text()","Action",
"/AuditRecord/TransactionId/text()","TransactionId",
"/AuditRecord/Returncode/text()","Returncode",
"/AuditRecord/Scn/text()","Scn",
"/AuditRecord/Comment_Text/text()","Comment_Text",
"/AuditRecord/Sql_Bind/text()","Sql_Bind",
"/AuditRecord/Sql_Text/text()","Sql_Text",
"/AuditRecord/OSPrivilege/text()","OSPrivilege",
"/AuditRecord/DBID/text()","DBID"
]
}
xml形式のログフォーマットであるため、xml filterを利用する。
message内容をxpath指定でfieldとvalueに分解する。](https://image.slidesharecdn.com/jeugopensiem-180619101626/85/JEUG-SIEM-25-320.jpg)
![26
RDSのSQL監査ログ(3/3)
S3へのRDS OracleのSQL監査ログのアップデート方法にてログの重複の可能性があるため...
if [DB_User][0] == "/" { drop {} }
fingerprint {
source => "message"
target => "[@metadata][fingerprint]"
method => "MURMUR3"
}
date {
match => [ "Extended_Timestamp[0]" , "yyyy-MM-dd'T'HH:mm:ss.SSSSSS'Z'" ]
timezone => "UTC"
target => "@timestamp"
}
mutate {
add_field => {
"file" => "%{[@metadata][s3][key]}"
}
}
}
output {
elasticsearch {
hosts => [ “<ElasticsearchのURL>:9200" ]
index => "rds-audit-%{+YYYYMMdd}"
document_id => "%{[@metadata][fingerprint]}"
}
}
ハッシュ値が一意になるようにsourceとしてmessageを指定する王道。
※同じmessageとなるログは基本的には存在しないため
method(利用するアルゴリズム)には、衝突率と処理速度でMURMUR3。
document_idにfingerprintのtargetで指定したメタフィールドを利用。
※障害時のログ取り込みの重複を防ぐ効果あり](https://image.slidesharecdn.com/jeugopensiem-180619101626/85/JEUG-SIEM-26-320.jpg)
![27
CloudTrailの操作ログ
CloudTrailの操作ログはCloudwatchLogsに寄せるとJSON形式でキレイに取れる。
【参考】 https://github.com/lukewaite/logstash-input-cloudwatch-logs
input {
cloudwatch_logs {
region => "ap-northeast-1"
log_group => [ "CloudTrail/AWSLogGroup" ]
sincedb_path => "/var/lib/logstash/sincedb_cloudtrail"
codec => json
}
}
filter {
json {
source => "message"
}
date {
match => [ "eventTime", "ISO8601" ]
timezone => "Asia/Tokyo"
locale => "en"
target => "@timestamp"
}
geoip {
source => "sourceIPAddress"
}
}
Githubからコミュニティプラグインの
logstash-input-cloudwatch-logsを導入する
ことで複数並列の[]を正規化してくれる。
複雑すぎてgrok filterではほぼ不可能(´;ω;｀)](https://image.slidesharecdn.com/jeugopensiem-180619101626/85/JEUG-SIEM-27-320.jpg)
![36
イベントログ取得はもちろんWinlogbeatにお任せ！
イベントログの取得は、WinlogbeatでイベントIDを取得するだけでOK！
# イベントID 内容
1 21 OSログイン成功
2 23 OSログオフ成功
3 24 OSセッション切断
4 25 OSセッション再接続
5 4625 OSログイン失敗
【winlogbeat.yml】
winlogbeat.event_logs:
- name: Microsoft-Windows-TerminalServices-LocalSessionManager/Operational
tags: ["login"]
event_id: 21,23,24,25
- name: Security
tags: ["login"]
event_id: 4625
Securityの「成功の監査」や「失敗の監査」の
イベントを取るよりもこのログを取るほうが正確な
OS認証ログが効率よく取得できる。(オススメ)
踏台サーバの利用終了時
ちゃんとログオフしていない
アカウントの監視ができる。
(セキュリティポリシー違反の監査)
【認証関連イベント情報】](https://image.slidesharecdn.com/jeugopensiem-180619101626/85/JEUG-SIEM-36-320.jpg)
![[Modern Cloud Day Tokyo 2019] Oracle Cloud Infrastructure 基本サービス入門(2) - ユーザー管...](https://cdn.slidesharecdn.com/ss_thumbnails/mcd19d-2-190822001051-thumbnail.jpg?width=640&height=640&fit=bounds)
【JEUG】 オープンSIEMの世界へ
- 1. 1 2018/6/19(Tue) Future Architect, Inc. HisashiHibino オープンSIEMの世界へ (ElasticStackと共に歩み続けたセキュリティログ分析)
- 2. 2 自己紹介 名前：日比野 恒 (ひびのひさし) 所属：フューチャーアーキテクト株式会社 セキュリティアーキテクト (CISSP、CISA、情報処理安全確保支援士) AIなどの「システム高度化」により、ITリテラシーの非対称性が拡大している IoT/コネクテッド領域など、ITが人々の生活に密接に関わるにつれ、危機感を持つようになる オープンな技術を用いたセキュリティログの分析プラットフォーム開発に目覚め、今に至る
- 3.
- 4.
- 5. 5 ログ管理製品の分類 Syslog 統合ログ管理 SIEM 相関分析 正規化 可視化 ログアーカイブ(長期保管)用途ログ分析(リアルタイム)用途 ※IO性能よりもディスク容量やセキュリティ重視 ※ディスク容量よりもIO性能重視 【製品例】 ①Qradar ②McAfeeSIEM ③Splunk Enterprise 【製品例】 ①LogStorage ②LogRevi ③EventLog Analyzer 【製品例】 ①Kiwi Syslog ②rsyslog ③syslog-ng ログ収集 相関分析 正規化 可視化 ログ収集 相関分析 正規化 可視化 ログ収集 SIEM(Security Information and Event Management)は、セキュリティ脅威検知に特化したログ管理製品。
- 6.
- 7.
- 8.
- 9.
- 10.
- 11. 11 70％の企業が攻撃に気づいていない 2015年の日本年金機構の事件を境に報告数急増。約70%が外部からの指摘で発覚。 2013年 2014年 2015年2016年 0 出典: 「平成28年におけるサイバー空間をめぐる脅威の情勢について」(警視庁) 492 1,723 4,046 1,000 2,000 3,000 4,000 3,828
- 12.
- 13.
- 14.
- 15.
- 16.
- 17. 17 Elasticを活用したSIEMプラットフォームサービス 脅威分析のユースケースにおいて、Elasticプロダクトを活用するとこんな感じになる。 Kibana Elasticsearch Logstash Beats Alerting Monitoring Graph Security X-Pack Elastic Stack(オープンソース) 有償サブスクリプション Machine Learning Reporting 正規化 保存/蓄積 可視化 認証/暗号化 通知 相関分析 異常検知取り込み Platinum Edition Gold Edition ※ 有償サブスクリプションを購入することでX-Packの有償機能とElasticのサポートを受けられる。 ※ エディションに応じて、利用できる機能およびサポートレベルが異なる。 ※ ライセンスは本番環境のElasticsearchクラスタ内のノード数分を購入する。(クォーラム維持に必要な最小3ノードから) 本 日 は 私 の 好 き な こ の 辺 り を
- 18. 18 有償プラグイン(X-Pack) 有償プラグインであるX-Packでは、エンタープライズ向けに6種類の製品が提供されている。 Security Monitoring Reporting Alerting Graph Machine Learning データの変化を検知 多種多様な通知方法 ダッシュボードのレポート化(PDF等) Alertingと組み合わせたレポートのスケジュール通知 Elasticsearchクラスタの性能情報 Kibanaの性能情報 Logstashの性能情報 データの関連性を可視化 教師無し機械学習によるデータ分析 時系列異常検知 はぐれ者検知 稀有な非構造メッセージ検知 Kibanaの認証 Kibanaの通信暗号化 AD/LDAP認証連携 API監査 ドキュメント暗号化
- 19. 19 LogstashとBeatsの使い分け Elasticには、データの取り込みツールに「Logstash」と「Beats」の2種類がある。 正しい使い分けについて質問を頂くことが多いため、まとめてみた。 Go言語による実装でシンプルで軽量 特定ソースからのデータ取り込み データ保存先は1つのみ エージェント用途での利用 Javaベースで大量メモリ消費 多種多様なソースからのデータ取り込み 多種多様なフィルタによるデータ加工 多種多様な保存先にデータ出力 対象システムに負荷を掛けず用途に応じて 効率よくデータを取得することに特化 ETLツールとして、分析に活用したい データをほしい形に加工することに特化
- 20.
- 21.
- 22. 22 フォーマットの異なる複数ログを取りこむ際のポイント オンプレ環境で複数ログをSyslogで取り組む場合はLogstashの前にsyslogサーバを挟む。 logstash rsyslog等 ログ形式① (Firewall) ログ形式② (WAF) input file input file grok-> geoip -> date -> mutate csv -> geoip -> date -> mutate output elasticsearch output elasticsearch Elasticsearch Index① Index② Index③ ログ形式③ (IPS) input file grok -> geoip -> date -> mutate output elasticsearch Firewall WAF IPS 【設計ポイント①】 異なるログ形式を同じinput syslogで取得して、異なる正規化フィルタに 掛けることが出来ないため、rsyslogで受信して別ファイルにしてすることで input fileで異なるフィルタで正規化することが可能となる。 【設計ポイント②】 multi pipeline機能を利用してログ形式ごとにconfファイルを作成することでフィルタを シンプルにすることが可能であり、リソース管理もpipeline単位で制御出来るメリットがある。 【設計ポイント③】 格納するログ形式が異なるため、ElasticsearchのIndexも ログごとに分けることで性能面や運用面でメリットがある。 kibana
- 23. 23 【参考】AWS環境の場合、ログは全てS3を介して取り込むべし ログ形式毎にフォルダを切ってS3にログを収集することで障害時のハンドリングが容易になる。 ログファイル データベース ネットワーク機器 イベントログ Filebeat Winlogbeat Logstash (収集) input jdbc input tcp/udp (syslog/netflow) S3Bucket (bucket-a) /log /backup AWS各種アクセスログ Logstash (正規化) S3アクセスログ CloudFront アクセスログ ELB アクセスログ Elasticsearch input s3output s3 output es 1 2 3 input { s3 { backup_to_bucket => “bucket-a" backup_add_prefix => “backup/" delete => "true" bucket => "bucket-a" region => "ap-northeast-1" prefix => “log/log-a" interval => "5" sincedb_path => "/var/lib/logstash/sincedb" } } log-a Logstashで取り込まれた後 生ログは/backupで保持される
- 24. 24 RDSのSQL監査ログ(1/3) S3経由で取得したRDS(Oracleエンジン)のSQL監査ログのinput区はこんな感じ。 input { s3 { id=> "rds-audit" bucket => “SIEM-AUDIT" prefix => "/rds/audit/" region => "ap-northeast-1" sincedb_path => "/var/lib/logstash/sincedb_rds-audit" codec => multiline { pattern => "(<?xml .*|<Audit .*|xmlns:xsi|xsi:schemaLocation|<Version>|</AuditRecord>|</Audit>)" negate => true what => "next" } } } RDS Oracleのaudit_trailをOS形式で出力すると1レコードが複数行にまたがるログとなるため、codecでmultilineを指定する。 Patternで指定した文字列以外(negateがtrue)の行は、最初の行の後ろ(whatがnext)に追記して1件のログと認識する。 【参考】 https://dev.classmethod.jp/cloud/aws/rds-oracle-copy-audit-logs-to-s3/
- 25. 25 RDSのSQL監査ログ(2/3) filter区はこんな感じ。次ページに続くｗ filter { xml { source=> "message" store_xml => false xpath => [ "/AuditRecord/Audit_Type/text()","Audit_Type", "/AuditRecord/Session_Id/text()","Session_Id", "/AuditRecord/StatementId/text()","StatementId", "/AuditRecord/EntryId/text()","EntryId", "/AuditRecord/Extended_Timestamp/text()","Extended_Timestamp", "/AuditRecord/DB_User/text()","DB_User", "/AuditRecord/OS_User/text()","OS_User", "/AuditRecord/Userhost/text()","Userhost", "/AuditRecord/OS_Process/text()","OS_Process", "/AuditRecord/Terminal/text()","Terminal", "/AuditRecord/Instance_Number/text()","Instance_Number", "/AuditRecord/Object_Schema/text()","Object_Schema", "/AuditRecord/Object_Name/text()","Object_Name", "/AuditRecord/Action/text()","Action", "/AuditRecord/TransactionId/text()","TransactionId", "/AuditRecord/Returncode/text()","Returncode", "/AuditRecord/Scn/text()","Scn", "/AuditRecord/Comment_Text/text()","Comment_Text", "/AuditRecord/Sql_Bind/text()","Sql_Bind", "/AuditRecord/Sql_Text/text()","Sql_Text", "/AuditRecord/OSPrivilege/text()","OSPrivilege", "/AuditRecord/DBID/text()","DBID" ] } xml形式のログフォーマットであるため、xml filterを利用する。 message内容をxpath指定でfieldとvalueに分解する。
- 26. 26 RDSのSQL監査ログ(3/3) S3へのRDS OracleのSQL監査ログのアップデート方法にてログの重複の可能性があるため... if [DB_User][0]== "/" { drop {} } fingerprint { source => "message" target => "[@metadata][fingerprint]" method => "MURMUR3" } date { match => [ "Extended_Timestamp[0]" , "yyyy-MM-dd'T'HH:mm:ss.SSSSSS'Z'" ] timezone => "UTC" target => "@timestamp" } mutate { add_field => { "file" => "%{[@metadata][s3][key]}" } } } output { elasticsearch { hosts => [ “<ElasticsearchのURL>:9200" ] index => "rds-audit-%{+YYYYMMdd}" document_id => "%{[@metadata][fingerprint]}" } } ハッシュ値が一意になるようにsourceとしてmessageを指定する王道。 ※同じmessageとなるログは基本的には存在しないため method(利用するアルゴリズム)には、衝突率と処理速度でMURMUR3。 document_idにfingerprintのtargetで指定したメタフィールドを利用。 ※障害時のログ取り込みの重複を防ぐ効果あり
- 27. 27 CloudTrailの操作ログ CloudTrailの操作ログはCloudwatchLogsに寄せるとJSON形式でキレイに取れる。 【参考】 https://github.com/lukewaite/logstash-input-cloudwatch-logs input { cloudwatch_logs{ region => "ap-northeast-1" log_group => [ "CloudTrail/AWSLogGroup" ] sincedb_path => "/var/lib/logstash/sincedb_cloudtrail" codec => json } } filter { json { source => "message" } date { match => [ "eventTime", "ISO8601" ] timezone => "Asia/Tokyo" locale => "en" target => "@timestamp" } geoip { source => "sourceIPAddress" } } Githubからコミュニティプラグインの logstash-input-cloudwatch-logsを導入する ことで複数並列の[]を正規化してくれる。 複雑すぎてgrok filterではほぼ不可能(´;ω;｀)
- 28. 28 【参考】CloudTrailのログの分析ポイント 管理コンソールへのログインやAPI操作を「いつ」・「誰が」・「どこから」実行したかを抑える。 ※Logstashのgeoip filterを用いて、送信元IPアドレスに国情報を付加しておく。 eventType AwsAPICall AwsConsoleSignIn userIdentity.type responseElements.ConsoleLogin IAMUser Root AWSService AssumedRole AwsAccount eventNameConsole Login CheckMfa SwitchRole Success Failure responseElements.CheckMfa Success Failure responseElements.SwitchRole Success Failure Field Name Value 【凡例】 Additional EventData.MFAUsed Yes No geoip.ip geoip.country_name userIdentity.type userIdentity.username @timestamp eventName API名 API名 ※ APIごとにイベントが存在し、大量のイベントが存在する。 存在しないIAMUserでログイン施行があると 「userIdentity.username 」に 「HIDDEN_DUE_TO_SECURITY_REASONS」と出る。 MFAを利用したログイン行為を実施しているかのチェックに 「Additional EventData.MFAUsed」を利用する。
- 29. 29 DDoS攻撃やSQLインジェクション攻撃には... ログデータを利用したい形式に加工することで迅速なインシデントレスポンス対応が可能に！！ Webアクセスログ file grok geoipdns Elastic search 【辛みポイント①】 CSVフィルタでトライするもURLにSQL インジェクションで使われる文字列が入り separatorが機能せず Σ（・□・；） 結果的にgrokフィルタで落ち着く。 【辛みポイント②】 キャッシュ有効化するもそんなにヒットしない ため、都度DNSサーバに問い合わせに... 性能が5分の1くらいまで下がる。
- 30. 30 これだけ嬉しいことが起きるはず (^^) 1. SyslogサーバからFirewallログ取得 2.国情報から国外アクセスを検索 3. 国外IP一覧をIPアドレスごとに集計 4. IPアドレスをWhoisでホスト名検索 5. 不審なIPアドレスをFirewallでブロック 繰り返す 1. SyslogサーバからFirewallログ取得 2. 国情報から国外アクセスを検索 3. 国外IP一覧をIPアドレスごとに集計 4. IPアドレスをWhoisでホスト名検索 5. 不審なIPアドレスをFirewallでブロック ElasticStack に よ る 自 動 化
- 31.
- 32. 32 【参考】私がログ分析でよく使うフィルタたち # フィルタ名 説明 1grok 非構造データを正規表現を用いて構造化データに変換するフィルタ 2 date ログ内の日付データを@timestampに置換するフィルタ 3 mutate fieldの型を変更したり、fieldを追加削除、編集するフィルタ 4 geoip ログ内のIPアドレスに国情報や緯度経度情報を付加するフィルタ 5 dns IPアドレスからホスト名(逆引き)、またはその逆の正引きを行うフィルタ 6 drop 条件に合致するログレコードを廃棄させるフィルタ 7 csv csv形式のログデータをfieldとvalueに分割するフィルタ 8 kv key=value形式のログデータをfieldとvalueに分割するフィルタ 9 xml xml形式のログデータをfieldとvalueに分割するフィルタ 10 translate valueの中身を指定した文字列に合致したら置換させるフィルタ 11 fingerprint 指定したfieldのvalueからハッシュ値を生成し、新たにfield化するフィルタ
- 33.
- 34.
- 35.
- 36. 36 イベントログ取得はもちろんWinlogbeatにお任せ！ イベントログの取得は、WinlogbeatでイベントIDを取得するだけでOK！ # イベントID 内容 121 OSログイン成功 2 23 OSログオフ成功 3 24 OSセッション切断 4 25 OSセッション再接続 5 4625 OSログイン失敗 【winlogbeat.yml】 winlogbeat.event_logs: - name: Microsoft-Windows-TerminalServices-LocalSessionManager/Operational tags: ["login"] event_id: 21,23,24,25 - name: Security tags: ["login"] event_id: 4625 Securityの「成功の監査」や「失敗の監査」の イベントを取るよりもこのログを取るほうが正確な OS認証ログが効率よく取得できる。(オススメ) 踏台サーバの利用終了時 ちゃんとログオフしていない アカウントの監視ができる。 (セキュリティポリシー違反の監査) 【認証関連イベント情報】
- 37. 37 Windowsのログイン監査グラフ Y軸を件数、X軸を時系列(日単位)でログインアカウント毎に積立棒グラフで表示する。 「いつ」、「誰が」、「何回」、ログイン成功もしくは失敗したのか監査が可能。 User A User B UserC 【サンプル:ログイン成功グラフ (イベントID:21)】
- 38. 38 【参考】ファイル操作に関するイベントログと表示される項目一覧 項目名 / イベントID4656 (OPEN) 4656 (DELETE) 4658 (CLOSE) 4663 (ACCESS) 4690 (COPY) AccessList ● ● - ● - AccessMask (CRUDの情報) ● ● - ● - AccessReason ● ● - - - HandleId ● ● ● ● - ObjectName (フォルダ名やファイル名のフルパス) ● ● - ● - ObjectServer ● ● ● ● - ObjectType (DirectoryまたはFile) ● ● - ● - PrivilegeList ● ● - - - ProcessId ● ● ● ● - ProcessName ● ● ● ● - ResourceAttributes ● ● - ● - RestrictedSidCount ● ● - - - SourceHandleId - - - - ● SourceProcessId - - - - ● SubjectDomainName (ユーザのドメイン名) ● ● ● ● ● SubjectLogonId ● ● ● ● ● SubjectUserName (アカウント名) ● ● ● ● ● SubjectUserSid ● ● ● ● ● TargetHandleId - - - - ● TargetProcessId - - - - ● TransactionId ● ● - - - COPYしたファイル名をイベンID:4690 単体でトレースすることは出来ない。
- 39. 39 【参考】JPCERT/CCの情報も参考に！！ 内部不正を見張る上で地味に活用できるイベントIDを紹介 出典：ログを活用したActive Directoryに対する攻撃の検知と対策(JPCERT/CC) # イベント名イベントID 内容 1 Security 1102 イベントログの削除 2 Security 4672 特権の割り当て 3 Security 4698 スケジュールされたタスクの作成 4 Security 4768 Kerberos認証(TGT要求) 5 Security 4769 Kerberos認証(ST要求)
- 40.
- 41.
- 42. 42 ルールの書き方はaudit.rulesと同じ auditdのプロセスを停止して、auditbeatでログ取得する方が正規化不要でラクチン。 【auditbeat.yml】 auditbeat.modules: - module: auditd audit_rules:| -a always,exit -F arch=b32 -F auid>=1000 -F auid!=4294967295 -S execve -a always,exit -F arch=b64 -F auid>=1000 -F auid!=4294967295 -S execve - module: file_integrity paths: - /bin - /usr/bin - /sbin - /usr/sbin - /etc 【参考】 https://access.redhat.com/documentation/ja-jp/red_hat_enterprise_linux/6/html/security_guide/sec-defining_audit_rules_and_controls UID1000以上のシステムユーザ以外のユーザ によるコマンド実行を全て取得することが可能。 ユーザログイン認証はデフォルトで取得可能。 変更を見張りたいディレクトリを記載することで ファイル改ざん監視が可能。 audit_rules変更時に自動的にーDされると書かれているが、auditctl –lするとルールは消えてない...あれれ
- 43.
- 44. 44 是非、解決してもらいたい課題について ElasticsearchのタイムゾーンがUTCであることの運用課題をそろそろ解決出来るように... ログ管理DB Winlogbeat KibanaElasticsearch search Auditbeat Alerting セキュリティ担当 Mail ログファイル (Linux) イベントログ (Windows) Windowsサーバ Linuxサーバ Logstash Syslog UTM Sandbox Proxy Anti Virus Mail (MTA) FileTransfer OSが保持しているタイムゾーン (JST) ブラウザが保持しているタイムゾーン (JST) ESが保持しているタイムゾーン (UTC) Index01 Index02 Index03 【ポイント②】 ログ分析ユースケースでは、取り込むデータが日々増え続ける ため、LogstashやBeatsの生成するIndexはデフォルト日次 で作成され、切り替わる。 しかし切り替わるタイミングがUTCのため日本のAM9時となる。 【ポイント①】 search文の中で時刻を範囲指定する場合、前日0時～当日0時を “gt”: “now-1d/d-9h“と”lt”: “now/d-9h”と9時間引く必要がある。
- 45.