Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

【SecurityJAWS】Kibana Canvasで魅せる!AWS環境における脅威分析ユースケース

6,193 views

Published on

Kibana Canvasで魅せる!AWS環境における脅威分析ユースケース

Published in: Technology
  • Be the first to comment

【SecurityJAWS】Kibana Canvasで魅せる!AWS環境における脅威分析ユースケース

  1. 1. 1 2018/5/16(水) フューチャーアーキテクト株式会社 Kibana Canvasで魅せる! AWS環境における脅威分析ユースケース
  2. 2. 2 本日、伝えたいこと  ElasticStackで構築するログ分析プラットフォーム  CloudTrailのログを参考にした脅威分析のコツ ※資料は終了後公開します
  3. 3. 3 自己紹介① 名前:日比野 恒 (ひびの ひさし) 所属:フューチャーアーキテクト株式会社 セキュリティアーキテクト (CISSP、CISA、RISS)  AIなどの「システム高度化」により、ITリテラシーの非対称性が拡大している  IoT/コネクテッド領域など、ITが人々の生活に密接に関わるにつれ、危機感を持つようになる  オープンな技術を用いたセキュリティログの分析プラットフォーム開発に従事し、今に至る
  4. 4. 4 自己紹介② 名前:中井 祐季 (なかい ゆうき) 所属:フューチャーアーキテクト株式会社 コンサルタント(3年目) 新卒入社 2016/4 AWSとの出会い (たぶん) 2017/6ElasticStack との出会い 2016/7 初登壇 2017/10 初 セキュリティ案件 2018/1 今ココ!  セキュリティ歴もAWS歴も浅いですが、よろしくお願いします。
  5. 5. 5 1. オープンSIEM構想
  6. 6. 6 オープンSIEM構想とは 「オープンな技術」、「オープンな環境」でSIEMを作りたい! オープンな技術 オープンな環境× 例えば、各製品のログフォーマットを正規化するためのLogstashのフィルタを公開。 少ない貴重なエンジニアリソースをシェアリングして皆でオープンな技術でSIEMを構築していく等。
  7. 7. 7 保護対象システム ネットワーク (多層防御) オープンSIEMカバー範囲 業務視点でのセキュリティ監視に強みを発揮 業務とアプリケーションに強みを持つ者の視点でセキュリティ監査を実現する。 フ ァ イ ア ウ ォ ー ル IDS/IPS WAF ア ン チ ウ ィ ル ス サ ン ド ボ ッ ク ス ス パ ム フ ィ ル タ 外部脅威 内部不正 インスタンス/サーバ OS データ(機密) データベース アプリ ミドル クラウドサービス 一般的な商用SIEM製品の得意領域 我々の考えるSIEMの得意領域  外部からシステムを守ることを主目的としているため 入り口になるネットワーク寄りの監視が得意領域
  8. 8. 8 シンプルな分析画面とすること! 無駄にカッコ良いものを目指さない。分かりやすさ重視のシンプルなものを提供するのがコツ。  だれでも  いつでも  どこでも 確認が可能であること 【期待できる効果】  脅威検知時以外でも変化に気づくようになる。  ログから読み取れる情報に対する関心が高まる。
  9. 9. 9 ログ分析システム キッカケは意外なところから... 金融機関のマイナンバー管理のサブシステムとしてスタート!! データベース (暗号化) WebAPIPSLBFW LAN Internet 利用ユーザ (スマホ) 番号登録担当 (PC端末) 踏台 SQL監査ログAPI実行ログ 認証ログ 通信ログ LogstashElasticsearchKibana 【法令要件に準拠するため、業務視点での監視と監査を実現】  マイナンバーを参照するAPIは基本的に叩かれない。 →参照系APIが叩かれたら不正操作となる。  メンテナンス作業は申請ベースで厳格に行われる。 →申請外で踏台ログインや直接データベース接続されたら不正操作となる。 操作録画ソフト マイナンバー SQLAPI
  10. 10. 10 お国のシステムにも導入してみた 標的型サイバー攻撃を想定したセキュリティ統合管理基盤のSIEMでElasticStackを採用。 SIEMサーバ ログファイル (Linux) Syslog イベントログ (Windows) Filebeat Winlogbeat セキュリティ 監査端末 Windowsサーバ Linuxサーバ UTM Sandbox Proxy 【監視業務】 1.マルウェア検知システムの監視 2.業務時間外の不正通信の監視 3.許可していない外部向け通信の監視 4.不正なUserAgentでのWeb通信の監視 5.ファイル転送システムの不正利用の監査 6.管理者によるOSへの不正ログインの監査 etc... Anti Virus Mail (MTA) File Tracefer Logstash Elasticsearch Kibana Kibana HA構成 Logstash HA構成 Elasticsearch Elasticsearch クラスタ構成
  11. 11. 11 SIEM AWS環境における導入が次々と RDSやS3に個人データを保持するシステムが増加し、不正監査をする仕組みでAWS導入。 AZ-a AZ-c Internet WebAP#01 IF#01 WebAP#02 IF#02 踏台 SIEM#01 SIEM#02JOB 利用者 IF連携システム 保守者 SIEM#03AZ-d 大 量 個 人 情 報 の 保 有
  12. 12. 12 2. アーキテクチャの概要
  13. 13. 13 AWS環境であっても基本的な考え方は同じ 「不正利用/なりすまし」や「不正アクセス/不正侵入」に対する技術的対策は変わらない!
  14. 14. 14 ログ分析における全体連携図 ログ管理DB ログファイル 性能データ イベントログ Metricbeat Filebeat Winlogbeat Logstash input s3 クライアント サーバ ネットワーク トラフィック パケットキャプチャ Packetbeat KibanaElasticsearch search Windows Linux アクセスログ SQL監査ログ VPC Flow Logs CloudTrail 操作ログ WAFログ 改ざん検知 認証ログ Auditbeat input cloudwatchlogs input beats Alerting セキュリティ担当 Security Machine Learning Mail EC2 アクセスログ 永続性確保
  15. 15. 15 Elasticプロダクトの活用イメージ 脅威分析のユースケースにおいて、Elasticプロダクトを活用するとこんな感じになる。 Kibana Elasticsearch Logstash Beats アラート 性能監視 グラフ セキュリティ X-Pack Elastic Stack (オープンソース) 有償サブスクリプション 機械学習 レポート 正規化 保存/蓄積 可視化 認証/暗号化 通知 相関分析 異常検知取り込み 【全体コンポーネント構成】 Platinum Edition Gold Edition ※ 有償サブスクリプションを購入することでX-Packの有償機能とメーカーサポートを受けることが可能になります。 ※ エディションに応じて、利用できる機能およびサポートレベルが異なります。 ※ ライセンスはElasticsearchクラスタのノード数購入する必要があります。(最小3ノードから)
  16. 16. 16 【参考】有償プラグイン(X-Pack) 有償プラグインであるX-Packでは、エンタープライズ向けに6種類の製品が提供されている。 Security Monitoring Reporting Alerting Graph Machine Learning  データの変化を検知  多種多様な通知方法  ダッシュボードのレポート化(PDF等)  Alertingと組み合わせたレポートのスケジュール通知  Elasticsearchクラスタの性能情報  Kibanaの性能情報  Logstashの性能情報  データの関連性を可視化  教師無し機械学習によるデータ分析  時系列異常検知  はぐれ者検知  稀有な非構造メッセージ検知  Kibanaの認証  Kibanaの通信暗号化  AD/LDAP認証連携  API監査  ドキュメント暗号化
  17. 17. 17 【参考】ElasticStackの性能管理方法 無償でElasticStackの性能管理ができるX-Pack BasicのMonitoringは使うべし!! 参考URL https://www.elastic.co/jp/products/x-pack/monitoring 【Elasticsearch】 Search Rate、Search Latency、Indexing Rate、Indexing Latency、JVM Heap、CPU Utilization、Latency、Index Memory、System Load、Sement Count、GC Count、GC Duration、Request Rate、Indexing Threads、Read Threads、Cgroup CPU Performance Cgroup CFS Stats、Document Count 【Kibana】 Client Requests、Client Response Time、Memory Size、HTTP Connections、System Load、Event Loop Delay 【Logstash】 Events Received Rate、 JVM Heap、Events Emitted Rate、 CPU Utilization、Event Latency、System Load
  18. 18. 18 【参考】Beatsの採用ポイント(1/2) EC2内のログ収集にはCloudWatchLogsエージェントがあるが... エージェント ログファイルイベントログ/IISログ Beats ログファイルイベントログ 性能データ 改ざん検知 認証ログ CloudWatchLogs 【CloudWatchLogsエージェント】 【Beats】 Athena (ETL) RedShift (分析) ログ管理DB Logstash Logstash Elasticsearch 【特徴】  ログ正規化を行い、Elasticsearchに出力することが出来る  ログ形式に合わせたBeatsをGo言語で自作することが出来る  ElasticsearchかLogstashにしかoutput出来ないので、S3に上げるのがメンドイw
  19. 19. 19 【参考】Beatsの採用ポイント(2/2) Elasticには、データの取り込みツールに「Beats」と「Logstash」の2種類がある。 正しい使い分けについて良く質問をもらうので、まとめてみた。  Go言語による実装でシンプルで軽量  特定ソースからのデータ取り込み  データ保存先はLogstash/ESのみ  エージェント用途での利用  Javaベースで大量メモリ消費  多種多様なソースからのデータ取り込み  多種多様なフィルタによるデータ加工  多種多様な保存先にデータ出力
  20. 20. 20 3. 脅威分析のユースケース
  21. 21. 21 そろそろ本題に入らないとアカン!! 前置きは程ほどにして、AWS環境における「外部」と「内部」の脅威対策について 1.外部の脅威対策 →ハッキング攻撃対策 2.内部の脅威対策 →機密データ不正取得対策
  22. 22. 22 外部からのハッキング攻撃の分析ポイント 不審なIPまたは国からの不正なログイン行為やAPIの監査がポイントになる。 ハッカー集団 APIs 各種AWSサービス 管理コンソール Internet CloudTrailログ SQL監査ログ API実行ログ アクセスログ APIサーバ 攻撃通信 【凡例】 ログ連携 AWSAPICalls ConsoleSignIn
  23. 23. 23 内部犯行による機密情報不正奪取の分析ポイント 特に、機密データに対するシステム管理者の操作の監査方法がポイントになる。 踏台 ログファイル イベントログ 改ざん検知 認証ログ システム管理者 (運用保守) SQL監査ログ アクセスログ 管理コンソール CloudTrailログ RDP or SSH HTTPS ⑤データ暗号鍵 ダウンロード ⑥機密データ アクセス SQL AWS CLI ①不正ログイン ②不正ログイン ③不正コマンド実行 ④ログ改ざん ①不正ログイン監査 ⑤不正ダウンロード監査 ⑥不正SQL監査 ②不正ログイン監査 ③不正OSコマンド実行監査 ④ログ改ざん監査
  24. 24. 24 内部犯行の特定は、ログと作業記録との突合せで!! 件数だけでは判断できない認証ログ、アクセスログは作業申請との突合せで 内部不正やマルウェア攻撃による潜伏行動の早期発見につなげることが出来る。 システムによる 管理 人手による 管理 ログ (システムから出力) 作業記録 (人が作成) 日常的な モニタリング セキュリティ監査 【システム管理者】 ①不正(ルール違反、さぼり)のチェック ②ミス(処理漏れ、誤り)のチェック 【セキュリティ監査者】 ①情報漏洩や内部不正のチェック ②セキュリティ機能のチェック
  25. 25. 25 CloudTrail分析
  26. 26. 26 CloudTrailのログの分析ポイント 管理コンソールへのログインやAPI操作を「いつ」・「誰が」・「どこから」実行したかを抑える。 ※Logstashのgeoip filterを用いて、送信元IPアドレスに国情報を付加しておく。 eventType AwsAPICall AwsConsoleSignIn userIdentity.type responseElements.ConsoleLogin IAMUser Root AWSService AssumedRole AwsAccount eventName Console 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_SECRITY_REASONS」と出る。 MFAを利用したログイン行為を実施しているかのチェックに 「Additional EventData.MFAUsed」を利用する。
  27. 27. 27 不正API分析画面サンプル(1/3) 秘密 秘密 秘密 秘密 秘密 When Where Who What IAMUserの実行したAWS APIコールに関するCloudTrail操作ログを分析する。 絞 り 込 む 分 析 軸
  28. 28. 28 不正API分析画面サンプル(2/3) パターン①: 送信元IPアドレス「54.239.22.23」で絞ってみる。 該当するIAMユーザは表示されなかった。 イベントにはNetworkInterfaceに関するAPIが集計された。 54.239.22.23はAWSが保持しているIPアドレスで ENIに関する操作を指示するAPIがこのIPから発呼されていると 推察できる。
  29. 29. 29 不正API分析画面サンプル(3/3) パターン②: IAMユーザ「alex」で絞ってみる。 秘密 秘密 秘密 自宅、会社、WiFiルータの3つの認識している グローバルIPアドレスのみが表示された。 認識していない不審な国やIPアドレスがなく ひと安心 ^o^y
  30. 30. 30 不正ログイン分析画面サンプル(1/3) 秘密 AWS管理コンソールへのログインに関するCloudTrail操作ログを分析する。 絞 り 込 む 分 析 軸
  31. 31. 31 不正ログイン分析画面サンプル(2/3) 秘密 秘密 イベント名「ConsoleLogin」で絞ってみた。 ログインに失敗している回数が28回もいた。 ログイン時にMFAを有効化していないログインが4回も出ている。 多要素認証を設定していないユーザを特定してみる。
  32. 32. 32 不正ログイン分析画面サンプル(3/3) 追加でMFA利用有無を「No」で絞ってみた。 間違ったIAMユーザ名で2回、alexが2回 MFAを利用しないでログインを施行している。 間違ったIAMユーザのログインは「Failure」であることが分かる。 秘密 秘密
  33. 33. 33 番外編
  34. 34. 34 ログからアプリケーション脆弱性攻撃を検出 CLBのアクセスログからアプリの脆弱性を付いた攻撃が発生していることを検出。 Jorgeeとは、phpmyadminの脆弱性をスキャンするツール で利用されるUserAgent名。攻撃の兆候を特定。 国別のアクセス数を集計し、明らかに異常に多いアクセスがある国 からのアクセスについては、内容を確認し、必要な部分については フィルタリング等の対応を実施
  35. 35. 35 Machine Learningで異常検知 CLBの遅延時間の大きい時間帯のアクセスで異常検知し、おかしなUserAgentを発見。 DoS攻撃の検知
  36. 36. 36
  37. 37. 37 あれ?Canvasの話はしないの??
  38. 38. 38 Kibana Canvasで魅せられなかった! ごめんなさい 客寄せパンダ失格(汗)
  39. 39. 39
  40. 40. 40 Appendix
  41. 41. 41 Elasticsearch
  42. 42. 42 EC2 Discovery Pluginでクラスタを組もう AWSのSecurity Groupを認識して所属しているElasticsearchノードを探しに行く。 【参考】EC2 Discovery Plugin https://www.elastic.co/guide/en/elasticsearch/plugins/6.2/discovery-ec2.html Security Group VPC ES01 ES02 ES03 Elasticsearch Cluster # export ES_JAVA_OPTS=“-Dhttps.proxyHost=<プロキシIP> -Dhttps.proxyPort=<ポート>" # /usr/share/elasticsearch/bin/elasticsearch-plugin install discovery-ec2 # vi /etc/elasticsearch/elasticsearch.yml # --------------------------------- Discovery ---------------------------------- discovery.zen.hosts_provider: ec2 discovery.ec2.groups: "<SecurityGroupID>" discovery.ec2.availability_zones: [ "ap-northeast-1a", "ap-northeast-1c" ] cloud.aws.region: ap-northeast-1 # ---------------------------------- Cloud AWS -------------------------------- cloud: aws: protocol: https proxy: host: <プロキシサーバのIPアドレス> port: <プロキシサーバのポート番号> # systemctl restart elasticsearch 【導入手順】 ※プロキシサーバ環境の場合に必要 Elasticsearch Cluster用 IAMロールを割り当てる
  43. 43. 43 EC2 Repository S3 Pluginでバックアップとリストアを簡単に! シームレスにS3 Bucketに対して、IndexのSnapshotをバックアップとリストアが可能。 【参考】Snapshot And Restore https://www.elastic.co/guide/en/elasticsearch/reference/6.2/modules-snapshots.html#_repository_plugins Curator repository-s3 S3 Bucket (log-a) /backup/index # export ES_JAVA_OPTS=“-Dhttps.proxyHost=<プロキシIP> -Dhttps.proxyPort=<ポート>" # /usr/share/elasticsearch/bin/elasticsearch-plugin install repository-s3 【導入手順】 ※プロキシサーバ環境の場合に必要 Elasticsearch Index 1 2 Snapshot Curator用IAMロールを割り当てる PUT /_snapshot/my_s3_repository { "type": "s3", "settings": { "bucket": "log-a", "region": "ap-northeast-1", "base_path": "backup/index", "compress": "true", "server_side_encryption": "true" } }
  44. 44. 44 Elasticsearchノードをテンプレート化する時の考え方 Elasticsearchを導入してAMI化するとクラスタへの追加時にノードID重複となる。 EC2 CentOS 7 Java 8 Python Curator AMI EC2 CentOS 7 Java 8 Python Curator イメージ化 インスタンス作成  Java導入  Curator導入  Elasticsearchは導入しない Elasticsearch Elasticsearchを設定  Elasticsearch導入  ingest plugin導入  aws cloud plugin導入  elastisearch.yml設定  jvm.options設定  X-Pack導入 Elasticsearch Cluster ES01 ES02 ES03 1 2 3
  45. 45. 45 Elasticsearchのクラスタに対するAPIアクセス KibanaとElasticsearchが別ノードの場合はロードバランサを挟む必要がある。 【参考】Load Balancing Across Multiple Elasticsearch Nodes https://www.elastic.co/guide/en/kibana/current/production.html#load-balancing Elasticsearch Cluster Elasticsearch01 Elasticsearch02 Elasticsearch03 Kibana Internal-ELB TCP9200 TCP9200 # The URL of the Elasticsearch instance to use for all your queries. elasticsearch.url: “http://<Internal-ELBのFQDN>:9200" 【kibana.ymlの設定】 ※elasticsearch.urlは、URLを1つしか指定出来ない。
  46. 46. 46 Logstash
  47. 47. 47 LogstashをECSでコンテナサービス化しよう! コンテナ化することでLogstashをタスクとして実行することが可能になる。 ※Logstash 6xはMultipipeline対応しているので、そちらでもある程度いい感じに出来る。 EC2 (ビルドマシン) CentOS 7 Docker 1.12 CentOS 7 Logstash Dockerfile Image ECS ECR docker pushdocker build ECS Cluster EC2 (ECS最適化) EC2 (ECS最適化) Docker 1.12 ECS Agent Logstash Docker 1.12 ECS Agent Logstash docker pull ECS最適化AMI (ami-ab5ea9cd) 【ECS化のメリット】  障害時のエラーハンドリング  ログの量やリアルタイム性に応じた柔軟なサイジング 【IAMロール】 AmazonEC2ContainerRegistryPowerUser 【IAMロール】 AmazonEC2ContainerServiceforEC2Role
  48. 48. 48 ログは全てS3を介して取り込むべし ログ形式毎にフォルダを切ってS3にログを収集することで障害時のハンドリングが容易になる。 ログファイル データベース ネットワーク機器 イベントログ Filebeat Winlogbeat Logstash (収集) input jdbc input tcp/udp (syslog/netflow) S3 Bucket (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で保持される
  49. 49. 49 S3で難しいものは、泣く泣くCloudWatchLogs CloudTrailの操作ログはJSON形式だが、複数並列の[]がうまくパース出来ない問題。 S3アクセスログ CloudFront アクセスログ ELB アクセスログ CloudTrail 操作ログ RDS SQL監査ログ S3 Bucket Cloud Watch Logs Logstash (正規化) input s3 output es input cloudwatch_logs input { cloudwatch_logs { log_group => [ "CloudTrail/DefaultLogGroup" ] region => "ap-northeast-1“ codec => json } } 【参考】input cloudwatch-logs plugin https://github.com/lukewaite/logstash-input-cloudwatch-logs Elasticsearch
  50. 50. 50 Kibana
  51. 51. 51 Kibana認証と暗号化には、ELBとNginxを噛ませる デフォルトのままだとHTTP通信になるため、ELBでHTTPS(TCP443)化する。 また、Nginxの認証機能を利用して、Kibanaアクセスに認証機能を追加する。 Internet ElasticsearchKibanaExternal-ELB HTTPS(TCP443) セキュリティ運用者 (SOC等) # 送信元 宛先ポート 1 NginxのSecurity Group TCP 5601 # 送信元 宛先ポート 1 セキュリティ運用者のGIP TCP 443 Security Group # 送信元 宛先ポート 1 ELBのSecurity Group TCP 8080 2 ELBのSecurity Group TCP 8081 HTTP(TCP8080) HTTP(TCP5601) ELBヘルスチェックは、Kibanaまで到達出来るパスを指定し NginxまたはKibanaの障害時に切り替わるように設計する ①通信暗号化 ②ユーザ認証
  52. 52. 52 マルチテナント環境で利用する場合は... 1つのElasticsearch Clusterに対して、テナント(ユーザ企業)ごとにKibanaを用意する。 Kibana02 Kibana01 Kibanaxx Elasticsearch Cluster Internet ユーザ企業A社 (SOC運用担当) ユーザ企業B社 (SOC運用担当) ユーザ企業Z社 (SOC運用担当) ・ ・ ・ Store ELB01 ELB02 ELBxx ・ ・ ・ ・ ・ ・ Elasticsearch01 Elasticsearch02 Elasticsearch03 Elasticsearch04 Elasticsearch05
  53. 53. 53 Other Settings
  54. 54. 54 Elasticsearchに必要なIAMロール { "Statement": [ { "Action": [ "ec2:DescribeInstances“ ], "Effect": "Allow", "Resource": [ "*“ ] } ], "Version": "2012-10-17“ } Elasticsearch Cluster用 { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": "s3:*", “Resource”: “arn:aws:s3:::<S3 Bucket名>/backup/index/*“ } ] } Curator用
  55. 55. 55 Logstashに必要なIAMロール { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": "s3:*", "Resource": "*“ } ] } input S3用 { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "ecs:CreateCluster", "ecs:DeregisterContainerInstance", "ecs:DiscoverPollEndpoint", "ecs:Poll", "ecs:RegisterContainerInstance", "ecs:StartTelemetrySession", "ecs:UpdateContainerInstancesState", "ecs:Submit*", "ecr:GetAuthorizationToken", "ecr:BatchCheckLayerAvailability", "ecr:GetDownloadUrlForLayer", "ecr:BatchGetImage", "logs:CreateLogStream", "logs:PutLogEvents“ ], "Resource": "*“ } ] } ECSクラスタ用
  56. 56. 56 elasticsearch.ymlのサンプル # ---------------------------------- Cluster ----------------------------------- cluster.name: es_cluster01 # ------------------------------------ Node ------------------------------------ node.name: node-es01 # ---------------------------------- Network ----------------------------------- network.host: 0.0.0.0 # --------------------------------- Discovery ---------------------------------- discovery.zen.hosts_provider: ec2 discovery.ec2.groups: "<SecurityGroupID>" discovery.ec2.availability_zones: [ "ap-northeast-1a", "ap-northeast-1c" ] cloud.aws.region: ap-northeast-1 # ---------------------------------- Cloud AWS -------------------------------- cloud: aws: protocol: https proxy: host: <プロキシサーバのIPアドレス> port: <プロキシサーバのポート番号> AWSとの通信にプロキシサーバを介す場合
  57. 57. 57 logstash.confのサンプル 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" } } filter { date { timezone => "Asia/Tokyo“ } } output { elasticsearch { hosts => [ “internal-<ELB名>-<AWSアカウント>.ap-northeast-1.elb.amazonaws.com:9200" ] index => “log-a-%{+YYYY.MM.dd}" template_name => "log-a" } }
  58. 58. 58 Dockerfileのサンプル FROM centos:7 # Ensure Logstash gets a UTF-8 locale by default. ENV LANG='en_US.UTF-8' LC_ALL='en_US.UTF-8' # timezone settings RUN cp -p /usr/share/zoneinfo/Asia/Tokyo /etc/localtime # install java1.8.0 RUN yum install -y java-1.8.0-openjdk ENV JAVA_HOME=/usr/lib/jvm/jre-1.8.0 COPY java.sh /etc/profile.d/java.sh RUN chmod +x /etc/profile.d/java.sh # install logstash COPY elastic.repo /etc/yum.repos.d/ RUN yum install -y logstash-5.5.x COPY logstash.conf /etc/logstash/conf.d/logstash.conf COPY logstash.yml /etc/logstash/logstash.yml #install plugins RUN /usr/share/logstash/bin/logstash-plugin install <plugins名> # enable systemd ENV container docker # exec logstash RUN systemctl enable logstash.service EXPOSE 5044 CMD [“/usr/sbin/init”]

×