Query Elasticsearch via Python

Reference:

Elasticsearch Python Client

Examples 

Elasticsearch配置及python操作 

Elasticsearch查詢DSL

Querying Elasticsearch using @timestamp range 

Understanding the Elasticsearch Query DSL: A Quick Introduction 

Understanding the Elasticsearch Query DSL 

ElasticSearch实战系列二: ElasticSearch的DSL语句使用教程---图文详解

 

安裝：

RockyLinux 9.2 minimal
yum update python
python -m ensurepip

python -m pip install elasticsearch==7.x.x (安裝和 ELK 相同版本的python package)

copy cert to /root/cert/ca.crt (複製自建的根憑證)

Linux ACL 目錄/檔案權限繼承

Reference:

Linux ACL 檔案權限設定 setfacl、getfacl 指令使用教學與範例

Linux目录文件的权限、ACL、继承

 

有一台 NAS 的 NFS share 預設值會啟用 ACL，但預設權限是 770 (rwxrwx---)。

通常預設權限是 755，這個預設權限造成同 group 的帳號可以修改！

 

把 NAS ACL 設定關閉後，新建的目錄/檔案會按照帳號的 umask 權限，但之前已經產生的檔案必須自己修改。

 

查詢 ACL 指令：

getfacl <filename> 

移除 ACL 指令(含子目錄)：

setfacl -bR <filename>

移除 group 寫入檔案權限指令(含子目錄)：

chmod -R g-w .

找出目錄下有 group 寫入權限的檔案指令(排除symbolic links)：

find . -perm -g+w ! -type l

Hyper-V Replica

Reference:

New-SelfSignedCertificate

 

設定 Hyper-V Replica 必須有 https 憑證。

自己產生憑證的指令(10年有效期)：

New-SelfSignedCertificate -DnsName "hostname" -CertStoreLocation "cert:\LocalMachine\My" -TestRoot -NotAfter (Get-Date).AddMonths(120)

狀況：

來源主機 BLADE-33，目的主機 BLADE-38

(注意) 目的主機的Windows版本必須 大於/等於 來源主機

步驟：

• 在 BLADE-33, BLADE-38 各自產生憑證。將中繼憑證 CertReq Test Root 複製到 受信任的根憑證。
  

網站資安風險 Cloud Metadata Potentially Exposed

Reference:

Trust No One: The Perils of Trusting User Input

【Nginx】valid_referers 参数绕坑指南

狀況：OWASP ZAP掃描出高風險

High	Cloud Metadata Potentially Exposed
Description	The Cloud Metadata Attack attempts to abuse a misconfigured NGINX server in order to access the instance metadata maintained by cloud service providers such as AWS, GCP and Azure.
	All of these providers provide metadata via an internal unroutable IP address '169.254.169.254' - this can be exposed by incorrectly configured NGINX servers and accessed by using this IP address in the Host header field.
URL	https://xxx.com.tw/latest/meta-data/
Method	GET
Parameter
Attack	169.254.169.254
Evidence
Instances	1
Solution	Do not trust any user data in NGINX configs. In this case it is probably the use of the $host variable which is set from the 'Host' header and can be controlled by an attacker.
Reference	https://www.nginx.com/blog/trust-no-one-perils-of-trusting-user-input/
CWE Id
WASC Id
Plugin Id	90034