NICによるWebアプリのセキュリティ

この章では、実際にデプロイしたNGINX Ingress Controllerを使い、Webアプリケーションに対するWAF・DoS対策の実施方法を確認します。 設定例は NGINX Inc GitHubの examples/custom-resources/ に管理されております

Syslog Serverのデプロイ

NGINX App Protect WAF、NGINX App Protect DoS 双方のセキュリティモジュールのログをSyslogサーバに転送し、結果を確認します。 まずはじめにSyslogサーバをデプロイします。

syslog.yaml は、NAP WAF、NAP DoSで利用します。
syslog2.yaml は、NAP DoSで利用します

Syslogイメージのデプロイ

cd ~/kubernetes-ingress/examples/custom-resources/app-protect-dos
kubectl apply -f syslog.yaml
kubectl apply -f syslog2.yaml

デプロイされた内容の確認

kubectl get deployment
実行結果サンプル
1NAME       READY   UP-TO-DATE   AVAILABLE   AGE
2syslog     1/1     1            1           9m
3syslog-2   1/1     1            1           9m
kubectl get svc| grep syslog-svc
実行結果サンプル
1syslog-svc     ClusterIP   10.96.250.209    <none>        514/TCP   9m
2syslog-svc-2   ClusterIP   10.103.224.109   <none>        514/UDP   9m

Ingress Controller で WAF機能(NGINX App Protect WAF) のデプロイ

https://github.com/nginxinc/kubernetes-ingress/tree/v3.1.1/examples/custom-resources/app-protect-waf

サンプルアプリケーションをデプロイ

アプリケーションをデプロイします。

cd ~/kubernetes-ingress/examples/custom-resources/app-protect-waf
kubectl apply -f webapp.yaml
kubectl apply -f ap-apple-uds.yaml
kubectl apply -f ap-dataguard-alarm-policy.yaml
kubectl apply -f ap-logconf.yaml
kubectl apply -f waf.yaml
kubectl apply -f virtual-server.yaml

Syslogサーバのログの出力状況を確認します。新たに同ホストへ接続するターミナルを1つ用意し、ログを表示してください

SyslogサーバのPod名を確認します

kubectl get pod
実行結果サンプル
1NAME                       READY   STATUS    RESTARTS       AGE
2syslog-2-96dfdf5c6-7t8d4   1/1     Running   0              1h
3syslog-cccc648c6-2n9v4     1/1     Running   0              1h
4webapp-64d444885-bgrj7     1/1     Running   0              6m

syslog、それぞれのPOD名を参考に、追加するターミナルでログを表示してください。

# 追加するターミナル1 で 'syslog' の情報を表示する
kubectl exec -it <syslog POD名> --  tail -f /var/log/messages

リソースを確認

ポイントとなるファイルの内容を確認します。

NAP WAFのPolicyでは様々なセキュリティ機能を用いて外部からの攻撃をブロックします。 外部からの様々な攻撃を通信の特徴や、リクエストに含まれる文字列などから検知・ブロックするためのルールとしてSignatureがあります。 NAP WAFではお客様アプリケーションに合わせた制御や、特定の通信を制御するため、ユーザ定義シグネチャ(User-Defined Signature)の定義が可能です

こちらで設定する ユーザ定義シグネチャ の詳細は、以下の内容を参照してください。
NGINX Ingress Controller での NAP WAF の詳細は、以下のページを参照してください。
ap-apple-uds.yaml は、ユーザ独自のシグネチャの定義となります。
条件は rule に指定された内容となります。また、tagとして Fruits を指定します。
ap-apple-uds.yaml
 1apiVersion: appprotect.f5.com/v1beta1
 2kind: APUserSig
 3metadata:
 4  name: apple
 5spec:
 6  signatures:
 7  - accuracy: medium
 8    attackType:
 9      name: Brute Force Attack
10    description: Medium accuracy user defined signature with tag (Fruits)
11    name: Apple_medium_acc
12    risk: medium
13    rule: content:"apple"; nocase;
14    signatureType: request
15    systems:
16    - name: Microsoft Windows
17    - name: Unix/Linux
18  tag: Fruits

ap-dataguard-alarm-policy.yaml は、App ProtectのPolicy設定となります。tagとして Fruits を持つシグネチャを参照・有効にしています

ap-dataguard-alarm-policy.yaml
 1apiVersion: appprotect.f5.com/v1beta1
 2kind: APPolicy
 3metadata:
 4  name: dataguard-alarm
 5spec:
 6  policy:
 7    signature-requirements:
 8    - tag: Fruits
 9    signature-sets:
10    - name: apple_sigs
11      block: true
12      signatureSet:
13        filter:
14          tagValue: Fruits
15          tagFilter: eq
16    applicationLanguage: utf-8
17    blocking-settings:
18      violations:
19      - alarm: true
20        block: false
21        name: VIOL_DATA_GUARD
22    data-guard:
23      creditCardNumbers: true
24      enabled: true
25      enforcementMode: ignore-urls-in-list
26      enforcementUrls: []
27      lastCcnDigitsToExpose: 4
28      lastSsnDigitsToExpose: 4
29      maskData: true
30      usSocialSecurityNumbers: true
31    enforcementMode: blocking
32    name: dataguard-alarm
33    template:
34      name: POLICY_TEMPLATE_NGINX_BASE

ap-logconf.yaml は、Logの定義に関する設定となります。

ap-logconf.yaml
 1apiVersion: appprotect.f5.com/v1beta1
 2kind: APLogConf
 3metadata:
 4  name: logconf
 5spec:
 6  content:
 7    format: default
 8    max_message_size: 64k
 9    max_request_size: any
10  filter:
11    request_type: all

waf.yaml は、VirtualServerが参照するPolicy設定となります。利用するApp ProtectのPolicyとして dataguard-alarm を指定し、Log 設定として logconf を指定します。

waf.yaml
 1apiVersion: k8s.nginx.org/v1
 2kind: Policy
 3metadata:
 4  name: waf-policy
 5spec:
 6  waf:
 7    enable: true
 8    apPolicy: "default/dataguard-alarm"
 9    securityLog:
10      enable: true
11      apLogConf: "default/logconf"
12      logDest: "syslog:server=syslog-svc.default:514"

virtual-server.yaml で、作成した waf-poicy を割り当てます

virtual-server.yaml
 1apiVersion: k8s.nginx.org/v1
 2kind: VirtualServer
 3metadata:
 4  name: webapp
 5spec:
 6  host: webapp.example.com
 7  policies:
 8  - name: waf-policy
 9  upstreams:
10  - name: webapp
11    service: webapp-svc
12    port: 80
13  routes:
14  - path: /
15    action:
16      pass: webapp

以下の通り、各リソースを適切に作成されていることを確認します。

kubectl get APUserSig
実行結果サンプル
1NAME    AGE
2apple   38m
kubectl get aplogconf
実行結果サンプル
1NAME      AGE
2logconf   39m
kubectl get appolicy
実行結果サンプル
1NAME              AGE
2dataguard-alarm   39m
kubectl get policy
実行結果サンプル
1NAME         STATE   AGE
2waf-policy   Valid   41m

動作確認

curlコマンドでリクエストを送信します。

curl -v --resolve webapp.example.com:80:127.0.0.1 "http://webapp.example.com/"
実行結果サンプル
 1* Added webapp.example.com:80:127.0.0.1 to DNS cache
 2* Hostname webapp.example.com was found in DNS cache
 3*   Trying 127.0.0.1:80...
 4* TCP_NODELAY set
 5* Connected to webapp.example.com (127.0.0.1) port 80 (#0)
 6> GET / HTTP/1.1
 7> Host: webapp.example.com
 8> User-Agent: curl/7.68.0
 9> Accept: */*
10>
11* Mark bundle as not supporting multiuse
12< HTTP/1.1 200 OK
13< Content-Type: text/plain
14< Content-Length: 157
15< Connection: keep-alive
16< Expires: Thu, 20 Jan 2022 03:07:27 GMT
17< Cache-Control: no-cache
18<
19Server address: 192.168.127.42:8080
20Server name: webapp-64d444885-jg6hf
21Date: 20/Jan/2022:03:07:28 +0000
22URI: /
23Request ID: e0b6f00106a11885f85300ffcaf5b912
24* Connection #0 to host webapp.example.com left intact

ログメッセージを見ると、通信をブロックせず転送(PASSED)していることが確認できます。NGINX App ProtectはBot Signatureの機能をもっておりますので、curlコマンドであることを“人によるブラウザの通信ではなくBot Clientである”という形で検知をしておりますが、即座に驚異であると判断される設定となっておりませんので適切な通信としてWebアプリケーションへ転送が行われております。

該当するSyslogのサンプル
 1Jan 20 03:07:28 nginx-ingress-5ddc7f4f-zjlt2 ASM:
 2attack_type="Non-browser Client",
 3blocking_exception_reason="N/A",
 4date_time="2022-01-20 03:07:28",
 5dest_port="80",
 6ip_client="10.1.1.9",
 7is_truncated="false",
 8method="GET",
 9policy_name="dataguard-alarm",
10protocol="HTTP",
11request_status="alerted",
12response_code="200",
13severity="Critical",
14sig_cves="N/A",
15sig_ids="N/A",
16sig_names="N/A",
17sig_set_names="N/A",
18src_port="49443",
19sub_violations="N/A",
20support_id="16242938385820378173",
21threat_campaign_names="N/A",
22unit_hostname="nginx-ingress-5ddc7f4f-zjlt2",
23uri="/",
24violation_rating="0",
25vs_name="32-webapp.example.com:8-/",
26x_forwarded_for_header_value="N/A",
27outcome="PASSED",
28outcome_reason="SECURITY_WAF_VIOLATION_TRANSPARENT_MODE",
29violations="Bot Client Detected",
30violation_details="N/A",
31bot_signature_name="curl",
32bot_category="HTTP Library",
33bot_anomalies="N/A",
34enforced_bot_anomalies="N/A",
35client_class="Untrusted Bot",
36client_application="N/A",
37client_application_version="N/A",
38request="GET / HTTP/1.1\r\nHost: webapp.example.com\r\nUser-Agent: curl/7.68.0\r\nAccept: */*\r\n\r\n",
39transport_protocol="HTTP/1.1"

次にNAP WAFで攻撃として検知するリクエストを、curlコマンドで送信します。クロスサイトスクリプティング(XSS)を想定した接続をします。

curl -v --resolve webapp.example.com:80:127.0.0.1 "http://webapp.example.com/<script>"
実行結果サンプル (区切り位置で改行して表示)
 1* Added webapp.example.com:80:127.0.0.1 to DNS cache
 2* Hostname webapp.example.com was found in DNS cache
 3*   Trying 127.0.0.1:80...
 4* TCP_NODELAY set
 5* Connected to webapp.example.com (127.0.0.1) port 80 (#0)
 6> GET /<script> HTTP/1.1
 7> Host: webapp.example.com
 8> User-Agent: curl/7.68.0
 9> Accept: */*
10>
11* Mark bundle as not supporting multiuse
12< HTTP/1.1 200 OK
13< Content-Type: text/html; charset=utf-8
14< Connection: close
15< Cache-Control: no-cache
16< Pragma: no-cache
17< Content-Length: 247
18<
19* Closing connection 0
20<html><head><title>Request Rejected</title></head><body>The requested URL was rejected. Please consult with your administrator.<br><br>Your support ID is: 16242938385820378683<br><br><a href='javascript:history.back();'>[Go Back]</a></body></html>

通信が 拒否 され、エラーページが応答されています。 support ID に表示される値を確認してください。

ログメッセージを見ると、URLに不正な文字列が含まれており、XSS script tag(URI)などのSignatureで検知、通信をブロック(REJECTED)していることが確認できます。また、 violation_rating="5" となっています。Violation Rating はNAP WAFが通信の内容を元にリクエストのリスクを判定します。デフォルトテンプレートはこちらの値を元にブロックする挙動となります。詳細は以下のページを参照してください。
該当するSyslogのサンプル
 1Jan 20 03:07:39 nginx-ingress-5ddc7f4f-zjlt2 ASM:
 2attack_type="Non-browser Client,Abuse of Functionality,Cross Site Scripting (XSS)",
 3blocking_exception_reason="N/A",
 4date_time="2022-01-20 03:07:39",
 5dest_port="80",
 6ip_client="10.1.1.9",
 7is_truncated="false",
 8method="GET",
 9policy_name="dataguard-alarm",
10protocol="HTTP",
11request_status="blocked",
12response_code="0",
13severity="Critical",
14sig_cves="N/A",
15sig_ids="200000099,200000093",
16sig_names="XSS script tag (URI),XSS script tag end (URI)",
17sig_set_names="{Cross Site Scripting Signatures;High Accuracy Signatures},{Cross Site Scripting Signatures;High Accuracy Signatures}",
18src_port="61276",
19sub_violations="N/A",
20support_id="16242938385820378683",
21threat_campaign_names="N/A",
22unit_hostname="nginx-ingress-5ddc7f4f-zjlt2",
23uri="/<script>",
24violation_rating="5",
25vs_name="32-webapp.example.com:8-/",
26x_forwarded_for_header_value="N/A",
27outcome="REJECTED",
28outcome_reason="SECURITY_WAF_VIOLATION",
29violations="Illegal meta character in URL,Attack signature detected,Violation Rating Threat detected,Bot Client Detected",
30violation_details="<?xml version='1.0' encoding='UTF-8'?><BAD_MSG><violation_masks><block>410000000200c00-3a03030c30000072-8000000000000000-0</block><alarm>2477f0ffcbbd0fea-befbf35cb000007e-8000000000000000-0</alarm><learn>0-20-0-0</learn><staging>0-0-0-0</staging></violation_masks><request-violations><violation><viol_index>42</viol_index><viol_name>VIOL_ATTACK_SIGNATURE</viol_name><context>url</context><sig_data><sig_id>200000099</sig_id><blocking_mask>3</blocking_mask><kw_data><buffer>LzxzY3JpcHQ+</buffer><offset>1</offset><length>7</length></kw_data></sig_data><sig_data><sig_id>200000093</sig_id><blocking_mask>3</blocking_mask><kw_data><buffer>LzxzY3JpcHQ+</buffer><offset>2</offset><length>7</length></kw_data></sig_data></violation><violation><viol_index>26</viol_index><viol_name>VIOL_URL_METACHAR</viol_name><uri>LzxzY3JpcHQ+</uri><metachar_index>60</metachar_index><wildcard_entity>*</wildcard_entity><staging>0</staging></violation><violation><viol_index>26</viol_index><viol_name>VIOL_URL_METACHAR</viol_name><uri>LzxzY3JpcHQ+</uri><metachar_index>62</metachar_index><wildcard_entity>*</wildcard_entity><staging>0</staging></violation></request-violations></BAD_MSG>",
31bot_signature_name="curl",
32bot_category="HTTP Library",
33bot_anomalies="N/A",
34enforced_bot_anomalies="N/A",
35client_class="Untrusted Bot",
36client_application="N/A",
37client_application_version="N/A",
38request="GET /<script> HTTP/1.1\r\nHost: webapp.example.com\r\nUser-Agent: curl/7.68.0\r\nAccept: */*\r\n\r\n",
39transport_protocol="HTTP/1.1"

参考の情報ですが、curlコマンドの <script>?a=a?%27+OR+1=1– などの文字列に入れ替えると、SQL Injectionのブロックを見ることができますのでご確認ください。

User Defined Signatureで指定した内容が正しく動作しているか確認します。Webアプリケーションに”apple”という文字を送信します。

curl -v --resolve webapp.example.com:80:127.0.0.1 "http://webapp.example.com/" -X POST -d "apple"
実行結果サンプル (区切り位置で改行して表示)
 1Note: Unnecessary use of -X or --request, POST is already inferred.
 2* Added webapp.example.com:80:127.0.0.1 to DNS cache
 3* Hostname webapp.example.com was found in DNS cache
 4*   Trying 127.0.0.1:80...
 5* TCP_NODELAY set
 6* Connected to webapp.example.com (127.0.0.1) port 80 (#0)
 7> POST / HTTP/1.1
 8> Host: webapp.example.com
 9> User-Agent: curl/7.68.0
10> Accept: */*
11> Content-Length: 5
12> Content-Type: application/x-www-form-urlencoded
13>
14* upload completely sent off: 5 out of 5 bytes
15* Mark bundle as not supporting multiuse
16< HTTP/1.1 200 OK
17< Content-Type: text/html; charset=utf-8
18< Connection: close
19< Cache-Control: no-cache
20< Pragma: no-cache
21< Content-Length: 247
22<
23* Closing connection 0
24<html><head><title>Request Rejected</title></head><body>The requested URL was rejected. Please consult with your administrator.<br><br>Your support ID is: 16242938385820379193<br><br><a href='javascript:history.back();'>[Go Back]</a></body></html>

ログメッセージを見ると、該当のログメッセージが、User Defined Signatureの Apple_medium_acc というSignature Nameで検知されブロック(REJECTED)されていることが確認できます。

該当するSyslogのサンプル (区切り位置で改行して表示)
 1Jan 20 03:07:51 nginx-ingress-5ddc7f4f-zjlt2 ASM:
 2attack_type="Non-browser Client,Brute Force Attack",
 3blocking_exception_reason="N/A",
 4date_time="2022-01-20 03:07:51",
 5dest_port="80",
 6ip_client="10.1.1.9",
 7is_truncated="false",
 8method="POST",
 9policy_name="dataguard-alarm",
10protocol="HTTP",
11request_status="blocked",
12response_code="0",
13severity="Critical",
14sig_cves="N/A",
15sig_ids="300000000",
16sig_names="Apple_medium_acc [Fruits]",
17sig_set_names="{apple_sigs}",
18src_port="63409",
19sub_violations="N/A",
20support_id="16242938385820379193",
21threat_campaign_names="N/A",
22unit_hostname="nginx-ingress-5ddc7f4f-zjlt2",
23uri="/",
24violation_rating="2",
25vs_name="32-webapp.example.com:8-/",
26x_forwarded_for_header_value="N/A",
27outcome="REJECTED",
28outcome_reason="SECURITY_WAF_VIOLATION",
29violations="Attack signature detected,Bot Client Detected",
30violation_details="<?xml version='1.0' encoding='UTF-8'?><BAD_MSG><violation_masks><block>410000000200c00-3a03030c30000072-8000000000000000-0</block><alarm>2477f0ffcbbd0fea-befbf35cb000007e-8000000000000000-0</alarm><learn>0-20-0-0</learn><staging>0-0-0-0</staging></violation_masks><request-violations><violation><viol_index>42</viol_index><viol_name>VIOL_ATTACK_SIGNATURE</viol_name><context>request</context><sig_data><sig_id>300000000</sig_id><blocking_mask>3</blocking_mask><kw_data><buffer>YXBwbGU=</buffer><offset>0</offset><length>5</length></kw_data></sig_data></violation></request-violations></BAD_MSG>",
31bot_signature_name="curl",
32bot_category="HTTP Library",
33bot_anomalies="N/A",
34enforced_bot_anomalies="N/A",
35client_class="Untrusted Bot",
36client_application="N/A",
37client_application_version="N/A",
38request="POST / HTTP/1.1\r\nHost: webapp.example.com\r\nUser-Agent: curl/7.68.0\r\nAccept: */*\r\nContent-Length: 5\r\nContent-Type: application/x-www-form-urlencoded\r\n\r\napple",
39transport_protocol="HTTP/1.1"

リソースの削除

## cd ~/kubernetes-ingress/examples/custom-resources/waf
kubectl delete -f webapp.yaml
kubectl delete -f ap-apple-uds.yaml
kubectl delete -f ap-dataguard-alarm-policy.yaml
kubectl delete -f ap-logconf.yaml
kubectl delete -f waf.yaml
kubectl delete -f virtual-server.yaml

Ingress Controller で 高度なDoS対策機能(NGINX App Protect DoS) のデプロイ

https://github.com/nginxinc/kubernetes-ingress/tree/v3.1.1/examples/custom-resources/app-protect-dos

サンプルアプリケーションをデプロイ

アプリケーションをデプロイします。

cd ~/kubernetes-ingress/examples/custom-resources/app-protect-dos
kubectl apply -f webapp.yaml
kubectl apply -f apdos-protected.yaml
kubectl apply -f apdos-policy.yaml
kubectl apply -f apdos-logconf.yaml
kubectl apply -f virtual-server.yaml

Syslogサーバのログの出力状況を確認します。新たに同ホストへ接続するターミナルを2つ用意し、それぞれのターミナルでログを表示してください

SyslogサーバのPod名を確認します

kubectl get pod
実行結果サンプル
1NAME                       READY   STATUS    RESTARTS       AGE
2syslog-2-96dfdf5c6-7t8d4   1/1     Running   0              1h
3syslog-cccc648c6-2n9v4     1/1     Running   0              1h
4webapp-64d444885-bgrj7     1/1     Running   0              6m

syslog、syslog-2 それぞれのPOD名を参考に、追加するターミナルでログを表示してください。

# 追加するターミナル1 で 'syslog' の情報を表示する
kubectl exec -it <syslog POD名> --  tail -f /var/log/messages
# 追加するターミナル2 で 'syslog-2' の情報を表示する
kubectl exec -it <syslog-2 POD名> -- tail -f /var/log/messages

リソースを確認

ポイントとなるファイルの内容を確認します。

apdos-policy.yaml は、DosProtectResourceが参照する NAP DoS の Policy 設定となります。

apdos-policy.yaml
 1apiVersion: appprotectdos.f5.com/v1beta1
 2kind: APDosPolicy
 3metadata:
 4  name: dospolicy
 5spec:
 6  mitigation_mode: "standard"
 7  signatures: "on"
 8  bad_actors: "on"
 9  automation_tools_detection: "on"
10  tls_fingerprint: "on"

apdos-logconf.yaml は、DosProtectResourceが参照する Security Log の設定となります。

apdos-logconf.yaml
 1apiVersion: appprotectdos.f5.com/v1beta1
 2kind: APDosLogConf
 3metadata:
 4  name: doslogconf
 5spec:
 6  content:
 7    format: splunk
 8    max_message_size: 64k
 9  filter:
10    traffic-mitigation-stats: all
11    bad-actors: top 10
12    attack-signatures: top 10

apdos-protected.yaml は、VirtualServerが参照する DosProtectResource の設定となります。 利用するNAP DoSのリソースとして dospolicy を指定し、Dos Access Log、Dos Security Logを指定します。

apdos-protected.yaml
 1apiVersion: appprotectdos.f5.com/v1beta1
 2kind: DosProtectedResource
 3metadata:
 4  name: dos-protected
 5spec:
 6  enable: true
 7  name: "webapp.example.com"
 8  apDosPolicy: "dospolicy"
 9  apDosMonitor:
10    uri: "webapp.example.com"
11    protocol: "http1"
12    timeout: 5
13  dosAccessLogDest: "syslog-svc-2.default.svc.cluster.local:514"
14  dosSecurityLog:
15    enable: true
16    apDosLogConf: "doslogconf"
17    dosLogDest: "syslog-svc.default.svc.cluster.local:514"

virtual-server.yaml で、作成した dos-protected を割り当てます

virtual-server.yaml
 1apiVersion: k8s.nginx.org/v1
 2kind: VirtualServer
 3metadata:
 4  name: webapp
 5spec:
 6  host: webapp.example.com
 7  upstreams:
 8    - name: webapp
 9      service: webapp-svc
10      port: 80
11  routes:
12    - path: /
13      dos: dos-protected
14      action:
15        pass: webapp

以下の通り、各リソースを適切に作成されていることを確認します。

kubectl get apdoslogconf
実行結果サンプル
1NAME         AGE
2doslogconf   10m
kubectl get apdospolicy
実行結果サンプル
1NAME        AGE
2dospolicy   10m
kubectl get DosProtectedResource
実行結果サンプル
1NAME            AGE
2dos-protected   11m
kubectl get vs
実行結果サンプル
1NAME     STATE   HOST                 IP    PORTS   AGE
2webapp   Valid   webapp.example.com                 12m
kubectl get deployment
実行結果サンプル
1NAME       READY   UP-TO-DATE   AVAILABLE   AGE
2syslog     1/1     1            1           1h
3syslog-2   1/1     1            1           1h
4webapp     1/1     1            1           13m

動作確認

curl -H "Host:webapp.example.com" http://localhost/
実行結果サンプル
1Server address: 192.168.127.38:8080
2Server name: webapp-64d444885-bgrj7
3Date: 20/Jan/2022:09:30:55 +0000
4URI: /
5Request ID: 8b6810ab8c5a8eabacb9d7da9d775094
Terminal2 Log:Access Log (区切り位置で改行して表示)
1# Terminal2 log : 上記アクセスをした際に、以下のログが出力されます
2Jan 20 09:30:55 nginx-ingress-5ddc7f4f-zjlt2 nginx: ,
3vs_name_al=default/dos-protected/webapp.example.com,
4ip=10.1.1.9,
5tls_fp=-,
6outcome=Allow,
7reason=Allow,
8ip_tls=10.1.1.9:-,
Terminal1 Log:Security Log (区切り位置で改行して表示)
 1# Terminal1 log : 定期的にログが出力されます
 2Jan 20 09:30:57 syslog-cccc648c6-2n9v4 syslog-ng[1]: Syslog connection accepted; fd='20', client='AF_INET(192.168.127.46:34588)', local='AF_INET(0.0.0.0:514)'
 3Jan 20 09:30:57 192-168-127-46 date_time="Jan 20 2022 09:30:57",
 4product="app-protect-dos",
 5product_version="25+2.1.8-1~buster",
 6unit_hostname="nginx-ingress-5ddc7f4f-zjlt2",
 7instance_id=".scope",
 8vs_name="default/dos-protected/webapp.example.com",
 9dos_attack_id="0",
10attack_event="No Attack",
11stress_level="0.50",
12learning_confidence="Not ready",
13baseline_dps="0",
14incoming_dps="0",
15incoming_rps="0",
16successful_tps="0",
17unsuccessful_rps="0",
18incoming_datagrams="11",
19incoming_requests="11",
20successful_responses="5",
21unsuccessful_requests="6",
22active_connections="0",
23threshold_dps="2121.60",
24threshold_conns="2121.60",
25mitigated_bad_actors="0",
26mitigated_by_signatures="0",
27mitigated_by_global_rate="0",
28mitigated_slow="0",
29redirect_global="0",
30redirect_bad_actor="0",
31redirect_signature="0",
32redirect_slow="0",
33challenge_global="0",
34challenge_bad_actor="0",
35challenge_signature="0",
36challenge_slow="0",
37block_global="0",
38block_bad_actor="0",
39block_signature="0",
40block_slow="0",
41mitigated_connections="0",
42mitigated_bad_actors_rps="0",
43mitigated_by_signatures_rps="0",
44mitigated_by_global_rate_rps="0",
45mitigated_slow_rps="0",
46redirect_global_rps="0",
47redirect_bad_actor_rps="0",
48redirect_signature_rps="0",
49redirect_slow_rps="0",
50challenge_global_rps="0",
51challenge_bad_actor_rps="0",
52challenge_signature_rps="0",
53challenge_slow_rps="0",
54block_global_rps="0",
55block_bad_actor_rps="0",
56block_signature_rps="0",
57block_slow_rps="0",
58mitigated_connections_rps="0",
59Jan 20 09:30:57 syslog-cccc648c6-2n9v4 syslog-ng[1]: Syslog connection closed; fd='20', client='AF_INET(192.168.127.46:34588)', local='AF_INET(0.0.0.0:514)'

リソースの削除

## cd ~/kubernetes-ingress/examples/custom-resources/app-protect-dos
## 設定の削除
kubectl delete -f webapp.yaml
kubectl delete -f apdos-protected.yaml
kubectl delete -f apdos-policy.yaml
kubectl delete -f apdos-logconf.yaml
kubectl delete -f virtual-server.yaml

## Syslogの削除
kubectl delete -f syslog.yaml
kubectl delete -f syslog2.yaml