เสริมความปลอดภัยให้ Backend Applications ด้วย NGINX App Protect - ตอนที่ 4 - ปรับแต่ง NGINX App Protect - HTTP Compliance
Tags: node, waf, proen, appprotect
Published: 2021-10-01 14:54:52

*บทความนี้เป็นการใช้งาน NGINX Plus และ NGINX App Protect บน Proen Cloud จะมีค่าใช้จ่าย Subscription แบบรายเดือนครับ

ในตอนที่ 1 และ 2 เราได้ติดตั้ง NGINX Plus, NGINX App Protect รวมถึงการ Configure transparent mode

ตอนที่ 1 - ติดตั้ง NGINX Plus และ NGINX App Protect
https://bit.ly/napproen

ตอนที่ 2 - ปรับแต่ง NGINX App Protect - transparent mode
https://bit.ly/napproen-ep2

ตอนที่ 3 - ปรับแต่ง NGINX App Protect - Data Guard
https://bit.ly/napproen-ep3

วันนี้เราจะลงลึกไปอีกระดับ คือจะ Fine Tune ระดับ Component ของแต่ละ Signature โดยวันนี้โฟกัสที่ HTTP Compliance ซึ่งรวมถึง HTTPS ซึ่งวิ่งบน HTTP ด้วยนั่นเองครับ

หากเราต้องการเปิดใช้งาน HTTP Compliance ในระดับบทความก่อนหน้านี้ จะทำเพียงเลือกเปิดใช้ หรือปิดไม่ใช่เท่านั้นครับ แต่วันนี้เมื่อเปิดใช้แล้วเราสามารถ Fine Tune ว่า Compliance ข้อไหน ให้ใช้ ข้อไหนให้ยกเว้น ก็จะช่วยให้เรา Fine Tune สำหรับ Application ที่มีความเฉพาะ หรือมีการส่งข้อมูลผ่าน HTTP Protocol แบบพิเศษได้นั่นเองครับ

ทั้งนี้ HTTP Compliance หมายถึงข้อกำหนดอันดี ที่ HTTP ควรจะเป็นครับ แต่บ่อยครั้ง Application ที่มีการใช้งานเฉพาะ แม้ไม่เป็นการโจมตีแต่ก็จะไม่ตรง HTTP Compliance ทำให้ App นั้นๆ ใช้งานไม่ได้ จำเป็นต้องมีการ Fine Tune ตัว WAF ก่อนครับ ซึ่งเราจะทำได้ในตอนที่ 2 การใช้ transparent mode จากนั้นเราก็นำข้อมูลที่ได้มาปรับแต่งในตอนที่ 4 นี้

การทดสอบ เราสามารถทำต่อจากตอนที่ 1 ก็ได้ครับ(หากยังไม่ได้ Set ระบบไว้ ขอให้ย้อนทำตามตอนที่ 1 ก่อนครับ จากนั้นก็ต่อตอนที่ 4 ได้) หรือในการใช้งานจริง ก็จะเป็นการทำตอนที่ 2 ก่อนครับ แล้วถึงค่อยมา Fine Tune

ทดสอบเข้าใช้งานแบบปกติ สามารถใช้งานเว็บแบบปกติได้
![Alt Text](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/9kc9f9r3o03orx0timek.jpg)

ทดสอบการโจมตีด้วยเทคนิค Directory Traversal ไปยังไฟล์ htpasswd, ถูก Block โดย WAF นั่นคือ WAF ทำงานปกติ
![Alt Text](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/wt80qd7683rsqh90yosz.jpg)

ก่อนการปรับแต่ง เราจำเป็นต้องใช้สิทธิ์ root เพื่อแก้ไข WAF Policies

ที่ NGINX Load Balancer เลือก Add-ons และ Install Root Access Add-ons, กด Install
![Alt Text](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/aninzcbae4gmdc57s08u.jpg)

รอติดตั้งประมาณ 10s แล้วกด Close
![Alt Text](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/l5sdu77pugwwemk6subs.jpg)

SSH ไปที่เครื่อง NGINX Load Balancer, ยกระดับสิทธิ์การใช้งานเป็น root โดยพิมพ์คำสั่ง 'sudo -i'
![Alt Text](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/hbmqgf74fx75d2acff3t.jpg)

List file NGINX App Protect Policy โดย
'cd /etc/app_protect/conf'
'ls'
จะพบไฟล์ Policy เดิมที่มีอยู่แล้วครับ ให้เราทำการสร้างไฟล์ Policy ใหม่ขึ้นมา ชื่อNginxHTTPCompliance.json

'vi NginxHTTPCompliance.json'
Configure ตามนี้ครับ

{
    "name": "policy_name",
    "template": { "name": "POLICY_TEMPLATE_NGINX_BASE" },
    "applicationLanguage": "utf-8",
    "enforcementMode": "blocking",
    "blocking-settings": {
        "violations": [
            {
                "name": "VIOL_HTTP_PROTOCOL",
                "alarm": true,
                "block": true
            }
        ],
        "http-protocols": [
            {
                "description": "Header name with no header value",
                "enabled": true
            },
            {
                "description": "Chunked request with Content-Length header",
                "enabled": true
            },
            {
                "description": "Check maximum number of parameters",
                "enabled": true,
                "maxParams": 5
            },
            {
                "description": "Check maximum number of headers",
                "enabled": true,
                "maxHeaders": 20
            },
            {
                "description": "Body in GET or HEAD requests",
                "enabled": true
            },
            {
                "description": "Bad multipart/form-data request parsing",
                "enabled": true
            },
            {
                "description": "Bad multipart parameters parsing",
                "enabled": true
            },
            {
                "description": "Unescaped space in URL",
                "enabled": true
            }
        ]
    }
}

Save file จากนั้นแก้ไข NGINX Configuration ให้เรียกใช้ Policy NginxHTTPCompliance.conf และ Comment Policy เก่าครับ
vi /etc/nginx/app-protect.conf
![Alt Text](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/8k7qo1h36pcq5fjxpd1x.jpg)

จากนั้น reload configuration หากไม่มี Output ออกมา แสดงว่า reload สำเร็จครับ
![Alt Text](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/4mw7zzo4d56bu6moiu54.jpg)

เรามาทดสอบกันครับ เช่นการส่ง Header ตาม HTTP Compliance จะต้องมี Value ด้วย ตัวอย่างเช่น user=james

แต่ Application บางตัว อาจมีการเช็คว่ามี Header ที่ต้องการหรือไม่เท่านั้น โดยไม่สนใจว่ามีค่าใน Header นั้นๆ หรือไม่

ถ้าเรามี Application ลักษณะนี้อยู่ ซึ่งแน่นอนว่ามีการสร้างโดยไม่ตรงตาม HTTP Compliance ครับ และจะถูกบล็อกโดย WAF อย่างแน่นอน, เพื่อให้ Application ของเราทำงานได้ ก็จำเป็นต้องปรับแต่ง Rule ยกเว้น Compliance ข้อนี้ครับ

เราใช้ Postman มาช่วยในการปรับแต่ง Header ครับ เริ่มจากเรียกปกติก่อน สามารถเรียกได้
![image](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/nvpsg0vsfxva2kk05fdx.png)
 

ทดสอบเพิ่ม Header ที่ชื่อว่า Department โดยตั้งใจที่จะไม่ใส่ Value ลงไปครับ
![image](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/0nobpy20souiayc67bk3.png)
พบว่าถูก Reject

ตอนนี้เราจะใส่ Value ให้ครับ โดยกำหนดให้ Department=mobile
![Alt Text](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/2rwp364jixzog7eoa4zq.jpg)
พบว่าสามารถเรียกใช้งานได้ปกติแล้วครับ

ฉะนั้น ถ้าเรามี Application ที่มีการใช้งานในลักษณะที่ส่งเฉพาะ Header Department แต่ไม่มี Value แล้ว เราจะต้องปรับแต่ง Policy เพื่อให้รองรับครับ โดย
ปิด HTTP Compliance ในเรื่อง Header with no value โดยตั้ง enabled เป็น false 

'vi /etc/app_protect/conf/NginxHTTPCompliance.conf'

 ![image](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/zbqocqk57or6m6dnru1t.png)
 
ทำการ Save และ reload configuration หากไม่มี Output ออกมา แสดงว่า reload สำเร็จครับ
![Alt Text](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/4mw7zzo4d56bu6moiu54.jpg)

ทำการลบ Value ของ Header Department ออกครับ แล้วเรียกอีกครั้ง พบว่าครั้งนี้ไม่ถูก Reject แล้ว
![Alt Text](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/hl2d5qefqmghvtai1q24.jpg)

เท่านี้ WAF ก็ถูกปรับแต่งให้พร้อมใช้งานกับ Application ของเราครับ

เรายังสามารถปรับแต่ง HTTP Compliance อื่นๆ ได้อีกครับ เช่น กำหนดจำนวน Parameter ที่สามารถส่งได้ ให้ไม่เกิน 5 Parameters
![Alt Text](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/c1uo14vym4q0s0h0auyn.jpg)

Compliance ข้อนี้ จะช่วยป้องกันการโจมที่ ที่มีการส่ง parameter แบบ common lists จำนวนมากๆ  เข้ามา ก็จะถูก Block ไปทันทีครับ

ทดสอบการทำงาน ส่งเต็ม Quota = 5 Parameters ได้แก่ a, b, c, d, e พบว่าใช้งานได้ปกติ
![Alt Text](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/4q5aqjhr5l4ntfscrr39.jpg)

ลองเพิ่ม Parameters ให้เป็น 6 ตัว โดยเดิม f เข้าไป พบว่าถูก Reject
![Alt Text](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/gcq77dwqcnmx4vinj0u0.jpg)

เช่นเดียวกับตอนต้นครับ หาก Application ที่เราใช้งาน มีการส่ง Parameter มากกว่า 5 ตัว เราสามารถ Fine Tune เพิ่มจำนวน Parameter ได้ครับ

ในทางกลับกัน หาก Application ของเราต้องการ Parameter เพียงตัวเดียว ก็ลดจำนวน Parameter เหลือ 1 จะทำให้ WAF ของเรายิ่ง Strict มากขึ้น
![Alt Text](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/te3l2mellj9pp6hn2p1u.jpg)

ด้วยสถานการณ์ปัจจุบัน เราคงขึ้น Application โดยไม่มี WAF ไม่ได้แล้วครับ NGINX WAF มีจุดเด่นที่สามารถติดตั้งได้ใกล้กับ Application มากกว่า WAF เจ้าอื่น มี Signature รวมถึง Threat Campaign เดียวกับ F5 Advance WAF ทำให้มั่นใจได้ว่าครอบคลุมการโจมตีได้หลากหลาย


---
Series: เสริมความปลอดภัยให้ Backend Applications ด้วย NGINX App Protect


เสริมความปลอดภัยให้ Backend Applications ด้วย NGINX App Protect - ตอนที่ 1 - ติดตั้ง NGINX Plus และ NGINX App Protect
https://bit.ly/napproen

เสริมความปลอดภัยให้ Backend Applications ด้วย NGINX App Protect  - ตอนที่ 2 - ปรับแต่ง NGINX App Protect - transparent mode
https://bit.ly/napproen-ep2

เสริมความปลอดภัยให้ Backend Applications ด้วย NGINX App Protect - ตอนที่ 3 - ปรับแต่ง NGINX App Protect - Data Guard
https://bit.ly/napproen-ep3

เสริมความปลอดภัยให้ Backend Applications ด้วย NGINX App Protect - ตอนที่ 4 - ปรับแต่ง NGINX App Protect - HTTP Compliance
https://bit.ly/napproen-ep4

---
สัปดาห์หน้า พบกับ Protection Mechanism ถัดไป ติดตามได้ที่
FB Page: นั่งเล่น NGINX
https://web.facebook.com/NungLenNGINX
FB Group: ร่วมพูดคุยและแลกเปลี่ยนความรู้ไปกับเรา NGINX Super User TH
https://web.facebook.com/groups/394098015436072

เริ่มต้นใช้งานได้ที่ https://app.manage.proen.cloud/
มีทีม Support ให้ครับ
อีกหนึ่งช่องทาง nginx@mfec.co.th